From: Ye Liu <ye.liu@linux.dev>
To: Lorenzo Stoakes <ljs@kernel.org>, David Hildenbrand <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Ye Liu <liuye@kylinos.cn>, Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Kairui Song <kasong@tencent.com>,
Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Jann Horn <jannh@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: handle potential NULL return from anon_vma_name_reuse()
Date: Tue, 21 Apr 2026 17:25:38 +0800 [thread overview]
Message-ID: <af74eb8c-b45f-475c-aa27-7bf067b9a438@linux.dev> (raw)
In-Reply-To: <aec7p15jvsw7XRHz@lucifer>
在 2026/4/21 17:08, Lorenzo Stoakes 写道:
> NAK, expected allocation failures (even if practically impossible) should not
> cause arbitrary kernel warnings.
Thank you both for the thorough review and explanation.
You are absolutely right. I mistakenly assumed that leaving vma->anon_name
as NULL could lead to a NULL pointer dereference in some path, but as you
pointed out, the code is designed to treat NULL as "no name", which is
perfectly valid.
I also acknowledge that adding a WARN_ON_ONCE in an allocation failure path
is incorrect and harmful under memory pressure.
Please disregard this patch. I've learned a valuable lesson about error
handling in cosmetic features.
Thank you again for the guidance.
--
Thanks,
Ye Liu
prev parent reply other threads:[~2026-04-21 9:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 8:50 [PATCH] mm: handle potential NULL return from anon_vma_name_reuse() Ye Liu
2026-04-21 8:55 ` David Hildenbrand (Arm)
2026-04-21 9:10 ` Lorenzo Stoakes
2026-04-21 9:08 ` Lorenzo Stoakes
2026-04-21 9:25 ` Ye Liu [this message]
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=af74eb8c-b45f-475c-aa27-7bf067b9a438@linux.dev \
--to=ye.liu@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuye@kylinos.cn \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=qi.zheng@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=yuanchu@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.