* Re: linux-next: build failure after merge of the origin tree
From: Michael Ellerman @ 2021-09-14 12:21 UTC (permalink / raw)
To: Linus Torvalds, Stephen Rothwell
Cc: Linux Next Mailing List, PowerPC, Linux Kernel Mailing List
In-Reply-To: <CAHk-=wieb251-L9D-v3BeF-Cna8r5kLz2MeyXDS3mrNUmXNYrg@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Sep 13, 2021 at 7:08 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> That patch works for me - for the ppc64_defconfig build at least.
>
> Yeah, I just tested the allmodconfig case too, although I suspect it's
> essentially the same wrt the boot *.S files, so it probably doesn't
> matter.
>
> I'd like to have Michael or somebody who can actually run some tests
> on the end result ack that patch (or - even better - come up with
> something cleaner) before committing it.
>
> Because yeah, the build failure is annoying and I apologize, but I'd
> rather have the build fail overnight than commit something that builds
> but then is subtle buggy for some reason.
>
> But if I don't get any other comments by the time I'm up again
> tomorrow, I'll just commit it as "fixes the build".
I ended up doing a more minimal version of your change.
I sent it separately, or it's here:
https://lore.kernel.org/lkml/20210914121723.3756817-1-mpe@ellerman.id.au/
cheers
^ permalink raw reply
* Re: [PATCH bpf-next v2] bpf: Change value of MAX_TAIL_CALL_CNT from 32 to 33
From: Tiezhu Yang @ 2021-09-14 12:36 UTC (permalink / raw)
To: Daniel Borkmann, Shubham Bansal, Russell King, Alexei Starovoitov,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Zi Shen Lim, Catalin Marinas,
Will Deacon, Paul Burton, Thomas Bogendoerfer, naveen.n.rao,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Luke Nelson, Xi Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou,
bjorn, davem, Johan Almbladh, Paul Chaignon
Cc: netdev, linux-kernel, linux-mips, sparclinux, bpf, linuxppc-dev,
linux-riscv, linux-arm-kernel
In-Reply-To: <0fb8d16f-67e7-7197-fce2-a4c17f1e5987@iogearbox.net>
On 09/14/2021 03:30 PM, Daniel Borkmann wrote:
> On 9/11/21 3:56 AM, Tiezhu Yang wrote:
>>
[...]
>> With this patch, it does not change the current limit 33,
>> MAX_TAIL_CALL_CNT
>> can reflect the actual max tail call count, the tailcall selftests
>> can work
>> well, and also the above failed testcase in test_bpf can be fixed for
>> the
>> interpreter (all archs) and the JIT (all archs except for x86).
>>
>> # uname -m
>> x86_64
>> # echo 1 > /proc/sys/net/core/bpf_jit_enable
>> # modprobe test_bpf
>> # dmesg | grep -w FAIL
>> Tail call error path, max count reached jited:1 ret 33 != 34 FAIL
>
> Could you also state in here which archs you have tested with this
> change? I
> presume /every/ arch which has a JIT?
OK, will do it in v3.
I have tested on x86 and mips.
>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
>> ---
>>
>> v2:
>> -- fix the typos in the commit message and update the commit message.
>> -- fix the failed tailcall selftests for x86 jit.
>> I am not quite sure the change on x86 is proper, with this change,
>> tailcall selftests passed, but tailcall limit test in test_bpf.ko
>> failed, I do not know the reason now, I think this is another
>> issue,
>> maybe someone more versed in x86 jit could take a look.
>
> There should be a series from Johan coming today with regards to
> test_bpf.ko
> that will fix the "tail call error path, max count reached" test which
> had an
> assumption in that R0 would always be valid for the fall-through and
> could be
> passed to the bpf_exit insn whereas it is not guaranteed and verifier,
> for
> example, forbids a subsequent access to R0 w/o reinit. For your
> testing, I
> would suggested to recheck once this series is out.
I will test the following patch on x86 and mips:
[PATCH bpf v4 13/14] bpf/tests: Fix error in tail call limit tests
[...]
>> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>> index 0fe6aac..74a9e61 100644
>> --- a/arch/x86/net/bpf_jit_comp.c
>> +++ b/arch/x86/net/bpf_jit_comp.c
>> @@ -402,7 +402,7 @@ static int get_pop_bytes(bool *callee_regs_used)
>> * ... bpf_tail_call(void *ctx, struct bpf_array *array, u64 index)
>> ...
>> * if (index >= array->map.max_entries)
>> * goto out;
>> - * if (++tail_call_cnt > MAX_TAIL_CALL_CNT)
>> + * if (tail_call_cnt++ == MAX_TAIL_CALL_CNT)
>
> Why such inconsistency to e.g. above with arm64 case but also compared to
> x86 32 bit which uses JAE? If so, we should cleanly follow the reference
> implementation (== interpreter) _everywhere_ and _not_ introduce
> additional
> variants/implementations across JITs.
In order tokeep consistencyand make as few changes as possible,
<javascript:void(0);>I will modify the check condition as follows:
#define MAX_TAIL_CALL_CNT 33
(1) for x86, arm64, ... (0 ~ 32)
tcc = 0;
if (tcc == MAX_TAIL_CALL_CNT)
goto out;
tcc++;
(2) for mips, riscv (33 ~ 1)
tcc = MAX_TAIL_CALL_CNT;
if (tcc == 0)
goto out;
tcc--;
[...]
^ permalink raw reply
* Re: [PATCH trivial] powerpc/powernv/dump: Fix typo is comment
From: Joel Stanley @ 2021-09-14 13:29 UTC (permalink / raw)
To: Vasant Hegde; +Cc: linuxppc-dev
In-Reply-To: <20210914101646.30684-1-hegdevasant@linux.vnet.ibm.com>
On Tue, 14 Sept 2021 at 10:17, Vasant Hegde
<hegdevasant@linux.vnet.ibm.com> wrote:
>
> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
There's a typo in your commit message :)
> ---
> arch/powerpc/platforms/powernv/opal-dump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
> index 00c5a59d82d9..717d1d30ade5 100644
> --- a/arch/powerpc/platforms/powernv/opal-dump.c
> +++ b/arch/powerpc/platforms/powernv/opal-dump.c
> @@ -419,7 +419,7 @@ void __init opal_platform_dump_init(void)
> int rc;
> int dump_irq;
>
> - /* ELOG not supported by firmware */
> + /* Dump not supported by firmware */
> if (!opal_check_token(OPAL_DUMP_READ))
> return;
>
> --
> 2.31.1
>
^ permalink raw reply
* Re: [RFC PATCH 0/8] Move task_struct::cpu back into thread_info
From: Christophe Leroy @ 2021-09-14 13:49 UTC (permalink / raw)
To: Ard Biesheuvel, linux-kernel
Cc: Peter Zijlstra, Catalin Marinas, Paul Mackerras, linux-riscv,
Will Deacon, linux-s390, Arnd Bergmann, Russell King,
Christian Borntraeger, Ingo Molnar, Albert Ou, Kees Cook,
Vasily Gorbik, Heiko Carstens, Keith Packard, Borislav Petkov,
Andy Lutomirski, Paul Walmsley, Thomas Gleixner, linux-arm-kernel,
linuxppc-dev, Palmer Dabbelt, Linus Torvalds
In-Reply-To: <20210914121036.3975026-1-ardb@kernel.org>
Le 14/09/2021 à 14:10, Ard Biesheuvel a écrit :
> Commit c65eacbe290b ("sched/core: Allow putting thread_info into
> task_struct") mentions that, along with moving thread_info into
> task_struct, the cpu field is moved out of the former into the latter,
> but does not explain why.
I think it does explain why (init/Kconfig): "an arch will need to remove
all thread_info fields except flags".
IIUC initially the intention with THREAD_INFO_IN_TASK was to remove
everything from thread_info, but at the end it didn't happen it seems.
>
> While collaborating with Keith on adding THREAD_INFO_IN_TASK support to
> ARM, we noticed that keeping CPU in task_struct is problematic for
> architectures that define raw_smp_processor_id() in terms of this field,
> as it requires linux/sched.h to be included, which causes a lot of pain
> in terms of circular dependencies (or 'header soup', as the original
> commit refers to it).
>
> For examples of how existing architectures work around this, please
> refer to patches #6 or #7. In the former case, it uses an awful
> asm-offsets hack to index thread_info/current without using its type
> definition. The latter approach simply keeps a copy of the task_struct
> CPU field in thread_info, and keeps it in sync at context switch time.
It was a pain when implementing that on powerpc, so I really like your
idea, the series looks good to me.
>
> Patch #8 reverts this latter approach for ARM, but this code is still
> under review so it does not currently apply to mainline.
>
> We also discussed introducing yet another Kconfig symbol to indicate
> that the arch has THREAD_INFO_IN_TASK enabled but still prefers to keep
> its CPU field in thread_info, but simply keeping it in thread_info in
> all cases seems to be the cleanest approach here.
Yes, if we can avoid yet another config, that's better. We already have
so many configs that are supposed to be temporary and have lasted for
years if not decades.
Christophe
^ permalink raw reply
* Re: [RFC PATCH 0/8] Move task_struct::cpu back into thread_info
From: Mark Rutland @ 2021-09-14 13:55 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Peter Zijlstra, Paul Mackerras, linux-riscv, Will Deacon,
linux-s390, Arnd Bergmann, Russell King, Christian Borntraeger,
Ingo Molnar, Catalin Marinas, Albert Ou, Kees Cook, Vasily Gorbik,
Heiko Carstens, Keith Packard, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Thomas Gleixner, linux-arm-kernel, linuxppc-dev,
linux-kernel, Palmer Dabbelt, Linus Torvalds
In-Reply-To: <20210914121036.3975026-1-ardb@kernel.org>
On Tue, Sep 14, 2021 at 02:10:28PM +0200, Ard Biesheuvel wrote:
> Commit c65eacbe290b ("sched/core: Allow putting thread_info into
> task_struct") mentions that, along with moving thread_info into
> task_struct, the cpu field is moved out of the former into the latter,
> but does not explain why.
From what I recall of talking to Andy around that time, when converting
arm64 over, the theory was that over time we'd move more and more out of
thread_info and into task_struct or thread_struct, until task_struct
supplanted thread_info entirely, and that all became generic.
I think the key gain there was making things more *generic*, and there
are other ways we could do that in future without moving more into
task_struct (e.g. with a geenric thread_info and arch_thread_info inside
that).
With that in mind, and given the diffstat, I think this is worthwhile.
FWIW, for the series:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> While collaborating with Keith on adding THREAD_INFO_IN_TASK support to
> ARM, we noticed that keeping CPU in task_struct is problematic for
> architectures that define raw_smp_processor_id() in terms of this field,
> as it requires linux/sched.h to be included, which causes a lot of pain
> in terms of circular dependencies (or 'header soup', as the original
> commit refers to it).
>
> For examples of how existing architectures work around this, please
> refer to patches #6 or #7. In the former case, it uses an awful
> asm-offsets hack to index thread_info/current without using its type
> definition. The latter approach simply keeps a copy of the task_struct
> CPU field in thread_info, and keeps it in sync at context switch time.
>
> Patch #8 reverts this latter approach for ARM, but this code is still
> under review so it does not currently apply to mainline.
>
> We also discussed introducing yet another Kconfig symbol to indicate
> that the arch has THREAD_INFO_IN_TASK enabled but still prefers to keep
> its CPU field in thread_info, but simply keeping it in thread_info in
> all cases seems to be the cleanest approach here.
>
> Cc: Keith Packard <keithpac@amazon.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Albert Ou <aou@eecs.berkeley.edu>
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-riscv@lists.infradead.org
> Cc: linux-s390@vger.kernel.org
>
> Ard Biesheuvel (8):
> arm64: add CPU field to struct thread_info
> x86: add CPU field to struct thread_info
> s390: add CPU field to struct thread_info
> powerpc: add CPU field to struct thread_info
> sched: move CPU field back into thread_info if THREAD_INFO_IN_TASK=y
> powerpc: smp: remove hack to obtain offset of task_struct::cpu
> riscv: rely on core code to keep thread_info::cpu updated
> ARM: rely on core code to keep thread_info::cpu updated
>
> arch/arm/include/asm/switch_to.h | 14 --------------
> arch/arm/kernel/smp.c | 3 ---
> arch/arm64/include/asm/thread_info.h | 1 +
> arch/arm64/kernel/asm-offsets.c | 2 +-
> arch/arm64/kernel/head.S | 2 +-
> arch/powerpc/Makefile | 11 -----------
> arch/powerpc/include/asm/smp.h | 17 +----------------
> arch/powerpc/include/asm/thread_info.h | 3 +++
> arch/powerpc/kernel/asm-offsets.c | 4 +---
> arch/powerpc/kernel/smp.c | 2 +-
> arch/riscv/kernel/asm-offsets.c | 1 -
> arch/riscv/kernel/entry.S | 5 -----
> arch/riscv/kernel/head.S | 1 -
> arch/s390/include/asm/thread_info.h | 1 +
> arch/x86/include/asm/thread_info.h | 3 +++
> include/linux/sched.h | 6 +-----
> kernel/sched/sched.h | 4 ----
> 17 files changed, 14 insertions(+), 66 deletions(-)
>
> --
> 2.30.2
>
^ permalink raw reply
* Re: [PATCH RESEND v3 6/6] powerpc/signal: Use unsafe_copy_siginfo_to_user()
From: Christophe Leroy @ 2021-09-14 14:00 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-kernel, hch, Paul Mackerras, linuxppc-dev
In-Reply-To: <87ilz4mgts.fsf@disp2133>
Le 13/09/2021 à 21:11, Eric W. Biederman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>
>> Le 13/09/2021 à 18:21, Eric W. Biederman a écrit :
>>> ebiederm@xmission.com (Eric W. Biederman) writes:
>>>
>>>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>>>
>>>>> Use unsafe_copy_siginfo_to_user() in order to do the copy
>>>>> within the user access block.
>>>>>
>>>>> On an mpc 8321 (book3s/32) the improvment is about 5% on a process
>>>>> sending a signal to itself.
>>>
>>> If you can't make function calls from an unsafe macro there is another
>>> way to handle this that doesn't require everything to be inline.
>>>
>>> From a safety perspective it is probably even a better approach.
>>
>> Yes but that's exactly what I wanted to avoid for the native ppc32 case: this
>> double hop means useless pressure on the cache. The siginfo_t structure is 128
>> bytes large, that means 8 lines of cache on powerpc 8xx.
>>
>> But maybe it is acceptable to do that only for the compat case. Let me think
>> about it, it might be quite easy.
>
> The places get_signal is called tend to be well known. So I think we
> are safe from a capacity standpoint.
>
> I am not certain it makes a difference in capacity as there is a high
> probability that the stack was deeper recently than it is now which
> suggests the cache blocks might already be in the cache.
>
> My sense it is worth benchmarking before optimizing out the extra copy
> like that.
>
> On the extreme side there is simply building the entire sigframe on the
> stack and then just calling it copy_to_user. As the stack cache lines
> are likely to be hot, and copy_to_user is quite well optimized
> there is a real possibility that it is faster to build everything
> on the kernel stack, and then copy it to the user space stack.
>
> It is also possible that I am wrong and we may want to figure out how
> far up we can push the conversion to the 32bit siginfo format.
>
> If could move the work into collect_signal we could guarantee there
> would be no extra work. That would require adjusting the sigframe
> generation code on all of the architectures.
>
> There is a lot we can do but we need benchmarking to tell if it is
> worth it.
>
Sure, I'm benchmarking all the work I have been doing on signal code
with the following simple app that I run with 'perf stat':
#include <stdlib.h>
#include <signal.h>
void sigusr1(int sig) { }
int main(int argc, char **argv)
{
int i = 100000;
signal(SIGUSR1, sigusr1);
for (;i--;)
raise(SIGUSR1);
exit(0);
}
On an mpc8321 a 32 bits powerpc with KUAP enabled (KUAP is equivalent of
x86 SMAP)
Before changing copy_siginfo_to_user() to unsafe_copy_siginfo_to_user(),
'perf stat' reports 1983 msec (task-clock)
After my change I get 1900 msec.
With your approach I get 1930 msec, so we are loosing 36% of the benefit
of converting to the 'unsafe_' alternative.
So I think it is worth it.
Christophe
^ permalink raw reply
* [PATCH v4 1/5] powerpc/signal64: Access function descriptor with user access block
From: Christophe Leroy @ 2021-09-14 14:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
ebiederm, hch
Cc: linuxppc-dev, linux-kernel
Access the function descriptor of the handler within a
user access block.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v3: Flatten the change to avoid nested gotos.
---
arch/powerpc/kernel/signal_64.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index 1831bba0582e..7b1cd50bc4fb 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -936,8 +936,13 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
func_descr_t __user *funct_desc_ptr =
(func_descr_t __user *) ksig->ka.sa.sa_handler;
- err |= get_user(regs->ctr, &funct_desc_ptr->entry);
- err |= get_user(regs->gpr[2], &funct_desc_ptr->toc);
+ if (!user_read_access_begin(funct_desc_ptr, sizeof(func_descr_t)))
+ goto badfunc;
+
+ unsafe_get_user(regs->ctr, &funct_desc_ptr->entry, badfunc_block);
+ unsafe_get_user(regs->gpr[2], &funct_desc_ptr->toc, badfunc_block);
+
+ user_read_access_end();
}
/* enter the signal handler in native-endian mode */
@@ -962,5 +967,12 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
badframe:
signal_fault(current, regs, "handle_rt_signal64", frame);
+ return 1;
+
+badfunc_block:
+ user_read_access_end();
+badfunc:
+ signal_fault(current, regs, __func__, (void __user *)ksig->ka.sa.sa_handler);
+
return 1;
}
--
2.31.1
^ permalink raw reply related
* [PATCH v4 4/5] powerpc/uaccess: Add unsafe_clear_user()
From: Christophe Leroy @ 2021-09-14 14:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
ebiederm, hch
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1718f38859d5366f82d5bef531f255cedf537b5d.1631629700.git.christophe.leroy@csgroup.eu>
Implement unsafe_clear_user() for powerpc.
It's a copy/paste of unsafe_copy_to_user() with value 0 as source.
It may be improved in a later patch by using 'dcbz' instruction
to zeroize full cache lines at once.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/uaccess.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 22c79ab40006..962b675485ff 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -467,6 +467,26 @@ do { \
unsafe_put_user(*(u8*)(_src + _i), (u8 __user *)(_dst + _i), e); \
} while (0)
+#define unsafe_clear_user(d, l, e) \
+do { \
+ u8 __user *_dst = (u8 __user *)(d); \
+ size_t _len = (l); \
+ int _i; \
+ \
+ for (_i = 0; _i < (_len & ~(sizeof(u64) - 1)); _i += sizeof(u64)) \
+ unsafe_put_user(0, (u64 __user *)(_dst + _i), e); \
+ if (_len & 4) { \
+ unsafe_put_user(0, (u32 __user *)(_dst + _i), e); \
+ _i += 4; \
+ } \
+ if (_len & 2) { \
+ unsafe_put_user(0, (u16 __user *)(_dst + _i), e); \
+ _i += 2; \
+ } \
+ if (_len & 1) \
+ unsafe_put_user(0, (u8 __user *)(_dst + _i), e); \
+} while (0)
+
#define HAVE_GET_KERNEL_NOFAULT
#define __get_kernel_nofault(dst, src, type, err_label) \
--
2.31.1
^ permalink raw reply related
* [PATCH v4 5/5] powerpc/signal: Use unsafe_copy_siginfo_to_user()
From: Christophe Leroy @ 2021-09-14 14:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
ebiederm, hch
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1718f38859d5366f82d5bef531f255cedf537b5d.1631629700.git.christophe.leroy@csgroup.eu>
Use unsafe_copy_siginfo_to_user() in order to do the copy
within the user access block.
On an mpc 8321 (book3s/32) the improvment is about 5% on a process
sending a signal to itself.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v4: Use another approach for compat: drop the unsafe_copy_siginfo_to_user32(), instead directly call copy_siginfo_to_external32() before user_access_begin()
v3: Don't leave compat aside, use the new unsafe_copy_siginfo_to_user32()
---
arch/powerpc/kernel/signal_32.c | 17 ++++++++---------
arch/powerpc/kernel/signal_64.c | 5 +----
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index ff101e2b3bab..f1f5dde0885f 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -710,12 +710,6 @@ static long restore_tm_user_regs(struct pt_regs *regs, struct mcontext __user *s
}
#endif
-#ifdef CONFIG_PPC64
-
-#define copy_siginfo_to_user copy_siginfo_to_user32
-
-#endif /* CONFIG_PPC64 */
-
/*
* Set up a signal frame for a "real-time" signal handler
* (one which gets siginfo).
@@ -731,6 +725,7 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
struct pt_regs *regs = tsk->thread.regs;
/* Save the thread's msr before get_tm_stackpointer() changes it */
unsigned long msr = regs->msr;
+ compat_siginfo_t uinfo;
/* Set up Signal Frame */
frame = get_sigframe(ksig, tsk, sizeof(*frame), 1);
@@ -744,6 +739,9 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
else
prepare_save_user_regs(1);
+ if (IS_ENABLED(CONFIG_COMPAT))
+ copy_siginfo_to_external32(&uinfo, &ksig->info);
+
if (!user_access_begin(newsp, __SIGNAL_FRAMESIZE + 16 + sizeof(*frame)))
goto badframe;
@@ -779,15 +777,16 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
asm("dcbst %y0; sync; icbi %y0; sync" :: "Z" (mctx->mc_pad[0]));
}
unsafe_put_sigset_t(&frame->uc.uc_sigmask, oldset, failed);
+ if (IS_ENABLED(CONFIG_COMPAT))
+ unsafe_copy_to_user(&frame->info, &uinfo, sizeof(frame->info), failed);
+ else
+ unsafe_copy_siginfo_to_user((void *)&frame->info, &ksig->info, failed);
/* create a stack frame for the caller of the handler */
unsafe_put_user(regs->gpr[1], newsp, failed);
user_access_end();
- if (copy_siginfo_to_user(&frame->info, &ksig->info))
- goto badframe;
-
regs->link = tramp;
#ifdef CONFIG_PPC_FPU_REGS
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index d80ff83cacb9..56c0c74aa28c 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -901,15 +901,12 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
}
unsafe_copy_to_user(&frame->uc.uc_sigmask, set, sizeof(*set), badframe_block);
+ unsafe_copy_siginfo_to_user(&frame->info, &ksig->info, badframe_block);
/* Allocate a dummy caller frame for the signal handler. */
unsafe_put_user(regs->gpr[1], newsp, badframe_block);
user_write_access_end();
- /* Save the siginfo outside of the unsafe block. */
- if (copy_siginfo_to_user(&frame->info, &ksig->info))
- goto badframe;
-
/* Make sure signal handler doesn't get spurious FP exceptions */
tsk->thread.fp_state.fpscr = 0;
--
2.31.1
^ permalink raw reply related
* [PATCH v4 3/5] signal: Add unsafe_copy_siginfo_to_user()
From: Christophe Leroy @ 2021-09-14 14:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
ebiederm, hch
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1718f38859d5366f82d5bef531f255cedf537b5d.1631629700.git.christophe.leroy@csgroup.eu>
In the same spirit as commit fb05121fd6a2 ("signal: Add
unsafe_get_compat_sigset()"), implement an 'unsafe' version of
copy_siginfo_to_user() in order to use it within user access blocks.
For that, also add an 'unsafe' version of clear_user().
This commit adds the generic fallback for unsafe_clear_user().
Architectures wanting to use unsafe_copy_siginfo_to_user() within a
user_access_begin() section have to make sure they have their
own unsafe_clear_user().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v3: Added precision about unsafe_clear_user() in commit message.
---
include/linux/signal.h | 15 +++++++++++++++
include/linux/uaccess.h | 1 +
kernel/signal.c | 5 -----
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 3f96a6374e4f..70ea7e741427 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -35,6 +35,21 @@ static inline void copy_siginfo_to_external(siginfo_t *to,
int copy_siginfo_to_user(siginfo_t __user *to, const kernel_siginfo_t *from);
int copy_siginfo_from_user(kernel_siginfo_t *to, const siginfo_t __user *from);
+static __always_inline char __user *si_expansion(const siginfo_t __user *info)
+{
+ return ((char __user *)info) + sizeof(struct kernel_siginfo);
+}
+
+#define unsafe_copy_siginfo_to_user(to, from, label) do { \
+ siginfo_t __user *__ucs_to = to; \
+ const kernel_siginfo_t *__ucs_from = from; \
+ char __user *__ucs_expansion = si_expansion(__ucs_to); \
+ \
+ unsafe_copy_to_user(__ucs_to, __ucs_from, \
+ sizeof(struct kernel_siginfo), label); \
+ unsafe_clear_user(__ucs_expansion, SI_EXPANSION_SIZE, label); \
+} while (0)
+
enum siginfo_layout {
SIL_KILL,
SIL_TIMER,
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index c05e903cef02..37073caac474 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -398,6 +398,7 @@ long strnlen_user_nofault(const void __user *unsafe_addr, long count);
#define unsafe_put_user(x,p,e) unsafe_op_wrap(__put_user(x,p),e)
#define unsafe_copy_to_user(d,s,l,e) unsafe_op_wrap(__copy_to_user(d,s,l),e)
#define unsafe_copy_from_user(d,s,l,e) unsafe_op_wrap(__copy_from_user(d,s,l),e)
+#define unsafe_clear_user(d, l, e) unsafe_op_wrap(__clear_user(d, l), e)
static inline unsigned long user_access_save(void) { return 0UL; }
static inline void user_access_restore(unsigned long flags) { }
#endif
diff --git a/kernel/signal.c b/kernel/signal.c
index 952741f6d0f9..23f168730b7e 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3324,11 +3324,6 @@ enum siginfo_layout siginfo_layout(unsigned sig, int si_code)
return layout;
}
-static inline char __user *si_expansion(const siginfo_t __user *info)
-{
- return ((char __user *)info) + sizeof(struct kernel_siginfo);
-}
-
int copy_siginfo_to_user(siginfo_t __user *to, const kernel_siginfo_t *from)
{
char __user *expansion = si_expansion(to);
--
2.31.1
^ permalink raw reply related
* [PATCH v4 2/5] powerpc/signal: Include the new stack frame inside the user access block
From: Christophe Leroy @ 2021-09-14 14:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
ebiederm, hch
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1718f38859d5366f82d5bef531f255cedf537b5d.1631629700.git.christophe.leroy@csgroup.eu>
Include the new stack frame inside the user access block and set it up
using unsafe_put_user().
On an mpc 8321 (book3s/32) the improvment is about 4% on a process
sending a signal to itself.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/signal_32.c | 29 +++++++++++++----------------
arch/powerpc/kernel/signal_64.c | 14 +++++++-------
2 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 0608581967f0..ff101e2b3bab 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -726,7 +726,7 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
struct rt_sigframe __user *frame;
struct mcontext __user *mctx;
struct mcontext __user *tm_mctx = NULL;
- unsigned long newsp = 0;
+ unsigned long __user *newsp;
unsigned long tramp;
struct pt_regs *regs = tsk->thread.regs;
/* Save the thread's msr before get_tm_stackpointer() changes it */
@@ -734,6 +734,7 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
/* Set up Signal Frame */
frame = get_sigframe(ksig, tsk, sizeof(*frame), 1);
+ newsp = (unsigned long __user *)((unsigned long)frame - (__SIGNAL_FRAMESIZE + 16));
mctx = &frame->uc.uc_mcontext;
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
tm_mctx = &frame->uc_transact.uc_mcontext;
@@ -743,7 +744,7 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
else
prepare_save_user_regs(1);
- if (!user_access_begin(frame, sizeof(*frame)))
+ if (!user_access_begin(newsp, __SIGNAL_FRAMESIZE + 16 + sizeof(*frame)))
goto badframe;
/* Put the siginfo & fill in most of the ucontext */
@@ -779,6 +780,9 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
}
unsafe_put_sigset_t(&frame->uc.uc_sigmask, oldset, failed);
+ /* create a stack frame for the caller of the handler */
+ unsafe_put_user(regs->gpr[1], newsp, failed);
+
user_access_end();
if (copy_siginfo_to_user(&frame->info, &ksig->info))
@@ -790,13 +794,8 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
tsk->thread.fp_state.fpscr = 0; /* turn off all fp exceptions */
#endif
- /* create a stack frame for the caller of the handler */
- newsp = ((unsigned long)frame) - (__SIGNAL_FRAMESIZE + 16);
- if (put_user(regs->gpr[1], (u32 __user *)newsp))
- goto badframe;
-
/* Fill registers for signal handler */
- regs->gpr[1] = newsp;
+ regs->gpr[1] = (unsigned long)newsp;
regs->gpr[3] = ksig->sig;
regs->gpr[4] = (unsigned long)&frame->info;
regs->gpr[5] = (unsigned long)&frame->uc;
@@ -826,7 +825,7 @@ int handle_signal32(struct ksignal *ksig, sigset_t *oldset,
struct sigframe __user *frame;
struct mcontext __user *mctx;
struct mcontext __user *tm_mctx = NULL;
- unsigned long newsp = 0;
+ unsigned long __user *newsp;
unsigned long tramp;
struct pt_regs *regs = tsk->thread.regs;
/* Save the thread's msr before get_tm_stackpointer() changes it */
@@ -834,6 +833,7 @@ int handle_signal32(struct ksignal *ksig, sigset_t *oldset,
/* Set up Signal Frame */
frame = get_sigframe(ksig, tsk, sizeof(*frame), 1);
+ newsp = (unsigned long __user *)((unsigned long)frame - __SIGNAL_FRAMESIZE);
mctx = &frame->mctx;
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
tm_mctx = &frame->mctx_transact;
@@ -843,7 +843,7 @@ int handle_signal32(struct ksignal *ksig, sigset_t *oldset,
else
prepare_save_user_regs(1);
- if (!user_access_begin(frame, sizeof(*frame)))
+ if (!user_access_begin(newsp, __SIGNAL_FRAMESIZE + sizeof(*frame)))
goto badframe;
sc = (struct sigcontext __user *) &frame->sctx;
@@ -873,6 +873,8 @@ int handle_signal32(struct ksignal *ksig, sigset_t *oldset,
unsafe_put_user(PPC_RAW_SC(), &mctx->mc_pad[1], failed);
asm("dcbst %y0; sync; icbi %y0; sync" :: "Z" (mctx->mc_pad[0]));
}
+ /* create a stack frame for the caller of the handler */
+ unsafe_put_user(regs->gpr[1], newsp, failed);
user_access_end();
regs->link = tramp;
@@ -881,12 +883,7 @@ int handle_signal32(struct ksignal *ksig, sigset_t *oldset,
tsk->thread.fp_state.fpscr = 0; /* turn off all fp exceptions */
#endif
- /* create a stack frame for the caller of the handler */
- newsp = ((unsigned long)frame) - __SIGNAL_FRAMESIZE;
- if (put_user(regs->gpr[1], (u32 __user *)newsp))
- goto badframe;
-
- regs->gpr[1] = newsp;
+ regs->gpr[1] = (unsigned long)newsp;
regs->gpr[3] = ksig->sig;
regs->gpr[4] = (unsigned long) sc;
regs_set_return_ip(regs, (unsigned long) ksig->ka.sa.sa_handler);
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index 7b1cd50bc4fb..d80ff83cacb9 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -847,13 +847,14 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
struct task_struct *tsk)
{
struct rt_sigframe __user *frame;
- unsigned long newsp = 0;
+ unsigned long __user *newsp;
long err = 0;
struct pt_regs *regs = tsk->thread.regs;
/* Save the thread's msr before get_tm_stackpointer() changes it */
unsigned long msr = regs->msr;
frame = get_sigframe(ksig, tsk, sizeof(*frame), 0);
+ newsp = (unsigned long __user *)((unsigned long)frame - __SIGNAL_FRAMESIZE);
/*
* This only applies when calling unsafe_setup_sigcontext() and must be
@@ -862,7 +863,7 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
if (!MSR_TM_ACTIVE(msr))
prepare_setup_sigcontext(tsk);
- if (!user_write_access_begin(frame, sizeof(*frame)))
+ if (!user_write_access_begin(newsp, __SIGNAL_FRAMESIZE + sizeof(*frame)))
goto badframe;
unsafe_put_user(&frame->info, &frame->pinfo, badframe_block);
@@ -900,6 +901,9 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
}
unsafe_copy_to_user(&frame->uc.uc_sigmask, set, sizeof(*set), badframe_block);
+ /* Allocate a dummy caller frame for the signal handler. */
+ unsafe_put_user(regs->gpr[1], newsp, badframe_block);
+
user_write_access_end();
/* Save the siginfo outside of the unsafe block. */
@@ -919,10 +923,6 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
regs_set_return_ip(regs, (unsigned long) &frame->tramp[0]);
}
- /* Allocate a dummy caller frame for the signal handler. */
- newsp = ((unsigned long)frame) - __SIGNAL_FRAMESIZE;
- err |= put_user(regs->gpr[1], (unsigned long __user *)newsp);
-
/* Set up "regs" so we "return" to the signal handler. */
if (is_elf2_task()) {
regs->ctr = (unsigned long) ksig->ka.sa.sa_handler;
@@ -947,7 +947,7 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
/* enter the signal handler in native-endian mode */
regs_set_return_msr(regs, (regs->msr & ~MSR_LE) | (MSR_KERNEL & MSR_LE));
- regs->gpr[1] = newsp;
+ regs->gpr[1] = (unsigned long)newsp;
regs->gpr[3] = ksig->sig;
regs->result = 0;
if (ksig->ka.sa.sa_flags & SA_SIGINFO) {
--
2.31.1
^ permalink raw reply related
* [PATCH v2 00/29] Change wildcards on ABI files
From: Mauro Carvalho Chehab @ 2021-09-14 14:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linux Doc Mailing List
Cc: Heikki Krogerus, Kees Cook, Jonathan Corbet,
Mauro Carvalho Chehab, netdev, Richard Cochran, Anton Vorontsov,
linux-kernel, Johan Hovold, Tony Luck, Colin Cross, linux-usb,
linuxppc-dev, Peter Rosin
The ABI files are meant to be parsed via a script (scripts/get_abi.pl).
A new improvement on it will allow it to help to detect if an ABI description
is missing, or if the What: field won't match the actual location of the symbol.
In order for get_abi.pl to convert What: into regex, changes are needed on
existing ABI files, as the conversion should not be ambiguous.
One alternative would be to convert everything into regexes, but this
would generate a huge amount of patches/changes. So, instead, let's
touch only the ABI files that aren't following the de-facto wildcard
standards already found on most of the ABI files, e. g.:
/.../
*
<foo>
(option1|option2)
X
Y
Z
[0-9] (and variants)
A couple of the patches here came from v1, but most of the patches were
written to address things like rcN, where N is a wildcard.
We can't teach get_abi.pl to use an uppercase "N" letter to be a wildcard,
as the USB ABI already uses "N" inside some of their symbols, like
bNumEndpoints.
Mauro Carvalho Chehab (29):
ABI: sysfs-bus-usb: better document variable argument
ABI: sysfs-tty: better document module name parameter
ABI: sysfs-kernel-slab: use a wildcard for the cache name
ABI: security: fix location for evm and ima_policy
ABI: sysfs-class-tpm: use wildcards for pcr-* nodes
ABI: sysfs-bus-rapidio: use wildcards on What definitions
ABI: sysfs-class-cxl: place "not in a guest" at description
ABI: sysfs-class-devfreq-event: use the right wildcards on What
ABI: sysfs-class-mic: use the right wildcards on What definitions
ABI: pstore: Fix What field
ABI: sysfs-class-typec: fix a bad What field
ABI: sysfs-ata: use a proper wildcard for ata_*
ABI: sysfs-class-infiniband: use wildcards on What definitions
ABI: sysfs-bus-pci: use wildcards on What definitions
ABI: sysfs-bus-soundwire-master: use wildcards on What definitions
ABI: sysfs-bus-soundwire-slave: use wildcards on What definitions
ABI: sysfs-class-gnss: use wildcards on What definitions
ABI: sysfs-class-mei: use wildcards on What definitions
ABI: sysfs-class-mux: use wildcards on What definitions
ABI: sysfs-class-pwm: use wildcards on What definitions
ABI: sysfs-class-rc: use wildcards on What definitions
ABI: sysfs-class-rc-nuvoton: use wildcards on What definitions
ABI: sysfs-class-uwb_rc: use wildcards on What definitions
ABI: sysfs-class-uwb_rc-wusbhc: use wildcards on What definitions
ABI: sysfs-devices-platform-dock: use wildcards on What definitions
ABI: sysfs-devices-system-cpu: use wildcards on What definitions
ABI: sysfs-firmware-efi-esrt: use wildcards on What definitions
ABI: sysfs-platform-sst-atom: use wildcards on What definitions
ABI: sysfs-ptp: use wildcards on What definitions
.../ABI/stable/sysfs-class-infiniband | 64 ++++++-------
Documentation/ABI/stable/sysfs-class-tpm | 2 +-
Documentation/ABI/testing/evm | 4 +-
Documentation/ABI/testing/ima_policy | 2 +-
Documentation/ABI/testing/pstore | 3 +-
Documentation/ABI/testing/sysfs-ata | 2 +-
Documentation/ABI/testing/sysfs-bus-pci | 2 +-
Documentation/ABI/testing/sysfs-bus-rapidio | 32 +++----
.../ABI/testing/sysfs-bus-soundwire-master | 2 +-
.../ABI/testing/sysfs-bus-soundwire-slave | 2 +-
Documentation/ABI/testing/sysfs-bus-usb | 16 ++--
Documentation/ABI/testing/sysfs-class-cxl | 15 ++-
.../ABI/testing/sysfs-class-devfreq-event | 12 +--
Documentation/ABI/testing/sysfs-class-gnss | 2 +-
Documentation/ABI/testing/sysfs-class-mei | 18 ++--
Documentation/ABI/testing/sysfs-class-mic | 24 ++---
Documentation/ABI/testing/sysfs-class-mux | 2 +-
Documentation/ABI/testing/sysfs-class-pwm | 20 ++--
Documentation/ABI/testing/sysfs-class-rc | 14 +--
.../ABI/testing/sysfs-class-rc-nuvoton | 2 +-
Documentation/ABI/testing/sysfs-class-typec | 2 +-
Documentation/ABI/testing/sysfs-class-uwb_rc | 26 ++---
.../ABI/testing/sysfs-class-uwb_rc-wusbhc | 10 +-
.../ABI/testing/sysfs-devices-platform-dock | 10 +-
.../ABI/testing/sysfs-devices-system-cpu | 16 ++--
.../ABI/testing/sysfs-firmware-efi-esrt | 16 ++--
Documentation/ABI/testing/sysfs-kernel-slab | 94 +++++++++----------
.../ABI/testing/sysfs-platform-sst-atom | 2 +-
Documentation/ABI/testing/sysfs-ptp | 30 +++---
Documentation/ABI/testing/sysfs-tty | 32 +++----
30 files changed, 242 insertions(+), 236 deletions(-)
--
2.31.1
^ permalink raw reply
* [PATCH v2 07/29] ABI: sysfs-class-cxl: place "not in a guest" at description
From: Mauro Carvalho Chehab @ 2021-09-14 14:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linux Doc Mailing List
Cc: Andrew Donnellan, Jonathan Corbet, Mauro Carvalho Chehab,
linux-kernel, Frederic Barrat, linuxppc-dev
In-Reply-To: <cover.1631629496.git.mchehab+huawei@kernel.org>
The What: field should have just the location of the ABI.
Anything else should be inside the description.
This fixes its parsing by get_abi.pl script.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
Documentation/ABI/testing/sysfs-class-cxl | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl
index 818f55970efb..3c77677e0ca7 100644
--- a/Documentation/ABI/testing/sysfs-class-cxl
+++ b/Documentation/ABI/testing/sysfs-class-cxl
@@ -166,10 +166,11 @@ Description: read only
Decimal value of the Per Process MMIO space length.
Users: https://github.com/ibm-capi/libcxl
-What: /sys/class/cxl/<afu>m/pp_mmio_off (not in a guest)
+What: /sys/class/cxl/<afu>m/pp_mmio_off
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
+ (not in a guest)
Decimal value of the Per Process MMIO space offset.
Users: https://github.com/ibm-capi/libcxl
@@ -190,28 +191,31 @@ Description: read only
Identifies the revision level of the PSL.
Users: https://github.com/ibm-capi/libcxl
-What: /sys/class/cxl/<card>/base_image (not in a guest)
+What: /sys/class/cxl/<card>/base_image
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
+ (not in a guest)
Identifies the revision level of the base image for devices
that support loadable PSLs. For FPGAs this field identifies
the image contained in the on-adapter flash which is loaded
during the initial program load.
Users: https://github.com/ibm-capi/libcxl
-What: /sys/class/cxl/<card>/image_loaded (not in a guest)
+What: /sys/class/cxl/<card>/image_loaded
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
+ (not in a guest)
Will return "user" or "factory" depending on the image loaded
onto the card.
Users: https://github.com/ibm-capi/libcxl
-What: /sys/class/cxl/<card>/load_image_on_perst (not in a guest)
+What: /sys/class/cxl/<card>/load_image_on_perst
Date: December 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
+ (not in a guest)
Valid entries are "none", "user", and "factory".
"none" means PERST will not cause image to be loaded to the
card. A power cycle is required to load the image.
@@ -235,10 +239,11 @@ Description: write only
contexts on the card AFUs.
Users: https://github.com/ibm-capi/libcxl
-What: /sys/class/cxl/<card>/perst_reloads_same_image (not in a guest)
+What: /sys/class/cxl/<card>/perst_reloads_same_image
Date: July 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
+ (not in a guest)
Trust that when an image is reloaded via PERST, it will not
have changed.
--
2.31.1
^ permalink raw reply related
* [PATCH trivial v2] powerpc/powernv/dump: Fix typo in comment
From: Vasant Hegde @ 2021-09-14 14:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Vasant Hegde, joel
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
index 00c5a59d82d9..717d1d30ade5 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -419,7 +419,7 @@ void __init opal_platform_dump_init(void)
int rc;
int dump_irq;
- /* ELOG not supported by firmware */
+ /* Dump not supported by firmware */
if (!opal_check_token(OPAL_DUMP_READ))
return;
--
2.31.1
^ permalink raw reply related
* Re: [PATCH] powerpc/boot: Fix build failure since GCC 4.9 removal
From: Guenter Roeck @ 2021-09-14 14:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, linux-next, torvalds, linux-kernel, sfr
In-Reply-To: <20210914121723.3756817-1-mpe@ellerman.id.au>
On Tue, Sep 14, 2021 at 10:17:23PM +1000, Michael Ellerman wrote:
> Stephen reported that the build was broken since commit
> 6d2ef226f2f1 ("compiler_attributes.h: drop __has_attribute() support for
> gcc4"), with errors such as:
>
> include/linux/compiler_attributes.h:296:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
> 296 | #if __has_attribute(__warning__)
> | ^~~~~~~~~~~~~~~
> make[2]: *** [arch/powerpc/boot/Makefile:225: arch/powerpc/boot/crt0.o] Error 1
>
> But we expect __has_attribute() to always be defined now that we've
> stopped using GCC 4.
>
> Linus debugged it to the point of reading the GCC sources, and noticing
> that the problem is that __has_attribute() is not defined when
> preprocessing assembly files, which is what we're doing here.
>
> Our assembly files don't include, or need, compiler_attributes.h, but
> they are getting it unconditionally from the -include in BOOT_CFLAGS,
> which is then added in its entirety to BOOT_AFLAGS.
>
> That -include was added in commit 77433830ed16 ("powerpc: boot: include
> compiler_attributes.h") so that we'd have "fallthrough" and other
> attributes defined for the C files in arch/powerpc/boot. But it's not
> needed for assembly files.
>
> The minimal fix is to move the addition to BOOT_CFLAGS of -include
> compiler_attributes.h until after we've copied BOOT_CFLAGS into
> BOOT_AFLAGS. That avoids including compiler_attributes.h for asm files,
> but makes no other change to BOOT_CFLAGS or BOOT_AFLAGS.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Debugged-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Guenter Roeck <linux@roeck-us.net>
> ---
> arch/powerpc/boot/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> This seemed safer as a minimal fix, rather than doing a more
> comprehensive separation of CFLAGS/AFLAGS. We can do that in a future
> patch.
>
> It passed my usual build/boot tests, including booting the built zImage
> on some real hardware, so this is good to go from my POV.
>
> cheers
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 6900d0ac2421..089ee3ea55c8 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -35,7 +35,6 @@ endif
> BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \
> -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
> - -include $(srctree)/include/linux/compiler_attributes.h \
> $(LINUXINCLUDE)
>
> ifdef CONFIG_PPC64_BOOT_WRAPPER
> @@ -70,6 +69,7 @@ ifeq ($(call cc-option-yn, -fstack-protector),y)
> BOOTCFLAGS += -fno-stack-protector
> endif
>
> +BOOTCFLAGS += -include $(srctree)/include/linux/compiler_attributes.h
> BOOTCFLAGS += -I$(objtree)/$(obj) -I$(srctree)/$(obj)
>
> DTC_FLAGS ?= -p 1024
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
From: Christophe Leroy @ 2021-09-14 14:47 UTC (permalink / raw)
To: Borislav Petkov, Michael Ellerman
Cc: linux-s390, Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh,
kvm, Tom Lendacky, Tianyu Lan, Joerg Roedel, x86, kexec,
linux-kernel, dri-devel, platform-driver-x86, Christoph Hellwig,
iommu, Andi Kleen, Paul Mackerras, amd-gfx, linux-fsdevel,
linux-graphics-maintainer, linuxppc-dev
In-Reply-To: <YUCOTIPPsJJpLO/d@zn.tnic>
Le 14/09/2021 à 13:58, Borislav Petkov a écrit :
> On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
>> Introduce a powerpc version of the cc_platform_has() function. This will
>> be used to replace the powerpc mem_encrypt_active() implementation, so
>> the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
>> attribute.
>>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>> arch/powerpc/platforms/pseries/Kconfig | 1 +
>> arch/powerpc/platforms/pseries/Makefile | 2 ++
>> arch/powerpc/platforms/pseries/cc_platform.c | 26 ++++++++++++++++++++
>> 3 files changed, 29 insertions(+)
>> create mode 100644 arch/powerpc/platforms/pseries/cc_platform.c
>
> Michael,
>
> can I get an ACK for the ppc bits to carry them through the tip tree
> pls?
>
> Btw, on a related note, cross-compiling this throws the following error here:
>
> $ make CROSS_COMPILE=/home/share/src/crosstool/gcc-9.4.0-nolibc/powerpc64-linux/bin/powerpc64-linux- V=1 ARCH=powerpc
>
> ...
>
> /home/share/src/crosstool/gcc-9.4.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -Wp,-MD,arch/powerpc/boot/.crt0.o.d -D__ASSEMBLY__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc -include ./include/linux/compiler_attributes.h -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -m32 -isystem /home/share/src/crosstool/gcc-9.4.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/9.4.0/include -mbig-endian -nostdinc -c -o arch/powerpc/boot/crt0.o arch/powerpc/boot/crt0.S
> In file included from <command-line>:
> ././include/linux/compiler_attributes.h:62:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
> 62 | #if __has_attribute(__assume_aligned__)
> | ^~~~~~~~~~~~~~~
> ././include/linux/compiler_attributes.h:62:20: error: missing binary operator before token "("
> 62 | #if __has_attribute(__assume_aligned__)
> | ^
> ././include/linux/compiler_attributes.h:88:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
> 88 | #if __has_attribute(__copy__)
> | ^~~~~~~~~~~~~~~
> ...
>
> Known issue?
>
> This __has_attribute() thing is supposed to be supported
> in gcc since 5.1 and I'm using the crosstool stuff from
> https://www.kernel.org/pub/tools/crosstool/ and gcc-9.4 above is pretty
> new so that should not happen actually.
>
> But it does...
>
> Hmmm.
>
Yes, see
https://lore.kernel.org/linuxppc-dev/20210914123919.58203eef@canb.auug.org.au/T/#t
^ permalink raw reply
* Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
From: Borislav Petkov @ 2021-09-14 14:56 UTC (permalink / raw)
To: Christophe Leroy
Cc: Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh, kvm,
dri-devel, platform-driver-x86, Paul Mackerras, linux-s390,
Andi Kleen, Joerg Roedel, x86, amd-gfx, Christoph Hellwig,
linux-graphics-maintainer, Tom Lendacky, Tianyu Lan, kexec,
linux-kernel, iommu, linux-fsdevel, linuxppc-dev
In-Reply-To: <41b93dae-2f10-15a3-a079-c632381bec73@csgroup.eu>
On Tue, Sep 14, 2021 at 04:47:41PM +0200, Christophe Leroy wrote:
> Yes, see https://lore.kernel.org/linuxppc-dev/20210914123919.58203eef@canb.auug.org.au/T/#t
Aha, more compiler magic stuff ;-\
Oh well, I guess that fix will land upstream soon.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [5.15-rc1][PPC][bisected 6d2ef226] mainline build breaks at ./include/linux/compiler_attributes.h:62:5: warning: "__has_attribute"
From: Nick Desaulniers @ 2021-09-14 15:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: sachinp, linux-kernel, Abdul Haleem, linux-next, ojeda,
linuxppc-dev
In-Reply-To: <20210914162223.363dd7c2@canb.auug.org.au>
On Mon, Sep 13, 2021 at 11:22 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Abdul,
>
> On Tue, 14 Sep 2021 11:39:44 +0530 Abdul Haleem <abdhalee@linux.vnet.ibm.com> wrote:
> >
> > Today's mainline kernel fails to compile on my powerpc box with below errors
> >
> > ././include/linux/compiler_attributes.h:62:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
> > #if __has_attribute(__assume_aligned__)
> > ^~~~~~~~~~~~~~~
> > ././include/linux/compiler_attributes.h:62:20: error: missing binary operator before token "("
> > #if __has_attribute(__assume_aligned__)
> > ^
> > ././include/linux/compiler_attributes.h:88:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
> > #if __has_attribute(__copy__)
> > ^~~~~~~~~~~~~~~
> > ././include/linux/compiler_attributes.h:88:20: error: missing binary operator before token "("
> > #if __has_attribute(__copy__)
> >
> > Kernel builds fine when below patch is reverted
> >
> > commit 6d2ef22 : compiler_attributes.h: drop __has_attribute() support for gcc4
>
> Thanks for your report.
>
> This is known and being addressed.
Thanks for the report. Support for GCC 4.X has been dropped.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76ae847497bc5207c479de5e2ac487270008b19b
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH] swiotlb: set IO TLB segment size via cmdline
From: Jan Beulich @ 2021-09-14 15:29 UTC (permalink / raw)
To: Roman Skakun
Cc: linux-doc, Peter Zijlstra, Viresh Kumar, linux-kernel,
Paul Mackerras, Will Deacon, Boris Ostrovsky, Marek Szyprowski,
Stefano Stabellini, Jonathan Corbet, Christoph Hellwig, xen-devel,
Paul E. McKenney, Konrad Rzeszutek Wilk, Muchun Song,
Thomas Gleixner, Juergen Gross, Thomas Bogendoerfer,
Andrii Anisov, linuxppc-dev, Randy Dunlap, linux-mips, iommu,
Roman Skakun, Andrew Morton, Lu Baolu, Robin Murphy,
Mike Rapoport, Maciej W. Rozycki
In-Reply-To: <20210914151016.3174924-1-Roman_Skakun@epam.com>
On 14.09.2021 17:10, Roman Skakun wrote:
> From: Roman Skakun <roman_skakun@epam.com>
>
> It is possible when default IO TLB size is not
> enough to fit a long buffers as described here [1].
>
> This patch makes a way to set this parameter
> using cmdline instead of recompiling a kernel.
>
> [1] https://www.xilinx.com/support/answers/72694.html
I'm not convinced the swiotlb use describe there falls under "intended
use" - mapping a 1280x720 framebuffer in a single chunk? (As an aside,
the bottom of this page is also confusing, as following "Then we can
confirm the modified swiotlb size in the boot log:" there is a log
fragment showing the same original size of 64Mb.
> --- a/arch/mips/cavium-octeon/dma-octeon.c
> +++ b/arch/mips/cavium-octeon/dma-octeon.c
> @@ -237,7 +237,7 @@ void __init plat_swiotlb_setup(void)
> swiotlbsize = 64 * (1<<20);
> #endif
> swiotlb_nslabs = swiotlbsize >> IO_TLB_SHIFT;
> - swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
> + swiotlb_nslabs = ALIGN(swiotlb_nslabs, swiotlb_io_seg_size());
In order to be sure to catch all uses like this one (including ones
which make it upstream in parallel to yours), I think you will want
to rename the original IO_TLB_SEGSIZE to e.g. IO_TLB_DEFAULT_SEGSIZE.
> @@ -81,15 +86,30 @@ static unsigned int max_segment;
> static unsigned long default_nslabs = IO_TLB_DEFAULT_SIZE >> IO_TLB_SHIFT;
>
> static int __init
> -setup_io_tlb_npages(char *str)
> +setup_io_tlb_params(char *str)
> {
> + unsigned long tmp;
> +
> if (isdigit(*str)) {
> - /* avoid tail segment of size < IO_TLB_SEGSIZE */
> - default_nslabs =
> - ALIGN(simple_strtoul(str, &str, 0), IO_TLB_SEGSIZE);
> + default_nslabs = simple_strtoul(str, &str, 0);
> }
> if (*str == ',')
> ++str;
> +
> + /* get max IO TLB segment size */
> + if (isdigit(*str)) {
> + tmp = simple_strtoul(str, &str, 0);
> + if (tmp)
> + io_tlb_seg_size = ALIGN(tmp, IO_TLB_SEGSIZE);
From all I can tell io_tlb_seg_size wants to be a power of 2. Merely
aligning to a multiple of IO_TLB_SEGSIZE isn't going to be enough.
Jan
^ permalink raw reply
* Re: [PATCH] swiotlb: set IO TLB segment size via cmdline
From: Christoph Hellwig @ 2021-09-14 15:30 UTC (permalink / raw)
To: Jan Beulich
Cc: Roman Skakun, linux-doc, Peter Zijlstra, Viresh Kumar,
linux-kernel, Paul Mackerras, Will Deacon, Boris Ostrovsky,
Marek Szyprowski, Stefano Stabellini, Jonathan Corbet,
Christoph Hellwig, xen-devel, Paul E. McKenney,
Konrad Rzeszutek Wilk, Muchun Song, Thomas Gleixner,
Juergen Gross, Thomas Bogendoerfer, Andrii Anisov, linuxppc-dev,
Randy Dunlap, linux-mips, iommu, Roman Skakun, Andrew Morton,
Lu Baolu, Robin Murphy, Mike Rapoport, Maciej W. Rozycki
In-Reply-To: <7c04db79-7de1-93ff-0908-9bad60a287b9@suse.com>
On Tue, Sep 14, 2021 at 05:29:07PM +0200, Jan Beulich wrote:
> I'm not convinced the swiotlb use describe there falls under "intended
> use" - mapping a 1280x720 framebuffer in a single chunk? (As an aside,
> the bottom of this page is also confusing, as following "Then we can
> confirm the modified swiotlb size in the boot log:" there is a log
> fragment showing the same original size of 64Mb.
It doesn't. We also do not add hacks to the kernel for whacky out
of tree modules.
^ permalink raw reply
* Re: [RFC PATCH 1/8] arm64: add CPU field to struct thread_info
From: Linus Torvalds @ 2021-09-14 15:41 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Peter Zijlstra, Paul Mackerras, linux-riscv, Will Deacon,
linux-s390, Arnd Bergmann, Russell King, Christian Borntraeger,
Ingo Molnar, Catalin Marinas, Albert Ou, Kees Cook, Vasily Gorbik,
Heiko Carstens, Keith Packard, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Thomas Gleixner, Linux ARM,
Linux Kernel Mailing List, Palmer Dabbelt, linuxppc-dev
In-Reply-To: <20210914121036.3975026-2-ardb@kernel.org>
On Tue, Sep 14, 2021 at 5:10 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> The CPU field will be moved back into thread_info even when
> THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of
> struct thread_info.
The series looks sane to me, but it strikes me that it's inconsistent
- here for arm64, you make it unconditional, but for the other
architectures you end up putting it inside a #ifdef CONFIG_SMP.
Was there some reason for this odd behavior?
Linus
^ permalink raw reply
* Re: [RFC PATCH 1/8] arm64: add CPU field to struct thread_info
From: Ard Biesheuvel @ 2021-09-14 15:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Peter Zijlstra, Paul Mackerras, linux-riscv, Will Deacon,
linux-s390, Arnd Bergmann, Russell King, Christian Borntraeger,
Ingo Molnar, Catalin Marinas, Albert Ou, Kees Cook, Vasily Gorbik,
Heiko Carstens, Keith Packard, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Thomas Gleixner, Linux ARM,
Linux Kernel Mailing List, Palmer Dabbelt, linuxppc-dev
In-Reply-To: <CAHk-=whkCzP-wyZ08r9RDJRx9cbANVHy-jy=vJAGTkSbXm50iA@mail.gmail.com>
On Tue, 14 Sept 2021 at 17:41, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, Sep 14, 2021 at 5:10 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > The CPU field will be moved back into thread_info even when
> > THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of
> > struct thread_info.
>
> The series looks sane to me, but it strikes me that it's inconsistent
> - here for arm64, you make it unconditional, but for the other
> architectures you end up putting it inside a #ifdef CONFIG_SMP.
>
> Was there some reason for this odd behavior?
>
Yes. CONFIG_SMP is a 'def_bool y' on arm64.
^ permalink raw reply
* Re: [RFC PATCH 5/8] sched: move CPU field back into thread_info if THREAD_INFO_IN_TASK=y
From: Linus Torvalds @ 2021-09-14 15:46 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Peter Zijlstra, Paul Mackerras, linux-riscv, Will Deacon,
linux-s390, Arnd Bergmann, Russell King, Christian Borntraeger,
Ingo Molnar, Catalin Marinas, Albert Ou, Kees Cook, Vasily Gorbik,
Heiko Carstens, Keith Packard, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Thomas Gleixner, Linux ARM,
Linux Kernel Mailing List, Palmer Dabbelt, linuxppc-dev
In-Reply-To: <20210914121036.3975026-6-ardb@kernel.org>
On Tue, Sep 14, 2021 at 5:11 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> static inline unsigned int task_cpu(const struct task_struct *p)
> {
> #ifdef CONFIG_THREAD_INFO_IN_TASK
> - return READ_ONCE(p->cpu);
> + return READ_ONCE(p->thread_info.cpu);
> #else
> return READ_ONCE(task_thread_info(p)->cpu);
> #endif
Those two lines look different, but aren't.
Please just remove the CONFIG_THREAD_INFO_IN_TASK conditional, and use
return READ_ONCE(task_thread_info(p)->cpu);
unconditionally, which now does the right thing regardless.
Linus
^ permalink raw reply
* Re: [RFC PATCH 5/8] sched: move CPU field back into thread_info if THREAD_INFO_IN_TASK=y
From: Ard Biesheuvel @ 2021-09-14 15:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Peter Zijlstra, Paul Mackerras, linux-riscv, Will Deacon,
linux-s390, Arnd Bergmann, Russell King, Christian Borntraeger,
Ingo Molnar, Catalin Marinas, Albert Ou, Kees Cook, Vasily Gorbik,
Heiko Carstens, Keith Packard, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Thomas Gleixner, Linux ARM,
Linux Kernel Mailing List, Palmer Dabbelt, linuxppc-dev
In-Reply-To: <CAHk-=whLEofPLzzTKXN5etnH5WqsTPQRLVv8uQgHnx7c59omBg@mail.gmail.com>
On Tue, 14 Sept 2021 at 17:49, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, Sep 14, 2021 at 5:11 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > static inline unsigned int task_cpu(const struct task_struct *p)
> > {
> > #ifdef CONFIG_THREAD_INFO_IN_TASK
> > - return READ_ONCE(p->cpu);
> > + return READ_ONCE(p->thread_info.cpu);
> > #else
> > return READ_ONCE(task_thread_info(p)->cpu);
> > #endif
>
> Those two lines look different, but aren't.
>
> Please just remove the CONFIG_THREAD_INFO_IN_TASK conditional, and use
>
> return READ_ONCE(task_thread_info(p)->cpu);
>
> unconditionally, which now does the right thing regardless.
>
Unfortunately not.
task_cpu() takes a 'const struct task_struct *', whereas
task_thread_info() takes a 'struct task_struct *'.
Since task_thread_info()-><foo> is widely used as an lvalue, I would
need to update task_cpu()'s prototype and fix up all the callers, some
of which take the const flavor themselves. Or introduce
'const_task_thread_info()' which takes the const flavor, and cannot be
used to instantiate lvalues.
Suggestions welcome, but this is the cleanest I could come up with.
^ permalink raw reply
* Re: [RFC PATCH 5/8] sched: move CPU field back into thread_info if THREAD_INFO_IN_TASK=y
From: Linus Torvalds @ 2021-09-14 15:58 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Peter Zijlstra, Paul Mackerras, linux-riscv, Will Deacon,
linux-s390, Arnd Bergmann, Russell King, Christian Borntraeger,
Ingo Molnar, Catalin Marinas, Albert Ou, Kees Cook, Vasily Gorbik,
Heiko Carstens, Keith Packard, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Thomas Gleixner, Linux ARM,
Linux Kernel Mailing List, Palmer Dabbelt, linuxppc-dev
In-Reply-To: <CAMj1kXH_Q4a4Gsi0Xuw=YsV-b7Mu8TQndk3Ei-JFaRV=GSiqUQ@mail.gmail.com>
On Tue, Sep 14, 2021 at 8:53 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> task_cpu() takes a 'const struct task_struct *', whereas
> task_thread_info() takes a 'struct task_struct *'.
Oh, annoying, but that's easily fixed. Just make that
static inline struct thread_info *task_thread_info(struct
task_struct *task) ..
be a simple
#define task_thread_info(tsk) (&(tsk)->thread_info)
instead. That actually then matches the !THREAD_INFO_IN_TASK case anyway.
Make the commit comment be about how that fixes the type problem.
Because while in many cases inline functions are superior to macros,
it clearly isn't the case in this case.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox