[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa3510f3-d3cc-45d2-b38e-e8717e2a9f83@ddn.com>
Date: Wed, 18 Oct 2023 11:52:03 +0000
From: Bernd Schubert <bschubert@....com>
To: André Draszik <andre.draszik@...aro.org>
CC: Miklos Szeredi <mszeredi@...hat.com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Revert "fuse: Apply flags2 only when userspace set the
FUSE_INIT_EXT"
On 10/18/23 13:46, André Draszik wrote:
> On Wed, 2023-10-18 at 11:39 +0000, Bernd Schubert wrote:
>> On 10/18/23 13:15, André Draszik wrote:
>>> From: André Draszik <andre.draszik@...aro.org>
>>>
>>> This reverts commit 3066ff93476c35679cb07a97cce37d9bb07632ff.
>>>
>>> This patch breaks all existing userspace by requiring updates as
>>> mentioned in the commit message, which is not allowed.
>>>
>>> Revert to restore compatibility with existing userspace
>>> implementations.
>>
>> Which fuse file system does it exactly break? In fact there haven't
>> been
>> added too many flags after - what exactly is broken?
>
> The original patch broke the existing kernel <-> user ABI by now
> requiring user space applications to pass in an extra flag.
> There are various side-effects of this, like unbootable systems, just
> because the kernel was updated.
> Breaking the ABI is the one thing that is not allowed. This is not
> specific to any particular fuse file system.
How exactly did it break it? These are feature flags - is there really a
file system that relies on these flag to the extend that it does not
work anymore?
Also, reverting this patch has the side effect that you can ask the
kernel to use initialized bits - which obviously has other side effects.
Thanks,
Bernd
Powered by blists - more mailing lists