Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752761AbbH2RIc (ORCPT ); Sat, 29 Aug 2015 13:08:32 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:36197 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbbH2RIb (ORCPT ); Sat, 29 Aug 2015 13:08:31 -0400 MIME-Version: 1.0 In-Reply-To: <1440857473.8932.146.camel@edumazet-glaptop2.roam.corp.google.com> 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> Date: Sat, 29 Aug 2015 10:08:30 -0700 X-Google-Sender-Auth: HcEXlRboB44INqo0j9qFViY-KAg Message-ID: Subject: Re: [PATCH] task_work: remove fifo ordering guarantee From: Linus Torvalds To: Eric Dumazet Cc: Oleg Nesterov , Al Viro , "linux-kernel@vger.kernel.org" , Andrew Morton , Thomas Gleixner , Ingo Molnar , =?UTF-8?Q?Maciej_=C5=BBenczykowski?= Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1463 Lines: 35 On Sat, Aug 29, 2015 at 7:11 AM, Eric Dumazet wrote: > > If this needs to be kept, maybe then add following, to make sure > we flush the list at most every BITS_PER_LONG files 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? Because it feels all kinds of stupid to add things to the task-work queue just to then remove it almost immediately again. And close_files() is also called from various contexts. but the whole "put the final 'files_struct' case is certainly not at all as special as the 'put the final file'. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/