* Re: [PATCH] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe
From: Joakim Tjernlund @ 2020-08-24 8:49 UTC (permalink / raw)
To: yebin10@huawei.com, gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
leoyang.li@nxp.com
In-Reply-To: <20200824082122.GA336539@kroah.com>
On Mon, 2020-08-24 at 10:21 +0200, Greg KH wrote:
>
> On Mon, Aug 24, 2020 at 04:04:37PM +0800, Ye Bin wrote:
> > Signed-off-by: Ye Bin <yebin10@huawei.com>
>
> I can't take patches without any changelog text, sorry.
Still taking patches for fsl_udc_core.c ?
I figured this driver was obsolete and should be moved to one of the Chipidea drivers.
Jocke
^ permalink raw reply
* Re: Re：Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero
From: Guohua Zhong @ 2020-08-24 11:54 UTC (permalink / raw)
To: segher
Cc: zhongguohua1, wangle6, gregkh, linuxppc-dev, linux-kernel, paulus,
stable, nixiaoming
In-Reply-To: <20200823001101.GO28786@gate.crashing.org>
>> Yet, I have noticed that there is no checking of 'base' in these functions.
>> But I am not sure how to check is better.As we know that the result is
>> undefined when divisor is zero. It maybe good to print error and dump stack.
>> Let the process to know that the divisor is zero by sending SIGFPE.
> That is now what the PowerPC integer divide insns do: they just leave
> the result undefined (and they can set the overflow flag then, but no
> one uses that).
OK ,So just keep the patch as below. If this patch looks good for you, please
help to review. I will send the new patch later.
Thanks for your reply.
diff --git a/arch/powerpc/boot/div64.S b/arch/powerpc/boot/div64.S
index 4354928ed62e..1d3561cf16fa 100644
--- a/arch/powerpc/boot/div64.S
+++ b/arch/powerpc/boot/div64.S
@@ -13,8 +13,10 @@
.globl __div64_32
.globl __div64_32
__div64_32:
+ cmplwi r4,0 # check if divisor r4 is zero
lwz r5,0(r3) # get the dividend into r5/r6
lwz r6,4(r3)
+ beq 5f # jump to label 5 if r4(divisor) is zero
cmplw r5,r4
li r7,0
li r8,0
@@ -52,7 +54,7 @@ __div64_32:
4: stw r7,0(r3) # return the quotient in *r3
stw r8,4(r3)
mr r3,r6 # return the remainder in r3
- blr
+5: blr # return if divisor r4 is zero
/*
* Extended precision shifts.
diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
index 3d5426e7dcc4..570774d9782d 100644
--- a/arch/powerpc/lib/div64.S
+++ b/arch/powerpc/lib/div64.S
@@ -13,8 +13,10 @@
#include <asm/processor.h>
_GLOBAL(__div64_32)
+ cmplwi r4,0 # check if divisor r4 is zero
lwz r5,0(r3) # get the dividend into r5/r6
lwz r6,4(r3)
+ beq 5f # jump to label 5 if r4(divisor) is zero
cmplw r5,r4
li r7,0
li r8,0
@@ -52,4 +54,4 @@ _GLOBAL(__div64_32)
4: stw r7,0(r3) # return the quotient in *r3
stw r8,4(r3)
mr r3,r6 # return the remainder in r3
- blr
+5: blr # return if divisor r4 is zero
Guohua
^ permalink raw reply related
* [PATCH] selftests/powerpc: Fix prefixes in alignment_handler signal handler
From: Jordan Niethe @ 2020-08-24 13:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jordan Niethe
The signal handler in the alignment handler self test has the ability to
jump over the instruction that triggered the signal. It does this by
incrementing the PT_NIP in the user context by 4. If it were a prefixed
instruction this will mean that the suffix is then executed which is
incorrect. Instead check if the major opcode indicates a prefixed
instruction (e.g. it is 1) and if so increment PT_NIP by 8.
If ISA v3.1 is not available treat it as a word instruction even if the
major opcode is 1.
Fixes: 620a6473df36 ("selftests/powerpc: Add prefixed loads/stores to
alignment_handler test")
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
.../selftests/powerpc/alignment/alignment_handler.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/alignment/alignment_handler.c b/tools/testing/selftests/powerpc/alignment/alignment_handler.c
index 55ef15184057..c197ff828120 100644
--- a/tools/testing/selftests/powerpc/alignment/alignment_handler.c
+++ b/tools/testing/selftests/powerpc/alignment/alignment_handler.c
@@ -64,12 +64,14 @@ int bufsize;
int debug;
int testing;
volatile int gotsig;
+bool haveprefixes;
char *cipath = "/dev/fb0";
long cioffset;
void sighandler(int sig, siginfo_t *info, void *ctx)
{
ucontext_t *ucp = ctx;
+ u32 inst;
if (!testing) {
signal(sig, SIG_DFL);
@@ -77,7 +79,12 @@ void sighandler(int sig, siginfo_t *info, void *ctx)
}
gotsig = sig;
#ifdef __powerpc64__
- ucp->uc_mcontext.gp_regs[PT_NIP] += 4;
+ if (haveprefixes) {
+ inst = *(u32 *)ucp->uc_mcontext.gp_regs[PT_NIP];
+ ucp->uc_mcontext.gp_regs[PT_NIP] += ((inst >> 26 == 1) ? 8 : 4);
+ } else {
+ ucp->uc_mcontext.gp_regs[PT_NIP] += 4;
+ }
#else
ucp->uc_mcontext.uc_regs->gregs[PT_NIP] += 4;
#endif
@@ -648,6 +655,8 @@ int main(int argc, char *argv[])
exit(1);
}
+ haveprefixes = have_hwcap2(PPC_FEATURE2_ARCH_3_1);
+
rc |= test_harness(test_alignment_handler_vsx_206,
"test_alignment_handler_vsx_206");
rc |= test_harness(test_alignment_handler_vsx_207,
--
2.17.1
^ permalink raw reply related
* Re: Re：Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero
From: Guohua Zhong @ 2020-08-24 13:25 UTC (permalink / raw)
To: paubert
Cc: zhongguohua1, wangle6, gregkh, linuxppc-dev, linux-kernel, paulus,
stable, nixiaoming
In-Reply-To: <20200822172524.GA5451@lt-gp.iram.es>
>> >In generic version in lib/math/div64.c, there is no checking of 'base'
>> >either.
>> >Do we really want to add this check in the powerpc version only ?
>>
>> >The only user of __div64_32() is do_div() in
>> >include/asm-generic/div64.h. Wouldn't it be better to do the check there ?
>>
>> >Christophe
>>
>> Yet, I have noticed that there is no checking of 'base' in these functions.
>> But I am not sure how to check is better.As we know that the result is
>> undefined when divisor is zero. It maybe good to print error and dump stack.
>> Let the process to know that the divisor is zero by sending SIGFPE.
>>
>> diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h
>> index a3b98c86f077..161c656ee3ee 100644
>> --- a/include/asm-generic/div64.h
>> +++ b/include/asm-generic/div64.h
>> @@ -43,6 +43,11 @@
>> # define do_div(n,base) ({ \
>> uint32_t __base = (base); \
>> uint32_t __rem; \
>> + if (unlikely(base == 0)) { \
>> + pr_err("do_div base=%d\n",base); \
>> + dump_stack(); \
>> + force_sig(SIGFPE); \
>> + }
>>
> I suspect this will generate a strong reaction. SIGFPE is for user space
> instruction attempting a division by zero. A division by zero in the
> kernel is a kernel bug, period, and you don't want to kill a user
> process for this reason.
> If it happens in an interrupt, the context of the kernel may not even be
> related to the current process.
> Many other architectures (x86 for example) already trigger an exception
> on a division by zero but the handler will find that the exception
> happened in kernel context and generate an Oops, not raise a signal in a
> (possibly innocent) userland process.
OK. So just don't touch do_div functions in include/asm-generic/div64.h
But for powerpc it can not trigger an exception when divisor is 0 in __div64_32.
So the patch as below is still useful for powerpc. If this patch looks good for
you, please help to review. I will send the new patch later.
Thanks for your reply.
diff --git a/arch/powerpc/boot/div64.S b/arch/powerpc/boot/div64.S
index 4354928ed62e..1d3561cf16fa 100644
--- a/arch/powerpc/boot/div64.S
+++ b/arch/powerpc/boot/div64.S
@@ -13,8 +13,10 @@
.globl __div64_32
.globl __div64_32
__div64_32:
+ cmplwi r4,0 # check if divisor r4 is zero
lwz r5,0(r3) # get the dividend into r5/r6
lwz r6,4(r3)
+ beq 5f # jump to label 5 if r4(divisor) is zero
cmplw r5,r4
li r7,0
li r8,0
@@ -52,7 +54,7 @@ __div64_32:
4: stw r7,0(r3) # return the quotient in *r3
stw r8,4(r3)
mr r3,r6 # return the remainder in r3
- blr
+5: blr # return if divisor r4 is zero
/*
* Extended precision shifts.
diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
index 3d5426e7dcc4..570774d9782d 100644
--- a/arch/powerpc/lib/div64.S
+++ b/arch/powerpc/lib/div64.S
@@ -13,8 +13,10 @@
#include <asm/processor.h>
_GLOBAL(__div64_32)
+ cmplwi r4,0 # check if divisor r4 is zero
lwz r5,0(r3) # get the dividend into r5/r6
lwz r6,4(r3)
+ beq 5f # jump to label 5 if r4(divisor) is zero
cmplw r5,r4
li r7,0
li r8,0
@@ -52,4 +54,4 @@ _GLOBAL(__div64_32)
4: stw r7,0(r3) # return the quotient in *r3
stw r8,4(r3)
mr r3,r6 # return the remainder in r3
- blr
+5: blr # return if divisor r4 is zero
Guohua
^ permalink raw reply related
* Re: [PATCH RESEND] ASoC: fsl_sai: Add -EPROBE_DEFER check for regmap init
From: Mark Brown @ 2020-08-24 13:31 UTC (permalink / raw)
To: Xiubo.Lee, tiwai, timur, alsa-devel, festevam, Shengjiu Wang,
lgirdwood, perex, nicoleotsuka
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1598255887-1391-1-git-send-email-shengjiu.wang@nxp.com>
On Mon, 24 Aug 2020 15:58:07 +0800, Shengjiu Wang wrote:
> Regmap initialization may return -EPROBE_DEFER for clock
> may not be ready, so check -EPROBE_DEFER error type before
> start another Regmap initialization.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_sai: Add -EPROBE_DEFER check for regmap init
commit: c1e47e8919da525c803d1557a30e44441db1e5ee
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe
From: Felipe Balbi @ 2020-08-24 13:58 UTC (permalink / raw)
To: Joakim Tjernlund, yebin10@huawei.com, gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
leoyang.li@nxp.com
In-Reply-To: <f61f4bc3916f852799edb6af9740afb2118ec84f.camel@infinera.com>
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
Joakim Tjernlund <Joakim.Tjernlund@infinera.com> writes:
> On Mon, 2020-08-24 at 10:21 +0200, Greg KH wrote:
>>
>> On Mon, Aug 24, 2020 at 04:04:37PM +0800, Ye Bin wrote:
>> > Signed-off-by: Ye Bin <yebin10@huawei.com>
>>
>> I can't take patches without any changelog text, sorry.
>
> Still taking patches for fsl_udc_core.c ?
> I figured this driver was obsolete and should be moved to one of the Chipidea drivers.
Nobody sent any patches to switch over the users of this driver to
chipidea. I would love to delete this driver :-)
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]
^ permalink raw reply
* Re: [PATCH] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe
From: Joakim Tjernlund @ 2020-08-24 14:12 UTC (permalink / raw)
To: yebin10@huawei.com, gregkh@linuxfoundation.org, balbi@kernel.org
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
leoyang.li@nxp.com
In-Reply-To: <87d03gjgbw.fsf@kernel.org>
On Mon, 2020-08-24 at 16:58 +0300, Felipe Balbi wrote:
> Joakim Tjernlund <Joakim.Tjernlund@infinera.com> writes:
>
> > On Mon, 2020-08-24 at 10:21 +0200, Greg KH wrote:
> > >
> > > On Mon, Aug 24, 2020 at 04:04:37PM +0800, Ye Bin wrote:
> > > > Signed-off-by: Ye Bin <yebin10@huawei.com>
> > >
> > > I can't take patches without any changelog text, sorry.
> >
> > Still taking patches for fsl_udc_core.c ?
> > I figured this driver was obsolete and should be moved to one of the Chipidea drivers.
>
> Nobody sent any patches to switch over the users of this driver to
> chipidea. I would love to delete this driver :-)
Me too, I got a few local patches here as the driver is quite buggy.
Got to little USB knowledge to switch it over though :(
Jocke
^ permalink raw reply
* RE: Re：Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero
From: David Laight @ 2020-08-24 15:05 UTC (permalink / raw)
To: 'Guohua Zhong', paubert@iram.es
Cc: wangle6@huawei.com, gregkh@linuxfoundation.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
paulus@samba.org, stable@vger.kernel.org, nixiaoming@huawei.com
In-Reply-To: <20200824132539.35972-1-zhongguohua1@huawei.com>
From: Guohua Zhong
> Sent: 24 August 2020 14:26
>
> >> >In generic version in lib/math/div64.c, there is no checking of 'base'
> >> >either.
> >> >Do we really want to add this check in the powerpc version only ?
> >>
> >> >The only user of __div64_32() is do_div() in
> >> >include/asm-generic/div64.h. Wouldn't it be better to do the check there ?
> >>
> >> >Christophe
> >>
> >> Yet, I have noticed that there is no checking of 'base' in these functions.
> >> But I am not sure how to check is better.As we know that the result is
> >> undefined when divisor is zero. It maybe good to print error and dump stack.
I thought that the onus was put on the caller to avoid divide by zero.
On x86 divide by zero causes an exception which (I'm pretty sure)
leads to a oops/panic.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* [PATCH AUTOSEL 5.8 59/63] powerpc/perf: Fix soft lockups due to missed interrupt accounting
From: Sasha Levin @ 2020-08-24 16:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexey Kardashevskiy, Athira Rajeev, linuxppc-dev, Sasha Levin
In-Reply-To: <20200824163504.605538-1-sashal@kernel.org>
From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]
Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().
Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.
But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.
Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/perf/core-book3s.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 01d70280d2872..190bc4f255b42 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2101,6 +2101,10 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
if (perf_event_overflow(event, &data, regs))
power_pmu_stop(event, 0);
+ } else if (period) {
+ /* Account for interrupt in case of invalid SIAR */
+ if (perf_event_account_interrupt(event))
+ power_pmu_stop(event, 0);
}
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.7 50/54] powerpc/perf: Fix soft lockups due to missed interrupt accounting
From: Sasha Levin @ 2020-08-24 16:36 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexey Kardashevskiy, Athira Rajeev, linuxppc-dev, Sasha Levin
In-Reply-To: <20200824163634.606093-1-sashal@kernel.org>
From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]
Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().
Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.
But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.
Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/perf/core-book3s.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 3dcfecf858f36..5216c5a7f46da 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2099,6 +2099,10 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
if (perf_event_overflow(event, &data, regs))
power_pmu_stop(event, 0);
+ } else if (period) {
+ /* Account for interrupt in case of invalid SIAR */
+ if (perf_event_account_interrupt(event))
+ power_pmu_stop(event, 0);
}
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 36/38] powerpc/perf: Fix soft lockups due to missed interrupt accounting
From: Sasha Levin @ 2020-08-24 16:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexey Kardashevskiy, Athira Rajeev, linuxppc-dev, Sasha Levin
In-Reply-To: <20200824163751.606577-1-sashal@kernel.org>
From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]
Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().
Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.
But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.
Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/perf/core-book3s.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index ca92e01d0bd1b..e32f7700303bc 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2106,6 +2106,10 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
if (perf_event_overflow(event, &data, regs))
power_pmu_stop(event, 0);
+ } else if (period) {
+ /* Account for interrupt in case of invalid SIAR */
+ if (perf_event_account_interrupt(event))
+ power_pmu_stop(event, 0);
}
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 21/21] powerpc/perf: Fix soft lockups due to missed interrupt accounting
From: Sasha Levin @ 2020-08-24 16:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexey Kardashevskiy, Athira Rajeev, linuxppc-dev, Sasha Levin
In-Reply-To: <20200824163845.606933-1-sashal@kernel.org>
From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]
Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().
Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.
But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.
Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/perf/core-book3s.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 4004dbdab9c7b..d407b73298171 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2087,6 +2087,10 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
if (perf_event_overflow(event, &data, regs))
power_pmu_stop(event, 0);
+ } else if (period) {
+ /* Account for interrupt in case of invalid SIAR */
+ if (perf_event_account_interrupt(event))
+ power_pmu_stop(event, 0);
}
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 11/11] powerpc/perf: Fix soft lockups due to missed interrupt accounting
From: Sasha Levin @ 2020-08-24 16:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexey Kardashevskiy, Athira Rajeev, linuxppc-dev, Sasha Levin
In-Reply-To: <20200824163914.607152-1-sashal@kernel.org>
From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]
Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().
Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.
But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.
Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/perf/core-book3s.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 3188040022c4f..78f75e48dfe7f 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2096,6 +2096,10 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
if (perf_event_overflow(event, &data, regs))
power_pmu_stop(event, 0);
+ } else if (period) {
+ /* Account for interrupt in case of invalid SIAR */
+ if (perf_event_account_interrupt(event))
+ power_pmu_stop(event, 0);
}
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 8/8] powerpc/perf: Fix soft lockups due to missed interrupt accounting
From: Sasha Levin @ 2020-08-24 16:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexey Kardashevskiy, Athira Rajeev, linuxppc-dev, Sasha Levin
In-Reply-To: <20200824163931.607291-1-sashal@kernel.org>
From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]
Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().
Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.
But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.
Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/perf/core-book3s.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index ba49ae6625f1b..a10b67df83bae 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2042,6 +2042,10 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
if (perf_event_overflow(event, &data, regs))
power_pmu_stop(event, 0);
+ } else if (period) {
+ /* Account for interrupt in case of invalid SIAR */
+ if (perf_event_account_interrupt(event))
+ power_pmu_stop(event, 0);
}
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 6/6] powerpc/perf: Fix soft lockups due to missed interrupt accounting
From: Sasha Levin @ 2020-08-24 16:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexey Kardashevskiy, Athira Rajeev, linuxppc-dev, Sasha Levin
In-Reply-To: <20200824163943.607406-1-sashal@kernel.org>
From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]
Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().
Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.
But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.
Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/perf/core-book3s.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 30e2e8efbe6b7..aab13558e9700 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2040,6 +2040,10 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
if (perf_event_overflow(event, &data, regs))
power_pmu_stop(event, 0);
+ } else if (period) {
+ /* Account for interrupt in case of invalid SIAR */
+ if (perf_event_account_interrupt(event))
+ power_pmu_stop(event, 0);
}
}
--
2.25.1
^ permalink raw reply related
* Re: Re：Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero
From: Segher Boessenkool @ 2020-08-24 18:17 UTC (permalink / raw)
To: Guohua Zhong
Cc: wangle6, gregkh, linuxppc-dev, linux-kernel, paulus, stable,
nixiaoming
In-Reply-To: <20200824115407.55896-1-zhongguohua1@huawei.com>
On Mon, Aug 24, 2020 at 07:54:07PM +0800, Guohua Zhong wrote:
> >> Yet, I have noticed that there is no checking of 'base' in these functions.
> >> But I am not sure how to check is better.As we know that the result is
> >> undefined when divisor is zero. It maybe good to print error and dump stack.
> >> Let the process to know that the divisor is zero by sending SIGFPE.
>
> > That is now what the PowerPC integer divide insns do: they just leave
> > the result undefined (and they can set the overflow flag then, but no
> > one uses that).
>
> OK ,So just keep the patch as below. If this patch looks good for you, please
> help to review. I will send the new patch later.
>
> Thanks for your reply.
>
> diff --git a/arch/powerpc/boot/div64.S b/arch/powerpc/boot/div64.S
> index 4354928ed62e..1d3561cf16fa 100644
> --- a/arch/powerpc/boot/div64.S
> +++ b/arch/powerpc/boot/div64.S
> @@ -13,8 +13,10 @@
>
> .globl __div64_32
> .globl __div64_32
> __div64_32:
> + cmplwi r4,0 # check if divisor r4 is zero
> lwz r5,0(r3) # get the dividend into r5/r6
> lwz r6,4(r3)
> + beq 5f # jump to label 5 if r4(divisor) is zero
Just "beqlr".
This instruction scheduling hurts all CPUs that aren't 8xx, fwiw (but
likely only in the case where r4 *is* zero, so who cares :-) )
So... What is the *goal* of this patch? It looks like the routine
would not get into a loop if r4 is 0, just return the wrong result?
But, it *always* will, there *is* no right result?
No caller should call it with zero as divisor ever, so in that sense,
checking for it in the division routine is just pure wasted work.
Segher
^ permalink raw reply
* RE: [PATCH v2] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe
From: Leo Li @ 2020-08-24 18:46 UTC (permalink / raw)
To: Ye Bin, linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20200824084234.232179-1-yebin10@huawei.com>
> -----Original Message-----
> From: Ye Bin <yebin10@huawei.com>
> Sent: Monday, August 24, 2020 3:43 AM
> To: Leo Li <leoyang.li@nxp.com>; linux-usb@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Cc: Ye Bin <yebin10@huawei.com>
> Subject: [PATCH v2] usb: gadget: fsl: Fix unsigned expression compared with
> zero in fsl_udc_probe
>
> udc_controller->irq is "unsigned int" always >= 0, but platform_get_irq may
> return little than zero. So "dc_controller->irq < 0" condition is never
> accessible.
>
> Signed-off-by: Ye Bin <yebin10@huawei.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
> ---
> drivers/usb/gadget/udc/fsl_udc_core.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
> b/drivers/usb/gadget/udc/fsl_udc_core.c
> index a6f7b2594c09..3e98740b8cfc 100644
> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -2439,11 +2439,12 @@ static int fsl_udc_probe(struct platform_device
> *pdev)
> /* DEN is bidirectional ep number, max_ep doubles the number */
> udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK)
> * 2;
>
> - udc_controller->irq = platform_get_irq(pdev, 0);
> - if (udc_controller->irq <= 0) {
> - ret = udc_controller->irq ? : -ENODEV;
> + ret = platform_get_irq(pdev, 0);
> + if (ret <= 0) {
> + ret = ret ? : -ENODEV;
> goto err_iounmap;
> }
> + udc_controller->irq = ret;
>
> ret = request_irq(udc_controller->irq, fsl_udc_irq, IRQF_SHARED,
> driver_name, udc_controller);
> --
> 2.25.4
^ permalink raw reply
* Re: [GIT PULL] fallthrough pseudo-keyword macro conversions for 5.9-rc3
From: Nathan Chancellor @ 2020-08-24 19:43 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: linuxppc-dev, Linus Torvalds, Kees Cook,
Linux Kernel Mailing List
In-Reply-To: <20200824034841.GA29995@embeddedor>
On Sun, Aug 23, 2020 at 10:48:41PM -0500, Gustavo A. R. Silva wrote:
> Hi Linus,
>
> Not sure what the problem was with my pull-request for -rc2. So, I'm giving
> this a second try because I think it is worth it.
>
> I have build-tested this patch on 10 different architectures: x86_64, i386,
> arm64, powerpc, s390, sparc64, sh, m68k, powerpc64 and alpha (allyesconfig/
> allmodconfig for all of them). This is in linux-next already and kernel
> test robot has also helped me to successfully build-test early versions
> of this patch[2][3][4][5]. This patch does not introduce any new warnings.
>
> Thank you
> --
> Gustavo
>
> [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> [2] https://lore.kernel.org/lkml/5f3cc99a.HgvOW3rH0mD0RmkM%25lkp@intel.com/
> [3] https://lore.kernel.org/lkml/5f3dd1d2.l1axczH+t4hMBZ63%25lkp@intel.com/
> [4] https://lore.kernel.org/lkml/5f3e977a.mwYHUIObbR4SHr0B%25lkp@intel.com/
> [5] https://lore.kernel.org/lkml/5f3f9e1c.qsyb%2FaySkiXNpkO4%25lkp@intel.com/
>
>
> The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
>
> Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git tags/fallthrough-pseudo-keyword-5.9-rc3
>
> for you to fetch changes up to df561f6688fef775baa341a0f5d960becd248b11:
>
> treewide: Use fallthrough pseudo-keyword (2020-08-23 17:36:59 -0500)
>
> ----------------------------------------------------------------
> fallthrough pseudo-keyword macro conversions for 5.9-rc3
>
> Hi Linus,
>
> Please, pull the following tree-wide patch that replaces tons (2484) of
> /* fall through */ comments, and its variants, with the new pseudo-keyword
> macro fallthrough[1]. Also, remove unnecessary fall-through markings when
> it is the case.
>
> There are currently 1167 intances of this fallthrough pseudo-keyword
> macro in mainline (5.9-rc2), that have been introduced over the last
> couple of development cycles:
>
> $ git grep -nw 'fallthrough;' | wc -l
> 1167
>
> The global adoption of the fallthrough pseudo-keyword is something certain
> to happen; so, better sooner than later. :) This will also save everybody's
> time and thousands of lines of unnecessarily repetitive changelog text.
>
> After applying this patch on top of 5.9-rc2, we'll have a total of 3651
> instances of this macro:
>
> $ git grep -nw 'fallthrough;' | wc -l
> 3651
>
> This treewide patch doesn't address ALL fall-through markings in all
> subsystems at once because I have previously sent out patches for some of
> such subsystems separately, and I will follow up on them; however, this
> definitely contributes most of the work needed to replace all the
> fall-through markings with the fallthrough pseudo-keyword macro in the
> whole codebase.
>
> I have build-tested this patch on 10 different architectures: x86_64, i386,
> arm64, powerpc, s390, sparc64, sh, m68k, powerpc64 and alpha (allyesconfig
> for all of them). This is in linux-next already and kernel test robot has
> also helped me to successfully build-test early versions of this
> patch[2][3][4][5].
>
> Thanks
> --
> [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> [2] https://lore.kernel.org/lkml/5f3cc99a.HgvOW3rH0mD0RmkM%25lkp@intel.com/
> [3] https://lore.kernel.org/lkml/5f3dd1d2.l1axczH+t4hMBZ63%25lkp@intel.com/
> [4] https://lore.kernel.org/lkml/5f3e977a.mwYHUIObbR4SHr0B%25lkp@intel.com/
> [5] https://lore.kernel.org/lkml/5f3f9e1c.qsyb%2FaySkiXNpkO4%25lkp@intel.com/
>
> ----------------------------------------------------------------
> Gustavo A. R. Silva (1):
> treewide: Use fallthrough pseudo-keyword
$ scripts/config --file arch/powerpc/configs/powernv_defconfig -e KERNEL_XZ
$ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc64le-linux- distclean powernv_defconfig zImage
...
In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:234,
from arch/powerpc/boot/decompress.c:38:
arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c: In function 'dec_main':
arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:586:4: error: 'fallthrough' undeclared (first use in this function)
586 | fallthrough;
| ^~~~~~~~~~~
arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:586:4: note: each undeclared identifier is reported only once for each function it appears in
In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:235,
from arch/powerpc/boot/decompress.c:38:
arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c: In function 'xz_dec_lzma2_run':
arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c:1046:4: error: 'fallthrough' undeclared (first use in this function)
1046 | fallthrough;
| ^~~~~~~~~~~
make[2]: *** [arch/powerpc/boot/Makefile:215: arch/powerpc/boot/decompress.o] Error 1
make[2]: Target 'arch/powerpc/boot/zImage' not remade because of errors.
make[1]: *** [arch/powerpc/Makefile:295: zImage] Error 2
make: *** [Makefile:335: __build_one_by_one] Error 2
make: Target 'distclean' not remade because of errors.
make: Target 'powernv_defconfig' not remade because of errors.
make: Target 'zImage' not remade because of errors.
This will end up affecting distribution configurations such as Debian
and OpenSUSE according to my testing. I am not sure what the solution
is, the PowerPC wrapper does not set -D__KERNEL__ so I am not sure that
compiler_attributes.h can be safely included. Adding Michael and
linuxppc-dev to CC.
Cheers,
Nathan
^ permalink raw reply
* Re: [GIT PULL] fallthrough pseudo-keyword macro conversions for 5.9-rc3
From: Gustavo A. R. Silva @ 2020-08-24 20:04 UTC (permalink / raw)
To: Nathan Chancellor, Gustavo A. R. Silva
Cc: linuxppc-dev, Linus Torvalds, Kees Cook,
Linux Kernel Mailing List
In-Reply-To: <20200824194335.GA4082027@ubuntu-n2-xlarge-x86>
Hi Nathan,
On 8/24/20 14:43, Nathan Chancellor wrote:
>> Gustavo A. R. Silva (1):
>> treewide: Use fallthrough pseudo-keyword
>
> $ scripts/config --file arch/powerpc/configs/powernv_defconfig -e KERNEL_XZ
>
> $ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc64le-linux- distclean powernv_defconfig zImage
> ...
> In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:234,
> from arch/powerpc/boot/decompress.c:38:
> arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c: In function 'dec_main':
> arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:586:4: error: 'fallthrough' undeclared (first use in this function)
> 586 | fallthrough;
> | ^~~~~~~~~~~
> arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:586:4: note: each undeclared identifier is reported only once for each function it appears in
> In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:235,
> from arch/powerpc/boot/decompress.c:38:
> arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c: In function 'xz_dec_lzma2_run':
> arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c:1046:4: error: 'fallthrough' undeclared (first use in this function)
> 1046 | fallthrough;
> | ^~~~~~~~~~~
> make[2]: *** [arch/powerpc/boot/Makefile:215: arch/powerpc/boot/decompress.o] Error 1
> make[2]: Target 'arch/powerpc/boot/zImage' not remade because of errors.
> make[1]: *** [arch/powerpc/Makefile:295: zImage] Error 2
> make: *** [Makefile:335: __build_one_by_one] Error 2
> make: Target 'distclean' not remade because of errors.
> make: Target 'powernv_defconfig' not remade because of errors.
> make: Target 'zImage' not remade because of errors.
>
> This will end up affecting distribution configurations such as Debian
> and OpenSUSE according to my testing. I am not sure what the solution
> is, the PowerPC wrapper does not set -D__KERNEL__ so I am not sure that
> compiler_attributes.h can be safely included. Adding Michael and
> linuxppc-dev to CC.
>
Thanks for the report. I think, for now, the best solution is to
use /* fall through */ comments instead of the pseudo-keyword in
lib/
I'll send a fix for that right away.
Thanks
--
Gustavo
^ permalink raw reply
* [Bug 208957] 5.9-rc1 fails to build for a PowerMac G5: .../book3s64/hash_utils.c:1119:21: error: ‘default_uamor’ undeclared (first use in this function) 1119 | mtspr(SPRN_UAMOR, default_uamor);
From: bugzilla-daemon @ 2020-08-24 20:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-208957-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=208957
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE
--- Comment #1 from Erhard F. (erhard_f@mailbox.org) ---
5.9-rc2 builds again with the same config.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: fsl_espi errors on v5.7.15
From: Chris Packham @ 2020-08-24 22:04 UTC (permalink / raw)
To: Heiner Kallweit, broonie@kernel.org, mpe@ellerman.id.au,
benh@kernel.crashing.org, paulus@samba.org,
tiago.brusamarello@datacom.ind.br
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org
In-Reply-To: <0ff80ebb-e6ae-d8e1-9f0d-8759b2556141@alliedtelesis.co.nz>
On 20/08/20 9:08 am, Chris Packham wrote:
>
> On 19/08/20 6:15 pm, Heiner Kallweit wrote:
>> On 19.08.2020 00:44, Chris Packham wrote:
>>> Hi Again,
>>>
>>> On 17/08/20 9:09 am, Chris Packham wrote:
>>>
>>>> On 14/08/20 6:19 pm, Heiner Kallweit wrote:
>>>>> On 14.08.2020 04:48, Chris Packham wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm seeing a problem with accessing spi-nor after upgrading a T2081
>>>>>> based system to linux v5.7.15
>>>>>>
>>>>>> For this board u-boot and the u-boot environment live on spi-nor.
>>>>>>
>>>>>> When I use fw_setenv from userspace I get the following kernel logs
>>>>>>
>>>>>> # fw_setenv foo=1
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>>>> fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
>>>>>> fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>>>>> fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
>>>>>> fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>>>>> fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
>>>>>> fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>>>>> ...
>>>>>>
>>>>> This error reporting doesn't exist yet in 4.4. So you may have an
>>>>> issue
>>>>> under 4.4 too, it's just not reported.
>>>>> Did you verify that under 4.4 fw_setenv actually has an effect?
>>>> Just double checked and yes under 4.4 the setting does get saved.
>>>>>> If I run fw_printenv (before getting it into a bad state) it is
>>>>>> able to
>>>>>> display the content of the boards u-boot environment.
>>>>>>
>>>>> This might indicate an issue with spi being locked. I've seen related
>>>>> questions, just use the search engine of your choice and check for
>>>>> fw_setenv and locked.
>>>> I'm running a version of fw_setenv which includes
>>>> https://gitlab.denx.de/u-boot/u-boot/-/commit/db820159 so it shouldn't
>>>> be locking things unnecessarily.
>>>>>> If been unsuccessful in producing a setup for bisecting the
>>>>>> issue. I do
>>>>>> know the issue doesn't occur on the old 4.4.x based kernel but
>>>>>> that's
>>>>>> probably not much help.
>>>>>>
>>>>>> Any pointers on what the issue (and/or solution) might be.
>>> I finally managed to get our board running with a vanilla kernel. With
>>> corenet64_smp_defconfig I occasionally see
>>>
>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>
>>> other than the message things seem to be working.
>>>
>>> With a custom defconfig I see
>>>
>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't
>>> empty!
>>> fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>> ...
>>>
>>> and access to the spi-nor does not work until the board is reset.
>>>
>>> I'll try and pick apart the differences between the two defconfigs.
>
> I now think my earlier testing is invalid. I have seen the problem
> with either defconfig if I try hard enough. I had convinced myself
> that the problem was CONFIG_PREEMPT but that was before I found
> boot-to-boot differences with the same kernel.
>
> It's possible that I'm chasing multiple issues with the same symptom.
>
> The error I'm most concerned with is in the sequence
> 1. boot with old image
> 2. write environment
> 3. boot with new image
> 4. write environment
> 5. write fails and environment is corrupted
>
> After I recover the system things sometimes seem fine. Until I repeat
> the sequence above.
>
>> Also relevant may be:
>> - Which dts are you using?
> Custom but based heavily on the t2080rdb.
>> - What's the spi-nor type, and at which frequency are you operating it?
> The board has several alternate parts for the spi-nor so the dts just
> specifies compatible = "jedec,spi-nor" the actual chip detected on the
> board I have is "n25q032a (4096 Kbytes)". The dts sets
> spi-max-frequency = <10000000> I haven't measured the actual frequency
> on the bus.
>> - Does the issue still happen if you lower the frequency?
> I did play around with the frequency initially but I should probably
> give that another go now that I have a better reproduction method.
Playing around with the frequency didn't help.
One thing that I've found is that the problem appears to be that I end
up with extra bytes in the RX FIFO. If I add code to drain the RX FIFO
then the system is able to keep accessing the spi-nor (albeit with some
noisy logs).
^ permalink raw reply
* [Bug 209029] New: kernel 5.9-rc2 fails to boot on a PowerMac G5 11, 2 - BUG: Kernel NULL pointer dereference on read at 0x00000020
From: bugzilla-daemon @ 2020-08-24 22:49 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=209029
Bug ID: 209029
Summary: kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 -
BUG: Kernel NULL pointer dereference on read at
0x00000020
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.9-rc2
Hardware: PPC-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-64
Assignee: platform_ppc-64@kernel-bugs.osdl.org
Reporter: erhard_f@mailbox.org
Regression: No
Created attachment 292153
--> https://bugzilla.kernel.org/attachment.cgi?id=292153&action=edit
kernel .config (kernel 5.9-rc2, PowerMac G5 11,2)
Transcribed the stacktrace from a screenshot with my camera:
[...]
REGS: c00000047d0d7850 TRAP: 0700 Tainted: G W
(5.9.0-rc2-PowerMacG5)
MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 44000448 XER: 200fffff
IRQMASK: 0
GPR00: c000000000af853c c00000047d0d7ae0 c000000000d17300 0000000000000001
GPR04: 00001ccccf255000 c00000047b5c92a8 0000000000000001 0000000000000000
GPR08: c000000000000000 0000000000000001 3fffffffffffffff 4000000000000000
GPR12: 0000000024000448 c00000000ffffc80 c00000000000fd78 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000c3e000 c000000000c3e307 c000000000d83b90 c000300000030f80
GPR24: c000000000d83c28 0000000000000c00 c00000047b5c74b0 8000000000000105
GPR28: ee1fffffffffffbf c00000047d64f800 00001ccccf255000 00001ccccf255000
NIP [c000000000af8568] .debug_um_pgtable+0x884/0xa20
LR [c000000000af853c] .debug_vm_pgtable+0x858/0xa20
Call Trace:
[c00000047d0d7ae0] [c000000000af853c] .debug_vm_pgtable++0x858/0xa20
(unreliable)
[c00000047d0d7be0] [c00000000000f62c] .do_one_initcall+0x60/0x344
[c00000047d0d7cc0] [c000000000ad8d64] .kerne]_init_freeable+0x3c0/0x3f4
[c00000047d0d7db0] [c00000000000fd88] .kernel_init+0x10/0x130
[c00000047d0d7e20] [c00000000000b9d8] .ret_from_kerne!_thread+0x58/0x60
Instruction dump:
4b53b145 60000000 e8df0000 7f863278 3f80ee1f 639cffff 7b9c07c6 679cffff
639cffbf 7cc6e038 3146ffff 7cca3110 <0b060000> 39000000 38e00000 38c0ffff
irg event stamp: 369
hardirgs last enabled at (369): [<c0000000000cd624>]
.console_unlock+0x650/0x664
hardirgs last disabled at (366): [<c0000000000cd144>]
.console_unlock+0x170/0x664
softirgs last enabled at (0): [<c00000000005ff38>] .copy_process+0x69c/0x1510
softirgs last disabled at (0): [<0000000000000000>] 0x0
---[ end trace 0561544ca9dc6c57 ]---
BUG: Kernel NULL pointer dereference on read at 0x00000020
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Faulting instruction address: 0xc000000000033924
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=4 NUMA PowerMac
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.9.0-rc2-PowerMacG5
#2
NIP: c000000000033924 LR: c0000000000338e4 CTR: 0000000000000000
REGS: c00000047d0d77a0 TRAP: 0380 Tainted: G W
(5.9.0-rc2-PowerMacG5)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 44000448 XER: 200fffff
IRQMASK: 0
GPR00: c0000000000338e4 c00000047d0d7a30 c000000000d17300 c00000047d0d7aa8
GPR04: 8000000000c3e387 0000000000000001 8000000000c3e387 0000000000000001
GPR08: c000000000000000 0000000000000000 c000000000d83d48 0000000000000000
GPR12: 0000000024000448 c00000000ffffc80 c00000000000fd78 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000c3e000 c000000000c3e307 c000000000d83b90 c000300000030f80
GPR24: c000000000d83c28 0000000000000c00 c00000047b5c74b0 8000000000000105
GPR28: c00000047b5c74b0 0000000000000001 8000000000c3e387 c00000047b5c92a8
NIP [c000000000033924] .huge_ptep_set_access_flags+0x70/0x114
LR [c0000000000338e4] .huge_ptep_set_access_flags+0x30/0x114
Call Trace:
[c00000047d0d7a30] [c0000000000338e4] .huge_ptep_set_access_flags+0x30/0x114
(unreliable)
[c00000047d0d7ae0] [c000000000af86b4] .debug_vm_pgtable++0x9d0/0xa20
[c00000047d0d7be0] [c00000000000f62c] .do_one_initcall+0x60/0x344
[c00000047d0d7cc0] [c000000000ad8d64] .kerne]_init_freeable+0x3c0/0x3f4
[c00000047d0d7db0] [c00000000000fd88] .kernel_init+0x10/0x130
[c00000047d0d7e20] [c00000000000b9d8] .ret_from_kerne!_thread+0x58/0x60
Instruction dump:
794a07c6 654affff 7fc94a78 614affbf 7d295038 2c290000 33a9ffff 7fbd4910
4182008c e93c00a0 3d420007 394aca48 <e9290020> 810a0268 e9290028 e9290648
---[ end trace 0561544ca9dc6c58 ]---
note: swapper/0[1] exited with preempt_count 1
ata2.00: ATA-8: WDC WD5000BPKX-22HPJT0, 01.01A01, max UDMA/133
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
Rebooting in 120 seconds..
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 209029] kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 - BUG: Kernel NULL pointer dereference on read at 0x00000020
From: bugzilla-daemon @ 2020-08-24 22:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-209029-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=209029
--- Comment #1 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 292155
--> https://bugzilla.kernel.org/attachment.cgi?id=292155&action=edit
dmesg screenshot
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [PATCH net] ibmvnic fix NULL tx_pools and rx_tools issue at do_reset
From: Dany Madden @ 2020-08-24 23:49 UTC (permalink / raw)
To: davem; +Cc: Dany Madden, netdev, Mingming Cao, linuxppc-dev
From: Mingming Cao <mmc@linux.vnet.ibm.com>
At the time of do_reset, ibmvnic tries to re-initalize the tx_pools
and rx_pools to avoid re-allocating the long term buffer. However
there is a window inside do_reset that the tx_pools and
rx_pools were freed before re-initialized making it possible to deference
null pointers.
This patch fixes this issue by checking that the tx_pool
and rx_pool are not NULL after ibmvnic_login. If so, re-allocating
the pools. This will avoid getting into calling reset_tx/rx_pools with
NULL adapter tx_pools/rx_pools pointer. Also add null pointer check in
reset_tx_pools and reset_rx_pools to safe handle NULL pointer case.
Signed-off-by: Mingming Cao <mmc@linux.vnet.ibm.com>
Signed-off-by: Dany Madden <drt@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 5afb3c9c52d2..5ff48e55308b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -479,6 +479,9 @@ static int reset_rx_pools(struct ibmvnic_adapter *adapter)
int i, j, rc;
u64 *size_array;
+ if (!adapter->tx_pool)
+ return -1;
+
size_array = (u64 *)((u8 *)(adapter->login_rsp_buf) +
be32_to_cpu(adapter->login_rsp_buf->off_rxadd_buff_size));
@@ -649,6 +652,9 @@ static int reset_tx_pools(struct ibmvnic_adapter *adapter)
int tx_scrqs;
int i, rc;
+ if (!adapter->tx_pool)
+ return -1;
+
tx_scrqs = be32_to_cpu(adapter->login_rsp_buf->num_txsubm_subcrqs);
for (i = 0; i < tx_scrqs; i++) {
rc = reset_one_tx_pool(adapter, &adapter->tso_pool[i]);
@@ -2011,7 +2017,10 @@ static int do_reset(struct ibmvnic_adapter *adapter,
adapter->req_rx_add_entries_per_subcrq !=
old_num_rx_slots ||
adapter->req_tx_entries_per_subcrq !=
- old_num_tx_slots) {
+ old_num_tx_slots ||
+ !adapter->rx_pool ||
+ !adapter->tso_pool ||
+ !adapter->tx_pool) {
release_rx_pools(adapter);
release_tx_pools(adapter);
release_napi(adapter);
@@ -2024,10 +2033,14 @@ static int do_reset(struct ibmvnic_adapter *adapter,
} else {
rc = reset_tx_pools(adapter);
if (rc)
+ netdev_dbg(adapter->netdev, "reset tx pools failed (%d)\n",
+ rc);
goto out;
rc = reset_rx_pools(adapter);
if (rc)
+ netdev_dbg(adapter->netdev, "reset rx pools failed (%d)\n",
+ rc);
goto out;
}
ibmvnic_disable_irqs(adapter);
--
2.18.2
^ permalink raw reply related
* [PATCH] powerpc/boot: Update Makefile comment for 64bit wrapper
From: Jordan Niethe @ 2020-08-25 3:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jordan Niethe
As of commit 147c05168fc8 ("powerpc/boot: Add support for 64bit little
endian wrapper") the comment in the Makefile is misleading. The wrapper
packaging 64bit kernel may built as a 32 or 64 bit elf. Update the
comment to reflect this.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
arch/powerpc/boot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index b88fd27a45f0..f8ce6d2dde7b 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -7,7 +7,7 @@
# Based on coffboot by Paul Mackerras
# Simplified for ppc64 by Todd Inglett
#
-# NOTE: this code is built for 32 bit in ELF32 format even though
+# NOTE: this code may be built for 32 bit in ELF32 format even though
# it packages a 64 bit kernel. We do this to simplify the
# bootloader and increase compatibility with OpenFirmware.
#
--
2.17.1
^ permalink raw reply related
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