* [PATCHv7 12/12] misc: pci_endpoint_test: Add driver data for Layerscape PCIe controllers
From: Zhiqiang Hou @ 2020-08-11 9:54 UTC (permalink / raw)
To: linux-pci, devicetree, linux-kernel, linux-arm-kernel,
linuxppc-dev, robh+dt, bhelgaas, lorenzo.pieralisi, shawnguo,
leoyang.li, kishon, gustavo.pimentel, roy.zang, jingoohan1,
andrew.murray
Cc: minghuan.Lian, Hou Zhiqiang, mingkai.hu
In-Reply-To: <20200811095441.7636-1-Zhiqiang.Hou@nxp.com>
From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
The commit 0a121f9bc3f5 ("misc: pci_endpoint_test: Use streaming DMA
APIs for buffer allocation") changed to use streaming DMA APIs, however,
dma_map_single() might not return a 4KB aligned address, so add the
default_data as driver data for Layerscape PCIe controllers to make it
4KB aligned.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
---
V7:
- New patch.
drivers/misc/pci_endpoint_test.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 4a17f08de60f..70a790cd14c5 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -946,8 +946,12 @@ static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x),
.driver_data = (kernel_ulong_t)&default_data,
},
- { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
- { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, PCI_DEVICE_ID_LS1088A) },
+ { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0),
+ .driver_data = (kernel_ulong_t)&default_data,
+ },
+ { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, PCI_DEVICE_ID_LS1088A),
+ .driver_data = (kernel_ulong_t)&default_data,
+ },
{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
.driver_data = (kernel_ulong_t)&am654_data
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] powerpc/rtas: Restrict RTAS requests from userspace
From: Michael Ellerman @ 2020-08-11 11:48 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev; +Cc: nathanl, leobras.c, Daniel Axtens
In-Reply-To: <1ff85ddd-1b75-f49d-0ae2-edf9e5a199e2@linux.ibm.com>
Andrew Donnellan <ajd@linux.ibm.com> writes:
> On 10/8/20 4:40 pm, Michael Ellerman wrote:
>> Hi ajd,
>>
>> Thanks for taking care of this.
>>
>> I was going to merge this as-is, but given it's fixing a long standing
>> issue there's not really a big rush. So a few comments below.
>
> Thanks for the review.
>
>>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
>>> index a09eba03f180..ec1cae52d8bd 100644
>>> --- a/arch/powerpc/kernel/rtas.c
>>> +++ b/arch/powerpc/kernel/rtas.c
...
>>
>>> + { "ibm,activate-firmware", -1, -1, -1, -1 },
>>
>> Would it be worth making the indices 1-based, allowing 0 to be the
>> unused value, meaning you only have to initialise the used fields?
>
> 1-based array indices are morally reprehensible. It would make it
> cleaner but I kind of prefer an obvious and clear constant for unused, idk
In my defence they wouldn't be 1-based, they'd be 0-based but off-by-one :P
I'm happy either way, your choice.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/hotplug-cpu: increase wait time for vCPU death
From: Michael Ellerman @ 2020-08-11 11:56 UTC (permalink / raw)
To: Michael Roth, Nathan Lynch
Cc: linuxppc-dev, Greg Kurz, Thiago Jung Bauermann, Cedric Le Goater
In-Reply-To: <159712434106.7191.15165087672426328577@sif>
Michael Roth <mdroth@linux.vnet.ibm.com> writes:
> Quoting Nathan Lynch (2020-08-07 02:05:09)
...
>> wait_for_cpu_stopped() should be able to accommodate a time-based
>> warning if necessary, but speaking as a likely recipient of any bug
>> reports that would arise here, I'm not convinced of the need and I
>> don't know what a good value would be. It's relatively easy to sample
>> the stack of a task that's apparently failing to make progress, plus I
>> probably would use 'perf probe' or similar to report the inputs and
>> outputs for the RTAS call.
>
> I think if we make the timeout sufficiently high like 2 minutes or so
> it wouldn't hurt and if we did seem them it would probably point to an
> actual bug. But I don't have a strong feeling either way.
I think we should print a warning after 2 minutes.
It's true that there are fairly easy mechanisms to work out where the
thread is stuck, but customers are unlikely to use them. They're just
going to report that it's stuck with no further info, and probably
reboot the machine before we get a chance to get any further info.
Whereas if the kernel prints a warning with a stack trace we at least
have that to go on in an initial bug report.
>> I'm happy to make this a proper submission after I can clean it up and
>> retest it, or Michael R. is welcome to appropriate it, assuming it's
>> acceptable.
>>
>
> I've given it a shot with this patch and it seems to be holding up in
> testing. If we don't think the ~2 minutes warning message is needed I
> can clean it up to post:
>
> https://github.com/mdroth/linux/commit/354b8c97bf0dc1146e36aa72273f5b33fe90d09e
>
> I'd likely break the refactoring patches out to a separate patch under
> Nathan's name since it fixes a separate bug potentially.
While I like Nathan's refactoring, we probably want to do the minimal
fix first to ease backporting.
Then do the refactoring on top of that.
cheers
^ permalink raw reply
* Re: [RFC PATCH v1] power: don't manage floating point regs when no FPU
From: Michael Ellerman @ 2020-08-11 12:07 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <95c00a811897f6d9176d30bf2ac92dab8c9c8e95.1596816789.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> There is no point in copying floating point regs when there
> is no FPU and MATH_EMULATION is not selected.
Yeah I guess you're right. I've never touched a system with neither, but
if such a thing exists then it does seem silly to copy regs around that
can't be used.
> Create a new CONFIG_PPC_FPU_REGS bool that is selected by
> CONFIG_MATH_EMULATION and CONFIG_PPC_FPU, and use it to
> opt out everything related to fp_state in thread_struct.
>
> The following app runs in approx 10.50 seconds on an 8xx without
> the patch, and in 9.45 seconds with the patch.
>
> void sigusr1(int sig) { }
>
> int main(int argc, char **argv)
> {
> int i = 100000;
>
> signal(SIGUSR1, sigusr1);
> for (;i--;)
> raise(SIGUSR1);
> exit(0);
> }
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/processor.h | 2 ++
> arch/powerpc/kernel/asm-offsets.c | 2 ++
> arch/powerpc/kernel/process.c | 4 ++++
> arch/powerpc/kernel/ptrace/ptrace-novsx.c | 8 ++++++++
> arch/powerpc/kernel/ptrace/ptrace.c | 4 ++++
> arch/powerpc/kernel/signal.c | 12 +++++++++++-
> arch/powerpc/kernel/signal_32.c | 4 ++++
> arch/powerpc/kernel/traps.c | 4 ++++
> arch/powerpc/platforms/Kconfig.cputype | 4 ++++
> 10 files changed, 44 insertions(+), 1 deletion(-)
In general this looks fine.
It's a bit #ifdef heavy. Maybe some of those can be cleaned up a bit
with some wrapper inlines?
> diff --git a/arch/powerpc/kernel/ptrace/ptrace-novsx.c b/arch/powerpc/kernel/ptrace/ptrace-novsx.c
> index b2dc4e92d11a..8f87a11f3f8c 100644
> --- a/arch/powerpc/kernel/ptrace/ptrace-novsx.c
> +++ b/arch/powerpc/kernel/ptrace/ptrace-novsx.c
> @@ -28,6 +29,9 @@ int fpr_get(struct task_struct *target, const struct user_regset *regset,
>
> return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
> &target->thread.fp_state, 0, -1);
> +#else
> + return 0;
> +#endif
Should we return -ENODEV/EIO here? Wonder if another arch can give us a clue.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne X1000)
From: Michael Ellerman @ 2020-08-11 12:31 UTC (permalink / raw)
To: mpe, linuxppc-dev, Aneesh Kumar K.V; +Cc: Christian Zigotzky
In-Reply-To: <20200810102623.685083-1-aneesh.kumar@linux.ibm.com>
On Mon, 10 Aug 2020 15:56:23 +0530, Aneesh Kumar K.V wrote:
> On p6 and before we should avoid updating UAMOR SPRN. This resulted
> in boot failure on Nemo board.
Applied to powerpc/fixes.
[1/1] powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne X1000)
https://git.kernel.org/powerpc/c/6553fb799f601497ca0703682e2aff131197dc5c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/rtas: Restrict RTAS requests from userspace
From: Daniel Axtens @ 2020-08-11 13:41 UTC (permalink / raw)
To: Andrew Donnellan, Michael Ellerman, linuxppc-dev; +Cc: nathanl, leobras.c
In-Reply-To: <1ff85ddd-1b75-f49d-0ae2-edf9e5a199e2@linux.ibm.com>
Andrew Donnellan <ajd@linux.ibm.com> writes:
> On 10/8/20 4:40 pm, Michael Ellerman wrote:
>> Hi ajd,
>>
>> Thanks for taking care of this.
>>
>> I was going to merge this as-is, but given it's fixing a long standing
>> issue there's not really a big rush. So a few comments below.
>
> Thanks for the review.
>
>>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
>>> index a09eba03f180..ec1cae52d8bd 100644
>>> --- a/arch/powerpc/kernel/rtas.c
>>> +++ b/arch/powerpc/kernel/rtas.c
>>> @@ -324,6 +324,23 @@ int rtas_token(const char *service)
>>> }
>>> EXPORT_SYMBOL(rtas_token);
>>>
>>> +#ifdef CONFIG_PPC_RTAS_FILTER
>>> +
>>
>> I think this could be combined with the #ifdef block below?
>
> I put it here to keep it next to rtas_token() as it seemed thematically
> appropriate. Anyway per below I'll probably get rid of this function
> altogether.
>
>>
>>> +static char *rtas_token_name(int token)
>>> +{
>>> + struct property *prop;
>>> +
>>> + for_each_property_of_node(rtas.dev, prop) {
>>> + const __be32 *tokp = prop->value;
>>> +
>>> + if (tokp && be32_to_cpu(*tokp) == token)
>>> + return prop->name;
>>> + }
>>> + return NULL;
>>> +}
>>> +
>>> +#endif /* CONFIG_PPC_RTAS_FILTER */
>>> +
>>> int rtas_service_present(const char *service)
>>> {
>>> return rtas_token(service) != RTAS_UNKNOWN_SERVICE;
>>> @@ -1110,6 +1127,184 @@ struct pseries_errorlog *get_pseries_errorlog(struct rtas_error_log *log,
>>> return NULL;
>>> }
>>>
>>> +#ifdef CONFIG_PPC_RTAS_FILTER
>>> +
>>> +/*
>>> + * The sys_rtas syscall, as originally designed, allows root to pass
>>> + * arbitrary physical addresses to RTAS calls. A number of RTAS calls
>>> + * can be abused to write to arbitrary memory and do other things that
>>> + * are potentially harmful to system integrity, and thus should only
>>> + * be used inside the kernel and not exposed to userspace.
>>> + *
>>> + * All known legitimate users of the sys_rtas syscall will only ever
>>> + * pass addresses that fall within the RMO buffer, and use a known
>>> + * subset of RTAS calls.
>>> + *
>>> + * Accordingly, we filter RTAS requests to check that the call is
>>> + * permitted, and that provided pointers fall within the RMO buffer.
>>> + * The rtas_filters list contains an entry for each permitted call,
>>> + * with the indexes of the parameters which are expected to contain
>>> + * addresses and sizes of buffers allocated inside the RMO buffer.
>>> + */
>>> +struct rtas_filter {
>>> + const char name[32];
>>
>> Using a const char * for the name would be more typical, meaning the
>> strings would end up in .rodata, and could be merged with other uses of
>> the same strings.
>
> Will fix
>
>>
>>> +
>>> + /* Indexes into the args buffer, -1 if not used */
>>> + int rmo_buf_idx1;
>>> + int rmo_size_idx1;
>>> + int rmo_buf_idx2;
>>> + int rmo_size_idx2;
>>
>> The "rmo" prefix is probably unnecessary?
>>
>
> Ack
>
>>> +};
>>> +
>>> +struct rtas_filter rtas_filters[] = {
>>
>> Should be static, and __ro_after_init ?
>>
>>> + { "ibm,activate-firmware", -1, -1, -1, -1 },
>>
>> Would it be worth making the indices 1-based, allowing 0 to be the
>> unused value, meaning you only have to initialise the used fields?
>
> 1-based array indices are morally reprehensible. It would make it
> cleaner but I kind of prefer an obvious and clear constant for unused, idk
>
>> It would require adjusting them before use, but there's only 4 places
>> they're used, and you could probably use a macro to do the - 1.
>>
>>> + { "ibm,configure-connector", 0, -1, 1, -1 }, /* Special cased, size 4096 */
>>
>> Does it make sense to put the hard coded sizes in the structure as well?
>>
>> eg. fixed_size1 = 4096,
>>
>> I think that would avoid the need for any strcmps in the code.
>
> Not quite - we still have a special case for ibm,configure-connector
> passing a base address of 0.
>
> But yes that's a good idea.
>
>>
>>> + { "display-character", -1, -1, -1, -1 },
>>> + { "ibm,display-message", 0, -1, -1, -1 },
>>> + { "ibm,errinjct", 2, -1, -1, -1 }, /* Fixed size of 1024 */
>>> + { "ibm,close-errinjct", -1, -1, -1, -1 },
>>> + { "ibm,open-errinct", -1, -1, -1, -1 },
>>> + { "ibm,get-config-addr-info2", -1, -1, -1, -1 },
>>> + { "ibm,get-dynamic-sensor-state", 1, -1, -1, -1 },
>>> + { "ibm,get-indices", 2, 3, -1, -1 },
>>> + { "get-power-level", -1, -1, -1, -1 },
>>> + { "get-sensor-state", -1, -1, -1, -1 },
>>> + { "ibm,get-system-parameter", 1, 2, -1, -1 },
>>> + { "get-time-of-day", -1, -1, -1, -1 },
>>> + { "ibm,get-vpd", 0, -1, 1, 2 },
>>> + { "ibm,lpar-perftools", 2, 3, -1, -1 },
>>> + { "ibm,platform-dump", 4, 5, -1, -1 },
>>> + { "ibm,read-slot-reset-state", -1, -1, -1, -1 },
>>> + { "ibm,scan-log-dump", 0, 1, -1, -1 },
>>> + { "ibm,set-dynamic-indicator", 2, -1, -1, -1 },
>>> + { "ibm,set-eeh-option", -1, -1, -1, -1 },
>>> + { "set-indicator", -1, -1, -1, -1 },
>>> + { "set-power-level", -1, -1, -1, -1 },
>>> + { "set-time-for-power-on", -1, -1, -1, -1 },
>>> + { "ibm,set-system-parameter", 1, -1, -1, -1 },
>>> + { "set-time-of-day", -1, -1, -1, -1 },
>>> + { "ibm,suspend-me", -1, -1, -1, -1 },
>>> + { "ibm,update-nodes", 0, -1, -1, -1 }, /* Fixed size of 4096 */
>>> + { "ibm,update-properties", 0, -1, -1, -1 }, /* Fixed size of 4096 */
>>> + { "ibm,physical-attestation", 0, 1, -1, -1 },
>>> +};
>>> +
>>> +static void dump_rtas_params(int token, int nargs, int nret,
>>> + struct rtas_args *args)
>>> +{
>>> + int i;
>>> + char *token_name = rtas_token_name(token);
>>> +
>>> + pr_err_ratelimited("sys_rtas: token=0x%x (%s), nargs=%d, nret=%d (called by %s)\n",
>>> + token, token_name ? token_name : "unknown", nargs,
>>> + nret, current->comm);
>>> + pr_err_ratelimited("sys_rtas: args: ");
>>> +
>>> + for (i = 0; i < nargs; i++) {
>>> + u32 arg = be32_to_cpu(args->args[i]);
>>> +
>>> + pr_cont("%08x ", arg);
>>> + if (arg >= rtas_rmo_buf &&
>>> + arg < (rtas_rmo_buf + RTAS_RMOBUF_MAX))
>>> + pr_cont("(buf+0x%lx) ", arg - rtas_rmo_buf);
>>> + }
>>
>> This can leak the location of the RMO buf into dmesg. I know it's
>> visible via /proc, but the /proc file is 0400.
>>
>> So I think it's probably safer if we just don't dump the args, or their
>> relation to the RMO buf.
>
> Good point, removed.
>
>>
>>> +
>>> + pr_cont("\n");
>>> +}
>>> +
>>> +static bool in_rmo_buf(u32 base, u32 end)
>>> +{
>>> + return base >= rtas_rmo_buf &&
>>> + base < (rtas_rmo_buf + RTAS_RMOBUF_MAX) &&
>>> + base <= end &&
>>> + end >= rtas_rmo_buf &&
>>> + end < (rtas_rmo_buf + RTAS_RMOBUF_MAX);
>>> +}
>>> +
>>> +static bool block_rtas_call(int token, int nargs,
>>> + struct rtas_args *args)
>>> +{
>>> + int i;
>>> + const char *reason;
>>> + char *token_name = rtas_token_name(token);
>>
>> This code isn't particularly performance critical, but I think it would
>> be cleaner to do the token lookup once at init time, and store the token
>> in the filter array?
>>
>> Then this code would only be doing token comparisons.
>
> Yeah that would be cleaner, can get rid of rtas_token_name().
I'm not sure I quite understand what you're suggesting.
You still need to do a string->token lookup at least once as the tokens
differ between PowerVM and qemu. Are you saying that you can fold the
token name lookup into the init function?
Kind regards,
Daniel
>>
>>> +
>>> + if (!token_name)
>>> + goto err_notpermitted;
>>> +
>>> + for (i = 0; i < ARRAY_SIZE(rtas_filters); i++) {
>>> + struct rtas_filter *f = &rtas_filters[i];
>>> + u32 base, size, end;
>>> +
>>> + if (strcmp(token_name, f->name))
>>> + continue;
>>> +
>>> + if (f->rmo_buf_idx1 != -1) {
>>> + base = be32_to_cpu(args->args[f->rmo_buf_idx1]);
>>> + if (f->rmo_size_idx1 != -1)
>>> + size = be32_to_cpu(args->args[f->rmo_size_idx1]);
>>> + else if (!strcmp(token_name, "ibm,errinjct"))
>>> + size = 1024;
>>> + else if (!strcmp(token_name, "ibm,update-nodes") ||
>>> + !strcmp(token_name, "ibm,update-properties") ||
>>> + !strcmp(token_name, "ibm,configure-connector"))
>>> + size = 4096;
>>> + else
>>> + size = 1;
>>> +
>>> + end = base + size - 1;
>>> + if (!in_rmo_buf(base, end)) {
>>> + reason = "address pair 1 out of range";
>>
>> I don't think we need to give the user this much detail about what they
>> did wrong, all cases can just print "call not permitted" IMO.
>
> Ack
>
> --
> Andrew Donnellan OzLabs, ADL Canberra
> ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [RFC PATCH v1] power: don't manage floating point regs when no FPU
From: Christophe Leroy @ 2020-08-11 13:48 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87o8nh9yjd.fsf@mpe.ellerman.id.au>
Le 11/08/2020 à 14:07, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> There is no point in copying floating point regs when there
>> is no FPU and MATH_EMULATION is not selected.
>
> Yeah I guess you're right. I've never touched a system with neither, but
> if such a thing exists then it does seem silly to copy regs around that
> can't be used.
Yes that exists, because glibc implements floating point emulation and
it is definitely more efficient to rely of glibc emulation than kernel one.
>> 10 files changed, 44 insertions(+), 1 deletion(-)
>
> In general this looks fine.
>
> It's a bit #ifdef heavy. Maybe some of those can be cleaned up a bit
> with some wrapper inlines?
>
Yes I'll try and respin, as part of a series I'm preparing to switch the
32 bits signal code to using user_access_begin() logic and
unsafe_put_user() and friends to reduce KUAP unlock/lock.
Christophe
^ permalink raw reply
* [PATCH 0/7] powerpc: unrel_branch_check.sh: make it suck less
From: Stephen Rothwell @ 2020-08-11 14:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux PowerPC List, Nicholas Piggin
Michael Ellerman: "who wants to make
arch/powerpc/tools/unrel_branch_check.sh suck less"
This series is based off the current powerpc/next branch and keeps the
same functionaity as the original except that it suppresses some error
messages for early failures that still cause this script to succeed
(as it always did).
I did this as a series so that people can see the (mostly obvious)
transofrmations at each step. As a single patch, it basically replaces
the whole file.
Hopefully this fulfills your definition of "sucks less" :-)
arch/powerpc/tools/unrel_branch_check.sh | 88 ++++++++++++++++----------------
1 file changed, 43 insertions(+), 45 deletions(-)
Cc: Nicholas Piggin <npiggin@gmail.com>
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH 1/7] powerpc: unrel_branch_check.sh: fix shellcheck complaints
From: Stephen Rothwell @ 2020-08-11 14:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux PowerPC List, Nicholas Piggin
In-Reply-To: <20200811140435.20957-1-sfr@canb.auug.org.au>
No functional change
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/tools/unrel_branch_check.sh | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/tools/unrel_branch_check.sh b/arch/powerpc/tools/unrel_branch_check.sh
index 6e6a30aea3ed..4c1e04ba5081 100755
--- a/arch/powerpc/tools/unrel_branch_check.sh
+++ b/arch/powerpc/tools/unrel_branch_check.sh
@@ -1,3 +1,4 @@
+#!/bin/bash
# Copyright © 2016 IBM Corporation
#
# This program is free software; you can redistribute it and/or
@@ -26,7 +27,7 @@ awk '{print $1}'
BRANCHES=$(
$objdump -R "$vmlinux" -D --start-address=0xc000000000000000 \
- --stop-address=${end_intr} |
+ --stop-address="$end_intr" |
grep -e "^c[0-9a-f]*:[[:space:]]*\([0-9a-f][0-9a-f][[:space:]]\)\{4\}[[:space:]]*b" |
grep -v '\<__start_initialization_multiplatform>' |
grep -v -e 'b.\?.\?ctr' |
@@ -40,12 +41,12 @@ awk '{ print $1 ":" $6 ":0x" $7 ":" $8 " "}'
for tuple in $BRANCHES
do
- from=`echo $tuple | cut -d':' -f1`
- branch=`echo $tuple | cut -d':' -f2`
- to=`echo $tuple | cut -d':' -f3 | sed 's/cr[0-7],//'`
- sym=`echo $tuple | cut -d':' -f4`
+ from=$(echo "$tuple" | cut -d':' -f1)
+ branch=$(echo "$tuple" | cut -d':' -f2)
+ to=$(echo "$tuple" | cut -d':' -f3 | sed 's/cr[0-7],//')
+ sym=$(echo "$tuple" | cut -d':' -f4)
- if (( $to > $end_intr ))
+ if (( to > end_intr ))
then
if [ -z "$bad_branches" ]; then
echo "WARNING: Unrelocated relative branches"
--
2.28.0
^ permalink raw reply related
* [PATCH 2/7] powerpc: unrel_branch_check.sh: simplify and combine some executions
From: Stephen Rothwell @ 2020-08-11 14:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux PowerPC List, Nicholas Piggin
In-Reply-To: <20200811140435.20957-1-sfr@canb.auug.org.au>
Also some minor style changes.
There should still be no change in behaviour.
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/tools/unrel_branch_check.sh | 25 +++++++++++-------------
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/tools/unrel_branch_check.sh b/arch/powerpc/tools/unrel_branch_check.sh
index 4c1e04ba5081..d735e3875b5e 100755
--- a/arch/powerpc/tools/unrel_branch_check.sh
+++ b/arch/powerpc/tools/unrel_branch_check.sh
@@ -17,37 +17,34 @@ objdump="$1"
vmlinux="$2"
#__end_interrupts should be located within the first 64K
+kstart=0xc000000000000000
+printf -v kend '0x%x' $(( kstart + 0x10000 ))
end_intr=0x$(
-$objdump -R "$vmlinux" -d --start-address=0xc000000000000000 \
- --stop-address=0xc000000000010000 |
-grep '\<__end_interrupts>:' |
-awk '{print $1}'
+$objdump -R -d --start-address="$kstart" --stop-address="$kend" "$vmlinux" |
+awk '$2 == "<__end_interrupts>:" { print $1 }'
)
BRANCHES=$(
-$objdump -R "$vmlinux" -D --start-address=0xc000000000000000 \
- --stop-address="$end_intr" |
+$objdump -R -D --start-address="$kstart" --stop-address="$end_intr" "$vmlinux" |
grep -e "^c[0-9a-f]*:[[:space:]]*\([0-9a-f][0-9a-f][[:space:]]\)\{4\}[[:space:]]*b" |
-grep -v '\<__start_initialization_multiplatform>' |
-grep -v -e 'b.\?.\?ctr' |
-grep -v -e 'b.\?.\?lr' |
-sed -e 's/\bbt.\?[[:space:]]*[[:digit:]][[:digit:]]*,/beq/' \
+sed -e '/\<__start_initialization_multiplatform>/d' \
+ -e '/b.\?.\?ctr/d' \
+ -e '/b.\?.\?lr/d' \
+ -e 's/\bbt.\?[[:space:]]*[[:digit:]][[:digit:]]*,/beq/' \
-e 's/\bbf.\?[[:space:]]*[[:digit:]][[:digit:]]*,/bne/' \
-e 's/[[:space:]]0x/ /' \
-e 's/://' |
awk '{ print $1 ":" $6 ":0x" $7 ":" $8 " "}'
)
-for tuple in $BRANCHES
-do
+for tuple in $BRANCHES; do
from=$(echo "$tuple" | cut -d':' -f1)
branch=$(echo "$tuple" | cut -d':' -f2)
to=$(echo "$tuple" | cut -d':' -f3 | sed 's/cr[0-7],//')
sym=$(echo "$tuple" | cut -d':' -f4)
- if (( to > end_intr ))
- then
+ if (( to > end_intr )); then
if [ -z "$bad_branches" ]; then
echo "WARNING: Unrelocated relative branches"
bad_branches="yes"
--
2.28.0
^ permalink raw reply related
* [PATCH 3/7] powerpc: unrel_branch_check.sh: simplify objdump's asm output
From: Stephen Rothwell @ 2020-08-11 14:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux PowerPC List, Nicholas Piggin
In-Reply-To: <20200811140435.20957-1-sfr@canb.auug.org.au>
We don't use the raw hex instruction dump, so elide it and adjust the
following expressions.
Also use \s instead of [[:space:]] everywhere.
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/tools/unrel_branch_check.sh | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/tools/unrel_branch_check.sh b/arch/powerpc/tools/unrel_branch_check.sh
index d735e3875b5e..7e936e2cf70d 100755
--- a/arch/powerpc/tools/unrel_branch_check.sh
+++ b/arch/powerpc/tools/unrel_branch_check.sh
@@ -26,16 +26,16 @@ awk '$2 == "<__end_interrupts>:" { print $1 }'
)
BRANCHES=$(
-$objdump -R -D --start-address="$kstart" --stop-address="$end_intr" "$vmlinux" |
-grep -e "^c[0-9a-f]*:[[:space:]]*\([0-9a-f][0-9a-f][[:space:]]\)\{4\}[[:space:]]*b" |
+$objdump -R -D --no-show-raw-insn --start-address="$kstart" --stop-address="$end_intr" "$vmlinux" |
+grep -e "^c[0-9a-f]*:\s*b" |
sed -e '/\<__start_initialization_multiplatform>/d' \
-e '/b.\?.\?ctr/d' \
-e '/b.\?.\?lr/d' \
- -e 's/\bbt.\?[[:space:]]*[[:digit:]][[:digit:]]*,/beq/' \
- -e 's/\bbf.\?[[:space:]]*[[:digit:]][[:digit:]]*,/bne/' \
- -e 's/[[:space:]]0x/ /' \
+ -e 's/\bbt.\?\s*[[:digit:]][[:digit:]]*,/beq/' \
+ -e 's/\bbf.\?\s*[[:digit:]][[:digit:]]*,/bne/' \
+ -e 's/\s0x/ /' \
-e 's/://' |
-awk '{ print $1 ":" $6 ":0x" $7 ":" $8 " "}'
+awk '{ print $1 ":" $2 ":0x" $3 ":" $4 " "}'
)
for tuple in $BRANCHES; do
--
2.28.0
^ permalink raw reply related
* [PATCH 4/7] powerpc: unrel_branch_check.sh: convert grep | sed | awk to just sed
From: Stephen Rothwell @ 2020-08-11 14:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux PowerPC List, Nicholas Piggin
In-Reply-To: <20200811140435.20957-1-sfr@canb.auug.org.au>
Also start using sed -E and make all the separate expressions into a
single one with comments. Pull the stripping of condition registers
back into the sed command.
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/tools/unrel_branch_check.sh | 30 ++++++++++++++++--------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/tools/unrel_branch_check.sh b/arch/powerpc/tools/unrel_branch_check.sh
index 7e936e2cf70d..dc82289b2252 100755
--- a/arch/powerpc/tools/unrel_branch_check.sh
+++ b/arch/powerpc/tools/unrel_branch_check.sh
@@ -27,21 +27,31 @@ awk '$2 == "<__end_interrupts>:" { print $1 }'
BRANCHES=$(
$objdump -R -D --no-show-raw-insn --start-address="$kstart" --stop-address="$end_intr" "$vmlinux" |
-grep -e "^c[0-9a-f]*:\s*b" |
-sed -e '/\<__start_initialization_multiplatform>/d' \
- -e '/b.\?.\?ctr/d' \
- -e '/b.\?.\?lr/d' \
- -e 's/\bbt.\?\s*[[:digit:]][[:digit:]]*,/beq/' \
- -e 's/\bbf.\?\s*[[:digit:]][[:digit:]]*,/bne/' \
- -e 's/\s0x/ /' \
- -e 's/://' |
-awk '{ print $1 ":" $2 ":0x" $3 ":" $4 " "}'
+sed -E -n '
+# match lines that start with a kernel address
+/^c[0-9a-f]*:\s*b/ {
+ # drop a target that we do not care about
+ /\<__start_initialization_multiplatform>/d
+ # drop branches via ctr or lr
+ /\<b.?.?(ct|l)r/d
+ # cope with some differences between Clang and GNU objdumps
+ s/\<bt.?\s*[[:digit:]]+,/beq/
+ s/\<bf.?\s*[[:digit:]]+,/bne/
+ # tidy up
+ s/\s0x/ /
+ s/://
+ # format for the loop below
+ s/^(\S+)\s+(\S+)\s+(\S+)\s*(\S*).*$/\1:\2:0x\3:\4/
+ # strip out condition registers
+ s/:0xcr[0-7],/:0x/
+ p
+}'
)
for tuple in $BRANCHES; do
from=$(echo "$tuple" | cut -d':' -f1)
branch=$(echo "$tuple" | cut -d':' -f2)
- to=$(echo "$tuple" | cut -d':' -f3 | sed 's/cr[0-7],//')
+ to=$(echo "$tuple" | cut -d':' -f3)
sym=$(echo "$tuple" | cut -d':' -f4)
if (( to > end_intr )); then
--
2.28.0
^ permalink raw reply related
* [PATCH 5/7] powerpc: unrel_branch_check.sh: simplify and tidy up the final loop
From: Stephen Rothwell @ 2020-08-11 14:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux PowerPC List, Nicholas Piggin
In-Reply-To: <20200811140435.20957-1-sfr@canb.auug.org.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/tools/unrel_branch_check.sh | 26 +++++++++---------------
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/tools/unrel_branch_check.sh b/arch/powerpc/tools/unrel_branch_check.sh
index dc82289b2252..54ebd05615d4 100755
--- a/arch/powerpc/tools/unrel_branch_check.sh
+++ b/arch/powerpc/tools/unrel_branch_check.sh
@@ -25,7 +25,6 @@ $objdump -R -d --start-address="$kstart" --stop-address="$kend" "$vmlinux" |
awk '$2 == "<__end_interrupts>:" { print $1 }'
)
-BRANCHES=$(
$objdump -R -D --no-show-raw-insn --start-address="$kstart" --stop-address="$end_intr" "$vmlinux" |
sed -E -n '
# match lines that start with a kernel address
@@ -45,24 +44,19 @@ sed -E -n '
# strip out condition registers
s/:0xcr[0-7],/:0x/
p
-}'
-)
-
-for tuple in $BRANCHES; do
- from=$(echo "$tuple" | cut -d':' -f1)
- branch=$(echo "$tuple" | cut -d':' -f2)
- to=$(echo "$tuple" | cut -d':' -f3)
- sym=$(echo "$tuple" | cut -d':' -f4)
+}' | {
+all_good=true
+while IFS=: read -r from branch to sym; do
if (( to > end_intr )); then
- if [ -z "$bad_branches" ]; then
- echo "WARNING: Unrelocated relative branches"
- bad_branches="yes"
+ if $all_good; then
+ printf '%s\n' 'WARNING: Unrelocated relative branches'
+ all_good=false
fi
- echo "$from $branch-> $to $sym"
+ printf '%s %s-> %s %s\n' "$from" "$branch" "$to" "$sym"
fi
done
-if [ -z "$bad_branches" ]; then
- exit 0
-fi
+$all_good
+
+}
--
2.28.0
^ permalink raw reply related
* [PATCH 6/7] powerpc: unrel_branch_check.sh: fix up the file header
From: Stephen Rothwell @ 2020-08-11 14:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux PowerPC List, Nicholas Piggin
In-Reply-To: <20200811140435.20957-1-sfr@canb.auug.org.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/tools/unrel_branch_check.sh | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/tools/unrel_branch_check.sh b/arch/powerpc/tools/unrel_branch_check.sh
index 54ebd05615d4..4489f16a443c 100755
--- a/arch/powerpc/tools/unrel_branch_check.sh
+++ b/arch/powerpc/tools/unrel_branch_check.sh
@@ -1,16 +1,9 @@
#!/bin/bash
-# Copyright © 2016 IBM Corporation
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright © 2016,2020 IBM Corporation
#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version
-# 2 of the License, or (at your option) any later version.
-#
-# This script checks the relocations of a vmlinux for "suspicious"
-# branches from unrelocated code (head_64.S code).
-
-# Turn this on if you want more debug output:
-# set -x
+# This script checks the unrelocated code of a vmlinux for "suspicious"
+# branches to relocated code (head_64.S code).
# Have Kbuild supply the path to objdump so we handle cross compilation.
objdump="$1"
--
2.28.0
^ permalink raw reply related
* [PATCH 7/7] powerpc: unrel_branch_check.sh: exit silently for early errors
From: Stephen Rothwell @ 2020-08-11 14:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux PowerPC List, Nicholas Piggin
In-Reply-To: <20200811140435.20957-1-sfr@canb.auug.org.au>
If we can't find the address of __end_interrupts, then we still exit
successfully as that is the current behaviour.
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/tools/unrel_branch_check.sh | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/tools/unrel_branch_check.sh b/arch/powerpc/tools/unrel_branch_check.sh
index 4489f16a443c..70da90270c78 100755
--- a/arch/powerpc/tools/unrel_branch_check.sh
+++ b/arch/powerpc/tools/unrel_branch_check.sh
@@ -14,9 +14,12 @@ kstart=0xc000000000000000
printf -v kend '0x%x' $(( kstart + 0x10000 ))
end_intr=0x$(
-$objdump -R -d --start-address="$kstart" --stop-address="$kend" "$vmlinux" |
+$objdump -R -d --start-address="$kstart" --stop-address="$kend" "$vmlinux" 2>/dev/null |
awk '$2 == "<__end_interrupts>:" { print $1 }'
)
+if [ "$end_intr" = "0x" ]; then
+ exit 0
+fi
$objdump -R -D --no-show-raw-insn --start-address="$kstart" --stop-address="$end_intr" "$vmlinux" |
sed -E -n '
--
2.28.0
^ permalink raw reply related
* Re: [RFC PATCH v1] power: don't manage floating point regs when no FPU
From: Christophe Leroy @ 2020-08-11 14:06 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87o8nh9yjd.fsf@mpe.ellerman.id.au>
Le 11/08/2020 à 14:07, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> 10 files changed, 44 insertions(+), 1 deletion(-)
>
> In general this looks fine.
>
> It's a bit #ifdef heavy. Maybe some of those can be cleaned up a bit
> with some wrapper inlines?
Looking at it once more, looks like more or less the same level of
#ifdefs as things like CONFIG_ALTIVEC for instance. I can't really see
much opportunities to clean it up.
>
>> diff --git a/arch/powerpc/kernel/ptrace/ptrace-novsx.c b/arch/powerpc/kernel/ptrace/ptrace-novsx.c
>> index b2dc4e92d11a..8f87a11f3f8c 100644
>> --- a/arch/powerpc/kernel/ptrace/ptrace-novsx.c
>> +++ b/arch/powerpc/kernel/ptrace/ptrace-novsx.c
>> @@ -28,6 +29,9 @@ int fpr_get(struct task_struct *target, const struct user_regset *regset,
>>
>> return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
>> &target->thread.fp_state, 0, -1);
>> +#else
>> + return 0;
>> +#endif
>
> Should we return -ENODEV/EIO here? Wonder if another arch can give us a clue.
>
Looks like we have to do another way ... another #ifdef ... in the
definition of native_regsets[] in ptrace-view.c . And then we should be
able to not build ptrace-novsx.c at all. Will try that.
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/hotplug-cpu: increase wait time for vCPU death
From: Nathan Lynch @ 2020-08-11 14:46 UTC (permalink / raw)
To: Michael Ellerman, Michael Roth
Cc: linuxppc-dev, Greg Kurz, Thiago Jung Bauermann, Cedric Le Goater
In-Reply-To: <87r1sd9z0d.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Michael Roth <mdroth@linux.vnet.ibm.com> writes:
>> Quoting Nathan Lynch (2020-08-07 02:05:09)
> ...
>>> wait_for_cpu_stopped() should be able to accommodate a time-based
>>> warning if necessary, but speaking as a likely recipient of any bug
>>> reports that would arise here, I'm not convinced of the need and I
>>> don't know what a good value would be. It's relatively easy to sample
>>> the stack of a task that's apparently failing to make progress, plus I
>>> probably would use 'perf probe' or similar to report the inputs and
>>> outputs for the RTAS call.
>>
>> I think if we make the timeout sufficiently high like 2 minutes or so
>> it wouldn't hurt and if we did seem them it would probably point to an
>> actual bug. But I don't have a strong feeling either way.
>
> I think we should print a warning after 2 minutes.
>
> It's true that there are fairly easy mechanisms to work out where the
> thread is stuck, but customers are unlikely to use them. They're just
> going to report that it's stuck with no further info, and probably
> reboot the machine before we get a chance to get any further info.
>
> Whereas if the kernel prints a warning with a stack trace we at least
> have that to go on in an initial bug report.
>
>>> I'm happy to make this a proper submission after I can clean it up and
>>> retest it, or Michael R. is welcome to appropriate it, assuming it's
>>> acceptable.
>>>
>>
>> I've given it a shot with this patch and it seems to be holding up in
>> testing. If we don't think the ~2 minutes warning message is needed I
>> can clean it up to post:
>>
>> https://github.com/mdroth/linux/commit/354b8c97bf0dc1146e36aa72273f5b33fe90d09e
>>
>> I'd likely break the refactoring patches out to a separate patch under
>> Nathan's name since it fixes a separate bug potentially.
>
> While I like Nathan's refactoring, we probably want to do the minimal
> fix first to ease backporting.
>
> Then do the refactoring on top of that.
Fair enough, thanks.
^ permalink raw reply
* Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
From: Horia Geantă @ 2020-08-11 15:28 UTC (permalink / raw)
To: Eric Biggers
Cc: Andrei Botila (OSS), Andrei Botila, Herbert Xu,
Van Leeuwen, Pascal, Antoine Tenart, linux-s390@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@axis.com, linux-crypto@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200810170305.GA3352718@gmail.com>
On 8/10/2020 8:03 PM, Eric Biggers wrote:
> On Mon, Aug 10, 2020 at 05:33:39PM +0300, Horia Geantă wrote:
>> On 8/10/2020 4:45 PM, Herbert Xu wrote:
>>> On Mon, Aug 10, 2020 at 10:20:20AM +0000, Van Leeuwen, Pascal wrote:
>>>>
>>>> With all due respect, but this makes no sense.
>>>
>>> I agree. This is a lot of churn for no gain.
>>>
>> I would say the gain is that all skcipher algorithms would behave the same
>> when input length equals zero - i.e. treat the request as a no-op.
>>
>> We can't say "no input" has any meaning to the other skcipher algorithms,
>> but the convention is to accept this case and just return 0.
>> I don't see why XTS has to be handled differently.
>>
>
> CTS also rejects empty inputs.
>
> The rule it follows is just that all input lengths >= blocksize are allowed.
> Input lengths < blocksize aren't allowed.
>
Indeed, thanks.
What about, for example, CBC?
AFAICT cbc(aes) with input length = 0 is valid.
Same for CTR (with the note that blocksize = 1) and several other algorithms
mentioned in the cover letter.
What's the rule in these cases?
Thanks,
Horia
^ permalink raw reply
* [PATCH v2] powerpc/pseries/hotplug-cpu: wait indefinitely for vCPU death
From: Michael Roth @ 2020-08-11 16:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: Nathan Lynch, Cedric Le Goater, Thiago Jung Bauermann, Greg Kurz
For a power9 KVM guest with XIVE enabled, running a test loop
where we hotplug 384 vcpus and then unplug them, the following traces
can be seen (generally within a few loops) either from the unplugged
vcpu:
[ 1767.353447] cpu 65 (hwid 65) Ready to die...
[ 1767.952096] Querying DEAD? cpu 66 (66) shows 2
[ 1767.952311] list_del corruption. next->prev should be c00a000002470208, but was c00a000002470048
[ 1767.952322] ------------[ cut here ]------------
[ 1767.952323] kernel BUG at lib/list_debug.c:56!
[ 1767.952325] Oops: Exception in kernel mode, sig: 5 [#1]
[ 1767.952326] LE SMP NR_CPUS=2048 NUMA pSeries
[ 1767.952328] Modules linked in: fuse nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat_ipv6 nf_nat_ipv6 nft_chain_route_ipv6 nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_chain_route_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink uio_pdrv_genirq ip_tables xfs libcrc32c sd_mod sg xts vmx_crypto virtio_net net_failover failover virtio_scsi dm_multipath dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
[ 1767.952352] CPU: 66 PID: 0 Comm: swapper/66 Kdump: loaded Not tainted 4.18.0-221.el8.ppc64le #1
[ 1767.952354] NIP: c0000000007ab50c LR: c0000000007ab508 CTR: 00000000000003ac
[ 1767.952355] REGS: c0000009e5a17840 TRAP: 0700 Not tainted (4.18.0-221.el8.ppc64le)
[ 1767.952355] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28000842 XER: 20040000
[ 1767.952360] CFAR: c0000000001ffe64 IRQMASK: 1
[ 1767.952360] GPR00: c0000000007ab508 c0000009e5a17ac0 c000000001ac0700 0000000000000054
[ 1767.952360] GPR04: c0000009f056cf90 c0000009f05f5628 c0000009ed40d654 c000000001c90700
[ 1767.952360] GPR08: 0000000000000007 c0000009f0573980 00000009ef2b0000 7562202c38303230
[ 1767.952360] GPR12: 0000000000000000 c0000007fff6ce80 c00a000002470208 0000000000000000
[ 1767.952360] GPR16: 0000000000000001 c0000009f05fbb00 0000000000000800 c0000009ff3d4980
[ 1767.952360] GPR20: c0000009f05fbb10 5deadbeef0000100 5deadbeef0000200 0000000000187961
[ 1767.952360] GPR24: c0000009e5a17b78 0000000000000000 0000000000000001 ffffffffffffffff
[ 1767.952360] GPR28: c00a000002470200 c0000009f05fbb10 c0000009f05fbb10 0000000000000000
[ 1767.952375] NIP [c0000000007ab50c] __list_del_entry_valid+0xac/0x100
[ 1767.952376] LR [c0000000007ab508] __list_del_entry_valid+0xa8/0x100
[ 1767.952377] Call Trace:
[ 1767.952378] [c0000009e5a17ac0] [c0000000007ab508] __list_del_entry_valid+0xa8/0x100 (unreliable)
[ 1767.952381] [c0000009e5a17b20] [c000000000476e18] free_pcppages_bulk+0x1f8/0x940
[ 1767.952383] [c0000009e5a17c20] [c00000000047a9a0] free_unref_page+0xd0/0x100
[ 1767.952386] [c0000009e5a17c50] [c0000000000bc2a8] xive_spapr_cleanup_queue+0x148/0x1b0
[ 1767.952388] [c0000009e5a17cf0] [c0000000000b96dc] xive_teardown_cpu+0x1bc/0x240
[ 1767.952391] [c0000009e5a17d30] [c00000000010bf28] pseries_mach_cpu_die+0x78/0x2f0
[ 1767.952393] [c0000009e5a17de0] [c00000000005c8d8] cpu_die+0x48/0x70
[ 1767.952394] [c0000009e5a17e00] [c000000000021cf0] arch_cpu_idle_dead+0x20/0x40
[ 1767.952397] [c0000009e5a17e20] [c0000000001b4294] do_idle+0x2f4/0x4c0
[ 1767.952399] [c0000009e5a17ea0] [c0000000001b46a8] cpu_startup_entry+0x38/0x40
[ 1767.952400] [c0000009e5a17ed0] [c00000000005c43c] start_secondary+0x7bc/0x8f0
[ 1767.952403] [c0000009e5a17f90] [c00000000000ac70] start_secondary_prolog+0x10/0x14
or on the worker thread handling the unplug:
[ 1538.253044] pseries-hotplug-cpu: Attempting to remove CPU <NULL>, drc index: 1000013a
[ 1538.360259] Querying DEAD? cpu 314 (314) shows 2
[ 1538.360736] BUG: Bad page state in process kworker/u768:3 pfn:95de1
[ 1538.360746] cpu 314 (hwid 314) Ready to die...
[ 1538.360784] page:c00a000002577840 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0
[ 1538.361881] flags: 0x5ffffc00000000()
[ 1538.361908] raw: 005ffffc00000000 5deadbeef0000100 5deadbeef0000200 0000000000000000
[ 1538.361955] raw: 0000000000000000 0000000000000000 00000000ffffff7f 0000000000000000
[ 1538.362002] page dumped because: nonzero mapcount
[ 1538.362033] Modules linked in: kvm xt_CHECKSUM ipt_MASQUERADE xt_conntrack ipt_REJECT nft_counter nf_nat_tftp nft_objref nf_conntrack_tftp tun bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink sunrpc xts vmx_crypto ip_tables xfs libcrc32c sd_mod sg virtio_net net_failover virtio_scsi failover dm_mirror dm_region_hash dm_log dm_mod
[ 1538.362613] CPU: 0 PID: 548 Comm: kworker/u768:3 Kdump: loaded Not tainted 4.18.0-224.el8.bz1856588.ppc64le #1
[ 1538.362687] Workqueue: pseries hotplug workque pseries_hp_work_fn
[ 1538.362725] Call Trace:
[ 1538.362743] [c0000009d4adf590] [c000000000e0e0fc] dump_stack+0xb0/0xf4 (unreliable)
[ 1538.362789] [c0000009d4adf5d0] [c000000000475dfc] bad_page+0x12c/0x1b0
[ 1538.362827] [c0000009d4adf660] [c0000000004784bc] free_pcppages_bulk+0x5bc/0x940
[ 1538.362871] [c0000009d4adf760] [c000000000478c38] page_alloc_cpu_dead+0x118/0x120
[ 1538.362918] [c0000009d4adf7b0] [c00000000015b898] cpuhp_invoke_callback.constprop.5+0xb8/0x760
[ 1538.362969] [c0000009d4adf820] [c00000000015eee8] _cpu_down+0x188/0x340
[ 1538.363007] [c0000009d4adf890] [c00000000015d75c] cpu_down+0x5c/0xa0
[ 1538.363045] [c0000009d4adf8c0] [c00000000092c544] cpu_subsys_offline+0x24/0x40
[ 1538.363091] [c0000009d4adf8e0] [c0000000009212f0] device_offline+0xf0/0x130
[ 1538.363129] [c0000009d4adf920] [c00000000010aee4] dlpar_offline_cpu+0x1c4/0x2a0
[ 1538.363174] [c0000009d4adf9e0] [c00000000010b2f8] dlpar_cpu_remove+0xb8/0x190
[ 1538.363219] [c0000009d4adfa60] [c00000000010b4fc] dlpar_cpu_remove_by_index+0x12c/0x150
[ 1538.363264] [c0000009d4adfaf0] [c00000000010ca24] dlpar_cpu+0x94/0x800
[ 1538.363302] [c0000009d4adfc00] [c000000000102cc8] pseries_hp_work_fn+0x128/0x1e0
[ 1538.363347] [c0000009d4adfc70] [c00000000018aa84] process_one_work+0x304/0x5d0
[ 1538.363394] [c0000009d4adfd10] [c00000000018b5cc] worker_thread+0xcc/0x7a0
[ 1538.363433] [c0000009d4adfdc0] [c00000000019567c] kthread+0x1ac/0x1c0
[ 1538.363469] [c0000009d4adfe30] [c00000000000b7dc] ret_from_kernel_thread+0x5c/0x80
The latter trace is due to the following sequence:
page_alloc_cpu_dead
drain_pages
drain_pages_zone
free_pcppages_bulk
where drain_pages() in this case is called under the assumption that
the unplugged cpu is no longer executing. To ensure that is the case,
and early call is made to __cpu_die()->pseries_cpu_die(), which runs
a loop that waits for the cpu to reach a halted state by polling its
status via query-cpu-stopped-state RTAS calls. It only polls for
25 iterations before giving up, however, and in the trace above this
results in the following being printed only .1 seconds after the
hotplug worker thread begins processing the unplug request:
[ 1538.253044] pseries-hotplug-cpu: Attempting to remove CPU <NULL>, drc index: 1000013a
[ 1538.360259] Querying DEAD? cpu 314 (314) shows 2
At that point the worker thread assumes the unplugged CPU is in some
unknown/dead state and procedes with the cleanup, causing the race with
the XIVE cleanup code executed by the unplugged CPU.
Fix this by waiting indefinitely, but also making an effort to avoid
spurious lockup messages by allowing for rescheduling after polling
the CPU status and printing a warning if we wait for longer than 120s.
Fixes: eac1e731b59ee ("powerpc/xive: guest exploitation of the XIVE interrupt controller")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1856588
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Cedric Le Goater <clg@kaod.org>
Cc: Greg Kurz <groug@kaod.org>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
changes from v1:
- renamed from "powerpc/pseries/hotplug-cpu: increase wait time for vCPU death"
- wait indefinitely, but issue cond_resched() when RTAS reports that CPU
hasn't stopped (Michael)
- print a warning after 120s of waiting (Michael)
- use pr_warn() instead of default printk() level
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index c6e0d8abf75e..7a974ed6b240 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -107,22 +107,28 @@ static int pseries_cpu_disable(void)
*/
static void pseries_cpu_die(unsigned int cpu)
{
- int tries;
int cpu_status = 1;
unsigned int pcpu = get_hard_smp_processor_id(cpu);
+ unsigned long timeout = jiffies + msecs_to_jiffies(120000);
- for (tries = 0; tries < 25; tries++) {
+ while (true) {
cpu_status = smp_query_cpu_stopped(pcpu);
if (cpu_status == QCSS_STOPPED ||
cpu_status == QCSS_HARDWARE_ERROR)
break;
- cpu_relax();
+ if (time_after(jiffies, timeout)) {
+ pr_warn("CPU %i (hwid %i) didn't die after 120 seconds\n",
+ cpu, pcpu);
+ timeout = jiffies + msecs_to_jiffies(120000);
+ }
+
+ cond_resched();
}
- if (cpu_status != 0) {
- printk("Querying DEAD? cpu %i (%i) shows %i\n",
- cpu, pcpu, cpu_status);
+ if (cpu_status == QCSS_HARDWARE_ERROR) {
+ pr_warn("CPU %i (hwid %i) reported error while dying\n",
+ cpu, pcpu);
}
/* Isolation and deallocation are definitely done by
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 0/8] huge vmalloc mappings
From: Jonathan Cameron @ 2020-08-11 16:32 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linux-arch, Zefan Li, H. Peter Anvin, Will Deacon, x86,
linux-kernel, linux-mm, Ingo Molnar, Borislav Petkov,
Catalin Marinas, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200810022732.1150009-1-npiggin@gmail.com>
On Mon, 10 Aug 2020 12:27:24 +1000
Nicholas Piggin <npiggin@gmail.com> wrote:
> Not tested on x86 or arm64, would appreciate a quick test there so I can
> ask Andrew to put it in -mm. Other option is I can disable huge vmallocs
> for them for the time being.
Hi Nicholas,
For arm64 testing with a Kunpeng920.
I ran a quick sanity test with this series on top of mainline (yes mid merge window
so who knows what state is...). Could I be missing some dependency?
Without them it boots, with them it doesn't. Any immediate guesses?
[ 0.069507] Dentry cache hash table entries: 33554432 (order: 16, 268435456 bytes, vmalloc)
[ 0.087134] Inode-cache hash table entries: 16777216 (order: 15, 134217728 bytes, vmalloc)
[ 0.097044] Mount-cache hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc)
[ 0.106534] Mountpoint-cache hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc)
[ 0.116349] ------------[ cut here ]------------
[ 0.121465] kernel BUG at kernel/fork.c:402!
[ 0.126194] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 0.132273] Modules linked in:
[ 0.135653] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.8.0-12307-g2b197e00c338 #637
[ 0.144240] pstate: 20000009 (nzCv daif -PAN -UAO BTYPE=--)
[ 0.150420] pc : copy_process+0x10c0/0x1690
[ 0.155049] lr : copy_process+0x2e0/0x1690
[ 0.159584] sp : ffffd96c55773d60
[ 0.163250] x29: ffffd96c55773d70 x28: ffff20bf87060000
[ 0.169134] x27: 0000000000800300 x26: 00000000ffffffff
[ 0.175018] x25: ffff8000108a8000 x24: ffffd96c55a32708
[ 0.180901] x23: ffff20bf87043800 x22: 0000000000000000
[ 0.186787] x21: 0000000000000000 x20: ffffd96c55773ef0
[ 0.192672] x19: ffffd96c55783bc0 x18: 0000000000000010
[ 0.198557] x17: 00000000855c858e x16: 00000000a8256fca
[ 0.204441] x15: ffffffffffffffff x14: ffff000000000000
[ 0.210327] x13: ffff800010901000 x12: ffff8000108b1000
[ 0.216212] x11: 0000000000000001 x10: ffffd96c55a6d000
[ 0.222096] x9 : ffffd96c53bf7594 x8 : 0000000000000041
[ 0.227980] x7 : ffff004fffffa6b0 x6 : ffff800010aa8000
[ 0.233864] x5 : 000000000000fffd x4 : 0000000000000000
[ 0.239748] x3 : ffffd96c55a63598 x2 : 0000000000000001
[ 0.245632] x1 : ffffd96c55783bc0 x0 : 0000000000000008
[ 0.251519] Call trace:
[ 0.254221] copy_process+0x10c0/0x1690
[ 0.258466] _do_fork+0x98/0x488
[ 0.262036] kernel_thread+0x6c/0x90
[ 0.265997] rest_init+0x38/0xf0
[ 0.269568] arch_call_rest_init+0x18/0x24
[ 0.274105] start_kernel+0x60c/0x644
[ 0.278159] Code: f000a441 f943f421 cb010000 17ffffe1 (d4210000)
[ 0.284961] ---[ end trace 985361e2cb97a0d9 ]---
[ 0.290073] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.297532] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
Thanks,
Jonathan
>
> Since v2:
> - Rebased on vmalloc cleanups, split series into simpler pieces.
> - Fixed several compile errors and warnings
> - Keep the page array and accounting in small page units because
> struct vm_struct is an interface (this should fix x86 vmap stack debug
> assert). [Thanks Zefan]
>
> Nicholas Piggin (8):
> mm/vmalloc: fix vmalloc_to_page for huge vmap mappings
> mm: apply_to_pte_range warn and fail if a large pte is encountered
> mm/vmalloc: rename vmap_*_range vmap_pages_*_range
> lib/ioremap: rename ioremap_*_range to vmap_*_range
> mm: HUGE_VMAP arch support cleanup
> mm: Move vmap_range from lib/ioremap.c to mm/vmalloc.c
> mm/vmalloc: add vmap_range_noflush variant
> mm/vmalloc: Hugepage vmalloc mappings
>
> .../admin-guide/kernel-parameters.txt | 2 +
> arch/arm64/mm/mmu.c | 10 +-
> arch/powerpc/mm/book3s64/radix_pgtable.c | 8 +-
> arch/x86/mm/ioremap.c | 10 +-
> include/linux/io.h | 9 -
> include/linux/vmalloc.h | 13 +
> init/main.c | 1 -
> mm/ioremap.c | 231 +--------
> mm/memory.c | 60 ++-
> mm/vmalloc.c | 442 +++++++++++++++---
> 10 files changed, 453 insertions(+), 333 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 2/2 v2] powerpc/powernv: Enable and setup PCI P2P
From: Frederic Barrat @ 2020-08-11 17:25 UTC (permalink / raw)
To: Oliver O'Halloran, Max Gurtovoy
Cc: vladimirk, Carol L Soto, linux-pci, shlomin, israelr, idanw,
linuxppc-dev, Christoph Hellwig, aneela
In-Reply-To: <CAOSf1CGv=0bwShzzK5zP3dtKg=RxeTFvq52j-Vi4GDfZ4UpBJA@mail.gmail.com>
Le 03/08/2020 à 09:35, Oliver O'Halloran a écrit :
> On Thu, Apr 30, 2020 at 11:15 PM Max Gurtovoy <maxg@mellanox.com> wrote:
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index 57d3a6a..9ecc576 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> @@ -3706,18 +3706,208 @@ static void pnv_pci_ioda_dma_bus_setup(struct pci_bus *bus)
>> }
>> }
>>
>> +#ifdef CONFIG_PCI_P2PDMA
>> +static DEFINE_MUTEX(p2p_mutex);
>> +
>> +static bool pnv_pci_controller_owns_addr(struct pci_controller *hose,
>> + phys_addr_t addr, size_t size)
>> +{
>> + int i;
>> +
>> + /*
>> + * It seems safe to assume the full range is under the same PHB, so we
>> + * can ignore the size.
>> + */
>> + for (i = 0; i < ARRAY_SIZE(hose->mem_resources); i++) {
>> + struct resource *res = &hose->mem_resources[i];
>> +
>> + if (res->flags && addr >= res->start && addr < res->end)
>> + return true;
>> + }
>> + return false;
>> +}
>> +
>> +/*
>> + * find the phb owning a mmio address if not owned locally
>> + */
>> +static struct pnv_phb *pnv_pci_find_owning_phb(struct pci_dev *pdev,
>> + phys_addr_t addr, size_t size)
>> +{
>> + struct pci_controller *hose;
>> +
>> + /* fast path */
>> + if (pnv_pci_controller_owns_addr(pdev->bus->sysdata, addr, size))
>> + return NULL;
>
> Do we actually need this fast path? It's going to be slow either way.
> Also if a device is doing p2p to another device under the same PHB
> then it should not be happening via the root complex. Is this a case
> you've tested?
The "fast path" comment is misleading and we should rephrase. The point
is to catch if we're mapping a resource under the same PHB, in which
case we don't modify the PHB configuration. So we need to catch it
early, but it's not a fast path.
If the 2 devices are under the same PHB, the code above shouldn't do
anything. So I guess behavior depends on the underlying bridge? We'll
need another platform than witherspoon to test it. Probably worth checking.
>> + list_for_each_entry(hose, &hose_list, list_node) {
>> + struct pnv_phb *phb = hose->private_data;
>> +
>> + if (phb->type != PNV_PHB_NPU_NVLINK &&
>> + phb->type != PNV_PHB_NPU_OCAPI) {
>> + if (pnv_pci_controller_owns_addr(hose, addr, size))
>> + return phb;
>> + }
>> + }
>> + return NULL;
>> +}
>> +
>> +static u64 pnv_pci_dma_dir_to_opal_p2p(enum dma_data_direction dir)
>> +{
>> + if (dir == DMA_TO_DEVICE)
>> + return OPAL_PCI_P2P_STORE;
>> + else if (dir == DMA_FROM_DEVICE)
>> + return OPAL_PCI_P2P_LOAD;
>> + else if (dir == DMA_BIDIRECTIONAL)
>> + return OPAL_PCI_P2P_LOAD | OPAL_PCI_P2P_STORE;
>> + else
>> + return 0;
>> +}
>> +
>> +static int pnv_pci_ioda_enable_p2p(struct pci_dev *initiator,
>> + struct pnv_phb *phb_target,
>> + enum dma_data_direction dir)
>> +{
>> + struct pci_controller *hose;
>> + struct pnv_phb *phb_init;
>> + struct pnv_ioda_pe *pe_init;
>> + u64 desc;
>> + int rc;
>> +
>> + if (!opal_check_token(OPAL_PCI_SET_P2P))
>> + return -ENXIO;
>> +
>
>> + hose = pci_bus_to_host(initiator->bus);
>> + phb_init = hose->private_data;
>
> You can use the pci_bus_to_pnvhb() helper
>
>> +
>> + pe_init = pnv_ioda_get_pe(initiator);
>> + if (!pe_init)
>> + return -ENODEV;
>> +
>> + if (!pe_init->tce_bypass_enabled)
>> + return -EINVAL;
>> +
>> + /*
>> + * Configuring the initiator's PHB requires to adjust its TVE#1
>> + * setting. Since the same device can be an initiator several times for
>> + * different target devices, we need to keep a reference count to know
>> + * when we can restore the default bypass setting on its TVE#1 when
>> + * disabling. Opal is not tracking PE states, so we add a reference
>> + * count on the PE in linux.
>> + *
>> + * For the target, the configuration is per PHB, so we keep a
>> + * target reference count on the PHB.
>> + */
>
> This irks me a bit because configuring the DMA address limits for the
> TVE is the kernel's job. What we really should be doing is using
> opal_pci_map_pe_dma_window_real() to set the bypass-mode address limit
> for the TVE to something large enough to hit the MMIO ranges rather
> than having set_p2p do it as a side effect. Unfortunately, for some
> reason skiboot doesn't implement support for enabling 56bit addressing
> using opal_pci_map_pe_dma_window_real() and we do need to support
> older kernel's which used this stuff so I guess we're stuck with it
> for now. It'd be nice if we could fix this in the longer term
> though...
OK. We'd need more than a 56-bit opal_pci_map_pe_dma_window_real()
though, there's also a queue setting change on the target PHB.
Fred
>> + mutex_lock(&p2p_mutex);
>> +
>> + desc = OPAL_PCI_P2P_ENABLE | pnv_pci_dma_dir_to_opal_p2p(dir);
>> + /* always go to opal to validate the configuration */
>> + rc = opal_pci_set_p2p(phb_init->opal_id, phb_target->opal_id, desc,
>> + pe_init->pe_number);
>> + if (rc != OPAL_SUCCESS) {
>> + rc = -EIO;
>> + goto out;
>> + }
>> +
>> + pe_init->p2p_initiator_count++;
>> + phb_target->p2p_target_count++;
>> +
>> + rc = 0;
>> +out:
>> + mutex_unlock(&p2p_mutex);
>> + return rc;
>> +}
>> +
>> +static int pnv_pci_dma_map_resource(struct pci_dev *pdev,
>> + phys_addr_t phys_addr, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + struct pnv_phb *target_phb;
>> +
>> + target_phb = pnv_pci_find_owning_phb(pdev, phys_addr, size);
>> + if (!target_phb)
>> + return 0;
>> +
>> + return pnv_pci_ioda_enable_p2p(pdev, target_phb, dir);
>> +}
>> +
>> +static int pnv_pci_ioda_disable_p2p(struct pci_dev *initiator,
>> + struct pnv_phb *phb_target)
>> +{
>> + struct pci_controller *hose;
>> + struct pnv_phb *phb_init;
>> + struct pnv_ioda_pe *pe_init;
>> + int rc;
>> +
>> + if (!opal_check_token(OPAL_PCI_SET_P2P))
>> + return -ENXIO;
>
> This should probably have a WARN_ON() since we can't hit this path
> unless the initial map succeeds.
>
>> + hose = pci_bus_to_host(initiator->bus);
>> + phb_init = hose->private_data;
>
> pci_bus_to_pnvhb()
>
>> + pe_init = pnv_ioda_get_pe(initiator);
>> + if (!pe_init)
>> + return -ENODEV;
>> +
>> + mutex_lock(&p2p_mutex);
>> +
>> + if (!pe_init->p2p_initiator_count || !phb_target->p2p_target_count) {
>> + rc = -EINVAL;
>> + goto out;
>> + }
>> +
>> + if (--pe_init->p2p_initiator_count == 0)
>> + pnv_pci_ioda2_set_bypass(pe_init, true);
>> +
>> + if (--phb_target->p2p_target_count == 0) {
>> + rc = opal_pci_set_p2p(phb_init->opal_id, phb_target->opal_id,
>> + 0, pe_init->pe_number);
>> + if (rc != OPAL_SUCCESS) {
>> + rc = -EIO;
>> + goto out;
>> + }
>> + }
>> +
>> + rc = 0;
>> +out:
>> + mutex_unlock(&p2p_mutex);
>> + return rc;
>> +}
>> +
>> +static void pnv_pci_dma_unmap_resource(struct pci_dev *pdev,
>> + dma_addr_t addr, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + struct pnv_phb *target_phb;
>> + int rc;
>> +
>> + target_phb = pnv_pci_find_owning_phb(pdev, addr, size);
>> + if (!target_phb)
>> + return;
>> +
>> + rc = pnv_pci_ioda_disable_p2p(pdev, target_phb);
>> + if (rc)
>> + dev_err(&pdev->dev, "Failed to undo PCI peer-to-peer setup for address %llx: %d\n",
>> + addr, rc);
>
> Use pci_err() or pe_err().
>
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 6553fb799f601497ca0703682e2aff131197dc5c
From: kernel test robot @ 2020-08-11 18:51 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 6553fb799f601497ca0703682e2aff131197dc5c powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne X1000)
elapsed time: 868m
configs tested: 73
configs skipped: 93
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
mips qi_lb60_defconfig
m68k sun3x_defconfig
m68k sun3_defconfig
powerpc skiroot_defconfig
sh sh7710voipgw_defconfig
powerpc ppc64e_defconfig
powerpc ppc6xx_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20200811
x86_64 randconfig-a001-20200811
x86_64 randconfig-a003-20200811
x86_64 randconfig-a005-20200811
x86_64 randconfig-a004-20200811
x86_64 randconfig-a002-20200811
i386 randconfig-a005-20200811
i386 randconfig-a001-20200811
i386 randconfig-a002-20200811
i386 randconfig-a003-20200811
i386 randconfig-a006-20200811
i386 randconfig-a004-20200811
i386 randconfig-a016-20200811
i386 randconfig-a011-20200811
i386 randconfig-a015-20200811
i386 randconfig-a013-20200811
i386 randconfig-a012-20200811
i386 randconfig-a014-20200811
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS f04b169e953c4db1a3a3c1d23eea09c726f01ee5
From: kernel test robot @ 2020-08-11 18:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: f04b169e953c4db1a3a3c1d23eea09c726f01ee5 Automatic merge of 'master', 'next' and 'fixes' (2020-08-11 14:12)
elapsed time: 872m
configs tested: 66
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm allyesconfig
arm allmodconfig
arm64 defconfig
ia64 allyesconfig
ia64 allmodconfig
ia64 defconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20200811
i386 randconfig-a002-20200811
i386 randconfig-a003-20200811
i386 randconfig-a004-20200811
i386 randconfig-a005-20200811
i386 randconfig-a006-20200811
i386 randconfig-a016-20200811
i386 randconfig-a011-20200811
i386 randconfig-a015-20200811
i386 randconfig-a013-20200811
i386 randconfig-a012-20200811
i386 randconfig-a014-20200811
x86_64 randconfig-a006-20200811
x86_64 randconfig-a001-20200811
x86_64 randconfig-a003-20200811
x86_64 randconfig-a005-20200811
x86_64 randconfig-a004-20200811
x86_64 randconfig-a002-20200811
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 0a2900256840208c4a4248ff5900ae57990d55dc
From: kernel test robot @ 2020-08-11 18:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 0a2900256840208c4a4248ff5900ae57990d55dc powerpc: Use simple i2c probe function
elapsed time: 871m
configs tested: 69
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
sh rsk7264_defconfig
mips xway_defconfig
h8300 h8300h-sim_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20200811
x86_64 randconfig-a001-20200811
x86_64 randconfig-a003-20200811
x86_64 randconfig-a005-20200811
x86_64 randconfig-a004-20200811
x86_64 randconfig-a002-20200811
i386 randconfig-a005-20200811
i386 randconfig-a001-20200811
i386 randconfig-a002-20200811
i386 randconfig-a003-20200811
i386 randconfig-a006-20200811
i386 randconfig-a004-20200811
i386 randconfig-a016-20200811
i386 randconfig-a011-20200811
i386 randconfig-a015-20200811
i386 randconfig-a013-20200811
i386 randconfig-a012-20200811
i386 randconfig-a014-20200811
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
From: Herbert Xu @ 2020-08-12 0:36 UTC (permalink / raw)
To: Horia Geantă
Cc: Andrei Botila (OSS), Andrei Botila, Van Leeuwen, Pascal,
Antoine Tenart, linux-s390@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-arm-kernel@axis.com,
Eric Biggers, linux-crypto@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <d4a471e6-34c9-c702-63d6-1f6a3cba0ebe@nxp.com>
On Tue, Aug 11, 2020 at 06:28:39PM +0300, Horia Geantă wrote:
>
> What about, for example, CBC?
> AFAICT cbc(aes) with input length = 0 is valid.
That's just because CBC accepts any input which is a multiple
of blocksize.
> Same for CTR (with the note that blocksize = 1) and several other algorithms
> mentioned in the cover letter.
CTR accepts any input size.
> What's the rule in these cases?
What input size is accepted depends on the algorithm.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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