[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM9PR08MB7276E0DE6B4224C22B20A89CF44C9@AM9PR08MB7276.eurprd08.prod.outlook.com>
Date: Thu, 6 Jan 2022 10:13:06 +0000
From: Jianyong Wu <Jianyong.Wu@....com>
To: Catalin Marinas <Catalin.Marinas@....com>
CC: "will@...nel.org" <will@...nel.org>,
Anshuman Khandual <Anshuman.Khandual@....com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"david@...hat.com" <david@...hat.com>,
"quic_qiancai@...cinc.com" <quic_qiancai@...cinc.com>,
"ardb@...nel.org" <ardb@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"gshan@...hat.com" <gshan@...hat.com>,
Justin He <Justin.He@....com>, nd <nd@....com>
Subject: RE: [PATCH v3] arm64/mm: avoid fixmap race condition when create pud
mapping
Hi Catalin,
I test this patch in your way using both EDK2 V2.6 and EDK2 v2.7. it's peculiar that this issue shows up on v2.6 but not on v2.7.
For now, I only find that if "CONFIG_DEBUG_LOCK_ALLOC" is enabled, the kernel boot will hang. However, I can't debug it by printk as this issue happens before pl11 is ready.
I will go on debugging, but very appreciated if someone can give some hints on it.
Thanks
Jianyong
> -----Original Message-----
> From: Catalin Marinas <catalin.marinas@....com>
> Sent: Thursday, January 6, 2022 2:04 AM
> To: Jianyong Wu <Jianyong.Wu@....com>
> Cc: will@...nel.org; Anshuman Khandual <Anshuman.Khandual@....com>;
> akpm@...ux-foundation.org; david@...hat.com; quic_qiancai@...cinc.com;
> ardb@...nel.org; linux-kernel@...r.kernel.org; linux-arm-
> kernel@...ts.infradead.org; gshan@...hat.com; Justin He
> <Justin.He@....com>; nd <nd@....com>
> Subject: Re: [PATCH v3] arm64/mm: avoid fixmap race condition when create
> pud mapping
>
> On Thu, Dec 16, 2021 at 04:28:12PM +0800, Jianyong Wu wrote:
> > The 'fixmap' is a global resource and is used recursively by create
> > pud mapping(), leading to a potential race condition in the presence
> > of a concurrent call to alloc_init_pud():
> >
> > kernel_init thread virtio-mem workqueue thread
> > ================== ===========================
> >
> > alloc_init_pud(...) alloc_init_pud(...)
> > pudp = pud_set_fixmap_offset(...) pudp = pud_set_fixmap_offset(...)
> > READ_ONCE(*pudp)
> > pud_clear_fixmap(...)
> > READ_ONCE(*pudp) // CRASH!
> >
> > As kernel may sleep during creating pud mapping, introduce a mutex
> > lock to serialise use of the fixmap entries by alloc_init_pud().
> >
> > Signed-off-by: Jianyong Wu <jianyong.wu@....com>
>
> I tried to queue this patch but with certain configurations it doesn't boot
> under Qemu. Starting from defconfig, update .config with (I had this in one
> of my build scripts):
>
> $ ./scripts/config \
> -e DEBUG_KERNEL \
> -e DEBUG_PAGEALLOC \
> -e DEBUG_PAGEALLOC_ENABLE_DEFAULT \
> -e DEBUG_WX \
> -e DEBUG_SET_MODULE_RONX \
> -e DEBUG_ALIGN_RODATA \
> -e ARM64_PTDUMP_DEBUGFS \
> -e DEBUG_OBJECTS \
> -e DEBUG_OBJECTS_FREE \
> -e DEBUG_OBJECTS_TIMERS \
> -e DEBUG_KOBJECT_RELEASE \
> -e DEBUG_LOCKING_API_SELFTESTS \
> -e DEBUG_PREEMPT \
> -e DEBUG_TIMEKEEPING \
> -e DEBUG_VM \
> -e DEBUG_VM_VMACACHE \
> -e DEBUG_VM_RB \
> -e DEBUG_VM_PGFLAGS \
> -e DEBUG_VIRTUAL \
> -e DEBUG_LIST \
> -e DEBUG_PI_LIST \
> -e DEBUG_SG \
> -e PROVE_LOCKING \
> -e DEBUG_RT_MUTEXES \
> -e DEBUG_ATOMIC_SLEEP \
> -e ATOMIC64_SELFTEST
>
> It stop after exiting the EFI boot services. I did not have time to debug.
>
> --
> Catalin
Powered by blists - more mailing lists