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 CEB55C433EF for ; Wed, 13 Apr 2022 06:09:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 637516B0075; Wed, 13 Apr 2022 02:09:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E6886B007D; Wed, 13 Apr 2022 02:09:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D4D06B0080; Wed, 13 Apr 2022 02:09:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 3FAE06B0075 for ; Wed, 13 Apr 2022 02:09:55 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0605024ED4 for ; Wed, 13 Apr 2022 06:09:55 +0000 (UTC) X-FDA: 79350829950.14.F694E16 Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by imf05.hostedemail.com (Postfix) with ESMTP id 209C5100002 for ; Wed, 13 Apr 2022 06:09:53 +0000 (UTC) Received: from dread.disaster.area (pa49-181-115-138.pa.nsw.optusnet.com.au [49.181.115.138]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id E9AFA53458F; Wed, 13 Apr 2022 16:09:48 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1neWCI-00H7H4-RH; Wed, 13 Apr 2022 16:09:46 +1000 Date: Wed, 13 Apr 2022 16:09:46 +1000 From: Dave Chinner To: Dan Williams Cc: Shiyang Ruan , Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , "Darrick J. Wong" , Christoph Hellwig , Jane Chu Subject: Re: [PATCH v12 6/7] xfs: Implement ->notify_failure() for XFS Message-ID: <20220413060946.GL1544202@dread.disaster.area> References: <20220410160904.3758789-1-ruansy.fnst@fujitsu.com> <20220410160904.3758789-7-ruansy.fnst@fujitsu.com> <20220413000423.GK1544202@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.4 cv=deDjYVbe c=1 sm=1 tr=0 ts=62566930 a=/kVtbFzwtM2bJgxRVb+eeA==:117 a=/kVtbFzwtM2bJgxRVb+eeA==:17 a=kj9zAlcOel0A:10 a=z0gMJWrwH1QA:10 a=7-415B0cAAAA:8 a=1SRcz3ERVth_psKDs80A:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=none; spf=none (imf05.hostedemail.com: domain of david@fromorbit.com has no SPF policy when checking 211.29.132.246) smtp.mailfrom=david@fromorbit.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 209C5100002 X-Stat-Signature: zecraqati1y3ha3dfjuuwmf3etwjm3je X-HE-Tag: 1649830193-767862 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 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.... Cheers, Dave. -- Dave Chinner david@fromorbit.com