[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b90c9e30-362a-4448-b4c7-6b57627f1c9e@lucifer.local>
Date: Mon, 24 Nov 2025 10:43:41 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Aleksandr Nogikh <nogikh@...gle.com>
Cc: syzbot <syzbot+3e03c904429660114599@...kaller.appspotmail.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [mm?] WARNING in vma_modify (2)
On Mon, Nov 24, 2025 at 11:25:14AM +0100, Aleksandr Nogikh wrote:
> Hi Lorenzo,
>
> Thanks for taking a closer look!
>
> On Mon, Nov 24, 2025 at 10:53 AM 'Lorenzo Stoakes' via syzkaller-bugs
> <syzkaller-bugs@...glegroups.com> wrote:
> >
> > On Sat, Nov 22, 2025 at 09:30:29PM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> >
> > Hi, thanks for the report!
> >
> > >
> > > HEAD commit: fe4d0dea039f Add linux-next specific files for 20251119
> >
> > Hm this is quite far behind!
> >
> > This is a known issue that has already been fixed in linux-next.
>
> Could you please point to the patch series that introduced the original issue?
It's two versions of the same:
A fix-patch sent for v3 introduced it on Mon 17th Nov -
https://lore.kernel.org/all/13ae542f-5c47-4511-b0ad-6d1e9dcbdc9d@lucifer.local/
v4 fixed it on Tues 18th Nov -
https://lore.kernel.org/all/cover.1763460113.git.lorenzo.stoakes@oracle.com/
Unfortunately it seemed the former got sent to -next quicker than the latter
did.
So next-20251119 introduced the bug, next-20251120 fixes it.
It's all rebased so there's no meaningful commit to mention etc.
> I'd love to debug why https://ci.syzbot.org/ missed it.
It's not that it missed it I guess, it just worked through a backlog. But I'd
say it's not really useful at all to do so for prior versions of -next? You
should always do everything against the latest, since -next _always_ rebases
like this.
It's useful to look at older commits for Linus's tree, as we don't want bugs to
exist at any commit there. For -next it's not really helpful.
>
> >
> > It'll all be rebased so no syz command is going to be too useful here I think!
>
> Yes, we can only close it as invalid so that the report doesn't stay open:
> #syz invalid
Ah wasn't aware of that one. Maybe worth putting in footer?
>
> --
> Aleksandr
Cheers, Lorenzo
Powered by blists - more mailing lists