[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <056afddf-a933-493f-96ce-d801c5348059@oppo.com>
Date: Mon, 19 May 2025 11:24:00 +0800
From: Hailong Liu <hailong.liu@...o.com>
To: Suren Baghdasaryan <surenb@...gle.com>, "Liam R. Howlett"
<Liam.Howlett@...cle.com>, <maple-tree@...ts.infradead.org>,
<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, Zhaoyang Huang
<zhaoyang.huang@...soc.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
"zhangpeng . 00 @ bytedance . com" <zhangpeng.00@...edance.com>, Steve Kang
<Steve.Kang@...soc.com>, Matthew Wilcox <willy@...radead.org>, Sidhartha
Kumar <sidhartha.kumar@...cle.com>
Subject: Re: [RFC PATCH v6.6] maple_tree: Fix MA_STATE_PREALLOC flag in
mas_preallocate()
On 5/9/2025 11:27 PM, Suren Baghdasaryan wrote:
> On Wed, May 7, 2025 at 8:50 AM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
>>
>> * Liam R. Howlett <Liam.Howlett@...cle.com> [250428 21:48]:
>>> Temporarily clear the preallocation flag when explicitly requesting
>>> allocations. Pre-existing allocations are already counted against the
>>> request through mas_node_count_gfp(), but the allocations will not
>>> happen if the MA_STATE_PREALLOC flag is set. This flag is meant to
>>> avoid re-allocating in bulk allocation mode, and to detect issues with
>>> preallocation calculations.
>>>
>>> The MA_STATE_PREALLOC flag should also always be set on zero allocations
>>> so that detection of underflow allocations will print a WARN_ON() during
>>> consumption.
>>>
>>> User visible effect of this flaw is a WARN_ON() followed by a null
>>> pointer dereference when subsequent requests for larger number of nodes
>>> is ignored, such as the vma merge retry in mmap_region() caused by
>>> drivers altering the vma flags.
>>>
>>> Reported-by: Zhaoyang Huang <zhaoyang.huang@...soc.com>
>>> Reported-by: Hailong Liu <hailong.liu@...o.com>
>>> Fixes: 54a611b605901 ("Maple Tree: add new data structure")
>>> Link: https://lore.kernel.org/all/1652f7eb-a51b-4fee-8058-c73af63bacd1@oppo.com/
>>> Link: https://lore.kernel.org/all/20250428184058.1416274-1-Liam.Howlett@oracle.com/
>>> Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
>>> Cc: Suren Baghdasaryan <surenb@...gle.com>
>>> Cc: Hailong Liu <hailong.liu@...o.com>
>>> Cc: zhangpeng.00@...edance.com <zhangpeng.00@...edance.com>
>>> Cc: Steve Kang <Steve.Kang@...soc.com>
>>> Cc: Matthew Wilcox <willy@...radead.org>
>>> Cc: Sidhartha Kumar <sidhartha.kumar@...cle.com>
>>> Signed-off-by: Liam R. Howlett <Liam.Howlett@...cle.com>
>>
>> ...
>>
>> I have a version of this for mm-new and I'd like to send it out. Once
>> this is upstream, it will be backported to the stable kernels with
>> something that looks a lot like what I sent out here.
>>
>> Did this fix the issue in the longer running tests?
>
> - everyone else
>
> Hi Liam,
> I think the delay is due to the holidays in China. I requested an
> update from the partners but they will probably provide it next week.
Sorry for late reply. We applied this patch and verified it fix the issue.
Feel free to add
Tested-by: Hailong Liu <hailong.liu@...o.com>
Thanks,
Hailong.
> Thanks,
> Suren.
>
>>
>> Thanks,
>> Liam
Powered by blists - more mailing lists