Subject: Re: More LFS Woes
To: Konrad Schroder <firstname.lastname@example.org>
From: Gary Duzan <email@example.com>
Date: 02/03/2003 00:19:27
In Message <Pine.NEB.firstname.lastname@example.org> ,
Konrad Schroder <email@example.com> wrote:
=>On Sun, 2 Feb 2003, Gary Duzan wrote:
=>> #13 0xc01c18cb in lfs_remove (v=0xe411bcbc)
=>> at /usr/src/sys/ufs/lfs/lfs_vnops.c:632
=>> #14 0xc01c6da8 in ufs_rename (v=0xe411be70) at /usr/src/sys/sys/vnode_if.h:686
=>> #15 0xc01c1f0f in lfs_rename (v=0xe411be70)
=>> at /usr/src/sys/ufs/lfs/lfs_vnops.c:741
=>> Any ideas about what is going on here? I have a good core dump,
=>> and I can reliably recreate the problem, so suggestions on things
=>> to check and/or try would be appreciated.
=>I think you should be able to duplicate this condition by something like
=> cd /my/lfs
=> : > foo
=> ln foo bar
=> mv foo bar
=>at least, that should duplicate your stack trace.
It did duplicate the condition.
=> The problem that causes
=>this assertion failure is that lfs_remove is being called while the
=>original dirop (lfs_rename) is still active on the same inode.
I knew that looked screwy...
=> I've just
=>committed the obvious fix for that, although it's not immediately clear
=>that this double-dirop is the cause of your original problem.
Well, it fixed the immediate problem, anyway. The above example
is fixed and the build completes normally. I haven't worked out
all the details, but I think it fixes the original problem, too,
since we've eliminated the bogus call path, ufs_rename -> lfs_remove
-> lfs_set_dirop -> lfs_reserve -> lfs_reservebuf, which updates
the counter. I didn't see the lfs_fits_buf warning during the build,
either, so I think we can call it fixed for now.