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 B5577C433EF for ; Fri, 8 Apr 2022 06:25:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4CB36B0071; Fri, 8 Apr 2022 02:25:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DFA336B0072; Fri, 8 Apr 2022 02:25:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC1746B0074; Fri, 8 Apr 2022 02:25:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id BF4276B0071 for ; Fri, 8 Apr 2022 02:25:18 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7E992AE574 for ; Fri, 8 Apr 2022 06:25:18 +0000 (UTC) X-FDA: 79332724716.22.49AD94B Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf22.hostedemail.com (Postfix) with ESMTP id 0336AC0004 for ; Fri, 8 Apr 2022 06:25:17 +0000 (UTC) Received: by mail-pj1-f49.google.com with SMTP id s14-20020a17090a880e00b001caaf6d3dd1so11044806pjn.3 for ; Thu, 07 Apr 2022 23:25:17 -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=gpTt04knjFi7/r4rdhBFpeWlnWTTiUe1d93mQq2Do3I=; b=MAz6RPib3bcwbnw7VOzDKsX4M+0+QU+QgCQSRlXjmf8Y1j5E82C3MrTGAgpPQP7x2/ 7b9XV/2KcaXsvw+GrapP/fImELYl5GNzN9cbv9exuPksDfOeysAV7CzrjAFcCFLdpyD4 cv20aVQbMuVGhrrBsMZl3Y8jzXtJorYiwaZ6s95JJpE0/CNVsbKtdGQ2lozCaCX2Z2jj aCCws8x6/Q4nlxvNHMQu8EzHC848KqfeK37XWl/JO83aKLXIaLW6At4fR5a2AYuvw90o YBWxQySI3dDSIpAkhSAUDAIqcG8Am5xjHEv3dQvB8v6T2tmLMTp34RjSYln0W0Mrb2aR fI4Q== 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=gpTt04knjFi7/r4rdhBFpeWlnWTTiUe1d93mQq2Do3I=; b=6qFqPUnuw7u4sBJDssdGwQuTh28GqPwnGCSPQ38hJGbsyuKSqxMe8/IG2FEqQcseCi e8wB6Aens8i6K2sWNSyb8+DUsVLztbJKdcIcq+iXAiYQZUMRbDyLt1byZyneNTq2FVXI Na7U03IhUL77hkVqwV01uoyoUxmLE2eNhM/78ATRI9ojcjMNvw9U0A9PjupY4jxzT/ZL geYoOHV6hznLViPYyRbGKNSnnWhkyDYOKxxrl3VtwbSWfYdy3u+VxBGn4ws+FD7VE5pr wk8V/g6zdL/bfnD1QwFINEnS0NJrHKl60mdNBOqtja7qfLKqba6WrydLGvnhFDLI1JYO U/ug== X-Gm-Message-State: AOAM533h0fqtlQyujiIb1gZ+ML2ibo9dfvfwr6M38cOw3ybTA+oAxy3x 2c3QPLtoG4PyjBSG39ub8zRkhircLETG6QzDTrsIzQ== X-Google-Smtp-Source: ABdhPJzID/VraWAFCvRtOjZrpYKIIRqJ1ed+REfBAOD4Tjags0hA+q9Oe2WNNyfILt9xFCTGNazEpbsu/uJg2gJ2j9Y= X-Received: by 2002:a17:90a:c083:b0:1c6:a164:fd5d with SMTP id o3-20020a17090ac08300b001c6a164fd5dmr20043007pjs.8.1649399116938; Thu, 07 Apr 2022 23:25:16 -0700 (PDT) MIME-Version: 1.0 References: <20220227120747.711169-1-ruansy.fnst@fujitsu.com> <20220227120747.711169-8-ruansy.fnst@fujitsu.com> In-Reply-To: From: Dan Williams Date: Thu, 7 Apr 2022 23:25:06 -0700 Message-ID: Subject: Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS To: Christoph Hellwig Cc: Shiyang Ruan , Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , "Darrick J. Wong" , david , Jane Chu Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: u7a63yjdsrg4ynp3zkoq7xn354sntdne X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0336AC0004 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=MAz6RPib; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=none (imf22.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.216.49) smtp.mailfrom=dan.j.williams@intel.com X-Rspam-User: X-HE-Tag: 1649399117-667338 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, Mar 29, 2022 at 11:01 PM Christoph Hellwig wrote: > > > @@ -1892,6 +1893,8 @@ xfs_free_buftarg( > > list_lru_destroy(&btp->bt_lru); > > > > blkdev_issue_flush(btp->bt_bdev); > > + if (btp->bt_daxdev) > > + dax_unregister_holder(btp->bt_daxdev, btp->bt_mount); > > fs_put_dax(btp->bt_daxdev); > > > > kmem_free(btp); > > @@ -1939,6 +1942,7 @@ xfs_alloc_buftarg( > > struct block_device *bdev) > > { > > xfs_buftarg_t *btp; > > + int error; > > > > btp = kmem_zalloc(sizeof(*btp), KM_NOFS); > > > > @@ -1946,6 +1950,14 @@ xfs_alloc_buftarg( > > btp->bt_dev = bdev->bd_dev; > > btp->bt_bdev = bdev; > > btp->bt_daxdev = fs_dax_get_by_bdev(bdev, &btp->bt_dax_part_off); > > + if (btp->bt_daxdev) { > > + error = dax_register_holder(btp->bt_daxdev, mp, > > + &xfs_dax_holder_operations); > > + if (error) { > > + xfs_err(mp, "DAX device already in use?!"); > > + goto error_free; > > + } > > + } > > It seems to me that just passing the holder and holder ops to > fs_dax_get_by_bdev and the holder to dax_unregister_holder would > significantly simply the interface here. > > Dan, what do you think? Yes, makes sense, just like the optional holder arguments to blkdev_get_by_*(). > > > +#if IS_ENABLED(CONFIG_MEMORY_FAILURE) && IS_ENABLED(CONFIG_FS_DAX) > > No real need for the IS_ENABLED. Also any reason to even build this > file if the options are not set? It seems like > xfs_dax_holder_operations should just be defined to NULL and the > whole file not supported if we can't support the functionality. > > Dan: not for this series, but is there any reason not to require > MEMORY_FAILURE for DAX to start with? Given that DAX ties some storage semantics to memory and storage supports EIO I can see an argument to require memory_failure() for DAX, and especially for DAX on CXL where hotplug is supported it will be necessary. Linux currently has no facility to consult PCI drivers about removal actions, so the only recourse for a force removed CXL device is mass memory_failure(). > > > + > > + ddev_start = mp->m_ddev_targp->bt_dax_part_off; > > + ddev_end = ddev_start + > > + (mp->m_ddev_targp->bt_bdev->bd_nr_sectors << SECTOR_SHIFT) - 1; > > This should use bdev_nr_bytes. > > But didn't we say we don't want to support notifications on partitioned > devices and thus don't actually need all this? Right.