Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp486794ybc; Fri, 22 Nov 2019 08:17:15 -0800 (PST) X-Google-Smtp-Source: APXvYqwByt8Xb/3x2JYQMgWrzC8hmE1NeQ979bgVrI1d40DkcLvhDN3RNWe4dZhH2o+2iKdFJ4An X-Received: by 2002:a50:9b1a:: with SMTP id o26mr2026908edi.208.1574439435359; Fri, 22 Nov 2019 08:17:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574439435; cv=none; d=google.com; s=arc-20160816; b=QDBr0kES2WOG9bcqbi58K7Vi5zviuVb625udyHqVd9rRlL19mcnde/iSwQBchUng/R fnZyOn5Je7VpF6mi4tMEefA9HR7w8qRmcRTOUCSKkulg4ncamQ+j1yapBpJbD9z3/5gd 14JrfR8sogok5b/J3SA3NjI+7GHf0GF9LST3sWp2dIoL3KAKJMQD9ElSk1pZPX3KbbHl sOOIGcL8Y1d+YOUlA5ViN0PudLVk6O8jiPWu9er2C6yYoaCYPKtrXmboKj6X+i3709C9 OkxeJ1wKZ58+rUYm8Qipfz2g/3Z0+wWeFFP5jBUScrAqFp2iS8FE2ynB92q22oCzc9mZ EAWA== 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=bGAkIY/malVfTkqNJbPQAJQlDy7Ez63qwq+JecsGmso=; b=kSSuZVtgHpuiCtJrdHm0fH/DTqvxh5hXeKaF27J3VJWvN3MtJTJVX2U6//I9DSP7ej 4lyAKRwBdG1YAxg8FBJTWDRwZj/iBp0CWQA/Lkl/y/xBBDVkMX9ebYJnDJMb0/O7UQra aOnMNwMfpdLgDDbqhuxsogDj6REh0rvpd4kQIc5AKBVpQn3X7ofxBZrqyJBo30GCiw3K Gwdi98krZXHskX+IcjNR0L6Nrog0h+Pb5lXaIxmxhlZNcaIPMX4oqhbtu3viXyV+sFX8 aqEUu/Q1K7181vlbYLRtvhnsJLnGluP/YUT3AN64n1dn76rwVz1CKf+HvchmtgjwLTAS O9/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=u8FT0UY5; 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 d10si5879655edn.266.2019.11.22.08.16.51; Fri, 22 Nov 2019 08:17:15 -0800 (PST) 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=u8FT0UY5; 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 S1727234AbfKVQNS (ORCPT + 99 others); Fri, 22 Nov 2019 11:13:18 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:34522 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727141AbfKVQNR (ORCPT ); Fri, 22 Nov 2019 11:13:17 -0500 Received: by mail-ot1-f66.google.com with SMTP id w11so6659624ote.1 for ; Fri, 22 Nov 2019 08:13:17 -0800 (PST) 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=bGAkIY/malVfTkqNJbPQAJQlDy7Ez63qwq+JecsGmso=; b=u8FT0UY5EsTVWPrYHEXwEq/awgVnTMghppZ1AeqecEiteiyKKqKKc5MoolkdXaws2t SmJr8j/kAOZH32nqX4kc97Hc+b2Xi0RZ+UwTC3UmkWsDiNSRL0IUXu1iPz472CIrBxyA 2asrCnwmK9ReGLWKVOTiYpdemWfkj60RYDmHcr5xwGgq//CV13eZreLbWWIn7aFiFVsp AdFUs+Gcc30RSVGqYr8nEmr1skeEL7/65+4VpXgVfjWZDfA6hZXhhcWBXvn8yYPXs7V2 hSuoxj+uV9FUfKLmbTfISVzWcEclMbxPDvr3QJRJTVjI6insjBR9IqjtpDDorDVF/j0H /AKg== 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=bGAkIY/malVfTkqNJbPQAJQlDy7Ez63qwq+JecsGmso=; b=jEoescQEklyI65sesU8GOc8trHLyckZS5RKT/7pWjxHWcgub8r0yBCpoUuaMZvNIeT pf5ydXY9zIOHxELnqFP3wBgCDbb+m6dVNHwAxqG30qUcIZVIp88O2piC0wawUX4wG31l chJ+nA+myQ3DaVuQS67W4zd7MREBKiiH571wK/IylJ7Ei20ELZVSTZq/d+Is+jHrRVLV d++/DCCCxxZksuMEp+IrjHKaX5rCnXfo0l21ZeCqDRWZjbOUHZIRdJyuLg934AWK1GQb GrtQXnZcS92syKHr4hSU5fZX07Yq2CVFiP/IT7gjRVsM1zFIXFS/cqwecy7QFirH5e7r uIOg== X-Gm-Message-State: APjAAAUjB+OBdnboLiXoKKCsxDFcmdYbYMySxSZwTtSiqawqu6bT0WZa aX5T9qcQNrbW99366wRRKLBRhp3x4Zk0krMj+sGJiQ== X-Received: by 2002:a9d:2d89:: with SMTP id g9mr11028481otb.126.1574439196834; Fri, 22 Nov 2019 08:13:16 -0800 (PST) MIME-Version: 1.0 References: <20191120092831.6198-1-pagupta@redhat.com> In-Reply-To: From: Dan Williams Date: Fri, 22 Nov 2019 08:13:05 -0800 Message-ID: Subject: Re: [PATCH] virtio pmem: fix async flush ordering To: Jeff Moyer Cc: Pankaj Gupta , linux-nvdimm , Linux Kernel Mailing List , Linux ACPI , Vishal L Verma , Dave Jiang , "Weiny, Ira" , "Rafael J. Wysocki" , Len Brown , Vivek Goyal , Keith Busch 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 Fri, Nov 22, 2019 at 8:09 AM Jeff Moyer wrote: > > Dan Williams writes: > > > On Wed, Nov 20, 2019 at 9:26 AM Jeff Moyer wrote: > >> > >> Pankaj Gupta writes: > >> > >> > Remove logic to create child bio in the async flush function which > >> > causes child bio to get executed after parent bio 'pmem_make_request' > >> > completes. This resulted in wrong ordering of REQ_PREFLUSH with the > >> > data write request. > >> > > >> > Instead we are performing flush from the parent bio to maintain the > >> > correct order. Also, returning from function 'pmem_make_request' if > >> > REQ_PREFLUSH returns an error. > >> > > >> > Reported-by: Jeff Moyer > >> > Signed-off-by: Pankaj Gupta > >> > >> There's a slight change in behavior for the error path in the > >> virtio_pmem driver. Previously, all errors from virtio_pmem_flush were > >> converted to -EIO. Now, they are reported as-is. I think this is > >> actually an improvement. > >> > >> I'll also note that the current behavior can result in data corruption, > >> so this should be tagged for stable. > > > > I added that and was about to push this out, but what about the fact > > that now the guest will synchronously wait for flushing to occur. The > > goal of the child bio was to allow that to be an I/O wait with > > overlapping I/O, or at least not blocking the submission thread. Does > > the block layer synchronously wait for PREFLUSH requests? > > You *have* to wait for the preflush to complete before issuing the data > write. See the "Explicit cache flushes" section in > Documentation/block/writeback_cache_control.rst. I'm not debating the ordering, or that the current implementation is obviously broken. I'm questioning whether the bio tagged with PREFLUSH is a barrier for future I/Os. My reading is that it is only a gate for past writes, and it can be queued. I.e. along the lines of md_flush_request().