From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752741AbdJTJDm (ORCPT ); Fri, 20 Oct 2017 05:03:42 -0400 Received: from mx2.suse.de ([195.135.220.15]:50329 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752414AbdJTJDl (ORCPT ); Fri, 20 Oct 2017 05:03:41 -0400 Date: Fri, 20 Oct 2017 11:03:39 +0200 (CEST) From: Miroslav Benes To: Jason Baron cc: Josh Poimboeuf , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, jeyu@kernel.org, jikos@kernel.org, pmladek@suse.com Subject: Re: [PATCH v3 2/2] livepatch: add atomic replace In-Reply-To: <0a1bb3fa-b43b-2da8-9371-5d4e9c9fbfda@akamai.com> Message-ID: References: <20171006223247.fkkrrtxydq33c7dw@treble> <3b0c1c00-e4ae-13ab-434d-73d8a5e5a60d@akamai.com> <0a1bb3fa-b43b-2da8-9371-5d4e9c9fbfda@akamai.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > It is even more complicated and it is not connected only to atomic replace > > patch (I realized this while reading the first part of your email and > > then you confirmed it with this paragraph). The consistency model is > > broken with respect to immediate patches. > > Indeed. I came to the same conclusion. > > > > > func a > > patches 1i > > 2i > > 3 > > > > Now, when you're applying 3, only 2i function is checked. But there might > > be a task sleeping in 1i. Such task would be migrated to 3, because we do > > not check 1 in klp_check_stack_func() at all. > > > > I see three solutions. > > > > 1. Say it is an user's fault. Since it is not obvious and it is > > easy-to-make mistake, I would not go this way. > > > > 2. We can fix klp_check_stack_func() in an exact way you're proposing. > > We'd go back in func stack as long as there are immediate patches there. > > This adds complexity and I'm not sure if all the problems would be solved > > because scenarios how patches are stacked and applied to different > > functions may be quite complex. > > > > I think if its fixed in the current code (before atomic replace is > introduced), then it would allow the atomic replace to drop all > references to previous modules, since we would know they are no longer > in use. That's correct. Although, I'll submit my force patch soon, we can remove immediate afterwards and atomic replace should be simpler with that. Miroslav