Re: Understanding locking for buf

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.