Johannes Berg wrote: > On Wed, 2007-07-04 at 16:48 +0200, Patrick McHardy wrote: > > >>Yes, although in both cases you have no guarantee how long its >>going to take, someone else could be flooding the receive queue. >>For userspace this is more likely to be a real problem though >>since the kernel will keep processing the queue as long as packets >>are in it, while userspace could be scheduled away. > > > Right, but in the case of wireless you'll have different problems if > that happens, namely your wireless card won't be reassociating etc. I > don't think it'll be a problem in practice.
Not by itself probably but a user could DoS your wireless connectivity this way. >>I'm not so sure myself whether netlink is really a good idea for >>userspace<->userspace communication because of the above reason. >>IIRC Herbert had the same doubts some time ago, I wonder what >>made him change his mind. > > > Hm. The reason I wanted it initially is that this way we can guarantee > that userspace programs work in either case and also that we have better > control over the various APIs. > > >>There is a notifier for userspace unicast socket releases, would adding >>another one for multicast groups help? > > > Huh I think that notifier is enough in fact. It'll be called if a > userspace process closes a socket or such, right? Might get a lot of > events for generic netlink but that should be acceptable since it'd only > need to check .pid to start with. I'm not sure, it would probably also have to be called when userspace unsubscribes from a group, no? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
