[Question] Dead code in copy_pud_range() for copy_huge_pud() error check?

[Question] Dead code in copy_pud_range() for copy_huge_pud() error check?

[Ingyu Jang]

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?

Thanks,
Ingyu Jang

Re: [Question] Dead code in copy_pud_range() for copy_huge_pud() error check?

[Joshua Hahn]

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

Re: [Question] Dead code in copy_pud_range() for copy_huge_pud() error check?

[Matthew Wilcox]

On Mon, Feb 02, 2026 at 07:28:38AM -0800, Joshua Hahn wrote:
> 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:

Please don't encourage people to make changes to mm code when you aren't
the maintainer.  The last thing we need is more tweaky little changes
that need to be carefully reviewed in case they have a subtle bug.

Re: [Question] Dead code in copy_pud_range() for copy_huge_pud() error check?

[Joshua Hahn]

On Mon, 2 Feb 2026 15:37:20 +0000 Matthew Wilcox <willy@infradead.org> wrote:

> On Mon, Feb 02, 2026 at 07:28:38AM -0800, Joshua Hahn wrote:
> > 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:
> 
> Please don't encourage people to make changes to mm code when you aren't
> the maintainer.  The last thing we need is more tweaky little changes
> that need to be carefully reviewed in case they have a subtle bug.

Hello Matthew,

You're right, sorry about that. I'll be more mindful in the future.

Have a great day!
Joshua

Re: [Question] Dead code in copy_pud_range() for copy_huge_pud() error check?

[David Hildenbrand (arm)]

On 1/31/26 18:28, Ingyu Jang wrote:
> 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)
> 

I think it cannot currently trigger, but likely would once we support 
PUD THP, see [1]. So best to leave it as is.


[1] https://lkml.kernel.org/r/20260202005451.774496-1-usamaarif642@gmail.com

-- 
Cheers

David