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 F355DEC8745 for ; Thu, 7 Sep 2023 15:51:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 367AA8E0005; Thu, 7 Sep 2023 11:51:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 315B78E0001; Thu, 7 Sep 2023 11:51:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B57F8E0005; Thu, 7 Sep 2023 11:51:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0878D8E0001 for ; Thu, 7 Sep 2023 11:51:33 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AA7CD802E7 for ; Thu, 7 Sep 2023 15:51:32 +0000 (UTC) X-FDA: 81210241224.01.E61D525 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) by imf21.hostedemail.com (Postfix) with ESMTP id 6A17D1C0021 for ; Thu, 7 Sep 2023 15:51:27 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZpM3alFb; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf21.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694101890; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=L2dmd+nbo3rIDFah26q10/xEjd97odAK4oF9WTDFIyE=; b=wU8TLQ0tL0TZeZO9+oXPsgAPRJBMzP52XKOhrjyUsHqPEKr51RZH8G16bhUGwvm4/hM4CC eNy8wSO7CHGYbwpDCo8z5lhGmKZbuaq2aH918XlPEKZ3Xoqrv0aCoIys6j39WflC0m7/0M 2im9N62HLmJb94UNq5VADYJ8zwamiRg= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZpM3alFb; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf21.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694101890; a=rsa-sha256; cv=none; b=FepJANZzFdkU4oqu3l4Bc2+g0LEeyThCJiidd7WZIq0OkXp1izt2QwCyKFbjUhZX6QEYYY q84EMCmIQ3zzQ8Ep2jJtzCYrQcIcBAo24dolayhHOXywJX8ljeX8zdNdRyAIlf/UzN+wt/ Z1mktit7u/DhrUuEZCDtxyTvhT7yf2A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694101887; x=1725637887; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=6EsGUJGhX1zT+Uyl+vPXWvJ0hitAvo76hypLco20y4Y=; b=ZpM3alFbZSsprvtGsLkuMV2Ezo5AZEe4q4JtzTAYUCTx8VDD8Q7dm56W MOQHwXhqmMqORBR09N0av2P+9FZf6E444kfk/VdAX9AQ7i6LmeyUGwEy9 0w80Hys8tCiEK3xC0dTfWXyeVACmTe/393x32hYv64+askNpiru7/kdvv PW+xPnUH8rD58TvFagywZ31i72hgplyE0KR6w31KMsrS63KdOXE50XA0p ygdVT1YtZEC6Gn54Zc1L2IWdpMuk3IolNDkDcbSrN+f0SKL/rMiBKUidv eTVwZzX9nMStmRYeR/zHxt+vt/IDgFUYDCE3TWPGLX9mpaiOeWXfmf4u6 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10826"; a="408388041" X-IronPort-AV: E=Sophos;i="6.02,235,1688454000"; d="scan'208";a="408388041" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2023 08:51:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10826"; a="915793424" X-IronPort-AV: E=Sophos;i="6.02,235,1688454000"; d="scan'208";a="915793424" Received: from ningle-mobl2.amr.corp.intel.com (HELO [10.209.13.77]) ([10.209.13.77]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2023 08:51:06 -0700 Message-ID: <5a188bb6-add4-0522-069f-18fbd34aff16@intel.com> Date: Thu, 7 Sep 2023 08:51:06 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH 1/3] proc/vmcore: Do not map unaccepted memory Content-Language: en-US To: Adrian Hunter , "Kirill A. Shutemov" , Borislav Petkov , Andrew Morton Cc: Vlastimil Babka , Mike Rapoport , Lorenzo Stoakes , Tom Lendacky , Baoquan He , Vivek Goyal , Dave Young , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, kexec@lists.infradead.org References: <20230906073902.4229-1-adrian.hunter@intel.com> <20230906073902.4229-2-adrian.hunter@intel.com> <21bf2e44-3316-2372-44cb-1488f88650f5@intel.com> <30d0cebb-13f9-572e-9baa-b7450fec9108@intel.com> From: Dave Hansen In-Reply-To: <30d0cebb-13f9-572e-9baa-b7450fec9108@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 6A17D1C0021 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: re6cno5czauc4mnuiq3ytnaizzd6pn9n X-HE-Tag: 1694101887-659180 X-HE-Meta: U2FsdGVkX1/cxLucLDSpNaCmAHBpYKUZPWD7swUZ/7TlhulyeSI+0Fg5NKHrX4bPy4wVU0tIMV/61t8q1wqzGMbepHPEdaKV0UdoxPxd9EBcBSJ1boCKbz9h/R9hJFBoQMl/N+vP7FBBrMLOeJd+EwsimyY/NpiVbfAJgDRBAqRT3FdEqLEMDqY4QHdTCqBPmjtrrf/CwZ0CTdq16ZreLOtJk+9qSZxSvRr3hS1B78e3aN7SCI97/zIMj8Yy3OkRCaS6o+++ridpIP+ffSP//0j6ZsPjE1MKm6J3/wZ7IYc13gsxElhUbDda8yi65NpXrIm39NwnBXkBpva6Y28IO8fg2I/NUxR/WRkLilhWN9Vwb20HNMUUXOW7vh/mgm9iHwpflE+K4jjjq6CHBQnisMcYRNYI9RIYr/ZO/kE2cLzVgLCfYtuztLSC+YKIOskYinWDg7pgUG3NQCcwO7vA3gaNkv48+0r1jNZ+iQgBeneHkXgW7ndQAOWDBoDiRR8x4DySYButm9nuaUVtq09B4+g6k4OnyMywEdFPFEJmHzu6RXOdUspneCWrfknudGeFwhX98PbYChIRRp+4zMvB7N2bDTvh/rGtQyi0eqixBdD5yJtKd/c8UML33R8Wn2mzTEWk40mvxyYfgHTdyQD/C3ZBjwKcruiWkp+cD06amxnIOR2F2dqEFKW/jMlPsQ2W6Ku8BIsuZD2gPD7vnzmCz8Omsp6oAfgNw9gNQuJE0HZ6pC4TuCPa4PgJEd1+qkQNDs5jkWgrmmo2C7v9X2w4x39LiCj4BhxMEo2umL6dxnipu+rXviAbyHft3Z8IGPprA+pSYfOhocWh4nFOE4/+2gC2D4Xtil42OksF8Au6D8dVuZ83O49Js1Q984JMcbITCwK/jN3C6nEdQE23Z8rcy49SW8zxF/aXN1cqWqoWdH7pmAcLSpY6P4FTcT69cjm4CzmyNqPHNciOvgZBaUy 8WzxQ7P2 KQJlg6kijzEqaYS7qk6HmOlgALlcgQWWCZzlKn7bNFklH6qmydNcToG5l+E/wPUFNgXkEo/ZKRzXLpyvRidAc5cGJe2aWzEXy0DeUqQRYvre3o+NSnSZIhc4gSZkkySLROSPoM7WBlIETHy4= 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 9/7/23 08:44, Adrian Hunter wrote: > On 7/09/23 18:39, Dave Hansen wrote: >> On 9/6/23 00:39, Adrian Hunter wrote: >>> @@ -559,7 +567,8 @@ static int vmcore_remap_oldmem_pfn(struct vm_area_struct *vma, >>> * pages without a reason. >>> */ >>> idx = srcu_read_lock(&vmcore_cb_srcu); >>> - if (!list_empty(&vmcore_cb_list)) >>> + if (!list_empty(&vmcore_cb_list) || >>> + range_contains_unaccepted_memory(paddr, paddr + size)) >>> ret = remap_oldmem_pfn_checked(vma, from, pfn, size, prot); >>> else >>> ret = remap_oldmem_pfn_range(vma, from, pfn, size, prot); >> The whole callback mechanism which fs/proc/vmcore.c::pfn_is_ram() >> implements seems to be in place to ensure that there aren't a billion >> different "ram" checks in here. >> >> Is there a reason you can't register_vmcore_cb() a callback to check for >> unaccepted memory? > Someone asked for the change to be in arch-independent code... 😉 That doesn't really answer my question. virtio_mem_init_kdump(), for instance, is in arch-independent code.