linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hailong Liu <hailong.liu@oppo.com>
To: Suren Baghdasaryan <surenb@google.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	<maple-tree@lists.infradead.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>,
	Zhaoyang Huang <zhaoyang.huang@unisoc.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	"zhangpeng . 00 @ bytedance . com" <zhangpeng.00@bytedance.com>,
	Steve Kang <Steve.Kang@unisoc.com>,
	Matthew Wilcox <willy@infradead.org>,
	Sidhartha Kumar <sidhartha.kumar@oracle.com>
Subject: Re: [RFC PATCH v6.6] maple_tree: Fix MA_STATE_PREALLOC flag in mas_preallocate()
Date: Mon, 19 May 2025 11:24:00 +0800	[thread overview]
Message-ID: <056afddf-a933-493f-96ce-d801c5348059@oppo.com> (raw)
In-Reply-To: <CAJuCfpFXuyg+otnr2uHauGi1-UD2sxxS26ONQNBwuUUisOssQQ@mail.gmail.com>



On 5/9/2025 11:27 PM, Suren Baghdasaryan wrote:
> On Wed, May 7, 2025 at 8:50 AM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>>
>> * Liam R. Howlett <Liam.Howlett@oracle.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@unisoc.com>
>>> Reported-by: Hailong Liu <hailong.liu@oppo.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@oracle.com>
>>> Cc: Suren Baghdasaryan <surenb@google.com>
>>> Cc: Hailong Liu <hailong.liu@oppo.com>
>>> Cc: zhangpeng.00@bytedance.com <zhangpeng.00@bytedance.com>
>>> Cc: Steve Kang <Steve.Kang@unisoc.com>
>>> Cc: Matthew Wilcox <willy@infradead.org>
>>> Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>
>>> Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.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@oppo.com>

Thanks,
Hailong.

> Thanks,
> Suren.
> 
>>
>> Thanks,
>> Liam



  parent reply	other threads:[~2025-05-19  3:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-29  1:47 Liam R. Howlett
2025-04-29  7:48 ` Hailong Liu
2025-04-29 15:52   ` Suren Baghdasaryan
2025-05-07 15:50 ` Liam R. Howlett
2025-05-09 15:27   ` Suren Baghdasaryan
2025-05-09 15:28     ` Suren Baghdasaryan
2025-05-19  3:24     ` Hailong Liu [this message]
2025-05-19 18:24       ` Suren Baghdasaryan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=056afddf-a933-493f-96ce-d801c5348059@oppo.com \
    --to=hailong.liu@oppo.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=Steve.Kang@unisoc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=maple-tree@lists.infradead.org \
    --cc=sidhartha.kumar@oracle.com \
    --cc=surenb@google.com \
    --cc=willy@infradead.org \
    --cc=zhangpeng.00@bytedance.com \
    --cc=zhaoyang.huang@unisoc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox