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

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

The following reply was made to PR kern/50659; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Sebastian Ponitka <sebastian%xenoserver.net@localhost>
Cc: gnats-bugs%netbsd.org@localhost, port-xen-maintainer%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: port-xen/50659: Xen4.5 crash with vnds
Date: Wed, 23 Mar 2016 00:05:45 +0700

     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