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.
Regards,
Bill
--------------118B41BA4080177931C67FCA
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) &&
--------------118B41BA4080177931C67FCA--