From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755764Ab2DNDk5 (ORCPT ); Fri, 13 Apr 2012 23:40:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40258 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755027Ab2DNDk4 (ORCPT ); Fri, 13 Apr 2012 23:40:56 -0400 Date: Sat, 14 Apr 2012 05:39:53 +0200 From: Oleg Nesterov To: Linus Torvalds Cc: Andrew Morton , David Howells , Thomas Gleixner , Alexander Gordeev , Chris Zankel , David Smith , "Frank Ch. Eigler" , Geert Uytterhoeven , Larry Woodman , Peter Zijlstra , Tejun Heo , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/3] task_work_add: generic process-context callbacks Message-ID: <20120414033953.GA29189@redhat.com> References: <20120414021201.GA23385@redhat.com> <20120414021220.GA23393@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org probably I should also comment this part... On 04/13, Linus Torvalds wrote: > > Alternatively, you must make the rule be that the data can only be > freed by the caller *if* it was returned from "task_work_cancel()". Exactly. Once the caller does task_work_add(twork), it no longer "owns" this twork. But, if task_work_cancel() succeeds - you own it again. > But then you can't allocate it on the stack any more, and have to > allocate it separately. Yes, unless you do task_work_add/cancel(current). Oleg.