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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E925C433F5 for ; Mon, 6 Sep 2021 06:14:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 37D7260EC0 for ; Mon, 6 Sep 2021 06:14:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239397AbhIFGPX (ORCPT ); Mon, 6 Sep 2021 02:15:23 -0400 Received: from home.keithp.com ([63.227.221.253]:43210 "EHLO elaine.keithp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229792AbhIFGPR (ORCPT ); Mon, 6 Sep 2021 02:15:17 -0400 Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id 86EAF3F307E8; Sun, 5 Sep 2021 23:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=keithp.com; s=mail; t=1630908828; bh=nzQzOWzurWPXI3nB4kbriI3K5D3ah45RRHm3ACe7Waw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=vaOfet+uYMffXEWxV3r4g6+YzBofDhX54sdRdPrR+r3xkeKN6cZadhVWo1WJJ7xeD 88TAeYER/TSzYrkF4Mm21LwnQMtysa82uey18kW5KfieUbgATvplvUbKFYTusGyd00 eXDF/j0fujASLnlKYG+t375RR6v3YdQ9j+0cNyW6DuQWfBn+izE5LmhodiqBSgOhf5 fqrJqUrT4xS2pLpjiciG3hFh1fJFLvKvEocMmTfeqQWgJsXcNLGinithxz0chjuD5A 0/PvvoTZ9XPSweJr1xxlwnfWVD7fONhznQZ+svIgRpkJh88AcT7rqQ4wtd8OpnrBoh ZaPaGndBaYVLg== X-Virus-Scanned: Debian amavisd-new at keithp.com Received: from elaine.keithp.com ([127.0.0.1]) by localhost (elaine.keithp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bTezPySDxRLX; Sun, 5 Sep 2021 23:13:48 -0700 (PDT) Received: from keithp.com (168-103-156-98.tukw.qwest.net [168.103.156.98]) by elaine.keithp.com (Postfix) with ESMTPSA id C11C73F307D6; Sun, 5 Sep 2021 23:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=keithp.com; s=mail; t=1630908828; bh=nzQzOWzurWPXI3nB4kbriI3K5D3ah45RRHm3ACe7Waw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=vaOfet+uYMffXEWxV3r4g6+YzBofDhX54sdRdPrR+r3xkeKN6cZadhVWo1WJJ7xeD 88TAeYER/TSzYrkF4Mm21LwnQMtysa82uey18kW5KfieUbgATvplvUbKFYTusGyd00 eXDF/j0fujASLnlKYG+t375RR6v3YdQ9j+0cNyW6DuQWfBn+izE5LmhodiqBSgOhf5 fqrJqUrT4xS2pLpjiciG3hFh1fJFLvKvEocMmTfeqQWgJsXcNLGinithxz0chjuD5A 0/PvvoTZ9XPSweJr1xxlwnfWVD7fONhznQZ+svIgRpkJh88AcT7rqQ4wtd8OpnrBoh ZaPaGndBaYVLg== Received: by keithp.com (Postfix, from userid 1000) id 6D1A21E60119; Sun, 5 Sep 2021 23:14:09 -0700 (PDT) From: Keith Packard To: Ard Biesheuvel Cc: Linux Kernel Mailing List , Abbott Liu , Alexander Sverdlin , Andrew Morton , Anshuman Khandual , Arnd Bergmann , Bjorn Andersson , Florian Fainelli , Geert Uytterhoeven , Hartley Sweeten , Jens Axboe , Jian Cai , Joe Perches , Kees Cook , Krzysztof Kozlowski , Linus Walleij , Linux ARM , Manivannan Sadhasivam , Marc Zyngier , Masahiro Yamada , Miguel Ojeda , Mike Rapoport , Nathan Chancellor , Nick Desaulniers , Nicolas Pitre , Rob Herring , Russell King , Thomas Gleixner , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Valentin Schneider , Viresh Kumar , "Wolfram Sang (Renesas)" , YiFei Zhu Subject: Re: [PATCH 2/3] ARM: Move thread_info into task_struct (v7 only) In-Reply-To: References: <20210902155429.3987201-1-keithp@keithp.com> <20210904060908.1310204-1-keithp@keithp.com> <20210904060908.1310204-3-keithp@keithp.com> Date: Sun, 05 Sep 2021 23:14:09 -0700 Message-ID: <8735qifcy6.fsf@keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ard Biesheuvel writes: > c13 is not a register, it is a value in one of the dimensions of the > ARM sysreg space, and probably covers other system registers that > pre-v7 cores do implement. > Better to use its architectural name (TPIDRPRW) and clarify that > pre-v6k/v7 cores simply don't implement it. Thanks, I'll reword the commit message > Could we split this up? I could split up the assembler macro changes which add a temporary register to the calls getting the current thread_info/task_struct value? If that would help get this reviewed, I'd be happy to do that. Otherwise, it's pretty much all-or-nothing as enabling THREAD_INFO_IN_TASK requires a bunch of synchronized changes. >> +#ifdef CONFIG_THREAD_INFO_IN_TASK > > No need for this #ifdef - it only guards macros that will have no > effect if they are never instantiated (another case below) Sure, the resulting code is a bit less noisy, which seems good. >> +DECLARE_PER_CPU(struct task_struct *, current_task); >> + >> +static __always_inline struct task_struct *get_current(void) >> +{ >> + return raw_cpu_read(current_task); > > This needs to run with preemption disabled, or we might get migrated > to another CPU halfway through, and produce the wrong result (i.e., > the current task of the CPU we migrated from). However, it appears > that manipulating the preempt count will create a circular dependency > here. Yeah, I really don't understand the restrictions of this API well. Any code fetching the current task pointer better not be subject to preemption or that value will be stale at some point after it was computed. Do you know if it could ever be run in a context allowing preemption? > > Instead of using a per-CPU variable for current, I think it might be > better to borrow another system register (TPIDRURO or TPIDRURW) to > carry 'current' when THREAD_INFO_IN_TASK is in effect, similar to how > arm64 uses SP_EL0 - those registers could be preserved/restored in the > entry/exit from/to user space paths rather than in the context switch > path, and then be used any way we like while running in the kernel. Making sure these values don't leak through to user space somehow? I'm not excited by that prospect at all. But, perhaps someone can help me understand the conditions under which the current task value can be computed where preemption was enabled and have that not be a problem for the enclosing code? =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAmE1sbEACgkQ2yIaaQAA ABGusg/9FwN3xd/eIDwhSpWhgmZQsghjqpdH0H9Sjh/+nk4W6N9kRp22bty3b6Sx thxasQmaf6sgH+ZZA27hWbuoKU8QGBRj+cmjR9kSZWo/ia9C6QsqqvJB4W9Je6WQ S7wnmUrE2wIvcRsVNyPv1qBhpjoPq5yoCD8TainCrz9+n39QEmb4VL4ptwOpMvQr bk6iSoKdsv+KlZfOSGN4v4uO47KhMBpoJQQZGDsolBgmqDzKsI2LAqQUhLSt4YLr bZJkE7OGJ+DMrYCZBFka3P0UaJQC1mTdyv4IPYsLnY5wkNmje1AyfMYqgnjGVNgs 7mlkClXI+yrkBGSW6BHfEzpkAgjql+ZuEMBXY7TFNn0mUMuJ3qspJwwAU4YgFaHZ lkSp6aOJMCBshBvbbbG7BQ4unNlVhy43iJa9pHfMjeURSxV6dqydxmiQ7w9VjTJq g4pwRM8n7aoi2+aiPLgnR/Jva0U5JIM9Co4+97JtzbivVsnkLlZB2uC1DQe7VnPZ fPBg+ZDVYe46CftOjpmeG0Uogu2glKwUyaH3W+GTxXs4gHk6QfKkLZTaa+3FJQZv ejYsfvTeU/eAoMQeskyOOgvOlbkBxlGLiGUCvsV9pxZR2BwyFlGnTpz9Eq7ZZXG8 S+LacsRFQ87EmnAJBZMgRhL15/I0JOg3ybkYECzv3njVOUv2B2Y= =1sPs -----END PGP SIGNATURE----- --=-=-=-- 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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86A6EC433F5 for ; Mon, 6 Sep 2021 06:16:26 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 4EE8860EC0 for ; Mon, 6 Sep 2021 06:16:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4EE8860EC0 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=keithp.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oCrur8d7jFxZvhauldZD+vusYtRfJXe8+W/ViAmQNNM=; b=ZK7VToYdrTBjI/50T7l2q5u3JZ pxuKluTAObqNE+F6BIAEKqJAKn2d1ZB6GThuFMmwMd5FSc4tcWXsNn2P6yYndc/wQt8N46zH06zOq m9n9Vb/8b3HLn455wx+AAB6rbT7V972Trr9/RxHdDcjtXGW7VHXey859VA9qRZRJ+9qbB2X+LB/ZB ykqyEp6HEnmuIbGyC6BSNhiKgWbgXigjAOiUq1dPTf7vwkUIt40uNwq/lTm1Dkd9NRjm77rJdy801 ogPYVtd22XDrzH8z0zvA4gbefZPcac9JvJDy3iY0fMa/rV3NiY4tKN7cqXFu5KxmFbVygrFpm5VXT IcSxU91w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mN7tZ-00HNTT-U3; Mon, 06 Sep 2021 06:14:18 +0000 Received: from home.keithp.com ([63.227.221.253] helo=elaine.keithp.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mN7tW-00HNSu-P7 for linux-arm-kernel@lists.infradead.org; Mon, 06 Sep 2021 06:14:16 +0000 Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id 86EAF3F307E8; Sun, 5 Sep 2021 23:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=keithp.com; s=mail; t=1630908828; bh=nzQzOWzurWPXI3nB4kbriI3K5D3ah45RRHm3ACe7Waw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=vaOfet+uYMffXEWxV3r4g6+YzBofDhX54sdRdPrR+r3xkeKN6cZadhVWo1WJJ7xeD 88TAeYER/TSzYrkF4Mm21LwnQMtysa82uey18kW5KfieUbgATvplvUbKFYTusGyd00 eXDF/j0fujASLnlKYG+t375RR6v3YdQ9j+0cNyW6DuQWfBn+izE5LmhodiqBSgOhf5 fqrJqUrT4xS2pLpjiciG3hFh1fJFLvKvEocMmTfeqQWgJsXcNLGinithxz0chjuD5A 0/PvvoTZ9XPSweJr1xxlwnfWVD7fONhznQZ+svIgRpkJh88AcT7rqQ4wtd8OpnrBoh ZaPaGndBaYVLg== X-Virus-Scanned: Debian amavisd-new at keithp.com Received: from elaine.keithp.com ([127.0.0.1]) by localhost (elaine.keithp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bTezPySDxRLX; Sun, 5 Sep 2021 23:13:48 -0700 (PDT) Received: from keithp.com (168-103-156-98.tukw.qwest.net [168.103.156.98]) by elaine.keithp.com (Postfix) with ESMTPSA id C11C73F307D6; Sun, 5 Sep 2021 23:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=keithp.com; s=mail; t=1630908828; bh=nzQzOWzurWPXI3nB4kbriI3K5D3ah45RRHm3ACe7Waw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=vaOfet+uYMffXEWxV3r4g6+YzBofDhX54sdRdPrR+r3xkeKN6cZadhVWo1WJJ7xeD 88TAeYER/TSzYrkF4Mm21LwnQMtysa82uey18kW5KfieUbgATvplvUbKFYTusGyd00 eXDF/j0fujASLnlKYG+t375RR6v3YdQ9j+0cNyW6DuQWfBn+izE5LmhodiqBSgOhf5 fqrJqUrT4xS2pLpjiciG3hFh1fJFLvKvEocMmTfeqQWgJsXcNLGinithxz0chjuD5A 0/PvvoTZ9XPSweJr1xxlwnfWVD7fONhznQZ+svIgRpkJh88AcT7rqQ4wtd8OpnrBoh ZaPaGndBaYVLg== Received: by keithp.com (Postfix, from userid 1000) id 6D1A21E60119; Sun, 5 Sep 2021 23:14:09 -0700 (PDT) From: Keith Packard To: Ard Biesheuvel Cc: Linux Kernel Mailing List , Abbott Liu , Alexander Sverdlin , Andrew Morton , Anshuman Khandual , Arnd Bergmann , Bjorn Andersson , Florian Fainelli , Geert Uytterhoeven , Hartley Sweeten , Jens Axboe , Jian Cai , Joe Perches , Kees Cook , Krzysztof Kozlowski , Linus Walleij , Linux ARM , Manivannan Sadhasivam , Marc Zyngier , Masahiro Yamada , Miguel Ojeda , Mike Rapoport , Nathan Chancellor , Nick Desaulniers , Nicolas Pitre , Rob Herring , Russell King , Thomas Gleixner , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Valentin Schneider , Viresh Kumar , "Wolfram Sang (Renesas)" , YiFei Zhu Subject: Re: [PATCH 2/3] ARM: Move thread_info into task_struct (v7 only) In-Reply-To: References: <20210902155429.3987201-1-keithp@keithp.com> <20210904060908.1310204-1-keithp@keithp.com> <20210904060908.1310204-3-keithp@keithp.com> Date: Sun, 05 Sep 2021 23:14:09 -0700 Message-ID: <8735qifcy6.fsf@keithp.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210905_231414_932694_E466A25D X-CRM114-Status: GOOD ( 30.82 ) 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: multipart/mixed; boundary="===============7601864520474944652==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7601864520474944652== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ard Biesheuvel writes: > c13 is not a register, it is a value in one of the dimensions of the > ARM sysreg space, and probably covers other system registers that > pre-v7 cores do implement. > Better to use its architectural name (TPIDRPRW) and clarify that > pre-v6k/v7 cores simply don't implement it. Thanks, I'll reword the commit message > Could we split this up? I could split up the assembler macro changes which add a temporary register to the calls getting the current thread_info/task_struct value? If that would help get this reviewed, I'd be happy to do that. Otherwise, it's pretty much all-or-nothing as enabling THREAD_INFO_IN_TASK requires a bunch of synchronized changes. >> +#ifdef CONFIG_THREAD_INFO_IN_TASK > > No need for this #ifdef - it only guards macros that will have no > effect if they are never instantiated (another case below) Sure, the resulting code is a bit less noisy, which seems good. >> +DECLARE_PER_CPU(struct task_struct *, current_task); >> + >> +static __always_inline struct task_struct *get_current(void) >> +{ >> + return raw_cpu_read(current_task); > > This needs to run with preemption disabled, or we might get migrated > to another CPU halfway through, and produce the wrong result (i.e., > the current task of the CPU we migrated from). However, it appears > that manipulating the preempt count will create a circular dependency > here. Yeah, I really don't understand the restrictions of this API well. Any code fetching the current task pointer better not be subject to preemption or that value will be stale at some point after it was computed. Do you know if it could ever be run in a context allowing preemption? > > Instead of using a per-CPU variable for current, I think it might be > better to borrow another system register (TPIDRURO or TPIDRURW) to > carry 'current' when THREAD_INFO_IN_TASK is in effect, similar to how > arm64 uses SP_EL0 - those registers could be preserved/restored in the > entry/exit from/to user space paths rather than in the context switch > path, and then be used any way we like while running in the kernel. Making sure these values don't leak through to user space somehow? I'm not excited by that prospect at all. But, perhaps someone can help me understand the conditions under which the current task value can be computed where preemption was enabled and have that not be a problem for the enclosing code? =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAmE1sbEACgkQ2yIaaQAA ABGusg/9FwN3xd/eIDwhSpWhgmZQsghjqpdH0H9Sjh/+nk4W6N9kRp22bty3b6Sx thxasQmaf6sgH+ZZA27hWbuoKU8QGBRj+cmjR9kSZWo/ia9C6QsqqvJB4W9Je6WQ S7wnmUrE2wIvcRsVNyPv1qBhpjoPq5yoCD8TainCrz9+n39QEmb4VL4ptwOpMvQr bk6iSoKdsv+KlZfOSGN4v4uO47KhMBpoJQQZGDsolBgmqDzKsI2LAqQUhLSt4YLr bZJkE7OGJ+DMrYCZBFka3P0UaJQC1mTdyv4IPYsLnY5wkNmje1AyfMYqgnjGVNgs 7mlkClXI+yrkBGSW6BHfEzpkAgjql+ZuEMBXY7TFNn0mUMuJ3qspJwwAU4YgFaHZ lkSp6aOJMCBshBvbbbG7BQ4unNlVhy43iJa9pHfMjeURSxV6dqydxmiQ7w9VjTJq g4pwRM8n7aoi2+aiPLgnR/Jva0U5JIM9Co4+97JtzbivVsnkLlZB2uC1DQe7VnPZ fPBg+ZDVYe46CftOjpmeG0Uogu2glKwUyaH3W+GTxXs4gHk6QfKkLZTaa+3FJQZv ejYsfvTeU/eAoMQeskyOOgvOlbkBxlGLiGUCvsV9pxZR2BwyFlGnTpz9Eq7ZZXG8 S+LacsRFQ87EmnAJBZMgRhL15/I0JOg3ybkYECzv3njVOUv2B2Y= =1sPs -----END PGP SIGNATURE----- --=-=-=-- --===============7601864520474944652== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============7601864520474944652==--