Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753247AbbKWW63 (ORCPT ); Mon, 23 Nov 2015 17:58:29 -0500 Received: from mail-yk0-f179.google.com ([209.85.160.179]:36270 "EHLO mail-yk0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751255AbbKWW61 (ORCPT ); Mon, 23 Nov 2015 17:58:27 -0500 Date: Mon, 23 Nov 2015 17:58:23 -0500 From: Tejun Heo To: Petr Mladek Cc: Andrew Morton , Oleg Nesterov , Ingo Molnar , Peter Zijlstra , 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 09/22] kthread: Allow to cancel kthread work Message-ID: <20151123225823.GI19072@mtj.duckdns.org> References: <1447853127-3461-1-git-send-email-pmladek@suse.com> <1447853127-3461-10-git-send-email-pmladek@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1447853127-3461-10-git-send-email-pmladek@suse.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1279 Lines: 54 Hello, On Wed, Nov 18, 2015 at 02:25:14PM +0100, Petr Mladek wrote: > +static int > +try_to_cancel_kthread_work(struct kthread_work *work, > + spinlock_t *lock, > + unsigned long *flags) > +{ > + int ret = 0; > + > + if (work->timer) { > + /* Try to cancel the timer if pending. */ > + if (del_timer(work->timer)) { > + ret = 1; > + goto out; > + } > + > + /* Are we racing with the timer callback? */ > + if (timer_active(work->timer)) { > + /* Bad luck, need to avoid a deadlock. */ > + spin_unlock_irqrestore(lock, *flags); > + del_timer_sync(work->timer); > + ret = -EAGAIN; > + goto out; > + } As the timer side is already kinda trylocking anyway, can't the cancel path be made simpler? Sth like lock(worker); work->canceling = true; del_timer_sync(work->timer); unlock(worker); And the timer can do (ignoring the multiple worker support, do we even need that?) while (!trylock(worker)) { if (work->canceling) return; cpu_relax(); } queue; unlock(worker); Thanks. -- tejun -- 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/