Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 291782 Details for
Bug 428920
user data corruption on misaligned access with certain FP instructions
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
[patch]
git commit - has description & patch
fpfix.git (text/plain), 1.96 KB, created by
Tony Luck
on 2008-01-16 01:08:37 UTC
(
hide
)
Description:
git commit - has description & patch
Filename:
MIME Type:
Creator:
Tony Luck
Created:
2008-01-16 01:08:37 UTC
Size:
1.96 KB
patch
obsolete
>commit 1a499150e4ec1299232e24389f648d059ce5617a >Author: Luck, Tony <tony.luck@intel.com> >Date: Mon Jan 14 09:59:24 2008 -0800 > > [IA64] Fix unaligned handler for floating point instructions with base update > > The compiler team did the hard work for this distilling a problem in > large fortran application which showed up when applied to a 290MB input > data set down to this instruction: > > ldfd f34=[r17],-8 > > Which they noticed incremented r17 by 0x10 rather than decrementing it > by 8 when the value in r17 caused an unaligned data fault. I tracked > it down to some bad instruction decoding in unaligned.c. The code > assumes that the 'x' bit can determine whether the instruction is > an "ldf" or "ldfp" ... which it is for opcode=6 (see table 4-29 on > page 3:302 of the SDM). But for opcode=7 the 'x' bit is irrelevent, > all variants are "ldf" instructions (see table 4-36 on page 3:306). > > Note also that interpreting the instruction as "ldfp" means that the > "paired" floating point register (f35 in the example here) will also > be corrupted. > > Signed-off-by: Tony Luck <tony.luck@intel.com> > >diff --git a/arch/ia64/kernel/unaligned.c b/arch/ia64/kernel/unaligned.c >index 2173de9..f6a1aeb 100644 >--- a/arch/ia64/kernel/unaligned.c >+++ b/arch/ia64/kernel/unaligned.c >@@ -1488,16 +1488,19 @@ ia64_handle_unaligned (unsigned long ifa, struct pt_regs *regs) > case LDFA_OP: > case LDFCCLR_OP: > case LDFCNC_OP: >- case LDF_IMM_OP: >- case LDFA_IMM_OP: >- case LDFCCLR_IMM_OP: >- case LDFCNC_IMM_OP: > if (u.insn.x) > ret = emulate_load_floatpair(ifa, u.insn, regs); > else > ret = emulate_load_float(ifa, u.insn, regs); > break; > >+ case LDF_IMM_OP: >+ case LDFA_IMM_OP: >+ case LDFCCLR_IMM_OP: >+ case LDFCNC_IMM_OP: >+ ret = emulate_load_float(ifa, u.insn, regs); >+ break; >+ > case STF_OP: > case STF_IMM_OP: > ret = emulate_store_float(ifa, u.insn, regs);
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 428920
: 291782 |
292864