Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752353AbbH2DTo (ORCPT ); Fri, 28 Aug 2015 23:19:44 -0400 Received: from mail-io0-f171.google.com ([209.85.223.171]:36180 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751505AbbH2DTn (ORCPT ); Fri, 28 Aug 2015 23:19:43 -0400 MIME-Version: 1.0 In-Reply-To: <1440816150.8932.123.camel@edumazet-glaptop2.roam.corp.google.com> References: <1440816150.8932.123.camel@edumazet-glaptop2.roam.corp.google.com> Date: Fri, 28 Aug 2015 20:19:42 -0700 X-Google-Sender-Auth: Rs9BRttsM87dy3onFprON6wLCrA Message-ID: Subject: Re: [PATCH] task_work: remove fifo ordering guarantee From: Linus Torvalds To: Eric Dumazet Cc: Al Viro , "linux-kernel@vger.kernel.org" , Oleg Nesterov , 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: 1092 Lines: 26 On Fri, Aug 28, 2015 at 7:42 PM, Eric Dumazet wrote: > > We could add yet another cond_resched() in the reverse loop, or we > can simply remove the reversal, as I do not think anything > would depend on order of task_work_add() submitted works. So I think this should be ok, with things like file closing not really caring about ordering as far as I can tell. However, has anybody gone through all the task-work users? I looked quickly at the task_work_add() cases, and didn't see anything that looked like it would care, but others should look too. In the vfs, theres' the delayed fput and mnt freeing, and there's a keyring installation one. The threaded irq handlers use it as that exit-time hack, which certainly shouldn't care, and there's some uprobe thing. Can anybody see anything fishy? 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/