Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5889880yba; Thu, 11 Apr 2019 07:52:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqzNqo1xCiDLBn6RlfMB1OdReNg+qdDOCkgODLkK9wjGqVxFGUCDlbpQB9tFyH+NjQe1GtFI X-Received: by 2002:a63:4616:: with SMTP id t22mr47776719pga.217.1554994378005; Thu, 11 Apr 2019 07:52:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554994377; cv=none; d=google.com; s=arc-20160816; b=Hc2ni5n7BglUjMlS2ihW+zfMllTCOl6hQn7cWs7599rmq/FrNfaJDOyzDILxAIAzRN YWgWg3Pjpx78oJg0NQqrfrKwnDYTXqqZznLh6zHUSFTjdNspHaewlDsvczXt4hkd8yNM JCgHE6Mtu4tGnSDtJ0YsC/uU6loKLrKwqa2PGGfgfi8MveKrA67h8HrP29cqA22a8h+R 2FImVFIfV3t7N0lWSfia7s0+upoeA0GpeB3URwYfZ5EhwlzGkhDRvlc7h8tzxcP957Wa zhTagXqxTTv2B/uBJYQU937vR8LEbuVktoklN18E+AoGMVniAKs6ALLLEorbX4hh00k0 bgVg== 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=HrHI1yUQh4ijcB7YHVwA9JPy3wKlBzvWJG6Efesd/f0=; b=XWKCgF/wPZvcMplfg7yT+xX1SS/he5n7CnUXpRTNyl9f8KsKq9AAKOGn/hh/pxrI6N MpEY7KB1PieQuR+kN72m/p3hMV4XpSSc6Ajy87vw3uDNjanF4uyvWYb/hEkw3Ove2rwX kPQrcG9O4y83JhDzBtkYxnSUFFkXJmsE9f2n7xqaJuWnDvNMFNTL2Sm/BttKRHdQc0QI ckGQ2JuO91K+6pgiQkDh4A0V1h0bovWPmZwH2NAg4/8tv/exe5BlSlZ+5iUnYkKff9yu U8shK5wQXn4TNoJ+aPNECsDaA2p4xbnrw1QUxrZ0WGOCOBb3e6wmu0cN05Tyl6jVz6c9 tXMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=zi4I18XM; 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 q190si18765390pfc.215.2019.04.11.07.52.39; Thu, 11 Apr 2019 07:52:57 -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=zi4I18XM; 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 S1726564AbfDKOwB (ORCPT + 99 others); Thu, 11 Apr 2019 10:52:01 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:34853 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726585AbfDKOwB (ORCPT ); Thu, 11 Apr 2019 10:52:01 -0400 Received: by mail-ot1-f66.google.com with SMTP id m10so5497076otp.2 for ; Thu, 11 Apr 2019 07:52:00 -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=HrHI1yUQh4ijcB7YHVwA9JPy3wKlBzvWJG6Efesd/f0=; b=zi4I18XMGtYXeCFOI7IgUdbB0EOZdbnJeoa3l20X2Gqlcl0YR55UhU5luYmUa6cHU5 EqcmShYr64nYFlNtn7Rd+1lIJH9XABBmZCQPUOavNMLs+0n9I8m1OuY2+KD0JtN93YcX 3rvvNLyeug/w5aNDC5fj4CjwQPXARfaplfRzq12KFQ4x2cbAHrzA+mENqSKh1c617RSg xlJAToPXjpLqe1zcSJodjCgmY5dhUdHQiVkQchFEI36jgwV1c+a/Zf73ibOfskPgdlC8 PjhIrDB/UX3hLAtfZ9Gz/P0KisQxQ6VH57FKrSFjl+UerDKSD8YHx1TPbaLhBc3i7fUT dpzg== 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=HrHI1yUQh4ijcB7YHVwA9JPy3wKlBzvWJG6Efesd/f0=; b=eeq/lTIdPs9Id4qnE0YaYyfEpcbNvSIEvGPboUJS9rKb5jpbyYLOMeHQmqwpUYPkCM wRwQY4hugMGNupgIJGLAUmYry29+wDY0dZb3xUN7v5wopCPrd8s41/8a17PRnBu4x83L Mzkn6ilK8A7d2lVdS8WCdwdra88EeMJgNXuahNVwnrZJiqY5rRF8szk3eX0iRMOKhV1g u1vNv03Dg24ZI8NqdLMowOpmbuF25FGeWbY/3UZiPVd64x7R/sHDThJTMd6yFPt1u7Cw LyGBFM/PUTEr3MZQ5Y0HnkdeUZtDv7haMqL1zIpcUmFOWs8OJN7IRhqo/M3rdtlZK/bP 3xLw== X-Gm-Message-State: APjAAAVDWRf9cDVAjoJF7hv2A2wzjTZzzQRlUOnXhRQST9oqHAZAPjl4 OfdlGyZZboFbaJk/mz84T9sL9tu+qpS3iwC39nLa/g== X-Received: by 2002:a9d:3f4b:: with SMTP id m69mr32615377otc.246.1554994319729; Thu, 11 Apr 2019 07:51:59 -0700 (PDT) MIME-Version: 1.0 References: <20190410040826.24371-1-pagupta@redhat.com> <20190410040826.24371-2-pagupta@redhat.com> In-Reply-To: <20190410040826.24371-2-pagupta@redhat.com> From: Dan Williams Date: Thu, 11 Apr 2019 07:51:48 -0700 Message-ID: Subject: Re: [PATCH v5 1/6] libnvdimm: nd_region flush callback support To: Pankaj Gupta Cc: linux-nvdimm , Linux Kernel Mailing List , virtualization@lists.linux-foundation.org, KVM list , linux-fsdevel , Linux ACPI , Qemu Developers , linux-ext4 , linux-xfs , Ross Zwisler , Vishal L Verma , Dave Jiang , "Michael S. Tsirkin" , Jason Wang , Matthew Wilcox , "Rafael J. Wysocki" , Christoph Hellwig , Len Brown , Jan Kara , "Theodore Ts'o" , Andreas Dilger , "Darrick J. Wong" , lcapitulino@redhat.com, Kevin Wolf , Igor Mammedov , jmoyer , Nitesh Narayan Lal , Rik van Riel , Stefan Hajnoczi , Andrea Arcangeli , David Hildenbrand , david , cohuck@redhat.com, Xiao Guangrong , Paolo Bonzini , kilobyte@angband.pl, yuval.shaia@oracle.com 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 Tue, Apr 9, 2019 at 9:09 PM 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 > --- [..] > 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) ...so why not gate async behavior on the presence of the 'bio' argument? > + 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. > + } else { > + if (nd_region->flush(nd_region)) > + rc = -EIO; Given the common case wants to be fast and synchronous I think we should try to avoid retpoline overhead by default. So something like this: if (nd_region->flush == generic_nvdimm_flush) rc = generic_nvdimm_flush(...);