From patchwork Mon May 15 08:34:00 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 13240957 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 11291C77B7D for ; Mon, 15 May 2023 08:34:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 97FF0900003; Mon, 15 May 2023 04:34:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 92FEF900002; Mon, 15 May 2023 04:34:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81EB0900003; Mon, 15 May 2023 04:34:16 -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 73E9C900002 for ; Mon, 15 May 2023 04:34:16 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 230C01A1382 for ; Mon, 15 May 2023 08:34:16 +0000 (UTC) X-FDA: 80791827312.18.199DE5C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 823F840008 for ; Mon, 15 May 2023 08:34:14 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=saSSWqFN; spf=pass (imf04.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684139654; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=SSTWFDRqAB+fp/I7s0r4QdFBu/0VpGF1K49FOZeZ6bg=; b=M6bgZ3BsDDsSvt5IyaK7XkVO4kFiIW4OZh7BoWCZaIV4sEJX3fW2GsFYYRD3Wzw0b/3YZn Nspp+7hodzXk8gdauN0qc6cEGsmqiiCVYCZK8TgSa+zk0CUSJx+41mUMQqeZ+yS4QbGkNC EAtNOf51cniI/qMkNsE+wBS4KEXA/gA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684139654; a=rsa-sha256; cv=none; b=0Vmelnmrfjm05A8Fon2Jo8bZuK267yd8CIVwqeJgAxR5kbnL7fPGTh7i2G4u8wfHDGwdcM SHUvZjFI4zAErZpAzFKq/AJE0nVYBljqWUUkuHVlsfssDTnJfPW1aM3yRf9YabUQPA38ZT DOIPM9mN9dfLgI6oTyNC5c+0sC6THFs= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=saSSWqFN; spf=pass (imf04.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 49B086104F; Mon, 15 May 2023 08:34:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58A18C433D2; Mon, 15 May 2023 08:34:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684139652; bh=b5jfUGBb8JJ/0NiF7GCWAxiRgd25Y0crY5ZrPs7w7U0=; h=From:To:Cc:Subject:Date:From; b=saSSWqFNR5BBz2qvQ6WJCQigMj4d1IVXs15OGzWM0ICdrmZHIBTHwb8VCL6biv5Xf b4Pi/8czfxY3R1h4FfxXzWbBbx1m2fHt5FzDlOXKTzTQS1qEv6q4ibaLk5VdO8M0+X Y0EM+dB5RnwPzUgBoozTV6CPM4HZJCKTPkOE3FCokiSPu5lTU7I1C2RazKtyM5DfKW CLPNWtBYL7knMOag/MkGj9o6wkVU3//CQrERJSwphud9O95D2aFx09l22o4FgGhWOF 6NNFefyu1pxhjmnHRXuPKTxgx6USykhQw76NgfulBhf0fwluQpZP+8Sk59Di8VIhjS SNN47HdBSNSyQ== From: Mike Rapoport To: Andrew Morton Cc: Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] mm/secretmem: make it on by default Date: Mon, 15 May 2023 11:34:00 +0300 Message-Id: <20230515083400.3563974-1-rppt@kernel.org> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 823F840008 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: effehat1pqq51gk3zti3iwccbwf7a9co X-HE-Tag: 1684139654-919948 X-HE-Meta: U2FsdGVkX1+1i3phc+Hxf7EkIz/dk3deKuem6vpvDGmUQpAB/+O+ipYW/Nwal1Q9QGHukk3w3B5cJ9pFTwjcEjXWQ7fw/zrTiRZb84bIX9jrDyr/LadYA4ztMWMJgpMADpieob1TjLSz/fm1SJ2t986ad8wfXoYKKi95uWiyqaNHaGuAzQU+bk1NTSYzdmUNTu2hup2wwbABbSUc1D1PoRVxHGuoluR53riL/QJw8FNJuBBmh/hOH/vnE0BJsTKPlYhyKN9taLg1sR5uYENTj6zWTaSVuoEEnIeCmBbTVDcWCx2Sm1V4FW4aarAYTzeCprHNayeeypwl5Sx9ybz0j4XabKDfYWlms3C9Tu12peOz/lbkenVk8Pm8PiXxEJtZS1Gl8XxNff8pnvymcotmMOggm59y4xg/oAsRB18mKi3SxVWjvvQFiTE1ZwHEEVumlMdPc9cLDqFymIPBvrjIso6xWV5u1Qi9S/pmr1Panmgq6vFmNUn+PIWy773T4N5Y0n+vvU206/lEkLRUij8hhNxSuJAGoxPOrkp002euIRmTRzUfxvzWCvcj4lRofQzcJIVrAzzGt/CUu1qlj718PnbDGj5jF1Ao/iZp2F67S7etZWy16t4zR5zP0We3N7S7YKryLX1xnGJRZ3ofwY5ZKtksch+d67pk8iJd+U5MIZWE5ecs/xhRFRB1GYBBsWUNDhSNCwQQO0e/2aggXU5EVcqUE+YTouquqgBc6a9PHQxVZBusq0nRWvEBKPzjAHUfFlab3pAyPpxEbn1ZjGHRiJA0MDr6kUUpVeN8O0oOyugSGG+JlGX8DeiXDwHswYUmR80GLUe2qbdkhz8lHWb1Dm6vUGECpajaLs7I9KTNal5xQO2Ao6ubc+UE6Bq/1pdBJBY6V8kHDlSPqwxA0SX8EuN3JGVWrfMjqwwyP9H+/tEezx6h5kFYNX7cE7FI4nteOdUadzSy9b36H3gXVlr BLwIWUWb 4CRbM69DjbPtkuOmXlVl4+/Tqtm1BI7pGUnMNMesUmPsMIuz4OAr+VyZMvJj8Q9MQI9tq4qZpdACrbYGqt2rWuKzsg4P33iczEsYkEL6g0o+0Eq7LPPMi87pysRv0j4+1yZKs+g0P8jb/VoTJVb2NGPOBHbTY8eXyNAYofm99OC2eClwc4ASsjS5MuTPBA34Aea87EvUnjB33d4G5oF3LfkbVZysj0Tt5DMhqoE4/dvDiU6Mc2t/cMsSnbf9srARSUnpI9inUWutUXR1NMKO1wR9Z3tZHMtRleWFUJbBYmxwkCiVTe3kSw983kQsG/lmpiXNivv5X1P/74YmmCPS+hfHTYgSbe3b+NPvxT0S5BTl/eI18Ratd7cRgip6docPQemtfF/oChUjiCtg= 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: From: "Mike Rapoport (IBM)" Following the discussion about direct map fragmentaion at LSF/MM [1], it appears that direct map fragmentation has a negligible effect on kernel data accesses. Since the only reason that warranted secretmem to be disabled by default was concern about performance regression caused by the direct map fragmentation, it makes perfect sense to lift this restriction and make secretmem enabled. secretmem obeys RLIMIT_MEMBLOCK and as such it is not expected to cause large fragmentation of the direct map or meaningfull increase in page tables allocated during split of the large mappings in the direct map. The secretmem.enable parameter is retained to allow system administrators to disable secretmem at boot. Switch the default setting of secretem.enable parameter to 1. Link: https://lwn.net/Articles/931406/ [1] Signed-off-by: Mike Rapoport (IBM) Acked-by: David Hildenbrand --- mm/secretmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/secretmem.c b/mm/secretmem.c index 0b502625cd30..974b32ba8b9d 100644 --- a/mm/secretmem.c +++ b/mm/secretmem.c @@ -35,7 +35,7 @@ #define SECRETMEM_MODE_MASK (0x0) #define SECRETMEM_FLAGS_MASK SECRETMEM_MODE_MASK -static bool secretmem_enable __ro_after_init; +static bool secretmem_enable __ro_after_init = 1; module_param_named(enable, secretmem_enable, bool, 0400); MODULE_PARM_DESC(secretmem_enable, "Enable secretmem and memfd_secret(2) system call");