Xen devel - Mar 2009 - Backend in user space, how is its kernel dev unregistered?

There''s a curious asymmetry in how Xen backend devices are registered
and unregistered.

Registering is the job of xenbus_probe.c: it watches xenstore, and when
a device node shows up, it calls device_register().

Unregistering is the device driver''s job: it watches xenstore, and when
it sees the front end shut down, it calls device_unregister().

But what if the device driver is in user space?  vfb and vkbd are.  I
can''t see how their kernel devices can ever get unregistered.

If that is true, any ideas on how to plug the leak?

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

On 04/03/2009 19:02, "Markus Armbruster" <armbru@redhat.com>
wrote:
> Unregistering is the device driver''s job: it watches xenstore, and
when
> it sees the front end shut down, it calls device_unregister().
> 
> But what if the device driver is in user space?  vfb and vkbd are.  I
> can''t see how their kernel devices can ever get unregistered.
> 
> If that is true, any ideas on how to plug the leak?
Backends also tear down when their xenstore directory is removed. I think
that''s the job of xenbus_cleanup_devices() in the 2.6.18 tree.

 -- Keir



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

On 04/03/2009 19:02, "Markus Armbruster" <armbru@redhat.com>
wrote:
> But what if the device driver is in user space?  vfb and vkbd are.  I
> can''t see how their kernel devices can ever get unregistered.
Presumably these should watch xenstore themselves and tear down state when
they see state changes from the frontend, or the corresponding xenstore
directory disappear completely. Just like in the kernel''s
xenbus_probe.c.

 -- Keir



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

Keir Fraser <keir.fraser@eu.citrix.com> writes:
> On 04/03/2009 19:02, "Markus Armbruster"
<armbru@redhat.com> wrote:
>
>> But what if the device driver is in user space?  vfb and vkbd are.  I
>> can''t see how their kernel devices can ever get unregistered.
>
> Presumably these should watch xenstore themselves and tear down state when
> they see state changes from the frontend, or the corresponding xenstore
> directory disappear completely. Just like in the kernel''s
xenbus_probe.c.
>
>  -- Keir
Stupid question: how can a user space driver get *kernel* devices unregistered?

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

On 04/03/2009 19:51, "Markus Armbruster" <armbru@redhat.com>
wrote:
>>> But what if the device driver is in user space?  vfb and vkbd are. 
I
>>> can''t see how their kernel devices can ever get
unregistered.
>> 
>> Presumably these should watch xenstore themselves and tear down state
when
>> they see state changes from the frontend, or the corresponding xenstore
>> directory disappear completely. Just like in the kernel''s
xenbus_probe.c.
>> 
>>  -- Keir
> 
> Stupid question: how can a user space driver get *kernel* devices
> unregistered?
Maybe I misunderstand the problem. I don''t know much about pvfb or
pvkbd.

 -- Keir



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

Markus Armbruster wrote:
> Keir Fraser <keir.fraser@eu.citrix.com> writes:
> 
>> On 04/03/2009 19:02, "Markus Armbruster"
<armbru@redhat.com> wrote:
>>
>>> But what if the device driver is in user space?  vfb and vkbd are. 
I
>>> can''t see how their kernel devices can ever get
unregistered.
>> Presumably these should watch xenstore themselves and tear down state
when
>> they see state changes from the frontend, or the corresponding xenstore
>> directory disappear completely. Just like in the kernel''s
xenbus_probe.c.
>>
>>  -- Keir
> 
> Stupid question: how can a user space driver get *kernel* devices
unregistered?
/me is confused.
Which kernel device you are talking about?
Frontend?  That one lives in guest kernel space and should work like all
other frontends.
Backend?  There is no kernel device in the first place.

cheers,
  Gerd

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

Keir Fraser <keir.fraser@eu.citrix.com> writes:
> On 04/03/2009 19:51, "Markus Armbruster"
<armbru@redhat.com> wrote:
>
>>>> But what if the device driver is in user space?  vfb and vkbd
are.  I
>>>> can''t see how their kernel devices can ever get
unregistered.
>>> 
>>> Presumably these should watch xenstore themselves and tear down
state when
>>> they see state changes from the frontend, or the corresponding
xenstore
>>> directory disappear completely. Just like in the kernel''s
xenbus_probe.c.
>>> 
>>>  -- Keir
>> 
>> Stupid question: how can a user space driver get *kernel* devices
>> unregistered?
>
> Maybe I misunderstand the problem. I don''t know much about pvfb or
pvkbd.
>
>  -- Keir
Let me elaborate.

Backend device registration is split between xenbus_probe.c
(registering) and the backend device driver (unregistering).  When a
device node shows up in xenstore, xenbus_probe_node() calls
device_register().  When the backend driver sees the frontend shut down,
it calls device_unregister().  For an example see frontend_changed() in
drivers/xen/blkback/xenbus.c.

The vfb and vkbd backends live in user space, i.e. there is no backend
driver in the kernel.  device_unregister() never gets called.  This is a
resource leak.

Does this explain the problem sufficienctly?

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

> The vfb and vkbd backends live in user space, i.e. there is no backend
> driver in the kernel.  device_unregister() never gets called.  This is a
> resource leak.
When a domain shuts down xend will cleanup the backend device entries in
xenstore, which in turn kills the devices.  At least they disappear from
sysfs on my box ...

cheers,
  Gerd


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

On 05/03/2009 12:40, "Markus Armbruster" <armbru@redhat.com>
wrote:
> Let me elaborate.
> 
> Backend device registration is split between xenbus_probe.c
> (registering) and the backend device driver (unregistering).  When a
> device node shows up in xenstore, xenbus_probe_node() calls
> device_register().  When the backend driver sees the frontend shut down,
> it calls device_unregister().  For an example see frontend_changed() in
> drivers/xen/blkback/xenbus.c.
> 
> The vfb and vkbd backends live in user space, i.e. there is no backend
> driver in the kernel.  device_unregister() never gets called.  This is a
> resource leak.
> 
> Does this explain the problem sufficienctly?
Ah yes, I think that makes sense. Does xenbus_probe really do a
device_register() despite not finding a backend kernel driver to handles the
device? That would sound like the source of the problem, to me.

 -- Keir



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