* Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()
2026-10-30 0:07 [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud() Ritesh Harjani (IBM)
@ 2026-10-30 2:11 ` Zi Yan
2026-10-30 2:21 ` Muchun Song
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: Zi Yan @ 2026-10-30 2:11 UTC (permalink / raw)
To: Ritesh Harjani (IBM)
Cc: linux-mm, Andrew Morton, Madhavan Srinivasan,
Venkat Rao Bagalkote, linux-kernel, linuxppc-dev,
David Hildenbrand, Muchun Song, Baolin Wang, Pavithra
On 29 Oct 2026, at 20:07, Ritesh Harjani (IBM) wrote:
> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
>
> WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
> NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
> LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
> Call Trace:
> zap_huge_pud+0x170/0x2d0 (unreliable)
> __zap_vma_range+0x1604/0x1e20
> unmap_vmas+0xa0/0x1f0
> unmap_region+0xb0/0x130
> vms_complete_munmap_vmas+0x120/0x310
> do_vmi_align_munmap+0x1ec/0x240
> __vm_munmap+0x148/0x220
> sys_munmap+0x28/0x40
>
> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
> byte so that the whole 1G is mapped by a single PUD and then munmap()
> it.
>
> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
> the page size for which tlb flush is needed. zap_huge_pmd(),
> zap_pte_range(), change_huge_pud() etc all do this already. However,
> since commit:
> dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
>
> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
> tlb->page_size is still whatever the previous user left behind, which is
> 0 for the fresh gather set up by munmap() and so the check fires.
>
> Fix this in the same way like how other similar paths do.
>
> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
> Reported-by: Pavithra <pavrampu@linux.ibm.com>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> ---
> [v1]->v2:
> =========
> - Split the 2 part patch series. Patch-1 is now superseded by a different patch
> from Muchun which he already posted [2].
> - No difference in this patch from v1.
>
> [v1]: https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
> [2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
>
> mm/huge_memory.c | 2 ++
> 1 file changed, 2 insertions(+)
>
Makes sense. Thanks.
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()
2026-10-30 0:07 [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud() Ritesh Harjani (IBM)
2026-10-30 2:11 ` Zi Yan
@ 2026-10-30 2:21 ` Muchun Song
2026-10-30 6:46 ` pavrampu
2026-10-30 9:00 ` David Hildenbrand (Arm)
3 siblings, 0 replies; 7+ messages in thread
From: Muchun Song @ 2026-10-30 2:21 UTC (permalink / raw)
To: Ritesh Harjani (IBM)
Cc: linux-mm, Andrew Morton, Madhavan Srinivasan,
Venkat Rao Bagalkote, linux-kernel, linuxppc-dev,
David Hildenbrand, Zi Yan, Baolin Wang, Pavithra
> On Oct 30, 2026, at 08:07, Ritesh Harjani (IBM) <ritesh.list@gmail.com> wrote:
>
> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
>
> WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
> NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
> LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
> Call Trace:
> zap_huge_pud+0x170/0x2d0 (unreliable)
> __zap_vma_range+0x1604/0x1e20
> unmap_vmas+0xa0/0x1f0
> unmap_region+0xb0/0x130
> vms_complete_munmap_vmas+0x120/0x310
> do_vmi_align_munmap+0x1ec/0x240
> __vm_munmap+0x148/0x220
> sys_munmap+0x28/0x40
>
> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
> byte so that the whole 1G is mapped by a single PUD and then munmap()
> it.
>
> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
> the page size for which tlb flush is needed. zap_huge_pmd(),
> zap_pte_range(), change_huge_pud() etc all do this already. However,
> since commit:
> dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
>
> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
> tlb->page_size is still whatever the previous user left behind, which is
> 0 for the fresh gather set up by munmap() and so the check fires.
>
> Fix this in the same way like how other similar paths do.
>
> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
> Reported-by: Pavithra <pavrampu@linux.ibm.com>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Acked-by: Muchun Song <muchun.song@linux.dev>
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()
2026-10-30 0:07 [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud() Ritesh Harjani (IBM)
2026-10-30 2:11 ` Zi Yan
2026-10-30 2:21 ` Muchun Song
@ 2026-10-30 6:46 ` pavrampu
2026-10-30 9:00 ` David Hildenbrand (Arm)
3 siblings, 0 replies; 7+ messages in thread
From: pavrampu @ 2026-10-30 6:46 UTC (permalink / raw)
To: Ritesh Harjani (IBM)
Cc: linux-mm, Andrew Morton, Madhavan Srinivasan,
Venkat Rao Bagalkote, linux-kernel, linuxppc-dev,
David Hildenbrand, Muchun Song, Zi Yan, Baolin Wang
On 2026-10-30 05:37, Ritesh Harjani (IBM) wrote:
> Unmapping a device-dax mapping with 1G alignment on powerpc radix
> kernel
> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
>
> WARNING: mm/mmu_gather.c:176 at
> __tlb_remove_folio_pages_size+0x38/0x230
> NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
> LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
> Call Trace:
> zap_huge_pud+0x170/0x2d0 (unreliable)
> __zap_vma_range+0x1604/0x1e20
> unmap_vmas+0xa0/0x1f0
> unmap_region+0xb0/0x130
> vms_complete_munmap_vmas+0x120/0x310
> do_vmi_align_munmap+0x1ec/0x240
> __vm_munmap+0x148/0x220
> sys_munmap+0x28/0x40
>
> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
> byte so that the whole 1G is mapped by a single PUD and then munmap()
> it.
>
> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
> the page size for which tlb flush is needed. zap_huge_pmd(),
> zap_pte_range(), change_huge_pud() etc all do this already. However,
> since commit:
> dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
>
> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
> tlb->page_size is still whatever the previous user left behind, which
> is
> 0 for the fresh gather set up by munmap() and so the check fires.
>
> Fix this in the same way like how other similar paths do.
>
> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
> Reported-by: Pavithra <pavrampu@linux.ibm.com>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> ---
> [v1]->v2:
> =========
> - Split the 2 part patch series. Patch-1 is now superseded by a
> different patch
> from Muchun which he already posted [2].
> - No difference in this patch from v1.
>
> [v1]:
> https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
> [2]:
> https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
>
> mm/huge_memory.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index bd44d58e8684..7e589a2fb02d 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3040,6 +3040,8 @@ int zap_huge_pud(struct mmu_gather *tlb, struct
> vm_area_struct *vma,
> spinlock_t *ptl;
> pud_t orig_pud;
>
> + tlb_change_page_size(tlb, HPAGE_PUD_SIZE);
> +
> ptl = __pud_trans_huge_lock(pud, vma);
> if (!ptl)
> return 0;
> --
> 2.39.5
Tested on Power10 (ppc64le), kernel v7.3
Tested-by: Pavithra Prakash <pavrampu@linux.ibm.com>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()
2026-10-30 0:07 [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud() Ritesh Harjani (IBM)
` (2 preceding siblings ...)
2026-10-30 6:46 ` pavrampu
@ 2026-10-30 9:00 ` David Hildenbrand (Arm)
2026-10-30 10:15 ` Ritesh Harjani
3 siblings, 1 reply; 7+ messages in thread
From: David Hildenbrand (Arm) @ 2026-10-30 9:00 UTC (permalink / raw)
To: Ritesh Harjani (IBM), linux-mm, Andrew Morton
Cc: Madhavan Srinivasan, Venkat Rao Bagalkote, linux-kernel,
linuxppc-dev, Muchun Song, Zi Yan, Baolin Wang, Pavithra
On 10/30/26 01:07, Ritesh Harjani (IBM) wrote:
> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
>
> WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
> NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
> LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
> Call Trace:
> zap_huge_pud+0x170/0x2d0 (unreliable)
> __zap_vma_range+0x1604/0x1e20
> unmap_vmas+0xa0/0x1f0
> unmap_region+0xb0/0x130
> vms_complete_munmap_vmas+0x120/0x310
> do_vmi_align_munmap+0x1ec/0x240
> __vm_munmap+0x148/0x220
> sys_munmap+0x28/0x40
>
> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
> byte so that the whole 1G is mapped by a single PUD and then munmap()
> it.
>
> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
> the page size for which tlb flush is needed. zap_huge_pmd(),
> zap_pte_range(), change_huge_pud() etc all do this already. However,
> since commit:
> dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
>
> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
> tlb->page_size is still whatever the previous user left behind, which is
> 0 for the fresh gather set up by munmap() and so the check fires.
>
> Fix this in the same way like how other similar paths do.
>
> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
> Reported-by: Pavithra <pavrampu@linux.ibm.com>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> ---
> [v1]->v2:
> =========
> - Split the 2 part patch series. Patch-1 is now superseded by a different patch
> from Muchun which he already posted [2].
> - No difference in this patch from v1.
>
> [v1]: https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
> [2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
>
> mm/huge_memory.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index bd44d58e8684..7e589a2fb02d 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3040,6 +3040,8 @@ int zap_huge_pud(struct mmu_gather *tlb, struct vm_area_struct *vma,
> spinlock_t *ptl;
> pud_t orig_pud;
>
> + tlb_change_page_size(tlb, HPAGE_PUD_SIZE);
> +
> ptl = __pud_trans_huge_lock(pud, vma);
> if (!ptl)
> return 0;
> --
> 2.39.5
>
Matches zap_huge_pmd().
I will wait a bit and then queue this shortly.
This sounds like stable material?
--
Cheers,
David
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()
2026-10-30 9:00 ` David Hildenbrand (Arm)
@ 2026-10-30 10:15 ` Ritesh Harjani
2026-10-30 11:09 ` David Hildenbrand (Arm)
0 siblings, 1 reply; 7+ messages in thread
From: Ritesh Harjani @ 2026-10-30 10:15 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-mm, Andrew Morton
Cc: Madhavan Srinivasan, Venkat Rao Bagalkote, linux-kernel,
linuxppc-dev, Muchun Song, Zi Yan, Baolin Wang, Pavithra
"David Hildenbrand (Arm)" <david@kernel.org> writes:
> On 10/30/26 01:07, Ritesh Harjani (IBM) wrote:
>> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
>> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
>>
>> WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
>> NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
>> LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
>> Call Trace:
>> zap_huge_pud+0x170/0x2d0 (unreliable)
>> __zap_vma_range+0x1604/0x1e20
>> unmap_vmas+0xa0/0x1f0
>> unmap_region+0xb0/0x130
>> vms_complete_munmap_vmas+0x120/0x310
>> do_vmi_align_munmap+0x1ec/0x240
>> __vm_munmap+0x148/0x220
>> sys_munmap+0x28/0x40
>>
>> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
>> byte so that the whole 1G is mapped by a single PUD and then munmap()
>> it.
>>
>> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
>> the page size for which tlb flush is needed. zap_huge_pmd(),
>> zap_pte_range(), change_huge_pud() etc all do this already. However,
>> since commit:
>> dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
>>
>> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
>> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
>> tlb->page_size is still whatever the previous user left behind, which is
>> 0 for the fresh gather set up by munmap() and so the check fires.
>>
>> Fix this in the same way like how other similar paths do.
>>
>> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
>> Reported-by: Pavithra <pavrampu@linux.ibm.com>
>> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> ---
>> [v1]->v2:
>> =========
>> - Split the 2 part patch series. Patch-1 is now superseded by a different patch
>> from Muchun which he already posted [2].
>> - No difference in this patch from v1.
>>
>> [v1]: https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
>> [2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
>>
>> mm/huge_memory.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index bd44d58e8684..7e589a2fb02d 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -3040,6 +3040,8 @@ int zap_huge_pud(struct mmu_gather *tlb, struct vm_area_struct *vma,
>> spinlock_t *ptl;
>> pud_t orig_pud;
>>
>> + tlb_change_page_size(tlb, HPAGE_PUD_SIZE);
>> +
>> ptl = __pud_trans_huge_lock(pud, vma);
>> if (!ptl)
>> return 0;
>> --
>> 2.39.5
>>
>
>
> Matches zap_huge_pmd().
>
> I will wait a bit and then queue this shortly.
>
Thanks David, however, looks like Andrew might have queued this up in
his mm tree [1], right?
[1]: https://lore.kernel.org/all/20261030021905.2DCA71F000C1@smtp.kernel.org/
> This sounds like stable material?
>
Sorry, my bad. Yes, we should have this Cc: stable@vger.kernel.org.
Kindly let me know if I should update the tag and send v3, or can it be
taken care? Thanks!
-ritesh
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()
2026-10-30 10:15 ` Ritesh Harjani
@ 2026-10-30 11:09 ` David Hildenbrand (Arm)
0 siblings, 0 replies; 7+ messages in thread
From: David Hildenbrand (Arm) @ 2026-10-30 11:09 UTC (permalink / raw)
To: Ritesh Harjani (IBM), linux-mm, Andrew Morton
Cc: Madhavan Srinivasan, Venkat Rao Bagalkote, linux-kernel,
linuxppc-dev, Muchun Song, Zi Yan, Baolin Wang, Pavithra
On 10/30/26 11:15, Ritesh Harjani (IBM) wrote:
> "David Hildenbrand (Arm)" <david@kernel.org> writes:
>
>> On 10/30/26 01:07, Ritesh Harjani (IBM) wrote:
>>> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
>>> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
>>>
>>> WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
>>> NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
>>> LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
>>> Call Trace:
>>> zap_huge_pud+0x170/0x2d0 (unreliable)
>>> __zap_vma_range+0x1604/0x1e20
>>> unmap_vmas+0xa0/0x1f0
>>> unmap_region+0xb0/0x130
>>> vms_complete_munmap_vmas+0x120/0x310
>>> do_vmi_align_munmap+0x1ec/0x240
>>> __vm_munmap+0x148/0x220
>>> sys_munmap+0x28/0x40
>>>
>>> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
>>> byte so that the whole 1G is mapped by a single PUD and then munmap()
>>> it.
>>>
>>> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
>>> the page size for which tlb flush is needed. zap_huge_pmd(),
>>> zap_pte_range(), change_huge_pud() etc all do this already. However,
>>> since commit:
>>> dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
>>>
>>> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
>>> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
>>> tlb->page_size is still whatever the previous user left behind, which is
>>> 0 for the fresh gather set up by munmap() and so the check fires.
>>>
>>> Fix this in the same way like how other similar paths do.
>>>
>>> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
>>> Reported-by: Pavithra <pavrampu@linux.ibm.com>
>>> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>>> ---
>>> [v1]->v2:
>>> =========
>>> - Split the 2 part patch series. Patch-1 is now superseded by a different patch
>>> from Muchun which he already posted [2].
>>> - No difference in this patch from v1.
>>>
>>> [v1]: https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
>>> [2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
>>>
>>> mm/huge_memory.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index bd44d58e8684..7e589a2fb02d 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -3040,6 +3040,8 @@ int zap_huge_pud(struct mmu_gather *tlb, struct vm_area_struct *vma,
>>> spinlock_t *ptl;
>>> pud_t orig_pud;
>>>
>>> + tlb_change_page_size(tlb, HPAGE_PUD_SIZE);
>>> +
>>> ptl = __pud_trans_huge_lock(pud, vma);
>>> if (!ptl)
>>> return 0;
>>> --
>>> 2.39.5
>>>
>>
>>
>> Matches zap_huge_pmd().
>>
>> I will wait a bit and then queue this shortly.
>>
>
> Thanks David, however, looks like Andrew might have queued this up in
> his mm tree [1], right?
>
> [1]: https://lore.kernel.org/all/20261030021905.2DCA71F000C1@smtp.kernel.org/
No worries, one of us can drop it before sending it upstream.
I'm about to send out the MAINTAINTERS update in a bit, so right now it's still
confusing.
(but also there is no harm in having it in two trees temporarily)
>
>> This sounds like stable material?
>>
>
> Sorry, my bad. Yes, we should have this Cc: stable@vger.kernel.org.
>
> Kindly let me know if I should update the tag and send v3, or can it be
> taken care? Thanks!
I would just apply that when picking, no need to resend.
Thanks!
--
Cheers,
David
^ permalink raw reply [flat|nested] 7+ messages in thread