summaryrefslogtreecommitdiffstats
path: root/lib/extable.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* extable: add support for relative extables to search and sort routinesArd Biesheuvel2016-02-241-9/+41
| | | | | | | | | | | | | | | This adds support to the generic search_extable() and sort_extable() implementations for dealing with exception table entries whose fields contain relative offsets rather than absolute addresses. Acked-by: Helge Deller <deller@gmx.de> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: H. Peter Anvin <hpa@linux.intel.com> Acked-by: Tony Luck <tony.luck@intel.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
* module: trim exception table on init free.Rusty Russell2009-06-121-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | It's theoretically possible that there are exception table entries which point into the (freed) init text of modules. These could cause future problems if other modules get loaded into that memory and cause an exception as we'd see the wrong fixup. The only case I know of is kvm-intel.ko (when CONFIG_CC_OPTIMIZE_FOR_SIZE=n). Amerigo fixed this long-standing FIXME in the x86 version, but this patch is more general. This implements trim_init_extable(); most archs are simple since they use the standard lib/extable.c sort code. Alpha and IA64 use relative addresses in their fixups, so thier trimming is a slight variation. Sparc32 is unique; it doesn't seem to define ARCH_HAS_SORT_EXTABLE, yet it defines its own sort_extable() which overrides the one in lib. It doesn't sort, so we have to mark deleted entries instead of actually trimming them. Inspired-by: Amerigo Wang <amwang@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: linux-alpha@vger.kernel.org Cc: sparclinux@vger.kernel.org Cc: linux-ia64@vger.kernel.org
* lib/extable.c: remove an expensive integer divide in search_extable()Eric Dumazet2008-02-061-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actual code let compiler generates idiv instruction on x86. Using a right shift is OK here and readable as well. Before patch 10: 57 push %edi 11: 56 push %esi 12: 89 d6 mov %edx,%esi 14: 53 push %ebx 15: 89 c3 mov %eax,%ebx 17: eb 22 jmp 3b <search_extable+0x2b> 19: 89 f0 mov %esi,%eax 1b: ba 02 00 00 00 mov $0x2,%edx 20: 29 d8 sub %ebx,%eax 22: 89 d7 mov %edx,%edi 24: c1 f8 03 sar $0x3,%eax 27: 99 cltd 28: f7 ff idiv %edi 2a: 8d 04 c3 lea (%ebx,%eax,8),%eax 2d: 39 08 cmp %ecx,(%eax) ... After patch 00000010 <search_extable>: 10: 53 push %ebx 11: 89 c3 mov %eax,%ebx 13: eb 18 jmp 2d <search_extable+0x1d> 15: 89 d0 mov %edx,%eax 17: 29 d8 sub %ebx,%eax 19: c1 f8 04 sar $0x4,%eax 1c: 8d 04 c3 lea (%ebx,%eax,8),%eax 1f: 39 08 cmp %ecx,(%eax) ... Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Remove obsolete #include <linux/config.h>Jörn Engel2006-06-301-1/+0
| | | | | Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* [PATCH] powerpc: trivial: modify comments to refer to new location of filesJon Mason2006-02-101-1/+0
| | | | | | | | | This patch removes all self references and fixes references to files in the now defunct arch/ppc64 tree. I think this accomplises everything wanted, though there might be a few references I missed. Signed-off-by: Jon Mason <jdmason@us.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [PATCH] extable: remove needless declarationNicolas Pitre2005-10-311-3/+0
| | | | | | | | They aren't used anywhere in that file. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-171-0/+79
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!