From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752614AbdK0OlZ (ORCPT ); Mon, 27 Nov 2017 09:41:25 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:32964 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752434AbdK0OlY (ORCPT ); Mon, 27 Nov 2017 09:41:24 -0500 Date: Mon, 27 Nov 2017 06:41:25 -0800 From: "Paul E. McKenney" To: Florian Weimer Cc: NeilBrown , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Triplett Subject: Re: [PATCH] VFS: use synchronize_rcu_expedited() in namespace_unlock() Reply-To: paulmck@linux.vnet.ibm.com References: <87y3nyd4pu.fsf@notabene.neil.brown.name> <20171026122743.GX3659@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-cbid: 17112714-0048-0000-0000-0000020BD43D X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008121; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000241; SDB=6.00951976; UDB=6.00480872; IPR=6.00732057; BA=6.00005715; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018208; XFM=3.00000015; UTC=2017-11-27 14:41:20 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17112714-0049-0000-0000-0000434B09DD Message-Id: <20171127144125.GF3624@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-27_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711270202 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 27, 2017 at 12:27:04PM +0100, Florian Weimer wrote: > On 10/26/2017 02:27 PM, Paul E. McKenney wrote: > >But just for completeness, one way to make this work across the board > >might be to instead use call_rcu(), with the callback function kicking > >off a workqueue handler to do the rest of the unmount. Of course, > >in saying that, I am ignoring any mutexes that you might be holding > >across this whole thing, and also ignoring any problems that might arise > >when returning to userspace with some portion of the unmount operation > >still pending. (For example, someone unmounting a filesystem and then > >immediately remounting that same filesystem.) > > You really need to complete all side effects of deallocating a > resource before returning to user space. Otherwise, it will never > be possible to allocate and deallocate resources in a tight loop > because you either get spurious failures because too many > unaccounted deallocations are stuck somewhere in the system (and the > user can't tell that this is due to a race), or you get an OOM > because the user manages to queue up too much state. > > We already have this problem with RLIMIT_NPROC, where waitpid etc. > return before the process is completely gone. On some > kernels/configurations, the resulting race is so wide that parallel > make no longer works reliable because it runs into fork failures. Or alternatively, use rcu_barrier() occasionally to wait for all preceding deferred deallocations. And there are quite a few other ways to take on this problem. Thanx, Paul