[RFC PATCH 2/2] ARM: VFP: preserve the HW context when calling signal handlers

[RFC PATCH 2/2] ARM: VFP: preserve the HW context when calling signal handlers

[Siarhei Siamashka]

On Monday 04 January 2010 16:25:49 ext Russell King - ARM Linux wrote:
> On Mon, Jan 04, 2010 at 04:15:26PM +0200, Siarhei Siamashka wrote:
> > On Saturday 13 June 2009 20:04:06 ext Russell King - ARM Linux wrote:
> > > - wait for a new patch which includes these other registers and not
> > > have any ABI visible changes to contend with
> >
> > Sorry for bumping this old thread, but what is the current status of
> > these patches?
>
> What happened was that the 2nd option was decided upon, and then the
> thread died, and probably everyone forgot about it.
>
> So, I'm doing exactly what I said I'd do in the second option.  I'm just
> still waiting some six months on...

OK, it's understandable. The issue just got a bit more popular now than it
used to be six months ago.

> If someone comes up with a tested patch, then its something we should
> sort out.

Thanks for clarifying the situation.

For now I'll keep advising people to use old Imre's patches (1st option) until
it is decided who, how, and when is going to fix it in a right way (2nd
option).

-- 
Best regards,
Siarhei Siamashka

[RFC PATCH 2/2] ARM: VFP: preserve the HW context when calling signal handlers

[Imre Deak]

On Mon, Jan 04, 2010 at 04:18:54PM +0100, Siamashka Siarhei (Nokia-D/Helsinki) wrote:
> On Monday 04 January 2010 16:25:49 ext Russell King - ARM Linux wrote:
> > On Mon, Jan 04, 2010 at 04:15:26PM +0200, Siarhei Siamashka wrote:
> > > On Saturday 13 June 2009 20:04:06 ext Russell King - ARM Linux wrote:
> > > > - wait for a new patch which includes these other registers and not
> > > > have any ABI visible changes to contend with
> > >
> > > Sorry for bumping this old thread, but what is the current status of
> > > these patches?
> >
> > What happened was that the 2nd option was decided upon, and then the
> > thread died, and probably everyone forgot about it.
> >
> > So, I'm doing exactly what I said I'd do in the second option.  I'm just
> > still waiting some six months on...
> 
> OK, it's understandable. The issue just got a bit more popular now than it
> used to be six months ago.
> 
> > If someone comes up with a tested patch, then its something we should
> > sort out.
> 
> Thanks for clarifying the situation.

Jamie, you raised the question of FP emulation in user space; could you
provide the VFP registers needed for that in addition to the already saved
ones? With that info I could update the patch so it's acceptable for everyone.

Thanks,
Imre

[RFC PATCH 2/2] ARM: VFP: preserve the HW context when callingsignal handlers

[Catalin Marinas]

On Wed, 2010-01-06 at 17:47 +0000, Imre Deak wrote:
> On Mon, Jan 04, 2010 at 04:18:54PM +0100, Siamashka Siarhei (Nokia-D/Helsinki) wrote:
> > On Monday 04 January 2010 16:25:49 ext Russell King - ARM Linux wrote:
> > > On Mon, Jan 04, 2010 at 04:15:26PM +0200, Siarhei Siamashka wrote:
> > > > On Saturday 13 June 2009 20:04:06 ext Russell King - ARM Linux wrote:
> > > > > - wait for a new patch which includes these other registers and not
> > > > > have any ABI visible changes to contend with
> > > >
> > > > Sorry for bumping this old thread, but what is the current status of
> > > > these patches?
> > >
> > > What happened was that the 2nd option was decided upon, and then the
> > > thread died, and probably everyone forgot about it.
> > >
> > > So, I'm doing exactly what I said I'd do in the second option.  I'm just
> > > still waiting some six months on...
> >
> > OK, it's understandable. The issue just got a bit more popular now than it
> > used to be six months ago.
> >
> > > If someone comes up with a tested patch, then its something we should
> > > sort out.
> >
> > Thanks for clarifying the situation.
> 
> Jamie, you raised the question of FP emulation in user space; could you
> provide the VFP registers needed for that in addition to the already saved
> ones? With that info I could update the patch so it's acceptable for everyone.

I think you need to save all of FPSCR, FPEXC, FPINST, FPINST2. The
information in the latter 2 registers is only relevant if corresponding
bits in FPEXC are set (like EX and FP2V). A signal handler could decide
whether to use them or not.

-- 
Catalin

[RFC PATCH 2/2] ARM: VFP: preserve the HW context when callingsignal handlers

[Imre Deak]

On Wed, Jan 13, 2010 at 04:49:42PM +0100, ext Catalin Marinas wrote:
> On Wed, 2010-01-06 at 17:47 +0000, Imre Deak wrote:
> > On Mon, Jan 04, 2010 at 04:18:54PM +0100, Siamashka Siarhei (Nokia-D/Helsinki) wrote:
> > > On Monday 04 January 2010 16:25:49 ext Russell King - ARM Linux wrote:
> > > > On Mon, Jan 04, 2010 at 04:15:26PM +0200, Siarhei Siamashka wrote:
> > > > > On Saturday 13 June 2009 20:04:06 ext Russell King - ARM Linux wrote:
> > > > > > - wait for a new patch which includes these other registers and not
> > > > > > have any ABI visible changes to contend with
> > > > >
> > > > > Sorry for bumping this old thread, but what is the current status of
> > > > > these patches?
> > > >
> > > > What happened was that the 2nd option was decided upon, and then the
> > > > thread died, and probably everyone forgot about it.
> > > >
> > > > So, I'm doing exactly what I said I'd do in the second option.  I'm just
> > > > still waiting some six months on...
> > >
> > > OK, it's understandable. The issue just got a bit more popular now than it
> > > used to be six months ago.
> > >
> > > > If someone comes up with a tested patch, then its something we should
> > > > sort out.
> > >
> > > Thanks for clarifying the situation.
> > 
> > Jamie, you raised the question of FP emulation in user space; could you
> > provide the VFP registers needed for that in addition to the already saved
> > ones? With that info I could update the patch so it's acceptable for everyone.
> 
> I think you need to save all of FPSCR, FPEXC, FPINST, FPINST2. The
> information in the latter 2 registers is only relevant if corresponding
> bits in FPEXC are set (like EX and FP2V). A signal handler could decide
> whether to use them or not.

Thanks for the info, I'll try to update my patches based on this.

--Imre

[RFC PATCH 2/2] ARM: VFP: preserve the HW context when calling signal handlers

[Siarhei Siamashka]

On Saturday 13 June 2009 20:04:06 ext Russell King - ARM Linux wrote:
> On Sat, Jun 13, 2009 at 05:40:35PM +0100, Jamie Lokier wrote:
> > Russell King - ARM Linux wrote:
> > > It seems that people do want access to these registers in signal
> > > handlers, yet there's still the original set of patches from Imre
> > > in the patch system.
> > >
> > > I'm been holding off applying them because of this open question.
> > >
> > > What am I to do with them?  Are people happy with the existing
> > > patches?
> > >
> > > (note that without the patch system, I'd have completely forgotten
> > > about those two patches and so would not be sending this chase-up.)
> >
> > The main thing is that all the machine state which affects user-space
> > which is saved on entering a signal handler, and restored on leaving
> > it, is accessible somehow through the arguments to the signal handler.
>
> I agree that we need something.  However, there seemed to be some kind of
> agreement in this thread that having access to these other registers from
> signal handlers would be a good thing.
>
> So, what I'm asking is, do I:
>
> - merge the current two patches in the patch system, and then at a later
>   date have to change the layout when someone wants access to these other
>   registers, thereby causing an ABI visible change with all the problems
>   that goes with that
>
> or
>
> - wait for a new patch which includes these other registers and not have
>   any ABI visible changes to contend with

Sorry for bumping this old thread, but what is the current status of these
patches?

This bug shows up as image corruption (typically it looks like short
horizontal stripes all over the screen) when using NEON optimized pixman
library and scrolling pages in firefox for example.

X server uses signal handlers for processing input, and they corrupt content
of NEON registers which are heavily used by pixman to process pixel data.

The problem has been already encountered by the maintainers of several
linux distributions (angstrom, ubuntu).

-- 
Best regards,
Siarhei Siamashka