Hi Thorsten, (sorry for the slow reply) On Wed, 2023-11-01 at 13:36 +0100, Linux regression tracking (Thorsten Leemhuis) wrote: > I'm taken a bit back and forth here and it seems we are stuck again. > So > let me try again to hopefully clear things up a bit: > > André, could you please state > > * What practical use-case actually stopped working? It's impossible to use a newer kernel together with an older user space which is something that Android had been supporting for a long time. > * What Linux kernel version actually worked for your (because if > thing > broke when you upgraded from a vendor kernel to a vanilla kernel than > this does not qualify as regression IMHO) We are using the Android kernel in all cases and Android applies patches on top of Linus' tree, yes (as does everybody else). The previous Android kernel worked, the current Android kernel doesn't because of the patch in question. I think Greg made some valid points before: https://lore.kernel.org/all/2023102731-wobbly-glimpse-97f5@gregkh/ > 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! I guess it boils down to an an agreement regarding Greg's previous questions/points: https://lore.kernel.org/all/2023102757-cornflake-pry-e788@gregkh/ > So because Android userspace is sending a flag value that is not in > the upstream table, this breakage is ok? and https://lore.kernel.org/all/2023102740-think-hatless-ab87@gregkh/ > now older Android userspace breaks with newer kernels because of this > commit, which you all even agreed might happen here! > > So either you have a policy of "we only care about libfuse use cases > for this api", or you don't, which is fine, just say so. But that's > not what the changelog says. But I agree, it seems we're stuck and I'm not sure how to resolve this either, Miklos has his points, Android has a different position. Cheers, Andre'
