[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiH4-v3YxzN9_obL8Z_d9+TiFOdXwiDAauHqO-1vymY-w@mail.gmail.com>
Date: Mon, 6 Oct 2025 13:51:58 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Chuck Lever <cel@...nel.org>, Christian Brauner <brauner@...nel.org>,
Johannes Berg <johannes@...solutions.net>
Cc: 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, 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.
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
Powered by blists - more mailing lists