From: David Hildenbrand <david@redhat.com>
To: Jianyong Wu <Jianyong.Wu@arm.com>,
Anshuman Khandual <Anshuman.Khandual@arm.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"will@kernel.org" <will@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "ardb@kernel.org" <ardb@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"gshan@redhat.com" <gshan@redhat.com>,
Justin He <Justin.He@arm.com>, nd <nd@arm.com>
Subject: Re: [PATCH v2] arm64/mm: avoid fixmap race condition when create pud mapping
Date: Mon, 13 Dec 2021 08:37:04 +0100 [thread overview]
Message-ID: <3366ba9f-5993-1c52-de0c-53e618f20cd8@redhat.com> (raw)
In-Reply-To: <AM9PR08MB7276135C8586C80BD51A5A68F4749@AM9PR08MB7276.eurprd08.prod.outlook.com>
On 13.12.21 08:27, Jianyong Wu wrote:
>
>
>> -----Original Message-----
>> From: Anshuman Khandual <anshuman.khandual@arm.com>
>> Sent: Monday, December 13, 2021 2:56 PM
>> To: Jianyong Wu <Jianyong.Wu@arm.com>; Catalin Marinas
>> <Catalin.Marinas@arm.com>; will@kernel.org; akpm@linux-foundation.org
>> Cc: ardb@kernel.org; linux-kernel@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; david@redhat.com; gshan@redhat.com; Justin
>> He <Justin.He@arm.com>; nd <nd@arm.com>
>> Subject: Re: [PATCH v2] arm64/mm: avoid fixmap race condition when create
>> pud mapping
>>
>>
>>
>> On 12/10/21 3:24 PM, Jianyong Wu wrote:
>>> fixmap is a global resource and is used recursively in create pud mapping.
>>> It may lead to race condition when alloc_init_pud is called concurrently.
>>>
>>> Fox example:
>>> alloc_init_pud is called when kernel_init. If memory hotplug thread,
>>> which will also call alloc_init_pud, happens during kernel_init, the
>>> race for fixmap occurs.
>>>
>>> The race condition flow can be:
>>>
>>> *************** begin **************
>>>
>>> kerenl_init thread virtio-mem workqueue thread
>>> ================== ======== ==================
>>> alloc_init_pud(...)
>>> pudp = pud_set_fixmap_offset(..) alloc_init_pud(...)
>>> ... ...
>>> READ_ONCE(*pudp) //OK! pudp = pud_set_fixmap_offset(
>>> ... ...
>>> pud_clear_fixmap() //fixmap break
>>> READ_ONCE(*pudp) //CRASH!
>>>
>>> **************** end ***************
>>>
>>> Hence, a spin lock is introduced to protect the fixmap during create
>>> pdg mapping.
>>>
>>> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
>>> ---
>>> arch/arm64/mm/mmu.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index
>>> acfae9b41cc8..98ac09ae9588 100644
>>> --- a/arch/arm64/mm/mmu.c
>>> +++ b/arch/arm64/mm/mmu.c
>>> @@ -63,6 +63,7 @@ static pmd_t bm_pmd[PTRS_PER_PMD]
>> __page_aligned_bss
>>> __maybe_unused; static pud_t bm_pud[PTRS_PER_PUD]
>> __page_aligned_bss
>>> __maybe_unused;
>>>
>>> static DEFINE_SPINLOCK(swapper_pgdir_lock);
>>> +static DEFINE_SPINLOCK(fixmap_lock);
>>>
>>> void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd) { @@ -329,6 +330,11 @@
>>> static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long
>> end,
>>> }
>>> BUG_ON(p4d_bad(p4d));
>>>
>>> + /*
>>> + * fixmap is global resource, thus it needs to be protected by a lock
>>> + * in case of race condition.
>>> + */
>>> + spin_lock(&fixmap_lock);
>>> pudp = pud_set_fixmap_offset(p4dp, addr);
>>> do {
>>> pud_t old_pud = READ_ONCE(*pudp);
>>> @@ -359,6 +365,7 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned
>> long addr, unsigned long end,
>>> } while (pudp++, addr = next, addr != end);
>>>
>>> pud_clear_fixmap();
>>> + spin_unlock(&fixmap_lock);
>>> }
>>>
>>> static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
>>>
>>
>> As the race could only happen with memory hotplug being enabled, could
>> not we wrap this around with CONFIG_MEMORY_HOTPLUG, just to narrow
>> its scope possibly speed up other non-hotplug cases ?
>
> I think it's better.
We better avoid using ifdef if not really necessary, it just uglifies
the code. We could add
if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
...
But should we really try to micto-optimize this code and make it harder
to read for the purpose of an unproven performance gain? (if there is no
contention, we'll most probably not even recognize that we're taking a lock)
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-12-13 7:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 9:54 [PATCH v2] arm64/mm: avoid fixmap race condition when create pud mapping Jianyong Wu
2021-12-10 11:22 ` Catalin Marinas
2021-12-13 5:24 ` Jianyong Wu
2021-12-13 6:56 ` Anshuman Khandual
2021-12-13 7:27 ` Jianyong Wu
2021-12-13 7:37 ` David Hildenbrand [this message]
2021-12-13 9:57 ` Catalin Marinas
2021-12-13 10:16 ` Anshuman Khandual
2021-12-13 10:35 ` Ard Biesheuvel
2021-12-13 13:45 ` Will Deacon
2021-12-13 14:01 ` Ard Biesheuvel
2021-12-13 16:42 ` Will Deacon
2021-12-15 14:13 ` Qian Cai
2021-12-15 16:02 ` Catalin Marinas
2021-12-15 16:04 ` David Hildenbrand
2021-12-16 3:00 ` Jianyong Wu
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=3366ba9f-5993-1c52-de0c-53e618f20cd8@redhat.com \
--to=david@redhat.com \
--cc=Anshuman.Khandual@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Jianyong.Wu@arm.com \
--cc=Justin.He@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=gshan@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nd@arm.com \
--cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).