Date: Sun, 6 Feb 2022 12:03:07 +0100 From: Stefan Esser <se@FreeBSD.org> To: Michael Jung <mikej@paymentallianceintl.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: pciconf -lbvV crashes kernel main-8d72c409c Message-ID: <016bb393-9f4a-cefa-858f-aef7ce41e640@FreeBSD.org> In-Reply-To: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local> References: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------ofK5ce99cbe2nKle3Bm9SEq6
Content-Type: multipart/mixed; boundary="------------EpAH2XZhPiiWbbYUDyouNveM";
protected-headers="v1"
From: Stefan Esser <se@FreeBSD.org>
To: Michael Jung <mikej@paymentallianceintl.com>
Cc: freebsd-current <freebsd-current@freebsd.org>
Message-ID: <016bb393-9f4a-cefa-858f-aef7ce41e640@FreeBSD.org>
Subject: Re: pciconf -lbvV crashes kernel main-8d72c409c
References: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local>
In-Reply-To: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local>
--------------EpAH2XZhPiiWbbYUDyouNveM
Content-Type: multipart/mixed; boundary="------------4l5O0uW3zUcOq38cVYbzEyob"
--------------4l5O0uW3zUcOq38cVYbzEyob
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Am 06.02.22 um 01:19 schrieb Michael Jung:
> Dump header from device: /dev/ada0p2
> Architecture: amd64
> Architecture Version: 2
> Dump Length: 900231168
> Blocksize: 512
> Compression: none
> Dumptime: 2022-02-04 15:48:08 -0500
> Hostname: draid.mikej.com
> Magic: FreeBSD Kernel Dump
> Version String: FreeBSD 14.0-CURRENT #1 main-8d72c409c: Thu Feb 3 18:14=
:01 EST 2022
> mikej@draid:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> Panic String: length mismatch
> Dump Parity: 1692982593
> Bounds: 2
> Dump Status: good
This is caused by the following code fragments:
/*
* Calculate the amount of space needed in the data buffer. An
* identifier element is always present followed by the read-only=
* and read-write keywords.
*/
len =3D sizeof(struct pci_vpd_element) + strlen(vpd->vpd_ident);
for (i =3D 0; i < vpd->vpd_rocnt; i++)
len +=3D sizeof(struct pci_vpd_element) + vpd->vpd_ros[i]=
=2Elen;
for (i =3D 0; i < vpd->vpd_wcnt; i++)
len +=3D sizeof(struct pci_vpd_element) + vpd->vpd_w[i].l=
en;
[...]
vpd_user =3D lvio->plvi_data;
[...]
vpd_user =3D PVE_NEXT_LEN(vpd_user, vpd_element.pve_datalen);
vpd_element.pve_flags =3D 0;
for (i =3D 0; i < vpd->vpd_rocnt; i++) {
vpd_element.pve_keyword[0] =3D vpd->vpd_ros[i].keyword[0]=
;
vpd_element.pve_keyword[1] =3D vpd->vpd_ros[i].keyword[1]=
;
vpd_element.pve_datalen =3D vpd->vpd_ros[i].len;
error =3D copyout(&vpd_element, vpd_user, sizeof(vpd_elem=
ent));
if (error)
return (error);
error =3D copyout(vpd->vpd_ros[i].value, vpd_user->pve_data,
vpd->vpd_ros[i].len);
if (error)
return (error);
vpd_user =3D PVE_NEXT_LEN(vpd_user, vpd_element.pve_datal=
en);
}
vpd_element.pve_flags =3D PVE_FLAG_RW;
for (i =3D 0; i < vpd->vpd_wcnt; i++) {
vpd_element.pve_keyword[0] =3D vpd->vpd_w[i].keyword[0];
vpd_element.pve_keyword[1] =3D vpd->vpd_w[i].keyword[1];
vpd_element.pve_datalen =3D vpd->vpd_w[i].len;
error =3D copyout(&vpd_element, vpd_user, sizeof(vpd_elem=
ent));
if (error)
return (error);
error =3D copyout(vpd->vpd_w[i].value, vpd_user->pve_data=
,
vpd->vpd_w[i].len);
if (error)
return (error);
vpd_user =3D PVE_NEXT_LEN(vpd_user, vpd_element.pve_datal=
en);
}
KASSERT((char *)vpd_user - (char *)lvio->plvi_data =3D=3D len,
("length mismatch"));
The KASSERT triggered, indicating that a different amount of data has bee=
n
fetched than has previously been calculated.
It would be interesting to compare the pre-computed "len" and the actual
amount of data (i.e. the operands of =3D=3D in the KASSERT).
The definition of PVE_NEXT_LEN looks correct, but in order to completely
understand what the issue is, a dump of the VPD range should be analyzed
(or you could add trace output to both the calculation of "len" and to
the fetching of the VPD data that advances vpd_user).
Regards, STefan
PS: You may want to build a kernel with the attached patch, which prints
the calculated lengths after each element that is added to "len".
The KASSERT will only trigger if the actual length exceeds the expect=
ed
value, and the printf() output should go to the console device.
My system does not seem to have a single device that provides VPD,
therefore the patch has only been compile tested ...
--------------4l5O0uW3zUcOq38cVYbzEyob
Content-Type: text/plain; charset=UTF-8; name="pci_user.diff"
Content-Disposition: attachment; filename="pci_user.diff"
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL3N5cy9kZXYvcGNpL3BjaV91c2VyLmMgYi9zeXMvZGV2L3BjaS9wY2lf
dXNlci5jCmluZGV4IGE1Zjg0OWU4NWMyZC4uYzc3MWRiMGI1MDcwIDEwMDY0NAotLS0gYS9z
eXMvZGV2L3BjaS9wY2lfdXNlci5jCisrKyBiL3N5cy9kZXYvcGNpL3BjaV91c2VyLmMKQEAg
LTU2NSw2ICs1NjUsNyBAQCBwY2lfbGlzdF92cGQoZGV2aWNlX3QgZGV2LCBzdHJ1Y3QgcGNp
X2xpc3RfdnBkX2lvICpsdmlvKQogCXNpemVfdCBsZW47CiAJaW50IGVycm9yLCBpOwogCisJ
cHJpbnRmKCIlcCAvICVwXG4iLCBsdmlvLT5wbHZpX2RhdGEsIFBWRV9ORVhUX0xFTihsdmlv
LT5wbHZpX2RhdGEsIDEpKTsKIAl2cGQgPSBwY2lfZmV0Y2hfdnBkX2xpc3QoZGV2KTsKIAlp
ZiAodnBkLT52cGRfcmVnID09IDAgfHwgdnBkLT52cGRfaWRlbnQgPT0gTlVMTCkKIAkJcmV0
dXJuIChFTlhJTyk7CkBAIC01NzUsMTAgKzU3NiwxNSBAQCBwY2lfbGlzdF92cGQoZGV2aWNl
X3QgZGV2LCBzdHJ1Y3QgcGNpX2xpc3RfdnBkX2lvICpsdmlvKQogCSAqIGFuZCByZWFkLXdy
aXRlIGtleXdvcmRzLgogCSAqLwogCWxlbiA9IHNpemVvZihzdHJ1Y3QgcGNpX3ZwZF9lbGVt
ZW50KSArIHN0cmxlbih2cGQtPnZwZF9pZGVudCk7Ci0JZm9yIChpID0gMDsgaSA8IHZwZC0+
dnBkX3JvY250OyBpKyspCisJcHJpbnRmKCJMRU4oJWQpOiAlbHVcbiIsIC0xLCBsZW4pOwor
CWZvciAoaSA9IDA7IGkgPCB2cGQtPnZwZF9yb2NudDsgaSsrKSB7CiAJCWxlbiArPSBzaXpl
b2Yoc3RydWN0IHBjaV92cGRfZWxlbWVudCkgKyB2cGQtPnZwZF9yb3NbaV0ubGVuOwotCWZv
ciAoaSA9IDA7IGkgPCB2cGQtPnZwZF93Y250OyBpKyspCisJCXByaW50ZigiTEVOKCVkKTog
JWx1XG4iLCBpLCBsZW4pOworCX0KKwlmb3IgKGkgPSAwOyBpIDwgdnBkLT52cGRfd2NudDsg
aSsrKSB7CiAJCWxlbiArPSBzaXplb2Yoc3RydWN0IHBjaV92cGRfZWxlbWVudCkgKyB2cGQt
PnZwZF93W2ldLmxlbjsKKwkJcHJpbnRmKCJMRU4oJWQpOiAlbHVcbiIsIGksIGxlbik7CisJ
fQogCiAJaWYgKGx2aW8tPnBsdmlfbGVuID09IDApIHsKIAkJbHZpby0+cGx2aV9sZW4gPSBs
ZW47CkBAIC02MDYsNiArNjEyLDcgQEAgcGNpX2xpc3RfdnBkKGRldmljZV90IGRldiwgc3Ry
dWN0IHBjaV9saXN0X3ZwZF9pbyAqbHZpbykKIAlpZiAoZXJyb3IpCiAJCXJldHVybiAoZXJy
b3IpOwogCXZwZF91c2VyID0gUFZFX05FWFRfTEVOKHZwZF91c2VyLCB2cGRfZWxlbWVudC5w
dmVfZGF0YWxlbik7CisJcHJpbnRmKCJMRU4oJWQpOiAlbHVcbiIsIC0xLCAoc2l6ZV90KSgo
Y2hhciAqKXZwZF91c2VyIC0gKGNoYXIgKilsdmlvLT5wbHZpX2RhdGEpKTsKIAl2cGRfZWxl
bWVudC5wdmVfZmxhZ3MgPSAwOwogCWZvciAoaSA9IDA7IGkgPCB2cGQtPnZwZF9yb2NudDsg
aSsrKSB7CiAJCXZwZF9lbGVtZW50LnB2ZV9rZXl3b3JkWzBdID0gdnBkLT52cGRfcm9zW2ld
LmtleXdvcmRbMF07CkBAIC02MTksNiArNjI2LDcgQEAgcGNpX2xpc3RfdnBkKGRldmljZV90
IGRldiwgc3RydWN0IHBjaV9saXN0X3ZwZF9pbyAqbHZpbykKIAkJaWYgKGVycm9yKQogCQkJ
cmV0dXJuIChlcnJvcik7CiAJCXZwZF91c2VyID0gUFZFX05FWFRfTEVOKHZwZF91c2VyLCB2
cGRfZWxlbWVudC5wdmVfZGF0YWxlbik7CisJCXByaW50ZigiTEVOKCVkKTogJWx1XG4iLCBp
LCAoc2l6ZV90KSgoY2hhciAqKXZwZF91c2VyIC0gKGNoYXIgKilsdmlvLT5wbHZpX2RhdGEp
KTsKIAl9CiAJdnBkX2VsZW1lbnQucHZlX2ZsYWdzID0gUFZFX0ZMQUdfUlc7CiAJZm9yIChp
ID0gMDsgaSA8IHZwZC0+dnBkX3djbnQ7IGkrKykgewpAQCAtNjMzLDggKzY0MSw5IEBAIHBj
aV9saXN0X3ZwZChkZXZpY2VfdCBkZXYsIHN0cnVjdCBwY2lfbGlzdF92cGRfaW8gKmx2aW8p
CiAJCWlmIChlcnJvcikKIAkJCXJldHVybiAoZXJyb3IpOwogCQl2cGRfdXNlciA9IFBWRV9O
RVhUX0xFTih2cGRfdXNlciwgdnBkX2VsZW1lbnQucHZlX2RhdGFsZW4pOworCQlwcmludGYo
IkxFTiglZCk6ICVsdVxuIiwgaSwgKHNpemVfdCkoKGNoYXIgKil2cGRfdXNlciAtIChjaGFy
ICopbHZpby0+cGx2aV9kYXRhKSk7CiAJfQotCUtBU1NFUlQoKGNoYXIgKil2cGRfdXNlciAt
IChjaGFyICopbHZpby0+cGx2aV9kYXRhID09IGxlbiwKKwlLQVNTRVJUKChjaGFyICopdnBk
X3VzZXIgLSAoY2hhciAqKWx2aW8tPnBsdmlfZGF0YSA8PSBsZW4sCiAJICAgICgibGVuZ3Ro
IG1pc21hdGNoIikpOwogCWx2aW8tPnBsdmlfbGVuID0gbGVuOwogCXJldHVybiAoMCk7Cg==
--------------4l5O0uW3zUcOq38cVYbzEyob--
--------------EpAH2XZhPiiWbbYUDyouNveM--
--------------ofK5ce99cbe2nKle3Bm9SEq6
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"
-----BEGIN PGP SIGNATURE-----
wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmH/qusFAwAAAAAACgkQR+u171r99USE
GggAqqv0fYlvNQqr7hEtKNTxmN5e0IwhnK3RRbXcCcQ0zYmmmV+T7oBlmADtBn/pYCsn3y7cZzO5
QDdkqauSXd65N64vJ+trSrHJn46dakqRbKkyjSuMm8OTyusYBxKXNpaIyUn3UnvlbSOX8nYQn1BW
3RRle1BYSd51r4X46RtjgXY2uy5mtJE8/I3SGZgJY0fRE0azSWJY1hp7jxZLxebfqGfl9ZxhT/6B
+zaUTlVcS6Te3On9MNN9r8Bf1HZqYFumewKcwOgnnTJIbUhzrdCM56O5JXpcvQ2qrCm0ZTU7vJys
4ggcnvhPyMe+JqGqVCIo9q05At/Pp8R/NyAPYuJY+g==
=2nxb
-----END PGP SIGNATURE-----
--------------ofK5ce99cbe2nKle3Bm9SEq6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?016bb393-9f4a-cefa-858f-aef7ce41e640>