Skip to contentSkip to conversation

kernel space getcwd()? (using current() to find out cwd)

DISCUSSION Michael L. Welles 2 participants 2 messages Apr 16, 2001 – Apr 17, 2001

lore
Share & tools
lore
#0 lore raw

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; 
}
#1 lore raw
Quoted 9 lines · 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

Signature · 1 line
Of course it doesn't work. We've performed a software upgrade.