[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023102757-cornflake-pry-e788@gregkh>
Date: Fri, 27 Oct 2023 15:11:54 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Miklos Szeredi <mszeredi@...hat.com>
Cc: Linux regressions mailing list <regressions@...ts.linux.dev>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Paul Lawrence <paullawrence@...gle.com>,
Daniel Rosenberg <drosen@...gle.com>,
Alessio Balsini <balsini@...roid.com>,
Amir Goldstein <amir73il@...il.com>,
Bernd Schubert <bschubert@....com>,
André Draszik <andre.draszik@...aro.org>
Subject: Re: [PATCH v2] Revert "fuse: Apply flags2 only when userspace set
the FUSE_INIT_EXT"
On Fri, Oct 27, 2023 at 03:03:28PM +0200, Miklos Szeredi wrote:
> On Fri, Oct 27, 2023 at 2:46 PM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
>
> > I'm talking about a patch where you are changing the existing
> > user/kernel api by filtering out values that you previously accepted.
> > And it was done in a patch saying "this might break userspace", and
> > guess what, it did!
> >
> > So why not revert it as obviously you all anticipated that this might
> > happen?
>
> Because it's a useful patch, and while I mentioned the possibility of
> a regression, I definitely didn't expect it to happen.
But it did :(
> And I still think that the Android case doesn't count, because it's
> just a completely different environment. What can happen on Android
> may not happen on non-Android and vice versa. Why should I revert a
> useful patch, because it causes a regression in a downstream kernel,
> because of an Android only patch?
It's not all that different of an environment, they use a stock kernel,
you can boot an android device just fine for many years without any
changes.
I would argue there are less changes in an android kernel than an
"enterprise" linux distro kernel these days by far :)
> > The "internal" patch from Android was just using the upper values of the
> > fuse api because they didn't want to conflict with the upstream values
> > before their code was accepted (and it was submitted already, but not
> > accepted.)
> >
> > So how do you want developers to work on changes before they are
> > accepted with this user/kernel numbering scheme that you have? You just
> > broke anyone who was using a not-accepted-in-the-tree value, right?
>
> Again, upstream and downstream. There's a reason why some companies
> have upstream first policies: because it's less painful in the long
> run. Android having decided to go ahead and add that patch is not my
> problem, and I really really don't want to care.
I think you rejected Android's changes, so what were they supposed to
do? Or someone did, I can't remember when it was submitted, but i do
remember seeing the patches flow by on some list...
> Having said all that, if there's a regression that someone reports for
> upstream flags (even on a vendor kernel), I'll just revert the patch
> right away.
So because Android userspace is sending a flag value that is not in the
upstream table, this breakage is ok? Or do you mean something else, I'm
getting confused.
thanks,
greg k-h
Powered by blists - more mailing lists