Re: Rootfs mounted from user space - problem with umount

[William Lee Irwin III]

William Lee Irwin III wrote:
>> Could you do a sysrq t and send in a backtrace?

On Sat, Nov 29, 2003 at 01:14:34AM -0500, John Zielinski wrote:
> Here's the trace for umount:
> umount        D DF9D98C0  3920   380    245                     (NOTLB)
[...]
> Call Trace:
> [<c015be66>] path_release+0x16/0x40
> [<c0169f59>] umount_tree+0xa9/0x100
> [<c01e169c>] rwsem_down_write_failed+0x8c/0x140
> [<c0155e0b>] .text.lock.super+0x12/0x187
> [<c016a22c>] sys_umount+0x3c/0x90
> [<c016a299>] sys_oldumount+0x19/0x20
> [<c010938f>] syscall_call+0x7/0xb

Looks like either namespace->sem or sb->s_umount; you should be able
to put some instrumentation code in down_write() and/or down_read() to
see who acquired it first by checking to see if the sem acquired belongs
to rootfs' sb or some namespace (doubtful you'll create many of them).


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/