Re: [PATCH 0/3] Backport statx(..., NULL, AT_EMPTY_PATH, ...)

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Thu, Sep 19, 2024 at 01:37:17AM +0800, Xi Ruoyao wrote:
> On Wed, 2024-09-18 at 19:33 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Sep 18, 2024 at 10:01:18PM +0800, Miao Wang via B4 Relay wrote:
> > > Commit 0ef625bba6fb ("vfs: support statx(..., NULL, AT_EMPTY_PATH,
> > > ...)") added support for passing in NULL when AT_EMPTY_PATH is given,
> > > improving performance when statx is used for fetching stat informantion
> > > from a given fd, which is especially important for 32-bit platforms.
> > > This commit also improved the performance when an empty string is given
> > > by short-circuiting the handling of such paths.
> > > 
> > > This series is based on the commits in the Linus’ tree. Sligth
> > > modifications are applied to the context of the patches for cleanly
> > > applying.
> > > 
> > > Tested-by: Xi Ruoyao <xry111@xry111.site>
> > > Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
> > 
> > This really looks like a brand new feature wanting to be backported, so
> > why does it qualify under the stable kernel rules as fixing something?
> > 
> > I am willing to take some kinds of "fixes performance issues" new
> > features when the subsystem maintainers agree and ask for it, but that
> > doesn't seem to be the case here, and so without their approval and
> > agreement that this is relevant, we can't accept them.
> 
> Unfortunately the performance issue fix and the new feature are in the
> same commit.  Is it acceptable to separate out the performance fix part
> for stable?  (Basically remove "if (!path) return true;" from the 1st
> patch.)

What prevents you, if you wish to have the increased performance, from
just moving to a newer kernel version?  We add new features and
improvements like this all the time, why is this one so special to
warrant doing backports.  Especially with no maintainer or subsystem
developer asking for this to be done?

thanks,

greg k-h