On 05/16, Waiman Long wrote: > > On 05/16/2018 06:48 AM, Oleg Nesterov wrote: > > On 05/15, Waiman Long wrote: > >> There are use cases where a rwsem can be acquired by one task, but > >> released by another task. In thess cases, optimistic spinning may need > >> to be disabled. One example will be the filesystem freeze/thaw code > > You do not read my emails ;) > > > > Let me repeat once again that in this particular case the writer will > > never spin because of owner == NULL. freeze_super() checks SB_UNFROZEN > > under sb->s_umount and only then calls sb_wait_write(). IOW, sb_wait_write() > > can only be called when this rwsem was already released by the previous > > writer. > > > > I am not arguing with this change, percpu_rwsem_release/acquire may have > > another user sometime, but the changelog is not accurate. > > I know the change may not be necessary in this particular case, but it > is a correctness issue. Really? I mean, performance-wise the unnecessary spinning is obviously bad, but why it is a correctness issue? And how this differs from the case when down_write() is preempted right before rwsem_set_owner() ? > Optimistic spinning should be disabled when the > exact time delay between percpu_rwsem_release() and > percpu_rwsem_acquire() is indeterminate even though no one is supposed > to spin on the rwsem during that time. > > If we don't do that now, we may forget this issue when See above, I never argued with this change. Just the changelog looks as if we already have this issue in freeze/thaw code, this is not true. Oleg.
