Re: [PATCH] mapletree-vs-khugepaged

[Liam Howlett <liam.howlett@oracle.com>]

* Sven Schnelle <svens@linux.ibm.com> [220516 13:10]:
> Liam Howlett <liam.howlett@oracle.com> writes:
> 
> > * Sven Schnelle <svens@linux.ibm.com> [220516 11:37]:
> >> Hi Liam,
> >> 
> >> Liam Howlett <liam.howlett@oracle.com> writes:
> >> 
> >> > * Sven Schnelle <svens@linux.ibm.com> [220515 16:02]:
> >> >
> >> > I tried the above on my qemu s390 with kernel 5.18.0-rc6-next-20220513,
> >> > but it runs without issue, return code is 0.  Is there something the VM
> >> > needs to have for this to trigger?
> >> 
> >> A coworker said the same. Reason for this seems to be that i've run the
> >> code in a unittest environment which seems to make a difference. When
> >> compiling the code above with gcc on my system it also doesn't crash.
> >> So i have to figure out what makes this unittest binary special.
> >> 
> >> >> I've added a few debug statements to the maple tree code:
> >> >> 
> >> >> [   27.769641] mas_next_entry: offset=14
> >> >> [   27.769642] mas_next_nentry: entry = 0e00000000000000, slots=0000000090249f80, mas->offset=15 count=14
> >> >
> >> > Where exactly are you printing this?
> >> 
> >> I added a lot of debug statements to the code trying to understand
> >> it. I'll attach it to this mail.
> >
> > Thanks.  Can you check to see if that diff you sent was the correct
> > file?  It appears to be the git stats and not the changes themselves.
> 
> No, it wasn't. I did git stash show with -p, which doesn't make sense.
> I've attached the correct diff.

Thanks for this.  I think the key is that the offset is beyond the end
of the node (count).  What is happening is that we are already at the
last entry in the node and calling next.  I had moved the last entry
from the loop to optimize mas_next_nentry() and set it after.
Unfortunately I did not check for this condition on entry to the
function.  I have a patch I will send out shortly.