All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Denis V. Lunev" <den@sw.ru>
To: Patrick McHardy <kaber@trash.net>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Linux Containers <containers@lists.osdl.org>,
	netdev@vger.kernel.org, David Miller <davem@davemloft.net>
Subject: Re: [Devel] Re: [PATCH 2/5] net: Make rtnetlink infrastructure network namespace aware
Date: Mon, 01 Oct 2007 12:26:52 +0400	[thread overview]
Message-ID: <4700AF4C.6020509@sw.ru> (raw)
In-Reply-To: <46FFC34A.3020701@trash.net>

Patrick McHardy wrote:
> Eric W. Biederman wrote:
>> Patrick McHardy <kaber@trash.net> 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
>>> processing the queue would also process the new messages, but
>>> if it the rtnl was locked for some other reason (for example
>>> during module registration) the message would sit in the
>>> queue until the next rtnetlink sendmsg call, which is why
>>> rtnl_unlock does queue processing. Commit 6756ae4b changed
>>> the down_trylock to mutex_lock, so senders will now simply wait
>>> until the mutex is released and then call netlink_run_queue
>>> themselves. This means its not needed anymore.
>>
>> Sounds reasonable.
>>
>> I started looking through the code paths and I currently cannot
>> see anything that would leave a message on a kernel rtnl socket.
>>
>> However I did a quick test adding a WARN_ON if there were any messages
>> found in the queue during rtnl_unlock and I found this code path
>> getting invoked from linkwatch_event.  So there is clearly something I
>> don't understand, and it sounds at odds just a bit from your
>> description.
> 
> 
> That sounds like a bug. Did you place the WARN_ON before or after
> the mutex_unlock()?

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
          netlink_data_ready
              rtnetlink_rcv
                  mutex_lock(&rtnl_mutex);
                  netlink_run_queue(sk, qlen, &rtnetlink_rcv_msg);
                  mutex_unlock(&rtnl_mutex);

so, the presence of the packet in the rtnl queue on rtnl_unlock is
normal race with a rtnetlink_rcv for me.

Regards,
	Den

  reply	other threads:[~2007-10-01  8:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-29  1:00 [PATCH 1/5] net: Modify all rtnetlink methods to only work in the initial namespace Eric W. Biederman
2007-09-29  1:00 ` Eric W. Biederman
2007-09-29  1:02 ` [PATCH 2/5] net: Make rtnetlink infrastructure network namespace aware Eric W. Biederman
2007-09-29  1:02   ` Eric W. Biederman
     [not found]   ` <m1hcle9td8.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-09-29  1:04     ` [PATCH 3/5] net: Make the netlink methods in rtnetlink handle multiple network namespaces Eric W. Biederman
2007-09-29  1:07       ` [PATCH 4/5] net: Make AF_PACKET " Eric W. Biederman
2007-09-29  1:07         ` Eric W. Biederman
2007-09-29  1:08         ` [PATCH 5/5] net: Make AF_UNIX per network namespace safe Eric W. Biederman
2007-09-29  1:08           ` Eric W. Biederman
2007-09-29 15:47           ` Patrick McHardy
2007-09-29 17:03             ` Eric W. Biederman
2007-09-29 17:50               ` Patrick McHardy
2007-09-29 15:44   ` [PATCH 2/5] net: Make rtnetlink infrastructure network namespace aware Patrick McHardy
2007-09-29 16:51     ` Eric W. Biederman
2007-09-29 17:48       ` Patrick McHardy
2007-09-29 21:00         ` Eric W. Biederman
2007-09-30 13:13           ` [Devel] " Denis V. Lunev
2007-09-30 15:39           ` Patrick McHardy
2007-10-01  8:26             ` Denis V. Lunev [this message]
2007-10-01  8:45               ` [Devel] " Eric W. Biederman
2007-10-10 12:35 ` [Devel] [PATCH 1/5] net: Modify all rtnetlink methods to only work in the initial namespace Denis V. Lunev
2007-10-10 14:05   ` Daniel Lezcano
2007-10-10 14:29     ` Denis V. Lunev
2007-10-10 19:37   ` Eric W. Biederman
     [not found]     ` <m13awilq1r.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-10-11  6:36       ` Denis V. Lunev
     [not found]         ` <470DC48A.30603-3ImXcnM4P+0@public.gmane.org>
2007-10-11  7:57           ` Eric W. Biederman
     [not found]             ` <m1r6k2gk2w.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-10-11 12:18               ` Denis V. Lunev
     [not found]                 ` <470E149A.3040803-3ImXcnM4P+0@public.gmane.org>
2007-10-11 17:08                   ` Eric W. Biederman
     [not found]                     ` <m1przlbmu4.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-10-11 17:28                       ` Denis V. Lunev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4700AF4C.6020509@sw.ru \
    --to=den@sw.ru \
    --cc=containers@lists.osdl.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.