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 A74D3C433F5 for ; Wed, 16 Mar 2022 14:39:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240455AbiCPOkT (ORCPT ); Wed, 16 Mar 2022 10:40:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240487AbiCPOkQ (ORCPT ); Wed, 16 Mar 2022 10:40:16 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9B8EE26EC; Wed, 16 Mar 2022 07:39:01 -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 sin.source.kernel.org (Postfix) with ESMTPS id CAC00CE1FE0; Wed, 16 Mar 2022 14:38:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B930C340EC; Wed, 16 Mar 2022 14:38:55 +0000 (UTC) Date: Wed, 16 Mar 2022 14:38:51 +0000 From: Catalin Marinas To: guoren@kernel.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-csky@vger.kernel.org, linux-riscv@lists.infradead.org, linux-xtensa@linux-xtensa.org, Guo Ren , Max Filippov , Will Deacon , Palmer Dabbelt , Masami Hiramatsu , Chris Zankel , Arnd Bergmann Subject: Re: [PATCH V2] arch: patch_text: Fixup last cpu should be master Message-ID: References: <20220313012221.1755483-1-guoren@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220313012221.1755483-1-guoren@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 13, 2022 at 09:22:21AM +0800, guoren@kernel.org wrote: > 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. I couldn't find the original intent in the commit logs (at least not in the arm64 logs). Maybe the intention was for the CPUs to wait for the text patching to complete rather than the master CPU to wait for the others to enter the cpu_relax() loop before patching. I think your patch makes sense anyway, the master CPU would wait for all the others to enter the cpu_relax() loop before patching and releasing them with another increment. You probably wouldn't see any issues in practice unless you insert probes in the multi_stop_cpu() function (or we could mark this function as __kprobes and get rid of the extra loops entirely). > --- a/arch/arm64/kernel/patching.c > +++ b/arch/arm64/kernel/patching.c > @@ -117,8 +117,8 @@ static int __kprobes aarch64_insn_patch_text_cb(void *arg) > int i, ret = 0; > struct aarch64_insn_patch *pp = arg; > > - /* The first CPU becomes master */ > - if (atomic_inc_return(&pp->cpu_count) == 1) { > + /* The last CPU becomes master */ > + if (atomic_inc_return(&pp->cpu_count) == num_online_cpus()) { > for (i = 0; ret == 0 && i < pp->insn_cnt; i++) > ret = aarch64_insn_patch_text_nosync(pp->text_addrs[i], > pp->new_insns[i]); For arm64: Reviewed-by: Catalin Marinas -- Catalin