Xen devel - Dec 2006 - [PATCH] Add a --force option to detach operations

The following patch adds a --force option to detach operations. It
avoids the device being held forever when frontend fails.

Comments welcome,

-- 
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 13/12/06 22:35, "Glauber de Oliveira Costa"
<gcosta@redhat.com> wrote:
> The following patch adds a --force option to detach operations. It
> avoids the device being held forever when frontend fails.
Looks good. I think --force should be more brutal (i.e., assume that we have
already politely requested the disconnection, if that''s what we really
wanted).

Apart from that, we should remember that if we need to use --force then it
probably indicates a problem in the frontend driver. If you can repro a
situation that requires --force then we should investigate that (and work
out a patch for blkfront).

 Thanks,
 Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 12/14/06, Keir Fraser <keir@xensource.com>
wrote:
> On 13/12/06 22:35, "Glauber de Oliveira Costa"
<gcosta@redhat.com> wrote:
>
> > The following patch adds a --force option to detach operations. It
> > avoids the device being held forever when frontend fails.
>
> Looks good. I think --force should be more brutal (i.e., assume that we
have
> already politely requested the disconnection, if that''s what we
really
> wanted).
How can we be more brutal than that ? The only non-brutal thing I''ve
put there
is denying disconnection when still in Connected state. But if for
some reason the frontend does not want to disconnect, then the tools
have no power over it. It can simply crash guest.

Example: attach a device, mount it at guest, and try to detach it
using --force. It should not force it, as it crashes the
guest.
> Apart from that, we should remember that if we need to use --force then it
> probably indicates a problem in the frontend driver. If you can repro a
> situation that requires --force then we should investigate that (and work
> out a patch for blkfront).
>
Not exactly. The example I''m tracking is as follow:
* try attaching a file:///<valid_file> as sda, after modprobing
sd_mod at guest.
* guest is not able to allocate it a major, and fails like this:

Registering block device major 8
register_blkdev: cannot get major 8 for sd
xen_blk: can''t get major 8 with name sd

Besides, there are many situations in which the underlying block layer
can fail (out of memory, and so on). And it does not necessarily means
a bug in the frontend device.

I do however agree that in the general case, it is a good indicator.

-- 
Glauber de Oliveira Costa.
"Free as in Freedom"

Add your comments to GPLv3 at:
http://gplv3.fsf.org/comments/gplv3-draft-2.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 14/12/06 12:52, "Glauber de Oliveira Costa"
<glommer@gmail.com> wrote:
> How can we be more brutal than that ? The only non-brutal thing
I''ve put there
> is denying disconnection when still in Connected state. But if for
> some reason the frontend does not want to disconnect, then the tools
> have no power over it. It can simply crash guest.
> 
> Example: attach a device, mount it at guest, and try to detach it
> using --force. It should not force it, as it crashes the guest.
Don''t use --force if you don''t know what you''re doing
is a reasonable
caveat. You''re on flakey ground if you have to use it in any case as
something is obviously screwed.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2006-12-14 at 13:29 +0000, Keir Fraser wrote:
> On 14/12/06 12:52, "Glauber de Oliveira Costa"
<glommer@gmail.com> wrote:
> 
> > How can we be more brutal than that ? The only non-brutal thing
I''ve put there
> > is denying disconnection when still in Connected state. But if for
> > some reason the frontend does not want to disconnect, then the tools
> > have no power over it. It can simply crash guest.
> > 
> > Example: attach a device, mount it at guest, and try to detach it
> > using --force. It should not force it, as it crashes the guest.
> 
> Don''t use --force if you don''t know what you''re
doing is a reasonable
> caveat. You''re on flakey ground if you have to use it in any case
as
> something is obviously screwed.
These kind of things can happen by accident. And in case an accident
happens, it does not seems a good idea to crash the guest.

Moreover, the lack of any kind of timeout can lead netfront to leak
memory. If the stores are released too early, backend may be unable to
release the references, and frontend will leak. I see no way of having
any guarantee of being in a termination state, so we will not be able to
to be sure it is safe to remove the entries anyway. But tests I made
with that timeout value lead to no leaks. 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel