Re: Understanding locking for buf
- Reply: Konstantin Belousov : "Re: Understanding locking for buf"
- In reply to: Konstantin Belousov : "Re: Understanding locking for buf"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 08 Mar 2023 09:19:23 UTC
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? - Alex -- Technische Universität Dortmund Computer Science XII - System Software Group Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 https://sys.cs.tu-dortmund.de/al