diff options
| author | Roman Zippel <zippel@linux-m68k.org> | 2005-05-31 14:39:29 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-05-31 14:54:18 -0700 |
| commit | ae92ef8a442421356950a0a8dfdc35e8e783000e (patch) | |
| tree | ddfad1eff028815ff32fd9f21b6e18df4e3804ae | |
| parent | f50734569c25c4e902bd3d0fb2e5bd93a200cc75 (diff) | |
| download | linux-3.10-ae92ef8a442421356950a0a8dfdc35e8e783000e.tar.gz linux-3.10-ae92ef8a442421356950a0a8dfdc35e8e783000e.tar.bz2 linux-3.10-ae92ef8a442421356950a0a8dfdc35e8e783000e.zip | |
[PATCH] flush icache in correct context
flush_icache_range() is used in two different situation - in binfmt_elf.c &
co for user space mappings and module.c for kernel modules. On m68k
flush_icache_range() doesn't know which data to flush, as it has separate
address spaces and the pointer argument can be valid in either address
space.
First I considered splitting flush_icache_range(), but this patch is
simpler. Setting the correct context gives flush_icache_range() enough
information to flush the correct data.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| -rw-r--r-- | kernel/module.c | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/kernel/module.c b/kernel/module.c index 5734ab09d3f..83b3d376708 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -1758,6 +1758,7 @@ sys_init_module(void __user *umod, const char __user *uargs) { struct module *mod; + mm_segment_t old_fs = get_fs(); int ret = 0; /* Must have permission */ @@ -1775,6 +1776,9 @@ sys_init_module(void __user *umod, return PTR_ERR(mod); } + /* flush the icache in correct context */ + set_fs(KERNEL_DS); + /* Flush the instruction cache, since we've played with text */ if (mod->module_init) flush_icache_range((unsigned long)mod->module_init, @@ -1783,6 +1787,8 @@ sys_init_module(void __user *umod, flush_icache_range((unsigned long)mod->module_core, (unsigned long)mod->module_core + mod->core_size); + set_fs(old_fs); + /* Now sew it into the lists. They won't access us, since strong_try_module_get() will fail. */ stop_machine_run(__link_module, mod, NR_CPUS); |