Messages in this thread | | | Date | Tue, 19 Oct 1999 07:59:54 +0100 (BST) | From | Tigran Aivazian <> | Subject | Re: access_ok inside kernelspace |
| |
Hi Alan (and the World),
You said recently: ----------------------------- begin > mm_segment_t fs;
fs=get_fs(); set_fs(get_ds());
/* User space is now the kernel */
/* Put it back again */
set_fs(fs);
------------------------------- end >
However, it seems to be not *always* safe. Please have a look at this tiny piece of code, if you have 2 minutes:
int __init init_bfs_fs(void) { int error; mm_segment_t fs;
error = register_filesystem(&bfs_fs_type); if (error) return error; fs = get_fs(); set_fs(get_ds()); bfs_fsindex = sysfs(1, (unsigned long)"bfs", 0); set_fs(fs); return bfs_fsindex < 0 ? -EINVAL : 0; }
(where sysfs() is pulled in via _syscall3() from <asm/unistd.h> and errno is exported and __KERNEL_SYSCALLS__ is defined, of course).
It works fine if the filesystem is already loaded (insmod bfs or statically linked) and then mounted but oopses (in request_module() from get_fs_type()) if it is autoloaded from within mount(2) system call.
So, the moral (temporary moral, until I see the picture clearer) of the story is: do not use system calls from within system calls. Is this correct or is it a bug that I should try to fix?
If the above behaviour is correct then I would appreciate anyone suggesting some ideas on how to get at fs_index() value without exporting fs_index() and without doing the syscall trick above. (I abandon my earlier idea of exporting fs_index() because I believe all accesses to file_systems should go through rw spinlock and it (nor fs_name nor fs_maxindex) shouldn't be exported until that is done).
Al Viro suggested adding a field to struct file_system_type which is initialized by register_filesystem(), which seems to be a good idea. If no-one suggests anything better I will do so. (I *really* need fs_index() value - pretty please :)
Regards, ------ Tigran A. Aivazian | http://www.sco.com Escalations Research Group | tel: +44-(0)1923-813796 Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |