Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp2624814rdg; Mon, 16 Oct 2023 09:43:20 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF/SpPA1lvcPiF2+O376Xcc8YAPmXpSiY6eEa9fOmuRce6Y/qSq2FobW4WcNuhZwutMhoYx X-Received: by 2002:a05:6870:cd85:b0:1e9:cde8:6db0 with SMTP id xb5-20020a056870cd8500b001e9cde86db0mr10272056oab.50.1697474600196; Mon, 16 Oct 2023 09:43:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697474600; cv=none; d=google.com; s=arc-20160816; b=Ni6R5TC1f7cc8xpqnmWw6ieI7Kpu9TAK4ZVwCjsZaJbQv0KLZdQPtBfR/7+7fRFIBI FVExyJqytkUQN/64Ly4TYYg8gbc7gO8CMD5FiFqA/oCYtlE4ZBs5Pg9v+kFNKKV0fDc4 gc1SzPyWxs1xM2TwV7rfRi7SA8MYOwt1Z9wN0ZqwFZZI6ePNoh6ZNm4V9vsvo7V/ygQ8 E4rqjAS4KcJR5BMEyfvw/y2UpRkEzof1B3+ubBOm7f6MduXMSp3J+5sj9KTgIKRIu7Pe y0rLSgZSpxg6Mh23NN6xNl9sM4EVOpsRU7FJ+/CLcjz/6lP6Ihb64PqqAZ93yvm2K0Mh QAjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=rtcLf634amKXX13PoI1EmxXp12+Wl6KlAGXtdbAfusc=; fh=05azdIY8Jp+agptCT1wMET9AoIH2V/SOM5dxRUkckGs=; b=J+o3YcD2O4HJN/ml4YfquOzswy8ftTdnzXw9IVVJlKLJVgm+XARkDnpG6kuvnIAn2C oRnIBuW0l1oHSfZTz6x/fK7gzC2F8YBDD6DCl2QZDFjKBHKEnTT5BXyhXcj+ef7yqHpv NkeXTWYnitPTnQ/Y6E6QpTxRzFJt6pBs1drqW7lxQv194oUzcxy+PgBxq6OQ+UyH66b3 UsEoIfr7O74NTu1zAlJ29CpvJYxr2OYjCcd714XSfOitz352BLoN+8NK6o9MrB5ewfTu 0o9BBfUccJHHgBV+G3s00MwXHZIBLncXHQ/3D/3WnllVdojkPlsZwJiWtr3dD1ToMujy k29A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZZKdhCNQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id s8-20020a637708000000b005b21d089aabsi5577626pgc.519.2023.10.16.09.43.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 09:43:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZZKdhCNQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id E852B8087DC8; Mon, 16 Oct 2023 09:43:04 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234608AbjJPQlw (ORCPT + 99 others); Mon, 16 Oct 2023 12:41:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234589AbjJPQl1 (ORCPT ); Mon, 16 Oct 2023 12:41:27 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 968562D71; Mon, 16 Oct 2023 09:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697473902; x=1729009902; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=KArkgIRLDhwmtFvU9fISOShueMaeloHHrxiJqwNwLLU=; b=ZZKdhCNQ/P4SHyYF/wWIHnCixs/uOKF2ApRFxmmv+T3kW9fmk2fdqvR6 LWdVP8BgNcrO1lt0c2bbZJtAHvOfyg46TzFQY40SU+QQFVTYDtR+RThan JOju2liU7SBgz0oXyWZwwl33hpU9K4WFeyLSGDnEnf71ON0c8DV+6+SHq uDf4RuiJYJ1MT8lnEd9+8rarDLiL/6u4CMBHpVUMzkJYiXuNaJ9A7I5E4 J//yWLeM/UTL8ffGMA2QV+tB8NkG7htKGh5n5Zyr9ktt57ZvueNvIQ0NN /5JghnquVruYXRWVqAf4lDZUhFlBLCZQe3dhlz+htr4/dszO/pebrO/4Z Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="449785296" X-IronPort-AV: E=Sophos;i="6.03,229,1694761200"; d="scan'208";a="449785296" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 09:31:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872177333" X-IronPort-AV: E=Sophos;i="6.03,229,1694761200"; d="scan'208";a="872177333" Received: from ranaelna-mobl.amr.corp.intel.com (HELO box.shutemov.name) ([10.251.208.247]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 09:31:29 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 21C6A10A1F3; Mon, 16 Oct 2023 19:31:27 +0300 (+03) From: "Kirill A. Shutemov" To: Borislav Petkov , Andy Lutomirski , Dave Hansen , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel Cc: Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Mike Rapoport , David Hildenbrand , Mel Gorman , marcelo.cerri@canonical.com, tim.gardner@canonical.com, philip.cox@canonical.com, aarcange@redhat.com, peterx@redhat.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" , stable@kernel.org, Nikolay Borisov Subject: [PATCHv2] efi/unaccepted: Fix soft lockups caused by parallel memory acceptance Date: Mon, 16 Oct 2023 19:31:22 +0300 Message-ID: <20231016163122.12855-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Mon, 16 Oct 2023 09:43:05 -0700 (PDT) Michael reported soft lockups on a system that has unaccepted memory. This occurs when a user attempts to allocate and accept memory on multiple CPUs simultaneously. The root cause of the issue is that memory acceptance is serialized with a spinlock, allowing only one CPU to accept memory at a time. The other CPUs spin and wait for their turn, leading to starvation and soft lockup reports. To address this, the code has been modified to release the spinlock while accepting memory. This allows for parallel memory acceptance on multiple CPUs. A newly introduced "accepting_list" keeps track of which memory is currently being accepted. This is necessary to prevent parallel acceptance of the same memory block. If a collision occurs, the lock is released and the process is retried. Such collisions should rarely occur. The main path for memory acceptance is the page allocator, which accepts memory in MAX_ORDER chunks. As long as MAX_ORDER is equal to or larger than the unit_size, collisions will never occur because the caller fully owns the memory block being accepted. Aside from the page allocator, only memblock and deferered_free_range() accept memory, but this only happens during boot. The code has been tested with unit_size == 128MiB to trigger collisions and validate the retry codepath. Signed-off-by: Kirill A. Shutemov Reported-by: Michael Roth Reviewed-by: Nikolay Borisov --- v2: - Fix deadlock (Vlastimil); - Fix comments (Vlastimil); - s/cond_resched()/cpu_relax()/ -- cond_resched() cannot be called from atomic context; --- drivers/firmware/efi/unaccepted_memory.c | 71 ++++++++++++++++++++++-- 1 file changed, 67 insertions(+), 4 deletions(-) diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c index 853f7dc3c21d..fa3363889224 100644 --- a/drivers/firmware/efi/unaccepted_memory.c +++ b/drivers/firmware/efi/unaccepted_memory.c @@ -5,9 +5,17 @@ #include #include -/* Protects unaccepted memory bitmap */ +/* Protects unaccepted memory bitmap and accepting_list */ static DEFINE_SPINLOCK(unaccepted_memory_lock); +struct accept_range { + struct list_head list; + unsigned long start; + unsigned long end; +}; + +static LIST_HEAD(accepting_list); + /* * accept_memory() -- Consult bitmap and accept the memory if needed. * @@ -24,6 +32,7 @@ void accept_memory(phys_addr_t start, phys_addr_t end) { struct efi_unaccepted_memory *unaccepted; unsigned long range_start, range_end; + struct accept_range range, *entry; unsigned long flags; u64 unit_size; @@ -78,20 +87,74 @@ void accept_memory(phys_addr_t start, phys_addr_t end) if (end > unaccepted->size * unit_size * BITS_PER_BYTE) end = unaccepted->size * unit_size * BITS_PER_BYTE; - range_start = start / unit_size; - + range.start = start / unit_size; + range.end = DIV_ROUND_UP(end, unit_size); +retry: spin_lock_irqsave(&unaccepted_memory_lock, flags); + + /* + * Check if anybody works on accepting the same range of the memory. + * + * The check is done with unit_size granularity. It is crucial to catch + * all accept requests to the same unit_size block, even if they don't + * overlap on physical address level. + */ + list_for_each_entry(entry, &accepting_list, list) { + if (entry->end < range.start) + continue; + if (entry->start >= range.end) + continue; + + /* + * Somebody else accepting the range. Or at least part of it. + * + * Drop the lock and retry until it is complete. + */ + spin_unlock_irqrestore(&unaccepted_memory_lock, flags); + + /* + * The code is reachable from atomic context. + * cond_resched() cannot be used. + */ + cpu_relax(); + + goto retry; + } + + /* + * Register that the range is about to be accepted. + * Make sure nobody else will accept it. + */ + list_add(&range.list, &accepting_list); + + range_start = range.start; for_each_set_bitrange_from(range_start, range_end, unaccepted->bitmap, - DIV_ROUND_UP(end, unit_size)) { + range.end) { unsigned long phys_start, phys_end; unsigned long len = range_end - range_start; phys_start = range_start * unit_size + unaccepted->phys_base; phys_end = range_end * unit_size + unaccepted->phys_base; + /* + * Keep interrupts disabled until the accept operation is + * complete in order to prevent deadlocks. + * + * Enabling interrupts before calling arch_accept_memory() + * creates an opportunity for an interrupt handler to request + * acceptance for the same memory. The handler will continuously + * spin with interrupts disabled, preventing other task from + * making progress with the acceptance process. + */ + spin_unlock(&unaccepted_memory_lock); + arch_accept_memory(phys_start, phys_end); + + spin_lock(&unaccepted_memory_lock); bitmap_clear(unaccepted->bitmap, range_start, len); } + + list_del(&range.list); spin_unlock_irqrestore(&unaccepted_memory_lock, flags); } -- 2.41.0