Minor bug in 2.9 mknod(2)

[dudek at harvard.ARPA]

Description:
    There is a minor bug in the mknod(2) system call in sys2.c.  Mknod
calls namei to parse the pathname, and then examines the inode pointer
returned to see if the file already exists.  If it does, then it returns
the error EEXISTS.  If it does not exist, then it goes ahead and tries
to allocate a new inode, WITHOUT checking the error status from namei.
If (for instance) part of the path does not exist, instead of returning
ENOENT (No such file or directory), mknod goes ahead and tries to get an
inode, more often than not resulting in a failed getfs() (trying to find
the filesystem the non-existent parent lives on) and a return
of ENOSPC (No space left on device).

Repeat-by:
    Try "mknod /foo/tty00 c 1 0", (where /foo is some directory
which does not exist) preferably from the console.  You will
get a kernel console printf of "No fs on dev #, #",
and "No space left on device" from mknod(8).

Fix:
    After the section of code in mknod() in sys2.c which ensures the
return value from namei() is NULL, add the test:

	if (u.u_error)
	    return;

Exciting, no?  At least I wasn't out of inodes like I thought at first.

		Glen Dudek
		harvard!dudek, dudek at harvard.ARPA, dudek%HARVUNXH.BITNET