From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753331AbdIURQt (ORCPT ); Thu, 21 Sep 2017 13:16:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:51080 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751809AbdIURQp (ORCPT ); Thu, 21 Sep 2017 13:16:45 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E30A6218F8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jaegeuk@kernel.org Date: Thu, 21 Sep 2017 10:16:44 -0700 From: Jaegeuk Kim To: "Theodore Ts'o" , Al Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [PATCH v2] vfs: introduce UMOUNT_WAIT which waits for umount completion Message-ID: <20170921171644.GA3813@jaegeuk-macbookpro.roam.corp.google.com> References: <20170913200941.39420-1-jaegeuk@kernel.org> <20170920173831.GA7151@jaegeuk-macbookpro.roam.corp.google.com> <20170920183825.GD32076@ZenIV.linux.org.uk> <20170921003409.GA11365@jaegeuk-macbookpro.roam.corp.google.com> <20170921024251.GE32076@ZenIV.linux.org.uk> <20170921050237.GA28821@jaegeuk-macbookpro.roam.corp.google.com> <20170921144809.wv6546fqtentm7vv@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170921144809.wv6546fqtentm7vv@thunk.org> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/21, Theodore Ts'o wrote: > On Wed, Sep 20, 2017 at 10:02:37PM -0700, Jaegeuk Kim wrote: > > > > Yes, and actually, android retries umount(2) for several seconds, if it gets > > failure. So, first I thought it'd be better to make umount() more deterministic. > > > > I'm not sure how many times we can retry and wait for this. IMHO, it'd be better > > to use this together with the new flag, since this can detect unclosed namespace > > given successful umount(2). > > Even if you could make umount wait for the binder deferred workqueue > to exit, if it takes time, it takes time. And that's not the core > VFS's fault. It's binder's. > > So... why not fix this by adding a binder ioctl which forces its > workqueue to be flushed, and use that *before* you try calling mount? Yes, we can, but I'm not 100% sure this happens only by binder. This is caused by delayed_fput/mntput called by any kernel thread which would be much generic. > If that binder ioctl takes minutes or hours to complete, then that's a > binder bug, and needs to be fixed in binder. > > - Ted