[linux-next:master] [maple_tree] 540335e987: BUG:kernel_NULL_pointer_dereference,address

[Liam R. Howlett]

* Wei Yang <richard.weiyang at gmail.com> [250619 22:14]:
> On Thu, Jun 19, 2025 at 03:44:46PM -0700, Andrew Morton wrote:
> >On Thu, 19 Jun 2025 15:32:12 +0800 kernel test robot <oliver.sang at intel.com> wrote:
> >
> >> kernel test robot noticed "BUG:kernel_NULL_pointer_dereference,address" on:
> >> 
> >> commit: 540335e9878005bf238ab4e1f91e8df0e3091a03 ("maple_tree: restart walk on correct status")
> >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> >> 
> >> [test failed on linux-next/master 6e5ab6fee68df8c40b338baeae6e269fa25a7e25]
> >> 
> >> ...
> >>
> >> [ 85.008687][ T5293] RIP: 0010:mtree_range_walk (lib/maple_tree.c:2773) 
> >
> >Seems this is
> >
> >		if (pivots[0] >= mas->index) {
> >
> >It seems odd that mtree_range_walk() doesn't (and didn't) check for
> >ma_pivots() returning NULL.
> >
> >Oh well, thanks, the report is solid - I'll drop the series.

This will need to be addressed once the dense nodes arrive, but it
really should not happen right now.

I don't like the idea of checking this every time we walk a node, if it
can be avoided.

> 
> Sorry for the trouble. It is better to drop it.

This indicates another issue exists which was exposed with your fix.

I've tracked it down to the maple status being restored to ma_active
before the maple state node is set.  The bot looks to have hit this by
going mas_prev() on 0 and getting the status to ma_underflow, then
mas_find(), which restored it to ma_active and tried to walk when the
node was NULL in mas_find_setup().

I have a fix for this and I'll roll your change into my fix and add you
as the reporter... and add links to the resend, v3 patches, and this
thread.  Stable will be excluded because it's really not worth the risk
- the code is stable now but just suboptimal.

This still leaves your initial patch 1 and 3, which has nothing to do
with either of these bugs that you included in the patch set.  It is
best to keep patches related to each other together, but not include
things you find while developing those fixes, specifically for this
scenario.

I will grab those patches and re-examine them before sending them along,
again.

Thanks,
Liam