On Wed, Oct 26, 2022 at 02:32:00PM -0400, Seth Jenkins wrote:
> Hi Greg,
>
> The upstream commit that fixed the issue was not an intentional fix
> AFAIK, but a refactor to switch to maple tree VMA lookups. I was under
> the impression that there were no plans to backport maple trees back
> to stable trees but do let me know if that presumption is incorrect.
Backporting the maple tree to earlier kernels would be a giant upheaval.
I doubt it could ever be justified; certainly the need for this patch
would not be sufficient. Not only would we have to backport the maple
tree data structure itself (which could be justified), but we'd also
have to redo the conversion of the VMAs from rbtree to maple tree.
> Assuming they're not getting backported, what do you think of this
> instead:
> c4c84f06285e on upstream resolves this issue as part of the switch to
> using maple trees for VMA lookups, but a fix must still be applied to
> stable trees 4.19-5.19.
>
> On Wed, Oct 26, 2022 at 12:41 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Wed, Oct 26, 2022 at 12:24:38PM -0400, Seth Jenkins wrote:
> > > Commit 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value
> > > seq_file") introduced a null-deref if there are no vma's in the task in
> > > show_smaps_rollup.
> > >
> > > Fixes: 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value seq_file")
> > > Signed-off-by: Seth Jenkins <sethjenkins@xxxxxxxxxx>
> > > Reviewed-by: Alexey Dobriyan <adobriyan@xxxxxxxxx>
> > > Tested-by: Alexey Dobriyan <adobriyan@xxxxxxxxx>
> > > ---
> > > c4c84f06285e on upstream resolves this issue, but a fix must still be applied to stable trees 4.19-5.19.
> >
> > And you need to document really really really well why we can not take
> > that upstream commit please.
> >
> > Also note that 5.19.y is end-of-life.
> >
> > Please fix up and resend.
> >
> > thanks,
> >
> > greg k-h
