From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org ([198.145.29.96]:56456 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727012AbeGYFYw (ORCPT ); Wed, 25 Jul 2018 01:24:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 24 Jul 2018 21:15:05 -0700 From: isaacm@codeaurora.org To: Sebastian Andrzej Siewior Cc: peterz@infradead.org, matt@codeblueprint.co.uk, mingo@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, psodagud@codeaurora.org, gregkh@linuxfoundation.org, pkondeti@codeaurora.org, stable@vger.kernel.org Subject: Re: [PATCH] stop_machine: Disable preemption after queueing stopper threads In-Reply-To: <20180724062350.nlem2suuy5wlxpts@linutronix.de> References: <1531856129-9871-1-git-send-email-isaacm@codeaurora.org> <20180724062350.nlem2suuy5wlxpts@linutronix.de> Message-ID: <9d89ec1c84546e7b8044b3d2b24fc175@codeaurora.org> Sender: stable-owner@vger.kernel.org List-ID: Hi Sebastian, Thanks for the response. "I haven't look in detail at this but your new preempt_disable() makes things unbalanced for the err != 0 case." This cannot happen. The only possible return values of this function are -ENOENT or 0. In the case where we return -ENOENT, we'll go straight to "unlock," which releases the two locks being held, but doesn't disable preemption, and since err != we won't call preemption_enable. In the case where we return 0, then that means the works were queued successfully, and preemption was disabled, and we'll fall into the if branch, after releasing the locks, and enable preemption, which is correct. In either case, there is no imbalance between the preemption_[disable/enable] calls. Thanks, Isaac Manjarres On 2018-07-23 23:23, Sebastian Andrzej Siewior wrote: > On 2018-07-23 18:13:48 [-0700], isaacm@codeaurora.org wrote: >> Hi all, > Hi, > >> Are there any comments about this patch? > > I haven't look in detail at this but your new preempt_disable() makes > things unbalanced for the err != 0 case. > >> Thanks, >> Isaac Manjarres > > Sebastian