Re: [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in mmap_region()

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

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.