|To:||Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>|
|Subject:||Re: [PATCH] Improve behaviour of Netlink Sockets|
|From:||Pablo Neira <pablo@xxxxxxxxxxx>|
|Date:||Mon, 20 Sep 2004 00:49:10 +0200|
|Cc:||netdev@xxxxxxxxxxx, "David S. Miller" <davem@xxxxxxxxxx>|
|References:||<414D0CCD.email@example.com> <E1C8way-0000aHfirstname.lastname@example.org> <20040919120249.GA5963@gondor.apana.org.au> <20040919120730.GA6005@gondor.apana.org.au> <414DF111.email@example.com> <20040919215328.GA9573@gondor.apana.org.au>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7|
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.
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.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||[PATCH 2.6.9-rc2-mm1 1/1] r8169: default on disabling PCIDAC, Francois Romieu|
|Next by Date:||Re: [PATCH] Improve behaviour of Netlink Sockets, Pablo Neira|
|Previous by Thread:||Re: [PATCH] Improve behaviour of Netlink Sockets, Herbert Xu|
|Next by Thread:||Re: [PATCH] Improve behaviour of Netlink Sockets, Herbert Xu|
|Indexes:||[Date] [Thread] [Top] [All Lists]|