From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751392AbdINBKw (ORCPT ); Wed, 13 Sep 2017 21:10:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:38964 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751311AbdINBKt (ORCPT ); Wed, 13 Sep 2017 21:10:49 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ADBFD218F9 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: Wed, 13 Sep 2017 18:10:48 -0700 From: Jaegeuk Kim To: Al Viro Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion Message-ID: <20170914011048.GA47448@jaegeuk-macbookpro.roam.corp.google.com> References: <20170913200941.39420-1-jaegeuk@kernel.org> <20170913230426.GN5426@ZenIV.linux.org.uk> <20170913233116.GA45354@jaegeuk-macbookpro.roam.corp.google.com> <20170913234437.GO5426@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170913234437.GO5426@ZenIV.linux.org.uk> 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/14, Al Viro wrote: > On Wed, Sep 13, 2017 at 04:31:16PM -0700, Jaegeuk Kim wrote: > > Hi Al, > > > > On 09/14, Al Viro wrote: > > > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > > > > + if (!retval && (flags & UMOUNT_WAIT)) { > > > > + if (likely(!(current->flags & PF_KTHREAD))) > > > > + task_work_run(); > > > > > > This is complete crap. The same damn thing will be done by > > > caller of sys_umount() pretty much immediately afterwards. > > > I'm not sure what it is that you are trying to paper over, > > > but this is just plain wrong. > > > > Okay. > > > > > What _is_ the semantics of UMOUNT_WAIT? What does it guarantee, > > > and what would be supplying it to umount(2)? > > > > When android tries to reboot the system, it calls umount(2) without any flag. > > Then, mntput_no_expire() will add delayed_mntput_work() which finally does > > cleanup_mnt() later. In the mean time, android proceeded to shutdown all > > the UFS devices. > > Why has task_work_add() failed? Or is that umount(2) issued by a kernel thread? Android triggers umount(2) by init process, which is definitely not a kernel thread. But, we've seen some kernel panics which say umount(2) was succeeded, but ext4 triggered a kernel panic due to EIO after then like below. I'm also not sure task_work_run() would be also safe enoughly. May I ask where I can find sys_umount() calls task_work_run()? [254012.860565] c4 12426 [] panic+0x184/0x37c [254012.860589] c4 12426 [] __ext4_abort+0x198/0x19c [254012.860606] c4 12426 [] ext4_put_super+0x80/0x2b4 [254012.860629] c4 12426 [] generic_shutdown_super+0x68/0xd0 [254012.860646] c4 12426 [] kill_block_super+0x1c/0x5c [254012.860663] c4 12426 [] deactivate_locked_super+0x5c/0xc0 [254012.860679] c4 12426 [] deactivate_super+0x68/0x74 [254012.860696] c4 12426 [] cleanup_mnt+0xb0/0x12c [254012.860712] c4 12426 [] delayed_mntput+0x38/0x4c [254012.860737] c4 12426 [] process_one_work+0x1e0/0x490 [254012.860753] c4 12426 [] worker_thread+0x314/0x494 [254012.860771] c4 12426 [] kthread+0xdc/0xec [254012.860790] c4 12426 [] ret_from_fork+0x10/0x30