__copy_user exception handling

__copy_user exception handling

[Matt Chapman]

The main __copy_user loop looks like this:

2:
        EX(.failure_in3,(p16) ld8 val1[0]=[src1],16)
(p16)   ld8 val2[0]=[src2],16

        EX(.failure_out, (EPI)  st8 [dst1]=val1[PIPE_DEPTH-1],16)
(EPI)   st8 [dst2]=val2[PIPE_DEPTH-1],16
        br.ctop.dptk 2b

What I'm trying to understand is why there is no EX necessary on the
second store.  As far as I understand the implementation, src is 16-byte
aligned here, so there is no need for EX on the second load, since it
necessarily hits the same page.  But dst is only 8-byte aligned, so I
would think that the second store could fault.

I've done some testing and for some reason it doesn't seem to be a
problem in Linux; I haven't been able to produce an oops.  But I've hit
oopses in Xen (we use the same code), and so I'm trying to understand
*why* it's not a problem in Linux.

Does anyone have some insight?

Matt

RE: __copy_user exception handling

[Chen, Kenneth W]

Matt Chapman wrote on Friday, July 29, 2005 3:11 PM
> The main __copy_user loop looks like this:
> 
> 2:
>         EX(.failure_in3,(p16) ld8 val1[0]=[src1],16)
> (p16)   ld8 val2[0]=[src2],16
> 
>         EX(.failure_out, (EPI)  st8 [dst1]=val1[PIPE_DEPTH-1],16)
> (EPI)   st8 [dst2]=val2[PIPE_DEPTH-1],16
>         br.ctop.dptk 2b
> 
> What I'm trying to understand is why there is no EX necessary on the
> second store.  As far as I understand the implementation, src is 16-byte
> aligned here, so there is no need for EX on the second load, since it
> necessarily hits the same page.  But dst is only 8-byte aligned, so I
> would think that the second store could fault.

Because exception handler use to work at instruction bundle granularity.
The first EX would automatically catch the 2nd ld8 or st8, with a caveat
that this code is assuming gcc 2.x tool chain.  With moving to gcc 3.x
assembler where it understand local tag support, the exception handler
works at instruction granularity and then all the sudden, it falls flat
on its face.


> I've done some testing and for some reason it doesn't seem to be a
> problem in Linux; I haven't been able to produce an oops.  But I've hit
> oopses in Xen (we use the same code), and so I'm trying to understand
> *why* it's not a problem in Linux.

Are you sure you want to use this code?  It's for first incarnation of
Itanium.  The kernel has an optimized version of copy_user for Itanium2.
See memcpy_mck.S

- Ken
 

Re: __copy_user exception handling

[Matt Chapman]

On Fri, Jul 29, 2005 at 04:23:33PM -0700, Chen, Kenneth W wrote:
> 
> Because exception handler use to work at instruction bundle granularity.
> The first EX would automatically catch the 2nd ld8 or st8, with a caveat
> that this code is assuming gcc 2.x tool chain.  With moving to gcc 3.x
> assembler where it understand local tag support, the exception handler
> works at instruction granularity and then all the sudden, it falls flat
> on its face.

Ah right.

> Are you sure you want to use this code?  It's for first incarnation of
> Itanium.  The kernel has an optimized version of copy_user for Itanium2.
> See memcpy_mck.S

Aha, thank you!  That explains why I can't trigger that bug in Linux
on Itanium 2.  I'll make Xen use the memcpy_mck.S version.

Matt