* [xen-4.6-testing bisection] complete test-xtf-amd64-amd64-5
@ 2017-04-02 22:44 osstest service owner
2017-04-03 8:02 ` Jan Beulich
0 siblings, 1 reply; 5+ messages in thread
From: osstest service owner @ 2017-04-02 22:44 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-4.6-testing
xenbranch xen-4.6-testing
job test-xtf-amd64-amd64-5
testid xtf-run
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.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: 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Bug not present: 7017321d9b7b23adb50cad66d55ae526ab5d9fe1
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107130/
commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri Mar 31 09:03:32 2017 +0200
xen: sched: don't call hooks of the wrong scheduler via VCPU2OP
Within context_saved(), we call the context_saved hook,
and we use VCPU2OP() to determine from what scheduler.
VCPU2OP uses DOM2OP, which uses d->cpupool, which is
NULL when d is the idle domain. And in that case,
DOM2OP just returns ops, the scheduler of cpupool0.
Therefore, if:
- cpupool0's scheduler defines context_saved (like
Credit2 and RTDS do),
- we are not in cpupool0 (i.e., our scheduler is
not ops),
- we are context switching from idle,
we call VCPU2OP(idle_vcpu), which means
DOM2OP(idle->cpupool), which is ops.
Therefore, we both:
- check if context_saved is defined in the wrong
scheduler;
- if yes, call the wrong one.
When using Credit2 at boot, and also Credit2 in
the other cpupool, this is wrong but innocuous,
because it only involves the idle vcpus.
When using Credit2 at boot, and Credit1 in the
other cpupool, this is *totally* wrong, and
it's by chance it does not explode!
When using Credit2 and other schedulers I'm
developping, I hit the following assert (in
sched_credit2.c, on a CPU inside a cpupool that
does not use Credit2):
csched2_context_saved()
{
...
ASSERT(!vcpu_on_runq(svc));
...
}
Fix this by dealing explicitly, in VCPU2OP, with
idle vcpus, returning the scheduler of the pCPU
they (always) run on.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
master commit: a3653e6a279213ba4e883b2252415dc98633106a
master date: 2017-03-27 14:28:05 +0100
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.6-testing/test-xtf-amd64-amd64-5.xtf-run.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.6-testing/test-xtf-amd64-amd64-5.xtf-run --summary-out=tmp/107130.bisection-summary --basis-template=106819 --blessings=real,real-bisect xen-4.6-testing test-xtf-amd64-amd64-5 xtf-run
Searching for failure / basis pass:
107119 fail [host=baroque1] / 106819 [host=baroque0] 106663 [host=rimava0] 106529 ok.
Failure / basis pass flights: 107119 / 106529
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Tree: xtf git://xenbits.xen.org/xtf.git
Latest b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b7e9d3976ba48f277da6004311f5025b07a884ea 722ce03b32f37ef5af09105727b574339326d354 abb5a1291555d0e33a19e2a252f00852a9026f98 83af19a3154af85815e4c8ffd170839b99685adc
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#b65f2f457c49b2cfd7967c34b7a0b04c25587f13-b65f2f457c49b2cfd7967c34b7a0b04c25587f13 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#b7e9d3976ba48f277da6004311f5025b07a884ea-57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 git://xenbits.xen.org/qemu-xen.git#722ce03b32f37ef5af09105727b574339326d354-44f3d4e6448e37588248db784193b7a047add65a git://xenbits.xen.org/xen.git#abb5a1291555d0e33a19e2a252f00852a9026f98-7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 git://xenbits.xen.org/xtf.git#83af19a3154af85815e4c8ffd170839b99685adc-2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465.
Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465.
Loaded 1304 nodes in revision graph
Searching for test results:
106529 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b7e9d3976ba48f277da6004311f5025b07a884ea 722ce03b32f37ef5af09105727b574339326d354 abb5a1291555d0e33a19e2a252f00852a9026f98 83af19a3154af85815e4c8ffd170839b99685adc
106663 [host=rimava0]
106819 [host=baroque0]
107020 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107042 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107076 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107097 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107116 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b7e9d3976ba48f277da6004311f5025b07a884ea 722ce03b32f37ef5af09105727b574339326d354 abb5a1291555d0e33a19e2a252f00852a9026f98 83af19a3154af85815e4c8ffd170839b99685adc
107117 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107118 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b7e9d3976ba48f277da6004311f5025b07a884ea 44f3d4e6448e37588248db784193b7a047add65a 18949dc6e1a520b6430f128a6981318552ca7823 83af19a3154af85815e4c8ffd170839b99685adc
107120 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 9eb0aa2f47a78ffbab9e7ab9974440a132ce073f 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107121 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 541ad61a921965c692ea31a06d9d14a1bb1e7346 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107124 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7017321d9b7b23adb50cad66d55ae526ab5d9fe1 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107125 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107126 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7017321d9b7b23adb50cad66d55ae526ab5d9fe1 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107119 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107128 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107129 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7017321d9b7b23adb50cad66d55ae526ab5d9fe1 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
107130 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
Searching for interesting versions
Result found: flight 106529 (pass), for basis pass
Result found: flight 107020 (fail), for basis failure
Repro found: flight 107116 (pass), for basis pass
Repro found: flight 107117 (fail), for basis failure
0 revisions at b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a 7017321d9b7b23adb50cad66d55ae526ab5d9fe1 2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
No revisions left to test, checking graph state.
Result found: flight 107124 (pass), for last pass
Result found: flight 107125 (fail), for first failure
Repro found: flight 107126 (pass), for last pass
Repro found: flight 107128 (fail), for first failure
Repro found: flight 107129 (pass), for last pass
Repro found: flight 107130 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Bug not present: 7017321d9b7b23adb50cad66d55ae526ab5d9fe1
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107130/
commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri Mar 31 09:03:32 2017 +0200
xen: sched: don't call hooks of the wrong scheduler via VCPU2OP
Within context_saved(), we call the context_saved hook,
and we use VCPU2OP() to determine from what scheduler.
VCPU2OP uses DOM2OP, which uses d->cpupool, which is
NULL when d is the idle domain. And in that case,
DOM2OP just returns ops, the scheduler of cpupool0.
Therefore, if:
- cpupool0's scheduler defines context_saved (like
Credit2 and RTDS do),
- we are not in cpupool0 (i.e., our scheduler is
not ops),
- we are context switching from idle,
we call VCPU2OP(idle_vcpu), which means
DOM2OP(idle->cpupool), which is ops.
Therefore, we both:
- check if context_saved is defined in the wrong
scheduler;
- if yes, call the wrong one.
When using Credit2 at boot, and also Credit2 in
the other cpupool, this is wrong but innocuous,
because it only involves the idle vcpus.
When using Credit2 at boot, and Credit1 in the
other cpupool, this is *totally* wrong, and
it's by chance it does not explode!
When using Credit2 and other schedulers I'm
developping, I hit the following assert (in
sched_credit2.c, on a CPU inside a cpupool that
does not use Credit2):
csched2_context_saved()
{
...
ASSERT(!vcpu_on_runq(svc));
...
}
Fix this by dealing explicitly, in VCPU2OP, with
idle vcpus, returning the scheduler of the pCPU
they (always) run on.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
master commit: a3653e6a279213ba4e883b2252415dc98633106a
master date: 2017-03-27 14:28:05 +0100
Revision graph left in /home/logs/results/bisect/xen-4.6-testing/test-xtf-amd64-amd64-5.xtf-run.{dot,ps,png,html,svg}.
----------------------------------------
107130: tolerable ALL FAIL
flight 107130 xen-4.6-testing real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/107130/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-xtf-amd64-amd64-5 11 xtf-run fail baseline untested
jobs:
test-xtf-amd64-amd64-5 fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [xen-4.6-testing bisection] complete test-xtf-amd64-amd64-5
2017-04-02 22:44 [xen-4.6-testing bisection] complete test-xtf-amd64-amd64-5 osstest service owner
@ 2017-04-03 8:02 ` Jan Beulich
2017-04-04 17:23 ` Dario Faggioli
0 siblings, 1 reply; 5+ messages in thread
From: Jan Beulich @ 2017-04-03 8:02 UTC (permalink / raw)
To: xen-devel; +Cc: Dario Faggioli, osstest-admin
>>> On 03.04.17 at 00:44, <osstest-admin@xenproject.org> wrote:
> branch xen-4.6-testing
> xenbranch xen-4.6-testing
> job test-xtf-amd64-amd64-5
> testid xtf-run
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.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: 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
> Bug not present: 7017321d9b7b23adb50cad66d55ae526ab5d9fe1
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107130/
>
>
> commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
> Author: Dario Faggioli <dario.faggioli@citrix.com>
> Date: Fri Mar 31 09:03:32 2017 +0200
>
> xen: sched: don't call hooks of the wrong scheduler via VCPU2OP
I must have completely screwed up on this backport, so I've simply
reverted it for now. I didn't look closely yet whether this is some
trivial oversight of mine, or whether perhaps it shouldn't have been
backported that far back in the first place.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [xen-4.6-testing bisection] complete test-xtf-amd64-amd64-5
2017-04-03 8:02 ` Jan Beulich
@ 2017-04-04 17:23 ` Dario Faggioli
2017-04-05 6:54 ` Jan Beulich
0 siblings, 1 reply; 5+ messages in thread
From: Dario Faggioli @ 2017-04-04 17:23 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: osstest-admin
[-- Attachment #1.1: Type: text/plain, Size: 1308 bytes --]
On Mon, 2017-04-03 at 02:02 -0600, Jan Beulich wrote:
> > > > On 03.04.17 at 00:44, <osstest-admin@xenproject.org> wrote:
> > commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
> > Author: Dario Faggioli <dario.faggioli@citrix.com>
> > Date: Fri Mar 31 09:03:32 2017 +0200
> >
> > xen: sched: don't call hooks of the wrong scheduler via
> > VCPU2OP
>
> I must have completely screwed up on this backport, so I've simply
> reverted it for now. I didn't look closely yet whether this is some
> trivial oversight of mine, or whether perhaps it shouldn't have been
> backported that far back in the first place.
>
I had a look. The backport looks fine in itself to me.
If I'm not mistaken, this is not in staging-4.6:
f3d47501db2b7bb8dfd6a3c9710b7aff4b1fc55b
xen: fix a (latent) cpupool-related race during domain destroy
I can't be positive this is what's missing, but it's my best guess. :-)
I also haven't tried backporting it, but I'm happy to. Let me know if I
should.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [xen-4.6-testing bisection] complete test-xtf-amd64-amd64-5
2017-04-04 17:23 ` Dario Faggioli
@ 2017-04-05 6:54 ` Jan Beulich
2017-04-05 16:53 ` Dario Faggioli
0 siblings, 1 reply; 5+ messages in thread
From: Jan Beulich @ 2017-04-05 6:54 UTC (permalink / raw)
To: Dario Faggioli; +Cc: xen-devel, osstest-admin
>>> On 04.04.17 at 19:23, <dario.faggioli@citrix.com> wrote:
> On Mon, 2017-04-03 at 02:02 -0600, Jan Beulich wrote:
>> > > > On 03.04.17 at 00:44, <osstest-admin@xenproject.org> wrote:
>> > commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
>> > Author: Dario Faggioli <dario.faggioli@citrix.com>
>> > Date: Fri Mar 31 09:03:32 2017 +0200
>> >
>> > xen: sched: don't call hooks of the wrong scheduler via
>> > VCPU2OP
>>
>> I must have completely screwed up on this backport, so I've simply
>> reverted it for now. I didn't look closely yet whether this is some
>> trivial oversight of mine, or whether perhaps it shouldn't have been
>> backported that far back in the first place.
>>
> I had a look. The backport looks fine in itself to me.
>
> If I'm not mistaken, this is not in staging-4.6:
>
> f3d47501db2b7bb8dfd6a3c9710b7aff4b1fc55b
> xen: fix a (latent) cpupool-related race during domain destroy
>
> I can't be positive this is what's missing, but it's my best guess. :-)
>
> I also haven't tried backporting it, but I'm happy to. Let me know if I
> should.
I think we could leave 4.6 alone in this regard, unless you see a
strong need for the fix there, or unless anyone's aware of
someone having actively encountered the problem there. Or in
other words - if you feel like making sure we know of all prereqs
(and providing backports if those won't apply as is), I'd happily
apply them, but I don't think you absolutely need to.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [xen-4.6-testing bisection] complete test-xtf-amd64-amd64-5
2017-04-05 6:54 ` Jan Beulich
@ 2017-04-05 16:53 ` Dario Faggioli
0 siblings, 0 replies; 5+ messages in thread
From: Dario Faggioli @ 2017-04-05 16:53 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, osstest-admin
[-- Attachment #1.1: Type: text/plain, Size: 1622 bytes --]
On Wed, 2017-04-05 at 00:54 -0600, Jan Beulich wrote:
> > > > On 04.04.17 at 19:23, <dario.faggioli@citrix.com> wrote:
> >
> > If I'm not mistaken, this is not in staging-4.6:
> >
> > f3d47501db2b7bb8dfd6a3c9710b7aff4b1fc55b
> > xen: fix a (latent) cpupool-related race during domain destroy
> >
> > I can't be positive this is what's missing, but it's my best guess.
> > :-)
> >
> > I also haven't tried backporting it, but I'm happy to. Let me know
> > if I
> > should.
>
> I think we could leave 4.6 alone in this regard, unless you see a
> strong need for the fix there, or unless anyone's aware of
> someone having actively encountered the problem there.
>
I agree. And no, I'm not aware of anyone having run into the issue on
4.6.x.
> Or in
> other words - if you feel like making sure we know of all prereqs
> (and providing backports if those won't apply as is), I'd happily
> apply them, but I don't think you absolutely need to.
>
I actually tried backporting the above commit. It's not just a matter
of cherry picking, but it's trivial. I could not test the result,
though, because I can't build the tools from 4.6 with my gcc (6.3.0),
without backporting some toolstack patches too.
I can look into which ones are needed, but not right now. So I'm going
to put this on hold.
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-04-05 16:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-02 22:44 [xen-4.6-testing bisection] complete test-xtf-amd64-amd64-5 osstest service owner
2017-04-03 8:02 ` Jan Beulich
2017-04-04 17:23 ` Dario Faggioli
2017-04-05 6:54 ` Jan Beulich
2017-04-05 16:53 ` Dario Faggioli
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.