From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751878AbdK0L1J (ORCPT ); Mon, 27 Nov 2017 06:27:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57554 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751375AbdK0L1I (ORCPT ); Mon, 27 Nov 2017 06:27:08 -0500 Subject: Re: [PATCH] VFS: use synchronize_rcu_expedited() in namespace_unlock() To: paulmck@linux.vnet.ibm.com, NeilBrown Cc: Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Triplett References: <87y3nyd4pu.fsf@notabene.neil.brown.name> <20171026122743.GX3659@linux.vnet.ibm.com> From: Florian Weimer Message-ID: Date: Mon, 27 Nov 2017 12:27:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171026122743.GX3659@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 27 Nov 2017 11:27:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks, Florian