Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5960585yba; Thu, 11 Apr 2019 09:10:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqzzjlQ6/iO7p/W1D6iMz4FM3N55QN6If4+xuCDxHhS+4n4t7ncour3Iy/1hxXwu8AFtRMHA X-Received: by 2002:a17:902:bd92:: with SMTP id q18mr51154291pls.136.1554999013805; Thu, 11 Apr 2019 09:10:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554999013; cv=none; d=google.com; s=arc-20160816; b=h98f4/IGEoLfQUUAxKJz6IbdEI6TfU9ttZ8I8RbRuUs6GIzpBeORlfTCob6p7FRYu6 F6SArzuQ/U7P40SRpPbgLpGsxSIKcYRQttTZCcQrIn30/M2lJ8mpMpJur9nOlXzFOzZv 0YlxKOCPzSMDqyVT/7WT+AHn7wsn8CgJRgYc++Yh3gXpIg+yZti3y1TGpR0JdrN9dTpx QLP4MPudrBhlCflaHAybfv+PplJIqnA/BU0b5rt/+9P1Qfw1dnzwCoMPRH3fjK2bqHAd iaFIltYAYkbqrlNb+sPbwMpbozEueUFFTi8kJdKAj2msvtXoa/HfjebdxXsuvII2c8jF vtLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=6e0pYzlyJULDAsD9P9xF/AncqgDFrFc74lsbm2pp/Hs=; b=i05FF4pQUyhphLg+v6EqQrUg+KiDd7rY2wAZj/owWnLd6VgB5Zq+94qOYZ3B099Dj+ GHl+BYYAAAx8n2Mde1u9ETw/3EhSxirx0LgxU2pln1Upg9h43FyTvWkbLCO3gsPbBYUs yiG12tSfufFdkbtxkPKeRPilnlmfWhfI0ykGMD/NTLZuSXyzrCe5oTM9WbZBEin5uCFN t96Zd+pUoIl/Jp5t60iGvRjBI4thMmgPrPCH67utFffG1mY+mxQy2A/BGrrCIvuepgPx +YB95qAnkfnJdlfq9bVzaL8xynCqRVTMK2O34LmkepkF3MMWp6zpu1+gjVxVaQUVsuap Y3fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=OExIW2rN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x186si23482534pgx.399.2019.04.11.09.09.57; Thu, 11 Apr 2019 09:10:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=OExIW2rN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726815AbfDKQJS (ORCPT + 99 others); Thu, 11 Apr 2019 12:09:18 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:32889 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726538AbfDKQJQ (ORCPT ); Thu, 11 Apr 2019 12:09:16 -0400 Received: by mail-ot1-f66.google.com with SMTP id j10so5745655otq.0 for ; Thu, 11 Apr 2019 09:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6e0pYzlyJULDAsD9P9xF/AncqgDFrFc74lsbm2pp/Hs=; b=OExIW2rNOO/AH8PIKD7PW7F27aEB3OXEbjCq6Q6tNZhacP/yTFe/CceQjwK6DhN3wH oSYVIYB+W1CWVwUu39E04NAG7rs/ZW1gmqb4pY9Use2kIavWy+EhYD9dN5hnfiBUSXa7 j3w2WgxABB/9K4yxGHWnWJWZyy+R14QZMxpiaHZKWxzjUW5L8YPQy+TwoIA6GuQM7Hb/ kuBcj3LTC3SIBPEhfvER2+1uq20CVu/8H3CWzdcmbXQ/4j4zE6By8oEOImglUSPjMCEC oSiyhWkjCY5wdaVgflK3PeIX2XQ3v/2wgv8tCDV4u4PMImHPgHDdehpn60Hs6bvMuDdZ 3Pgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6e0pYzlyJULDAsD9P9xF/AncqgDFrFc74lsbm2pp/Hs=; b=ukoe/Sxe+Tx7eqgsVfO8xeM5CEn31OvEq2nsGrdyrQSpRfvyYbmiVTnMaQMTCTHtuP awNjTXmcYlOmHlSGFwPkY/9w0i9Ut6CLKpUCAiRRn+1eUTacmIUvKvysiCCOqkeRZN/I t9l3w9aerIpvKqozZ33b2BOnZu7n+/T6l/7gIQ3jO+0r4q/HoTXJVUZJzt8iTUgY3fm3 S65U0+9eiN2WEvRHoaA1lpQbyWqgfY8lCNQSKVHzWVq8YM2JwrBgXcfFEur7tiXdWiie oLvN+XkyyOHvdCAFggW2lPOIRuWmCRVNFUIW2iohFm+U3yH6+Gg+DZj9u6Aju0JSoPk+ h+jQ== X-Gm-Message-State: APjAAAWaQUxZNPNDnIAGpVbm32ADcJFhE6R+twJxYMj5C20se1++0sx4 cjrHGcPJzjGfuHoqHpR2leEaEJYuAzxYxhNgUBmsdw== X-Received: by 2002:a9d:5c86:: with SMTP id a6mr31770148oti.118.1554998955333; Thu, 11 Apr 2019 09:09:15 -0700 (PDT) MIME-Version: 1.0 References: <20190410040826.24371-1-pagupta@redhat.com> <20190410040826.24371-2-pagupta@redhat.com> <1463291806.21158433.1554998258746.JavaMail.zimbra@redhat.com> In-Reply-To: <1463291806.21158433.1554998258746.JavaMail.zimbra@redhat.com> From: Dan Williams Date: Thu, 11 Apr 2019 09:09:03 -0700 Message-ID: Subject: Re: [Qemu-devel] [PATCH v5 1/6] libnvdimm: nd_region flush callback support To: Pankaj Gupta Cc: cohuck@redhat.com, Jan Kara , KVM list , "Michael S. Tsirkin" , Jason Wang , david , Qemu Developers , virtualization@lists.linux-foundation.org, Andreas Dilger , Ross Zwisler , Andrea Arcangeli , Dave Jiang , linux-nvdimm , Vishal L Verma , David Hildenbrand , Matthew Wilcox , Christoph Hellwig , Linux ACPI , jmoyer , linux-ext4 , Len Brown , kilobyte@angband.pl, Rik van Riel , yuval shaia , Stefan Hajnoczi , Paolo Bonzini , lcapitulino@redhat.com, Kevin Wolf , Nitesh Narayan Lal , "Theodore Ts'o" , Xiao Guangrong , "Darrick J. Wong" , "Rafael J. Wysocki" , Linux Kernel Mailing List , linux-xfs , linux-fsdevel , Igor Mammedov Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 11, 2019 at 9:02 AM Pankaj Gupta wrote: > > > > > > > > > This patch adds functionality to perform flush from guest > > > to host over VIRTIO. We are registering a callback based > > > on 'nd_region' type. virtio_pmem driver requires this special > > > flush function. For rest of the region types we are registering > > > existing flush function. Report error returned by host fsync > > > failure to userspace. > > > > > > This also handles asynchronous flush requests from the block layer > > > by creating a child bio and chaining it with parent bio. > > > > > > Signed-off-by: Pankaj Gupta > > > ---bio_chain Dan williams > > [..] > > > diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c > > > index b4ef7d9ff22e..fb1041ab32a6 100644 > > > --- a/drivers/nvdimm/region_devs.c > > > +++ b/drivers/nvdimm/region_devs.c > > > @@ -295,7 +295,9 @@ static ssize_t deep_flush_store(struct device *dev, > > > struct device_attribute *att > > > return rc; > > > if (!flush) > > > return -EINVAL; > > > - nvdimm_flush(nd_region); > > > + rc = nvdimm_flush(nd_region, NULL, false); > > > + if (rc) > > > + return rc; > > > > > > return len; > > > } > > > @@ -1085,6 +1087,11 @@ static struct nd_region *nd_region_create(struct > > > nvdimm_bus *nvdimm_bus, > > > dev->of_node = ndr_desc->of_node; > > > nd_region->ndr_size = resource_size(ndr_desc->res); > > > nd_region->ndr_start = ndr_desc->res->start; > > > + if (ndr_desc->flush) > > > + nd_region->flush = ndr_desc->flush; > > > + else > > > + nd_region->flush = generic_nvdimm_flush; > > > + > > > nd_device_register(dev); > > > > > > return nd_region; > > > @@ -1125,11 +1132,36 @@ struct nd_region > > > *nvdimm_volatile_region_create(struct nvdimm_bus *nvdimm_bus, > > > } > > > EXPORT_SYMBOL_GPL(nvdimm_volatile_region_create); > > > > > > +int nvdimm_flush(struct nd_region *nd_region, struct bio *bio, bool async) > > > +{ > > > > I don't quite see the point of the 'async' argument. All the usages of > > this routine are either > > > > nvdimm_flush(nd_region, bio, true) > > ...or: > > nvdimm_flush(nd_region, NULL, false) > > Agree. > > > > > ...so why not gate async behavior on the presence of the 'bio' argument? > > Sure. > > > > > > > > + int rc = 0; > > > + > > > + /* Create child bio for asynchronous flush and chain with > > > + * parent bio. Otherwise directly call nd_region flush. > > > + */ > > > + if (async && bio->bi_iter.bi_sector != -1) { > > > + > > > + struct bio *child = bio_alloc(GFP_ATOMIC, 0); > > > + > > > + if (!child) > > > + return -ENOMEM; > > > + bio_copy_dev(child, bio); > > > + child->bi_opf = REQ_PREFLUSH; > > > + child->bi_iter.bi_sector = -1; > > > + bio_chain(child, bio); > > > + submit_bio(child); > > > > I understand how this works, but it's a bit too "magical" for my > > taste. I would prefer that all flush implementations take an optional > > 'bio' argument rather than rely on the make_request implementation to > > stash the bio away on a driver specific list. > > I did this to make use of "bio_chain" for chaining child bio for async flush > suggested [1]. Are you saying to remove this and just call "flush" based on > bio argument? Or I implemented the 'bio_chain' request entirely wrong? No, I think you implemented it correctly. I'm just asking for the chaining to be performed internal to the ->flush() callback rather than in the common nvdimm_flush() front-end.