* Steve Grubb (sgrubb(a)redhat.com) wrote:
There's design flaw (in my opinion) regarding how this function
works. It's
purpose is to try to send packets to userspace. It calls netlink_unicast. If
the return value is < 0, it claims the netlink socket is too busy and marks a
packet as lost.
It tries to backlog the packet (it requeues the skb). My experience is
it's never made a difference (but that could be an issue because of the
retry happening too fast). Once the netlink socket send does EAGAIN
it's very likely to not recover (but hey, at least it's not a huge
memory leak like it used to be ;-)
The fact is that as long as we have space in the backlog, we
don't have to
lose a packet do we? Can we not defer claiming we've lost one and try again
later?
We do that. But 5 retries on same audit buffer sklist causes the real
error.
What is the purpose of the backlog if we can't defer delivery?
Also,
shouldn't we put retval in the "too busy" message to help troubleshooting?
Sure could.
thanks,
-chris
--
Linux Security Modules
http://lsm.immunix.org http://lsm.bkbits.net