OpenVZ Forum


Home » Mailing lists » Devel » [PATCH] usbatm: Update to use the kthread api.
Re: [PATCH] usbatm: Update to use the kthread api. [message #17071 is a reply to message #16994] Fri, 15 December 2006 10:54 Go to previous messageGo to previous message
ebiederm is currently offline  ebiederm
Messages: 1354
Registered: February 2006
Senior Member
Duncan Sands <baldrick@free.fr> writes:

> Hi Eric,
>
> presumably the problem is that if the thread has spontaneously exited, and
> afterwards disconnect calls kthread_stop, then things go boom.  The same
> problem exists (though with lesser consequences) when sending a signal.
> There is already code in usbatm to avoid this problem with signals.  Why
> not just recycle it in the kthread_stop case?  I guess there is no
> problem if you can guarantee that the following occurs:
> if kthread_stop is ever called for the kthread, then the kthread only
> exits after seeing kthread_should_stop return true.

I suspect we can recycle the locking on the signal sending code.  At
least as a first pass.   I have almost digested the problem sufficiently
to write some code. Maybe this weekend.

>> To be clear I have a problem with using numeric pids of kernel threads,
>
> Yes, this is a problem with usbatm at the moment.
>
>> and with spawning threads from a possibly user space environment.
>
> Not the case with usbatm.  It is always spawned from khubd.

That is where I thought we were at, doing the conversion so it
is obvious and we can remove the use of kernel_thread and daemonize
would certainly be good.  The more shared infrastructure we can
reasonably have the more likely the code will function correctly.

Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [PATCH] Set a separate lockdep class for neighbour table's proxy_queue
Next Topic: Re: Getting the new RxRPC patches upstream
Goto Forum:
  


Current Time: Sun Jul 27 14:21:52 GMT 2025

Total time taken to generate the page: 0.57686 seconds