kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout <christophe@saout.de>]

Am So, den 15.02.2004 schrieb Christoph Hellwig um 20:46:

> > The only reason, I guess, is that it depends on this very small
> > dm-daemon thing:
> > http://people.sistina.com/~thornber/dm/patches/2.6-unstable/2.6.2/2.6.2-udm1/00016.patch
>
> Well, actually the above code should not enter the kernel tree at all.
> Care to rewrite dm-crypt to use Rusty's kthread code in -mm instead and
> submit a patch to Andrew?  Whenever he merges the kthread stuff to mainline
> he could just include dm-crypt then.

Sure I could.

But kthread is currently not a full replacement for dm-daemon. kthread
provides thread creation and destruction functions. But dm-daemon
additionaly does mainloop handling.

Usually, the dm-daemon client adds some work to a list under a spinlock
and calls dm_daemon_wake. The next time the thread runs it calls the
client work function which usually just grabs the whole list and
processes it.
The client work function can also indicate it wants periodic wakeup
using a return value which is currently used in the multipath target but
it's not sure whether this will be moved to a userspace daemon.

There seems to beg a small race conditition that can appear when using
only wake_up for notifies so dm-daemon uses an additional atomic_t
variable to make sure nothing gets missed. Just see the function
``daemon'' in dm-daemon.c.

Making dm-daemon use the kthread primitives would make dm-daemon a very
small and stupid wrapper. Changing all dm targets to handle worker
thread notification themselves would result in unnecessary code
duplication.

It seems to me that this functionality could perhaps be somehow added to
kthread without changing it too much... ?

I would like to double-check with Joe rushing forward on my own.