32 bits BOOKE have special interrupts for debug and other
critical events.
When handling those interrupts, dedicated registers are saved
in the stack frame in addition to the standard registers, leading
to a shift of the pt_regs struct.
Since commit db297c3b07af ("powerpc/32: Don't save
On 7/7/21 12:45 AM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jul 06, 2021 at 05:26:12PM +0530, kajoljain escreveu:
>>
>>
>> On 6/29/21 12:39 PM, kajoljain wrote:
>>>
>>>
>>> On 6/28/21 8:19 PM, Paul A. Clarke wrote:
On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
> Commit
Currently it is vm-$currentpid which works as long as there is just one
VM per the userspace (99.99% cases) but produces a bunch
of "debugfs: Directory 'vm16679' with parent 'kvm' already present!"
when syzkaller (syscall fuzzer) is running so only one VM is present in
the debugfs for a given
@@ -763,6 +771,14 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
/* dst = *(u16 *)(ul) (src + off) */
case BPF_LDX | BPF_MEM | BPF_H:
case BPF_LDX | BPF_PROBE_MEM | BPF_H:
+ if (BPF_MODE(code) == BPF_PROBE_MEM) {
+
On 7/6/21 3:23 PM, Christophe Leroy wrote:
Le 06/07/2021 à 09:32, Ravi Bangoria a écrit :
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Can you do the same for 32bit ?
Sure. But before
allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20210706
i386 randconfig-a006-20210706
i386 randconfig-a001-20210706
i386 randconfig-a003-20210706
allnoconfig
i386 randconfig-a004-20210706
i386 randconfig-a006-20210706
i386 randconfig-a001-20210706
i386 randconfig-a003-20210706
i386 randconfig-a005-20210706
i386 randconfig-a002
On Tue, Jul 6, 2021 at 8:51 AM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return
Hello,
v1 was acked by some more after I stopped looking in my mailbox while
preparing v2:
On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is
On Tue, 2021-07-06 at 17:48 +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because
> there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return
On Tue, Jul 6, 2021 at 5:53 PM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return
Hello,
compared to (implicit) v1 that I sent earlier today
(https://lore.kernel.org/r/20210706095037.1425211-1-u.kleine-koe...@pengutronix.de)
the following is changed:
- Add three more patches preparing some s390 specific busses
and adapt them in the last patch. Thanks to Cornelia Huck for
On Tue, Jul 06 2021, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were
Uwe Kleine-König writes:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their remove callback.
>
On Tue, 6 Jul 2021 at 03:56, Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void
On Tue, Jul 6, 2021 at 12:50 PM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return
On 7/6/21 2:50 AM, Uwe Kleine-König wrote:
> --- a/arch/powerpc/platforms/ps3/system-bus.c
> +++ b/arch/powerpc/platforms/ps3/system-bus.c
> @@ -381,7 +381,7 @@ static int ps3_system_bus_probe(struct device *_dev)
> return result;
> }
>
> -static int ps3_system_bus_remove(struct device
On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also
On Tue 06 Jul 13:43 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Tue, Jul 06, 2021 at 01:08:18PM -0500, Bjorn Andersson wrote:
> > On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> > > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > > index
Em Tue, Jul 06, 2021 at 05:26:12PM +0530, kajoljain escreveu:
>
>
> On 6/29/21 12:39 PM, kajoljain wrote:
> >
> >
> > On 6/28/21 8:19 PM, Paul A. Clarke wrote:
> >> On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
> >>> Commit 48a1f565261d ("perf script python: Add more PMU fields
>
Hi Will and Robin,
On 7/6/2021 10:06 AM, Will Deacon wrote:
On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote:
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something
Hello Bjorn,
On Tue, Jul 06, 2021 at 01:08:18PM -0500, Bjorn Andersson wrote:
> On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > index c1404d3dae2c..7f6fac618ab2 100644
> > --- a/drivers/rpmsg/rpmsg_core.c
> > +++
On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void
On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote:
> On 2021-07-06 15:05, Christoph Hellwig wrote:
> > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > FWIW I was pondering the question of whether to do something along those
> > > lines or just scrap the default
On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
> On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > > FWIW I was
Happy to help, Christian :)
Nirmoy
On 7/6/2021 5:33 PM, Christian Zigotzky wrote:
Hi Nirmoy,
This patch works! Thanks a lot! We tested it on an A-EON AmigaOne
X5000/20 today.
Screenshot:
On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > FWIW I was pondering the question of whether to do something along those
> > > lines
On 06.07.21 11:50, Uwe Kleine-König wrote:
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead
Hi Nirmoy,
This patch works! Thanks a lot! We tested it on an A-EON AmigaOne
X5000/20 today.
Screenshot:
http://www.skateman.nl/wp-content/uploads/2021/07/Screenshot-at-2021-07-06-113237.png
Cheers,
Christian
On 05 July 2021 at 06:48 pm, Christian Zigotzky wrote:
Hi Nirmoy,
Many thanks
Hi Nick,
Your patch works (see patch below)! Many thanks for your help! We tested
it on an A-EON AmigaOne X5000/20 and in a virtual e5500 QEMU machine today.
Screenshots:
-
http://www.skateman.nl/wp-content/uploads/2021/07/Screenshot-at-2021-07-06-113237.png
-
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > FWIW I was pondering the question of whether to do something along those
> > lines or just scrap the default assignment entirely, so since I hadn't got
> > round
Le 06/07/2021 à 16:05, Radu Rendec a écrit :
On Tue, 2021-07-06 at 15:53 +0200, Christophe Leroy wrote:
Le 06/07/2021 à 15:50, Radu Rendec a écrit :
On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
Le 06/07/2021 à 13:56, Radu Rendec a écrit :
On Tue, 2021-07-06 at 12:43 +0200,
On Tue, 2021-07-06 at 15:53 +0200, Christophe Leroy wrote:
>Le 06/07/2021 à 15:50, Radu Rendec a écrit :
>> On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
>>> Le 06/07/2021 à 13:56, Radu Rendec a écrit :
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
> Le
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> FWIW I was pondering the question of whether to do something along those
> lines or just scrap the default assignment entirely, so since I hadn't got
> round to saying that I've gone ahead and hacked up the alternative
> (similarly
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
Le 06/07/2021 à 15:50, Radu Rendec a écrit :
On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
Le 06/07/2021 à 13:56, Radu Rendec a écrit :
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
Le 04/07/2021 à 23:38, Radu Rendec a écrit :
I'm trying to set up my (virtual)
On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
>Le 06/07/2021 à 13:56, Radu Rendec a écrit :
>> On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
>>> Le 04/07/2021 à 23:38, Radu Rendec a écrit :
I'm trying to set up my (virtual) environment to test an old bug in the
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
> > So at this point, the AMD IOMMU driver does:
> >
> > swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
> >
> > where 'swiotlb' is a
Le 06/07/2021 à 13:56, Radu Rendec a écrit :
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
Le 04/07/2021 à 23:38, Radu Rendec a écrit :
I'm trying to set up my (virtual) environment to test an old bug in the
PPC32 ptrace() code. I came across a completely different problem,
On Tue, Jul 06, 2021 at 01:17:37PM +0200, Cornelia Huck wrote:
> On Tue, Jul 06 2021, Cornelia Huck wrote:
>
> > On Tue, Jul 06 2021, Uwe Kleine-König
> > wrote:
> >
> >> The driver core ignores the return value of this callback because there
> >> is only little it can do when a device
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also
On 7/6/21 11:50 AM, Uwe Kleine-König wrote:
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove
On Tue, Jul 06 2021, Cornelia Huck wrote:
> On Tue, Jul 06 2021, Uwe Kleine-König wrote:
>
>> The driver core ignores the return value of this callback because there
>> is only little it can do when a device disappears.
>>
>> This is the final bit of a long lasting cleanup quest where several
On 7/6/2021 3:20 PM, Uwe Kleine-König wrote:
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their
On 06/07/2021 11:50:37+0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void
On Tue, Jul 06 2021, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also
On 06-07-21, 11:50, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their
Em Tue, 6 Jul 2021 11:50:37 +0200
Uwe Kleine-König escreveu:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also
On Tuesday 06 July 2021 11:50:37 Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return
On Tue, Jul 6, 2021 at 5:54 PM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
> Le 04/07/2021 à 23:38, Radu Rendec a écrit :
> > I'm trying to set up my (virtual) environment to test an old bug in the
> > PPC32 ptrace() code. I came across a completely different problem,
> > which seems to make gdb pretty much
On 6/29/21 12:39 PM, kajoljain wrote:
>
>
> On 6/28/21 8:19 PM, Paul A. Clarke wrote:
>> On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
>>> Commit 48a1f565261d ("perf script python: Add more PMU fields
>>> to event handler dict") added functionality to report fields like
>>>
From: Lijun Pan
[ Upstream commit 73214a690c50a134bd364e1a4430e0e7ac81a8d8 ]
Fix the following kernel build warnings:
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Function parameter or member
'skb' not described in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning:
From: Lijun Pan
[ Upstream commit 73214a690c50a134bd364e1a4430e0e7ac81a8d8 ]
Fix the following kernel build warnings:
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Function parameter or member
'skb' not described in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning:
On Tue, 6 Jul 2021 15:13:10 +1000, Nicholas Piggin wrote:
> BookE does not have mtmsrd, switch to use wrteei to enable MSR[EE].
Applied to powerpc/fixes.
[1/1] powerpc/64e: Fix system call illegal mtmsrd instruction
https://git.kernel.org/powerpc/c/1df3af6dc3cfe643f43d46f202bd44861ccbdb99
On Thu, 1 Jul 2021 20:38:57 +0530, Naveen N. Rao wrote:
> The first patch fixes an issue that causes a soft lockup on ppc64 with
> the BPF_ATOMIC bounds propagation verifier test. The second one updates
> ppc32 JIT to reject atomic operations properly.
>
> - Naveen
>
> Naveen N. Rao (2):
>
On Thu, 1 Jul 2021 11:17:08 + (UTC), Christophe Leroy wrote:
> The powerpc kernel is not prepared to handle exec faults from kernel.
> Especially, the function is_exec_fault() will return 'false' when an
> exec fault is taken by kernel, because the check is based on reading
>
On Thu, 1 Jul 2021 17:24:12 +0200, Cédric Le Goater wrote:
> This is a smatch warning:
>
> arch/powerpc/sysdev/xive/common.c:1161 xive_request_ipi() warn: unsigned
> 'xid->irq' is never less than zero.
Applied to powerpc/fixes.
[1/1] powerpc/xive: Fix error handling when allocating an IPI
On 06/07/2021 12:36, Lee Jones wrote:
> On Tue, 06 Jul 2021, Uwe Kleine-König wrote:
>
>> The driver core ignores the return value of this callback because there
>> is only little it can do when a device disappears.
>>
>> This is the final bit of a long lasting cleanup quest where several
>>
Le 04/07/2021 à 23:38, Radu Rendec a écrit :
Hi Everyone,
I'm trying to set up my (virtual) environment to test an old bug in the
PPC32 ptrace() code. I came across a completely different problem,
which seems to make gdb pretty much unusable on PPC32. I'm not sure if
this is a real kernel
On Tue, 06 Jul 2021, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from
Le 06/07/2021 à 09:32, Ravi Bangoria a écrit :
On PowerPC with KUAP enabled, any kernel code which wants to
access userspace needs to be surrounded by disable-enable KUAP.
But that is not happening for BPF_PROBE_MEM load instruction.
So, when BPF program tries to access invalid userspace
Le 06/07/2021 à 09:32, Ravi Bangoria a écrit :
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Can you do the same for 32bit ?
Unlike other archs which uses extable 'fixup' field to pass
RFC: https://lkml.org/lkml/2021/6/4/791
PATCH v1: https://lkml.org/lkml/2021/6/16/805
Changelog v1 --> v2
Based on comments from Fabiano and Gautham, the following changes
were made:
1. Added flag attributes to fetch either single or all attributes from
the H_GET_ENERGY_SCALE_INFO HCALL
2.
Adds a generic interface to represent the energy and frequency related
PAPR attributes on the system using the new H_CALL
"H_GET_ENERGY_SCALE_INFO".
H_GET_EM_PARMS H_CALL was previously responsible for exporting this
information in the lparcfg, however the H_GET_EM_PARMS H_CALL
will be deprecated
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on next-20210701]
[cannot apply to v5.13]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as
On PowerPC with KUAP enabled, any kernel code which wants to
access userspace needs to be surrounded by disable-enable KUAP.
But that is not happening for BPF_PROBE_MEM load instruction.
So, when BPF program tries to access invalid userspace address,
page-fault handler considers it as bad KUAP
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Unlike other archs which uses extable 'fixup' field to pass dest_reg
and nip, BPF exception table on PowerPC follows the generic PowerPC
exception table
In case of extra_pass, we always skips usual JIT passes. Thus
extra_pass is always false while calling bpf_jit_build_body()
and thus it can be removed.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/net/bpf_jit.h| 2 +-
arch/powerpc/net/bpf_jit_comp.c | 6 +++---
Patch #1, #2 are simple cleanup patches. Patch #3 adds
BPF_PROBE_MEM support with PowerPC 64bit JIT compiler.
Patch #4 adds explicit addr > TASK_SIZE_MAX check to
handle bad userspace pointers.
Ravi Bangoria (4):
bpf powerpc: Remove unused SEEN_STACK
bpf powerpc: Remove extra_pass from
SEEN_STACK is unused on PowerPC. Remove it. Also, have
SEEN_TAILCALL use 0x4000.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/net/bpf_jit.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index
On 6/23/21 4:46 PM, Michael Ellerman wrote:
> Peter Zijlstra writes:
>> On Wed, Jun 23, 2021 at 01:40:38PM +0530, kajoljain wrote:
>>>
>>> On 6/22/21 6:44 PM, Peter Zijlstra wrote:
On Thu, Jun 17, 2021 at 06:56:13PM +0530, Kajol Jain wrote:
> ---
> Kajol Jain (4):
>
78 matches
Mail list logo
