diff options
author | Denis V. Lunev <den@openvz.org> | 2007-10-10 21:12:58 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2007-10-10 21:12:58 -0700 |
commit | 1536cc0d55a2820b71daf912060fe43ec15630c2 (patch) | |
tree | 0561a25ba3623e987fb801da529ea7c2270f0d11 /CREDITS | |
parent | d1ec3b772233826bf156284170632563790dbabf (diff) | |
download | linux-3.10-1536cc0d55a2820b71daf912060fe43ec15630c2.tar.gz linux-3.10-1536cc0d55a2820b71daf912060fe43ec15630c2.tar.bz2 linux-3.10-1536cc0d55a2820b71daf912060fe43ec15630c2.zip |
[NET]: rtnl_unlock cleanups
There is no need to process outstanding netlink user->kernel packets
during rtnl_unlock now. There is no rtnl_trylock in the rtnetlink_rcv
anymore.
Normal code path is the following:
netlink_sendmsg
netlink_unicast
netlink_sendskb
skb_queue_tail
netlink_data_ready
rtnetlink_rcv
mutex_lock(&rtnl_mutex);
netlink_run_queue(sk, qlen, &rtnetlink_rcv_msg);
mutex_unlock(&rtnl_mutex);
So, it is possible, that packets can be present in the rtnl->sk_receive_queue
during rtnl_unlock, but there is no need to process them at that moment as
rtnetlink_rcv for that packet is pending.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'CREDITS')
0 files changed, 0 insertions, 0 deletions