lists.openwall.net | 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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <67ce254c-aacc-43b6-d8d5-168ef9200f9e@intel.com> Date: Tue, 10 Aug 2021 11:16:26 -0700 From: Dave Hansen <dave.hansen@...el.com> To: "Kirill A. Shutemov" <kirill@...temov.name>, Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>, Sean Christopherson <seanjc@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Joerg Roedel <jroedel@...e.de> Cc: Andi Kleen <ak@...ux.intel.com>, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>, David Rientjes <rientjes@...gle.com>, Vlastimil Babka <vbabka@...e.cz>, Tom Lendacky <thomas.lendacky@....com>, Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>, Paolo Bonzini <pbonzini@...hat.com>, Ingo Molnar <mingo@...hat.com>, Varad Gautam <varad.gautam@...e.com>, Dario Faggioli <dfaggioli@...e.com>, x86@...nel.org, linux-mm@...ck.org, linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com> 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: del_page_from_free_list()-> clear_page_offline()-> accept_memory() 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