| Message ID | 20250124191946.22308-1-cel@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Address CVE-2024-46701 | expand |
On 1/24/25 2:19 PM, cel@kernel.org wrote: > From: Chuck Lever <chuck.lever@oracle.com> > > 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 ?
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 <chuck.lever@oracle.com> > > > > 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. 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? thanks, greg k-h
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 <chuck.lever@oracle.com> >>> >>> 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. > 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.
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 <chuck.lever@oracle.com> > > > > > > > > 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. thanks, greg k-h
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 <chuck.lever@oracle.com> >>>>> >>>>> 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")
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 <chuck.lever@oracle.com> > > > > > > > > > > > > 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. greg k-h
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 <chuck.lever@oracle.com> >>>>>>> >>>>>>> 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. 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. Thank you, Greg, for your time.
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 <chuck.lever@oracle.com> > >>>>>>> > >>>>>>> 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
From: Chuck Lever <chuck.lever@oracle.com> 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(-)