linux-kernel - Re: [PATCH v4 1/2] locking/rwsem: Add a new RWSEM_ANONYMOUSLY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180516152712.GA29871@redhat.com>
Date:   Wed, 16 May 2018 17:27:13 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     Waiman Long <longman@...hat.com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Davidlohr Bueso <dave@...olabs.net>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Amir Goldstein <amir73il@...il.com>, Jan Kara <jack@...e.cz>,
        Matthew Wilcox <willy@...radead.org>
Subject: Re: [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.