Subject: Re: [PATCH] Improve behaviour of Netlink Sockets

From: Pablo Neira <[email-masked]>
Date: Sun, 19 Sep 2004 22:50:36 +0200

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