Re: Understanding locking for buf
- Reply: Alexander Lochmann : "Re: Understanding locking for buf"
- In reply to: Alexander Lochmann : "Re: Understanding locking for buf"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.