summaryrefslogtreecommitdiffstats
path: root/arch/arm/nwfpe/softfloat.c
AgeCommit message (Collapse)Author
2005-11-07[ARM] 3117/1: nwfpe kernel memory info leakLennert Buytenhek
Patch from Lennert Buytenhek The routine that nwfpe uses for converting floats/doubles to extended precision fails to zero two bytes of kernel stack. This is not immediately obvious, as the floatx80 structure has 16 bits of implicit padding (by design.) These two bytes are copied to userspace when an stfe is emulated, causing a possible info leak. Make the padding explicit and zero it out in the relevant places. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-15[PATCH] ARM: 2851/1: Fix NWFPE extended precision exception handlingRichard Purdie
Patch from Richard Purdie The exception handling code fails to compile if the extended precision mode is enabled. This patch fixes those compile errors and also stops _quiet functions from incorrectly raising exceptions. Reported-by: Ralph Siemsen <ralphs@netwinder.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-03[PATCH] ARM: 2837/2: Re: ARM: Make NWFPE preempt safeRichard Purdie
Patch from Richard Purdie NWFPE used global variables which meant it wasn't safe for use with preemptive kernels. This patch removes them and communicates the information between functions in a preempt safe manner. Generation of some exceptions was broken and this has also been corrected. Tests with glibc's maths test suite show no change in the results before/after this patch. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-23[PATCH] ARM: 2722/1: remove reliance on udivdi3 for nwfpeNicolas Pitre
Patch from Nicolas Pitre Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!