From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935071AbcKNSOg (ORCPT ); Mon, 14 Nov 2016 13:14:36 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:48115 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932899AbcKNSOd (ORCPT ); Mon, 14 Nov 2016 13:14:33 -0500 Date: Mon, 14 Nov 2016 10:14:25 -0800 From: "Paul E. McKenney" To: Cong Wang Cc: Rolf Neugebauer , LKML , Linux Kernel Network Developers , Justin Cormack , Ian Campbell Subject: Re: Long delays creating a netns after deleting one (possibly RCU related) Reply-To: paulmck@linux.vnet.ibm.com References: <20161110212404.GB4127@linux.vnet.ibm.com> <20161112002347.GL4127@linux.vnet.ibm.com> <20161114162417.GJ4127@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16111418-0016-0000-0000-0000052B80DC X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006077; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00780628; UDB=6.00376452; IPR=6.00558129; BA=6.00004878; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013322; XFM=3.00000011; UTC=2016-11-14 18:14:30 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16111418-0017-0000-0000-000034A2FD7D Message-Id: <20161114181425.GN4127@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-14_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611140366 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 14, 2016 at 09:44:35AM -0800, Cong Wang wrote: > On Mon, Nov 14, 2016 at 8:24 AM, Paul E. McKenney > wrote: > > On Sun, Nov 13, 2016 at 10:47:01PM -0800, Cong Wang wrote: > >> On Fri, Nov 11, 2016 at 4:55 PM, Cong Wang wrote: > >> > On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney > >> > wrote: > >> >> > >> >> Ah! This net_mutex is different than RTNL. Should synchronize_net() be > >> >> modified to check for net_mutex being held in addition to the current > >> >> checks for RTNL being held? > >> >> > >> > > >> > Good point! > >> > > >> > Like commit be3fc413da9eb17cce0991f214ab0, checking > >> > for net_mutex for this case seems to be an optimization, I assume > >> > synchronize_rcu_expedited() and synchronize_rcu() have the same > >> > behavior... > >> > >> Thinking a bit more, I think commit be3fc413da9eb17cce0991f > >> gets wrong on rtnl_is_locked(), the lock could be locked by other > >> process not by the current one, therefore it should be > >> lockdep_rtnl_is_held() which, however, is defined only when LOCKDEP > >> is enabled... Sigh. > >> > >> I don't see any better way than letting callers decide if they want the > >> expedited version or not, but this requires changes of all callers of > >> synchronize_net(). Hm. > > > > I must confess that I don't understand how it would help to use an > > expedited grace period when some other process is holding RTNL. > > In contrast, I do well understand how it helps when the current process > > is holding RTNL. > > Yeah, this is exactly my point. And same for ASSERT_RTNL() which checks > rtnl_is_locked(), clearly we need to assert "it is held by the current process" > rather than "it is locked by whatever process". > > But given *_is_held() is always defined by LOCKDEP, so we probably need > mutex to provide such a helper directly, mutex->owner is not always defined > either. :-/ There is always the option of making acquisition and release set a per-task variable that can be tested. (Where did I put that asbestos suit, anyway?) Thanx, Paul