On Sun, 19 Nov 2023 09:18:02 -0600, Timothy Pearson wrote:
> During floating point and vector save to thread data fr0/vs0 are clobbered
> by the FPSCR/VSCR store routine.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc: Don't clobber fr0/vs0 during fp|altivec register save
https://git.ke
- Original Message -
> From: "Michael Ellerman"
> To: "Timothy Pearson"
> Cc: "Jens Axboe" , "regressions"
> , "npiggin" ,
> "christophe leroy" , "linuxppc-dev"
>
> Sent: Tuesday, November 28,
Michael Ellerman writes:
> Timothy Pearson writes:
>
>> Just wanted to check back and see if this patch was going to be queued
>> up soon? We're still having to work around / advertise the data
>> destruction issues the underlying bug is causing on e.g. Debian
>> Stable.
>
> Yeah I'll apply it t
On Tue Nov 28, 2023 at 10:59 AM AEST, Michael Ellerman wrote:
> Christophe Leroy writes:
> > Le 27/11/2023 à 19:39, Timothy Pearson a écrit :
> >> Just wanted to check back and see if this patch was going to be
> >> queued up soon? We're still having to work around / advertise the
> >> data destr
Christophe Leroy writes:
> Le 27/11/2023 à 19:39, Timothy Pearson a écrit :
>> Just wanted to check back and see if this patch was going to be
>> queued up soon? We're still having to work around / advertise the
>> data destruction issues the underlying bug is causing on e.g. Debian
>> Stable.
>
Timothy Pearson writes:
> Just wanted to check back and see if this patch was going to be queued
> up soon? We're still having to work around / advertise the data
> destruction issues the underlying bug is causing on e.g. Debian
> Stable.
Yeah I'll apply it this week, so it will be in rc4.
I w
Hi,
Le 27/11/2023 à 19:39, Timothy Pearson a écrit :
> Just wanted to check back and see if this patch was going to be queued up
> soon? We're still having to work around / advertise the data destruction
> issues the underlying bug is causing on e.g. Debian Stable.
>
Has any agreement been re
Just wanted to check back and see if this patch was going to be queued up soon?
We're still having to work around / advertise the data destruction issues the
underlying bug is causing on e.g. Debian Stable.
Thanks!
- Original Message -
> From: "Michael Ellerman"
> To: "Timothy Pearson"
> Cc: "Jens Axboe" , "regressions"
> , "npiggin" ,
> "christophe leroy" , "linuxppc-dev"
>
> Sent: Tuesday, Novem
Timothy Pearson writes:
>
...
>
> So a little more detail on this, just to put it to rest properly vs.
> assuming hand analysis caught every possible pathway. :)
>
> The debugging that generates this stack trace also verifies the following in
> __giveup_fpu():
>
> 1.) tsk->thread.fp_state.fpr doe
gt; "christophe leroy" , "linuxppc-dev"
> >
> > Sent: Monday, November 20, 2023 5:39:52 PM
> > Subject: Re: [PATCH v2] powerpc: Don't clobber fr0/vs0 during fp|altivec
> > register save
>
> > Timothy Pearson writes:
> >>
;christophe leroy" , "linuxppc-dev"
> >
> > Sent: Monday, November 20, 2023 5:39:52 PM
> > Subject: Re: [PATCH v2] powerpc: Don't clobber fr0/vs0 during fp|altivec
> > register save
>
> > Timothy Pearson writes:
> >>
- Original Message -
> From: "Timothy Pearson"
> To: "Michael Ellerman"
> Cc: "Jens Axboe" , "regressions"
> , "npiggin" ,
> "christophe leroy" , "linuxppc-dev"
>
> Sent: Monday, Novem
- Original Message -
> From: "Michael Ellerman"
> To: "Timothy Pearson"
> Cc: "Jens Axboe" , "regressions"
> , "npiggin" ,
> "christophe leroy" , "linuxppc-dev"
>
> Sent: Monday, November 20,
- Original Message -
> From: "Michael Ellerman"
> To: "Timothy Pearson"
> Cc: "Jens Axboe" , "regressions"
> , "npiggin" ,
> "christophe leroy" , "linuxppc-dev"
>
> Sent: Monday, November 20,
On Tue Nov 21, 2023 at 9:39 AM AEST, Michael Ellerman wrote:
> Timothy Pearson writes:
> > - Original Message -
> >> From: "Michael Ellerman"
> ...
> >>
> >> But we now have a new path, because io-uring can call copy_process() via
> >> create_io_thread() from the signal handling path. Th
istophe
> > leroy" ,
> > "linuxppc-dev"
> > Sent: Monday, November 20, 2023 1:10:06 AM
> > Subject: Re: [PATCH v2] powerpc: Don't clobber fr0/vs0 during fp|altivec
> > register save
>
> > Hi Timothy,
> >
> > Great work debu
Timothy Pearson writes:
> - Original Message -
>> From: "Michael Ellerman"
...
>>
>> But we now have a new path, because io-uring can call copy_process() via
>> create_io_thread() from the signal handling path. That's OK if the signal is
>> handled as we return from a syscall, but it's n
- Original Message -
> From: "Michael Ellerman"
> To: "Timothy Pearson" , "Jens Axboe"
> , "regressions"
> , "npiggin" , "christophe
> leroy" ,
> "linuxppc-dev"
> Sent: Monday, November 20,
Yeah, awesome.
On Mon Nov 20, 2023 at 5:10 PM AEST, Michael Ellerman wrote:
> Hi Timothy,
>
> Great work debugging this. I think your fix is good, but I want to understand
> it
> a bit more to make sure I can explain why we haven't seen it outside of
> io-uring.
Analysis seems right to me.
Pro
Hi Timothy,
Great work debugging this. I think your fix is good, but I want to understand it
a bit more to make sure I can explain why we haven't seen it outside of
io-uring.
If this can be triggered outside of io-uring then I have even more backporting
in my future :}
Typically save_fpu() is ca
During floating point and vector save to thread data fr0/vs0 are clobbered
by the FPSCR/VSCR store routine. This leads to userspace register corruption
and application data corruption / crash under the following rare condition:
* A userspace thread is executing with VSX/FP mode enabled
* The us
22 matches
Mail list logo
