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] [day] [month] [year] [list]
Message-ID: <20251007-ausholen-wohlklang-832361d2e995@brauner>
Date: Tue, 7 Oct 2025 14:06:56 +0200
From: Christian Brauner <brauner@...nel.org>
To: Jeff Layton <jlayton@...nel.org>
Cc: Chuck Lever <cel@...nel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Johannes Berg <johannes@...solutions.net>, 
	linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org
Subject: Re: [GIT PULL] NFSD changes for v6.18

On Tue, Oct 07, 2025 at 07:47:39AM -0400, Jeff Layton wrote:
> On Tue, 2025-10-07 at 13:26 +0200, Christian Brauner wrote:
> > 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.
> > 
> 
> I did send it to fsdevel, but you may have missed it in the deluge. Mea
> culpa from me too -- I should have noticed that you guys hadn't acked
> this yet. Any objection?

No, it looks sane overally.

I think we should renumber. Frankly, I would also prefer for stuff like
this to be enums. It makes debugging for stuff like drgn that people use
easier and imho also looks nicer in the code. But that's a matter of
taste. And the renumbering might be the bigger win as Linus suggested.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ