linux-kernel - Re: [PATCH] mapletree-vs-khugepaged

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220517145222.7onuxvc7ckbmx3e6@revolver>
Date:   Tue, 17 May 2022 14:52:33 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Sven Schnelle <svens@...ux.ibm.com>
CC:     Heiko Carstens <hca@...ux.ibm.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mapletree-vs-khugepaged

* Sven Schnelle <svens@...ux.ibm.com> [220516 13:10]:
> Liam Howlett <liam.howlett@...cle.com> writes:
> 
> > * Sven Schnelle <svens@...ux.ibm.com> [220516 11:37]:
> >> Hi Liam,
> >> 
> >> Liam Howlett <liam.howlett@...cle.com> writes:
> >> 
> >> > * Sven Schnelle <svens@...ux.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.