[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <95fcd42c-cb41-d280-32a4-97708061fe41@huawei.com>
Date: Thu, 2 Mar 2023 11:47:16 +0800
From: mawupeng <mawupeng1@...wei.com>
To: <dave.hansen@...el.com>, <akpm@...ux-foundation.org>,
<dave.hansen@...ux.intel.com>, <luto@...nel.org>,
<peterz@...radead.org>
CC: <mawupeng1@...wei.com>, <linux-kernel@...r.kernel.org>,
<x86@...nel.org>, <bp@...e.de>, <toshi.kani@...com>,
<suresh.b.siddha@...el.com>,
<syzbot+5f488e922d047d8f00cc@...kaller.appspotmail.com>
Subject: Re: [RFC PATCH 1/1] x86/mm/pat: Clear VM_PAT if copy_p4d_range failed
On 2023/2/23 4:03, Dave Hansen wrote:
> On 2/16/23 18:56, Wupeng Ma wrote:
>> dup_mm
>> dup_mmap
>> copy_page_range
>> copy_p4d_range
>> copy_pud_range
>> copy_pmd_range
>> pmd_alloc
>> __pmd_alloc
>> pmd_alloc_one
>> page = alloc_pages(gfp, 0);
>> if (!page)
>> return NULL;
>> mmput
>> exit_mmap
>> unmap_vmas
>> unmap_single_vma
>> untrack_pfn
>> follow_phys
>> WARN_ON_ONCE(1);
>
> What's the point of that warning in the first place? I can certainly
> imagine follow_phys() failing for sparse mappings, for instance. Is
> there some requirement that VM_PFNMAP can't be sparse?
Hi Dave
Thanks for reviewing.
Sorry,I have no idea why warning in the first place.
I think we can delete this WARN_ON_ONCE with another patch?
Powered by blists - more mailing lists