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 BCC70C433F5 for ; Fri, 27 May 2022 13:12:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245012AbiE0NM6 (ORCPT ); Fri, 27 May 2022 09:12:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235848AbiE0NM6 (ORCPT ); Fri, 27 May 2022 09:12:58 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2293A127195; Fri, 27 May 2022 06:12:56 -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 BE8BBB82504; Fri, 27 May 2022 13:12:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 612C0C385A9; Fri, 27 May 2022 13:12:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653657173; bh=6p7oBMm6QzOQnT+oDCahCxyIyMkTov2pRVoC/5qV0Vg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Ur4MvhVOEYu8X+dWTZLVGLtUeUGSQarP/6edtuUKsXuuFYAiWtJ9FscVsgbGRzTs+ cc5ouYbGudAgEmXQaO/LYV47GdBCltvHwXmYvpCz/a4wTM/vrRb2t4wPXAV8ZHUoMC V2fZkn2Qta1sql+NivJgcl80ThZ1Or3sPMZQMVB1Lwc5wrbR6HKRVzkB+iwSGBVG15 1TAGOX9hjemeGIb/wSTMHVh5Xo1+KAkaLgqs4LOWwI9qrvvSdiwKM5+vX59vQKMF7e /682dMs77CMIky/gGCXkOOk9Wiqs6mAmjbZ0HaKkrJl1o21DXstGcNuzDuQIVHSLhq hWN2wtgQ8KKIA== Received: by mail-oi1-f175.google.com with SMTP id w130so5678246oig.0; Fri, 27 May 2022 06:12:53 -0700 (PDT) X-Gm-Message-State: AOAM533dsPVn1ZaUcFZeiTm+ZusY7lobDRYpt4HBOArp7JPAy+FwmJ2o m1n67DKQoTmPZZ1/x6dV5VLgPADcm7kLaeZcVmI= X-Google-Smtp-Source: ABdhPJw4LvLt21j/5Z86BrQ95Geu5PHkJnYczZRrX6hNjWux11OuOwaYX7mYe+cl+gjqPUv7ftdhzrIRe3/RFP/4Eyw= X-Received: by 2002:a05:6808:f88:b0:32b:d10f:cc6b with SMTP id o8-20020a0568080f8800b0032bd10fcc6bmr1815761oiw.228.1653657172571; Fri, 27 May 2022 06:12:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Fri, 27 May 2022 15:12:40 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: am335x: 5.18.x: system stalling To: Arnd Bergmann Cc: Yegor Yefremov , Tony Lindgren , Linux-OMAP , linux-clk , Stephen Boyd , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org On Fri, 27 May 2022 at 14:54, Arnd Bergmann wrote: > > On Fri, May 27, 2022 at 11:50 AM Yegor Yefremov > wrote: > > > > # zcat /proc/config.gz | grep 'CONFIG_ARCH_MULTI_V6\|CONFIG_SMP' > > # CONFIG_ARCH_MULTI_V6 is not set > > CONFIG_ARCH_MULTI_V6_V7=y > > CONFIG_SMP=y > > CONFIG_SMP_ON_UP=y > > > > No stalls. > > > > # zcat /proc/config.gz | grep 'CONFIG_ARCH_MULTI_V6\|CONFIG_SMP\|ARCH_OMAP2' > > CONFIG_ARCH_MULTI_V6=y > > CONFIG_ARCH_MULTI_V6_V7=y > > CONFIG_ARCH_OMAP2=y > > CONFIG_ARCH_OMAP2PLUS=y > > CONFIG_ARCH_OMAP2PLUS_TYPICAL=y > > > > No stalls. > > > > As soon as I enable both SMP and OMAP2 options the system stalls. > > Ok, that points to the SMP patching for percpu data, which doesn't happen > before the patch, and which is different between loadable modules and > the normal code. > Not just per-cpu data: there is also the 'current' global variable which gets used now instead of the user thread ID register, and this is also different between modules and the core kernel (unless CONFIG_ARM_MODULE_PLTS is disabled) I looked at the fdti-sio and slcan modules, and didn't find any references to per-CPU offsets when building them using the provided .config. I did find some references to __current, but these seem to be ignored (they are only emitted to satisfy the "m" inline asm constraint in get_domain(), but the parameter is never actually used in the assembler code) > Can you try out this patch to short-circuit the logic and always return > the offset for CPU 0? This is obviously broken on SMP machines but > would get around the bit of code that is V6+SMP specific. > > Arnd > > diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h > index 7545c87c251f..3057c5fef970 100644 > --- a/arch/arm/include/asm/percpu.h > +++ b/arch/arm/include/asm/percpu.h > @@ -25,10 +25,13 @@ static inline void set_my_cpu_offset(unsigned long off) > asm volatile("mcr p15, 0, %0, c13, c0, 4" : : "r" (off) : "memory"); > } > > +extern unsigned long __per_cpu_offset[]; > static __always_inline unsigned long __my_cpu_offset(void) > { > unsigned long off; > > + return __per_cpu_offset[0]; > + > /* > * Read TPIDRPRW. > * We want to allow caching the value, so avoid using volatile and 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9E146C433F5 for ; Fri, 27 May 2022 13:14:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9BCMFAEq5pbpzSBVr/dcvNPJW19WGHTjNEXVK7S+Vys=; b=EKucndSIFoAhCm bONOL68RXDiVErerJRj28wbfX1Bqq1udfP0WfNutGcxUaxampfW5qVT/lKtmNtLrx4fL9FV+On1Ai aL9M4MbxJ3jhXn6NI2KrkaIHGj8ZNRYzVVYFb3CXC/zemUW3ibBwHkEmsKwmLOVkX9TanU5CAO/xP zzfgveXJum0aLG3Rm7DD6CKiYCKuJTpTzZDgPWXD3ZWwJxZJGe6JNEVJmVcnkFbohkVY4ubdv62Yw VTPX1jliVFLkGgT13LUmBIu2EPVyQBEdNdMqyxaZlIZv7aozOuePtXBtvQjXqMQGxmCg4iPsKy9nf gJ0ZYn8YV9Dd7mbAtgLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nuZm5-0006SW-AE; Fri, 27 May 2022 13:13:05 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nuZlx-0006RO-7Q for linux-arm-kernel@lists.infradead.org; Fri, 27 May 2022 13:13:02 +0000 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 98290B8229A for ; Fri, 27 May 2022 13:12:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63C86C34113 for ; Fri, 27 May 2022 13:12:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653657173; bh=6p7oBMm6QzOQnT+oDCahCxyIyMkTov2pRVoC/5qV0Vg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Ur4MvhVOEYu8X+dWTZLVGLtUeUGSQarP/6edtuUKsXuuFYAiWtJ9FscVsgbGRzTs+ cc5ouYbGudAgEmXQaO/LYV47GdBCltvHwXmYvpCz/a4wTM/vrRb2t4wPXAV8ZHUoMC V2fZkn2Qta1sql+NivJgcl80ThZ1Or3sPMZQMVB1Lwc5wrbR6HKRVzkB+iwSGBVG15 1TAGOX9hjemeGIb/wSTMHVh5Xo1+KAkaLgqs4LOWwI9qrvvSdiwKM5+vX59vQKMF7e /682dMs77CMIky/gGCXkOOk9Wiqs6mAmjbZ0HaKkrJl1o21DXstGcNuzDuQIVHSLhq hWN2wtgQ8KKIA== Received: by mail-oi1-f177.google.com with SMTP id u140so3189376oie.3 for ; Fri, 27 May 2022 06:12:53 -0700 (PDT) X-Gm-Message-State: AOAM530w3BO1OcFZAKtU6HZ75uwuHbZl17z1EsiAqOVU6vd97WR/hqro iCK8dtaXjLXNgPZEXwcmivMKsIBKvzTnK007wyE= X-Google-Smtp-Source: ABdhPJw4LvLt21j/5Z86BrQ95Geu5PHkJnYczZRrX6hNjWux11OuOwaYX7mYe+cl+gjqPUv7ftdhzrIRe3/RFP/4Eyw= X-Received: by 2002:a05:6808:f88:b0:32b:d10f:cc6b with SMTP id o8-20020a0568080f8800b0032bd10fcc6bmr1815761oiw.228.1653657172571; Fri, 27 May 2022 06:12:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Fri, 27 May 2022 15:12:40 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: am335x: 5.18.x: system stalling To: Arnd Bergmann Cc: Yegor Yefremov , Tony Lindgren , Linux-OMAP , linux-clk , Stephen Boyd , Linux ARM X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220527_061257_608291_612025BE X-CRM114-Status: GOOD ( 26.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 27 May 2022 at 14:54, Arnd Bergmann wrote: > > On Fri, May 27, 2022 at 11:50 AM Yegor Yefremov > wrote: > > > > # zcat /proc/config.gz | grep 'CONFIG_ARCH_MULTI_V6\|CONFIG_SMP' > > # CONFIG_ARCH_MULTI_V6 is not set > > CONFIG_ARCH_MULTI_V6_V7=y > > CONFIG_SMP=y > > CONFIG_SMP_ON_UP=y > > > > No stalls. > > > > # zcat /proc/config.gz | grep 'CONFIG_ARCH_MULTI_V6\|CONFIG_SMP\|ARCH_OMAP2' > > CONFIG_ARCH_MULTI_V6=y > > CONFIG_ARCH_MULTI_V6_V7=y > > CONFIG_ARCH_OMAP2=y > > CONFIG_ARCH_OMAP2PLUS=y > > CONFIG_ARCH_OMAP2PLUS_TYPICAL=y > > > > No stalls. > > > > As soon as I enable both SMP and OMAP2 options the system stalls. > > Ok, that points to the SMP patching for percpu data, which doesn't happen > before the patch, and which is different between loadable modules and > the normal code. > Not just per-cpu data: there is also the 'current' global variable which gets used now instead of the user thread ID register, and this is also different between modules and the core kernel (unless CONFIG_ARM_MODULE_PLTS is disabled) I looked at the fdti-sio and slcan modules, and didn't find any references to per-CPU offsets when building them using the provided .config. I did find some references to __current, but these seem to be ignored (they are only emitted to satisfy the "m" inline asm constraint in get_domain(), but the parameter is never actually used in the assembler code) > Can you try out this patch to short-circuit the logic and always return > the offset for CPU 0? This is obviously broken on SMP machines but > would get around the bit of code that is V6+SMP specific. > > Arnd > > diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h > index 7545c87c251f..3057c5fef970 100644 > --- a/arch/arm/include/asm/percpu.h > +++ b/arch/arm/include/asm/percpu.h > @@ -25,10 +25,13 @@ static inline void set_my_cpu_offset(unsigned long off) > asm volatile("mcr p15, 0, %0, c13, c0, 4" : : "r" (off) : "memory"); > } > > +extern unsigned long __per_cpu_offset[]; > static __always_inline unsigned long __my_cpu_offset(void) > { > unsigned long off; > > + return __per_cpu_offset[0]; > + > /* > * Read TPIDRPRW. > * We want to allow caching the value, so avoid using volatile and _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel