Date: Thu, 9 Mar 2023 02:40:04 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alexander Lochmann <alexander.lochmann@tu-dortmund.de> Cc: freebsd-fs@freebsd.org Subject: Re: Understanding locking for buf Message-ID: <ZAkq5HSXp4QEjXeu@kib.kiev.ua> In-Reply-To: <ac91fec9-9b26-c770-409c-040ea4545e8c@tu-dortmund.de> References: <45d84dae-0ca9-95ed-f6fd-8243797453ff@tu-dortmund.de> <Y/khDDKYYnt4Y6aO@kib.kiev.ua> <8e8d9145-9ee1-195e-3dd3-4e3166ac8abb@tu-dortmund.de> <Y/y8851RQLGR1VwS@kib.kiev.ua> <8e9ac2ec-6387-27b0-5cdc-1d61dbe2c831@tu-dortmund.de> <Y/4fz/hEyNiTjGmb@kib.kiev.ua> <1743b9f5-69be-b775-fb57-92b8115d4a81@tu-dortmund.de> <ZAE9FKivOiVYGggy@kib.kiev.ua> <ac91fec9-9b26-c770-409c-040ea4545e8c@tu-dortmund.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZAkq5HSXp4QEjXeu>