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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 147ADC433DB for ; Wed, 24 Mar 2021 07:48:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C67B4619E4 for ; Wed, 24 Mar 2021 07:48:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232540AbhCXHsY (ORCPT ); Wed, 24 Mar 2021 03:48:24 -0400 Received: from verein.lst.de ([213.95.11.211]:35848 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231344AbhCXHry (ORCPT ); Wed, 24 Mar 2021 03:47:54 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 6BC6D68B02; Wed, 24 Mar 2021 08:47:51 +0100 (CET) Date: Wed, 24 Mar 2021 08:47:51 +0100 From: Christoph Hellwig To: Dan Williams Cc: "ruansy.fnst@fujitsu.com" , Linux Kernel Mailing List , linux-xfs , linux-nvdimm , Linux MM , linux-fsdevel , device-mapper development , "Darrick J. Wong" , david , Christoph Hellwig , Alasdair Kergon , Mike Snitzer , Goldwyn Rodrigues , "qi.fuli@fujitsu.com" , "y-goto@fujitsu.com" Subject: Re: [PATCH v3 01/11] pagemap: Introduce ->memory_failure() Message-ID: <20210324074751.GA1630@lst.de> References: <20210208105530.3072869-1-ruansy.fnst@cn.fujitsu.com> <20210208105530.3072869-2-ruansy.fnst@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org 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. 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. > 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.