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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7DECC433EF for ; Fri, 12 Nov 2021 08:28:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5B74360F46 for ; Fri, 12 Nov 2021 08:28:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5B74360F46 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CE4EA6B0074; Fri, 12 Nov 2021 03:28:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C94646B0078; Fri, 12 Nov 2021 03:28:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5D0F6B007B; Fri, 12 Nov 2021 03:28:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id A50086B0074 for ; Fri, 12 Nov 2021 03:28:26 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 637B11809F349 for ; Fri, 12 Nov 2021 08:28:26 +0000 (UTC) X-FDA: 78799601412.25.9818976 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id EBEC8900026E for ; Fri, 12 Nov 2021 08:28:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636705694; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MMC8qd8+7Ca3YzZrzMvAHcyUG/VYuDrlF+fpPBuOn/k=; b=QHpqogOEJl+NT7hcKfj1v+FGyKLSoO8+oZc3fV/YWtz94/rE8UY587liM+GDS/u002sS/2 M5pF71uRrauo1hzNdBfovlpSSEllco8ulF+kDpflQHrSylO53yX4GOlaDje17A3S08qvpk s7dIZ5fjZrsmy2B61Dddedsv6slWW6c= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-383--ZZ-cMb0OfmQB3NNaZOd9g-1; Fri, 12 Nov 2021 03:28:11 -0500 X-MC-Unique: -ZZ-cMb0OfmQB3NNaZOd9g-1 Received: by mail-wm1-f69.google.com with SMTP id k25-20020a05600c1c9900b00332f798ba1dso5964427wms.4 for ; Fri, 12 Nov 2021 00:28:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=MMC8qd8+7Ca3YzZrzMvAHcyUG/VYuDrlF+fpPBuOn/k=; b=bumpa0m0BIrmGRz+U8nmvSswKjSP0gUTrtqoYMt0J0HpXsZ9gL+F21l0EPZ25nUU+S agyOSnUjdmq2mdyJkXRaB/YHjvtwMctXLeGGH3mwbCfJieOCdNSoBlb3iZlosfyXNJD3 N7vowsKQvpe0JwmjcYIj5/5jt2cnA8gknVHP9qdcF/EbIDnV9B1vb2TDbBZw+gWEs4qA ENtkk+54+dy5hnwXkCHLgHfPyaoOUvlJEowcsF2maULO2USHxHfHPsWz3GMOSathpdm+ xikmcp8eTlV/ixqD3T4hFEoEQCLaf6L1Ok2Z3ctDLKLiK7gCQpp8clcYg4bOEWp1W5If I/2w== X-Gm-Message-State: AOAM533Kxwx0Rnj5qH0FtsE9vopI5bD4AO/H9IuhppXpFYWmLNeam2WC L0zafJsdKxKS7nOqJF2SrQ7RqZqHi4xs2Bc/SUY8Te8+NJ0esxiM1LHz7vbMzLzrAgtw0CP8rGi Qa5/i0dkqXNU= X-Received: by 2002:a05:600c:4fca:: with SMTP id o10mr15121521wmq.175.1636705690191; Fri, 12 Nov 2021 00:28:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJwH8UrEY9r4Zje19aA2qqBcbz8L5l097Cntjyi4QFVNg8xl1fM/LhGyVqNJE+EScdUvyPHnHw== X-Received: by 2002:a05:600c:4fca:: with SMTP id o10mr15121486wmq.175.1636705689955; Fri, 12 Nov 2021 00:28:09 -0800 (PST) Received: from [192.168.3.132] (p4ff23f5f.dip0.t-ipconnect.de. [79.242.63.95]) by smtp.gmail.com with ESMTPSA id g5sm8146127wri.45.2021.11.12.00.28.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Nov 2021 00:28:09 -0800 (PST) Message-ID: Date: Fri, 12 Nov 2021 09:28:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 To: Baoquan He Cc: linux-kernel@vger.kernel.org, Dave Young , Vivek Goyal , Andrew Morton , Philipp Rudo , kexec@lists.infradead.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org References: <20211111192243.22002-1-david@redhat.com> <20211112033028.GP27625@MiWiFi-R3L-srv> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v1] proc/vmcore: don't fake reading zeroes on surprise vmcore_cb unregistration In-Reply-To: <20211112033028.GP27625@MiWiFi-R3L-srv> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: EBEC8900026E X-Stat-Signature: qopx7p9gtpnefw4bdsxpaaxodwcwx9b1 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QHpqogOE; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf29.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1636705696-470813 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 12.11.21 04:30, Baoquan He wrote: > On 11/11/21 at 08:22pm, David Hildenbrand wrote: >> 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. > > Yes, this is the change what I would like to see in the original patch > "proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks". > I am happy with this patch appended to commit cc5f2704c934. Good, thanks! > >> >> 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 > > I am a little confused, could you tell more about "contact the hypervisor to > figure out if we already populated a page for a given PFN."? I think > vmcore dumping relies on the eflcorehdr which is created beforehand, and > relies on vmcore_cb registered in advance too, virtio-balloon could take > another way to interact with kdump to make sure the dumpable ram? This is essentially what the XEN callback does: check if a PFN is actually populated in the hypervisor; if not, avoid reading it so we won't be faulting+populating a fresh/zero page in the hypervisor just to be able to dump it in the guest. But in the XEN world we usually simply rely on straight hypercalls, not glued to actual devices that can get hot(un)plugged. Once you have some device that performs such checks instead that could get hotunplugged and unregister the vmcore_cb (and virtio-balloon is just one example), you would be able to trigger this. As we're dealing with a moving target (hypervisor will populate pages as necessary once the old kernel accesses them), there isn't really a way to adjust this in the old kernel -- where we build the eflcorehdr. We could try to adjust the elfcorehdr in the new kernel, but that certainly opens up another can of worms. But again, this is just an example to back the "future proof" claim because Dave was explicitly concerned about this situation. -- Thanks, David / dhildenb