From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751318AbbIEFMt (ORCPT ); Sat, 5 Sep 2015 01:12:49 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:57594 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800AbbIEFMo (ORCPT ); Sat, 5 Sep 2015 01:12:44 -0400 Date: Sat, 5 Sep 2015 06:12:34 +0100 From: Al Viro To: Linus Torvalds Cc: Eric Dumazet , Oleg Nesterov , "linux-kernel@vger.kernel.org" , Andrew Morton , Thomas Gleixner , Ingo Molnar , Maciej =?utf-8?Q?=C5=BBenczykowski?= Subject: Re: [PATCH] task_work: remove fifo ordering guarantee Message-ID: <20150905051232.GB22011@ZenIV.linux.org.uk> References: <1440816150.8932.123.camel@edumazet-glaptop2.roam.corp.google.com> <20150829124921.GA14973@redhat.com> <1440856650.8932.144.camel@edumazet-glaptop2.roam.corp.google.com> <1440857473.8932.146.camel@edumazet-glaptop2.roam.corp.google.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) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 29, 2015 at 10:08:30AM -0700, Linus Torvalds wrote: > Hmm. > > I'm wondering if we should just make close_files() (or maybe even > filp_close()) use a synchronous fput(). > > Iirc, the reason we delay fput() is that we had some nasty issues for > the generic fput case. It was called from interrupt context by the aio > code, and just in general there's a lot of nasty cases that can cause > the final fput to happen (so there are lockdep issues with the mmap > locks because the last fput being from munmap etc). > > Maybe I forget some detail - it's been several years by now - but I > think we could make the regular "close()" and "exit()" cases just use > the synchronous fput (it's called "__fput_sync()" and currently > explicitly limited to just kernel threads). > > Al? First of all, we'd better not count on e.g. delayed fput() *NOT* doing task_work_add() - we still need to check if any new work had been added. After all, final close() might very well have done a final mntput() on a lazy-unmounted filesystem, possibly leaving us with fs shutdown via task_work_add(). And if that sucker e.g. closes a socket, well, we are back to closing an opened struct file, with task_work_add() etc. I'm a bit nervious about filp_close() (that sucker is exported and widely abused), but close_files()... sure, shouldn't be a problem. And yes, we can teach __close_fd() to do the same. I really don't understand what's the benefit, though - it's about the case when we are closing the last descriptor for given opened file, so I would be rather surprised if slower path taken on the way out to userland was not lost in noise...