On Tue, Oct 27, 2009 at 07:27:10PM -0700, Dan Price wrote:
> On Tue 27 Oct 2009 at 07:03PM, Edward Pilatowicz wrote:
> >
> > the assumption is that we will never get stuck in this forever. if we
> > do then this fix is broken and we need to redesign the exit mechanism.
> > (i was debating just calling exit(0) instead of fdetach(), but iirc you
> > spent a while coming up with the door thread exit dance, hence and i
> > didn't want to change it too much.)
>
> Fair enough.
>
> > my assumption is that in this case we want to exit as quickly as
> > possible. By doing a yeild, i'm assuming that the doors thread in our
> > process should get scheduled before we do and hopefully finish up it's
> > work, there by allow us to exit (and not spinning too much).
>
> Thanks for filing the related bug.
>
> Did you catch this in action, with dtrace to know where that EBUSY
> is coming from? If we knew what was doing set_errno(EBUSY)...
>
well, i was running zts and i discovered that zoneadm and zoneadmd were
both spinning. after doing a code inspection of zoneadmd i determined
that the only way we could get into this situation was for fdetach() to
return EBUSY. so i wrote a test program to verify that it was possible
for fdetach() to return EBUSY for a door. (the test program is attached
to the bug report.)
so i just ran my test program again after activating the following
dtrace probe:
---8<---
e...@mcescher$ dtrace \
-n 'fbt::vn_vfswlock:entry/execname == "a.out"/{printf("0x%x", arg0)}' \
-n 'fbt::vn_vfswlock:return/execname == "a.out"/{printf("0x%x", arg1)}' \
-n 'fbt::set_errno:entry/execname == "a.out" && arg0 == 16/{stack(20);
exit(0);}'
...
1 21969 vn_vfswlock:entry 0xffffff04f3139600
1 21970 vn_vfswlock:return 0x10
1 19881 set_errno:entry
genunix`umount2_engine+0xa5
genunix`umount2+0x142
unix`_sys_sysenter_post_swapgs+0x149
---8<---
so vn_vfswlock() (called from umount2_engine()) is failing here:
---8<---
if (rwst_tryenter(&vpvfsentry->ve_lock, RW_WRITER))
return (0);
---8<---
ed
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
