Linux filesystem development
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Pedro Falcato <pfalcato@suse.de>,
	Jori Koolstra <jkoolstra@xs4all.nl>,
	Jeff Layton <jlayton@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Aleksa Sarai <aleksa@amutable.com>, NeilBrown <neil@brown.name>,
	Amir Goldstein <amir73il@gmail.com>, Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/14] vfs: add O_CREAT|O_DIRECTORY to open*(2)
Date: Wed, 22 Jul 2026 06:10:24 -0700	[thread overview]
Message-ID: <amDBQN5lCGbRxGWm@infradead.org> (raw)
In-Reply-To: <20260722-mundpropaganda-vorwahl-funkverkehr-48efdde92a00@brauner>

On Wed, Jul 22, 2026 at 02:51:54PM +0200, Christian Brauner wrote:
> > No, we can't rely on something being backport to old enterprise/cloud
> > kernel.  Doing so makes the interface unusable for actual applications.
> 
> It's backported to all LTS kernels for multiple years and this
> nonsensical theory of using a software version with O_DIRECTORY |
> O_CREAT on a pre-LTS kernel from years ago is just flimsy.

the kernel has always ignored unknown open flags, or unchecked
combinations and you can't just silently give them a meaning unless
it is backwars compatible.  That has nothing to do with this particular
combination.

> 
> Even just the mere fact that I was able to just backport that bugfix
> that started returning hard errors to all LTS kernels with absolutely
> zero regression reports defeats that argument. We've done way more
> invasive changes. This is a strawman really. 

Of course it didn't break anything yet because no one used it yet.
One we give it a meaning it will be used and break.  And if you like
it or not, a lot o Linux deployment is not using recent stable releases
or even tracking the -stable releases at all.

Just like we've always done in the past we'll need to APIs that don't
accidentally do the wrong thing on any old kernel.  We've survived doing
it this way the last 25 years (maybe longer, but that's about how long
I've been around) and there is no reason to magically change this now.


  reply	other threads:[~2026-07-22 13:10 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-04 16:41 [PATCH v3 00/14] vfs: add O_CREAT|O_DIRECTORY to open*(2) Jori Koolstra
2026-07-04 16:41 ` [PATCH v3 01/14] fs/namei.c: use trailing_slashes() Jori Koolstra
2026-07-06  3:56   ` NeilBrown
2026-07-06  7:29     ` David Laight
2026-07-06 20:55       ` Jori Koolstra
2026-07-07  7:42         ` David Laight
2026-07-07 10:51   ` Christian Brauner
2026-07-04 16:41 ` [PATCH v3 02/14] vfs: move create error && negative dentry case in lookup_open() up Jori Koolstra
2026-07-04 16:41 ` [PATCH v3 03/14] vfs: prepare vfs_creat|mkdir_no_perm for reuse in lookup_open() Jori Koolstra
2026-07-07 10:51   ` Christian Brauner
2026-07-04 16:41 ` [PATCH v3 04/14] vfs: call audit_inode_child() in lookup_open() on failure too Jori Koolstra
2026-07-06  5:33   ` NeilBrown
2026-07-06 21:20     ` Jori Koolstra
2026-07-06 23:02       ` NeilBrown
2026-07-07 10:51   ` Christian Brauner
2026-07-04 16:41 ` [PATCH v3 05/14] fs/namei.c: update docstring of atomic_open() Jori Koolstra
2026-07-06  5:36   ` NeilBrown
2026-07-07 10:51   ` Christian Brauner
2026-07-04 16:41 ` [PATCH v3 06/14] vfs: lookup_open(): move setting FMODE_CREATED down Jori Koolstra
2026-07-04 16:41 ` [PATCH v3 07/14] vfs: move ->create check in lookup_open() to before try_break_deleg() Jori Koolstra
2026-07-06  5:37   ` NeilBrown
2026-07-07 10:51   ` Christian Brauner
2026-07-04 16:41 ` [PATCH v3 08/14] vfs: lookup_open(): use vfs_create_no_perm() Jori Koolstra
2026-07-06  5:38   ` NeilBrown
2026-07-07 10:51   ` Christian Brauner
2026-07-04 16:41 ` [PATCH v3 09/14] vfs: add O_CREAT|O_DIRECTORY to open*(2) Jori Koolstra
2026-07-06  5:46   ` NeilBrown
2026-07-07  8:35   ` Pedro Falcato
2026-07-07 10:04     ` Christian Brauner
2026-07-07 13:04       ` Pedro Falcato
2026-07-07 13:30         ` Christian Brauner
2026-07-13  9:54       ` Christoph Hellwig
2026-07-13 21:35         ` NeilBrown
2026-07-14  5:10           ` Christoph Hellwig
2026-07-14 10:50             ` Jori Koolstra
2026-07-14 10:46         ` Jori Koolstra
2026-07-22 12:51         ` Christian Brauner
2026-07-22 13:10           ` Christoph Hellwig [this message]
2026-07-22 13:27             ` Jori Koolstra
2026-07-22 21:57               ` NeilBrown
2026-07-23  0:10                 ` Jori Koolstra
2026-07-24  9:33                   ` Christian Brauner
2026-07-24 13:04                     ` Jori Koolstra
2026-07-07 10:06     ` Jori Koolstra
2026-07-07 13:55       ` Pedro Falcato
2026-07-07 14:18         ` Jori Koolstra
2026-07-08 15:39           ` Pedro Falcato
2026-07-09  6:24             ` Christoph Hellwig
2026-07-09 10:51               ` Jori Koolstra
2026-07-09 14:21                 ` Christian Brauner
2026-07-09 14:34                   ` Jori Koolstra
2026-07-13  9:50                   ` Christoph Hellwig
2026-07-07 10:51   ` Christian Brauner
2026-07-10 18:55     ` Jori Koolstra
2026-07-12 12:39       ` Christian Brauner
2026-07-04 16:41 ` [PATCH v3 10/14] vfs: move O_IS_MKDIR check from lookup_open() into individual filesystems Jori Koolstra
2026-07-06  5:50   ` NeilBrown
2026-07-07 10:51   ` Christian Brauner
2026-07-04 16:41 ` [PATCH v3 11/14] vfs: refuse O_CREAT for directories through a dangling symlink Jori Koolstra
2026-07-06  5:51   ` NeilBrown
2026-07-04 16:41 ` [PATCH v3 12/14] vfs: short-circuit MAY_WRITE access for O_DIRECTORY opens Jori Koolstra
2026-07-06  5:51   ` NeilBrown
2026-07-04 16:41 ` [PATCH v3 13/14] selftest: fix headers in fclog.c Jori Koolstra
2026-07-06  5:57   ` NeilBrown
2026-07-06 21:07     ` Jori Koolstra
2026-07-07 10:51   ` Christian Brauner
2026-07-04 16:41 ` [PATCH v3 14/14] selftest: add tests for open*(O_CREAT|O_DIRECTORY) Jori Koolstra
2026-07-07 10:51   ` Christian Brauner
2026-07-07 10:51 ` [PATCH v3 00/14] vfs: add O_CREAT|O_DIRECTORY to open*(2) Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amDBQN5lCGbRxGWm@infradead.org \
    --to=hch@infradead.org \
    --cc=aleksa@amutable.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=jkoolstra@xs4all.nl \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=pfalcato@suse.de \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox