[PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Sourabh Jain]

Skip processing hugepage kernel arguments (hugepagesz, hugepages, and
default_hugepagesz) when hugepages are not supported by the
architecture.

Some architectures may need to disable hugepages based on conditions
discovered during kernel boot. The hugepages_supported() helper allows
architecture code to advertise whether hugepages are supported.

Currently, normal hugepage allocation is guarded by
hugepages_supported(), but gigantic hugepages are allocated regardless
of this check. This causes problems on powerpc for fadump (firmware-
assisted dump).

In the fadump (firmware-assisted dump) scenario, a production kernel
crash causes the system to boot into a special kernel whose sole
purpose is to collect the memory dump and reboot. Features such as
hugepages are not required in this environment and should be
disabled.

For example, when the fadump kernel boots with the following kernel
arguments:
default_hugepagesz=1GB hugepagesz=1GB hugepages=200

Before this patch, the kernel prints the following logs:

HugeTLB: allocating 200 of page size 1.00 GiB failed.  Only allocated 58 hugepages.
HugeTLB support is disabled!
HugeTLB: huge pages not supported, ignoring associated command-line parameters
hugetlbfs: disabling because there are no supported hugepage sizes

Even though the logs state that HugeTLB support is disabled, gigantic
hugepages are still allocated. This causes the fadump kernel to run out
of memory during boot.

After this patch is applied, the kernel prints the following logs for
the same command line:

HugeTLB: hugepages unsupported, ignoring default_hugepagesz=1GB cmdline
HugeTLB: hugepages unsupported, ignoring hugepagesz=1GB cmdline
HugeTLB: hugepages unsupported, ignoring hugepages=200 cmdline
HugeTLB support is disabled!
hugetlbfs: disabling because there are no supported hugepage sizes

To fix the issue, gigantic hugepage allocation should be guarded by
hugepages_supported().

Previously, two approaches were proposed to bring gigantic hugepage
allocation under hugepages_supported():

[1] Check hugepages_supported() in the generic code before allocating
gigantic hugepages
[2] Make arch_hugetlb_valid_size() return false for all hugetlb sizes

Approach [2] has two minor issues:
1. It prints misleading logs about invalid hugepage sizes
2. The kernel still processes hugepage kernel arguments unnecessarily

To control gigantic hugepage allocation, skip processing hugepage kernel
arguments (default_hugepagesz, hugepagesz and hugepages) when
hugepages_supported() returns false.

Link: https://lore.kernel.org/all/20250121150419.1342794-1-sourabhjain@linux.ibm.com/ [1]
Link: https://lore.kernel.org/all/20250128043358.163372-1-sourabhjain@linux.ibm.com/ [2]
Fixes: c2833a5bf75b ("hugetlbfs: fix changes to command line processing")
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: linux-mm@kvack.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: x86@kernel.org
Cc: linux-riscv@lists.infradead.org
Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
Changelog:

v1:
https://lore.kernel.org/all/20250121150419.1342794-1-sourabhjain@linux.ibm.com/

v2:
https://lore.kernel.org/all/20250124103220.111303-1-sourabhjain@linux.ibm.com/
 - disable gigantic hugepage in arch code, arch_hugetlb_valid_size()

v3:
https://lore.kernel.org/all/20250125104928.88881-1-sourabhjain@linux.ibm.com/
 - Do not modify the initialization of the shift variable

v4:
https://lore.kernel.org/all/20250128043358.163372-1-sourabhjain@linux.ibm.com/
 - Update commit message to include how hugepages_supported() detects
   hugepages support when fadump is active
 - Add Reviewed-by tag
 - NO functional change

v5:
https://lore.kernel.org/all/20251218114154.228484-1-sourabhjain@linux.ibm.com/
 - Significant change in approach: disable processing of hugepage kernel
   arguments if hugepages_supported() returns false
 - Drop a Reviewed-by tag

v6:
 - Updated commit message with additional logs and tags
 - No functional changes
---
 mm/hugetlb.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 51273baec9e5..e0ab14020513 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4286,6 +4286,11 @@ static int __init hugepages_setup(char *s)
 	unsigned long tmp;
 	char *p = s;
 
+	if (!hugepages_supported()) {
+		pr_warn("HugeTLB: hugepages unsupported, ignoring hugepages=%s cmdline\n", s);
+		return 0;
+	}
+
 	if (!parsed_valid_hugepagesz) {
 		pr_warn("HugeTLB: hugepages=%s does not follow a valid hugepagesz, ignoring\n", s);
 		parsed_valid_hugepagesz = true;
@@ -4366,6 +4371,11 @@ static int __init hugepagesz_setup(char *s)
 	unsigned long size;
 	struct hstate *h;
 
+	if (!hugepages_supported()) {
+		pr_warn("HugeTLB: hugepages unsupported, ignoring hugepagesz=%s cmdline\n", s);
+		return 0;
+	}
+
 	parsed_valid_hugepagesz = false;
 	size = (unsigned long)memparse(s, NULL);
 
@@ -4414,6 +4424,12 @@ static int __init default_hugepagesz_setup(char *s)
 	unsigned long size;
 	int i;
 
+	if (!hugepages_supported()) {
+		pr_warn("HugeTLB: hugepages unsupported, ignoring default_hugepagesz=%s cmdline\n",
+			s);
+		return 0;
+	}
+
 	parsed_valid_hugepagesz = false;
 	if (parsed_default_hugepagesz) {
 		pr_err("HugeTLB: default_hugepagesz previously specified, ignoring %s\n", s);
-- 
2.51.1

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Ritesh Harjani]

Hi Sourabh,

Sourabh Jain <sourabhjain@linux.ibm.com> writes:

> Skip processing hugepage kernel arguments (hugepagesz, hugepages, and
> default_hugepagesz) when hugepages are not supported by the
> architecture.
>
> Some architectures may need to disable hugepages based on conditions
> discovered during kernel boot. The hugepages_supported() helper allows
> architecture code to advertise whether hugepages are supported.
>
> Currently, normal hugepage allocation is guarded by
> hugepages_supported(), but gigantic hugepages are allocated regardless
> of this check. This causes problems on powerpc for fadump (firmware-
> assisted dump).
>
> In the fadump (firmware-assisted dump) scenario, a production kernel
> crash causes the system to boot into a special kernel whose sole
> purpose is to collect the memory dump and reboot. Features such as
> hugepages are not required in this environment and should be
> disabled.
>
> For example, when the fadump kernel boots with the following kernel
> arguments:
> default_hugepagesz=1GB hugepagesz=1GB hugepages=200
>
> Before this patch, the kernel prints the following logs:
>
> HugeTLB: allocating 200 of page size 1.00 GiB failed.  Only allocated 58 hugepages.
> HugeTLB support is disabled!
> HugeTLB: huge pages not supported, ignoring associated command-line parameters
> hugetlbfs: disabling because there are no supported hugepage sizes
>
> Even though the logs state that HugeTLB support is disabled, gigantic
> hugepages are still allocated. This causes the fadump kernel to run out
> of memory during boot.
>
> After this patch is applied, the kernel prints the following logs for
> the same command line:
>
> HugeTLB: hugepages unsupported, ignoring default_hugepagesz=1GB cmdline
> HugeTLB: hugepages unsupported, ignoring hugepagesz=1GB cmdline
> HugeTLB: hugepages unsupported, ignoring hugepages=200 cmdline
> HugeTLB support is disabled!
> hugetlbfs: disabling because there are no supported hugepage sizes
>
> To fix the issue, gigantic hugepage allocation should be guarded by
> hugepages_supported().
>
> Previously, two approaches were proposed to bring gigantic hugepage
> allocation under hugepages_supported():
>
> [1] Check hugepages_supported() in the generic code before allocating
> gigantic hugepages
> [2] Make arch_hugetlb_valid_size() return false for all hugetlb sizes
>
> Approach [2] has two minor issues:
> 1. It prints misleading logs about invalid hugepage sizes
> 2. The kernel still processes hugepage kernel arguments unnecessarily
>
> To control gigantic hugepage allocation, skip processing hugepage kernel
> arguments (default_hugepagesz, hugepagesz and hugepages) when
> hugepages_supported() returns false.
>
> Link: https://lore.kernel.org/all/20250121150419.1342794-1-sourabhjain@linux.ibm.com/ [1]
> Link: https://lore.kernel.org/all/20250128043358.163372-1-sourabhjain@linux.ibm.com/ [2]
> Fixes: c2833a5bf75b ("hugetlbfs: fix changes to command line processing")


I appreciate our proactiveness to respond quickly on mailing list, but I
suggest we give enough time to folks before sending the next version
please ;).

Your email from last night [1] says that we will use this fixes tag but
you haven't even given us 24hrs to respond to that email thread :). Now
we've sent this v6, with Acked-by of David and Reviewed-by of mine,
which seems like everything was agreed upon, but that isn't the case
actually.

My main concern was - 
A fixes tag means it might get auto backported to stable kernels too,
which means if the fixes tag is incorrect it could even break stable
kernels then. 

[1]: https://lore.kernel.org/linuxppc-dev/041352df-41ce-4898-8535-d6b7fd74a52b@linux.ibm.com/T/#m6e16738c03b2b2a8d09717f6291e46207033507a


Anyways,
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://lore.kernel.org/linuxppc-dev/875xa3ksz9.ritesh.list@gmail.com/

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://lore.kernel.org/all/b1f04f9f-fa46-c2a0-7693-4a0679d2a1ee@oracle.com/T/#m0eee87b458d93559426b8b0e78dc6ebcd26ad3ae

... 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2354ad252b66695be02f4acd18e37bf6264f0464

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? 

<...>
> Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
> Changelog:
>
<...>
> v6:
>  - Updated commit message with additional logs and tags
>  - No functional changes
> ---
>  mm/hugetlb.c | 16 ++++++++++++++++
>  1

-ritesh

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[David Hildenbrand (Red Hat)]

On 12/21/25 06:59, Ritesh Harjani (IBM) wrote:
> Hi Sourabh,
> 
> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
> 
>> Skip processing hugepage kernel arguments (hugepagesz, hugepages, and
>> default_hugepagesz) when hugepages are not supported by the
>> architecture.
>>
>> Some architectures may need to disable hugepages based on conditions
>> discovered during kernel boot. The hugepages_supported() helper allows
>> architecture code to advertise whether hugepages are supported.
>>
>> Currently, normal hugepage allocation is guarded by
>> hugepages_supported(), but gigantic hugepages are allocated regardless
>> of this check. This causes problems on powerpc for fadump (firmware-
>> assisted dump).
>>
>> In the fadump (firmware-assisted dump) scenario, a production kernel
>> crash causes the system to boot into a special kernel whose sole
>> purpose is to collect the memory dump and reboot. Features such as
>> hugepages are not required in this environment and should be
>> disabled.
>>
>> For example, when the fadump kernel boots with the following kernel
>> arguments:
>> default_hugepagesz=1GB hugepagesz=1GB hugepages=200
>>
>> Before this patch, the kernel prints the following logs:
>>
>> HugeTLB: allocating 200 of page size 1.00 GiB failed.  Only allocated 58 hugepages.
>> HugeTLB support is disabled!
>> HugeTLB: huge pages not supported, ignoring associated command-line parameters
>> hugetlbfs: disabling because there are no supported hugepage sizes
>>
>> Even though the logs state that HugeTLB support is disabled, gigantic
>> hugepages are still allocated. This causes the fadump kernel to run out
>> of memory during boot.
>>
>> After this patch is applied, the kernel prints the following logs for
>> the same command line:
>>
>> HugeTLB: hugepages unsupported, ignoring default_hugepagesz=1GB cmdline
>> HugeTLB: hugepages unsupported, ignoring hugepagesz=1GB cmdline
>> HugeTLB: hugepages unsupported, ignoring hugepages=200 cmdline
>> HugeTLB support is disabled!
>> hugetlbfs: disabling because there are no supported hugepage sizes
>>
>> To fix the issue, gigantic hugepage allocation should be guarded by
>> hugepages_supported().
>>
>> Previously, two approaches were proposed to bring gigantic hugepage
>> allocation under hugepages_supported():
>>
>> [1] Check hugepages_supported() in the generic code before allocating
>> gigantic hugepages
>> [2] Make arch_hugetlb_valid_size() return false for all hugetlb sizes
>>
>> Approach [2] has two minor issues:
>> 1. It prints misleading logs about invalid hugepage sizes
>> 2. The kernel still processes hugepage kernel arguments unnecessarily
>>
>> To control gigantic hugepage allocation, skip processing hugepage kernel
>> arguments (default_hugepagesz, hugepagesz and hugepages) when
>> hugepages_supported() returns false.
>>
>> Link: https://lore.kernel.org/all/20250121150419.1342794-1-sourabhjain@linux.ibm.com/ [1]
>> Link: https://lore.kernel.org/all/20250128043358.163372-1-sourabhjain@linux.ibm.com/ [2]
>> Fixes: c2833a5bf75b ("hugetlbfs: fix changes to command line processing")
> 
> 
> I appreciate our proactiveness to respond quickly on mailing list, but I
> suggest we give enough time to folks before sending the next version
> please ;).
> 
> Your email from last night [1] says that we will use this fixes tag but
> you haven't even given us 24hrs to respond to that email thread :). Now
> we've sent this v6, with Acked-by of David and Reviewed-by of mine,
> which seems like everything was agreed upon, but that isn't the case
> actually.

Agreed.

> 
> My main concern was -
> A fixes tag means it might get auto backported to stable kernels too,

Not in the MM world -- IIRC. I think there is the agreement, that we 
decide what should go into stable and what not.

Andrew can correct me if my memory is wrong.

But we can always jump in and say that something should not go to stable 
trees.

> which means if the fixes tag is incorrect it could even break stable
> kernels then.
> 
> [1]: https://lore.kernel.org/linuxppc-dev/041352df-41ce-4898-8535-d6b7fd74a52b@linux.ibm.com/T/#m6e16738c03b2b2a8d09717f6291e46207033507a
> 
> 
> Anyways,
> 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://lore.kernel.org/linuxppc-dev/875xa3ksz9.ritesh.list@gmail.com/
> 
> 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://lore.kernel.org/all/b1f04f9f-fa46-c2a0-7693-4a0679d2a1ee@oracle.com/T/#m0eee87b458d93559426b8b0e78dc6ebcd26ad3ae
> 
> ... 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2354ad252b66695be02f4acd18e37bf6264f0464
> 
> 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], and that that must 
be considered when attempting any kind of stable backports.

Thanks for pointing all that out.

-- 
Cheers

David

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Andrew Morton]

On Sun, 21 Dec 2025 10:22:44 +0100 "David Hildenbrand (Red Hat)" <david@kernel.org> wrote:

> > 
> > My main concern was -
> > A fixes tag means it might get auto backported to stable kernels too,
> 
> Not in the MM world -- IIRC. I think there is the agreement, that we 
> decide what should go into stable and what not.
> 
> Andrew can correct me if my memory is wrong.

Yes, -stable maintainers have been asked to only backport patches where
the MM developers asked for that, with cc:stable.  There may be
slipups, but as far as I know this is working.

I don't actually know how they determine which patches need this
special treatment.  Pathname?  Signed-off-by:akpm?

> But we can always jump in and say that something should not go to stable 
> trees.

Yes, please jump in if there are any thoughts about
ordering/priority/timing.  In fact, please jump in if there are any
thoughts at all ;)

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Ritesh Harjani]

"David Hildenbrand (Red Hat)" <david@kernel.org> 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://lore.kernel.org/linuxppc-dev/875xa3ksz9.ritesh.list@gmail.com/
>> 
>> 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://lore.kernel.org/all/b1f04f9f-fa46-c2a0-7693-4a0679d2a1ee@oracle.com/T/#m0eee87b458d93559426b8b0e78dc6ebcd26ad3ae
>> 
>> ... 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2354ad252b66695be02f4acd18e37bf6264f0464
>> 
>> 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.


-ritesh

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Sourabh Jain]

On 21/12/25 11:29, Ritesh Harjani (IBM) wrote:
> Hi Sourabh,
>
> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
>> Skip processing hugepage kernel arguments (hugepagesz, hugepages, and
>> default_hugepagesz) when hugepages are not supported by the
>> architecture.
>>
>> Some architectures may need to disable hugepages based on conditions
>> discovered during kernel boot. The hugepages_supported() helper allows
>> architecture code to advertise whether hugepages are supported.
>>
>> Currently, normal hugepage allocation is guarded by
>> hugepages_supported(), but gigantic hugepages are allocated regardless
>> of this check. This causes problems on powerpc for fadump (firmware-
>> assisted dump).
>>
>> In the fadump (firmware-assisted dump) scenario, a production kernel
>> crash causes the system to boot into a special kernel whose sole
>> purpose is to collect the memory dump and reboot. Features such as
>> hugepages are not required in this environment and should be
>> disabled.
>>
>> For example, when the fadump kernel boots with the following kernel
>> arguments:
>> default_hugepagesz=1GB hugepagesz=1GB hugepages=200
>>
>> Before this patch, the kernel prints the following logs:
>>
>> HugeTLB: allocating 200 of page size 1.00 GiB failed.  Only allocated 58 hugepages.
>> HugeTLB support is disabled!
>> HugeTLB: huge pages not supported, ignoring associated command-line parameters
>> hugetlbfs: disabling because there are no supported hugepage sizes
>>
>> Even though the logs state that HugeTLB support is disabled, gigantic
>> hugepages are still allocated. This causes the fadump kernel to run out
>> of memory during boot.
>>
>> After this patch is applied, the kernel prints the following logs for
>> the same command line:
>>
>> HugeTLB: hugepages unsupported, ignoring default_hugepagesz=1GB cmdline
>> HugeTLB: hugepages unsupported, ignoring hugepagesz=1GB cmdline
>> HugeTLB: hugepages unsupported, ignoring hugepages=200 cmdline
>> HugeTLB support is disabled!
>> hugetlbfs: disabling because there are no supported hugepage sizes
>>
>> To fix the issue, gigantic hugepage allocation should be guarded by
>> hugepages_supported().
>>
>> Previously, two approaches were proposed to bring gigantic hugepage
>> allocation under hugepages_supported():
>>
>> [1] Check hugepages_supported() in the generic code before allocating
>> gigantic hugepages
>> [2] Make arch_hugetlb_valid_size() return false for all hugetlb sizes
>>
>> Approach [2] has two minor issues:
>> 1. It prints misleading logs about invalid hugepage sizes
>> 2. The kernel still processes hugepage kernel arguments unnecessarily
>>
>> To control gigantic hugepage allocation, skip processing hugepage kernel
>> arguments (default_hugepagesz, hugepagesz and hugepages) when
>> hugepages_supported() returns false.
>>
>> Link: https://lore.kernel.org/all/20250121150419.1342794-1-sourabhjain@linux.ibm.com/ [1]
>> Link: https://lore.kernel.org/all/20250128043358.163372-1-sourabhjain@linux.ibm.com/ [2]
>> Fixes: c2833a5bf75b ("hugetlbfs: fix changes to command line processing")
>
> I appreciate our proactiveness to respond quickly on mailing list, but I
> suggest we give enough time to folks before sending the next version
> please ;).

I agree that I posted the v6 too quickly. I will avoid that in future.

>
> Your email from last night [1] says that we will use this fixes tag but
> you haven't even given us 24hrs to respond to that email thread :). Now
> we've sent this v6, with Acked-by of David and Reviewed-by of mine,
> which seems like everything was agreed upon, but that isn't the case
> actually.

Yes, you are right. I should have waited until the discussion about the
Fixes tag was finished.

Thanks for pointing out things Ritesh.

- Sourabh Jain

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Sourabh Jain]

On 22/12/25 08:42, Ritesh Harjani (IBM) wrote:
> "David Hildenbrand (Red Hat)" <david@kernel.org> 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://lore.kernel.org/linuxppc-dev/875xa3ksz9.ritesh.list@gmail.com/
>>>
>>> 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://lore.kernel.org/all/b1f04f9f-fa46-c2a0-7693-4a0679d2a1ee@oracle.com/T/#m0eee87b458d93559426b8b0e78dc6ebcd26ad3ae
>>>
>>> ... 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2354ad252b66695be02f4acd18e37bf6264f0464
>>>
>>> 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?

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2354ad252b66695be02f4acd18e37bf6264f0464

- Sourabh Jain

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[David Hildenbrand (Red Hat)]

On 12/22/25 06:57, Sourabh Jain wrote:
> 
> 
> On 22/12/25 08:42, Ritesh Harjani (IBM) wrote:
>> "David Hildenbrand (Red Hat)" <david@kernel.org> 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://lore.kernel.org/linuxppc-dev/875xa3ksz9.ritesh.list@gmail.com/
>>>>
>>>> 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://lore.kernel.org/all/b1f04f9f-fa46-c2a0-7693-4a0679d2a1ee@oracle.com/T/#m0eee87b458d93559426b8b0e78dc6ebcd26ad3ae
>>>>
>>>> ... 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2354ad252b66695be02f4acd18e37bf6264f0464
>>>>
>>>> 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).

-- 
Cheers

David

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Christophe Leroy (CS GROUP)]

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)" <david@kernel.org> 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: syzbot+56fbf4c7ddf65e95c7cc@syzkaller.appspotmail.com
     Closes: 
https://lore.kernel.org/all/6907edce.a70a0220.37351b.0014.GAE@google.com/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 <zhengqixing@huawei.com>
     Signed-off-by: Jens Axboe <axboe@kernel.dk>


Christophe

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[SeongJae Park]

On Sun, 21 Dec 2025 10:49:07 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Sun, 21 Dec 2025 10:22:44 +0100 "David Hildenbrand (Red Hat)" <david@kernel.org> wrote:
> 
> > > 
> > > My main concern was -
> > > A fixes tag means it might get auto backported to stable kernels too,
> > 
> > Not in the MM world -- IIRC. I think there is the agreement, that we 
> > decide what should go into stable and what not.
> > 
> > Andrew can correct me if my memory is wrong.
> 
> Yes, -stable maintainers have been asked to only backport patches where
> the MM developers asked for that, with cc:stable.  There may be
> slipups, but as far as I know this is working.
> 
> I don't actually know how they determine which patches need this
> special treatment.  Pathname?  Signed-off-by:akpm?

I guess it is pathname, based on ignore_list file [1] of stable-queue repo.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list#n16


Thanks,
SJ

[...]

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Andrew Morton]

On Mon, 22 Dec 2025 17:30:44 -0800 SeongJae Park <sj@kernel.org> wrote:

> On Sun, 21 Dec 2025 10:49:07 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Sun, 21 Dec 2025 10:22:44 +0100 "David Hildenbrand (Red Hat)" <david@kernel.org> wrote:
> > 
> > > > 
> > > > My main concern was -
> > > > A fixes tag means it might get auto backported to stable kernels too,
> > > 
> > > Not in the MM world -- IIRC. I think there is the agreement, that we 
> > > decide what should go into stable and what not.
> > > 
> > > Andrew can correct me if my memory is wrong.
> > 
> > Yes, -stable maintainers have been asked to only backport patches where
> > the MM developers asked for that, with cc:stable.  There may be
> > slipups, but as far as I know this is working.
> > 
> > I don't actually know how they determine which patches need this
> > special treatment.  Pathname?  Signed-off-by:akpm?
> 
> I guess it is pathname, based on ignore_list file [1] of stable-queue repo.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list#n16
> 

Oh, that's a bit sad.

- other trees sometimes mess with mm/ and they probably aren't aware
  that they need an explicit cc:stable.

- misses drivers/block/zram and probably various other things that
  the MM team maintains.

Oh well, I guess simple mm/* coverage is good enough.  But I do worry a
little that useful fixes coming into mm/ via other trees without
cc:stable will get missed.

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Sourabh Jain]

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)" <david@kernel.org> 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: syzbot+56fbf4c7ddf65e95c7cc@syzkaller.appspotmail.com
>     Closes: 
> https://lore.kernel.org/all/6907edce.a70a0220.37351b.0014.GAE@google.com/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 <zhengqixing@huawei.com>
>     Signed-off-by: Jens Axboe <axboe@kernel.dk>

Thanks for the suggestion Christophe. I will use Depends-on tag.

- Sourabh Jain

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Sasha Levin]

On Mon, Dec 22, 2025 at 06:30:55PM -0800, Andrew Morton wrote:
>On Mon, 22 Dec 2025 17:30:44 -0800 SeongJae Park <sj@kernel.org> wrote:
>
>> On Sun, 21 Dec 2025 10:49:07 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> > On Sun, 21 Dec 2025 10:22:44 +0100 "David Hildenbrand (Red Hat)" <david@kernel.org> wrote:
>> >
>> > > >
>> > > > My main concern was -
>> > > > A fixes tag means it might get auto backported to stable kernels too,
>> > >
>> > > Not in the MM world -- IIRC. I think there is the agreement, that we
>> > > decide what should go into stable and what not.
>> > >
>> > > Andrew can correct me if my memory is wrong.
>> >
>> > Yes, -stable maintainers have been asked to only backport patches where
>> > the MM developers asked for that, with cc:stable.  There may be
>> > slipups, but as far as I know this is working.
>> >
>> > I don't actually know how they determine which patches need this
>> > special treatment.  Pathname?  Signed-off-by:akpm?
>>
>> I guess it is pathname, based on ignore_list file [1] of stable-queue repo.
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list#n16
>>
>
>Oh, that's a bit sad.
>
>- other trees sometimes mess with mm/ and they probably aren't aware
>  that they need an explicit cc:stable.
>
>- misses drivers/block/zram and probably various other things that
>  the MM team maintains.
>
>Oh well, I guess simple mm/* coverage is good enough.  But I do worry a
>little that useful fixes coming into mm/ via other trees without
>cc:stable will get missed.

How should we improve the filter? mm/ AND signed off by akpm?

-- 
Thanks,
Sasha

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Andrew Morton]

On Tue, 23 Dec 2025 06:43:45 -0500 Sasha Levin <sashal@kernel.org> wrote:

> >> > Yes, -stable maintainers have been asked to only backport patches where
> >> > the MM developers asked for that, with cc:stable.  There may be
> >> > slipups, but as far as I know this is working.
> >> >
> >> > I don't actually know how they determine which patches need this
> >> > special treatment.  Pathname?  Signed-off-by:akpm?
> >>
> >> I guess it is pathname, based on ignore_list file [1] of stable-queue repo.
> >>
> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list#n16
> >>
> >
> >Oh, that's a bit sad.
> >
> >- other trees sometimes mess with mm/ and they probably aren't aware
> >  that they need an explicit cc:stable.
> >
> >- misses drivers/block/zram and probably various other things that
> >  the MM team maintains.
> >
> >Oh well, I guess simple mm/* coverage is good enough.  But I do worry a
> >little that useful fixes coming into mm/ via other trees without
> >cc:stable will get missed.
> 
> How should we improve the filter? mm/ AND signed off by akpm?

I think just signed-off-by:akpm please.  That way, mm fixes which come
in via other trees without cc:stable get backported.

Obviously we'd prefer that such patches get appropriate consideration
by the MM developers but sometimes other-tree people aren't that
cooperative.  In this case it's better to backport the thing rather
than missing a fix?

Re: [PATCH v6] mm/hugetlb: ignore hugepage kernel args if hugepages are unsupported

[Sasha Levin]

On Tue, Dec 23, 2025 at 08:54:34AM -0800, Andrew Morton wrote:
>On Tue, 23 Dec 2025 06:43:45 -0500 Sasha Levin <sashal@kernel.org> wrote:
>
>> >> > Yes, -stable maintainers have been asked to only backport patches where
>> >> > the MM developers asked for that, with cc:stable.  There may be
>> >> > slipups, but as far as I know this is working.
>> >> >
>> >> > I don't actually know how they determine which patches need this
>> >> > special treatment.  Pathname?  Signed-off-by:akpm?
>> >>
>> >> I guess it is pathname, based on ignore_list file [1] of stable-queue repo.
>> >>
>> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list#n16
>> >>
>> >
>> >Oh, that's a bit sad.
>> >
>> >- other trees sometimes mess with mm/ and they probably aren't aware
>> >  that they need an explicit cc:stable.
>> >
>> >- misses drivers/block/zram and probably various other things that
>> >  the MM team maintains.
>> >
>> >Oh well, I guess simple mm/* coverage is good enough.  But I do worry a
>> >little that useful fixes coming into mm/ via other trees without
>> >cc:stable will get missed.
>>
>> How should we improve the filter? mm/ AND signed off by akpm?
>
>I think just signed-off-by:akpm please.  That way, mm fixes which come
>in via other trees without cc:stable get backported.

Ack

>Obviously we'd prefer that such patches get appropriate consideration
>by the MM developers but sometimes other-tree people aren't that
>cooperative.  In this case it's better to backport the thing rather
>than missing a fix?

I tend to err on the side of taking one extra thing rather than missing
something :)

Would you be interested in trying out AUTOSEL for mm/ again? In the current
workflow I give about 2-3 weeks for review, and all it takes to have a patch
dropped is to just reply with a "no".

I can generate a series with mm/ patches from v6.18..v6.19-rc2 that don't have
a Fixes/stable tag but the LLM thinks that it should be backported as a way for
you and other mm/ folk to gauge the current state of AUTOSEL, if that helps?

-- 
Thanks,
Sasha