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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
