[xen-4.14-testing bisection] complete test-xtf-amd64-amd64-1
branch xen-4.14-testing xenbranch xen-4.14-testing job test-xtf-amd64-amd64-1 testid xtf/test-pv64-xsa-221 Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Tree: xtf git://xenbits.xen.org/xtf.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: b8c2efbe7b3e8fa5f0b0a3679afccd1204949070 Bug not present: f5469067ee0260673ca1e554ff512a55ccfc Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/154774/ commit b8c2efbe7b3e8fa5f0b0a3679afccd1204949070 Author: Jan Beulich Date: Tue Sep 22 16:13:34 2020 +0200 evtchn/x86: enforce correct upper limit for 32-bit guests The recording of d->max_evtchns in evtchn_2l_init(), in particular with the limited set of callers of the function, is insufficient. Neither for PV nor for HVM guests the bitness is known at domain_create() time, yet the upper bound in 2-level mode depends upon guest bitness. Recording too high a limit "allows" x86 32-bit domains to open not properly usable event channels, management of which (inside Xen) would then result in corruption of the shared info and vCPU info structures. Keep the upper limit dynamic for the 2-level case, introducing a helper function to retrieve the effective limit. This helper is now supposed to be private to the event channel code. The used in do_poll() and domain_dump_evtchn_info() weren't consistent with port uses elsewhere and hence get switched to port_is_valid(). Furthermore FIFO mode's setup_ports() gets adjusted to loop only up to the prior ABI limit, rather than all the way up to the new one. Finally a word on the change to do_poll(): Accessing ->max_evtchns without holding a suitable lock was never safe, as it as well as ->evtchn_port_ops may change behind do_poll()'s back. Using port_is_valid() instead widens some the window for potential abuse, until we've dealt with the race altogether (see XSA-343). This is XSA-342. Reported-by: Julien Grall Fixes: 48974e6ce52e ("evtchn: use a per-domain variable for the max number of event channels") Signed-off-by: Jan Beulich Reviewed-by: Stefano Stabellini Reviewed-by: Julien Grall For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.14-testing/test-xtf-amd64-amd64-1.xtf--test-pv64-xsa-221.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-4.14-testing/test-xtf-amd64-amd64-1.xtf--test-pv64-xsa-221 --summary-out=tmp/154889.bisection-summary --basis-template=154350 --blessings=real,real-bisect --flight=154889 xen-4.14-testing test-xtf-amd64-amd64-1 xtf/test-pv64-xsa-221 Searching for failure / basis pass: 154641 fail [host=chardonnay1] / 154350 [host=huxelrebe1] 154148 [host=albana0] 154116 [host=godello0] 152545 [host=elbling1] 152537 [host=chardonnay0] 152531 [host=godello0] 152153 [host=godello0] 152124 [host=fiano1] 152081 [host=albana0] 152061 [host=albana1] 152043 [host=huxelrebe1] 151922 [host=elbling1] 151899 ok. Failure / basis pass flights: 154641 / 151899 (tree with no url: minios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Tree: xtf git://xenbits.xen.org/xtf.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 fb97626fe04747ec89599dce0992def9a36e2f6b 3c659044118e34603161457db9934a34f816d78b ea6d3cd1ed79d824e605a70c3626bc437c386260 155821a1990b6de78dde5f98fa5ab90e802021e0 f37a1cf023b277d0d49323bf322ce3ff0c92262d 17d372b763cb0b2e2e6b5a637c11f3997d2533fa Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c6f3545aee0808b78a0ad4480b6eb9d24989dc1 3c659044118e34603161457db9934a34f816d78b ea6d3cd1ed79d824e605a70c3626bc437c386260 88ab0c15525ced2eefe39220742efe4769089ad8 ce3c4493e4e6c94495ddd8538e801a35980bff0d f645a19115e666ce6401ca63b7d7388571463b55 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.x
[xen-4.14-testing bisection] complete test-xtf-amd64-amd64-1
branch xen-4.14-testing xenbranch xen-4.14-testing job test-xtf-amd64-amd64-1 testid xtf/test-hvm64-xsa-221 Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Tree: xtf git://xenbits.xen.org/xtf.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: b8c2efbe7b3e8fa5f0b0a3679afccd1204949070 Bug not present: f5469067ee0260673ca1e554ff512a55ccfc Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/154774/ commit b8c2efbe7b3e8fa5f0b0a3679afccd1204949070 Author: Jan Beulich Date: Tue Sep 22 16:13:34 2020 +0200 evtchn/x86: enforce correct upper limit for 32-bit guests The recording of d->max_evtchns in evtchn_2l_init(), in particular with the limited set of callers of the function, is insufficient. Neither for PV nor for HVM guests the bitness is known at domain_create() time, yet the upper bound in 2-level mode depends upon guest bitness. Recording too high a limit "allows" x86 32-bit domains to open not properly usable event channels, management of which (inside Xen) would then result in corruption of the shared info and vCPU info structures. Keep the upper limit dynamic for the 2-level case, introducing a helper function to retrieve the effective limit. This helper is now supposed to be private to the event channel code. The used in do_poll() and domain_dump_evtchn_info() weren't consistent with port uses elsewhere and hence get switched to port_is_valid(). Furthermore FIFO mode's setup_ports() gets adjusted to loop only up to the prior ABI limit, rather than all the way up to the new one. Finally a word on the change to do_poll(): Accessing ->max_evtchns without holding a suitable lock was never safe, as it as well as ->evtchn_port_ops may change behind do_poll()'s back. Using port_is_valid() instead widens some the window for potential abuse, until we've dealt with the race altogether (see XSA-343). This is XSA-342. Reported-by: Julien Grall Fixes: 48974e6ce52e ("evtchn: use a per-domain variable for the max number of event channels") Signed-off-by: Jan Beulich Reviewed-by: Stefano Stabellini Reviewed-by: Julien Grall For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.14-testing/test-xtf-amd64-amd64-1.xtf--test-hvm64-xsa-221.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-4.14-testing/test-xtf-amd64-amd64-1.xtf--test-hvm64-xsa-221 --summary-out=tmp/154774.bisection-summary --basis-template=154350 --blessings=real,real-bisect xen-4.14-testing test-xtf-amd64-amd64-1 xtf/test-hvm64-xsa-221 Searching for failure / basis pass: 154641 fail [host=chardonnay1] / 154350 [host=huxelrebe1] 154148 [host=albana0] 154116 [host=godello0] 152545 [host=elbling1] 152537 [host=chardonnay0] 152531 [host=godello0] 152153 [host=godello0] 152124 [host=fiano1] 152081 [host=albana0] 152061 [host=albana1] 152043 [host=huxelrebe1] 151922 [host=elbling1] 151899 ok. Failure / basis pass flights: 154641 / 151899 (tree with no url: minios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Tree: xtf git://xenbits.xen.org/xtf.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 fb97626fe04747ec89599dce0992def9a36e2f6b 3c659044118e34603161457db9934a34f816d78b ea6d3cd1ed79d824e605a70c3626bc437c386260 155821a1990b6de78dde5f98fa5ab90e802021e0 f37a1cf023b277d0d49323bf322ce3ff0c92262d 17d372b763cb0b2e2e6b5a637c11f3997d2533fa Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c6f3545aee0808b78a0ad4480b6eb9d24989dc1 3c659044118e34603161457db9934a34f816d78b ea6d3cd1ed79d824e605a70c3626bc437c386260 88ab0c15525ced2eefe39220742efe4769089ad8 ce3c4493e4e6c94495ddd8538e801a35980bff0d f645a19115e666ce6401ca63b7d7388571463b55 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osste