Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp288143imn; Thu, 4 Aug 2022 06:09:53 -0700 (PDT) X-Google-Smtp-Source: AA6agR7odHogQrfPD9y1TqjWxj4uuqKZe5sMw/kOtq655zHkBM9Vh8JIG2EcklineA+VFu9gZG7h X-Received: by 2002:a17:902:ed83:b0:16e:eb08:fafc with SMTP id e3-20020a170902ed8300b0016eeb08fafcmr1872689plj.117.1659618593195; Thu, 04 Aug 2022 06:09:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659618593; cv=none; d=google.com; s=arc-20160816; b=DBBdQ7kKSa8Sx5GsKZcf72FlYOlxczfSV547BGqShIoyTL4MoosRAOwLwuZth/r1oh y7EuiOXk/5AG0dS1E6OZXQVwcy++rwql748MTki0YBOIoa+1YjELvnJWCkQpk/eNOCkW IpVOzG/Bv72o4blOIFowPTQSL6V/0OSRm6/REm3iH7aSXwEmSWWxEaA+l/x4L77U+elX aQ13z6hzpFYtChwgi1CDxEv7yGhCIYKsLczn9COGil/fNmxsyokp/9Wgx9p6vBX7d3AF o2gjrugVk5rvJ2Kthx4xo4YEQ1e158ThQHOF6dZMIQ130PV5e5n2RXiZtnCrIzgxSm6d Ay6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=3gPpoOwUEkIJ+ATjFpS4H9/4o1rTRBq+mrao0Dod2bw=; b=bHr2xXuCUmy6j/ZEpUEhMkz2BkibHh67UKlW3WVeE8qmfOL7msQ1FcAJ4T0s9lBwZA PZaEOORN7FPAwK5V/eEQdhtBNAsSqTxOhx1nNC3Jgh8y1uuC90+Z/u18d0S9bkbq27aj X78tOe13EO/y/kTLHPCcdmzMnNZnY281c1+HCfUYKehiblIbouxJTlf4X/W2YMuRb2dF 5teTmgs5z11T2PpcBNc5N62FxLY4ZbAv2tFluf8CKqbPG/1TDF41N+U/B9Bqm3rv0HnT Hn75+rXI+fs1XL6lfB729Bqdg10XX0foR5lGDr3/gmT9M4dXGWpwPHftTrsIZHP8dpuz 1keg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=NRG0H44A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e6-20020a170902b78600b0016dc58943absi743429pls.398.2022.08.04.06.09.20; Thu, 04 Aug 2022 06:09:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=NRG0H44A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239631AbiHDNG1 (ORCPT + 99 others); Thu, 4 Aug 2022 09:06:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229625AbiHDNG0 (ORCPT ); Thu, 4 Aug 2022 09:06:26 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7750C5F95; Thu, 4 Aug 2022 06:06:24 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id F3123205C4; Thu, 4 Aug 2022 13:06:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1659618382; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3gPpoOwUEkIJ+ATjFpS4H9/4o1rTRBq+mrao0Dod2bw=; b=NRG0H44A8xOtANNH5QwPGhga8gWutFv2PTnz5UYN4c+onzXETxCYBAAVZZa2Y9fevgrPdo qpNY4x0dUcJlU6zK4bJFIqHFTGE3sFl9m6VU+2zJ58JF6lWPcsh7yECYGUib8geTdt5M0u FFY+ZYwSqeuZzajhW0qDocSQREcgUtQ= Received: from suse.cz (unknown [10.100.208.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id CEAD82C141; Thu, 4 Aug 2022 13:06:21 +0000 (UTC) Date: Thu, 4 Aug 2022 15:06:21 +0200 From: Petr Mladek To: Rik van Riel Cc: Josh Poimboeuf , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, kernel-team@fb.com, Jiri Kosina , Miroslav Benes , Joe Lawrence , Breno Leitao Subject: Re: [PATCH v4] livepatch: fix race between fork and KLP transition Message-ID: References: <20220720121023.043738bb@imladris.surriel.com> <20220722150106.683f3704@imladris.surriel.com> <20220725094919.52bcde19@imladris.surriel.com> <20220727001040.vlqnnb4a3um46746@treble> <20220727102437.34530586@imladris.surriel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 2022-08-02 16:07:08, Rik van Riel wrote: > On Thu, 2022-07-28 at 17:37 +0200, Petr Mladek wrote: > > On Wed 2022-07-27 10:24:37, Rik van Riel wrote: > > > v4: address changelog comments by Josh (thank you) > > > > > > ---8<--- > > > When a KLP fails to apply, klp_reverse_transition will clear the > > > TIF_PATCH_PENDING flag on all tasks, except for newly created tasks > > > which are not on the task list yet. > > > > It actually is not true. klp_reverse_transtion() clears > > TIF_PATCH_FLAG only > > temporary when it waits until all processes leave the ftrace > > handler. It sets TIF_PATCH_FLAG once again for all tasks by calling > > klp_start_transition(). > > > > The difference is important. The WARN_ON_ONCE() in > > klp_complete_transition() will be printed when fork() copied > > TIF_PATCH_FLAG before it was set again. > > > > Anyway, the important thing is that TIF_PATCH_FLAG and task- > > >patch_state > > might be incompatible because fork() copies them at different times. > > > > klp_copy_process() must make sure that they are in sync. And > > it must be done under tasklist_lock when the child is added > > to the global task list. > > Hmmm, how should this be addressed in the changelog? > > Should I just remove most of that paragraph and leave it > at "there can be a race"? It would be nice to somehow summarize what I wrote. I mean to explain why the problem is easier to see with revert and not with forward transition. It is because TIF_PATCH_FLAG might stay cleared in the child even when it was set again in the parent by the klp_revert_transtion(). As a result, the child will never get transition back to the reverted state. The problem is hard to hit during the forward transition because child might have TIF_PATCH_FLAG still set even when it might later copy an already migrated task->patch_state when parent gets migrated in the race window. In this case, the TIF_PATCH_FLAG will get cleared when the child returns from fork and all will be good. In each case, the inconsistent state is there even during the forward transition. But it would be caught only when the entire transition is finished during the rather small race window. The patch should fix the race in any direction. I could provide even better description after I am back from vacation on Aug 22. Best Regards, Petr