On 7/17/19 3:22 PM, Jan Stancek wrote: > On Wed, Jul 17, 2019 at 10:19:04AM -0400, Waiman Long wrote: >>> If you add a comment to the code outlining the issue (preferably as >>> a litmus >>> test involving sem->count and some shared data which happens to be >>> vmacache_seqnum in your test)), then: >>> >>> Reviewed-by: Will Deacon <w...@kernel.org> >>> >>> Thanks, >>> >>> Will >> >> Agreed. A comment just above smp_acquire__after_ctrl_dep() on why this >> is needed will be great. >> >> Other than that, >> >> Acked-by: Waiman Long <long...@redhat.com> >> > > litmus test looks a bit long, would following be acceptable? > > diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c > index 37524a47f002..d9c96651bfc7 100644 > --- a/kernel/locking/rwsem.c > +++ b/kernel/locking/rwsem.c > @@ -1032,6 +1032,13 @@ static inline bool > rwsem_reader_phase_trylock(struct rw_semaphore *sem, > */ > if (adjustment && !(atomic_long_read(&sem->count) & > (RWSEM_WRITER_MASK | RWSEM_FLAG_HANDOFF))) { > + /* > + * down_read() issued ACQUIRE on enter, but we can race > + * with writer who did RELEASE only after us. > + * ACQUIRE here makes sure reader operations happen only > + * after all writer ones. > + */
How about that? /* * Add an acquire barrier here to make sure no stale data * acquired before the above test where the writer may still * be holding the lock will be reused in the reader critical * section. */ Thanks, Longman