Re: Understanding locking for buf

On Mon, Feb 27, 2023 at 09:38:47AM +0100, Alexander Lochmann wrote:
> On 24.02.23 21:41, Konstantin Belousov wrote:
> > > Viewing it from a different angle: Are accesses in g_vfs_done safe because
> > > the buf instance is already locked from a global perspective?
> > > Hence, other code paths would block on BUF_LOCK().
> > geom completion code is the only code that allowed to touch the buffer
> > after the ownership was relinguished.
> > 
> > I believe I already tell that to you: consider the buffer lock after
> > LK_KERNPROC as a semaphore and not lock.
> Yeah, you already did. I understand it.
> When synchronous IO is performed, the LK_KERNPROC thing isn't used. The lock
> is still owned by the context that triggered the IO operation.
Not quite.  Sync io (bread()) means that caller performs bufwait() on the
buffer.  It is still subject to the LK_KERNPROC ownership move.

> Am I right that even in this situation the accesses from g_vfs_done are
> performed?
I hope that the previous note answers this.

> Can those accesses be considered as valid exceptions of the overall locking
> rule 'use b_lock' since the buf is locked?
I am not sure what would be 'valid exceptions'.  I explained the locking scheme
used.