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
|