linux-kernel - Re: nfsd_copy_write_verifier: wrong usage of read_seqbegin_or

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]

Date:   Wed, 25 Oct 2023 20:19:14 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     Chuck Lever <chuck.lever@...cle.com>
Cc:     Jeff Layton <jlayton@...nel.org>, Neil Brown <neilb@...e.de>,
        Olga Kornievskaia <kolga@...app.com>,
        Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,
        Ingo Molnar <mingo@...hat.com>, linux-nfs@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: nfsd_copy_write_verifier: wrong usage of read_seqbegin_or_lock()

On 10/25, Chuck Lever wrote:
>
> On Wed, Oct 25, 2023 at 07:54:36PM +0200, Oleg Nesterov wrote:
> > On 10/25, Chuck Lever wrote:
> > >
> > > > Another question is why we can't simply turn nn->writeverf into seqcount_t.
> > > > I guess we can't because nfsd_reset_write_verifier() needs spin_lock() to
> > > > serialise with itself, right?
> > >
> > > "reset" is supposed to be very rare operation. Using a lock in that
> > > case is probably quite acceptable, as long as reading the verifier
> > > is wait-free and guaranteed to be untorn.
> > >
> > > But a seqcount_t is only 32 bits.
> >
> > Again, I don't understand you.
> >
> > Once again, we can turn writeverf into seqcount_t, see the patch below.
>
> The patch below does not turn "writeverf" into a seqcount_t, it
> turns "writeverf_lock" into a seqcount_t.

Yes, typo. Of course I meant writeverf_lock. A bit strange it was not clear.

> Your original proposal made no sense.

Which one??? I thought that you agree that the current nfsd_copy_write_verifier()
code makes no send, at least that is how I interpreted your previous email. Confused.

> But I see now what you
> would like to change.

OK,

> I'm not familiar enough with these primitives to have a strong
> opinion. What do you think would be the benefit?

See above. And just in case let me repeat. No, I don't think we can/should turn
writeverf_lock (double check I didn't say "writeverf") into seqcount_t.

Oleg.