This is probably a stupid question, and probably directed to the wrong
list. Apologies in advance, but I'm stumped
I've been working on a kernel module to report on "changed files". It
works just fine -- I wrap the orignal system calls with my
replacements which queue the filenames being modified, and when
another proccess reads from the device or proc entry, they get a nice
snapshot of what's going on in the system -- except that all the paths
are relative to the calling process.
So, a little ignorance being a dangerous thing, I thought I'd be clever
and manually reconstruct the full path by walking up
current->fs->pwd->d_parent and padding d_name to the filename until it
hits root.
Unfortunatly, this approach causes kernel panics. e.g., the attached
code snippet will inevitably bring down the machine if I call it
during in my replacement open, mkdir, rmdir, unlink routines -- and
tehy all work fine without itq.
What am I not getting? I do see, before I go down, that there's a few
occasions where current() is NULL...
Apologies in advance for a wordy, probably stupid question, but I'm
stumped.
If this is not the right approach for what I'm trying to do (e.g. a
kernel space getcwd()), can someone point me to something else I can try?
Thanks in advance,
Mike Welles
----------------------------------------
(this is the greatly reduced version which does nothing but try and
reference current->fs->pwd)
void fill_full_path(char *name)
{
if (current==NULL)
{
#ifdef DEBUG
printk("ERROR! current == NULL\n");
#endif
return;
}
if (current->fs==NULL)
{
#ifdef DEBUG
printk("ERROR! current-> == NULL\n");
#endif
return;
}
if (current->fs->pwd==NULL)
{
#ifdef DEBUG
printk("ERROR! current->fs->pwd == NULL\n");
#endif
return;
}
return;
}
This is probably a stupid question: I've been working on a kernel
module to report on "changed files".
It works just fine -- I wrap the orignal system calls with my
replacements which queue the filenames being modified, and when
another proccess reads from the device or proc entry, they get a nice
snapshot of what's going on in the system -- except that all the paths
are relative to the calling process.
So, a little ignorance being a dangerous thing, I thought I'd be clever
and manually reconstruct the full path by walking up
current->fs->pwd->d_parent and padding d_name to the filename until it
hits root.
Unfortunatly, this approach causes kernel panics. e.g., the attached
code snippet will inevitably bring down the machine if I call it
during in my replacement open, mkdir, rmdir, unlink routines -- and
tehy all work fine without itq.
What am I not getting? I do see, before I go down, that there's a few
occasions where current() is NULL...
Apologies in advance for a wordy, probably stupid question, but I'm
stumped.
If this is not the right approach for what I'm trying to do (e.g. a
kernel space getcwd()), can someone point me to where I should look?
Thanks in advance,
Mike Welles
----------------------------------------
(this is the greatly reduced version which does nothing but try and
reference current->fs->pwd)
void fill_full_path(char *name)
{
if (current==NULL)
{
#ifdef DEBUG
printk("ERROR! current == NULL\n");
#endif
return;
}
if (current->fs==NULL)
{
#ifdef DEBUG
printk("ERROR! current-> == NULL\n");
#endif
return;
}
if (current->fs->pwd==NULL)
{
#ifdef DEBUG
printk("ERROR! current->fs->pwd == NULL\n");
#endif
return;
}
return;
}
In article <[email protected]> you wrote:
> So, a little ignorance being a dangerous thing, I thought I'd be clever
> and manually reconstruct the full path by walking up
> current->fs->pwd->d_parent and padding d_name to the filename until it
> hits root.
>
> Unfortunatly, this approach causes kernel panics. e.g., the attached
> code snippet will inevitably bring down the machine if I call it
> during in my replacement open, mkdir, rmdir, unlink routines -- and
> tehy all work fine without itq.
Use d_path. NOTE: the buffer in which the pathname is returned is
the return value of the function and _not_ the buffer you gave to it.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
> This is probably a stupid question, and probably directed to the wrong
> list. Apologies in advance, but I'm stumped
>
> I've been working on a kernel module to report on "changed files". It
> works just fine -- I wrap the orignal system calls with my
> [...]
At least in the 2.4 kernels, there's already a __d_path() routine (fs/dcache.c)
that builds the pathname using the mechanism you discussed.
Here's one way you could use it:
char *
kgetcwd()
{
char *path = (char *) __get_free_page(GFP_USER);
struct vfsmnt *pwdmnt;
struct dentry *pwd;
if (!path)
return ERR_PTR(-ENOMEM);
read_lock(¤t->fs->lock);
pwdmnt = mntget(current->fs->pwdmnt);
pwd = dget(current->fs->pwd);
read_unlock(¤t->fs->lock);
spin_lock(&dcache_lock);
path = __d_path(pwd, pwdmnt, NULL, NULL, path, PAGE_SIZE);
spin_unlock(&dcache_lock);
mntput(pwdmnt);
dput(pwd);
return path;
}
If you only want the pathname back to the process root, use d_path() instead
(and don't grab the dcache_lock).
When you're done with path, free it with free_page() and not kfree().
BTW, I'm not subscribed to the kernel mailing list (I just read it on the web),
so please copy me on any response.
--
Brian Watson
Compaq Computer
"Brian J. Watson" wrote:
> path = __d_path(pwd, pwdmnt, NULL, NULL, path, PAGE_SIZE);
Oops! That's no good. Here's the new and improved version:
char *
kgetcwd(char **bufp)
{
char *path, *buf = (char *) __get_free_page(GFP_USER);
struct vfsmnt *pwdmnt;
struct dentry *pwd;
*bufp = NULL;
if (!buf)
return ERR_PTR(-ENOMEM);
read_lock(¤t->fs->lock);
pwdmnt = mntget(current->fs->pwdmnt);
pwd = dget(current->fs->pwd);
read_unlock(¤t->fs->lock);
spin_lock(&dcache_lock);
path = __d_path(pwd, pwdmnt, NULL, NULL, buf, PAGE_SIZE);
spin_unlock(&dcache_lock);
mntput(pwdmnt);
dput(pwd);
*bufp = buf;
return path;
}
The returned pointer is for the beginning of the path name. The pointer filled
into bufp is for the beginning of the allocated space. To deallocate, call
free_page() on the value in bufp.
The reason for the distinction is that __d_path builds the pathname from the end
of the buffer, working its way back toward the beginning. Rarely will the string
begin at the same address as the allocated buffer.
--
Brian Watson
Compaq Computer