2005-04-17 02:20:36 +04:00
/ * U1 m e m c p y . S : U l t r a S P A R C - I / I I / I I i / I I e o p t i m i z e d m e m c p y .
*
* Copyright ( C ) 1 9 9 7 , 2 0 0 4 D a v i d S . M i l l e r ( d a v e m @redhat.com)
* Copyright ( C ) 1 9 9 6 , 1 9 9 7 , 1 9 9 8 , 1 9 9 9 J a k u b J e l i n e k ( j j @ultra.linux.cz)
* /
# ifdef _ _ K E R N E L _ _
# include < a s m / v i s a s m . h >
# include < a s m / a s i . h >
# define G L O B A L _ S P A R E g 7
# else
# define G L O B A L _ S P A R E g 5
# define A S I _ B L K _ P 0 x f0
# define F P R S _ F E F 0 x04
# ifdef M E M C P Y _ D E B U G
# define V I S E n t r y r d % f p r s , % o 5 ; wr %g0, FPRS_FEF, %fprs; \
clr % g 1 ; clr %g2; clr %g3; subcc %g0, %g0, %g0;
# define V I S E x i t a n d % o 5 , F P R S _ F E F , % o 5 ; wr %o5, 0x0, %fprs
# else
# define V I S E n t r y r d % f p r s , % o 5 ; wr %g0, FPRS_FEF, %fprs
# define V I S E x i t a n d % o 5 , F P R S _ F E F , % o 5 ; wr %o5, 0x0, %fprs
# endif
# endif
# ifndef E X _ L D
# define E X _ L D ( x ) x
# endif
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
# ifndef E X _ L D _ F P
# define E X _ L D _ F P ( x ) x
# endif
2005-04-17 02:20:36 +04:00
# ifndef E X _ S T
# define E X _ S T ( x ) x
# endif
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
# ifndef E X _ S T _ F P
# define E X _ S T _ F P ( x ) x
# endif
2005-04-17 02:20:36 +04:00
# ifndef E X _ R E T V A L
# define E X _ R E T V A L ( x ) x
# endif
# ifndef L O A D
# define L O A D ( t y p e ,a d d r ,d e s t ) t y p e [ a d d r ] , d e s t
# endif
# ifndef L O A D _ B L K
# define L O A D _ B L K ( a d d r ,d e s t ) l d d a [ a d d r ] A S I _ B L K _ P , d e s t
# endif
# ifndef S T O R E
# define S T O R E ( t y p e ,s r c ,a d d r ) t y p e s r c , [ a d d r ]
# endif
# ifndef S T O R E _ B L K
# define S T O R E _ B L K ( s r c ,a d d r ) s t d a s r c , [ a d d r ] A S I _ B L K _ P
# endif
# ifndef F U N C _ N A M E
# define F U N C _ N A M E m e m c p y
# endif
# ifndef P R E A M B L E
# define P R E A M B L E
# endif
# ifndef X C C
# define X C C x c c
# endif
# define F R E G _ F R O B ( f1 , f2 , f3 , f4 , f5 , f6 , f7 , f8 , f9 ) \
faligndata % f1 , % f2 , % f48 ; \
faligndata % f2 , % f3 , % f50 ; \
faligndata % f3 , % f4 , % f52 ; \
faligndata % f4 , % f5 , % f54 ; \
faligndata % f5 , % f6 , % f56 ; \
faligndata % f6 , % f7 , % f58 ; \
faligndata % f7 , % f8 , % f60 ; \
faligndata % f8 , % f9 , % f62 ;
# define M A I N _ L O O P _ C H U N K ( s r c , d e s t , f d e s t , f s r c , l e n , j m p t g t ) \
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ L D _ F P ( L O A D _ B L K ( % s r c , % f d e s t ) ) ; \
EX_ S T _ F P ( S T O R E _ B L K ( % f s r c , % d e s t ) ) ; \
2005-04-17 02:20:36 +04:00
add % s r c , 0 x40 , % s r c ; \
subcc % l e n , 0 x40 , % l e n ; \
be,p n % x c c , j m p t g t ; \
add % d e s t , 0 x40 , % d e s t ; \
# define L O O P _ C H U N K 1 ( s r c , d e s t , l e n , b r a n c h _ d e s t ) \
MAIN_ L O O P _ C H U N K ( s r c , d e s t , f0 , f48 , l e n , b r a n c h _ d e s t )
# define L O O P _ C H U N K 2 ( s r c , d e s t , l e n , b r a n c h _ d e s t ) \
MAIN_ L O O P _ C H U N K ( s r c , d e s t , f16 , f48 , l e n , b r a n c h _ d e s t )
# define L O O P _ C H U N K 3 ( s r c , d e s t , l e n , b r a n c h _ d e s t ) \
MAIN_ L O O P _ C H U N K ( s r c , d e s t , f32 , f48 , l e n , b r a n c h _ d e s t )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
# define D O _ S Y N C m e m b a r #S y n c ;
2005-04-17 02:20:36 +04:00
# define S T O R E _ S Y N C ( d e s t , f s r c ) \
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ S T _ F P ( S T O R E _ B L K ( % f s r c , % d e s t ) ) ; \
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
add % d e s t , 0 x40 , % d e s t ; \
DO_ S Y N C
2005-04-17 02:20:36 +04:00
# define S T O R E _ J U M P ( d e s t , f s r c , t a r g e t ) \
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ S T _ F P ( S T O R E _ B L K ( % f s r c , % d e s t ) ) ; \
2005-04-17 02:20:36 +04:00
add % d e s t , 0 x40 , % d e s t ; \
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
ba,p t % x c c , t a r g e t ; \
nop;
2005-04-17 02:20:36 +04:00
# define F I N I S H _ V I S C H U N K ( d e s t , f0 , f1 , l e f t ) \
subcc % l e f t , 8 , % l e f t ;\
bl,p n % x c c , 9 5 f ; \
faligndata % f0 , % f1 , % f48 ; \
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ S T _ F P ( S T O R E ( s t d , % f48 , % d e s t ) ) ; \
2005-04-17 02:20:36 +04:00
add % d e s t , 8 , % d e s t ;
# define U N E V E N _ V I S C H U N K _ L A S T ( d e s t , f0 , f1 , l e f t ) \
subcc % l e f t , 8 , % l e f t ; \
bl,p n % x c c , 9 5 f ; \
2012-06-27 12:25:23 +04:00
fsrc2 % f0 , % f1 ;
2005-04-17 02:20:36 +04:00
# define U N E V E N _ V I S C H U N K ( d e s t , f0 , f1 , l e f t ) \
UNEVEN_ V I S C H U N K _ L A S T ( d e s t , f0 , f1 , l e f t ) \
ba,a ,p t % x c c , 9 3 f ;
.register % g2 ,#s c r a t c h
.register % g3 ,#s c r a t c h
.text
.align 64
.globl FUNC_NAME
.type FUNC_ N A M E ,#f u n c t i o n
FUNC_NAME : /* %o0=dst, %o1=src, %o2=len */
srlx % o 2 , 3 1 , % g 2
cmp % g 2 , 0
tne % x c c , 5
PREAMBLE
mov % o 0 , % o 4
cmp % o 2 , 0
be,p n % X C C , 8 5 f
or % o 0 , % o 1 , % o 3
cmp % o 2 , 1 6
blu,a ,p n % X C C , 8 0 f
or % o 3 , % o 2 , % o 3
cmp % o 2 , ( 5 * 6 4 )
blu,p t % X C C , 7 0 f
andcc % o 3 , 0 x7 , % g 0
/* Clobbers o5/g1/g2/g3/g7/icc/xcc. */
VISEntry
/* Is 'dst' already aligned on an 64-byte boundary? */
andcc % o 0 , 0 x3 f , % g 2
be,p t % X C C , 2 f
/ * Compute a b s ( ( d s t & 0 x3 f ) - 0 x40 ) i n t o % g 2 . T h i s i s t h e n u m b e r
* of b y t e s t o c o p y t o m a k e ' d s t ' 6 4 - b y t e a l i g n e d . W e p r e -
* subtract t h i s f r o m ' l e n ' .
* /
sub % o 0 , % o 1 , % G L O B A L _ S P A R E
sub % g 2 , 0 x40 , % g 2
sub % g 0 , % g 2 , % g 2
sub % o 2 , % g 2 , % o 2
andcc % g 2 , 0 x7 , % g 1
be,p t % i c c , 2 f
and % g 2 , 0 x38 , % g 2
1 : subcc % g 1 , 0 x1 , % g 1
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ L D _ F P ( L O A D ( l d u b , % o 1 + 0 x00 , % o 3 ) )
EX_ S T _ F P ( S T O R E ( s t b , % o 3 , % o 1 + % G L O B A L _ S P A R E ) )
2005-04-17 02:20:36 +04:00
bgu,p t % X C C , 1 b
add % o 1 , 0 x1 , % o 1
add % o 1 , % G L O B A L _ S P A R E , % o 0
2 : cmp % g 2 , 0 x0
and % o 1 , 0 x7 , % g 1
be,p t % i c c , 3 f
alignaddr % o 1 , % g 0 , % o 1
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ L D _ F P ( L O A D ( l d d , % o 1 , % f4 ) )
1 : EX_ L D _ F P ( L O A D ( l d d , % o 1 + 0 x8 , % f6 ) )
2005-04-17 02:20:36 +04:00
add % o 1 , 0 x8 , % o 1
subcc % g 2 , 0 x8 , % g 2
faligndata % f4 , % f6 , % f0
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ S T _ F P ( S T O R E ( s t d , % f0 , % o 0 ) )
2005-04-17 02:20:36 +04:00
be,p n % i c c , 3 f
add % o 0 , 0 x8 , % o 0
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ L D _ F P ( L O A D ( l d d , % o 1 + 0 x8 , % f4 ) )
2005-04-17 02:20:36 +04:00
add % o 1 , 0 x8 , % o 1
subcc % g 2 , 0 x8 , % g 2
faligndata % f6 , % f4 , % f0
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ S T _ F P ( S T O R E ( s t d , % f0 , % o 0 ) )
2005-04-17 02:20:36 +04:00
bne,p t % i c c , 1 b
add % o 0 , 0 x8 , % o 0
/* Destination is 64-byte aligned. */
3 :
membar #L o a d S t o r e | # S t o r e S t o r e | # S t o r e L o a d
subcc % o 2 , 0 x40 , % G L O B A L _ S P A R E
add % o 1 , % g 1 , % g 1
andncc % G L O B A L _ S P A R E , ( 0 x40 - 1 ) , % G L O B A L _ S P A R E
srl % g 1 , 3 , % g 2
sub % o 2 , % G L O B A L _ S P A R E , % g 3
andn % o 1 , ( 0 x40 - 1 ) , % o 1
and % g 2 , 7 , % g 2
andncc % g 3 , 0 x7 , % g 3
2012-06-27 12:25:23 +04:00
fsrc2 % f0 , % f2
2005-04-17 02:20:36 +04:00
sub % g 3 , 0 x8 , % g 3
sub % o 2 , % G L O B A L _ S P A R E , % o 2
add % g 1 , % G L O B A L _ S P A R E , % g 1
subcc % o 2 , % g 3 , % o 2
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ L D _ F P ( L O A D _ B L K ( % o 1 , % f0 ) )
2005-04-17 02:20:36 +04:00
add % o 1 , 0 x40 , % o 1
add % g 1 , % g 3 , % g 1
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ L D _ F P ( L O A D _ B L K ( % o 1 , % f16 ) )
2005-04-17 02:20:36 +04:00
add % o 1 , 0 x40 , % o 1
sub % G L O B A L _ S P A R E , 0 x80 , % G L O B A L _ S P A R E
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ L D _ F P ( L O A D _ B L K ( % o 1 , % f32 ) )
2005-04-17 02:20:36 +04:00
add % o 1 , 0 x40 , % o 1
/ * There a r e 8 i n s t a n c e s o f t h e u n r o l l e d l o o p ,
* one f o r e a c h p o s s i b l e a l i g n m e n t o f t h e
* source b u f f e r . E a c h l o o p i n s t a n c e i s 4 5 2
* bytes.
* /
sll % g 2 , 3 , % o 3
sub % o 3 , % g 2 , % o 3
sllx % o 3 , 4 , % o 3
add % o 3 , % g 2 , % o 3
sllx % o 3 , 2 , % g 2
1 : rd % p c , % o 3
add % o 3 , % l o ( 1 f - 1 b ) , % o 3
jmpl % o 3 + % g 2 , % g 0
nop
.align 64
1 : FREG_ F R O B ( f0 , f2 , f4 , f6 , f8 , f10 ,f12 ,f14 ,f16 )
LOOP_ C H U N K 1 ( o 1 , o 0 , G L O B A L _ S P A R E , 1 f )
FREG_ F R O B ( f16 ,f18 ,f20 ,f22 ,f24 ,f26 ,f28 ,f30 ,f32 )
LOOP_ C H U N K 2 ( o 1 , o 0 , G L O B A L _ S P A R E , 2 f )
FREG_ F R O B ( f32 ,f34 ,f36 ,f38 ,f40 ,f42 ,f44 ,f46 ,f0 )
LOOP_ C H U N K 3 ( o 1 , o 0 , G L O B A L _ S P A R E , 3 f )
ba,p t % x c c , 1 b + 4
faligndata % f0 , % f2 , % f48
1 : FREG_ F R O B ( f16 ,f18 ,f20 ,f22 ,f24 ,f26 ,f28 ,f30 ,f32 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f32 ,f34 ,f36 ,f38 ,f40 ,f42 ,f44 ,f46 ,f0 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 0 f )
2005-04-17 02:20:36 +04:00
2 : FREG_ F R O B ( f32 ,f34 ,f36 ,f38 ,f40 ,f42 ,f44 ,f46 ,f0 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f0 , f2 , f4 , f6 , f8 , f10 ,f12 ,f14 ,f16 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 8 f )
2005-04-17 02:20:36 +04:00
3 : FREG_ F R O B ( f0 , f2 , f4 , f6 , f8 , f10 ,f12 ,f14 ,f16 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f16 ,f18 ,f20 ,f22 ,f24 ,f26 ,f28 ,f30 ,f32 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 6 f )
2005-04-17 02:20:36 +04:00
1 : FREG_ F R O B ( f2 , f4 , f6 , f8 , f10 ,f12 ,f14 ,f16 ,f18 )
LOOP_ C H U N K 1 ( o 1 , o 0 , G L O B A L _ S P A R E , 1 f )
FREG_ F R O B ( f18 ,f20 ,f22 ,f24 ,f26 ,f28 ,f30 ,f32 ,f34 )
LOOP_ C H U N K 2 ( o 1 , o 0 , G L O B A L _ S P A R E , 2 f )
FREG_ F R O B ( f34 ,f36 ,f38 ,f40 ,f42 ,f44 ,f46 ,f0 , f2 )
LOOP_ C H U N K 3 ( o 1 , o 0 , G L O B A L _ S P A R E , 3 f )
ba,p t % x c c , 1 b + 4
faligndata % f2 , % f4 , % f48
1 : FREG_ F R O B ( f18 ,f20 ,f22 ,f24 ,f26 ,f28 ,f30 ,f32 ,f34 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f34 ,f36 ,f38 ,f40 ,f42 ,f44 ,f46 ,f0 , f2 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 1 f )
2005-04-17 02:20:36 +04:00
2 : FREG_ F R O B ( f34 ,f36 ,f38 ,f40 ,f42 ,f44 ,f46 ,f0 , f2 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f2 , f4 , f6 , f8 , f10 ,f12 ,f14 ,f16 ,f18 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 9 f )
2005-04-17 02:20:36 +04:00
3 : FREG_ F R O B ( f2 , f4 , f6 , f8 , f10 ,f12 ,f14 ,f16 ,f18 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f18 ,f20 ,f22 ,f24 ,f26 ,f28 ,f30 ,f32 ,f34 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 7 f )
2005-04-17 02:20:36 +04:00
1 : FREG_ F R O B ( f4 , f6 , f8 , f10 ,f12 ,f14 ,f16 ,f18 ,f20 )
LOOP_ C H U N K 1 ( o 1 , o 0 , G L O B A L _ S P A R E , 1 f )
FREG_ F R O B ( f20 ,f22 ,f24 ,f26 ,f28 ,f30 ,f32 ,f34 ,f36 )
LOOP_ C H U N K 2 ( o 1 , o 0 , G L O B A L _ S P A R E , 2 f )
FREG_ F R O B ( f36 ,f38 ,f40 ,f42 ,f44 ,f46 ,f0 , f2 , f4 )
LOOP_ C H U N K 3 ( o 1 , o 0 , G L O B A L _ S P A R E , 3 f )
ba,p t % x c c , 1 b + 4
faligndata % f4 , % f6 , % f48
1 : FREG_ F R O B ( f20 ,f22 ,f24 ,f26 ,f28 ,f30 ,f32 ,f34 ,f36 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f36 ,f38 ,f40 ,f42 ,f44 ,f46 ,f0 , f2 , f4 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 2 f )
2005-04-17 02:20:36 +04:00
2 : FREG_ F R O B ( f36 ,f38 ,f40 ,f42 ,f44 ,f46 ,f0 , f2 , f4 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f4 , f6 , f8 , f10 ,f12 ,f14 ,f16 ,f18 ,f20 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 0 f )
2005-04-17 02:20:36 +04:00
3 : FREG_ F R O B ( f4 , f6 , f8 , f10 ,f12 ,f14 ,f16 ,f18 ,f20 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f20 ,f22 ,f24 ,f26 ,f28 ,f30 ,f32 ,f34 ,f36 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 8 f )
2005-04-17 02:20:36 +04:00
1 : FREG_ F R O B ( f6 , f8 , f10 ,f12 ,f14 ,f16 ,f18 ,f20 ,f22 )
LOOP_ C H U N K 1 ( o 1 , o 0 , G L O B A L _ S P A R E , 1 f )
FREG_ F R O B ( f22 ,f24 ,f26 ,f28 ,f30 ,f32 ,f34 ,f36 ,f38 )
LOOP_ C H U N K 2 ( o 1 , o 0 , G L O B A L _ S P A R E , 2 f )
FREG_ F R O B ( f38 ,f40 ,f42 ,f44 ,f46 ,f0 , f2 , f4 , f6 )
LOOP_ C H U N K 3 ( o 1 , o 0 , G L O B A L _ S P A R E , 3 f )
ba,p t % x c c , 1 b + 4
faligndata % f6 , % f8 , % f48
1 : FREG_ F R O B ( f22 ,f24 ,f26 ,f28 ,f30 ,f32 ,f34 ,f36 ,f38 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f38 ,f40 ,f42 ,f44 ,f46 ,f0 , f2 , f4 , f6 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 3 f )
2005-04-17 02:20:36 +04:00
2 : FREG_ F R O B ( f38 ,f40 ,f42 ,f44 ,f46 ,f0 , f2 , f4 , f6 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f6 , f8 , f10 ,f12 ,f14 ,f16 ,f18 ,f20 ,f22 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 1 f )
2005-04-17 02:20:36 +04:00
3 : FREG_ F R O B ( f6 , f8 , f10 ,f12 ,f14 ,f16 ,f18 ,f20 ,f22 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f22 ,f24 ,f26 ,f28 ,f30 ,f32 ,f34 ,f36 ,f38 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 9 f )
2005-04-17 02:20:36 +04:00
1 : FREG_ F R O B ( f8 , f10 ,f12 ,f14 ,f16 ,f18 ,f20 ,f22 ,f24 )
LOOP_ C H U N K 1 ( o 1 , o 0 , G L O B A L _ S P A R E , 1 f )
FREG_ F R O B ( f24 ,f26 ,f28 ,f30 ,f32 ,f34 ,f36 ,f38 ,f40 )
LOOP_ C H U N K 2 ( o 1 , o 0 , G L O B A L _ S P A R E , 2 f )
FREG_ F R O B ( f40 ,f42 ,f44 ,f46 ,f0 , f2 , f4 , f6 , f8 )
LOOP_ C H U N K 3 ( o 1 , o 0 , G L O B A L _ S P A R E , 3 f )
ba,p t % x c c , 1 b + 4
faligndata % f8 , % f10 , % f48
1 : FREG_ F R O B ( f24 ,f26 ,f28 ,f30 ,f32 ,f34 ,f36 ,f38 ,f40 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f40 ,f42 ,f44 ,f46 ,f0 , f2 , f4 , f6 , f8 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 4 f )
2005-04-17 02:20:36 +04:00
2 : FREG_ F R O B ( f40 ,f42 ,f44 ,f46 ,f0 , f2 , f4 , f6 , f8 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f8 , f10 ,f12 ,f14 ,f16 ,f18 ,f20 ,f22 ,f24 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 2 f )
2005-04-17 02:20:36 +04:00
3 : FREG_ F R O B ( f8 , f10 ,f12 ,f14 ,f16 ,f18 ,f20 ,f22 ,f24 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f24 ,f26 ,f28 ,f30 ,f32 ,f34 ,f36 ,f38 ,f40 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 6 0 f )
2005-04-17 02:20:36 +04:00
1 : FREG_ F R O B ( f10 ,f12 ,f14 ,f16 ,f18 ,f20 ,f22 ,f24 ,f26 )
LOOP_ C H U N K 1 ( o 1 , o 0 , G L O B A L _ S P A R E , 1 f )
FREG_ F R O B ( f26 ,f28 ,f30 ,f32 ,f34 ,f36 ,f38 ,f40 ,f42 )
LOOP_ C H U N K 2 ( o 1 , o 0 , G L O B A L _ S P A R E , 2 f )
FREG_ F R O B ( f42 ,f44 ,f46 ,f0 , f2 , f4 , f6 , f8 , f10 )
LOOP_ C H U N K 3 ( o 1 , o 0 , G L O B A L _ S P A R E , 3 f )
ba,p t % x c c , 1 b + 4
faligndata % f10 , % f12 , % f48
1 : FREG_ F R O B ( f26 ,f28 ,f30 ,f32 ,f34 ,f36 ,f38 ,f40 ,f42 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f42 ,f44 ,f46 ,f0 , f2 , f4 , f6 , f8 , f10 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 5 f )
2005-04-17 02:20:36 +04:00
2 : FREG_ F R O B ( f42 ,f44 ,f46 ,f0 , f2 , f4 , f6 , f8 , f10 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f10 ,f12 ,f14 ,f16 ,f18 ,f20 ,f22 ,f24 ,f26 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 3 f )
2005-04-17 02:20:36 +04:00
3 : FREG_ F R O B ( f10 ,f12 ,f14 ,f16 ,f18 ,f20 ,f22 ,f24 ,f26 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f26 ,f28 ,f30 ,f32 ,f34 ,f36 ,f38 ,f40 ,f42 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 6 1 f )
2005-04-17 02:20:36 +04:00
1 : FREG_ F R O B ( f12 ,f14 ,f16 ,f18 ,f20 ,f22 ,f24 ,f26 ,f28 )
LOOP_ C H U N K 1 ( o 1 , o 0 , G L O B A L _ S P A R E , 1 f )
FREG_ F R O B ( f28 ,f30 ,f32 ,f34 ,f36 ,f38 ,f40 ,f42 ,f44 )
LOOP_ C H U N K 2 ( o 1 , o 0 , G L O B A L _ S P A R E , 2 f )
FREG_ F R O B ( f44 ,f46 ,f0 , f2 , f4 , f6 , f8 , f10 ,f12 )
LOOP_ C H U N K 3 ( o 1 , o 0 , G L O B A L _ S P A R E , 3 f )
ba,p t % x c c , 1 b + 4
faligndata % f12 , % f14 , % f48
1 : FREG_ F R O B ( f28 ,f30 ,f32 ,f34 ,f36 ,f38 ,f40 ,f42 ,f44 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f44 ,f46 ,f0 , f2 , f4 , f6 , f8 , f10 ,f12 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 6 f )
2005-04-17 02:20:36 +04:00
2 : FREG_ F R O B ( f44 ,f46 ,f0 , f2 , f4 , f6 , f8 , f10 ,f12 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f12 ,f14 ,f16 ,f18 ,f20 ,f22 ,f24 ,f26 ,f28 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 4 f )
2005-04-17 02:20:36 +04:00
3 : FREG_ F R O B ( f12 ,f14 ,f16 ,f18 ,f20 ,f22 ,f24 ,f26 ,f28 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f28 ,f30 ,f32 ,f34 ,f36 ,f38 ,f40 ,f42 ,f44 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 6 2 f )
2005-04-17 02:20:36 +04:00
1 : FREG_ F R O B ( f14 ,f16 ,f18 ,f20 ,f22 ,f24 ,f26 ,f28 ,f30 )
LOOP_ C H U N K 1 ( o 1 , o 0 , G L O B A L _ S P A R E , 1 f )
FREG_ F R O B ( f30 ,f32 ,f34 ,f36 ,f38 ,f40 ,f42 ,f44 ,f46 )
LOOP_ C H U N K 2 ( o 1 , o 0 , G L O B A L _ S P A R E , 2 f )
FREG_ F R O B ( f46 ,f0 , f2 , f4 , f6 , f8 , f10 ,f12 ,f14 )
LOOP_ C H U N K 3 ( o 1 , o 0 , G L O B A L _ S P A R E , 3 f )
ba,p t % x c c , 1 b + 4
faligndata % f14 , % f16 , % f48
1 : FREG_ F R O B ( f30 ,f32 ,f34 ,f36 ,f38 ,f40 ,f42 ,f44 ,f46 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f46 ,f0 , f2 , f4 , f6 , f8 , f10 ,f12 ,f14 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 4 7 f )
2005-04-17 02:20:36 +04:00
2 : FREG_ F R O B ( f46 ,f0 , f2 , f4 , f6 , f8 , f10 ,f12 ,f14 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f14 ,f16 ,f18 ,f20 ,f22 ,f24 ,f26 ,f28 ,f30 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 5 5 f )
2005-04-17 02:20:36 +04:00
3 : FREG_ F R O B ( f14 ,f16 ,f18 ,f20 ,f22 ,f24 ,f26 ,f28 ,f30 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ S Y N C ( o 0 , f48 )
2005-04-17 02:20:36 +04:00
FREG_ F R O B ( f30 ,f32 ,f34 ,f36 ,f38 ,f40 ,f42 ,f44 ,f46 )
[SPARC64]: Avoid membar instructions in delay slots.
In particular, avoid membar instructions in the delay
slot of a jmpl instruction.
UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.
If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.
We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-28 02:42:04 +04:00
STORE_ J U M P ( o 0 , f48 , 6 3 f )
2005-04-17 02:20:36 +04:00
40 : FINISH_ V I S C H U N K ( o 0 , f0 , f2 , g 3 )
41 : FINISH_ V I S C H U N K ( o 0 , f2 , f4 , g 3 )
42 : FINISH_ V I S C H U N K ( o 0 , f4 , f6 , g 3 )
43 : FINISH_ V I S C H U N K ( o 0 , f6 , f8 , g 3 )
44 : FINISH_ V I S C H U N K ( o 0 , f8 , f10 , g 3 )
45 : FINISH_ V I S C H U N K ( o 0 , f10 , f12 , g 3 )
46 : FINISH_ V I S C H U N K ( o 0 , f12 , f14 , g 3 )
47 : UNEVEN_ V I S C H U N K ( o 0 , f14 , f0 , g 3 )
48 : FINISH_ V I S C H U N K ( o 0 , f16 , f18 , g 3 )
49 : FINISH_ V I S C H U N K ( o 0 , f18 , f20 , g 3 )
50 : FINISH_ V I S C H U N K ( o 0 , f20 , f22 , g 3 )
51 : FINISH_ V I S C H U N K ( o 0 , f22 , f24 , g 3 )
52 : FINISH_ V I S C H U N K ( o 0 , f24 , f26 , g 3 )
53 : FINISH_ V I S C H U N K ( o 0 , f26 , f28 , g 3 )
54 : FINISH_ V I S C H U N K ( o 0 , f28 , f30 , g 3 )
55 : UNEVEN_ V I S C H U N K ( o 0 , f30 , f0 , g 3 )
56 : FINISH_ V I S C H U N K ( o 0 , f32 , f34 , g 3 )
57 : FINISH_ V I S C H U N K ( o 0 , f34 , f36 , g 3 )
58 : FINISH_ V I S C H U N K ( o 0 , f36 , f38 , g 3 )
59 : FINISH_ V I S C H U N K ( o 0 , f38 , f40 , g 3 )
60 : FINISH_ V I S C H U N K ( o 0 , f40 , f42 , g 3 )
61 : FINISH_ V I S C H U N K ( o 0 , f42 , f44 , g 3 )
62 : FINISH_ V I S C H U N K ( o 0 , f44 , f46 , g 3 )
63 : UNEVEN_ V I S C H U N K _ L A S T ( o 0 , f46 , f0 , g 3 )
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
93 : EX_ L D _ F P ( L O A D ( l d d , % o 1 , % f2 ) )
2005-04-17 02:20:36 +04:00
add % o 1 , 8 , % o 1
subcc % g 3 , 8 , % g 3
faligndata % f0 , % f2 , % f8
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ S T _ F P ( S T O R E ( s t d , % f8 , % o 0 ) )
2005-04-17 02:20:36 +04:00
bl,p n % x c c , 9 5 f
add % o 0 , 8 , % o 0
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ L D _ F P ( L O A D ( l d d , % o 1 , % f0 ) )
2005-04-17 02:20:36 +04:00
add % o 1 , 8 , % o 1
subcc % g 3 , 8 , % g 3
faligndata % f2 , % f0 , % f8
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ S T _ F P ( S T O R E ( s t d , % f8 , % o 0 ) )
2005-04-17 02:20:36 +04:00
bge,p t % x c c , 9 3 b
add % o 0 , 8 , % o 0
95 : brz,p t % o 2 , 2 f
mov % g 1 , % o 1
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
1 : EX_ L D _ F P ( L O A D ( l d u b , % o 1 , % o 3 ) )
2005-04-17 02:20:36 +04:00
add % o 1 , 1 , % o 1
subcc % o 2 , 1 , % o 2
sparc64: fix FP corruption in user copy functions
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-23 09:24:49 +03:00
EX_ S T _ F P ( S T O R E ( s t b , % o 3 , % o 0 ) )
2005-04-17 02:20:36 +04:00
bne,p t % x c c , 1 b
add % o 0 , 1 , % o 0
2 : membar #S t o r e L o a d | # S t o r e S t o r e
VISExit
retl
mov E X _ R E T V A L ( % o 4 ) , % o 0
.align 64
70 : /* 16 < len <= (5 * 64) */
bne,p n % X C C , 7 5 f
sub % o 0 , % o 1 , % o 3
72 : andn % o 2 , 0 x f , % G L O B A L _ S P A R E
and % o 2 , 0 x f , % o 2
1 : EX_ L D ( L O A D ( l d x , % o 1 + 0 x00 , % o 5 ) )
EX_ L D ( L O A D ( l d x , % o 1 + 0 x08 , % g 1 ) )
subcc % G L O B A L _ S P A R E , 0 x10 , % G L O B A L _ S P A R E
EX_ S T ( S T O R E ( s t x , % o 5 , % o 1 + % o 3 ) )
add % o 1 , 0 x8 , % o 1
EX_ S T ( S T O R E ( s t x , % g 1 , % o 1 + % o 3 ) )
bgu,p t % X C C , 1 b
add % o 1 , 0 x8 , % o 1
73 : andcc % o 2 , 0 x8 , % g 0
be,p t % X C C , 1 f
nop
EX_ L D ( L O A D ( l d x , % o 1 , % o 5 ) )
sub % o 2 , 0 x8 , % o 2
EX_ S T ( S T O R E ( s t x , % o 5 , % o 1 + % o 3 ) )
add % o 1 , 0 x8 , % o 1
1 : andcc % o 2 , 0 x4 , % g 0
be,p t % X C C , 1 f
nop
EX_ L D ( L O A D ( l d u w , % o 1 , % o 5 ) )
sub % o 2 , 0 x4 , % o 2
EX_ S T ( S T O R E ( s t w , % o 5 , % o 1 + % o 3 ) )
add % o 1 , 0 x4 , % o 1
1 : cmp % o 2 , 0
be,p t % X C C , 8 5 f
nop
ba,p t % x c c , 9 0 f
nop
75 : andcc % o 0 , 0 x7 , % g 1
sub % g 1 , 0 x8 , % g 1
be,p n % i c c , 2 f
sub % g 0 , % g 1 , % g 1
sub % o 2 , % g 1 , % o 2
1 : EX_ L D ( L O A D ( l d u b , % o 1 , % o 5 ) )
subcc % g 1 , 1 , % g 1
EX_ S T ( S T O R E ( s t b , % o 5 , % o 1 + % o 3 ) )
bgu,p t % i c c , 1 b
add % o 1 , 1 , % o 1
2 : add % o 1 , % o 3 , % o 0
andcc % o 1 , 0 x7 , % g 1
bne,p t % i c c , 8 f
sll % g 1 , 3 , % g 1
cmp % o 2 , 1 6
bgeu,p t % i c c , 7 2 b
nop
ba,a ,p t % x c c , 7 3 b
8 : mov 6 4 , % o 3
andn % o 1 , 0 x7 , % o 1
EX_ L D ( L O A D ( l d x , % o 1 , % g 2 ) )
sub % o 3 , % g 1 , % o 3
andn % o 2 , 0 x7 , % G L O B A L _ S P A R E
sllx % g 2 , % g 1 , % g 2
1 : EX_ L D ( L O A D ( l d x , % o 1 + 0 x8 , % g 3 ) )
subcc % G L O B A L _ S P A R E , 0 x8 , % G L O B A L _ S P A R E
add % o 1 , 0 x8 , % o 1
srlx % g 3 , % o 3 , % o 5
or % o 5 , % g 2 , % o 5
EX_ S T ( S T O R E ( s t x , % o 5 , % o 0 ) )
add % o 0 , 0 x8 , % o 0
bgu,p t % i c c , 1 b
sllx % g 3 , % g 1 , % g 2
srl % g 1 , 3 , % g 1
andcc % o 2 , 0 x7 , % o 2
be,p n % i c c , 8 5 f
add % o 1 , % g 1 , % o 1
ba,p t % x c c , 9 0 f
sub % o 0 , % o 1 , % o 3
.align 64
80 : /* 0 < len <= 16 */
andcc % o 3 , 0 x3 , % g 0
bne,p n % X C C , 9 0 f
sub % o 0 , % o 1 , % o 3
1 : EX_ L D ( L O A D ( l d u w , % o 1 , % g 1 ) )
subcc % o 2 , 4 , % o 2
EX_ S T ( S T O R E ( s t w , % g 1 , % o 1 + % o 3 ) )
bgu,p t % X C C , 1 b
add % o 1 , 4 , % o 1
85 : retl
mov E X _ R E T V A L ( % o 4 ) , % o 0
.align 32
90 : EX_ L D ( L O A D ( l d u b , % o 1 , % g 1 ) )
subcc % o 2 , 1 , % o 2
EX_ S T ( S T O R E ( s t b , % g 1 , % o 1 + % o 3 ) )
bgu,p t % X C C , 9 0 b
add % o 1 , 1 , % o 1
retl
mov E X _ R E T V A L ( % o 4 ) , % o 0
.size FUNC_ N A M E , . - F U N C _ N A M E