From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 48EB54420 for ; Fri, 27 Oct 2023 13:11:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="KKjhLe9b" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62F8EC433C7; Fri, 27 Oct 2023 13:11:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1698412316; bh=gqKsefNfAE2NujQeI+bmZ4vCEw2udQtY+8UsABoc8uU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KKjhLe9bI0q1V1YbURGnamPRx0+wvhNbwtlXsYzvK+Zz1qR7e6FJG2xtVs8dskOWy 6YEGMk3ctlnFnU65GCAH6qHjQpPyOuiffGYCAkb9qPdi2BDSiT+EvX421HNpx1cnvt nYa+gZ+nEtv31U7EshS+voJ5AwY69U8oyuchrb8E= Date: Fri, 27 Oct 2023 15:11:54 +0200 From: Greg Kroah-Hartman To: Miklos Szeredi Cc: Linux regressions mailing list , "stable@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Paul Lawrence , Daniel Rosenberg , Alessio Balsini , Amir Goldstein , Bernd Schubert , =?iso-8859-1?Q?Andr=E9?= Draszik Subject: Re: [PATCH v2] Revert "fuse: Apply flags2 only when userspace set the FUSE_INIT_EXT" Message-ID: <2023102757-cornflake-pry-e788@gregkh> References: <1b03f355170333f20ee20e47c5f355dc73d3a91c.camel@linaro.org> <9afc3152-5448-42eb-a7f4-4167fc8bc589@ddn.com> <5cd87a64-c506-46f2-9fed-ac8a74658631@ddn.com> <8ae8ce4d-6323-4160-848a-5e94895ae60e@leemhuis.info> <2023102731-wobbly-glimpse-97f5@gregkh> <2023102740-think-hatless-ab87@gregkh> Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 > 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