Re: port-xen/50659: Xen4.5 crash with vnds

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 16 Jan 2016 13:09:29 -0800
    From:        John Nemeth <jnemeth%cue.bc.ca@localhost>
    Message-ID:  <201601162109.u0GL9TvZ016963%server.CornerstoneService.ca@localhost>

  |      I can't say with certainty, but I doubt that cloning devices
  | will work with static configuration.  They are setup and operate
  | differently.

They should work just fine, at least vnd should, all that should be
required is to open the device and configure it, cloning driver or not.

What the cloning changes is that the kernel no longer has a fixed upper
bound on the number of devices, so all you need to create them is to
mknod in /dev (then reference the device).   And it is no longer rational
to attempt to list every possible vnd device, as there can be billions
(depending upon available kernel memory.)

Given that the error reported here is EBUSY, I looked in the driver for
causes for that.

There are just 3 uses of EBUSY in vnd.c (this output is from an annotated
listing of vnd.c from cvsweb)

1.221     mlelstv   350:        if (sc->sc_dkdev.dk_nwedges != 0 && part != RAW_PART) {
                    351:                error = EBUSY;
                    352:                goto done;
                    353:        }

but that one cannot be the cause, as it was reported on vnd0d which is
RAW_PART.

1.204     dyoung   1013:        if (DK_BUSY(vnd, pmask) && !force) {
1.199     dyoung   1014:                vndunlock(vnd);
                   1015:                return EBUSY;
                   1016:        }

but that is in the unconfigure case, which I doubt is relevant here.

1.17      cgd      1134:        case VNDIOCSET:
                   1135:                if (vnd->sc_flags & VNF_INITED)
1.197     dyoung   1136:                        return EBUSY;

which looks to be the most plausible, as it is in the "configure a vnd"
ioctl - and suggests that something thinks the config has already been done.
But that is fairly old code, so I looked to see if something new might be
setting VNF_INITED, but no, there is just one place it is set, also old code,
lower down in the ioctl code (line 1349 ...

1.17      cgd      1349:                vnd->sc_flags |= VNF_INITED;

which is truly ancient...   About the only other possibilities I can imagine
are that either the EBUSY is actually originating outside the vnd driver, in
one of the generic disk/wedge utility functions perhaps, or that somehow
the "wrong" vnd-> is being tested.

Do I understand correctly that the case that fails references "many" vnds,
(more than 4) ?   Do you have any idea which would be configured first?
And that if a config with < 4 vnds is set up first, the "big" one later
succeeds?

This may help figuring out what is going on .. which I am confident is
nothing at all related to vnd.c 1.134 - though that (without the corresponding
vnconfig change, which is still missing on the netbsd-7 branch) is the
cause of the 
	 vnconfig: VNDIOCGET: Device not configured
from vnconfig -l, but that is really just noise.   This won't be related
to the EBUSY problem at all.

kre