Re: [PATCH v3 09/14] vfs: add O_CREAT|O_DIRECTORY to open*(2)

[NeilBrown]

On Wed, 22 Jul 2026, Jori Koolstra wrote:
> > Op 22-07-2026 15:10 CEST schreef Christoph Hellwig <hch@xxxxxxxxxxxxx>:
> > 
> >  
> > 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.
> > 
> 
> If you want your software to be compatible with any Frankenstein-kernel
> you just check what you O_CREATed is in fact a directory. If it is and
> there is no EINVAL/EISDIR, you are running a supported kernel,
> if it isn't, you're not.
> 
> Or you just require a minimal reasonable kernel version.

Without getting all the arguments about how people should write their
apps and choose their kernels.....

Given how easy it would be to make this bullet proof by adding a "fail
if this combination isn't explicit permitted" flag to openat2 - why
don't we just do that so that it is EASY to write as safe app and EASY
to choose a kernel (i.e. any kernel at all with do).

NeilBrown


> 
> > 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.
>