[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ff1c8321-3830-41a3-abe3-6b32a4f72238@lucifer.local>
Date: Tue, 1 Oct 2024 11:33:19 +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 12:22:35PM GMT, Bert Karwatzki wrote:
> 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.
Thanks!
>
> > >
> > > [ 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
Perfect.
OK so what is less perfect is this looks very genuine and present in rc1 so
yeah.
Thanks so much for helping out here - I may ask you to try some patches if
that's ok at some point?
Cheers, Lorenzo
>
> Bert Karwatzki
>
>
Powered by blists - more mailing lists