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 F0579C433FE for ; Tue, 19 Apr 2022 19:23:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 752606B0073; Tue, 19 Apr 2022 15:23:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 728566B0074; Tue, 19 Apr 2022 15:23:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 616B56B0075; Tue, 19 Apr 2022 15:23:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 5510C6B0073 for ; Tue, 19 Apr 2022 15:23:59 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1CF7721554 for ; Tue, 19 Apr 2022 19:23:59 +0000 (UTC) X-FDA: 79374603798.04.A461576 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf21.hostedemail.com (Postfix) with ESMTP id A78C51C0019 for ; Tue, 19 Apr 2022 19:23:56 +0000 (UTC) Received: from zn.tnic (p200300ea971b5839329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:971b:5839:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 94A9C1EC0559; Tue, 19 Apr 2022 21:23:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1650396231; h=from:from: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; bh=29ILHsZsLNI1cHkGwMzPc7ayyznGcYHN5+bzv1pE4pk=; b=aOCYh/K44Q0EvpEMzkaAkbuIouuG5B+e3XnIHMcNGSqGDlq43m1JcEwpdibQBrvwv4q3/4 lpCszkih78a7WOxtjAwh9GrByUAHbvIgTuaQBP/HCbisa1Dwtwg3qHo3J0+uWJAwYS2ems JD2I1GH9VQDeinJxeKVOZFTVW7jM0CA= Date: Tue, 19 Apr 2022 21:23:48 +0200 From: Borislav Petkov To: "Kirill A. Shutemov" 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: 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> <20220419153002.ffh2ybdl7x2mm7zw@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220419153002.ffh2ybdl7x2mm7zw@box.shutemov.name> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A78C51C0019 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b="aOCYh/K4"; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf21.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de X-Stat-Signature: wbtuadur9jos7irg313yz8pzmp3ga4yn X-HE-Tag: 1650396236-664204 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 06:30:02PM +0300, Kirill A. Shutemov wrote: > Hm. Dave was worried about having copies of _find_next_bit() and > __bitmap_*() inside compressed/. That's fine. > How do we rectify code duplication and making decompresser self-contained? Also fine - as long as the decompressor and kernel-proper are independent. > Do we care about multiple copies of the same code in the kernel? The copied versions in the decompressor should be simply sufficient for its use. And there shouldn't be that much of duplication. Note that we're using the same strategy with perf tool - it does copy kernel facilities when it needs them. > Do we care about keeping them in sync? Nope - as long as they're sufficient for the decompressor. My expectation here is that the decompressor won't need too many facilities. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette