Staging tree status for the .33 kernel merge

Serge E. Hallyn serge at
Mon Jan 4 17:38:10 UTC 2010

Quoting Ashwin Ganti (ashwin.ganti at
> On Sun, Jan 3, 2010 at 10:57 PM, Serge E. Hallyn <serge at> wrote:
> > Quoting Greg KH (greg at
> > ...
> >> This means, unless someone steps up and starts doing real work (not
> >> trivial spelling fixes) on the following drivers, they will be removed
> >> in the future kernel releases.
> >>
> >> ?- arlan, netwave, strip, wavelan - wireless drivers mentioned above
> >> ? ?that are on the way out. ?Slated for removal in 2.6.35
> >> ?- hv - Microsoft Hyper V drivers. ?The developers again seem to have
> >> ? ?disappeared, this is getting old. Slated for removal in 2.6.35
> >> ?- p9auth - this will be removed in .34 unless someone steps up.
> >
> > I think I've decided to try to push it. ?I'm working with some patches
> > at git://
> > (branch p9auth.jan3.4 is latest). ?I'll send patches as I feel they
> > are ready - so far they pass testcases, but are too new for me to
> > feel I should push them today.
> Thanks Serge!
> It is useful to continue to have this driver in the tree as there a
> few other people as well who have shown interest in using this. I have
> been recently contacted by guys at Glendix (
> who have started looking at using this driver.
> >
> > Ashwin, I'm curious whether you'd think the last patch
> > (;a=commitdiff;h=1662ba777140a39c21a9b647459d2deab8ffe1ca)
> > would be a problem with any userspace - but I assume there is no
> > legacy userspace to really worry about?
> There is no legacy user space support yet for Linux. This should be
> fine in that sense.
> I still need to look at the patches in detail though but what is the
> motivation for this change?

Well, to have a login daemon be unprivileged, it needs some way to
set groups without CAP_SETGID.  I was playing with some toy frontend
and backend (i.e. login and factotum) code and this seemed a nice
simple way to do it.

> Please also cc rsc at and ericvh at as well when you
> send out these patches for review.

Will do, thanks.

> > Apart from plenty more cleanups, another more fundamental issue to
> > address is how to stop unused caphash entries from piling up in
> > memory. ?Put a timeout on them? ?Let privileged userspace list and
> > occasionally delete them? ?Associate a target task with each entry,
> > where either the task or its decendent can use the capability, but
> > if the task dies we free the caphash entry?
> So, there are a couple of options here (I favor the second approach):
> 1. We can add a timer to expire the capabilities.
> 2. Add a creation time stamp to every capability. Whenever a
> capability is used (i.e. written to /dev/caphash) we can go through
> the list in the kernel and reap the ones whose time stamp has expired.
> We can optimize the data structure later to make this faster.

Ok, I'll do that when I get a chance, do some more testing, and send
out in the next two weeks.


More information about the devel mailing list