"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
>
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 locke
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 th
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
>> e
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
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 queu
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 prob
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
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 ++--
include/net/net_namespac
