On Tue, Feb 18, 2025 at 05:29:53PM +0100, Christoph Hellwig wrote: > On Tue, Feb 18, 2025 at 09:45:02PM +0800, Ming Lei wrote: > > IMO, this RO attributes needn't protection from q->limits_lock: > > > > - no lifetime issue > > > > - in-tree code needn't limits_lock. > > > > - all are scalar variable, so the attribute itself is updated atomically > > Except in the memory model they aren't without READ_ONCE/WRITE_ONCE. RW_ONCE is supposed for avoiding compiler optimization, and scalar variable atomic update should be decided by hardware. > > Given that the limits_lock is not a hot lock taking the lock is a very > easy way to mark our intent. And if we get things like thread thread > sanitizer patches merged that will become essential. Even KCSAN > might object already without it. My main concern is that there are too many ->store()/->load() variants now, but not deal if you think this way is fine, :-) Thanks, Ming
