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: <386f485c-5dec-4c7c-81f8-a23aa98a72e7@lucifer.local>
Date: Tue, 1 Oct 2024 10:49:10 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Bert Karwatzki <spasswolf@....de>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in mmap_region()

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".

Could you do something like:

dmesg -w | tee log.txt

Prior to kicking off the repro to make sure we get it all?

Or you could set a cmdline parameter of log_buf_len=1G or something crazy
to make sure dmseg has it all :>)

Thanks! And repeating myself but your help is very much appreciated.