From: Joshua Hahn <joshua.hahnjy@gmail.com>
To: Ingyu Jang <ingyujang25@korea.ac.kr>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, david@kernel.org
Subject: Re: [Question] Dead code in copy_pud_range() for copy_huge_pud() error check?
Date: Mon, 2 Feb 2026 07:28:38 -0800 [thread overview]
Message-ID: <20260202152839.221116-1-joshua.hahnjy@gmail.com> (raw)
In-Reply-To: <20260131172854.3370590-1-ingyujang25@korea.ac.kr>
On Sun, 1 Feb 2026 02:28:54 +0900 Ingyu Jang <ingyujang25@korea.ac.kr> wrote:
Hello Ingyu,
I hope you are doing well!
I'm by no means an expert in this area, but thought I would reply with
what I found in the commit log.
> Hi,
>
> I noticed that in mm/memory.c, the function copy_pud_range() checks
> if copy_huge_pud() returns -ENOMEM (at line 1421):
>
> err = copy_huge_pud(dst_mm, src_mm,
> dst_pud, src_pud, addr, src_vma);
> if (err == -ENOMEM)
> return -ENOMEM;
>
> However, looking at copy_huge_pud() in mm/huge_memory.c (line 1966),
> it only returns two values:
> - 0 on success (line 1994)
> - -EAGAIN when !pud_trans_huge(pud) (line 1978)
>
> There is no code path that returns -ENOMEM, which means the check
> "if (err == -ENOMEM)" at line 1421 is unreachable dead code.
>
> Is this intentional defensive coding for potential future changes,
> or could this unreachable error check be cleaned up?
It seems like commit a00cc7d9dd93 ("mm, x86: add support for PUD-sized
transparent hugepages") introduced both the if (err == -ENOMEM) check and
copy_huge_pud, back in 2017.
And at the time these were introduced, copy_huge_pud only had return
values for -EAGAIN and 0, as you pointed out. So it doesn't seem like
there's any bug or missed case, just an extra case.
My guess is that copy_pud_range tried to imitate copy_pmd_range and added
the -ENOMEM check. copy_huge_pmd can return -ENOMEM though, so it seems
like this is what was missed when copying the function over.
If you have other changes in this area, this might be a good candidate
for a small fix-up to be included in the series? : -) The whole if
block inside pud_trans_huge(...) can be simplified quite a bit:
do {
...
if (pud_trans_huge(*src_pud)) {
VM_BUG_ON_VMA(next-addr != HPAGE_PUD_SIZE, src_vma);
if (!copy_huge_pud(dst_mm, src_mm, dst_pud, src_pud,
addr, src_vma))
continue;
}
...
}
Anyways... Hope this answers your question! Have a great day,
Joshua
next prev parent reply other threads:[~2026-02-02 15:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-31 17:28 Ingyu Jang
2026-02-02 15:28 ` Joshua Hahn [this message]
2026-02-02 15:37 ` Matthew Wilcox
2026-02-02 15:50 ` Joshua Hahn
2026-02-02 15:40 ` David Hildenbrand (arm)
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=20260202152839.221116-1-joshua.hahnjy@gmail.com \
--to=joshua.hahnjy@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=ingyujang25@korea.ac.kr \
--cc=linux-mm@kvack.org \
/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