[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26c34ef2-8309-4625-9bee-bb3e5c056568@kernel.org>
Date: Mon, 6 Oct 2025 16:58:22 -0400
From: Chuck Lever <cel@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.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 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.
> 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
Powered by blists - more mailing lists