Date: Thu, 28 Apr 2016 18:27:34 +0200
From: Wouter Verhelst <w@uter.be>
To: Markus Pargmann <mpa@pengutronix.de>
Cc: Ratna Manoj <manoj.br@gmail.com>, nbd-general@lists.sourceforge.net,
        Vinod Jayaraman <jv@portworx.com>, jack@suse.cz,
        linux-kernel@vger.kernel.org, Gou Rao <grao@portworx.com>,
        pbonzini@redhat.com
Subject: Re: [Nbd] [PATCH] NBD: replace kill_bdev() with __invalidate_device()
Message-ID: <20160428162734.GA3082@grep.be>
References: <56E711D1.9090708@gmail.com>
 <11986900.ymBh9azTyz@adelgunde>
 <571ADB31.2000609@gmail.com>
 <1809196.i4ZeAM11iZ@adelgunde>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1809196.i4ZeAM11iZ@adelgunde>
Organization: none
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2683
Lines: 62

On Thu, Apr 28, 2016 at 11:00:20AM +0200, Markus Pargmann wrote:
> Hi,
> 
> On Saturday 23 April 2016 07:47:21 Ratna Manoj wrote:
> > Thanks for the review. 
> > 
> > Atleast for ext4 this crash happens on a sys_umount() call, timing of
> > which is not in control of block driver. Block driver cannot force the
> > filesystems to be unmounted, and the file system does not expect 
> > buffers to get unmapped under it.
> 
> Yes the block driver can't force a clean umount.
> 
> > 
> > Ext4 can be fixed with the this patch:
> > http://www.spinics.net/lists/linux-ext4/msg51112.html 
> > It did not make to the kernel. It checks the state of the buffer head
> > before committing.
> > 
> > When we consider diskett/CD as user space thread that called NBD_DO_IT,
> > this problem is analogous to changing disk with another or the same
> > disk suddenly when the file system is still mounted. 
> > 
> > If we completely kill the block device we would loss some writes when
> > same thread is reconnected.
> 
> I am not so sure about your exact use-case here.
> 
> If the NBD_DO_IT thread returns I am considering the connection and
> block device as dead and disconnected. Securing any data afterwards with
> a new connection is potentially dangerous as it may be a different
> server.

Yes, from the kernel POV you're right.

However, at some point I agreed with Paul (your predecessor) that when
this happens due to an error condition (as opposed to it being due to an
explicit disconnect), the kernel would block all reads from or writes to
the device, and the client may try to reconnect *from the same
PID* (i.e., it may not fork()). If that succeeds, the next NBD_DO_IT is
assumed to be connected to the same server; if instead the process
exits, then the block device is assumed to be dead, will be reset, and
all pending reads or writes would error.

In principle, this allows for a proper reconnect from userspace if it
can be done. However, I'm not sure whether this ever worked well or
whether it was documented, so it's probably fine if you think it should
be replaced with something else.

(obviously, userspace reconnecting the device to a different device is
wrong and should not be done, but that's a case of "if you break it, you
get to keep both pieces)

At any rate, I think it makes sense for userspace to be given a chance
to *attempt* to reconnect a device when the connection drops
unexpectedly.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12