Re: Understanding locking for buf

On 23.03.23 12:56, Konstantin Belousov wrote:
> 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()])
Sure!

I want to know whether those accesses by thread 100033 in g_vfs_done() 
are valid 'exceptions' to the locking rule 'use b_lock to protect parts 
of struct buf'. I'd call it an exception because the lock is neither 
acquired nor released by thread 100033.
I'd have expected this thread to acquire the b_lock before accessing 
struct buf due to the aforementioned locking rule.
 From a global perspective, however, the corresponding buf is locked, 
and any other thread doing a lock() on b_lock will wait. Furthermore, 
thread 100002 does a bufwait, and is blocked as well.
Hence, the thread 100033 is the only one accessing it.

I'm quite certain that the acquisition and the release of the lock is 
performed by the thread 100002, and no owner transfer takes place.
If, however, an ownership transfer took place, the lock should not have 
been released by thread 100002.

- Alex

-- 
Technische Universität Dortmund
Computer Science XII - System Software Group
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
https://sys.cs.tu-dortmund.de/al