linux-kernel - Re: [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in mmap

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: <dac4dd705b0c5084cdc15b3bae4d363bc6448544.camel@web.de>
Date: Tue, 01 Oct 2024 12:22:35 +0200
From: Bert Karwatzki <spasswolf@....de>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>, Andrew Morton	
 <akpm@...ux-foundation.org>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, 	spasswolf@....de
Subject: Re: [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in
 mmap_region()

Am Dienstag, dem 01.10.2024 um 11:02 +0100 schrieb Lorenzo Stoakes:
> On Tue, Oct 01, 2024 at 11:57:02AM GMT, Bert Karwatzki wrote:
> > Am Dienstag, dem 01.10.2024 um 10:49 +0100 schrieb Lorenzo Stoakes:
> > > On Tue, Oct 01, 2024 at 10:20:02AM GMT, Lorenzo Stoakes wrote:
> > > > On Tue, Oct 01, 2024 at 11:10:55AM GMT, Bert Karwatzki wrote:
> > > > > It seems that the maple tree broke down, here's the result of the run with
> > > > > CONFIG_DEBUG_MAPLETREE=y in all it's g(l)ory. (Here I didn't need to try to
> > > > > kill
> > > > > the processes to get an error and soon after the error occured everything
> > > > > stopped working so I had to reboot via powerbutton.)
> > > > >
> > > > > Bert Karwatzki
> > > >
> > > > Yike thanks very much!
> > > >
> > > > If it's at all possible for you to confirm this happens on Linus's tree
> > > > just to be super super sure (again I totally expect this) then that'd be
> > > > amazing.
> > > >
> > > > I ask because we have another thread which bisected a problem to this
> > > > commit which we didn't think was the cause and seemed actually to be the
> > > > result of something else fiddling around with things it shouldn't so just
> > > > want to entirely rule that out (a fix was applied to Linus's tree for
> > > > that).
> > > >
> > > > [snip for snaity]
> > >
> > > OK so looking at the output it looks very much like your report is
> > > unfortunate truncated...
> > >
> > > There is a 'BUG at mas_validate_limits:7523 (1)' report but immediately
> > > prior to this there should be a line containing data formatted to "node%p:
> > > data_end %u != the last slot offset %u".
> >
> > Actually one can just grab the report from /var/log/kern.log after a reboot, I
> > just forgot to copy that line, here it is for the old report:
>
> Well depends on distro etc. I suspect systemd systems probably store too but I
> like to go with the 'easy' or at least straightforward option :P thanks though!
> :)

Distro is debian sid, last updated 20240929.

> >
> > [ T4598] node00000000f48524f2: data_end 9 != the last slot offset 8
> >
> > and here's the error report from next-20241001:
> >
>
> Can you confirm that's definitely the first line in any bug report in dmesg from
> boot? As after the first the tree is likely to get more corrupt and later
> reports are just not going to be that useful.
>
> Could you upload the full dmesg somewhere and give a link? Or send it
> direct to me at lorenzo.stoakes@...cle.com? As pasting whole thing on list
> might cause lore to sick up a bit. Possibly...
>
> Thanks!
>
> [snip]

I used bugzilla.kernel.org as a pastebin, here are both full dmesg logs:
https://bugzilla.kernel.org/show_bug.cgi?id=219338

Bert Karwatzki