Le 22/12/2025 à 11:28, David Hildenbrand (Red Hat) a écrit :

On 12/22/25 06:57, Sourabh Jain wrote:

quoted

On 22/12/25 08:42, Ritesh Harjani (IBM) wrote:

quoted

"David Hildenbrand (Red Hat)" [off-list ref] writes:

quoted

quoted

Coming back to the fixes tag. I did mention a bit of a history [2] of
whatever I could find while reviewing this patch. I am not sure 
whether
you have looked into the links shared in that email or not. Here [2]:

[2]: https://eur01.safelinks.protection.outlook.com/? 
url=https%3A%2F%2Flore.kernel.org%2Flinuxppc- 
dev%2F875xa3ksz9.ritesh.list%40gmail.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cfe40f4881e8441ab3ebf08de4144e747%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639019961377096292%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Dnvzy5kJ%2ByF9GJjIw%2B12FTjaVgeAM2gA9g7hsYl7Qok%3D&reserved=0

Where I am coming from is.. The current patch is acutally a partial
revert of the patch mentioned in the fixes tag. That means if this 
patch
gets applied to the older stable kernels, it would end up bringing the
same problem back, which the "Fixes" tagged patch is fixing in the 1st
place, isnt' it? See this discussion [3]...

[3]: https://eur01.safelinks.protection.outlook.com/? 
url=https%3A%2F%2Flore.kernel.org%2Fall%2Fb1f04f9f-fa46- 
c2a0-7693-4a0679d2a1ee%40oracle.com%2FT%2F%23m0eee87b458d93559426b8b0e78dc6ebcd26ad3ae&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cfe40f4881e8441ab3ebf08de4144e747%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639019961377117150%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bOO7FGN4jAtX3jjBnJVpSurmM9rGmz8vIs1iGtbm1gU%3D&reserved=0

... So, IMO - the right fixes tag, if we have to add, it should be the
patch which moved the hpage_shift initialization to happen early 
i.e. in
mmu_early_init_devtree. That would be this patch [4]:

[4]: https://eur01.safelinks.protection.outlook.com/? 
url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D2354ad252b66695be02f4acd18e37bf6264f0464&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cfe40f4881e8441ab3ebf08de4144e747%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639019961377133860%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0yTuECy%2BBGDLiSNYuqYH9xGBOSxiRLxAtW%2FWTQU%2FB%2BA%3D&reserved=0

Now, it's not really that the patch [4] had any issue as such. But it
seems like, that the current fix can only be applied after patch 
[4] is
taken.

Do we agree?

I think we should document all that in the cover letter, an describe
that this partial revert is only possible after [4],

Yes, I agree. Let's add the above details in the commit msg.

quoted

and that that must
be considered when attempting any kind of stable backports.

Sure. I would prefer if we change the Fixes tag to the one which I
pointed in above [4] (with explaination in the commit msg). However I am
still ok if we would like to retain the existing fixes tag and show [4]
as a dependency.

I think we should keep the current Fixes tag with an explanation for
dependency
on [1] in the commit message.

Would anyone have a different view?

Whatever introduced the issue should be called out in the Fixes tag; if 
there are dependencies for the fix through other patches that were 
already merged, that can be documented in the patch description 
(relevant for stable or distro backports only).

We can also use the Depends-on: tag, see for exemple commit 9517b82d8d42 
("nbd: defer config put in recv_work"):

     Reported-by: syzbot+56fbf4c7ddf65e95c7cc@syzkaller.appspotmail.com
     Closes: 
https://lore.kernel.org/all/6907edce.a70a0220.37351b.0014.GAE@google.com/T/ (local)
     Fixes: 87aac3a80af5 ("nbd: make the config put is called before the 
notifying the waiter")
     Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
     Signed-off-by: Zheng Qixing [off-list ref]
     Signed-off-by: Jens Axboe [off-list ref]


Christophe