lkml.org 
[lkml]   [2018]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 1/2] locking/rwsem: Add a new RWSEM_ANONYMOUSLY_OWNED flag
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.

\
 
 \ /
  Last update: 2018-05-16 17:28    [W:0.185 / U:1.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site