linux-kernel - Re: [Nbd] [PATCH][V3] nbd: add multi-connection support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <F4CD5523-E3BC-4151-B9B8-ADFE9040F6E3@alex.org.uk>
Date:   Sun, 2 Oct 2016 17:17:14 +0100
From:   Alex Bligh <alex@...x.org.uk>
To:     Josef Bacik <jbacik@...com>
Cc:     Alex Bligh <alex@...x.org.uk>, Wouter Verhelst <w@...r.be>,
        axboe@...com, linux-block@...r.kernel.org, kernel-team@...com,
        "nbd-general@...ts.sourceforge.net" 
        <nbd-general@...ts.sourceforge.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Nbd] [PATCH][V3] nbd: add multi-connection support


> On 29 Sep 2016, at 17:59, Josef Bacik <jbacik@...com> wrote:
> 
> On 09/29/2016 12:41 PM, Wouter Verhelst wrote:
>> On Thu, Sep 29, 2016 at 10:03:50AM -0400, Josef Bacik wrote:
>>> So think of it like normal disks with multiple channels.  We don't send flushes
>>> down all the hwq's to make sure they are clear, we leave that decision up to the
>>> application (usually a FS of course).
>> 
>> Well, when I asked earlier, Christoph said[1] that blk-mq assumes that
>> when a FLUSH is sent over one channel, and the reply comes in, that all
>> commands which have been received, regardless of which channel they were
>> received over, have reched disk.
>> 
>> [1] Message-ID: <20160915122304.GA15501@...radead.org>
>> 
>> It is impossible for nbd to make such a guarantee, due to head-of-line
>> blocking on TCP.
>> 
> 
> Huh I missed that.  Yeah that's not possible for us for sure, I think my option 
> idea is the less awful way forward if we want to address that limitation.  Thanks,

I think if the server supports flush (which you can tell), sending flush on
all channels is the only safe thing to do, without substantial protocol
changes (which I'm not sure how one would do given flush is in a sense
a synchronisation point). I think it's thus imperative this gets fixed
before the change gets merged.

-- 
Alex Bligh