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 1A664C3527C for ; Tue, 19 Apr 2022 16:39:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A08098D0085; Tue, 19 Apr 2022 12:38:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B6BE8D0047; Tue, 19 Apr 2022 12:38:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 808408D0085; Tue, 19 Apr 2022 12:38:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 6F1018D0047 for ; Tue, 19 Apr 2022 12:38:59 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 496D024B60 for ; Tue, 19 Apr 2022 16:38:59 +0000 (UTC) X-FDA: 79374187998.10.3EC74F6 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf13.hostedemail.com (Postfix) with ESMTP id 8381B20011 for ; Tue, 19 Apr 2022 16:38:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650386338; x=1681922338; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to; bh=/sjp7gFP/WNMm0rhzedY8jJRt5eNgyrw8SaiEPlBRkw=; b=FNcNjOqtHJasZTfYRskPBCtmxR2kKvVmkXdSN/jCQeUpO2mRMns8EX/B aOx9Ka14DaQ2W1ooN3ziA9mYoRpGVGZNIqHRPYsFjd3q8GlE6Ye+aKQd+ awou5DBH0KF7DVl87YppsdWTpAejZ6PL6DnlQuKihhocw3J71H29U2LE9 OoiWKsWkgnY74ytrZ5NmfGNwHU7/+ddvD0xC3B5r6i3/oxK/sACfbsy+T sH1FNo6G54VnUUwgBAfhjvo589dTQAWb7aUs2usEusdJdFsCTZd93Czhg TKxxoEx5ECJKDhkM5YRRwr9h/uA/cTH3Hoc40jMDU+rl2BwFNy9bytkfH A==; X-IronPort-AV: E=McAfee;i="6400,9594,10322"; a="244395630" X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="244395630" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 09:38:56 -0700 X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="530465027" Received: from sazizi-mobl2.amr.corp.intel.com (HELO [10.212.98.167]) ([10.212.98.167]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 09:38:54 -0700 Content-Type: multipart/mixed; boundary="------------eWVLiKb8hW4mlc5kPUXDDJhx" Message-ID: <79df6889-aa74-2a86-7565-be882623ddad@intel.com> Date: Tue, 19 Apr 2022 09:38:53 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: "Kirill A. Shutemov" , 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 , 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 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> From: Dave Hansen Subject: Re: [PATCHv4 3/8] efi/x86: Implement support for unaccepted memory In-Reply-To: <20220419153002.ffh2ybdl7x2mm7zw@box.shutemov.name> X-Stat-Signature: koepzk5obnqs5rrc6b71mp934ykj8hm3 X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=FNcNjOqt; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf13.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=dave.hansen@intel.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8381B20011 X-HE-Tag: 1650386337-66355 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: This is a multi-part message in MIME format. --------------eWVLiKb8hW4mlc5kPUXDDJhx Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/19/22 08:30, Kirill A. Shutemov wrote: >> 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? Would it be feasible to have the common code defined as a 'static inline' in a header that both the main kernel and the decompressor could include? Something like the attached patch. I'd much rather duplicate something like this: int strncasecmp(const char *s1, const char *s2, size_t len) { return __lib_strncasecmp(s1, s1, len); } in the decompressor versus a real full implementation. --------------eWVLiKb8hW4mlc5kPUXDDJhx Content-Type: text/x-patch; charset=UTF-8; name="lib-header.patch" Content-Disposition: attachment; filename="lib-header.patch" Content-Transfer-Encoding: base64 Y29tbWl0IGQ5NGZhNjg0MmIyNTgwOTk1ODkwM2ZkZDMzZDQ5OGJiNjIyNjk1YTUKQXV0aG9y OiBEYXZlIEhhbnNlbiA8ZGF2ZS5oYW5zZW5AbGludXguaW50ZWwuY29tPgpEYXRlOiAgIFR1 ZSBBcHIgMTkgMDk6MzE6MDcgMjAyMiAtMDcwMAoKICAgIGZvbwogICAgCiAgICBiYXIxCgpk aWZmIC0tZ2l0IGEvbGliL3N0cmluZy1pbnRlcm5hbC5oIGIvbGliL3N0cmluZy1pbnRlcm5h bC5oCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwMC4uMjMwYzIyODY0 Yjc1Ci0tLSAvZGV2L251bGwKKysrIGIvbGliL3N0cmluZy1pbnRlcm5hbC5oCkBAIC0wLDAg KzEsMzEgQEAKKyNpbmNsdWRlIDxsaW51eC9jdHlwZS5oPgorCisvKioKKyAqIHN0cm5jYXNl Y21wIC0gQ2FzZSBpbnNlbnNpdGl2ZSwgbGVuZ3RoLWxpbWl0ZWQgc3RyaW5nIGNvbXBhcmlz b24KKyAqIEBzMTogT25lIHN0cmluZworICogQHMyOiBUaGUgb3RoZXIgc3RyaW5nCisgKiBA bGVuOiB0aGUgbWF4aW11bSBudW1iZXIgb2YgY2hhcmFjdGVycyB0byBjb21wYXJlCisgKi8K K3N0YXRpYyBpbmxpbmUgaW50IF9fbGliX3N0cm5jYXNlY21wKGNvbnN0IGNoYXIgKnMxLCBj b25zdCBjaGFyICpzMiwgc2l6ZV90IGxlbikKK3sKKwkvKiBZZXMsIFZpcmdpbmlhLCBpdCBo YWQgYmV0dGVyIGJlIHVuc2lnbmVkICovCisJdW5zaWduZWQgY2hhciBjMSwgYzI7CisKKwlp ZiAoIWxlbikKKwkJcmV0dXJuIDA7CisKKwlkbyB7CisJCWMxID0gKnMxKys7CisJCWMyID0g KnMyKys7CisJCWlmICghYzEgfHwgIWMyKQorCQkJYnJlYWs7CisJCWlmIChjMSA9PSBjMikK KwkJCWNvbnRpbnVlOworCQljMSA9IHRvbG93ZXIoYzEpOworCQljMiA9IHRvbG93ZXIoYzIp OworCQlpZiAoYzEgIT0gYzIpCisJCQlicmVhazsKKwl9IHdoaWxlICgtLWxlbik7CisJcmV0 dXJuIChpbnQpYzEgLSAoaW50KWMyOworfQorI2VuZGlmCmRpZmYgLS1naXQgYS9saWIvc3Ry aW5nLmMgYi9saWIvc3RyaW5nLmMKaW5kZXggNDg1Nzc3YzlkYTgzLi43MDViNzk5ZTNiNWMg MTAwNjQ0Ci0tLSBhL2xpYi9zdHJpbmcuYworKysgYi9saWIvc3RyaW5nLmMKQEAgLTI5LDYg KzI5LDcgQEAKICNpbmNsdWRlIDxhc20vd29yZC1hdC1hLXRpbWUuaD4KICNpbmNsdWRlIDxh c20vcGFnZS5oPgogCisjaW5jbHVkZSAic3RyaW5nLWludGVybmFsLmgiCiAjaWZuZGVmIF9f SEFWRV9BUkNIX1NUUk5DQVNFQ01QCiAvKioKICAqIHN0cm5jYXNlY21wIC0gQ2FzZSBpbnNl bnNpdGl2ZSwgbGVuZ3RoLWxpbWl0ZWQgc3RyaW5nIGNvbXBhcmlzb24KQEAgLTM4LDI1ICsz OSw3IEBACiAgKi8KIGludCBzdHJuY2FzZWNtcChjb25zdCBjaGFyICpzMSwgY29uc3QgY2hh ciAqczIsIHNpemVfdCBsZW4pCiB7Ci0JLyogWWVzLCBWaXJnaW5pYSwgaXQgaGFkIGJldHRl ciBiZSB1bnNpZ25lZCAqLwotCXVuc2lnbmVkIGNoYXIgYzEsIGMyOwotCi0JaWYgKCFsZW4p Ci0JCXJldHVybiAwOwotCi0JZG8gewotCQljMSA9ICpzMSsrOwotCQljMiA9ICpzMisrOwot CQlpZiAoIWMxIHx8ICFjMikKLQkJCWJyZWFrOwotCQlpZiAoYzEgPT0gYzIpCi0JCQljb250 aW51ZTsKLQkJYzEgPSB0b2xvd2VyKGMxKTsKLQkJYzIgPSB0b2xvd2VyKGMyKTsKLQkJaWYg KGMxICE9IGMyKQotCQkJYnJlYWs7Ci0JfSB3aGlsZSAoLS1sZW4pOwotCXJldHVybiAoaW50 KWMxIC0gKGludCljMjsKKwlyZXR1cm4gX19saWJfc3RybmNhc2VjbXAoczEsIHMxLCBsZW4p OwogfQogRVhQT1JUX1NZTUJPTChzdHJuY2FzZWNtcCk7CiAjZW5kaWYK --------------eWVLiKb8hW4mlc5kPUXDDJhx--