Herbert Xu wrote:
On Sun, Sep 19, 2004 at 05:58:52PM +1000, Herbert Xu wrote:
Besides, for any netlink socket but the first for a process, they'll
all have negative pid's which have nothing to do with the real pid.
So I really think that the wake_up_process hunk is bogus.
Another reason why this is bogus.
Most kernel users of unicast have a send timeout setting of 0. Therefore
your wake_up_process() call will never happen when netlink_attachskb is
called by the kernel.
Yes, I didn't modify MSG_DONTWAIT + unicast behaviour and I've never
wanted to. Actually my patch is not addressed to that case, my intention
is improving netlink socket with when sending a lot of information from
kernel to user in a short time, in this case socket overruns easily.
Which are those applications? for example, netfilter modules like
ip_queue and ipt_ULOG. Even more, these applications are in interrupt
context and, if I'm not wrong, I realized that there's some problems
using netlink sockets in this context, for example, see netlink_ack
allocating a skb with GFP_KERNEL flag, it hits a bug slab.
Worse still, previously if a netlink request blocked indefinitely it
only did that in the context of the calling process. Now it'll
dead-lock the entire system because you're using the generic work
queue.
Hebert, I don't see such case, please could you detail it a bit more?
regards,
Pablo
|