Re: Pre-45 oopses

Bill Hawes (
Fri, 11 Jul 1997 15:59:11 -0400

This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael L. Galbraith wrote:
> This oops is new to pre-45. It didn't eat the filesystem (spare :). System is
> up-to-the-usec tools/libs wise MMX-150-Overdrive. Oops is reproducable.

I've tracked down the apparent cause of the oops in permission(). If
the directory path includes a zombie entry, the call to permission is
made with a null inode, generating the message you reported.

I've attached a patch that tests for null and denies access, but it
seems like we really shouldn't have paths without inodes.

It's easy to reproduce the problem -- just create a directory tree, cd
to the bottom, then delete a parent. Now try echo hi > foo and you'll
trigger the message.

Content-Type: text/plain; charset=us-ascii; name="namei_45-patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="namei_45-patch"

--- fs/namei.c.old Wed Jul 9 07:18:26 1997
+++ fs/namei.c Fri Jul 11 15:40:18 1997
@@ -184,11 +184,19 @@
* We use "fsuid" for this, letting us set arbitrary permissions
* for filesystem access without changing the "normal" uids which
* are used for other things..
+ *
+ * WSH: Check for NULL inode (possibly a zombie in path?)
int permission(struct inode * inode,int mask)
- int mode = inode->i_mode;
+ int mode;

+ if (!inode) {
+printk("permission: null inode\n");
+ return -EACCES; /* deny access */
+ }
+ mode = inode->i_mode;
if (inode->i_op && inode->i_op->permission)
return inode->i_op->permission(inode, mask);
else if ((mask & S_IWOTH) && IS_RDONLY(inode) &&