summaryrefslogtreecommitdiffstats
path: root/fs/dnotify.c
diff options
context:
space:
mode:
authorMichael Ellerman <michael@ellerman.id.au>2007-07-19 01:48:11 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-07-19 10:04:44 -0700
commit3d7e33825d8799115dd2495c9944badd3272a623 (patch)
tree869eeefa9dd88c622db199f636cd1785c6099947 /fs/dnotify.c
parent9e367d859297b9377d65574f538cf52730e9eda8 (diff)
downloadkernel-crypto-3d7e33825d8799115dd2495c9944badd3272a623.tar.gz
kernel-crypto-3d7e33825d8799115dd2495c9944badd3272a623.tar.xz
kernel-crypto-3d7e33825d8799115dd2495c9944badd3272a623.zip
jprobes: make jprobes a little safer for users
I realise jprobes are a razor-blades-included type of interface, but that doesn't mean we can't try and make them safer to use. This guy I know once wrote code like this: struct jprobe jp = { .kp.symbol_name = "foo", .entry = "jprobe_foo" }; And then his kernel exploded. Oops. This patch adds an arch hook, arch_deref_entry_point() (I don't like it either) which takes the void * in a struct jprobe, and gives back the text address that it represents. We can then use that in register_jprobe() to check that the entry point we're passed is actually in the kernel text, rather than just some random value. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com> Acked-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/dnotify.c')
0 files changed, 0 insertions, 0 deletions