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 DF06EC433FE for ; Thu, 20 Jan 2022 02:08:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43B316B007D; Wed, 19 Jan 2022 21:08:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EB686B007E; Wed, 19 Jan 2022 21:08:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B2AF6B0080; Wed, 19 Jan 2022 21:08:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id 1BE716B007D for ; Wed, 19 Jan 2022 21:08:01 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C9C72181CB2CC for ; Thu, 20 Jan 2022 02:08:00 +0000 (UTC) X-FDA: 79049029920.11.0898628 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf26.hostedemail.com (Postfix) with ESMTP id 52318140035 for ; Thu, 20 Jan 2022 02:08:00 +0000 (UTC) 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 ams.source.kernel.org (Postfix) with ESMTPS id 3431AB81C96; Thu, 20 Jan 2022 02:07:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2F20C340E4; Thu, 20 Jan 2022 02:07:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1642644478; bh=oXTiz8bgm2yyRMJ9IjFGvVMYI9DBH4p4inEGj6yoaMU=; h=Date:From:To:Subject:In-Reply-To:From; b=yhNwuacDw7oNdeWaQpMKQzTDTYiGfKHO+rxqL6vsWcWhyZ16JfoXbAddTR9rkBsk3 cnUxXDS87onZd3bb0a/Atv6Ce+3wdV32A+pJn0U6sGu+Betzm2euEVuGP1ft93H94m dIrpiKa1rdkDycUV85tnwmf9LtewKrWLMJ7Sr3yU= Date: Wed, 19 Jan 2022 18:07:57 -0800 From: Andrew Morton To: akpm@linux-foundation.org, bhe@redhat.com, david@redhat.com, dyoung@redhat.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, prudo@redhat.com, torvalds@linux-foundation.org, vgoyal@redhat.com Subject: [patch 05/55] proc/vmcore: don't fake reading zeroes on surprise vmcore_cb unregistration Message-ID: <20220120020757.dOiHTk8NT%akpm@linux-foundation.org> In-Reply-To: <20220119180714.9e187ce100e4510de3cd9f7d@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 52318140035 X-Stat-Signature: pcumzksan795799ra5sm5h1wzqxnnkiw Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=yhNwuacD; spf=pass (imf26.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1642644480-30383 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: David Hildenbrand Subject: proc/vmcore: don't fake reading zeroes on surprise vmcore_cb unregistration In commit cc5f2704c934 ("proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks"), we added detection of surprise vmcore_cb unregistration after the vmcore was already opened. Once detected, we warn the user and simulate reading zeroes from that point on when accessing the vmcore. The basic reason was that unexpected unregistration, for example, by manually unbinding a driver from a device after opening the vmcore, is not supported and could result in reading oldmem the vmcore_cb would have actually prohibited while registered. However, something like that can similarly be trigger by a user that's really looking for trouble simply by unbinding the relevant driver before opening the vmcore -- or by disallowing loading the driver in the first place. So it's actually of limited help. Currently, unregistration can only be triggered via virtio-mem when manually unbinding the driver from the device inside the VM; there is no way to trigger it from the hypervisor, as hypervisors don't allow for unplugging virtio-mem devices -- ripping out system RAM from a VM without coordination with the guest is usually not a good idea. The important part is that unbinding the driver and unregistering the vmcore_cb while concurrently reading the vmcore won't crash the system, and that is handled by the rwsem. To make the mechanism more future proof, let's remove the "read zero" part, but leave the warning in place. For example, we could have a future driver (like virtio-balloon) that will contact the hypervisor to figure out if we already populated a page for a given PFN. Hotunplugging such a device and consequently unregistering the vmcore_cb could be triggered from the hypervisor without harming the system even while kdump is running. In that case, we don't want to silently end up with a vmcore that contains wrong data, because the user inside the VM might be unaware of the hypervisor action and might easily miss the warning in the log. Link: https://lkml.kernel.org/r/20211111192243.22002-1-david@redhat.com Signed-off-by: David Hildenbrand Acked-by: Baoquan He Cc: Dave Young Cc: Vivek Goyal Cc: Philipp Rudo Signed-off-by: Andrew Morton --- fs/proc/vmcore.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) --- a/fs/proc/vmcore.c~proc-vmcore-dont-fake-reading-zeroes-on-surprise-vmcore_cb-unregistration +++ a/fs/proc/vmcore.c @@ -65,8 +65,6 @@ static size_t vmcoredd_orig_sz; static DECLARE_RWSEM(vmcore_cb_rwsem); /* List of registered vmcore callbacks. */ static LIST_HEAD(vmcore_cb_list); -/* Whether we had a surprise unregistration of a callback. */ -static bool vmcore_cb_unstable; /* Whether the vmcore has been opened once. */ static bool vmcore_opened; @@ -94,10 +92,8 @@ void unregister_vmcore_cb(struct vmcore_ * very unusual (e.g., forced driver removal), but we cannot stop * unregistering. */ - if (vmcore_opened) { + if (vmcore_opened) pr_warn_once("Unexpected vmcore callback unregistration\n"); - vmcore_cb_unstable = true; - } up_write(&vmcore_cb_rwsem); } EXPORT_SYMBOL_GPL(unregister_vmcore_cb); @@ -108,8 +104,6 @@ static bool pfn_is_ram(unsigned long pfn bool ret = true; lockdep_assert_held_read(&vmcore_cb_rwsem); - if (unlikely(vmcore_cb_unstable)) - return false; list_for_each_entry(cb, &vmcore_cb_list, next) { if (unlikely(!cb->pfn_is_ram)) @@ -581,7 +575,7 @@ static int vmcore_remap_oldmem_pfn(struc * looping over all pages without a reason. */ down_read(&vmcore_cb_rwsem); - if (!list_empty(&vmcore_cb_list) || vmcore_cb_unstable) + if (!list_empty(&vmcore_cb_list)) ret = remap_oldmem_pfn_checked(vma, from, pfn, size, prot); else ret = remap_oldmem_pfn_range(vma, from, pfn, size, prot); _