[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter-devel
Subject:    Re: Threading and libipq
From:       James Morris <jmorris () intercode ! com ! au>
Date:       2001-05-25 12:08:42
[Download RAW message or body]

On 25 May 2001, Per Cederqvist wrote:

> libipq isn't thread safe.  The error code is stored in a global
> variable.

Yep, this is on the TODO list as noted in libipq(3).

> But the thread unsafety lies deeper than that.  Consider the following
> lines from netlink_receive_user_skb() (Linux 2.4.4):
>
> 	if (nlq->peer.pid && !nlq->peer.died
> 	    && (nlq->peer.pid != nlh->nlmsg_pid)) {
> 	    	printk(KERN_WARNING "ip_queue: peer pid changed from %d to "
> 	    	      "%d, flushing queue\n", nlq->peer.pid, nlh->nlmsg_pid);
> 		ipq_flush(nlq);
> 	}
> 	nlq->peer.pid = nlh->nlmsg_pid;
>
> Unless I misread them (and their context) this means that I cannot
> have one thread that reads the queued data and another that replies to
> them.  (When using current versions of glibc and linux-threads, each
> thread gets a unique pid.)

As the underlying Netlink code is connectionless, much of the logic in
ip_queue is devoted to maintaining state between the userspace process and
the queue, including detecting and recovering from communication errors
and termination or change of the userspace process.  The queue module must
know whether a packet has been delivered to userspace, and be able to
determine when a client process has terminated.

I'm not sure how to solve this cleanly for linux-threads.

> Is it really necessary to update nlq->peer.pid each time a message is
> sent to the kernel?  Wouldn't it be good enough to do so only if the
> old peer has died?

Yes, this should be changed so that the field is updated only when the
peer PID changes.  But this won't help your problem, the module does not
actually know if the peer has died at that point, and is assuming that the
latest process to send a message is the correct peer.

It would be useful to have a reliable datagram mode for Netlink to solve
some of these issues, but possibly not worth the added complexity.

- James
-- 
James Morris
<jmorris@intercode.com.au>

[prev in list] [next in list] [prev in thread] [next in thread]