Date: Thu, 16 Mar 2023 13:24:24 +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: <ZBL8aN49i2bcEKuj@kib.kiev.ua> In-Reply-To: <6b1181f7-a58f-8d71-a05e-2dcb0a66ae4c@tu-dortmund.de> References: <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> <ZAkq5HSXp4QEjXeu@kib.kiev.ua> <6b1181f7-a58f-8d71-a05e-2dcb0a66ae4c@tu-dortmund.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 16, 2023 at 10:03:15AM +0100, Alexander Lochmann wrote: > > > On 09.03.23 01:40, Konstantin Belousov wrote: > > > 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()]) > > I said that sometimes it is still subject to change even with sync ops. > Ok. Thx. > > Is the following correct? > The aforementioned accesses by 100033 in g_vfs_done() are no violations with > respect to the locking rule because from a global perspective the buf is > locked. It is the only concurrent access at that moment. I would formulate it differently: No other thread might legitimately get access to the buffer using either bread() or getblk() until current io operation finishes. The io operation is handled in two contexts: top-level, where a thread used getblk() as usual to claim buffer ownership, and completion thread context (geom up thread). The completion code legitimately manipulates the buffer, because the top-level code expects that after the buffer strategy routine is called, effectively moving the ownership to the geom up thread.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZBL8aN49i2bcEKuj>