Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy

[Andrew Jones <drjones@redhat.com>]

On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> Hmm, I should maybe self-nack this. The bug that led me to writing
> it is likely only with older tooling, such as RHEL5's. The problem
> was if you attempted to detach a mounted disk twice, then the second
> time it would succeed. The guest had flipped to Closing on the first
> try, and thus didn't issue an error to xenbus on the second. I see

Actually, it's even worse than I thought. Just a single attempt to
detach the device will cause the guest grief (with RHEL5's tools
anyway). Once xenbus shows the device is in the Closing state, then
tasks accessing the device may hang.

> The reason I only say maybe self-nack though, is because this state
> change seemed to be thrown in with another fix[1]. I'm not sure if
> the new behavior on legacy hosts was considered or not. If not, then
> we can consider it now. Do we want to have deferred asynch detaches
> over protecting the guest from multiple detach calls on legacy hosts?
> 

I guess we can keep the feature and protect the guest with a patch like
I'll send in a moment. It doesn't really work for me with a RHEL5 host
though. The deferred close works from the pov of the guest, but the
state of the block device gets left in Closed after the guest unmounts
it, and then RHEL5's tools can't detach/reattach it. If the deferred
close ever worked on other Xen hosts though, then I don't believe this
patch would break it, and it will also keep the guest safe when run on
hosts that don't treat state=Closing the way it currently expects.

Drew