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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57827C433F5 for ; Wed, 13 Apr 2022 17:09:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D84F16B0075; Wed, 13 Apr 2022 13:09:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D33C76B0078; Wed, 13 Apr 2022 13:09:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C23696B007B; Wed, 13 Apr 2022 13:09:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id B46BA6B0075 for ; Wed, 13 Apr 2022 13:09:53 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7201EA4DA8 for ; Wed, 13 Apr 2022 17:09:53 +0000 (UTC) X-FDA: 79352493066.24.035D20C Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by imf22.hostedemail.com (Postfix) with ESMTP id CBA0CC0008 for ; Wed, 13 Apr 2022 17:09:52 +0000 (UTC) Received: by mail-pg1-f176.google.com with SMTP id t4so2388823pgc.1 for ; Wed, 13 Apr 2022 10:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S3oz53a9Ng+DbhMPj3RmOVulLJKw0oHFC07pKdWasCM=; b=TyHwk2+ZDToVQLJjhJ+GwARFZdQ6fdXaVDK/YYC0qiPJ7F3HvvKdsIy4kR9NZ9lfiE xNbBBit8CgoQNMM3vbwz+zcUp+XG/QEgMchCYBLIqOoKHYh9qiClo5rVQPmmMpqSPUnO fTwAt+4RIGqoQKVn7FHmUl91EINKQGRX9V6O4XaYR3KKGwQ7DyuU+XskDD/yq+WfPPb0 jHhSsiDLvDy2OM8+L6vgYYlOIp1RyCtA5mM1o9SZx1R1D8uyT7qDjUAy/V21ZTuRI2KZ 15EHyz55yFLViX9GowNZKfzHIy8YpYtk99kUuRUamcEDzFAgVe0K5UkAGDXYVx+esSvD 6SWw== 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=S3oz53a9Ng+DbhMPj3RmOVulLJKw0oHFC07pKdWasCM=; b=GSx/fv9SbPC3DXkDqetbd4phRImgZVp5c7Gllekg9+jSRRiKsv74/KpufiksYWQwfO QH/Gx09WdvYBVptiB0SBstmUNh9W0Bp2ZQ2Hm7eajA6+cfgK/0EfYQuIu+iLXsim7GQ8 Fjwzfc245ymCB3FjoLQh/mp7dLFC4Ykr5tHtj6/QCr+GksB6CL15kONUE6on5l5fc2W6 NJ5Wb/6Z1MEIehlam7PRapuCWJfZRfw5wSF/rzc0v7UQ7os8hCIrgfjLWxtXNg14dJ3M YUS/cPKxt5u+EXWtUxLmz52ezxnMvvgmI1fxEVuVzDJGP93b2HzyQ4Ae3zIPadk138HC OPig== X-Gm-Message-State: AOAM533giKxNVFTk9k+0u5Eq6qwUnsIOj/98HzCfQtnb+Gmu/eW9GGcy i6syenXoH2v/5IijJPLJSrJVlZmPV5UpaqnCsFe3uw== X-Google-Smtp-Source: ABdhPJzLi8gMisuellOBcvRBO68apFNBLKqg7RJ1uejuUvIlQHfa3U9nodhdf0gc7bErx9RfyUux7vESwpwfRM8oyF0= X-Received: by 2002:a05:6a02:283:b0:342:703e:1434 with SMTP id bk3-20020a056a02028300b00342703e1434mr35296654pgb.74.1649869791634; Wed, 13 Apr 2022 10:09:51 -0700 (PDT) MIME-Version: 1.0 References: <20220410160904.3758789-1-ruansy.fnst@fujitsu.com> <20220410160904.3758789-7-ruansy.fnst@fujitsu.com> <20220413000423.GK1544202@dread.disaster.area> <20220413060946.GL1544202@dread.disaster.area> In-Reply-To: <20220413060946.GL1544202@dread.disaster.area> From: Dan Williams Date: Wed, 13 Apr 2022 10:09:40 -0700 Message-ID: Subject: Re: [PATCH v12 6/7] xfs: Implement ->notify_failure() for XFS To: Dave Chinner Cc: Shiyang Ruan , Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , "Darrick J. Wong" , Christoph Hellwig , Jane Chu Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 7scbrz67zi5htre64i9zditwfgkd745e Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=TyHwk2+Z; spf=none (imf22.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.215.176) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: CBA0CC0008 X-HE-Tag: 1649869792-335383 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 Tue, Apr 12, 2022 at 11:10 PM Dave Chinner wrote: > > On Tue, Apr 12, 2022 at 07:06:40PM -0700, Dan Williams wrote: > > On Tue, Apr 12, 2022 at 5:04 PM Dave Chinner wrote: > > > On Mon, Apr 11, 2022 at 12:09:03AM +0800, Shiyang Ruan wrote: > > > > Introduce xfs_notify_failure.c to handle failure related works, such as > > > > implement ->notify_failure(), register/unregister dax holder in xfs, and > > > > so on. > > > > > > > > If the rmap feature of XFS enabled, we can query it to find files and > > > > metadata which are associated with the corrupt data. For now all we do > > > > is kill processes with that file mapped into their address spaces, but > > > > future patches could actually do something about corrupt metadata. > > > > > > > > After that, the memory failure needs to notify the processes who are > > > > using those files. > ... > > > > @@ -1964,8 +1965,8 @@ xfs_alloc_buftarg( > > > > btp->bt_mount = mp; > > > > btp->bt_dev = bdev->bd_dev; > > > > btp->bt_bdev = bdev; > > > > - btp->bt_daxdev = fs_dax_get_by_bdev(bdev, &btp->bt_dax_part_off, NULL, > > > > - NULL); > > > > + btp->bt_daxdev = fs_dax_get_by_bdev(bdev, &btp->bt_dax_part_off, mp, > > > > + &xfs_dax_holder_operations); > > > > > > I see a problem with this: we are setting up notify callbacks before > > > we've even read in the superblock during mount. i.e. we don't even > > > kow yet if we've got an XFS filesystem on this block device. > > > Hence these notifications need to be delayed until after the > > > filesystem is mounted, all the internal structures have been set up > > > and log recovery has completed. > > > > So I think this gets back to the fact that there will eventually be 2 > > paths into this notifier. > > I'm not really concerned by how the notifications are generated; > my concern is purely that notifications can be handled safely. > > > All that to say, I think it is ok / expected for the filesystem to > > drop notifications on the floor when it is not ready to handle them. > > Well, yes. The whole point of notifications is the consumer makes > the decision on what to do with the notification it receives - the > producer of the notification does not (and can not) dictate what > policy the consumer(s) implement... > > > For example there are no processes to send SIGBUS to if the filesystem > > has not even finished mount. > > There may be not processes to send SIGBUS to even if the filesystem > has finished mount. But we still want the notifications to be > delivered and we still need to handle them safely. > > IOWs, while we might start by avoiding notifications during mount, > this doesn't mean we will never have reason to process events during > mount. What we do with this notification is going to evolve over > time as we add new and adapt existing functionality.... Yes, sounds like we're on the same page. I had mistakenly interpreted "Hence these notifications need to be delayed until after the filesystem is mounted" as something the producer would need to handle, but yes, consumer is free to drop if the notification arrives at an inopportune time.