On 22/12/25 16:24, Christophe Leroy (CS GROUP) wrote:
Le 22/12/2025 à 11:28, David Hildenbrand (Red Hat) a écrit :
On 12/22/25 06:57, Sourabh Jain wrote:
On 22/12/25 08:42, Ritesh Harjani (IBM) wrote:
"David Hildenbrand (Red Hat)" <[email protected]> writes:
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.
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: [email protected]
Closes:
https://lore.kernel.org/all/[email protected]/T/
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 <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Thanks for the suggestion Christophe. I will use Depends-on tag.
- Sourabh Jain
