Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752495AbdGEMxa convert rfc822-to-8bit (ORCPT ); Wed, 5 Jul 2017 08:53:30 -0400 Received: from prv-mh.provo.novell.com ([137.65.248.74]:37552 "EHLO prv-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751743AbdGEMx3 (ORCPT ); Wed, 5 Jul 2017 08:53:29 -0400 Message-Id: <595CFD650200007800168BF1@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Wed, 05 Jul 2017 06:53:25 -0600 From: "Jan Beulich" To: "Vincent Legout" Cc: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" , , "Boris Ostrovsky" , "Juergen Gross" , Subject: Re: [Xen-devel] [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device References: <20170704114823.pvk6323gfebioikl@bres.gandi.net> <20170704165927.c6dgitftm4v3xk7w@dhcp-3-128.uk.xensource.com> <20170705080804.j6lptyhmjguhdj47@bres.gandi.net> <595CBCB40200007800168A16@prv-mh.provo.novell.com> <20170705123715.exc4qyllpxatxpnj@bres.gandi.net> In-Reply-To: <20170705123715.exc4qyllpxatxpnj@bres.gandi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 977 Lines: 21 >>> On 05.07.17 at 14:37, wrote: > On Wed, Jul 05, 2017 at 02:17:24AM -0600, Jan Beulich wrote : >> >>> On 05.07.17 at 10:08, wrote: >> > Without the patch, blkif_release and xlvbd_release_gendisk are never >> > called, and no call to blk_unregister_queue is made. >> >> But isn't that what needs to be fixed then? The device should be >> removed once its last user goes away (which would be at the time >> the umount is eventually done aiui). > > You mean that block-detach should fail if the device is still mounted? > or find a way to wait until all the users are gone? > > I don't say that's not what should be done, but that's not what I get. > The device is removed after a block-detach, even if still mounted. So > the system is left in an unstable state without the patch. Unstable? I'd expect subsequent I/O to fail for that device, yes, but that's still a stable system. Are you observing anything else? Jan