From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752132AbbIEFm4 (ORCPT <rfc822;w@1wt.eu>);
	Sat, 5 Sep 2015 01:42:56 -0400
Received: from zeniv.linux.org.uk ([195.92.253.2]:57644 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751619AbbIEFmu (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 5 Sep 2015 01:42:50 -0400
Date: Sat, 5 Sep 2015 06:42:47 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>, Oleg Nesterov <oleg@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
        Maciej =?utf-8?Q?=C5=BBenczykowski?= <maze@google.com>
Subject: Re: [PATCH] task_work: remove fifo ordering guarantee
Message-ID: <20150905054247.GE22011@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>
 <CA+55aFwKAnKb4oTRRSes7ssXZ_cFJb6SsOVHhaYYSpFxd04yEg@mail.gmail.com>
 <20150905051232.GB22011@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150905051232.GB22011@ZenIV.linux.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Sep 05, 2015 at 06:12:34AM +0100, Al Viro wrote:

> 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...

OK, having found the beginning of the thread, I understand what is being
attempted, but... why the hell bother with FIFO in the first place?  AFAICS,
task_work_add() uses in VFS (final fput() and final mntput() alike)
do not care about the FIFO at all.

Sure, some out-of-tree mer^H^Hodule might rely on that.  So what?

IMO, unless we have a good in-tree reason for insisting on FIFO, dropping it
is the most obvious solution...