VFS_OPEN Always Failing in Shell Mode


(Zachary Scott Moore) #1

Is there any reason that Vfs_open would be failing in shell mode?

I am making sure to kstrdup the string as to not destroy the path name.

All of the opentests and badcalls pass in kernel mode however, in shell mode whenever any call to open that includes looking at a pre-existing file happens vfs_open fails on a file not found error. Even the basic opentest will not work in shell mode and will fail the test.

vfs_lookparent within vfs_open is causing the issue.


(Matthew Mc Govern) #2

It’s likely that an argument is getting mangled, or an incorrect argument is being passed into the function. Have you verified that things look correct before the call with gdb?


(Zachary Scott Moore) #3

In gdp the filename printed as passed in is the exact filename that should be appearing.

After I copyin to check that the string is valid I kstrdup the userptr_t casted as a char * into a variable and pass it in.

What is so confusing is that only in the shell is this an issue.


(Matthew Mc Govern) #4

It is confusing, though it’s possible that checking into the difference between the those launch modes might shed some light on the problem.


(Zachary Scott Moore) #5

I was able to get open to work in shell by adding a ‘/’ in front of path name.

However, this feels like a very stupid fix and does not make sense.


(Scott Haseley) #6

Hmm, is it possible you’ve broken the current working dir of a newly created process somewhere along the way? Adding “/” sounds like it’s changing it from a relative path to an absolute one.


(Zachary Scott Moore) #7

I never explicitly set current working directory to the process.

Also testing chdir works in kernel as well as shell. pwd does not work in shell but does in kernel. Is it possible getcwd is called in the background somewhere, doesn’t properly work and then vfs_lookup fails?

I tried searching through the code and adding print lines in the syscall however I cannot seem to find it called anywhere.


(Scott Haseley) #8

Yes, I believe it is possible, though not exactly getcwd(). Looking at the call chain a bit, vfs_lookup() calls get_device() calls vfs_getcurdir(). Actually, look at the comments of where vfs_getcurdir() is called in get_device() (this is pretty much what I said in the prev post), and also, look at vfs_getcurdir(). The latter is a very short function, and I suspect this is this is the error you’re getting. It should hopefully give you something to go on.


(Zachary Scott Moore) #9

Thank you very much I noticed cwd was initialized to null however was unsure why it was not causing issues. Looks like this is a step in the right direction.

I guess just as a follow up, the tests I fail currently are not related to adding the ‘/’. Since we don’t really impose restrictions on where files are writable would there ever be issues with saying the path is always a direct path by adding a ‘/’ if one does not exist in the pathname? In real world applications there would definitely be issues but as far as tests are concerned any file created would be tossed in / and since we use the same file name it is readable from the same path as well.


(Geoffrey Challen) #10

That’s gross. Something is broken here. Better to fix it before it causes more problems.


(Zachary Scott Moore) #11

Yes it was very gross. I found out the root cause of the issue and got it fixed however it is possible to get a 150 on the assignment with the adding ‘/’ method.


(Geoffrey Challen) #12

Yeah… we’ll add a check for this at some point. (Just cding around a bit will do it.)