On Tue 09-02-21 14:47:28, Alexander Lochmann wrote:

On 09.02.21 13:00, Jan Kara wrote:

quoted

quoted

quoted

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
;).

quoted

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...

quoted

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.

quoted

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.>

Well, READ_ONCE() macro already exists in the kernel and is used in quite
some places. Generally, there's concensus that newly added unlocked
accesses should use that macro. But the amount of already existing unlocked
accesses in the kernel is large and the problem is mostly theoretical / for
machine checkers so there's some resistance to the churn generated by
global search-and-replace approach. But as I said we are moving in that
direction and eventually get there.

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR