__put_task_struct unresolved when being used in modules

__put_task_struct unresolved when being used in modules

[Thomas Spatzier]

I have a module that keeps a reference to a task_struct and uses
get_task_struct and put_task_struct to increment/decrement the
task_struct's ref count.
Function __put_task_struct defined in kernel/fork.c does not have
an associated EXPORT_SYMBOL , so I get an unresolved symbol
error.
Is there a reason why __put_task_struct is not exported? Otherwise,
I would just add the missing EXPORT_SYMBOL. There are a number
of EXPORT_SYMBOLs already defined in fork.c anyway.

Regards,
Thomas

Re: __put_task_struct unresolved when being used in modules

[Christoph Hellwig]

On Wed, Oct 13, 2004 at 12:17:54PM +0200, Thomas Spatzier wrote:
> 
> 
> 
> 
> I have a module that keeps a reference to a task_struct and uses
> get_task_struct and put_task_struct to increment/decrement the
> task_struct's ref count.
> Function __put_task_struct defined in kernel/fork.c does not have
> an associated EXPORT_SYMBOL , so I get an unresolved symbol
> error.
> Is there a reason why __put_task_struct is not exported? Otherwise,
> I would just add the missing EXPORT_SYMBOL. There are a number
> of EXPORT_SYMBOLs already defined in fork.c anyway.

In general module shouldn't deal with task reference counts.  If we decide
you have a legitimate reason for doing this from a module after a review here
on lkml we could add an EXPORT_SYMBOL_GPL at the same time your module gets
merged.

p.s. this is really becoming a FAQ ;-)

Re: __put_task_struct unresolved when being used in modules

[Thomas Spatzier]

Christoph Hellwig <hch@infradead.org> wrote on 13.10.2004 12:29:55:
>
> In general module shouldn't deal with task reference counts.  If we
decide
> you have a legitimate reason for doing this from a module after a review
here
> on lkml we could add an EXPORT_SYMBOL_GPL at the same time your module
gets
> merged.
>
The module is actually already in the kernel (drivers/s390/net/qeth.ko).
We have a userspace daemon that registers with the kernel module and we
need to send a signal to that daemon, whenever the device driver detects
some
change in its managed devices. This is done in qeth_notify_processes (just
in
case you want to take a look ;-) ).
For this purpose, we store a pointer to the daemon's task_struct, so we can
send a signal to that task. However, if the daemon crashes for some reason,
we have an invalid task_struct pointer. If we had a counted reference, we
could check the state of the task before signaling. In case of the task
being gone, we would release our reference.
We had another idea for solving the problem: is there a possibility that
our module gets notified when the task dies, i.e. is there a notifier_chain
defined for task states? In that case we could do the cleanup of our
notifier list when we receive the notification.

Thomas

Re: __put_task_struct unresolved when being used in modules

[Andrew Morton]

Thomas Spatzier <thomas.spatzier@de.ibm.com> wrote:
>
> Christoph Hellwig <hch@infradead.org> wrote on 13.10.2004 12:29:55:
>  >
>  > In general module shouldn't deal with task reference counts.  If we
>  decide
>  > you have a legitimate reason for doing this from a module after a review
>  here
>  > on lkml we could add an EXPORT_SYMBOL_GPL at the same time your module
>  gets
>  > merged.
>  >
>  The module is actually already in the kernel (drivers/s390/net/qeth.ko).
>  We have a userspace daemon that registers with the kernel module and we
>  need to send a signal to that daemon, whenever the device driver detects
>  some
>  change in its managed devices. This is done in qeth_notify_processes (just
>  in
>  case you want to take a look ;-) ).
>  For this purpose, we store a pointer to the daemon's task_struct, so we can
>  send a signal to that task. However, if the daemon crashes for some reason,
>  we have an invalid task_struct pointer.

Drivers should not be holding references to userspace processes.  Your
daemons should instead be holding references to resources within the
driver.

IOW: the daemon should be holding an open file descriptor and should be
blocked in read() or select/poll waiting for activity on that fd.