Re: Understanding locking for buf

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Thu, 09 Mar 2023 00:40:04 UTC
On Wed, Mar 08, 2023 at 10:19:23AM +0100, Alexander Lochmann wrote:
> On 03.03.23 01:19, Konstantin Belousov wrote:
> > All it means it that the statistic output by mount -v would be somewhat off
> > in the split of io ops by sync/async.  The total count is still correct.
> Ic. Thx.
> 
> So. The b_lock is subject to the ownership switch even if a synchronous read
> via breadn_flags() and bufwait() is performed. Am I right?
> 
> In our log, I see the following:
> - Kernel tries to mount the rootfs via readsuper(). The thread id is 100002.
> - 100002 allocates an instance of struct buf.
> - The b_lock is acquired by 100002 in buf_alloc().
> - Various accesses to buf by 100002.
> - Various accesses to buf by 100033 during g_vfs_done().
> - Again various accesses to buf by 100002.
> - The instances is unlocked and freed by 100002. (readsuper() ->
> ffs_use_bread() -> brelse() -> buf_free()[ -> BUF_UNLOCK()])
> 
> If that instance's ownership were changed during the IO op, the b_lock would
> have been unlocked by the wrong context.
> Is that correct? Am I missing something?
I said that sometimes it is still subject to change even with sync ops.