From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 2/5] net: Make rtnetlink infrastructure network namespace aware Date: Sun, 30 Sep 2007 17:39:54 +0200 Message-ID: <46FFC34A.3020701@trash.net> References: <46FE72E3.3000402@trash.net> <46FE8FD3.2030308@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: netdev-owner@vger.kernel.org To: "Eric W. Biederman" Cc: David Miller , netdev@vger.kernel.org, Linux Containers List-Id: containers.vger.kernel.org Eric W. Biederman wrote: > Patrick McHardy 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()?