From patchwork Mon Oct 24 11:29:15 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 8866 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp433143wru; Mon, 24 Oct 2022 05:48:40 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4oETh+Czf0WFPQQeYsPRhf6Mxa1cahuyWJ0RLWnqkwuDZxsXGF8Cs1EGrGvkcI2Hmj9r3+ X-Received: by 2002:a17:902:8542:b0:186:75ee:baac with SMTP id d2-20020a170902854200b0018675eebaacmr18291619plo.35.1666615719970; Mon, 24 Oct 2022 05:48:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666615719; cv=none; d=google.com; s=arc-20160816; b=pz9BMbsBknj8CH2ftWgJaf4hDbtuMTCAsQhmTT4JNFMGRPp8MZj2L8DqoO7dMxa7F1 MS4+kKpo9ZpjvmTHTa1N6sjpPXy124Mwv5gQVcuWnmWDUX35z78l55ZiI8KYFJ10ppi4 10oAn9B5ksiK6GxATRPln3G/zaS/KKt7gZW4uX7LDBd9H5VMbbhhHts5WcpNm/BmTFis UZBbMEagQbYQmiQBqDBdgWpoabF/058GpZmGYK7Iy7vPlaVOTpkpLFpKBlGq6ecSK/j7 AtcLglpdRcadLn9VLvhgo46Vz9qffyuRZWBHzX+COe/YYV0+7GzgoFMgVJ3hAv6yw7pc Y7kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=3P07V5+0QvgExhqU5bSPyEIgOG8Hgc7gEw584zyCgXs=; b=VlFVUMs4Y4AxdExzJWj0P18OylpNAKI8hkpG32NJ95Ri9a0i9Aqgw6u9YzQwE7fIYb RE+oi9OMOF7S8QQQAK7n87JO96yl9nncqyO99ZTXvCKyjbJMd7zwkxNFrWQm24+XktMo +R3Ui5Gz4HfsGQ0zJ/VVKpu8g/Pl74hmwIJUy8x/FNo9aXX8lunewiXiFcXFoVgf1UtN J0hor+7M44KjWenagPLBjRg5BdLXN6SAr5uCWK90mZjdE1KiNHGIIV/cypqYDyguG5xD 0EOlAqIdYAt3KXNGhO6j4hO8VvKeODjTFQdyHzAA46UUWv/hBMUVSCWqw4wwCLh/mTVG hM8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=0h5+sHIe; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s4-20020a170902b18400b00186aee053fbsi1977461plr.287.2022.10.24.05.48.26; Mon, 24 Oct 2022 05:48:39 -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=@linuxfoundation.org header.s=korg header.b=0h5+sHIe; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233993AbiJXMlo (ORCPT + 99 others); Mon, 24 Oct 2022 08:41:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230254AbiJXMiq (ORCPT ); Mon, 24 Oct 2022 08:38:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FC7189ACD; Mon, 24 Oct 2022 05:06:47 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D8DEA612DA; Mon, 24 Oct 2022 12:06:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC8B8C433D6; Mon, 24 Oct 2022 12:06:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666613198; bh=QU6jcTM5tFiqBhEpEDUebcCTZlgBib+XeTwuUsseiyE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0h5+sHIepDjG5IvtcEvd2LEO/IcDhyuNio63oH0RmR7IvyqnSvtDtub1ctw9ULdOo DpZrT3RTut92W/GY/ToJy2346pBesxdWx3W5wT5Bvg++j6TKTFKc+jDMXbMGTt9iZh Eq84gqVTv8cwhYWI9nbA9kSQX4IHYb1aHZ2XR/+s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Rik van Riel , Breno Leitao , Petr Mladek , Josh Poimboeuf , stable@kernel.org Subject: [PATCH 5.4 045/255] livepatch: fix race between fork and KLP transition Date: Mon, 24 Oct 2022 13:29:15 +0200 Message-Id: <20221024113003.931359535@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024113002.471093005@linuxfoundation.org> References: <20221024113002.471093005@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747573245461585137?= X-GMAIL-MSGID: =?utf-8?q?1747573245461585137?= From: Rik van Riel commit 747f7a2901174c9afa805dddfb7b24db6f65e985 upstream. The KLP transition code depends on the TIF_PATCH_PENDING and the task->patch_state to stay in sync. On a normal (forward) transition, TIF_PATCH_PENDING will be set on every task in the system, while on a reverse transition (after a failed forward one) first TIF_PATCH_PENDING will be cleared from every task, followed by it being set on tasks that need to be transitioned back to the original code. However, the fork code copies over the TIF_PATCH_PENDING flag from the parent to the child early on, in dup_task_struct and setup_thread_stack. Much later, klp_copy_process will set child->patch_state to match that of the parent. However, the parent's patch_state may have been changed by KLP loading or unloading since it was initially copied over into the child. This results in the KLP code occasionally hitting this warning in klp_complete_transition: for_each_process_thread(g, task) { WARN_ON_ONCE(test_tsk_thread_flag(task, TIF_PATCH_PENDING)); task->patch_state = KLP_UNDEFINED; } Set, or clear, the TIF_PATCH_PENDING flag in the child task depending on whether or not it is needed at the time klp_copy_process is called, at a point in copy_process where the tasklist_lock is held exclusively, preventing races with the KLP code. The KLP code does have a few places where the state is changed without the tasklist_lock held, but those should not cause problems because klp_update_patch_state(current) cannot be called while the current task is in the middle of fork, klp_check_and_switch_task() which is called under the pi_lock, which prevents rescheduling, and manipulation of the patch state of idle tasks, which do not fork. This should prevent this warning from triggering again in the future, and close the race for both normal and reverse transitions. Signed-off-by: Rik van Riel Reported-by: Breno Leitao Reviewed-by: Petr Mladek Acked-by: Josh Poimboeuf Fixes: d83a7cb375ee ("livepatch: change to a per-task consistency model") Cc: stable@kernel.org Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20220808150019.03d6a67b@imladris.surriel.com Signed-off-by: Greg Kroah-Hartman --- kernel/livepatch/transition.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) --- a/kernel/livepatch/transition.c +++ b/kernel/livepatch/transition.c @@ -611,9 +611,23 @@ void klp_reverse_transition(void) /* Called from copy_process() during fork */ void klp_copy_process(struct task_struct *child) { - child->patch_state = current->patch_state; - /* TIF_PATCH_PENDING gets copied in setup_thread_stack() */ + /* + * The parent process may have gone through a KLP transition since + * the thread flag was copied in setup_thread_stack earlier. Bring + * the task flag up to date with the parent here. + * + * The operation is serialized against all klp_*_transition() + * operations by the tasklist_lock. The only exception is + * klp_update_patch_state(current), but we cannot race with + * that because we are current. + */ + if (test_tsk_thread_flag(current, TIF_PATCH_PENDING)) + set_tsk_thread_flag(child, TIF_PATCH_PENDING); + else + clear_tsk_thread_flag(child, TIF_PATCH_PENDING); + + child->patch_state = current->patch_state; } /*