From: Keith Packard <keithp@keithp.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Abbott Liu" <liuwenliang@huawei.com>, "Alexander Sverdlin" <alexander.sverdlin@gmail.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Anshuman Khandual" <anshuman.khandual@arm.com>, "Arnd Bergmann" <arnd@arndb.de>, "Bjorn Andersson" <bjorn.andersson@linaro.org>, "Florian Fainelli" <f.fainelli@gmail.com>, "Geert Uytterhoeven" <geert+renesas@glider.be>, "Hartley Sweeten" <hsweeten@visionengravers.com>, "Jens Axboe" <axboe@kernel.dk>, "Jian Cai" <jiancai@google.com>, "Joe Perches" <joe@perches.com>, "Kees Cook" <keescook@chromium.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>, "Linus Walleij" <linus.walleij@linaro.org>, "Linux ARM" <linux-arm-kernel@lists.infradead.org>, "Manivannan Sadhasivam" <mani@kernel.org>, "Marc Zyngier" <maz@kernel.org>, "Masahiro Yamada" <masahiroy@kernel.org>, "Miguel Ojeda" <ojeda@kernel.org>, "Mike Rapoport" <rppt@kernel.org>, "Nathan Chancellor" <nathan@kernel.org>, "Nick Desaulniers" <ndesaulniers@google.com>, "Nicolas Pitre" <nico@fluxnic.net>, "Rob Herring" <robh@kernel.org>, "Russell King" <linux@armlinux.org.uk>, "Thomas Gleixner" <tglx@linutronix.de>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Valentin Schneider" <valentin.schneider@arm.com>, "Viresh Kumar" <viresh.kumar@linaro.org>, "Wolfram Sang (Renesas)" <wsa+renesas@sang-engineering.com>, "YiFei Zhu" <yifeifz2@illinois.edu> Subject: Re: [PATCH 2/3] ARM: Move thread_info into task_struct (v7 only) Date: Sun, 05 Sep 2021 23:14:09 -0700 [thread overview] Message-ID: <8735qifcy6.fsf@keithp.com> (raw) In-Reply-To: <CAMj1kXHHb_d4Exg7_5OdB-Ah=EQxVEUgEv1agUQZg-Rz8pLd5Q@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 2504 bytes --] Ard Biesheuvel <ardb@kernel.org> 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? -- -keith [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Keith Packard <keithp@keithp.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Abbott Liu" <liuwenliang@huawei.com>, "Alexander Sverdlin" <alexander.sverdlin@gmail.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Anshuman Khandual" <anshuman.khandual@arm.com>, "Arnd Bergmann" <arnd@arndb.de>, "Bjorn Andersson" <bjorn.andersson@linaro.org>, "Florian Fainelli" <f.fainelli@gmail.com>, "Geert Uytterhoeven" <geert+renesas@glider.be>, "Hartley Sweeten" <hsweeten@visionengravers.com>, "Jens Axboe" <axboe@kernel.dk>, "Jian Cai" <jiancai@google.com>, "Joe Perches" <joe@perches.com>, "Kees Cook" <keescook@chromium.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>, "Linus Walleij" <linus.walleij@linaro.org>, "Linux ARM" <linux-arm-kernel@lists.infradead.org>, "Manivannan Sadhasivam" <mani@kernel.org>, "Marc Zyngier" <maz@kernel.org>, "Masahiro Yamada" <masahiroy@kernel.org>, "Miguel Ojeda" <ojeda@kernel.org>, "Mike Rapoport" <rppt@kernel.org>, "Nathan Chancellor" <nathan@kernel.org>, "Nick Desaulniers" <ndesaulniers@google.com>, "Nicolas Pitre" <nico@fluxnic.net>, "Rob Herring" <robh@kernel.org>, "Russell King" <linux@armlinux.org.uk>, "Thomas Gleixner" <tglx@linutronix.de>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Valentin Schneider" <valentin.schneider@arm.com>, "Viresh Kumar" <viresh.kumar@linaro.org>, "Wolfram Sang (Renesas)" <wsa+renesas@sang-engineering.com>, "YiFei Zhu" <yifeifz2@illinois.edu> Subject: Re: [PATCH 2/3] ARM: Move thread_info into task_struct (v7 only) Date: Sun, 05 Sep 2021 23:14:09 -0700 [thread overview] Message-ID: <8735qifcy6.fsf@keithp.com> (raw) In-Reply-To: <CAMj1kXHHb_d4Exg7_5OdB-Ah=EQxVEUgEv1agUQZg-Rz8pLd5Q@mail.gmail.com> [-- Attachment #1.1: Type: text/plain, Size: 2504 bytes --] Ard Biesheuvel <ardb@kernel.org> 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? -- -keith [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-09-06 6:14 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-02 15:54 [PATCH 0/2]: ARM: Enable THREAD_INFO_IN_TASK Keith Packard 2021-09-02 15:54 ` Keith Packard 2021-09-02 15:54 ` [PATCH 1/2] ARM: Add per-cpu variable holding cpu number Keith Packard 2021-09-02 15:54 ` Keith Packard 2021-09-02 15:54 ` [PATCH 2/2] ARM: Move thread_info into task_struct Keith Packard 2021-09-02 15:54 ` Keith Packard 2021-09-02 16:07 ` [PATCH 0/2]: ARM: Enable THREAD_INFO_IN_TASK Kees Cook 2021-09-02 16:07 ` Kees Cook 2021-09-02 16:18 ` Ard Biesheuvel 2021-09-02 16:18 ` Ard Biesheuvel 2021-09-02 17:37 ` Kees Cook 2021-09-02 17:37 ` Kees Cook 2021-09-02 16:54 ` Russell King (Oracle) 2021-09-02 16:54 ` Russell King (Oracle) 2021-09-02 16:53 ` Russell King (Oracle) 2021-09-02 16:53 ` Russell King (Oracle) 2021-09-02 17:35 ` Kees Cook 2021-09-02 17:35 ` Kees Cook 2021-09-02 17:58 ` Keith Packard 2021-09-02 17:58 ` Keith Packard 2021-09-04 6:09 ` [PATCH 0/2] ARM: support THREAD_INFO_IN_TASK (v7 only) (v2) Keith Packard 2021-09-04 6:09 ` Keith Packard 2021-09-04 6:09 ` [PATCH 1/3] ARM: Pass cpu number to secondary_start_kernel Keith Packard 2021-09-04 6:09 ` Keith Packard 2021-09-05 20:25 ` Ard Biesheuvel 2021-09-05 20:25 ` Ard Biesheuvel 2021-09-04 6:09 ` [PATCH 2/3] ARM: Move thread_info into task_struct (v7 only) Keith Packard 2021-09-04 6:09 ` Keith Packard 2021-09-05 20:56 ` Ard Biesheuvel 2021-09-05 20:56 ` Ard Biesheuvel 2021-09-06 6:14 ` Keith Packard [this message] 2021-09-06 6:14 ` Keith Packard 2021-09-06 7:49 ` Ard Biesheuvel 2021-09-06 7:49 ` Ard Biesheuvel 2021-09-07 15:24 ` Keith Packard 2021-09-07 15:24 ` Keith Packard 2021-09-07 16:05 ` Ard Biesheuvel 2021-09-07 16:05 ` Ard Biesheuvel 2021-09-07 22:17 ` Keith Packard 2021-09-07 22:17 ` Keith Packard 2021-09-06 6:20 ` Keith Packard 2021-09-06 6:20 ` Keith Packard 2021-09-04 6:09 ` [PATCH 3/3] ARM: Add per-cpu variable cpu_number " Keith Packard 2021-09-04 6:09 ` Keith Packard 2021-09-07 22:00 ` [PATCH 0/7] ARM: support THREAD_INFO_IN_TASK (v3) Keith Packard 2021-09-07 22:00 ` Keith Packard 2021-09-07 22:00 ` [PATCH 1/7] ARM: Pass cpu number to secondary_start_kernel Keith Packard 2021-09-07 22:00 ` Keith Packard 2021-09-07 22:00 ` [PATCH 2/7] ARM: Pass task " Keith Packard 2021-09-07 22:00 ` Keith Packard 2021-09-07 22:00 ` [PATCH 3/7] ARM: Use smp_processor_id() in vfp_pm_suspend instead of ti->cpu Keith Packard 2021-09-07 22:00 ` Keith Packard 2021-09-07 22:00 ` [PATCH 4/7] ARM: Use hack from powerpc to get current cpu number Keith Packard 2021-09-07 22:00 ` Keith Packard 2021-09-08 7:45 ` Ard Biesheuvel 2021-09-08 7:45 ` Ard Biesheuvel 2021-09-07 22:00 ` [PATCH 5/7] ARM: Stop using TPIDRPRW to hold per_cpu_offset Keith Packard 2021-09-07 22:00 ` Keith Packard 2021-09-09 13:54 ` Ard Biesheuvel 2021-09-09 13:54 ` Ard Biesheuvel 2021-09-07 22:00 ` [PATCH 6/7] ARM: Use TPIDRPRW for current Keith Packard 2021-09-07 22:00 ` Keith Packard 2021-09-09 13:56 ` Ard Biesheuvel 2021-09-09 13:56 ` Ard Biesheuvel 2021-09-07 22:00 ` [PATCH 7/7] ARM: Move thread_info into task_struct (v7 only) Keith Packard 2021-09-07 22:00 ` Keith Packard 2021-09-08 7:01 ` [PATCH 0/7] ARM: support THREAD_INFO_IN_TASK (v3) Krzysztof Kozlowski 2021-09-08 7:01 ` Krzysztof Kozlowski 2021-09-08 7:47 ` Ard Biesheuvel 2021-09-08 7:47 ` Ard Biesheuvel 2021-09-08 7:50 ` Geert Uytterhoeven 2021-09-08 7:50 ` Geert Uytterhoeven
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8735qifcy6.fsf@keithp.com \ --to=keithp@keithp.com \ --cc=akpm@linux-foundation.org \ --cc=alexander.sverdlin@gmail.com \ --cc=anshuman.khandual@arm.com \ --cc=ardb@kernel.org \ --cc=arnd@arndb.de \ --cc=axboe@kernel.dk \ --cc=bjorn.andersson@linaro.org \ --cc=f.fainelli@gmail.com \ --cc=geert+renesas@glider.be \ --cc=hsweeten@visionengravers.com \ --cc=jiancai@google.com \ --cc=joe@perches.com \ --cc=keescook@chromium.org \ --cc=krzysztof.kozlowski@canonical.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=liuwenliang@huawei.com \ --cc=mani@kernel.org \ --cc=masahiroy@kernel.org \ --cc=maz@kernel.org \ --cc=nathan@kernel.org \ --cc=ndesaulniers@google.com \ --cc=nico@fluxnic.net \ --cc=ojeda@kernel.org \ --cc=robh@kernel.org \ --cc=rppt@kernel.org \ --cc=tglx@linutronix.de \ --cc=u.kleine-koenig@pengutronix.de \ --cc=valentin.schneider@arm.com \ --cc=viresh.kumar@linaro.org \ --cc=wsa+renesas@sang-engineering.com \ --cc=yifeifz2@illinois.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.