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:

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); 
  1  21969                vn_vfswlock:entry 0xffffff04f3139600
  1  21970               vn_vfswlock:return 0x10
  1  19881                  set_errno:entry

so vn_vfswlock() (called from umount2_engine()) is failing here:
        if (rwst_tryenter(&vpvfsentry->ve_lock, RW_WRITER))
                return (0);

zones-discuss mailing list

Reply via email to