On 09.02.21 13:00, Jan Kara wrote:
>>> Yes, although in last year, people try to convert these unlocked reads to
>>> READ_ONCE() or similar as otherwise the compiler is apparently allowed to
>>> generate code which is not safe. But that's a different story.
>> Is this ongoing work?
> 
> Yes, in a way. It's mostly prompted by KCSAN warnings generated by syzbot
> ;).
> 
>> Using such a macro would a) make our work much easier as we can instrument
>> them, and b) would tell less experienced developers that no locking is
>> needed.
> 
> Yes, I agree that it has some benefit for documentation and automatic
> checkers as well. OTOH code readability is sometimes hurt by this...
> 
>> Does the usage of READ_ONCE() imply that no lock is needed?
> 
> No, but it does indicate there's something unusual happening with the
> variable - usually that variable write can race with this read.
> 
>> Otherwise, one could introduce another macro for jbd2, such as #define
>> READ_UNLOCKED() READ_ONCE(), which is more precise.
> 
> Well, yes, but OTOH special macros for small subsystems like this are making
> more harm than good in terms of readability since people have to lookup
> what exactly they mean anyway.
So the only option left would be a global macro such as READ_ONCE() I guess.
How hard would it be to establish such a global notation?
It would make things a lot easier for LockDoc, because we can instrument 
such a macro, and therefore can annotate those accesses.>
> Definitely. The simplest case is: You can fetch
> journal->j_running_transaction pointer any time without any problem. But
> you can *dereference* it only if you hold the j_state_lock while fetching the
> pointer and dereferencing it.
Thx.
> 
>> So sometimes requiring the lock is just the least
>>> problematic solution - there's always the tradeoff between the speed and
>>> simplicity.
>>>
>>>>> All of the above members have word size, i.e., int, long, or ptr.
>>>>> Is it therefore safe to split the locking documentation as follows?
>>>>> @j_flags: General journaling state flags [r:nolocks, w:j_state_lock]
>>>
>>> I've checked the code and we usually use unlocked reads for quick, possibly
>>> racy checks and if they indicate we may need to do something then take the
>>> lock and do a reliable check. This is quite common pattern, not sure how to
>>> best document this. Maybe like [j_state_lock, no lock for quick racy checks]?
>>>
>> Yeah, I'm fine with that. Does this rule apply for the other members of
>> journal_t (and transaction_t?) listed above?
> 
> Yes.
Thx. I'll submit a patch for those elements.
For now, this will improve LockDoc's results as we can add "no locks 
needed" to our config for j_flags. We check whether the observed 
accesses match the documented locking rules.
LockDoc will accept both results "j_list_lock" and "no locks needed" for 
reading j_flags.
However, real faulty unlocked accesses will be concealed. :-(

- Alex
> 
> 								Honza
> 

-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al