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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7ECD5C433C1 for ; Wed, 24 Mar 2021 16:37:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0C32B619F3 for ; Wed, 24 Mar 2021 16:37:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0C32B619F3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 699D16B02C6; Wed, 24 Mar 2021 12:37:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 670EA6B02CB; Wed, 24 Mar 2021 12:37:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 511646B02CD; Wed, 24 Mar 2021 12:37:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0042.hostedemail.com [216.40.44.42]) by kanga.kvack.org (Postfix) with ESMTP id 35BBD6B02C6 for ; Wed, 24 Mar 2021 12:37:26 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E1406824999B for ; Wed, 24 Mar 2021 16:37:25 +0000 (UTC) X-FDA: 77955323250.33.8105723 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf08.hostedemail.com (Postfix) with ESMTP id B619480192F4 for ; Wed, 24 Mar 2021 16:37:22 +0000 (UTC) Received: by mail-ed1-f45.google.com with SMTP id bf3so28401571edb.6 for ; Wed, 24 Mar 2021 09:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F78F4/Kq+ndIvAG3q41JlNnbimm1afFKY1uPrkgKEKE=; b=CsDx6xAl1VtYRX8X8nlGVP72pS+Njf2eRG9UeLEcNYw/0GG+u51E8oRfnZj6k3/sNg aRLLF/mmJCW58czyShqa6WkR7qJxQwuiCLVxyrBpZ+TAPagZGTpDfa7+zl7Dur1DKlk4 B1AAACFL6xsj3ekCmh1gjol0o/QSp3xiwcbei6jwyZhVy3/cDah43fcg8J30O9ZE/PgR mQCXAHzOBzR2wsLGgkCG9GE3xk75u+tWfyPHSZJGznQsHqijxofg2L4Q1jPv+MKqUCHE RQjr95+R6I9EMKEYtmdWrRAb9fTP8P6XndMLkaPTVlg8oBOUifEZ/RsV84+JGEN92W79 y2cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F78F4/Kq+ndIvAG3q41JlNnbimm1afFKY1uPrkgKEKE=; b=LPrMpOPd/Ibiv2ar6a1+yvBoC/Jz3iakY0TtuHUFOs0oED0mcvbJH2WGL8tVi/BBVv gZio0cTqzrube3MkLuYaf9C4U/M5urbnHZf2a8mGjU3HZjPRhygzOJ3HvZvVPfxTb6sm EVPfEgtb7Bm1BhWkNnloede7RNir3xm9gSfhlEmUhdil6TkKyp9jvVbZin3SGHR74RbT HsbqLa2IEdNomMcOjCY9S5mf5O1h5ks/PWe1ombbZw9E528tPkpzWdMkTDT5enrh7+tZ ISeB5ef0zfhVSdPmsikphbI3Yb5qokclP4+CUp/CsnrQaJ6hYDg+CG+8R2jd/OAdfPGN xOlg== X-Gm-Message-State: AOAM531P7iQHH/WQLy8p4MBGpNEPv8AUTPgWPFzaQctRLIpRW1LUctdx XbftJfCLG3290tR1C8NPuYy6gzZ6PRAK8h0YafTLGw== X-Google-Smtp-Source: ABdhPJy0i6T+2AM1FhaOe2x1NOEA+VihVGm8Q0AyYdTDg9DUntxFo3NhisOlYTqdDwwzXOKs7/wWOwG2TBuN7zwJqD8= X-Received: by 2002:a05:6402:4301:: with SMTP id m1mr4548882edc.210.1616603832460; Wed, 24 Mar 2021 09:37:12 -0700 (PDT) MIME-Version: 1.0 References: <20210208105530.3072869-1-ruansy.fnst@cn.fujitsu.com> <20210208105530.3072869-2-ruansy.fnst@cn.fujitsu.com> <20210324074751.GA1630@lst.de> In-Reply-To: <20210324074751.GA1630@lst.de> From: Dan Williams Date: Wed, 24 Mar 2021 09:37:01 -0700 Message-ID: Subject: Re: [PATCH v3 01/11] pagemap: Introduce ->memory_failure() To: Christoph Hellwig Cc: "ruansy.fnst@fujitsu.com" , Linux Kernel Mailing List , linux-xfs , linux-nvdimm , Linux MM , linux-fsdevel , device-mapper development , "Darrick J. Wong" , david , Alasdair Kergon , Mike Snitzer , Goldwyn Rodrigues , "qi.fuli@fujitsu.com" , "y-goto@fujitsu.com" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 8dyjnbtiaqkxgy38kxwpkokd5pesohow X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B619480192F4 Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=mail-ed1-f45.google.com; client-ip=209.85.208.45 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616603842-567405 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 Wed, Mar 24, 2021 at 12:48 AM Christoph Hellwig wrote: > > On Tue, Mar 23, 2021 at 07:19:28PM -0700, Dan Williams wrote: > > So I think the path forward is: > > > > - teach memory_failure() to allow for ranged failures > > > > - let interested drivers register for memory failure events via a > > blocking_notifier_head > > Eww. As I said I think the right way is that the file system (or > other consumer) can register a set of callbacks for opening the device. How does that solve the problem of the driver being notified of all pfn failure events? Today pmem only finds out about the ones that are notified via native x86 machine check error handling via a notifier (yes "firmware-first" error handling fails to do the right thing for the pmem driver), or the ones that are eventually reported via address range scrub, but only for the nvdimms that implement range scrubbing. memory_failure() seems a reasonable catch all point to route pfn failure events, in an arch independent way, to interested drivers. I'm fine swapping out dax_device blocking_notiier chains for your proposal, but that does not address all the proposed reworks in my list which are: - delete "drivers/acpi/nfit/mce.c" - teach memory_failure() to be able to communicate range failure - enable memory_failure() to defer to a filesystem that can say "critical metadata is impacted, no point in trying to do file-by-file isolation, bring the whole fs down". > I have a series I need to finish and send out to do that for block > devices. We probably also need the concept of a holder for the dax > device to make it work nicely, as otherwise we're going to have a bit > of a mess. Ok, I'll take a look at adding a holder. > > > This obviously does not solve Dave's desire to get this type of error > > reporting on block_devices, but I think there's nothing stopping a > > parallel notifier chain from being created for block-devices, but > > that's orthogonal to requirements and capabilities provided by > > dax-devices. > > FYI, my series could easily accomodate that if we ever get a block > driver that actually could report such errors. Sure, whatever we land for a dax_device could easily be adopted for a block device.