* Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> [241106 19:57]: > Hi, > > 在 2024/11/06 23:19, Chuck Lever III 写道: > > > > > > > On Nov 6, 2024, at 1:16 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Thu, Oct 24, 2024 at 09:19:41PM +0800, Yu Kuai wrote: > > > > From: Yu Kuai <yukuai3@xxxxxxxxxx> > > > > > > > > Fix patch is patch 27, relied patches are from: > > > > I assume patch 27 is: > > > > libfs: fix infinite directory reads for offset dir > > > > https://lore.kernel.org/stable/20241024132225.2271667-12-yukuai1@xxxxxxxxxxxxxxx/ > > > > I don't think the Maple tree patches are a hard > > requirement for this fix. And note that libfs did > > not use Maple tree originally because I was told > > at that time that Maple tree was not yet mature. > > > > So, a better approach might be to fit the fix > > onto linux-6.6.y while sticking with xarray. > > The painful part is that using xarray is not acceptable, the offet > is just 32 bit and if it overflows, readdir will read nothing. That's > why maple_tree has to be used. Why does the xarray cause it to overflow vs the maple tree? The maple tree conversion was for performance reasons, as far as I know [1]. Thanks, Liam [1]. https://lore.kernel.org/all/170820083431.6328.16233178852085891453.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > Thanks, > Kuai > > > > > This is the first I've heard of this CVE. It > > would help if the patch authors got some > > notification when these are filed. > > > > > > > > - patches from set [1] to add helpers to maple_tree, the last patch to > > > > improve fork() performance is not backported; > > > > > > So things slowed down? > > > > > > > - patches from set [2] to change maple_tree, and follow up fixes; > > > > - patches from set [3] to convert offset_ctx from xarray to maple_tree; > > > > > > > > Please notice that I'm not an expert in this area, and I'm afraid to > > > > make manual changes. That's why patch 16 revert the commit that is > > > > different from mainline and will cause conflict backporting new patches. > > > > patch 28 pick the original mainline patch again. > > > > > > > > (And this is what we did to fix the CVE in downstream kernels). > > > > > > > > [1] https://lore.kernel.org/all/20231027033845.90608-1-zhangpeng.00@xxxxxxxxxxxxx/ > > > > [2] https://lore.kernel.org/all/20231101171629.3612299-2-Liam.Howlett@xxxxxxxxxx/T/ > > > > [3] https://lore.kernel.org/all/170820083431.6328.16233178852085891453.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > > > > This series looks rough. I want to have the maintainers of these > > > files/subsystems to ack this before being able to take them. > > > > > > thanks, > > > > > > greg k-h > > > > -- > > Chuck Lever > > > > >
