Re: Using get_cwd inside a module.

From: Szymon Acedański
Date: Sat Nov 22 2003 - 07:38:42 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/