I'm using 2.1.59-vger-vs-972010
do_mount calls add_vfsmnt, but if it then fails to read the super_block, it'll
jump directly to dput_and_out without calling remove_vfsmnt again. This leaves
the half-made vfsmnt entry in the table, which causes the later oops when the
table is scanned.
If this is fixed already, then perhaps I should ditch the CVS series and go
back to 2.1.60. I tried that the other day, though, and it didn't even boot;
it just rebooted halfway through the init sequence. I decided to leave it
until the 2.1.x and CVS trees were vaguely related to each other before trying
to switch back.
Extract from super.c:
if ((vfsmnt = lookup_vfsmnt(dev)) == (struct vfsmount *) NULL)
vfsmnt = add_vfsmnt(dev, dev_name, dir_name);
if (vfsmnt) {
/*
* Check whether to read the super block
*/
sb = get_super(dev);
if (!sb || !sb->s_root) {
error = -EINVAL;
sb = read_super(dev,type,flags,data,0);
if (!sb)
goto dput_and_out;
}
< ... >
dput_and_out:
dput(dir_d);
#ifdef PATCHED_BY_DAVE
if (vfsmnt) /* If I hadn't put this in, */
remove_vfsmnt(dev); /* the half-initialised vfsmnt */
#endif /* entry would be left in the table. */
out:
up(&mount_sem);
return error;