Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753797AbbKXO4y (ORCPT ); Tue, 24 Nov 2015 09:56:54 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:55559 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753071AbbKXO4w (ORCPT ); Tue, 24 Nov 2015 09:56:52 -0500 Date: Tue, 24 Nov 2015 15:56:41 +0100 From: Peter Zijlstra To: Petr Mladek Cc: Tejun Heo , Andrew Morton , Oleg Nesterov , Ingo Molnar , Steven Rostedt , "Paul E. McKenney" , Josh Triplett , Thomas Gleixner , Linus Torvalds , Jiri Kosina , Borislav Petkov , Michal Hocko , linux-mm@kvack.org, Vlastimil Babka , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 07/22] kthread: Detect when a kthread work is used by more workers Message-ID: <20151124145641.GV17308@twins.programming.kicks-ass.net> References: <1447853127-3461-1-git-send-email-pmladek@suse.com> <1447853127-3461-8-git-send-email-pmladek@suse.com> <20151123222703.GH19072@mtj.duckdns.org> <20151124100650.GF10750@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151124100650.GF10750@pathway.suse.cz> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1279 Lines: 33 On Tue, Nov 24, 2015 at 11:06:50AM +0100, Petr Mladek wrote: > On Mon 2015-11-23 17:27:03, Tejun Heo wrote: > > Hello, > > > > On Wed, Nov 18, 2015 at 02:25:12PM +0100, Petr Mladek wrote: > > > @@ -610,6 +625,12 @@ repeat: > > > if (work) { > > > __set_current_state(TASK_RUNNING); > > > work->func(work); > > > + > > > + spin_lock_irq(&worker->lock); > > > + /* Allow to queue the work into another worker */ > > > + if (!kthread_work_pending(work)) > > > + work->worker = NULL; > > > + spin_unlock_irq(&worker->lock); > > > > Doesn't this mean that the work item can't be freed from its callback? > > That pattern tends to happen regularly. > > I am not sure if I understand your question. Do you mean switching > work->func during the life time of the struct kthread_work? This > should not be affected by the above code. No, work->func(work) doing: kfree(work). That is indeed something quite frequently done, and since you now have references to work after calling func, things would go *boom* rather quickly. -- 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/