Re: Understanding locking for buf

On Tue, Mar 21, 2023 at 02:54:35PM +0100, Alexander Lochmann wrote:
> 
> 
> On 20.03.23 19:07, Konstantin Belousov wrote:
> > On Mon, Mar 20, 2023 at 11:25:30AM +0100, Alexander Lochmann wrote:
> > > 
> > > 
> > > On 16.03.23 12:24, Konstantin Belousov wrote:
> > > > > 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.
> > > Thx. But the top-level thread, using getblk(), legitimately releases the
> > > lock. Am I right?
> > No.  It does not, please re-read what I wrote.
> Yeah, but that's what I meant a few mails ago.
> The lock is acquired *and* released by the top-level thread. Although some
> accesses happen from the geom thread.
Sometimes yes, the buffer lifecycle is managed in the way you demonstrated
below.

I do not understand the goal of this conversation.  Can you formulate what
you are trying to achieve, please?
> 
> (The numbers are the logged thread ids.)
> 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()])