lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 10 Aug 2021 11:16:26 -0700
From:   Dave Hansen <>
To:     "Kirill A. Shutemov" <>,
        Borislav Petkov <>,
        Andy Lutomirski <>,
        Sean Christopherson <>,
        Andrew Morton <>,
        Joerg Roedel <>
Cc:     Andi Kleen <>,
        Kuppuswamy Sathyanarayanan 
        David Rientjes <>,
        Vlastimil Babka <>,
        Tom Lendacky <>,
        Thomas Gleixner <>,
        Peter Zijlstra <>,
        Paolo Bonzini <>,
        Ingo Molnar <>,
        Varad Gautam <>,
        Dario Faggioli <>,,,,,
        "Kirill A. Shutemov" <>
Subject: Re: [PATCH 4/5] x86/mm: Provide helpers for unaccepted memory

On 8/9/21 11:26 PM, Kirill A. Shutemov wrote:
> +void accept_memory(phys_addr_t start, phys_addr_t end)
> +{
> +	if (!boot_params.unaccepted_memory)
> +		return;
> +
> +	spin_lock(&unaccepted_memory_lock);
> +	__accept_memory(start, end);
> +	spin_unlock(&unaccepted_memory_lock);
> +}

Isn't this taken in the:


call path?

That's underneath:

	spin_lock_irqsave(&zone->lock, flags);

Which means that accept_memory() can happen from interrupt context.  Is
it always covered by another spin_lock_irqsave() which means that it can
use a plain spin_lock()?

If so, it would be nice to call out that logic.  It *looks* like a
spinlock that we would want to be spin_lock_irqsave().

Powered by blists - more mailing lists