From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4DDAEC433EF for ; Wed, 6 Apr 2022 17:03:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238521AbiDFRFx (ORCPT ); Wed, 6 Apr 2022 13:05:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238255AbiDFRFh (ORCPT ); Wed, 6 Apr 2022 13:05:37 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 151C34961FB; Wed, 6 Apr 2022 07:28:39 -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 ams.source.kernel.org (Postfix) with ESMTPS id 9EA4EB82353; Wed, 6 Apr 2022 14:28:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9470DC385A3; Wed, 6 Apr 2022 14:28:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649255316; bh=6ilL6lDyJxwwFSqe1lKQGv1TTtCGzwxuY6CWzqW3O/c=; h=From:To:Cc:Subject:Date:From; b=hgjDMg8XINxqdmkR9f8AdMKEfhxzsrPumb8XbUGwhvsXdS8enBomrRCBxL1/fdeo5 HJXRIG5UrwQhajTiMS5314t15cGqDyjEvjRWm5qzPCBqqZ1f+lT9+TrWA0HWOjVclP IA4bL8acXWbzqz2lbWLWN1OcqKnUVTpACzoQ8UL0ZJwB7KH9REsfITVpxRtYvIXmsJ +okbrVHjHzaBSkbpT5+heKmhrQQfLxLFCFQVuj8mWVe7GC1QISj6XJhMA98RzCrJAq atD8tYueuk2mvgnMMjuCNWsuJ3Ze9nxiNIZytrDh035g383swaQ/RKiqxAtRqvp9nQ JkjUqGSadJQTA== From: guoren@kernel.org To: guoren@kernel.org, arnd@arndb.de, jcmvbkbc@gmail.com, chris@zankel.net Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xtensa@linux-xtensa.org, Guo Ren , Masami Hiramatsu , stable@vger.kernel.org Subject: [PATCH V3] xtensa: patch_text: Fixup last cpu should be master Date: Wed, 6 Apr 2022 22:28:19 +0800 Message-Id: <20220406142819.730238-1-guoren@kernel.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Guo Ren These patch_text implementations are using stop_machine_cpuslocked infrastructure with atomic cpu_count. The original idea: When the master CPU patch_text, the others should wait for it. But current implementation is using the first CPU as master, which couldn't guarantee the remaining CPUs are waiting. This patch changes the last CPU as the master to solve the potential risk. Signed-off-by: Guo Ren Signed-off-by: Guo Ren Reviewed-by: Max Filippov Reviewed-by: Masami Hiramatsu Cc: --- arch/xtensa/kernel/jump_label.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/xtensa/kernel/jump_label.c b/arch/xtensa/kernel/jump_label.c index 0dde21e0d3de..ad1841cecdfb 100644 --- a/arch/xtensa/kernel/jump_label.c +++ b/arch/xtensa/kernel/jump_label.c @@ -40,7 +40,7 @@ static int patch_text_stop_machine(void *data) { struct patch *patch = data; - if (atomic_inc_return(&patch->cpu_count) == 1) { + if (atomic_inc_return(&patch->cpu_count) == num_online_cpus()) { local_patch_text(patch->addr, patch->data, patch->sz); atomic_inc(&patch->cpu_count); } else { -- 2.25.1