Re: [PATCH] Improve behaviour of Netlink Sockets

[Pablo Neira <pablo@xxxxxxxxxxx>]

Hi Herbert,

Sorry, if i repeat things, I'm not willing to be annoying, just clarifying.

I'm always talking all the time about sending information from kernel 
space to user space where I found the problem. There's no problem in 
doing on the other way, in that case buffer never gets full.

Herbert Xu wrote:

> Workaround for what? Please define your problem.
>  
Two problems:

a) if you request information via nl sockets from user space and a 
kernel module doesn't use the dontwait flag (I know, *nobody* is doing 
this at the moment, so currently broadcast/unicast never wait as you 
remarked).

When we request info from user space (sendmsg), you execute the callback 
from a module which usually replies with some information 
(netlink_unicast). The problem happens if the size of the information is 
too big for the buffer. In that case, before using applying my patch, it 
hangs (in <2.6.9-rc1, it puts it to sleep if buffer gets full). I'm 
talking about using unicast/broadcast without dontwait flag.

b) A module needs to send a lot of information from kernel space to user 
space, if buffer gets full quickly, buffer overruns and 
netlink_unicast/broadcast never wait, so they drop packets.

Why someone could call netlink_unicast/broadcast from a module telling 
them to wait if necessary? if that module want to care about a possible 
message drop. This happens if you stress nl sockets. This way netlink 
sockets behave well with an important workload without dropping 
messages. So the user space part doesn't get that annoying -enobufs error.

> Your original message mentioned a dead-lock, which is now obviously non-existant.
>  

it exists if you use netlink_unicast/broadcast telling them to wait, so 
it's not a real problem for current applications because they tell 
netlink_unicast/broadcast not to wait.

regards,
Pablo