linux-kernel - Re: [PATCH v2] Revert "fuse: Apply flags2 only when userspace set the FUSE_INIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Oct 2023 15:03:28 +0200
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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 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.

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?

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

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.

Thanks,
Miklos