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/