Re: [GIT PULL] liveupdate: a fix for v7.2-rc5

[Pratyush Yadav]

On Wed, Jul 22 2026, Linus Torvalds wrote:

> On Wed, 22 Jul 2026 at 09:25, Mike Rapoport <rppt@xxxxxxxxxx> wrote:
>>
>> * Fix validation of LIVEUPDATE_SESSION_GET_NAME ioctl argument caused by a
>>   wrong resolution of a merge conflict during the last merge window
>
> Hmm. I tried to figure this one out, and there's no "Fixes" tag on this commit.
>
> It would seem to appear that the "merge conflict" wasn't actually a
> merge conflict, it was in fact a bad rebase (which in turn was due to
> a merge conflict in linux-next).
>
> People really should be extra careful about rebases like this. They
> destroy history, and when bugs happen, it's really hard to see *why*
> the bug happened because the actual cause of the bug has disappeared
> and no longer exists after the rebase.
>
> I *think* this commit should have a
>
>    Fixes: 507e3b479f9c ("liveupdate: validate session type before
> performing operation")
>
> but I'm not familiar with this code, so somebody should check that.

Yep, that's the one. The patch for this commit [0] was based on the v7.1
fixes branch, and at that point LIVEUPDATE_SESSION_GET_NAME didn't
exist. LIVEUPDATE_SESSION_GET_NAME went in via v7.2-rc1. So original
patch did the right thing and didn't have this bug.

But the patch was sent around v7.1-rc6 and you complained at the time
about rcs being too big. This bug doesn't cause anything bad, only
warning messages, so we decided to move it to the next branch targeting
v7.2-rc1. The next branch had the new LIVEUPDATE_SESSION_GET_NAME ioctl.
The move from fixes to next caused a conflict, and that conflict was not
fixed correctly.

I did go and read the commit after the rebase to make sure everything
was good, but apparently I am blind and completely missed this.

Unfortunately for this case I don't think there is much we could have
done to avoid the rebasing. When you move a commit from one branch to
another, you have to lose the history.

But in general, I get your point. We are merging our fixes branch into
next instead of rebasing next on top of it, so we would at least not
lose history when something in fixes conflicts with next.

[0] https://lore.kernel.org/all/20260519122428.2378446-1-pratyush@xxxxxxxxxx/

>
> I really would like to see "Fixes" tags in general - but
> *particularly* for something like this because it's marked for stable
> (apparently because the bad rebase was marked for stable).

Yes, it should have the Fixes tag, and I missed that. But this patch
shouldn't go into stable. 507e3b479f9c ("liveupdate: validate session
type before performing operation") needs to go into stable but without
the LIVEUPDATE_SESSION_GET_NAME bits, because that's a new uAPI and has
no business being backported to stable. So the backport, if done right,
should not have this bug.

And Sasha did do the right thing with [1], so I think stable is already
in a good state.

[1] https://lore.kernel.org/stable/20260721004514.3421718-1-sashal@xxxxxxxxxx/

-- 
Regards,
Pratyush Yadav