Patrick McHardy wrote:
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Maybe I can save you some time: we used to do down_trylock()
for the rtnl mutex, so senders would simply return if someone
else was already processing the queue *or* the rtnl was locked
for some other
Denis V. Lunev [EMAIL PROTECTED] writes:
The presence of the message in the queue during rtnl_unlock is quite
possible as normal user-kernel message processing path for rtnl is the
following:
netlink_sendmsg
netlink_unicast
netlink_sendskb
skb_queue_tail
Hmm, so it looks like we do not need this queue processing at all...
Regards,
Den
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Maybe I can save you some time: we used to do down_trylock()
for the rtnl mutex, so senders would simply return if someone
else was
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Maybe I can save you some time: we used to do down_trylock()
for the rtnl mutex, so senders would simply return if someone
else was already processing the queue *or* the rtnl was locked
for some other reason. In the first case
Eric W. Biederman wrote:
void rtnl_unlock(void)
{
- mutex_unlock(rtnl_mutex);
- if (rtnl rtnl-sk_receive_queue.qlen)
+ struct net *net;
+
+ /*
+ * Loop through all of the rtnl sockets until none of them (in
+ * a live network namespace) have queue packets.
+
Patrick McHardy [EMAIL PROTECTED] writes:
I'm wondering why this receive queue processing on unlock is still
necessary today, we don't do trylock in rtnetlink_rcv anymore, so
all senders will simply wait until the lock is released and then
process the queue.
Good question, I should probably
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
I'm wondering why this receive queue processing on unlock is still
necessary today, we don't do trylock in rtnetlink_rcv anymore, so
all senders will simply wait until the lock is released and then
process the queue.
Good
Patrick McHardy [EMAIL PROTECTED] writes:
Maybe I can save you some time: we used to do down_trylock()
for the rtnl mutex, so senders would simply return if someone
else was already processing the queue *or* the rtnl was locked
for some other reason. In the first case the process already
After this patch none of the netlink callback support anything
except the initial network namespace but the rtnetlink infrastructure
now handles multiple network namespaces.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux/rtnetlink.h |8 ++--
