Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3183298pxb; Mon, 1 Nov 2021 09:18:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfL/TZg7PDmH0qtjAeGhZmoA1/DgpLnaCYJ5winvw/teSPe4n3M0QPksbosYrnz17xFb3e X-Received: by 2002:a05:6602:2cce:: with SMTP id j14mr8850798iow.23.1635783501374; Mon, 01 Nov 2021 09:18:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635783501; cv=none; d=google.com; s=arc-20160816; b=kQ4PaN2vXfqUaav1DlaU2p+ZukJYX/E7Cao/XAP1GncD0EJsMBYN3Ajf7fNjCD2SLW VGjz3VSmSUBtmMmWkgmyguDTB22O64Beh6Chn7Pu8Xy5rwGDRDfFBZbBY+B6YtFwr1Wz oQfhcwePwlKNRNXT41ZQJ2Y+H1sHuCRlVqGeVifRCezVG6UPVAnBVH5Rc9RlOaM+SEsb ba9suafMQIiWJhtTx53vd4GM1GhPOIgD4XiFYm92MXYyD3P8gj00fg41o/Nyfh2izsIC +KStjWrVpLiLhCelRkZ2HSQR6qXT+9Qd38TGMCsjD5SHZF05wDWGJhdS2mTDPOTF/JjG wGVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=F2vxwqlB6wFzeCRM5lLa77O94J13VaOz9ZvoVd+rZG8=; b=uYmfUuFxr+TMDEAcSOPC/bBebPU4ULz4E9CPZyl0sMJ124nf4WIKJNdbIVWH4iRJat qxrTS4z/iRVIjpFqwKBfnaB1OQXG7nDhdS5w4yvhH7coAXkB3X0JkYrCanmRb85m1ir2 3EwsI6pJ5I4RMJJ4S8KuhpA3DtnacTZo3QGjaH30TgyJ9lkoS6NnTrLol16OnouL8AkX 1pv89spaMI01PbqufU3XasY2bwieiSm1+4kK8qjAA6gKm9ZKWAZc8EFQUeXhNcby+pV/ yZEfygtCc7wc0yLob5mUjIo/Br8os+9IGBT2pLO/gwNwvT/YK+IforMqveqnIqjahXGF n4xg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=B7k9y58G; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g12si5304207jao.38.2021.11.01.09.17.50; Mon, 01 Nov 2021 09:18:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=B7k9y58G; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232416AbhKAQUV (ORCPT + 99 others); Mon, 1 Nov 2021 12:20:21 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:54923 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230517AbhKAQUU (ORCPT ); Mon, 1 Nov 2021 12:20:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635783467; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=F2vxwqlB6wFzeCRM5lLa77O94J13VaOz9ZvoVd+rZG8=; b=B7k9y58G4JcIJeeiOMtSuF/pN9PKfe884hWhZsMpBKVicHOLGOaAhA3bkvQohmEfRR30U6 ZdVJcyY/DGGosjEivx/lAq1oA8SbdNvebn4BSrV8ZNz5rn9Tc0zupJl4VmczztD5x2R0JF Ak+B7EQ3PIAaXpM6rGqwJSPquMZgtiQ= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-65-yrwmbtrENgKba52V0dasxg-1; Mon, 01 Nov 2021 12:17:46 -0400 X-MC-Unique: yrwmbtrENgKba52V0dasxg-1 Received: by mail-qt1-f200.google.com with SMTP id 14-20020ac8594e000000b002aa84c324e4so12371383qtz.10 for ; Mon, 01 Nov 2021 09:17:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=F2vxwqlB6wFzeCRM5lLa77O94J13VaOz9ZvoVd+rZG8=; b=jKmXHI2jy5dsnox06GaBgsT6wLQtLnmIGTcE4QLu5pk9Jnlt8LQC6ILvdi24VjmUi9 JHu4SFNP92kQuljkfxr4oBY66GHyxcECBxWVijdWmEB9UpT8U/2bL5B4wqDRbk00Jd5Z VHcaRd2MBfSueS9TX40iG2DSnttX3JDwtTGzwIpZP5j7vsJujdvWOvodm9h73yqWnHlS oveq+j7TKCoNXtSOpqvxIn5SsU5We7TRbRT4xeQJYxWetCQpuwYqqDnilTfKDmqQKx29 SOcDGyKLtbheZI1czqdomJzHkMzXGNk5+lpTMEShDpRXX1tTjNGlVezFO38E6vsYiHt3 qL5g== X-Gm-Message-State: AOAM531KY1fjEzu77JiL973rzio+yLZ022Tigmwa65Lbykx/vZVSjR4X pP2+lOFqwVEIveQu+agjOiWRPrKcWKbgEPVoYYv6Aw0gsmycUMi3yCOCLuPiRVSKNBl3EnB27Oe gjS+55KB34IZceaFcPIHL X-Received: by 2002:a05:622a:1006:: with SMTP id d6mr31006261qte.259.1635783465646; Mon, 01 Nov 2021 09:17:45 -0700 (PDT) X-Received: by 2002:a05:622a:1006:: with SMTP id d6mr31006216qte.259.1635783465346; Mon, 01 Nov 2021 09:17:45 -0700 (PDT) Received: from localhost (pool-68-160-176-52.bstnma.fios.verizon.net. [68.160.176.52]) by smtp.gmail.com with ESMTPSA id f66sm5772868qkj.76.2021.11.01.09.17.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Nov 2021 09:17:44 -0700 (PDT) Date: Mon, 1 Nov 2021 12:17:43 -0400 From: Mike Snitzer To: Dan Williams Cc: Christoph Hellwig , Ira Weiny , device-mapper development , linux-xfs , Linux NVDIMM , linux-s390 , linux-fsdevel , linux-erofs@lists.ozlabs.org, linux-ext4 , virtualization@lists.linux-foundation.org Subject: Re: [PATCH 07/11] dax: remove dax_capable Message-ID: References: <20211018044054.1779424-1-hch@lst.de> <20211018044054.1779424-8-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Oct 27 2021 at 8:16P -0400, Dan Williams wrote: > I am going to change the subject of this patch to: > > dax: remove ->dax_supported() > > On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > > > I'll add a bit more background to help others review this. > > The ->dax_supported() operation arranges for a stack of devices to > each answer the question "is dax operational". That request routes to > generic_fsdax_supported() at last level device and that attempted an > actual dax_direct_access() call and did some sanity checks. However, > those sanity checks can be validated in other ways and with those > removed the only question to answer is "has each block device driver > in the stack performed dax_add_host()". That can be validated without > a dax_operation. So, just open code the block size and dax_dev == NULL > checks in the callers, and delete ->dax_supported(). > > Mike, let me know if you have any concerns. Thanks for your additional background, it helped. > > > Just open code the block size and dax_dev == NULL checks in the callers. > > > > Signed-off-by: Christoph Hellwig > > --- > > drivers/dax/super.c | 36 ------------------------------------ > > drivers/md/dm-table.c | 22 +++++++++++----------- > > drivers/md/dm.c | 21 --------------------- > > drivers/md/dm.h | 4 ---- > > drivers/nvdimm/pmem.c | 1 - > > drivers/s390/block/dcssblk.c | 1 - > > fs/erofs/super.c | 11 +++++++---- > > fs/ext2/super.c | 6 ++++-- > > fs/ext4/super.c | 9 ++++++--- > > fs/xfs/xfs_super.c | 21 ++++++++------------- > > include/linux/dax.h | 14 -------------- > > 11 files changed, 36 insertions(+), 110 deletions(-) > > > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > > index 482fe775324a4..803942586d1b6 100644 > > --- a/drivers/dax/super.c > > +++ b/drivers/dax/super.c > > @@ -108,42 +108,6 @@ struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev) > > return dax_dev; > > } > > EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev); > > - > > -bool generic_fsdax_supported(struct dax_device *dax_dev, > > - struct block_device *bdev, int blocksize, sector_t start, > > - sector_t sectors) > > -{ > > - if (blocksize != PAGE_SIZE) { > > - pr_info("%pg: error: unsupported blocksize for dax\n", bdev); > > - return false; > > - } > > - > > - if (!dax_dev) { > > - pr_debug("%pg: error: dax unsupported by block device\n", bdev); > > - return false; > > - } > > - > > - return true; > > -} > > -EXPORT_SYMBOL_GPL(generic_fsdax_supported); > > - > > -bool dax_supported(struct dax_device *dax_dev, struct block_device *bdev, > > - int blocksize, sector_t start, sector_t len) > > -{ > > - bool ret = false; > > - int id; > > - > > - if (!dax_dev) > > - return false; > > - > > - id = dax_read_lock(); > > - if (dax_alive(dax_dev) && dax_dev->ops->dax_supported) > > - ret = dax_dev->ops->dax_supported(dax_dev, bdev, blocksize, > > - start, len); > > - dax_read_unlock(id); > > - return ret; > > -} > > -EXPORT_SYMBOL_GPL(dax_supported); > > #endif /* CONFIG_BLOCK && CONFIG_FS_DAX */ > > > > enum dax_device_flags { > > diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c > > index 1fa4d5582dca5..4ae671c2168ea 100644 > > --- a/drivers/md/dm-table.c > > +++ b/drivers/md/dm-table.c > > @@ -807,12 +807,14 @@ void dm_table_set_type(struct dm_table *t, enum dm_queue_mode type) > > EXPORT_SYMBOL_GPL(dm_table_set_type); > > > > /* validate the dax capability of the target device span */ > > -int device_not_dax_capable(struct dm_target *ti, struct dm_dev *dev, > > +static int device_not_dax_capable(struct dm_target *ti, struct dm_dev *dev, > > sector_t start, sector_t len, void *data) > > { > > - int blocksize = *(int *) data; > > + if (dev->dax_dev) > > + return false; > > > > - return !dax_supported(dev->dax_dev, dev->bdev, blocksize, start, len); > > + pr_debug("%pg: error: dax unsupported by block device\n", dev->bdev); Would prefer the use of DMDEBUG() here (which doesn't need trailing \n) But otherwise: Acked-by: Mike Snitzer