Re: rename() making ext2fs going bonkers? (was: interested in an account)

[Samuel Thibault]

Hello,

Thomas Schwinge, le Sat 03 Oct 2009 12:31:22 +0200, a écrit :
> Hello!
> 
> On Fri, Oct 02, 2009 at 10:01:22AM -0600, Eric Blake wrote:
> > However, I'm wondering if I just tickled a bug that hung flubber;
> > I was running the gnulib test for rename(2), and lost all response from
> > the machine.  After killing that make process, even simple commands like
> > "ls" failed to do anything for several seconds; when I hit Ctrl-C, I got:
> > 
> > $ ls
> > ^Cls: cannot open directory .: Interrupted system call
> > 
> > and after I exited my ssh session, I can't seem to get back on.
> 
> Yes, such things still happen on Hurd systems :-)...  If this turns out
> to be reproducible, we'll obviously have a bigger chance of getting an
> understanding of this failure, and fixing it.

It seems to be

rename("dir2", "dir/.");

with dir/ existing, which is hanging, I'm getting the following
backtrace in gdb:

#0  0x010e78bc in ?? () from /lib/libc.so.0.3
#1  0x010e8110 in mach_msg () from /lib/libc.so.0.3
#2  0x010b3602 in cproc_block ()
    at /var/tmp/hurd-20090404/./libthreads/cprocs.c:643
#3  0x010b3c7e in __mutex_lock_solid (ptr=0x8069814)
    at /var/tmp/hurd-20090404/./libthreads/cprocs.c:955
#4  0x080544c3 in diskfs_cached_lookup (inum=13, npp=0x12fbb18)
    at /var/tmp/hurd-20090404/./ext2fs/inode.c:79
#5  0x0804df9f in diskfs_lookup_hard (dp=0x8069358, name=0x1059248 ".", 
    type=REMOVE, npp=0x12fbbdc, ds=0x12fbb90, cred=0x80681f0)
    at /var/tmp/hurd-20090404/./ext2fs/dir.c:257
#6  0x010557bc in diskfs_lookup (dp=0x8069358, name=0x1059248 ".", 
    type=REMOVE, np=0x12fbbdc, ds=0x12fbb90, cred=0x80681f0)
    at /var/tmp/hurd-20090404/./libdiskfs/lookup.c:177
#7  0x010424e0 in diskfs_clear_directory (dp=0x8069358, pdp=0x8069358, 
    cred=0x80681f0) at /var/tmp/hurd-20090404/./libdiskfs/dir-clear.c:33
#8  0x01045144 in diskfs_rename_dir (fdp=0x8060aa0, fnp=0x8069778, 
    fromname=0x12fdf6c "dir2", tdp=0x8069358, toname=0x12fe378 ".", 
    fromcred=0x8061e10, tocred=0x80681f0)
    at /var/tmp/hurd-20090404/./libdiskfs/dir-renamed.c:191
#9  0x010444fb in diskfs_S_dir_rename (fromcred=0x8061e10, 
    fromname=0x12fdf6c "dir2", tocred=0x80681f0, toname=0x12fe378 ".", excl=0)
    at /var/tmp/hurd-20090404/./libdiskfs/dir-rename.c:78

The obvious issue is that rename_dir is passed "." as toname and not the
actual directory name, but since that's what the RPC asked, we have to
cope with, but we don't and try to lock toname twice.  Since POSIX says
“[EINVAL] ^[CX] The old pathname names an ancestor directory of the
new pathname, or either pathname argument contains a final component
that is dot or dot-dot.”, we could just refuse "." and ".." from
diskfs_S_dir_rename with EINVAL?

Samuel

BTW, all of this can be debugged as a mere user:

dd < /dev/zero > blip
mke2fs -o hurd blip
settrans -ca blop /hurd/ext2fs $PWD/blip

and then attaching gdb to that ext2fs.