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 0EB22C433F5 for ; Tue, 19 Apr 2022 15:28:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BE818D0079; Tue, 19 Apr 2022 11:28:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76CE18D0047; Tue, 19 Apr 2022 11:28:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E6898D0079; Tue, 19 Apr 2022 11:28:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 4C45F8D0047 for ; Tue, 19 Apr 2022 11:28:28 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0024B625BE for ; Tue, 19 Apr 2022 15:28:27 +0000 (UTC) X-FDA: 79374010296.03.F93979C Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf24.hostedemail.com (Postfix) with ESMTP id 61249180019 for ; Tue, 19 Apr 2022 15:28:26 +0000 (UTC) Received: by mail-lj1-f173.google.com with SMTP id y11so3431987ljh.5 for ; Tue, 19 Apr 2022 08:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=IPYkjAqB00Xxjikyucyrlisswxv3Uu4wKk4/LnVwWm8=; b=ET2dFk9aXbq+2du32xy0VJqQN1YDmZMLNM/xlOZkTY4XHyGVyzEkvOVxE5UmMLn+Wp YExIWYqo2rtEyCEv7QIXQpM20AA/xQeiAysy34JEPURNAMpqA3JBsOu604Lh2hPw+5/c E8hHPr0WCvb8dYnwnsNbVYuWCbGAv89QMKUDiEDqUFibiIWuzAAUPttZxNrbO1S9BV0s pzFdWnmFKbNVmXjSAKIB3rCAgGPKQ4U8YVKtVEgIrKpuK3oVlT8ntMSJQx+py4vFhPCq X8dRTTTGhxkUJqDhgSE8/4qnvNyK9Eg09cY3Oj7ufQ+uVc9YgodTclsGipgsgT1AZ5Nm BdFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IPYkjAqB00Xxjikyucyrlisswxv3Uu4wKk4/LnVwWm8=; b=A+sJzHzznR5xQHNDZHW5GHSCkp1wWq4VjcdX9ksYtcpCowOKTVE9q3c9BwUoFXvewy /Vv2v5OwpxVKxBFdURwNuvU18hvbVUt+TxdcLYDez3dngroRwH4bbUHel8t9zSmjv5FF f5cfgDwDSVMycmPclryZsMXTusfs9a1iW97+qP/V0KmH11qegl0K5wF8mh+WDyAcIaXy V7DB5F0R0wjN1JOt/r+98sonAP0jxRvEelGhZd7WzOPvT1Ya+ABwf777SCrAJKqDqH/0 HEPT+hufjixM9NrA6OPP9Bt2rdZdXd2F1AX9XHcDMdT9pmsRQimYSUTRkC+hF3M14xKV r75w== X-Gm-Message-State: AOAM530OuMCr2kLPYIVZiQkcV09lzgfkLoD3uuq61/oOSPVIbhE5o6hA CnrcbPlEWHCNx3hikYGipjujQw== X-Google-Smtp-Source: ABdhPJxFgaQNwsrkGsQvpbSc49Nh0VBtkIBJACRSpLsWn2p7SstiY+esd57CVUrx8BbP8cSpEJr3cw== X-Received: by 2002:a2e:84cc:0:b0:247:e395:7948 with SMTP id q12-20020a2e84cc000000b00247e3957948mr10253293ljh.499.1650382105629; Tue, 19 Apr 2022 08:28:25 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id e5-20020a196745000000b0046b8b922c1csm1543311lfj.158.2022.04.19.08.28.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Apr 2022 08:28:25 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 140FE103C63; Tue, 19 Apr 2022 18:30:02 +0300 (+03) Date: Tue, 19 Apr 2022 18:30:02 +0300 From: "Kirill A. Shutemov" To: Borislav Petkov Cc: "Kirill A. Shutemov" , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Dave Hansen , Brijesh Singh , Mike Rapoport , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv4 3/8] efi/x86: Implement support for unaccepted memory Message-ID: <20220419153002.ffh2ybdl7x2mm7zw@box.shutemov.name> References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-4-kirill.shutemov@linux.intel.com> <20220418155545.a567xnxa6elglapl@box.shutemov.name> <20220418202431.whvql4w57c7l5vpw@box.shutemov.name> <20220418235015.mnujtlmmlyin7y6m@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 61249180019 X-Stat-Signature: nqkre76zyf56upjdt3mfff66m5phtz5h Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=ET2dFk9a; dmarc=none; spf=none (imf24.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.208.173) smtp.mailfrom=kirill@shutemov.name X-HE-Tag: 1650382106-150937 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 Tue, Apr 19, 2022 at 09:39:53AM +0200, Borislav Petkov wrote: > On Tue, Apr 19, 2022 at 02:50:15AM +0300, Kirill A. Shutemov wrote: > > I find it strange that you go after which has limited > > exposure while and are there already. > > Funny you should mention that: > > https://lore.kernel.org/r/YlCKWhMJEMUgJmjF@zn.tnic > > I *have* been working towards that but it's a losing whack-a-mole game > when you and others keep adding new stuff. > > So no, we won't take a pile of changes and let the maintainer clean it > up afterwards. > > > What do you want me to do here? > > I think the stuff coming from the linux/ namespace you can simply copy > into a header in compressed/, like I've done with efi.h. Hm. Dave was worried about having copies of _find_next_bit() and __bitmap_*() inside compressed/. How do we rectify code duplication and making decompresser self-contained? Do we care about multiple copies of the same code in the kernel? Do we care about keeping them in sync? > > // > > The asm/ stuff can be put into a shared/ namespace header like the io > stuff you did. > > > As 1 bit represents 2M, not all chunks can be represented in the bitmap > > and they have to be accepted. But the *goal* is to record unaccepted > > memory into bitmap. Some accepting is a side effect. > > > > The early_accept_memory() name is just wrong. > > Ok, how about process_unaccepted_memory(). It should be generic enough. Sounds good. -- Kirill A. Shutemov