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 045A2C433F5 for ; Wed, 10 Nov 2021 12:06:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8F33E61241 for ; Wed, 10 Nov 2021 12:06:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8F33E61241 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 DC1916B006C; Wed, 10 Nov 2021 07:06:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D702B6B0071; Wed, 10 Nov 2021 07:06:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C38546B0072; Wed, 10 Nov 2021 07:06:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id B5CA66B006C for ; Wed, 10 Nov 2021 07:06:07 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6490F184F7976 for ; Wed, 10 Nov 2021 12:06:07 +0000 (UTC) X-FDA: 78792892374.31.D73B592 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 981C43000243 for ; Wed, 10 Nov 2021 12:05:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636545965; 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=GJti6YTXwzSdmRtUdfCdrEUOOwHBKjcMSceqtv5gbd4=; b=KD/4O6PVX3TqyJt7ME5DX84ryvHKB6ymXHkC+Od7bG7ejwj7gsNFf3OVFGxPQSypWxGckx gy3rE3yGVaH6J9G5J+rOEIKEVfC4PEnNml57oPLCSjsr7OVMUf2ARb/yFGvN2+JXeILlKz QPuH31VLW65gy9kKqwpL0AnNvmMzZAU= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-108-EklN-dS7Mteom7tlT7LE_A-1; Wed, 10 Nov 2021 07:06:02 -0500 X-MC-Unique: EklN-dS7Mteom7tlT7LE_A-1 Received: by mail-wm1-f71.google.com with SMTP id b133-20020a1c808b000000b0032cdd691994so3006476wmd.1 for ; Wed, 10 Nov 2021 04:06:02 -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=GJti6YTXwzSdmRtUdfCdrEUOOwHBKjcMSceqtv5gbd4=; b=T0btsBLWAS+n7dibqiutG6fLq6X4lrUb20Yz0j4qbT16IQ71leF3v52CPHgwpCRNt3 eONPKfVqN9syqMNa1ckni3FRM7uffBTKS3MCD4IFhytwXQ+J5VUlv1L42ArZkUBaXCwq XfT2v5do+MKPqJABwPaXcpR0pxznJIXtQ7DCDL4KvYKporsoqqTbdwEdZxRyiwS+p6Mo 6z/TmWVoGxn+Ab1jEOIVkz1QnAdsaDttB+w0jYoF23SbCUjWZokSSPoT7YuzykJ6VTJa v9QHMNmeiDRVE3t1DdkB1Qbiom7ycqRH3LCsUqhDPFzjJPoGi36cgTQSOXOfwIvXqmBy bEkQ== X-Gm-Message-State: AOAM531DU1r7ZTEuj+/d37aukbX/Pm0UeiMKIf9BoWgmvYmFMjCtPdqE 8NKzT6ZHkGQM71kFNRmP1Cg0RqReXh1gvb7arplmxLtShMxUDvkMnd2xSRYzQvcp852ujOojWIH uXmXFhKAyP5o= X-Received: by 2002:adf:e78c:: with SMTP id n12mr19011332wrm.83.1636545961742; Wed, 10 Nov 2021 04:06:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJwEcRyg9FrnXNxxKvjSKAzxVbukmqesRvVHyR22T35GZHU30Y7sLqr+vCuZAKlzoj/WR8KtiA== X-Received: by 2002:adf:e78c:: with SMTP id n12mr19011265wrm.83.1636545961442; Wed, 10 Nov 2021 04:06:01 -0800 (PST) Received: from [192.168.3.132] (p5b0c604f.dip0.t-ipconnect.de. [91.12.96.79]) by smtp.gmail.com with ESMTPSA id p12sm27279180wrr.10.2021.11.10.04.05.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Nov 2021 04:05:55 -0800 (PST) Message-ID: <0c83cb5b-20e0-31cb-b3bf-82d3ca30e08b@redhat.com> Date: Wed, 10 Nov 2021 13:05:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 To: Dave Young Cc: Baoquan He , boris.ostrovsky@oracle.com, bp@alien8.de, Andrew Morton , hpa@zytor.com, jasowang@redhat.com, jgross@suse.com, linux-mm@kvack.org, mhocko@suse.com, mingo@redhat.com, mm-commits@vger.kernel.org, mst@redhat.com, osalvador@suse.de, rafael.j.wysocki@intel.com, rppt@kernel.org, sstabellini@kernel.org, tglx@linutronix.de, torvalds@linux-foundation.org, vgoyal@redhat.com References: <20211108183057.809e428e841088b657a975ec@linux-foundation.org> <20211109023148.b1OlyuiXG%akpm@linux-foundation.org> <20211110072225.GA18768@MiWiFi-R3L-srv> <0c68b366-38f4-94fd-da11-57e40a44cb48@redhat.com> <1cbc6332-8a45-3af1-c648-99437819bb5a@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [patch 08/87] proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks In-Reply-To: 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: rspam01 X-Rspamd-Queue-Id: 981C43000243 X-Stat-Signature: 58fihyaogqk5edkpospq4onupju1eukh Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="KD/4O6PV"; spf=none (imf08.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1636545952-457451 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: >> "remaining vmcore is zeroed that it is bad and not acceptable for kdump." >> >> Which scenario are you concerned about? User space plays stupid games >> (unbining a driver from a virtio-mem device in a *kdump kernel* after >> opening /proc/vmcore) and wins stupid prices (a warning and a vmcore >> filled (partially) with zeroes). Why isn't a warning sufficient for >> something like that? > > Hi David, > > Suppose we have the use case below: > Hi Dave, thanks for elaborating, it helps a lot to understand your concerns. > A user plays with the game (Probably in hypervisor part, but the user is > not aware that the guest panicked and in a kdump kernel), then we get a > zeroed vmcore. But the panic can not be easily reproduced any more, > then the warning is not useful. I can only speak about virtio-mem (well, that's the only current known "dynamic vmcore_cb registration" user :) ). virtio-mem devices cannot get hotunplugged in the hypervisor (i.e., QEMU)-- you can only hot(un)plug device memory, but not the device itself, it will stick around. Hotunplugging the device is completely blocked and not supported. The reason is simple: unplugging a virtio-mem device will also remove the device memory. It's similar to other memory devices, such as DIMMs -- I would not recommend forced, physical removal of a DIMM to anybody -- not while the OS is running and not while kdump is saving /proc/vmcore. Which is also the reason why hypervisors don't generally support forced removal of such devices. :) So for the currently known vmcore_cb users, hypervisor action cannot result in driver unbinding and consequently vmcore_cb changes. Note: virtio-mem-pci devices might eventually get hotplugged while kdump is active. I assume we don't disable PCI hotplug in kdump kernels. While this will trigger a warning ("Unexpected vmcore callback registration"), the vmcore will not be affected and be complete. > > But if you think user is playing the game in kdump kernel, eg. in guest > os while kdump is saving vmcore then it is nearly not possible to happen > I agree with you it is a very trival problem. Yes, that's the only thing I consider can happen. For example, doing a: # echo 1 > /sys/devices/pci0000\:00/0000\:00\:03.0/remove in a kdump kernel after opening the vmcore. > > Probably we have some misunderstanding, but it would be good to make it > clear :) Understanding your concern, it could be future proof (for future vmcore_cb users?) to fail the ioctls instead of returning 0. But even for new memory devices, unplug is usually something to be fenced off by the hypervisor, just like not allowing forced DIMM removal. The only think I could imagine is having e.g., virtio-balloon device register a vmcore_cb dynamically and providing a new mechanism to query if a page is backed by a real page in the hypervisor (similar to XENs hypercall). Such a device could be unplugged without harm, as it doesn't actually provide device memory. -- Thanks, David / dhildenb