Re: [PATCH] Improve behaviour of Netlink Sockets

On Mon, Sep 20, 2004 at 12:49:10AM +0200, Pablo Neira wrote:

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

You're alright.  We're on the same side :)

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.

Yes I understand.

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).

And if anybody does that then they are buggy.  So let's not slow everybody
down for the sake of a non-existant buggy kernel implementation.

There is no point for the kernel to wait at all.  For unicast sockets
used for sending commands to the kernel, you should never get overruns
if you are reading your responses correctly and have set the queue size
correctly.
 

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.

I agree that this may be a problem for some, but I don't see how your
patch addresses it.  For the case of ip_queue the kernel simply cannot
wait since it just creates a queue through the backdoor.  You might as
well just increase your receive queue length.

And if your application can't keep up with the flow of packets, then
whatever we do in the kernel is not going to help.

Congestion control that Jamal talked about is certainly a good idea in
many situations.  But it can't be applied in the situation you're in
because ip_queue can't back off.

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.

I don't understand this paragraph.

quoted

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.

s/applications/kernel implementation/

As I said above, if the kernel waits then it's a bug.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt