From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752208AbcEDOML (ORCPT ); Wed, 4 May 2016 10:12:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:32924 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750857AbcEDOMJ (ORCPT ); Wed, 4 May 2016 10:12:09 -0400 Date: Wed, 4 May 2016 16:12:05 +0200 From: Petr Mladek To: Josh Poimboeuf Cc: Jessica Yu , Jiri Kosina , Miroslav Benes , Ingo Molnar , Peter Zijlstra , Michael Ellerman , Heiko Carstens , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, Vojtech Pavlik , Jiri Slaby , Chris J Arges , Andy Lutomirski Subject: Re: barriers: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model Message-ID: <20160504141205.GS2749@pathway.suse.cz> References: <20160504123940.GR2749@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160504123940.GR2749@pathway.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2016-05-04 14:39:40, Petr Mladek wrote: > * > * Note that the task must never be migrated to the target > * state when being inside this ftrace handler. > */ > > We might want to move the second paragraph on top of the function. > It is a basic and important fact. It actually explains why the first > read barrier is not needed when the patch is being disabled. I wrote the statement partly intuitively. I think that it is really somehow important. And I am slightly in doubts if we are on the safe side. First, why is it important that the task->patch_state is not switched when being inside the ftrace handler? If we are inside the handler, we are kind-of inside the called function. And the basic idea of this consistency model is that we must not switch a task when it is inside a patched function. This is normally decided by the stack. The handler is a bit special because it is called right before the function. If it was the only patched function on the stack, it would not matter if we choose the new or old code. Both decisions would be safe for the moment. The fun starts when the function calls another patched function. The other patched function must be called consistently with the first one. If the first function was from the patch, the other must be from the patch as well and vice versa. This is why we must not switch task->patch_state dangerously when being inside the ftrace handler. Now I am not sure if this condition is fulfilled. The ftrace handler is called as the very first instruction of the function. Does not it break the stack validity? Could we sleep inside the ftrace handler? Will the patched function be detected on the stack? Or is my brain already too far in the fantasy world? Best regards, Petr