to be at the
> > same place all the time.
> >
> > Instead of handling a special struct in addition to pt_regs, just
> > add those special registers to struct pt_regs.
> >
> > Reported-by: Radu Rendec
> > Signed-off-by: Christophe Leroy
> > Fixe
On Fri, 2021-06-11 at 10:37 -0400, Radu Rendec wrote:
>On Fri, 2021-06-11 at 08:02 +0200, Christophe Leroy wrote:
>>Le 19/06/2019 à 14:57, Radu Rendec a écrit :
>>> On Wed, 2019-06-19 at 10:36 +1000, Daniel Axtens wrote:
>>>> Andreas Schwab <
>>>> sch.
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, Christop
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) en
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 see
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 bug or maybe something wrong with my
configuration.
On Fri, 2021-06-11 at 08:02 +0200, Christophe Leroy wrote:
>Le 19/06/2019 à 14:57, Radu Rendec a écrit :
>> On Wed, 2019-06-19 at 10:36 +1000, Daniel Axtens wrote:
>>> Andreas Schwab <
>>> sch...@linux-m68k.org
>>>> writes:
>>>
>>&g
On 02/20/2020 at 12:48 PM Christophe Leroy wrote:
> Le 20/02/2020 à 18:34, Radu Rendec a écrit :
> > On 02/20/2020 at 11:25 AM Christophe Leroy wrote:
> >> Le 20/02/2020 à 17:02, Radu Rendec a écrit :
> >>> On 02/20/2020 at 3:38 AM Christophe Leroy wrote:
>
On 02/20/2020 at 11:25 AM Christophe Leroy wrote:
> Le 20/02/2020 à 17:02, Radu Rendec a écrit :
> > On 02/20/2020 at 3:38 AM Christophe Leroy wrote:
> >> On 02/19/2020 10:39 PM, Radu Rendec wrote:
> >>> On 02/19/2020 at 4:21 PM Christophe Leroy wrote:
> >>
On 02/20/2020 at 3:38 AM Christophe Leroy wrote:
> On 02/19/2020 10:39 PM, Radu Rendec wrote:
> > On 02/19/2020 at 4:21 PM Christophe Leroy wrote:
> >>> Interesting.
> >>>
> >>> 0x900 is the adress of the timer interrupt.
> >>>
> >&g
On 02/19/2020 at 4:21 PM Christophe Leroy wrote:
> > Radu Rendec a écrit :
> >> On 02/19/2020 at 10:11 AM Radu Rendec wrote:
> >>> On 02/18/2020 at 1:08 PM Christophe Leroy wrote:
> >>>> Le 18/02/2020 à 18:07, Radu Rendec a écrit :
> &
On 02/19/2020 at 10:11 AM Radu Rendec wrote:
> On 02/18/2020 at 1:08 PM Christophe Leroy wrote:
> > Le 18/02/2020 à 18:07, Radu Rendec a écrit :
> > > The saved NIP seems to be broken inside machine_check_exception() on
> > > MPC8378, running Linux 4.9.191. The value
On 02/18/2020 at 1:08 PM Christophe Leroy wrote:
> Le 18/02/2020 à 18:07, Radu Rendec a écrit :
> > The saved NIP seems to be broken inside machine_check_exception() on
> > MPC8378, running Linux 4.9.191. The value is 0x900 most of the times,
> > but I have seen other weird
Hi Everyone,
The saved NIP seems to be broken inside machine_check_exception() on
MPC8378, running Linux 4.9.191. The value is 0x900 most of the times,
but I have seen other weird values.
I've been able to track down the entry code to head_32.S (vector 0x200),
but I'm not sure where/how the NIP v
On Wed, 2019-06-19 at 10:36 +1000, Daniel Axtens wrote:
> Andreas Schwab <
> sch...@linux-m68k.org
> > writes:
>
> > On Jun 18 2019, Radu Rendec <
> > radu.ren...@gmail.com
> > > wrote:
> >
> > > Since you already have a working s
On Tue, 2019-06-18 at 16:42 +1000, Daniel Axtens wrote:
> Radu Rendec <
> radu.ren...@gmail.com
> > writes:
>
> > On Mon, 2019-06-17 at 11:19 +1000, Daniel Axtens wrote:
> > > Radu Rendec <
> > > radu.ren...@gmail.com
> > >
> > > &
On Mon, 2019-06-17 at 11:19 +1000, Daniel Axtens wrote:
> Radu Rendec <
> radu.ren...@gmail.com
> > writes:
>
> > Hi Everyone,
> >
> > I'm following up on the ptrace() problem that I reported a few days ago.
> > I believe my version of the code han
PTRACE_PEEKUSR/PTRACE_POKEUSR) seems to always read/write all FPU
registers whenever a traced task stops.
Signed-off-by: Radu Rendec
---
arch/powerpc/kernel/ptrace.c | 85 ++--
1 file changed, 52 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c
errno = 0;
ptrace (PTRACE_POKEUSER, pid,
/* Coerce to a uintptr_t first to avoid potential gcc warning
8<--
Radu Rendec (1):
PPC32: fix ptrace() access to FPU registers
arch/powerpc/kernel/ptrace.c | 85 ++--
1 file changed, 52 insertions(+), 33 deletions(-)
--
2.20.1
On Thu, 2019-06-06 at 07:15 +0200, Christophe Leroy wrote:
>
> Le 05/06/2019 à 23:45, Radu Rendec a écrit :
> > Hi Everyone,
> >
> > I'm seeing some weird memory corruption that I have been able to isolate
> > to arch_ptrace() [arch/powerpc/kernel/ptrace
out quickly what the
problem is.
Best regards,
Radu Rendec
Hi Michael,
On Wed, Nov 28, 2018 at 6:00 AM Michael Ellerman wrote:
>
> Radu Rendec writes:
> >
> > The assumption in arch_teardown_msi_irqs() is wrong and results in a
> > function call on a NULL pointer. An example of how this can happen is
> > included in the a
si_irqs() do happen (MSI descriptors are
allocated before pci_msi_setup_msi_irqs() is called and need to be
cleaned up if that fails).
Signed-off-by: Radu Rendec
---
arch/powerpc/kernel/msi.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/msi.c
nst v4.20-rc4, but I only actually tested it on
v4.9.115. On the other hand, the patch is trivial and I did check that
the NULL pointer dereference scenario is still valid on v4.20-rc4.
Best regards,
Radu Rendec
Radu Rendec (1):
Fix NULL pointer access in PowerPC MSI teardown code
arch/powerpc/kern
been any other changes to that
file up to the latest master in Linus' tree, so I believe the problem is
still there in the latest kernel.
Should commit df1024ad8728 be reapplied?
Thanks,
Radu Rendec
Hi Christophe,
On Thu, 2018-09-13 at 10:21 +0200, Christophe LEROY wrote:
>
> Le 11/09/2018 à 00:17, Radu Rendec a écrit :
> >
> > The MPC83xx also has a watchdog and the kernel driver (mpc8xxx_wdt.c)
> > could also be improved to support the WDIOC_GETBOOTSTATUS ioctl an
Hi,
On Mon, 2018-09-10 at 07:37 +0200, Christophe Leroy wrote:
> Le 10/09/2018 à 01:13, Radu Rendec a écrit :
> >
> > I'm using U-boot as well, but it's just not configured to read or clear
> > the RSR. I'm curious: if U-boot reads/clears the RSR in your c
Hi,
On Fri, 2018-08-24 at 16:20 +, Christophe Leroy wrote:
> > On 08/03/2018 04:36 PM, Radu Rendec wrote:
> >
> > Is there any kernel code that handles the "reset status register" (RSR)
> > on MPC83xx? I looked at arch/powerpc/platforms/83xx/misc.c, but
to look at it either (for
the bootstatus flags).
Basically I need to check the CPU reset reason and I thought I would ask
first, before starting to write any code of my own.
Thanks,
Radu Rendec
29 matches
Mail list logo
