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

[Jori Koolstra <jkoolstra@xs4all.nl>]

> Op 22-07-2026 15:10 CEST schreef Christoph Hellwig <hch@infradead.org>:
> 
>  
> 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.

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