Messages in this thread | ![/](/images/icornerl.gif) | | From | Szymon Acedański <> | Subject | Re: Using get_cwd inside a module. | Date | Sat, 22 Nov 2003 13:30:00 +0100 |
| |
On Saturday 22 November 2003 01:32, Maciej Zenczykowski wrote: > > ))(sys_call_table[__NR_getcwd]); > > > > and use it as I used to: > > > > len = getcwd(fullnewname, MAX_PATH); > > sys_getcwd is the actual function name. > > > Everything built just fine, but whenever I load the module and the above > > statement runs, the function returns -14. This is true on my debian > > testing box, and also on my YDL 3.0 machine, where the old version (with > > the cut n' paste code) still runs just fine. > > Well -14 is EFAULT - i.e. memory protection failure. You are passing a > kernel area pointer (the buf) to a userspace oriented function - it checks > the access and fails it as the user process doesn't have access to the > kernel memory of your module (Ie it doesn't realise it is being called from > the kernel and checks whether the user process currently running would have > access to your modules memory (likely stack) - obviously it wouldn't and > thus it fails with -EFAULT. > > Don't think there is anyway around this - so you'll probably need to > cut'n'paste. On the other hand if such functionality is required it is > probably best to split the fs/dcache.c sys_getcwd implementation into two > pieces - the userspace verify wrapper and the function which performs the > actual work.
You can consider doing similar hack as kHTTPd does. It calls temporarily set_fs(KERNEL_DS), disabling memlimit checking, then calls userspace-aware function, and then restores everything back. Try looking at linux/net/khttpd/rfc.c:SendHTTPHeader (it's in 2.4 kernels, but not in 2.6).
Cheers accek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |