From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B98CCDB47E for ; Fri, 13 Oct 2023 21:54:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 754518D0171; Fri, 13 Oct 2023 17:54:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DD168D0015; Fri, 13 Oct 2023 17:54:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5569A8D0171; Fri, 13 Oct 2023 17:54:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 428DD8D0015 for ; Fri, 13 Oct 2023 17:54:25 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 141358054E for ; Fri, 13 Oct 2023 21:54:25 +0000 (UTC) X-FDA: 81341792490.11.3796743 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by imf11.hostedemail.com (Postfix) with ESMTP id B354B40016 for ; Fri, 13 Oct 2023 21:54:22 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SNPG0IoZ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf11.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697234063; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ewJTdPB7p9vCUnK0Z052ih84nwQyktCChv8EpCp2ssU=; b=IZUgbpUBOO8olJ9DPdW7zV3TXXQ/yr8JjZmiIjSA9aEbnao8KW8aoTUrdLVPWYHHxlDjp0 LiGfpK/gt6D8+YASrGhrXMCBNHn9wv4PDE59gj3aZ4fKrEEvsHRymZiKH7mhcfhdduWFwc 47rwuuzYDJ6beO65tEWRRos80TzX6mk= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SNPG0IoZ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf11.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697234063; a=rsa-sha256; cv=none; b=IIUJbZbPsKZ5vz0uD10GCoNJtP6f1NB9xKXCRhIjlHgdvjAASoYydcyaQFl1Ju1z8NskMT CCyEeumCKjGvGn0s4Bn8UJhxlZoozoeLFHV3YzL7VZVR3mX3u8RKPGdQxF09hG8fLyEI+O OGkems5jCx6c70EudkWMJOQT9CypIIU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697234062; x=1728770062; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=dltmjFDVO3vTssOWPlJg915YZex65bACfWFkwBG7/Uo=; b=SNPG0IoZJ7i15zN8HcivWObCFSml2IlaCDxacCtz4NZsHjtQznKQpU15 xiZKu9Swd8vk9mpPmCKPl+2P6o+GK/h9BZXrQLOfKjad50+DJdAosLqFM f5lX3D5SBSpIKwWOeHx3iS5Ku4Y2M1rSyFIPYrjLdtMPkb8uWwJlEpC6b hrVOTaKBtryAtMbO792GczY1v/93lEGN6GrRIUa7bqsQnbzz1onETRZ5R f99dHSJ8b3ToJcIKrUlL0w8LdsWXGxWlOuf6vE1VubQ7JYQbyfcyQ9mga jEPvV3aHtFjCmRaEup2IGYqTcvE5RNeMEHZ9iXYXi4ymWNdcjLBNHsHmt A==; X-IronPort-AV: E=McAfee;i="6600,9927,10862"; a="384142825" X-IronPort-AV: E=Sophos;i="6.03,223,1694761200"; d="scan'208";a="384142825" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2023 14:54:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10862"; a="784311876" X-IronPort-AV: E=Sophos;i="6.03,223,1694761200"; d="scan'208";a="784311876" Received: from bgras-mobl1.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.59.145]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2023 14:54:13 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 9110A104350; Sat, 14 Oct 2023 00:54:10 +0300 (+03) Date: Sat, 14 Oct 2023 00:54:10 +0300 From: "Kirill A. Shutemov" To: Vlastimil Babka Cc: Michael Roth , Borislav Petkov , Andy Lutomirski , Dave Hansen , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , 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, khalid.elmously@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 Subject: Re: [PATCHv14 5/9] efi: Add unaccepted memory support Message-ID: <20231013215410.3os6d2ya7v5yu7vd@box.shutemov.name> References: <20230606142637.5171-1-kirill.shutemov@linux.intel.com> <20230606142637.5171-6-kirill.shutemov@linux.intel.com> <20231010210518.jguawj7bscwgvszv@amd.com> <20231013123358.y4pcdp5fgtt4ax6g@box.shutemov.name> <20231013162210.bqepgz6wnh7uohqq@box> <34d94c58-f5f3-48eb-5833-0ef0c90cf868@suse.cz> <20231013172728.66pm7os3fp7laxwr@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231013172728.66pm7os3fp7laxwr@box> X-Rspam-User: X-Stat-Signature: nnqg3s8so3texf3dw1y8drcison94un4 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B354B40016 X-HE-Tag: 1697234062-970896 X-HE-Meta: U2FsdGVkX19uVN9vNYNp6xnsaydmfswMSzy2zHZbQSiZf+7aG8lKiADRE/U6JHdWWI6q05GFZQUSpo8Zcz4d16NUBHd2HoJdjYu6raoff44jLNhXAhPFBDuo9vY/bF/9kkLxmZSLLAChABlGWtow2uHrFipBKAhN3ayiaO1J5gMNAriCUa2ry9h9LK+qGXEclYpDYsva61B8e6vw2AK6k1OgIOuo2hzPno0OWZyctTqYsGnRxE4BWrGsS1n6mvtJb8quCp1ZQLcxEh/OSq68Ue21vdBmCA21e02ayl9T8tZgiFDBq6Am3ZJS5h4vLZJFM+8CdxM9BCbcLW1aHtas8Lo8CSEUVqWm0lXPECdrUEYXyptd/E4Jh1piYiDu7iNwy269GOreRXPH+mmAeJsCtB+dSJ03zzMuo3WiOLQ/BVA9XZK8gEqyIoh+VOd8C66MHyH0YwcoPTjyXv5dz111Dg9aoaafkyL5D8UELvOOBf/et7bHngWjHuI3gbWny/wVjvKY2ADdBsidhBjEXq6+Rc7hUPvxhMHNOV1W/B3SfFlryP7h+VxiTMKRG7dhOjdz2iCYYjB0VEGlQvqgDWyRhRGl5gDqyXfF/HtR5a7jcR2airAJqrreD2goFysBiJmSln2wrAkgTDK3Yb4yzcvO5Ti2hiaUiWoxw/3RpJgk4rdWiEyEIX+cmDyvOClwjlGPXJnlGr/FPBR1YrPQwkOe0/yVZxcq/MqCUjLreO6LSGgFS+GVe2ogu1LRg7lnO7zwwTzT3kS/WWen0dRpp+DhUtxYsw5nzRqy4VFR3NZVCisNnquBVVD8wlrYHCtUV2Qg8XuepDY/G8kh2kdZu6jMy/0smN04Ur2CJyi69Ix522fnCHSUf5QzTeQQ4DlF3uxJPatdubTIxuQu4QbbfNxLAtnrtpkklRH13XchnpGegw4K901j7q1bzJFTzwGL0IudBMV5j7hBmOaaxqJ+BRe mwJd/aFN a2bzyxKOfg787PG/lRUUwy5YudjnrjiCXyHN2ViDsxW7+wLwmvDIpnbjQg6Q567giVBy8wkp2VNwlIRXCJPcw2uRH6V75wweJ0kjdNkCGgXtDfQY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Oct 13, 2023 at 08:27:28PM +0300, Kirill A. Shutemov wrote: > I will test the idea with larger unit_size to see how it behaves. It indeed uncovered an issue. We need to record ranges on accepting_list in unit_size granularity. Otherwise, we fail to stop parallel accept requests to the same unit_size block if they don't overlap on physical addresses. Updated patch: diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c index 853f7dc3c21d..8af0306c8e5c 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,58 @@ 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 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); + cond_resched(); + 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; + spin_unlock_irqrestore(&unaccepted_memory_lock, flags); + arch_accept_memory(phys_start, phys_end); + + spin_lock_irqsave(&unaccepted_memory_lock, flags); bitmap_clear(unaccepted->bitmap, range_start, len); } + + list_del(&range.list); spin_unlock_irqrestore(&unaccepted_memory_lock, flags); } -- Kiryl Shutsemau / Kirill A. Shutemov