From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 859CDC0218F for ; Thu, 30 Jan 2025 14:31:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 144702800B1; Thu, 30 Jan 2025 09:31:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F49E280058; Thu, 30 Jan 2025 09:31:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFE012800B1; Thu, 30 Jan 2025 09:31:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D23D2280058 for ; Thu, 30 Jan 2025 09:31:41 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7B3EDA0EDE for ; Thu, 30 Jan 2025 14:31:41 +0000 (UTC) X-FDA: 83064356802.19.57195B8 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf08.hostedemail.com (Postfix) with ESMTP id 4B55816000A for ; Thu, 30 Jan 2025 14:31:37 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="N/jzFBUs"; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf08.hostedemail.com: domain of gregkh@linuxfoundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738247497; a=rsa-sha256; cv=none; b=f/DuMIeQAnDn6c74H1zp4ysxBqC5DAW4HITzm28BFEliDWQBsoclwbLrKw0wVhknk3L3oO H49M6f3XyMBOt3yvIYXEQypggDYiFLtcDUSAtiO/IKdXX/t3E5q3Le967sfu5gBSyIf8qy wm1qZyCjNsO+WEVlbmwyt0l5QY2H5Hc= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="N/jzFBUs"; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf08.hostedemail.com: domain of gregkh@linuxfoundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738247497; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EbAQJ30qkbOysLK1aHxpnLVeLDshN4jHIo+jgFM/BsI=; b=lSwMC6tVpNRzTDs8tZtRKWIFexuyOCPWZWOxid0ZH5CtjUa5E5BAyb1G0JB9pGi+0juCos LHE9aMOFE2CSoFe3Nq5ZtSMs2Uq3SVaNcz02NuRI6fAA9YdPIgvBkqFAxozswb/MLVzGQo QjLirpsOR7NCv9zWtP5DmkaIelNfYOU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 554B4A41C76; Thu, 30 Jan 2025 14:29:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54D45C4CED2; Thu, 30 Jan 2025 14:31:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1738247495; bh=etcyA+MObeejoRPD9H+52sDwKfNZPrVKp5km4MTO7ow=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=N/jzFBUsX9PtQ3HsJNsQXv2HdftgVCkmCXSIztHmRnWMueLBJdZ0iZUt2jhnTcY8H nhNeS9MQWrZHv3BSsR2Ng60LAdlpjqNsXPQlhbq7GE9XkAUviVqLurZXOsyRpT/h1d GFdzeXfthuK4wfgNkG2MmcsNvEszVLGiqLo6mkpo= Date: Thu, 30 Jan 2025 15:24:30 +0100 From: Greg Kroah-Hartman To: Chuck Lever Cc: Hugh Dickins , Andrew Morten , Christian Brauner , Al Viro , Sasha Levin , linux-fsdevel@vger.kernel.org, stable@vger.kernel.org, linux-mm@kvack.org, yukuai3@huawei.com, yangerkun@huawei.com Subject: Re: [RFC PATCH v6.6 00/10] Address CVE-2024-46701 Message-ID: <2025013056-rejoin-number-8641@gregkh> References: <20250124191946.22308-1-cel@kernel.org> <50585d23-a0c1-4810-9e94-09506245f413@oracle.com> <2025012937-unsaddle-movable-4dae@gregkh> <69d8e9dd-59d1-4eb2-be93-1402dba12f34@oracle.com> <2025012924-shelter-disk-2fe1@gregkh> <9130c4f0-ad6b-4b6f-a395-33c7a6b21cbe@oracle.com> <2025013057-lagged-anointer-8b77@gregkh> <0a6b6602-3052-40c7-9727-abe69bd85a06@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a6b6602-3052-40c7-9727-abe69bd85a06@oracle.com> X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4B55816000A X-Stat-Signature: fwhdokf6dbudxksjt57znym8rwmepcuk X-HE-Tag: 1738247497-623109 X-HE-Meta: U2FsdGVkX1/FRiFqaqCP55SjmngNOcnPObtrFsWGu9kzSTBIij9anM5ey2ATjHa6vmX0m2RJjRCwHK9/PdPx96FPHlfcJUfF8SsN6iZeM5avPVWg5YZAL7wjzokfGcrpTdQfSRUYVYY4Yot7PY0S0MQY35DC6hxbzvFsl0FhQP6PNIvxbc75b79WQFztKC5yjc4sWhXyuvP8CyWZ5tIdfxDmpvFao6V9KlnFLhG1vHNft8NkAdICKDQ0kj7rgSfg2uqahFWBP1yZ0cd1svYA/51ZTIdX+L0RDauGFmk/ABo7iz+NXcOTAZMAL5q5PwxXPJ9VDybQqIzDOetLPyVn9Mqf5Gs/LA/zFcujSjjQFfV1z14kQ1xSi2g4CTm+/1/aEL5YwvmyfUUikezfrLeB1pq0boOB753aZdJGSmdPcm+vmx1+XFVZuIVMgWKcCvYKNme81QqjvkC+k50US6V9Z1hOYXZr0rLk8YLSo+g3ui1aVuigQBLYsM8OCA9FA0kv78R9e5fzsnFC6JsK37ik7asfH1PBjPePSWXWhQjbOR8pcDVaxLY8rR5pafwwPNmyk7n/ka5KOikjA5z5dmMNy3U3dIt49Zzt+WEGPxeUsE4lsYhk5P8sTsVA6HGr5W0FhfIgAp1EkgIya2gWJLDJRlN/BU3SIXNELly7gc0WKK2Zeddgu/LceEj8OPgNyOQ7+flCYgLPVylkCEtYqphIIMpIBYVxOVTlt9Z3D6qtyUgLVSL94Kaw9h4lLKhEWBLiq4apoh1xzhizseOYJVpLq8kpyKZVxvPvPxpk70flA/5UdbHVX25fY9WQEDbHofOO0LpprvKGLJ4e1eaxPInxcBjOZdUc0q3u9PJSEZdJhXKkRS3WuplGhReZEQkTkJTqJGKjClIMW/h9fx6bsyvvL8GzgoCAK7Fy9zRc4UR13gbGbtsX0dw6CtL6dHH7XVuDTYiv/cv4o1uYXJI1OWP SB6AGGyl lAozn2WkZeVOkWTpiLDKqePQUPejCwpT9YvY7qjXeTvDwcj5pZx6mAA3NOtKCOc52k8Z3pkvCLdNdoEEBFnK84F5vEs2l9Z832tCmfybZLnvtpuMbaP8E7ykAFlFGSgE5VXEBjPlL044JjE9pIzTFXIq7HOs/mv/Fsqhq9lNP6YeZZx/aRJ2MclNjxNcpNOlNmzDtZF5U45zFFPhDBtlifKyaeF24GE6Wwa6aFvR44XKgTASxxZldjIFtl9AexIraoVxmNseb6gsmQClBHAJhnUhv8ByoDwlcM582km7DvtXltb1YpspXWlHISLGoiQbwgegllirH26+NlRv2rcNu2g+0DSwjgGRTCzna5X1LtV+7EzZLmyxSi6vMGVpIdM6wuonBlqrQfQYXons= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jan 30, 2025 at 09:02:41AM -0500, Chuck Lever wrote: > On 1/30/25 3:45 AM, Greg Kroah-Hartman wrote: > > On Wed, Jan 29, 2025 at 11:37:51AM -0500, Chuck Lever wrote: > >> On 1/29/25 10:21 AM, Greg Kroah-Hartman wrote: > >>> On Wed, Jan 29, 2025 at 10:06:49AM -0500, Chuck Lever wrote: > >>>> On 1/29/25 9:50 AM, Greg Kroah-Hartman wrote: > >>>>> On Wed, Jan 29, 2025 at 08:55:15AM -0500, Chuck Lever wrote: > >>>>>> On 1/24/25 2:19 PM, cel@kernel.org wrote: > >>>>>>> From: Chuck Lever > >>>>>>> > >>>>>>> This series backports several upstream fixes to origin/linux-6.6.y > >>>>>>> in order to address CVE-2024-46701: > >>>>>>> > >>>>>>> https://nvd.nist.gov/vuln/detail/CVE-2024-46701 > >>>>>>> > >>>>>>> As applied to origin/linux-6.6.y, this series passes fstests and the > >>>>>>> git regression suite. > >>>>>>> > >>>>>>> Before officially requesting that stable@ merge this series, I'd > >>>>>>> like to provide an opportunity for community review of the backport > >>>>>>> patches. > >>>>>>> > >>>>>>> You can also find them them in the "nfsd-6.6.y" branch in > >>>>>>> > >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git > >>>>>>> > >>>>>>> Chuck Lever (10): > >>>>>>> libfs: Re-arrange locking in offset_iterate_dir() > >>>>>>> libfs: Define a minimum directory offset > >>>>>>> libfs: Add simple_offset_empty() > >>>>>>> libfs: Fix simple_offset_rename_exchange() > >>>>>>> libfs: Add simple_offset_rename() API > >>>>>>> shmem: Fix shmem_rename2() > >>>>>>> libfs: Return ENOSPC when the directory offset range is exhausted > >>>>>>> Revert "libfs: Add simple_offset_empty()" > >>>>>>> libfs: Replace simple_offset end-of-directory detection > >>>>>>> libfs: Use d_children list to iterate simple_offset directories > >>>>>>> > >>>>>>> fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ > >>>>>>> include/linux/fs.h | 2 + > >>>>>>> mm/shmem.c | 3 +- > >>>>>>> 3 files changed, 134 insertions(+), 48 deletions(-) > >>>>>>> > >>>>>> > >>>>>> I've heard no objections or other comments. Greg, Sasha, shall we > >>>>>> proceed with merging this patch series into v6.6 ? > >>>>> > >>>>> Um, but not all of these are in a released kernel yet, so we can't take > >>>>> them all yet. > >>>> > >>>> Hi Greg - > >>>> > >>>> The new patches are in v6.14 now. I'm asking stable to take these > >>>> whenever you are ready. Would that be v6.14-rc1? I can send a reminder > >>>> if you like. > >>> > >>> Yes, we have to wait until changes are in a -rc release unless there are > >>> "real reasons to take it now" :) > >>> > >>>>> Also what about 6.12.y and 6.13.y for those commits that > >>>>> will be showing up in 6.14-rc1? We can't have regressions for people > >>>>> moving to those releases from 6.6.y, right? > >>>> > >>>> The upstream commits have Fixes tags. I assumed that your automation > >>>> will find those and apply them to those kernels -- the upstream versions > >>>> of these patches I expect will apply cleanly to recent LTS. > >>> > >>> "Fixes:" are never guaranteed to show up in stable kernels, they are > >>> only a "maybe when we get some spare cycles and get around to it we > >>> might do a simple pass to see what works or doesn't." > >>> > >>> If you KNOW a change is a bugfix for stable kernels, please mark it as > >>> such! "Fixes:" is NOT how to do that, and never has been. It's only > >>> additional meta-data that helps us out. > >>> > >>> So please send us a list of the commits that need to go to 6.12.y and > >>> 6.13.y, we have to have that before we could take the 6.6.y changes. > >> > >> 903dc9c43a15 ("libfs: Return ENOSPC when the directory offset range is > >> exhausted") > >> d7bde4f27cee ("Revert "libfs: Add simple_offset_empty()"") > >> b662d858131d ("Revert "libfs: fix infinite directory reads for offset dir"") > >> 68a3a6500314 ("libfs: Replace simple_offset end-of-directory detection") > >> b9b588f22a0c ("libfs: Use d_children list to iterate simple_offset > >> directories") > > > > Cool, thanks for the list (and not all were marked with fixes, i.e. > > those reverts, I guess we need to start checking for reverts better. I > > have tooling set up for that but not integrated yet...) > > > > I'll just queue them all up now. > > My thinking was the patches marked "Fixes:" would show an obvious need > for applying the unmarked patches as pre-requisites first. For when you send us a patch series for inclusion, sure, all is fine. I mean for when you merge stuff to Linus and expect us to pick them up. > I promise to do better marking patches with "Cc: stable". But also let > me know if there's a way to label pre-req patches more clearly. Maybe > "Cc: stable" without "Fixes:" is the way to go there. Both is best, that way if you have a Fixes: tag in it, and a patch does not apply properly, you will get a "FAILED" email sent to you. If you only have the cc: stable then we just do a best-effort attempt and stop backporting when it doesn't apply and don't notify you at all about any failures. thanks, greg k-h