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 E1EBBC433EF for ; Tue, 9 Nov 2021 10:30:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8B39161107 for ; Tue, 9 Nov 2021 10:30:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8B39161107 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 E95766B00B8; Tue, 9 Nov 2021 05:30:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E1D746B00B9; Tue, 9 Nov 2021 05:30:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBDB26B00BA; Tue, 9 Nov 2021 05:30:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id B94EC6B00B8 for ; Tue, 9 Nov 2021 05:30:24 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 61367182751A0 for ; Tue, 9 Nov 2021 10:30:24 +0000 (UTC) X-FDA: 78789022368.23.5DE47BB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf14.hostedemail.com (Postfix) with ESMTP id 5337B6001E7A for ; Tue, 9 Nov 2021 10:30:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636453822; 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: in-reply-to:in-reply-to:references:references; bh=qMnwwnuOeLo2Cn4Qeo5XOq5qeOumYBkF0Cv+70+FbcY=; b=GvciIZD/gKLq8v6PV/pIKqTaknKw9XeuUEsrdQJDTq5VFq7OQZksAXsjxQ5yn1Sa4Ctvei 5m0wfPc0i7VUZxQEDuUqN3DSHGy2p8dZQtGerDqYYgv4+2Rg0pG4RqFjV6qgpauHTstCfl 2zH4QTNrEQfXsOWDCmngffVS+WR04Bk= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-336-LTkxL8tbPZ-vpBiAtnKLKQ-1; Tue, 09 Nov 2021 05:30:21 -0500 X-MC-Unique: LTkxL8tbPZ-vpBiAtnKLKQ-1 Received: by mail-wm1-f70.google.com with SMTP id b133-20020a1c808b000000b0032cdd691994so1132326wmd.1 for ; Tue, 09 Nov 2021 02:30:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qMnwwnuOeLo2Cn4Qeo5XOq5qeOumYBkF0Cv+70+FbcY=; b=IlrNMX/gNxGcZ6+gI3P3adF6yNoXyoVD+9qwdo/79ue1jZSVrnTLU3MqwESpAG0oBq XBLJQfS4n+Y5BK90ss1GRujq1pbyeZmgHOwLCJPaSc2VboUcT21bj6XAds1uBD6YZEiB iJ7R8lEoK+ZBC7dE0uZWjZLWBaD57IOR7GBccIVZXasKrrp44xJrcYm6K/kr+9/P5k8R 9zl6vdkGzJppuCytPK6ePL0+KER/ExwZzgHO3xyY4AuBZGPNGUnA55uiUHX+E30k2Jd6 TJ82vsZMALOZJQeBm8ZJNocEH6BCT5IQE8uUQ3rgbJOR/WCtwUg5tm3d3S/4z2xiTE/l VIsg== X-Gm-Message-State: AOAM530IpUl5ThEw5yvrJO6TDV0LWD3MzcaiAM13CmXPI6BiPA2GUiTD 7T5MZARWmOEEP0TaeUp+MJQ++KgxaCrbcXrbGAfCZYlMqrX7AdNMYhhnk6a2HhzcATgoXX2An7r fQxR5C0R/NZaauLV/NxIMChMNXlw= X-Received: by 2002:a5d:4411:: with SMTP id z17mr7686179wrq.59.1636453819949; Tue, 09 Nov 2021 02:30:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJxvdGIOX73miVp7CKgm3TdiaM1R2aWgE21wq/YyCf9M1MPAajm1EpdBq5Lwu3B3y7A92+4vi09YZzPM46zB6VM= X-Received: by 2002:a5d:4411:: with SMTP id z17mr7686133wrq.59.1636453819729; Tue, 09 Nov 2021 02:30:19 -0800 (PST) MIME-Version: 1.0 References: <20211108183057.809e428e841088b657a975ec@linux-foundation.org> <20211109023148.b1OlyuiXG%akpm@linux-foundation.org> <1d2642e6-8251-2b82-7afe-842d60ec099d@redhat.com> In-Reply-To: <1d2642e6-8251-2b82-7afe-842d60ec099d@redhat.com> From: Dave Young Date: Tue, 9 Nov 2021 18:30:08 +0800 Message-ID: Subject: Re: [patch 08/87] proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks To: David Hildenbrand Cc: Andrew Morton , bhe , boris.ostrovsky@oracle.com, Borislav Petkov , "H. Peter Anvin" , jasowang@redhat.com, jgross@suse.com, linux-mm@kvack.org, mhocko@suse.com, Ingo Molnar , mm-commits@vger.kernel.org, MST , osalvador@suse.de, rafael.j.wysocki@intel.com, rppt@kernel.org, sstabellini@kernel.org, Thomas Gleixner , torvalds@linux-foundation.org, "Goyal, Vivek" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000009dd77405d058985e" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5337B6001E7A X-Stat-Signature: gjkkgemyjdqko7bnzpy5as4xdhf69frk Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="GvciIZD/"; spf=none (imf14.hostedemail.com: domain of ruyang@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=ruyang@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1636453824-111433 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: --0000000000009dd77405d058985e Content-Type: text/plain; charset="UTF-8" On Tue, 9 Nov 2021 at 14:40, David Hildenbrand wrote: > On 09.11.21 04:59, Dave Young wrote: > > Hi Andrew, > > On 11/08/21 at 06:31pm, Andrew Morton wrote: > >> From: David Hildenbrand > >> Subject: proc/vmcore: convert oldmem_pfn_is_ram callback to more > generic vmcore callbacks > >> > >> Let's support multiple registered callbacks, making sure that > registering > >> vmcore callbacks cannot fail. Make the callback return a bool instead > of > >> an int, handling how to deal with errors internally. Drop unused > >> HAVE_OLDMEM_PFN_IS_RAM. > >> > >> We soon want to make use of this infrastructure from other drivers: > >> virtio-mem, registering one callback for each virtio-mem device, to > >> prevent reading unplugged virtio-mem memory. > >> > >> Handle it via a generic vmcore_cb structure, prepared for future > >> extensions: for example, once we support virtio-mem on s390x where the > >> vmcore is completely constructed in the second kernel, we want to detect > >> and add plugged virtio-mem memory ranges to the vmcore in order for them > >> to get dumped properly. > >> > >> Handle corner cases that are unexpected and shouldn't happen in sane > >> setups: registering a callback after the vmcore has already been opened > >> (warn only) and unregistering a callback after the vmcore has already > been > >> opened (warn and essentially read only zeroes from that point on). > > > > This is a nice improvement, thanks David. But I did not get time to > > review it yet. The overall idea is good, I would prefer to hold on the > > patches for some time and waiting for more review. > > > > Sorry for jumping in late. > > I really want this in v5.16. Please see the comment in > > https://lkml.kernel.org/r/20211006122709.27885-1-david@redhat.com > > Can we just fix any fallout (if any) as usual after the merge window? > Hi David, sounds good to me if there are no other objections. As we discussed offline in another thread, we can address the issues later if we have, eg. measuring the dump performance etc. Thanks Dave > > -- > Thanks, > > David / dhildenb > > --0000000000009dd77405d058985e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 9 Nov 2021 at 14:40, David Hi= ldenbrand <david@redhat.com> = wrote:
On 09.11.= 21 04:59, Dave Young wrote:
> Hi Andrew,
> On 11/08/21 at 06:31pm, Andrew Morton wrote:
>> From: David Hildenbrand <david@redhat.com>
>> Subject: proc/vmcore: convert oldmem_pfn_is_ram callback to more g= eneric vmcore callbacks
>>
>> Let's support multiple registered callbacks, making sure that = registering
>> vmcore callbacks cannot fail.=C2=A0 Make the callback return a boo= l instead of
>> an int, handling how to deal with errors internally.=C2=A0 Drop un= used
>> HAVE_OLDMEM_PFN_IS_RAM.
>>
>> We soon want to make use of this infrastructure from other drivers= :
>> virtio-mem, registering one callback for each virtio-mem device, t= o
>> prevent reading unplugged virtio-mem memory.
>>
>> Handle it via a generic vmcore_cb structure, prepared for future >> extensions: for example, once we support virtio-mem on s390x where= the
>> vmcore is completely constructed in the second kernel, we want to = detect
>> and add plugged virtio-mem memory ranges to the vmcore in order fo= r them
>> to get dumped properly.
>>
>> Handle corner cases that are unexpected and shouldn't happen i= n sane
>> setups: registering a callback after the vmcore has already been o= pened
>> (warn only) and unregistering a callback after the vmcore has alre= ady been
>> opened (warn and essentially read only zeroes from that point on).=
>
> This is a nice improvement, thanks David.=C2=A0 But I did not get time= to
> review it yet.=C2=A0 The overall idea is good, I would prefer to hold = on the
> patches for some time and waiting for more review.
>
> Sorry for jumping in late.

I really want this in v5.16. Please see the comment in

https://lkml.kernel.org/r/202110061= 22709.27885-1-david@redhat.com

Can we just fix any fallout (if any) as usual after the merge window?

Hi David,=C2=A0 sounds good to me if there a= re no other objections.

As we discussed offline in= another thread,=C2=A0 we can address the issues later if we have, eg. meas= uring the dump performance etc.

Thanks
<= div>Dave

--
Thanks,

David / dhildenb

--0000000000009dd77405d058985e--