linux-kernel - Re: [GIT PULL] NFSD changes for v6.18

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: <20251007-zoodirektor-widder-27776d2e7228@brauner>
Date: Tue, 7 Oct 2025 13:26:02 +0200
From: Christian Brauner <brauner@...nel.org>
To: Chuck Lever <cel@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	Johannes Berg <johannes@...solutions.net>, linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org, 
	Jeff Layton <jlayton@...nel.org>
Subject: Re: [GIT PULL] NFSD changes for v6.18

On Mon, Oct 06, 2025 at 04:58:22PM -0400, Chuck Lever wrote:
> On 10/6/25 4:51 PM, Linus Torvalds wrote:
> > On Mon, 6 Oct 2025 at 06:50, Chuck Lever <cel@...nel.org> wrote:
> >>
> >> One potential merge conflict has been reported for nfsd-6.18.
> > 
> > No problem, this is the simple kind of explicit conflict (famous last
> > words before I mess one of those things up).
> > 
> > Anyway, the reason I'm replying is actually that I notice that you
> > added that ATTR_CTIME_SET flag in <linux/fs.h> in commit afc5b36e29b9
> > ("vfs: add ATTR_CTIME_SET flag").
> > 
> > No complaints about it, but it looks a bit odd with ATTR_{A,M}TIME_SET
> > in bits 7 and 8, and then the new ATTR_CTIME_SET is in bit 10 with the
> > entirely unrelated ATTR_FORCE in between them all.
> 
> Oof. We should have gotten Acks for "vfs: add ATTR_CTIME_SET flag". My
> bad.

Yes, indeed. I wondered why I hadn't seen this patch.

> 
> 
> > So I'm thinking it would look cleaner if we just swapped
> > ATTR_CTIME_SET and ATTR_FORCE around - these are all just our own
> > kernel-internal bits (and the reason bit 10 was unused is that it used
> > to contain the odd ATTR_ATTR_FLAG that was never used).
> > 
> > Danger Will Robinson: hostfs has odd duplicate copies of all these, including a
> > 
> >    #define HOSTFS_ATTR_ATTR_FLAG   1024
> > 
> > of that no-longer existing flag.
> > 
> > But hostfs doesn't use ATTR_FORCE (aka HOSTFS_ATTR_FORCE), so
> > switching those two bits around wouldn't affect it either, even if you
> > were to have a version mismatch between the client and host when doing
> > UML (which I don't know
> > 
> > Adding Christian to the participants list, because I did *not* do that
> > cleanup thing myself, because I'm slightly worried that I'm missing
> > something. But it would seem to be a good thing to do just to have the
> > numbering make more sense, and Christian is probably the right person.
> > 
> > And adding Johannes Berg due to the UML connection, just to see that I
> > haven't misread that odd hostfs situation.
> > 
> > Comments?
> > 
> >             Linus
> 
> 
> -- 
> Chuck Lever