* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
[not found] <160874604800.15699.17952392608790984041@600e7e483b3a>
@ 2020-12-23 19:45 ` Stefano Stabellini
2020-12-23 20:01 ` Andrew Cooper
0 siblings, 1 reply; 13+ messages in thread
From: Stefano Stabellini @ 2020-12-23 19:45 UTC (permalink / raw)
To: xen-devel
Cc: famzheng, sstabellini, cardoe, wl, Bertrand.Marquis, julien,
andrew.cooper3
On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
> Hi,
>
> Patchew automatically ran gitlab-ci pipeline with this patch (series) applied, but the job failed. Maybe there's a bug in the patches?
>
> You can find the link to the pipeline near the end of the report below:
>
> Type: series
> Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
> Subject: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
>
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> sleep 10
> patchew gitlab-pipeline-check -p xen-project/patchew/xen
> === TEST SCRIPT END ===
[...]
> === OUTPUT BEGIN ===
> [2020-12-23 16:38:43] Looking up pipeline...
> [2020-12-23 16:38:43] Found pipeline 233889763:
>
> https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
This seems to be a genuine failure. Looking at the alpine-3.12-gcc-arm64
build test, the build error is appended below. This is a link to the
failed job: https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-project/patchew/xen/tools/misc/../../tools/config.h -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -D__XEN_TOOLS__ -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -Wno-declaration-after-statement -c -o xen-diag.o xen-diag.c
xen-fault-ttl.c: In function 'main':
xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig' has no member named 'emulation_flags'
25 | .emulation_flags = XEN_X86_EMU_LAPIC,
| ^~~~~~~~~~~~~~~
xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared (first use in this function)
25 | .emulation_flags = XEN_X86_EMU_LAPIC,
| ^~~~~~~~~~~~~~~~~
xen-fault-ttl.c:25:32: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [/builds/xen-project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-fault-ttl.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory '/builds/xen-project/patchew/xen/tools/misc'
make[3]: *** [/builds/xen-project/patchew/xen/tools/../tools/Rules.mk:160: subdir-install-misc] Error 2
make[3]: Leaving directory '/builds/xen-project/patchew/xen/tools'
make[2]: *** [/builds/xen-project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-install] Error 2
make[2]: Leaving directory '/builds/xen-project/patchew/xen/tools'
make[1]: *** [Makefile:67: install] Error 2
make[1]: Leaving directory '/builds/xen-project/patchew/xen/tools'
make: *** [Makefile:134: install-tools] Error 2
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2020-12-23 19:45 ` [PATCH 0/4] xen: domain-tracked allocations, and fault injection Stefano Stabellini
@ 2020-12-23 20:01 ` Andrew Cooper
2020-12-23 20:10 ` Stefano Stabellini
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Cooper @ 2020-12-23 20:01 UTC (permalink / raw)
To: Stefano Stabellini, xen-devel
Cc: famzheng, cardoe, wl, Bertrand.Marquis, julien
On 23/12/2020 19:45, Stefano Stabellini wrote:
> On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
>> Hi,
>>
>> Patchew automatically ran gitlab-ci pipeline with this patch (series) applied, but the job failed. Maybe there's a bug in the patches?
>>
>> You can find the link to the pipeline near the end of the report below:
>>
>> Type: series
>> Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
>> Subject: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
>>
>> === TEST SCRIPT BEGIN ===
>> #!/bin/bash
>> sleep 10
>> patchew gitlab-pipeline-check -p xen-project/patchew/xen
>> === TEST SCRIPT END ===
> [...]
>
>> === OUTPUT BEGIN ===
>> [2020-12-23 16:38:43] Looking up pipeline...
>> [2020-12-23 16:38:43] Found pipeline 233889763:
>>
>> https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
> This seems to be a genuine failure. Looking at the alpine-3.12-gcc-arm64
> build test, the build error is appended below. This is a link to the
> failed job: https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
>
>
>
> gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-project/patchew/xen/tools/misc/../../tools/config.h -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -D__XEN_TOOLS__ -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -Wno-declaration-after-statement -c -o xen-diag.o xen-diag.c
> xen-fault-ttl.c: In function 'main':
> xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig' has no member named 'emulation_flags'
> 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> | ^~~~~~~~~~~~~~~
> xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared (first use in this function)
> 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> | ^~~~~~~~~~~~~~~~~
> xen-fault-ttl.c:25:32: note: each undeclared identifier is reported only once for each function it appears in
> make[4]: *** [/builds/xen-project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-fault-ttl.o] Error 1
> make[4]: *** Waiting for unfinished jobs....
> make[4]: Leaving directory '/builds/xen-project/patchew/xen/tools/misc'
> make[3]: *** [/builds/xen-project/patchew/xen/tools/../tools/Rules.mk:160: subdir-install-misc] Error 2
> make[3]: Leaving directory '/builds/xen-project/patchew/xen/tools'
> make[2]: *** [/builds/xen-project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-install] Error 2
> make[2]: Leaving directory '/builds/xen-project/patchew/xen/tools'
> make[1]: *** [Makefile:67: install] Error 2
> make[1]: Leaving directory '/builds/xen-project/patchew/xen/tools'
> make: *** [Makefile:134: install-tools] Error 2
Yeah - that is a real failure, which can be fixed with a little bit of
ifdef-ary. I'm confused as to why I didn't get that email directly.
~Andrew
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2020-12-23 20:01 ` Andrew Cooper
@ 2020-12-23 20:10 ` Stefano Stabellini
2021-01-04 9:11 ` Zheng, Fam
2021-01-04 9:38 ` Roger Pau Monné
0 siblings, 2 replies; 13+ messages in thread
From: Stefano Stabellini @ 2020-12-23 20:10 UTC (permalink / raw)
To: Andrew Cooper
Cc: Stefano Stabellini, xen-devel, famzheng, cardoe, wl,
Bertrand.Marquis, julien
[-- Attachment #1: Type: text/plain, Size: 3583 bytes --]
On Wed, 23 Dec 2020, Andrew Cooper wrote:
> On 23/12/2020 19:45, Stefano Stabellini wrote:
> > On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
> >> Hi,
> >>
> >> Patchew automatically ran gitlab-ci pipeline with this patch (series) applied, but the job failed. Maybe there's a bug in the patches?
> >>
> >> You can find the link to the pipeline near the end of the report below:
> >>
> >> Type: series
> >> Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
> >> Subject: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
> >>
> >> === TEST SCRIPT BEGIN ===
> >> #!/bin/bash
> >> sleep 10
> >> patchew gitlab-pipeline-check -p xen-project/patchew/xen
> >> === TEST SCRIPT END ===
> > [...]
> >
> >> === OUTPUT BEGIN ===
> >> [2020-12-23 16:38:43] Looking up pipeline...
> >> [2020-12-23 16:38:43] Found pipeline 233889763:
> >>
> >> https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
> > This seems to be a genuine failure. Looking at the alpine-3.12-gcc-arm64
> > build test, the build error is appended below. This is a link to the
> > failed job: https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
> >
> >
> >
> > gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-project/patchew/xen/tools/misc/../../tools/config.h -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -D__XEN_TOOLS__ -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -Wno-declaration-after-statement -c -o xen-diag.o xen-diag.c
> > xen-fault-ttl.c: In function 'main':
> > xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig' has no member named 'emulation_flags'
> > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > | ^~~~~~~~~~~~~~~
> > xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared (first use in this function)
> > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > | ^~~~~~~~~~~~~~~~~
> > xen-fault-ttl.c:25:32: note: each undeclared identifier is reported only once for each function it appears in
> > make[4]: *** [/builds/xen-project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-fault-ttl.o] Error 1
> > make[4]: *** Waiting for unfinished jobs....
> > make[4]: Leaving directory '/builds/xen-project/patchew/xen/tools/misc'
> > make[3]: *** [/builds/xen-project/patchew/xen/tools/../tools/Rules.mk:160: subdir-install-misc] Error 2
> > make[3]: Leaving directory '/builds/xen-project/patchew/xen/tools'
> > make[2]: *** [/builds/xen-project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-install] Error 2
> > make[2]: Leaving directory '/builds/xen-project/patchew/xen/tools'
> > make[1]: *** [Makefile:67: install] Error 2
> > make[1]: Leaving directory '/builds/xen-project/patchew/xen/tools'
> > make: *** [Makefile:134: install-tools] Error 2
>
> Yeah - that is a real failure, which can be fixed with a little bit of
> ifdef-ary. I'm confused as to why I didn't get that email directly.
It looks like patchew doesn't yet CC the original author?
Also not sure why you weren't part of the default CC group anyway.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2020-12-23 20:10 ` Stefano Stabellini
@ 2021-01-04 9:11 ` Zheng, Fam
2021-01-04 9:38 ` Roger Pau Monné
1 sibling, 0 replies; 13+ messages in thread
From: Zheng, Fam @ 2021-01-04 9:11 UTC (permalink / raw)
To: sstabellini, andrew.cooper3
Cc: cardoe, wl, xen-devel, julien, Bertrand.Marquis
On Wed, 2020-12-23 at 12:10 -0800, Stefano Stabellini wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> On Wed, 23 Dec 2020, Andrew Cooper wrote:
> > On 23/12/2020 19:45, Stefano Stabellini wrote:
> > > On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
> > > > Hi,
> > > >
> > > > Patchew automatically ran gitlab-ci pipeline with this patch
> > > > (series) applied, but the job failed. Maybe there's a bug in
> > > > the patches?
> > > >
> > > > You can find the link to the pipeline near the end of the
> > > > report below:
> > > >
> > > > Type: series
> > > > Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
> > > > Subject: [PATCH 0/4] xen: domain-tracked allocations, and fault
> > > > injection
> > > >
> > > > === TEST SCRIPT BEGIN ===
> > > > #!/bin/bash
> > > > sleep 10
> > > > patchew gitlab-pipeline-check -p xen-project/patchew/xen
> > > > === TEST SCRIPT END ===
> > >
> > > [...]
> > >
> > > > === OUTPUT BEGIN ===
> > > > [2020-12-23 16:38:43] Looking up pipeline...
> > > > [2020-12-23 16:38:43] Found pipeline 233889763:
> > > >
> > > >
https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
> > >
> > > This seems to be a genuine failure. Looking at the alpine-3.12-
> > > gcc-arm64
> > > build test, the build error is appended below. This is a link to
> > > the
> > > failed job:
> > > https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
> > >
> > >
> > >
> > > gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-
> > > prototypes -Wdeclaration-after-statement -Wno-unused-but-set-
> > > variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer
> > > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD
> > > -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE
> > > -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-
> > > project/patchew/xen/tools/misc/../../tools/config.h
> > > -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include
> > > -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include
> > > -D__XEN_TOOLS__ -I/builds/xen-
> > > project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-
> > > project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-
> > > project/patchew/xen/tools/misc/../../tools/include -Wno-
> > > declaration-after-statement -c -o xen-diag.o xen-diag.c
> > > xen-fault-ttl.c: In function 'main':
> > > xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig' has
> > > no member named 'emulation_flags'
> > > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > > | ^~~~~~~~~~~~~~~
> > > xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared
> > > (first use in this function)
> > > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > > | ^~~~~~~~~~~~~~~~~
> > > xen-fault-ttl.c:25:32: note: each undeclared identifier is
> > > reported only once for each function it appears in
> > > make[4]: *** [/builds/xen-
> > > project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-
> > > fault-ttl.o] Error 1
> > > make[4]: *** Waiting for unfinished jobs....
> > > make[4]: Leaving directory '/builds/xen-
> > > project/patchew/xen/tools/misc'
> > > make[3]: *** [/builds/xen-
> > > project/patchew/xen/tools/../tools/Rules.mk:160: subdir-install-
> > > misc] Error 2
> > > make[3]: Leaving directory '/builds/xen-
> > > project/patchew/xen/tools'
> > > make[2]: *** [/builds/xen-
> > > project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-install]
> > > Error 2
> > > make[2]: Leaving directory '/builds/xen-
> > > project/patchew/xen/tools'
> > > make[1]: *** [Makefile:67: install] Error 2
> > > make[1]: Leaving directory '/builds/xen-
> > > project/patchew/xen/tools'
> > > make: *** [Makefile:134: install-tools] Error 2
> >
> > Yeah - that is a real failure, which can be fixed with a little bit
> > of
> > ifdef-ary. I'm confused as to why I didn't get that email
> > directly.
>
> It looks like patchew doesn't yet CC the original author?
>
> Also not sure why you weren't part of the default CC group anyway.
I've added Andrew to the default Cc list now.
Fam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2020-12-23 20:10 ` Stefano Stabellini
2021-01-04 9:11 ` Zheng, Fam
@ 2021-01-04 9:38 ` Roger Pau Monné
2021-01-04 10:53 ` Zheng, Fam
1 sibling, 1 reply; 13+ messages in thread
From: Roger Pau Monné @ 2021-01-04 9:38 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Andrew Cooper, xen-devel, famzheng, cardoe, wl, Bertrand.Marquis, julien
On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> On Wed, 23 Dec 2020, Andrew Cooper wrote:
> > On 23/12/2020 19:45, Stefano Stabellini wrote:
> > > On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
> > >> Hi,
> > >>
> > >> Patchew automatically ran gitlab-ci pipeline with this patch (series) applied, but the job failed. Maybe there's a bug in the patches?
> > >>
> > >> You can find the link to the pipeline near the end of the report below:
> > >>
> > >> Type: series
> > >> Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
> > >> Subject: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
> > >>
> > >> === TEST SCRIPT BEGIN ===
> > >> #!/bin/bash
> > >> sleep 10
> > >> patchew gitlab-pipeline-check -p xen-project/patchew/xen
> > >> === TEST SCRIPT END ===
> > > [...]
> > >
> > >> === OUTPUT BEGIN ===
> > >> [2020-12-23 16:38:43] Looking up pipeline...
> > >> [2020-12-23 16:38:43] Found pipeline 233889763:
> > >>
> > >> https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
> > > This seems to be a genuine failure. Looking at the alpine-3.12-gcc-arm64
> > > build test, the build error is appended below. This is a link to the
> > > failed job: https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
> > >
> > >
> > >
> > > gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-project/patchew/xen/tools/misc/../../tools/config.h -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -D__XEN_TOOLS__ -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -I/builds/xen-project/patchew/xen/tools/misc/../../tools/include -Wno-declaration-after-statement -c -o xen-diag.o xen-diag.c
> > > xen-fault-ttl.c: In function 'main':
> > > xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig' has no member named 'emulation_flags'
> > > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > > | ^~~~~~~~~~~~~~~
> > > xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared (first use in this function)
> > > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > > | ^~~~~~~~~~~~~~~~~
> > > xen-fault-ttl.c:25:32: note: each undeclared identifier is reported only once for each function it appears in
> > > make[4]: *** [/builds/xen-project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-fault-ttl.o] Error 1
> > > make[4]: *** Waiting for unfinished jobs....
> > > make[4]: Leaving directory '/builds/xen-project/patchew/xen/tools/misc'
> > > make[3]: *** [/builds/xen-project/patchew/xen/tools/../tools/Rules.mk:160: subdir-install-misc] Error 2
> > > make[3]: Leaving directory '/builds/xen-project/patchew/xen/tools'
> > > make[2]: *** [/builds/xen-project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-install] Error 2
> > > make[2]: Leaving directory '/builds/xen-project/patchew/xen/tools'
> > > make[1]: *** [Makefile:67: install] Error 2
> > > make[1]: Leaving directory '/builds/xen-project/patchew/xen/tools'
> > > make: *** [Makefile:134: install-tools] Error 2
> >
> > Yeah - that is a real failure, which can be fixed with a little bit of
> > ifdef-ary. I'm confused as to why I didn't get that email directly.
>
> It looks like patchew doesn't yet CC the original author?
Where do patchew emails go? I haven't seen any of them, and they don't
seem to go to xen-devel.
Thanks, Roger.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2021-01-04 9:38 ` Roger Pau Monné
@ 2021-01-04 10:53 ` Zheng, Fam
2021-01-04 17:30 ` Stefano Stabellini
0 siblings, 1 reply; 13+ messages in thread
From: Zheng, Fam @ 2021-01-04 10:53 UTC (permalink / raw)
To: roger.pau, sstabellini
Cc: julien, cardoe, wl, andrew.cooper3, xen-devel, Bertrand.Marquis
On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
> On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> > On Wed, 23 Dec 2020, Andrew Cooper wrote:
> > > On 23/12/2020 19:45, Stefano Stabellini wrote:
> > > > On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
> > > > > Hi,
> > > > >
> > > > > Patchew automatically ran gitlab-ci pipeline with this patch
> > > > > (series) applied, but the job failed. Maybe there's a bug in
> > > > > the patches?
> > > > >
> > > > > You can find the link to the pipeline near the end of the
> > > > > report below:
> > > > >
> > > > > Type: series
> > > > > Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
> > > > > Subject: [PATCH 0/4] xen: domain-tracked allocations, and
> > > > > fault injection
> > > > >
> > > > > === TEST SCRIPT BEGIN ===
> > > > > #!/bin/bash
> > > > > sleep 10
> > > > > patchew gitlab-pipeline-check -p xen-project/patchew/xen
> > > > > === TEST SCRIPT END ===
> > > >
> > > > [...]
> > > >
> > > > > === OUTPUT BEGIN ===
> > > > > [2020-12-23 16:38:43] Looking up pipeline...
> > > > > [2020-12-23 16:38:43] Found pipeline 233889763:
> > > > >
> > > > >
https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
> > > >
> > > > This seems to be a genuine failure. Looking at the alpine-3.12-
> > > > gcc-arm64
> > > > build test, the build error is appended below. This is a link
> > > > to the
> > > > failed job:
> > > > https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
> > > >
> > > >
> > > >
> > > > gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-
> > > > prototypes -Wdeclaration-after-statement -Wno-unused-but-set-
> > > > variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer
> > > > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
> > > > -MMD -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE
> > > > -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-
> > > > project/patchew/xen/tools/misc/../../tools/config.h
> > > > -I/builds/xen-
> > > > project/patchew/xen/tools/misc/../../tools/include
> > > > -I/builds/xen-
> > > > project/patchew/xen/tools/misc/../../tools/include
> > > > -D__XEN_TOOLS__ -I/builds/xen-
> > > > project/patchew/xen/tools/misc/../../tools/include
> > > > -I/builds/xen-
> > > > project/patchew/xen/tools/misc/../../tools/include
> > > > -I/builds/xen-
> > > > project/patchew/xen/tools/misc/../../tools/include -Wno-
> > > > declaration-after-statement -c -o xen-diag.o xen-diag.c
> > > > xen-fault-ttl.c: In function 'main':
> > > > xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig'
> > > > has no member named 'emulation_flags'
> > > > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > > > | ^~~~~~~~~~~~~~~
> > > > xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared
> > > > (first use in this function)
> > > > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > > > | ^~~~~~~~~~~~~~~~~
> > > > xen-fault-ttl.c:25:32: note: each undeclared identifier is
> > > > reported only once for each function it appears in
> > > > make[4]: *** [/builds/xen-
> > > > project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-
> > > > fault-ttl.o] Error 1
> > > > make[4]: *** Waiting for unfinished jobs....
> > > > make[4]: Leaving directory '/builds/xen-
> > > > project/patchew/xen/tools/misc'
> > > > make[3]: *** [/builds/xen-
> > > > project/patchew/xen/tools/../tools/Rules.mk:160: subdir-
> > > > install-misc] Error 2
> > > > make[3]: Leaving directory '/builds/xen-
> > > > project/patchew/xen/tools'
> > > > make[2]: *** [/builds/xen-
> > > > project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-
> > > > install] Error 2
> > > > make[2]: Leaving directory '/builds/xen-
> > > > project/patchew/xen/tools'
> > > > make[1]: *** [Makefile:67: install] Error 2
> > > > make[1]: Leaving directory '/builds/xen-
> > > > project/patchew/xen/tools'
> > > > make: *** [Makefile:134: install-tools] Error 2
> > >
> > > Yeah - that is a real failure, which can be fixed with a little
> > > bit of
> > > ifdef-ary. I'm confused as to why I didn't get that email
> > > directly.
> >
> > It looks like patchew doesn't yet CC the original author?
>
> Where do patchew emails go? I haven't seen any of them, and they
> don't
> seem to go to xen-devel.
It's to limit the noise level. We intend to stablize the workflow a
little more esp. wrt false positives before making every reply go to
xen-devel. There's a few things to tweak in patchew.
The next logical step should be including the patch author in the loop
I think.
Fam
>
> Thanks, Roger.
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2021-01-04 10:53 ` Zheng, Fam
@ 2021-01-04 17:30 ` Stefano Stabellini
2021-01-04 17:35 ` Julien Grall
2021-01-04 17:36 ` Andrew Cooper
0 siblings, 2 replies; 13+ messages in thread
From: Stefano Stabellini @ 2021-01-04 17:30 UTC (permalink / raw)
To: Zheng, Fam
Cc: roger.pau, sstabellini, julien, cardoe, wl, andrew.cooper3,
xen-devel, Bertrand.Marquis
[-- Attachment #1: Type: text/plain, Size: 4897 bytes --]
On Mon, 4 Jan 2021, Zheng, Fam wrote:
> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
> > On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> > > On Wed, 23 Dec 2020, Andrew Cooper wrote:
> > > > On 23/12/2020 19:45, Stefano Stabellini wrote:
> > > > > On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Patchew automatically ran gitlab-ci pipeline with this patch
> > > > > > (series) applied, but the job failed. Maybe there's a bug in
> > > > > > the patches?
> > > > > >
> > > > > > You can find the link to the pipeline near the end of the
> > > > > > report below:
> > > > > >
> > > > > > Type: series
> > > > > > Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
> > > > > > Subject: [PATCH 0/4] xen: domain-tracked allocations, and
> > > > > > fault injection
> > > > > >
> > > > > > === TEST SCRIPT BEGIN ===
> > > > > > #!/bin/bash
> > > > > > sleep 10
> > > > > > patchew gitlab-pipeline-check -p xen-project/patchew/xen
> > > > > > === TEST SCRIPT END ===
> > > > >
> > > > > [...]
> > > > >
> > > > > > === OUTPUT BEGIN ===
> > > > > > [2020-12-23 16:38:43] Looking up pipeline...
> > > > > > [2020-12-23 16:38:43] Found pipeline 233889763:
> > > > > >
> > > > > >
> https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
> > > > >
> > > > > This seems to be a genuine failure. Looking at the alpine-3.12-
> > > > > gcc-arm64
> > > > > build test, the build error is appended below. This is a link
> > > > > to the
> > > > > failed job:
> > > > > https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
> > > > >
> > > > >
> > > > >
> > > > > gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-
> > > > > prototypes -Wdeclaration-after-statement -Wno-unused-but-set-
> > > > > variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer
> > > > > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
> > > > > -MMD -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE
> > > > > -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-
> > > > > project/patchew/xen/tools/misc/../../tools/config.h
> > > > > -I/builds/xen-
> > > > > project/patchew/xen/tools/misc/../../tools/include
> > > > > -I/builds/xen-
> > > > > project/patchew/xen/tools/misc/../../tools/include
> > > > > -D__XEN_TOOLS__ -I/builds/xen-
> > > > > project/patchew/xen/tools/misc/../../tools/include
> > > > > -I/builds/xen-
> > > > > project/patchew/xen/tools/misc/../../tools/include
> > > > > -I/builds/xen-
> > > > > project/patchew/xen/tools/misc/../../tools/include -Wno-
> > > > > declaration-after-statement -c -o xen-diag.o xen-diag.c
> > > > > xen-fault-ttl.c: In function 'main':
> > > > > xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig'
> > > > > has no member named 'emulation_flags'
> > > > > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > > > > | ^~~~~~~~~~~~~~~
> > > > > xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared
> > > > > (first use in this function)
> > > > > 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> > > > > | ^~~~~~~~~~~~~~~~~
> > > > > xen-fault-ttl.c:25:32: note: each undeclared identifier is
> > > > > reported only once for each function it appears in
> > > > > make[4]: *** [/builds/xen-
> > > > > project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-
> > > > > fault-ttl.o] Error 1
> > > > > make[4]: *** Waiting for unfinished jobs....
> > > > > make[4]: Leaving directory '/builds/xen-
> > > > > project/patchew/xen/tools/misc'
> > > > > make[3]: *** [/builds/xen-
> > > > > project/patchew/xen/tools/../tools/Rules.mk:160: subdir-
> > > > > install-misc] Error 2
> > > > > make[3]: Leaving directory '/builds/xen-
> > > > > project/patchew/xen/tools'
> > > > > make[2]: *** [/builds/xen-
> > > > > project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-
> > > > > install] Error 2
> > > > > make[2]: Leaving directory '/builds/xen-
> > > > > project/patchew/xen/tools'
> > > > > make[1]: *** [Makefile:67: install] Error 2
> > > > > make[1]: Leaving directory '/builds/xen-
> > > > > project/patchew/xen/tools'
> > > > > make: *** [Makefile:134: install-tools] Error 2
> > > >
> > > > Yeah - that is a real failure, which can be fixed with a little
> > > > bit of
> > > > ifdef-ary. I'm confused as to why I didn't get that email
> > > > directly.
> > >
> > > It looks like patchew doesn't yet CC the original author?
> >
> > Where do patchew emails go? I haven't seen any of them, and they
> > don't
> > seem to go to xen-devel.
>
> It's to limit the noise level. We intend to stablize the workflow a
> little more esp. wrt false positives before making every reply go to
> xen-devel. There's a few things to tweak in patchew.
>
> The next logical step should be including the patch author in the loop
> I think.
Let's do it.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2021-01-04 17:30 ` Stefano Stabellini
@ 2021-01-04 17:35 ` Julien Grall
2021-01-04 17:36 ` Andrew Cooper
1 sibling, 0 replies; 13+ messages in thread
From: Julien Grall @ 2021-01-04 17:35 UTC (permalink / raw)
To: Stefano Stabellini, Zheng, Fam
Cc: roger.pau, cardoe, wl, andrew.cooper3, xen-devel, Bertrand.Marquis
On 04/01/2021 17:30, Stefano Stabellini wrote:
> On Mon, 4 Jan 2021, Zheng, Fam wrote:
>> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
>>> On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
>>>> On Wed, 23 Dec 2020, Andrew Cooper wrote:
>>>>> On 23/12/2020 19:45, Stefano Stabellini wrote:
>>>>>> On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Patchew automatically ran gitlab-ci pipeline with this patch
>>>>>>> (series) applied, but the job failed. Maybe there's a bug in
>>>>>>> the patches?
>>>>>>>
>>>>>>> You can find the link to the pipeline near the end of the
>>>>>>> report below:
>>>>>>>
>>>>>>> Type: series
>>>>>>> Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
>>>>>>> Subject: [PATCH 0/4] xen: domain-tracked allocations, and
>>>>>>> fault injection
>>>>>>>
>>>>>>> === TEST SCRIPT BEGIN ===
>>>>>>> #!/bin/bash
>>>>>>> sleep 10
>>>>>>> patchew gitlab-pipeline-check -p xen-project/patchew/xen
>>>>>>> === TEST SCRIPT END ===
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> === OUTPUT BEGIN ===
>>>>>>> [2020-12-23 16:38:43] Looking up pipeline...
>>>>>>> [2020-12-23 16:38:43] Found pipeline 233889763:
>>>>>>>
>>>>>>>
>> https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
>>>>>>
>>>>>> This seems to be a genuine failure. Looking at the alpine-3.12-
>>>>>> gcc-arm64
>>>>>> build test, the build error is appended below. This is a link
>>>>>> to the
>>>>>> failed job:
>>>>>> https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
>>>>>>
>>>>>>
>>>>>>
>>>>>> gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-
>>>>>> prototypes -Wdeclaration-after-statement -Wno-unused-but-set-
>>>>>> variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer
>>>>>> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
>>>>>> -MMD -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE
>>>>>> -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/config.h
>>>>>> -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include
>>>>>> -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include
>>>>>> -D__XEN_TOOLS__ -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include
>>>>>> -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include
>>>>>> -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include -Wno-
>>>>>> declaration-after-statement -c -o xen-diag.o xen-diag.c
>>>>>> xen-fault-ttl.c: In function 'main':
>>>>>> xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig'
>>>>>> has no member named 'emulation_flags'
>>>>>> 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
>>>>>> | ^~~~~~~~~~~~~~~
>>>>>> xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared
>>>>>> (first use in this function)
>>>>>> 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
>>>>>> | ^~~~~~~~~~~~~~~~~
>>>>>> xen-fault-ttl.c:25:32: note: each undeclared identifier is
>>>>>> reported only once for each function it appears in
>>>>>> make[4]: *** [/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-
>>>>>> fault-ttl.o] Error 1
>>>>>> make[4]: *** Waiting for unfinished jobs....
>>>>>> make[4]: Leaving directory '/builds/xen-
>>>>>> project/patchew/xen/tools/misc'
>>>>>> make[3]: *** [/builds/xen-
>>>>>> project/patchew/xen/tools/../tools/Rules.mk:160: subdir-
>>>>>> install-misc] Error 2
>>>>>> make[3]: Leaving directory '/builds/xen-
>>>>>> project/patchew/xen/tools'
>>>>>> make[2]: *** [/builds/xen-
>>>>>> project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-
>>>>>> install] Error 2
>>>>>> make[2]: Leaving directory '/builds/xen-
>>>>>> project/patchew/xen/tools'
>>>>>> make[1]: *** [Makefile:67: install] Error 2
>>>>>> make[1]: Leaving directory '/builds/xen-
>>>>>> project/patchew/xen/tools'
>>>>>> make: *** [Makefile:134: install-tools] Error 2
>>>>>
>>>>> Yeah - that is a real failure, which can be fixed with a little
>>>>> bit of
>>>>> ifdef-ary. I'm confused as to why I didn't get that email
>>>>> directly.
>>>>
>>>> It looks like patchew doesn't yet CC the original author?
>>>
>>> Where do patchew emails go? I haven't seen any of them, and they
>>> don't
>>> seem to go to xen-devel.
>>
>> It's to limit the noise level. We intend to stablize the workflow a
>> little more esp. wrt false positives before making every reply go to
>> xen-devel. There's a few things to tweak in patchew.
>>
>> The next logical step should be including the patch author in the loop
>> I think.
>
> Let's do it.
Fam's e-mail suggested that the workflow is not fully stabilized. So I
would suggest to add a warning at the top of the e-mail avoiding more
noise on the thread.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2021-01-04 17:30 ` Stefano Stabellini
2021-01-04 17:35 ` Julien Grall
@ 2021-01-04 17:36 ` Andrew Cooper
2021-01-04 18:11 ` Stefano Stabellini
1 sibling, 1 reply; 13+ messages in thread
From: Andrew Cooper @ 2021-01-04 17:36 UTC (permalink / raw)
To: Stefano Stabellini, Zheng, Fam
Cc: roger.pau, julien, cardoe, wl, xen-devel, Bertrand.Marquis
On 04/01/2021 17:30, Stefano Stabellini wrote:
> On Mon, 4 Jan 2021, Zheng, Fam wrote:
>> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
>>> On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
>>>> On Wed, 23 Dec 2020, Andrew Cooper wrote:
>>>>> On 23/12/2020 19:45, Stefano Stabellini wrote:
>>>>>> On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Patchew automatically ran gitlab-ci pipeline with this patch
>>>>>>> (series) applied, but the job failed. Maybe there's a bug in
>>>>>>> the patches?
>>>>>>>
>>>>>>> You can find the link to the pipeline near the end of the
>>>>>>> report below:
>>>>>>>
>>>>>>> Type: series
>>>>>>> Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
>>>>>>> Subject: [PATCH 0/4] xen: domain-tracked allocations, and
>>>>>>> fault injection
>>>>>>>
>>>>>>> === TEST SCRIPT BEGIN ===
>>>>>>> #!/bin/bash
>>>>>>> sleep 10
>>>>>>> patchew gitlab-pipeline-check -p xen-project/patchew/xen
>>>>>>> === TEST SCRIPT END ===
>>>>>> [...]
>>>>>>
>>>>>>> === OUTPUT BEGIN ===
>>>>>>> [2020-12-23 16:38:43] Looking up pipeline...
>>>>>>> [2020-12-23 16:38:43] Found pipeline 233889763:
>>>>>>>
>>>>>>>
>> https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
>>>>>> This seems to be a genuine failure. Looking at the alpine-3.12-
>>>>>> gcc-arm64
>>>>>> build test, the build error is appended below. This is a link
>>>>>> to the
>>>>>> failed job:
>>>>>> https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
>>>>>>
>>>>>>
>>>>>>
>>>>>> gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-
>>>>>> prototypes -Wdeclaration-after-statement -Wno-unused-but-set-
>>>>>> variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer
>>>>>> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
>>>>>> -MMD -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE
>>>>>> -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/config.h
>>>>>> -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include
>>>>>> -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include
>>>>>> -D__XEN_TOOLS__ -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include
>>>>>> -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include
>>>>>> -I/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/include -Wno-
>>>>>> declaration-after-statement -c -o xen-diag.o xen-diag.c
>>>>>> xen-fault-ttl.c: In function 'main':
>>>>>> xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig'
>>>>>> has no member named 'emulation_flags'
>>>>>> 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
>>>>>> | ^~~~~~~~~~~~~~~
>>>>>> xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared
>>>>>> (first use in this function)
>>>>>> 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
>>>>>> | ^~~~~~~~~~~~~~~~~
>>>>>> xen-fault-ttl.c:25:32: note: each undeclared identifier is
>>>>>> reported only once for each function it appears in
>>>>>> make[4]: *** [/builds/xen-
>>>>>> project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-
>>>>>> fault-ttl.o] Error 1
>>>>>> make[4]: *** Waiting for unfinished jobs....
>>>>>> make[4]: Leaving directory '/builds/xen-
>>>>>> project/patchew/xen/tools/misc'
>>>>>> make[3]: *** [/builds/xen-
>>>>>> project/patchew/xen/tools/../tools/Rules.mk:160: subdir-
>>>>>> install-misc] Error 2
>>>>>> make[3]: Leaving directory '/builds/xen-
>>>>>> project/patchew/xen/tools'
>>>>>> make[2]: *** [/builds/xen-
>>>>>> project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-
>>>>>> install] Error 2
>>>>>> make[2]: Leaving directory '/builds/xen-
>>>>>> project/patchew/xen/tools'
>>>>>> make[1]: *** [Makefile:67: install] Error 2
>>>>>> make[1]: Leaving directory '/builds/xen-
>>>>>> project/patchew/xen/tools'
>>>>>> make: *** [Makefile:134: install-tools] Error 2
>>>>> Yeah - that is a real failure, which can be fixed with a little
>>>>> bit of
>>>>> ifdef-ary. I'm confused as to why I didn't get that email
>>>>> directly.
>>>> It looks like patchew doesn't yet CC the original author?
>>> Where do patchew emails go? I haven't seen any of them, and they
>>> don't
>>> seem to go to xen-devel.
>> It's to limit the noise level. We intend to stablize the workflow a
>> little more esp. wrt false positives before making every reply go to
>> xen-devel. There's a few things to tweak in patchew.
>>
>> The next logical step should be including the patch author in the loop
>> I think.
> Let's do it.
Are we sure? The false positive rate is still very high.
There are two separate x86 randconfig failures, an ARM randconfig
failure, and an ARM smoke test failure.
None of these are fair to be raised as objections to a contributor, as
it leaves the results very noisy.
I think we need to get to 0 known outstanding false positives before
continuing.
~Andrew
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2021-01-04 17:36 ` Andrew Cooper
@ 2021-01-04 18:11 ` Stefano Stabellini
0 siblings, 0 replies; 13+ messages in thread
From: Stefano Stabellini @ 2021-01-04 18:11 UTC (permalink / raw)
To: Andrew Cooper
Cc: Stefano Stabellini, Zheng, Fam, roger.pau, julien, cardoe, wl,
xen-devel, Bertrand.Marquis
[-- Attachment #1: Type: text/plain, Size: 5840 bytes --]
On Mon, 4 Jan 2021, Andrew Cooper wrote:
> On 04/01/2021 17:30, Stefano Stabellini wrote:
> > On Mon, 4 Jan 2021, Zheng, Fam wrote:
> >> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
> >>> On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> >>>> On Wed, 23 Dec 2020, Andrew Cooper wrote:
> >>>>> On 23/12/2020 19:45, Stefano Stabellini wrote:
> >>>>>> On Wed, 23 Dec 2020, no-reply@patchew.org wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Patchew automatically ran gitlab-ci pipeline with this patch
> >>>>>>> (series) applied, but the job failed. Maybe there's a bug in
> >>>>>>> the patches?
> >>>>>>>
> >>>>>>> You can find the link to the pipeline near the end of the
> >>>>>>> report below:
> >>>>>>>
> >>>>>>> Type: series
> >>>>>>> Message-id: 20201223163442.8840-1-andrew.cooper3@citrix.com
> >>>>>>> Subject: [PATCH 0/4] xen: domain-tracked allocations, and
> >>>>>>> fault injection
> >>>>>>>
> >>>>>>> === TEST SCRIPT BEGIN ===
> >>>>>>> #!/bin/bash
> >>>>>>> sleep 10
> >>>>>>> patchew gitlab-pipeline-check -p xen-project/patchew/xen
> >>>>>>> === TEST SCRIPT END ===
> >>>>>> [...]
> >>>>>>
> >>>>>>> === OUTPUT BEGIN ===
> >>>>>>> [2020-12-23 16:38:43] Looking up pipeline...
> >>>>>>> [2020-12-23 16:38:43] Found pipeline 233889763:
> >>>>>>>
> >>>>>>>
> >> https://gitlab.com/xen-project/patchew/xen/-/pipelines/233889763
> >>>>>> This seems to be a genuine failure. Looking at the alpine-3.12-
> >>>>>> gcc-arm64
> >>>>>> build test, the build error is appended below. This is a link
> >>>>>> to the
> >>>>>> failed job:
> >>>>>> https://gitlab.com/xen-project/patchew/xen/-/jobs/929842628
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-
> >>>>>> prototypes -Wdeclaration-after-statement -Wno-unused-but-set-
> >>>>>> variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer
> >>>>>> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
> >>>>>> -MMD -MP -MF .xen-diag.o.d -D_LARGEFILE_SOURCE
> >>>>>> -D_LARGEFILE64_SOURCE -Werror -include /builds/xen-
> >>>>>> project/patchew/xen/tools/misc/../../tools/config.h
> >>>>>> -I/builds/xen-
> >>>>>> project/patchew/xen/tools/misc/../../tools/include
> >>>>>> -I/builds/xen-
> >>>>>> project/patchew/xen/tools/misc/../../tools/include
> >>>>>> -D__XEN_TOOLS__ -I/builds/xen-
> >>>>>> project/patchew/xen/tools/misc/../../tools/include
> >>>>>> -I/builds/xen-
> >>>>>> project/patchew/xen/tools/misc/../../tools/include
> >>>>>> -I/builds/xen-
> >>>>>> project/patchew/xen/tools/misc/../../tools/include -Wno-
> >>>>>> declaration-after-statement -c -o xen-diag.o xen-diag.c
> >>>>>> xen-fault-ttl.c: In function 'main':
> >>>>>> xen-fault-ttl.c:25:14: error: 'struct xen_arch_domainconfig'
> >>>>>> has no member named 'emulation_flags'
> >>>>>> 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> >>>>>> | ^~~~~~~~~~~~~~~
> >>>>>> xen-fault-ttl.c:25:32: error: 'XEN_X86_EMU_LAPIC' undeclared
> >>>>>> (first use in this function)
> >>>>>> 25 | .emulation_flags = XEN_X86_EMU_LAPIC,
> >>>>>> | ^~~~~~~~~~~~~~~~~
> >>>>>> xen-fault-ttl.c:25:32: note: each undeclared identifier is
> >>>>>> reported only once for each function it appears in
> >>>>>> make[4]: *** [/builds/xen-
> >>>>>> project/patchew/xen/tools/misc/../../tools/Rules.mk:144: xen-
> >>>>>> fault-ttl.o] Error 1
> >>>>>> make[4]: *** Waiting for unfinished jobs....
> >>>>>> make[4]: Leaving directory '/builds/xen-
> >>>>>> project/patchew/xen/tools/misc'
> >>>>>> make[3]: *** [/builds/xen-
> >>>>>> project/patchew/xen/tools/../tools/Rules.mk:160: subdir-
> >>>>>> install-misc] Error 2
> >>>>>> make[3]: Leaving directory '/builds/xen-
> >>>>>> project/patchew/xen/tools'
> >>>>>> make[2]: *** [/builds/xen-
> >>>>>> project/patchew/xen/tools/../tools/Rules.mk:155: subdirs-
> >>>>>> install] Error 2
> >>>>>> make[2]: Leaving directory '/builds/xen-
> >>>>>> project/patchew/xen/tools'
> >>>>>> make[1]: *** [Makefile:67: install] Error 2
> >>>>>> make[1]: Leaving directory '/builds/xen-
> >>>>>> project/patchew/xen/tools'
> >>>>>> make: *** [Makefile:134: install-tools] Error 2
> >>>>> Yeah - that is a real failure, which can be fixed with a little
> >>>>> bit of
> >>>>> ifdef-ary. I'm confused as to why I didn't get that email
> >>>>> directly.
> >>>> It looks like patchew doesn't yet CC the original author?
> >>> Where do patchew emails go? I haven't seen any of them, and they
> >>> don't
> >>> seem to go to xen-devel.
> >> It's to limit the noise level. We intend to stablize the workflow a
> >> little more esp. wrt false positives before making every reply go to
> >> xen-devel. There's a few things to tweak in patchew.
> >>
> >> The next logical step should be including the patch author in the loop
> >> I think.
> > Let's do it.
>
> Are we sure? The false positive rate is still very high.
>
> There are two separate x86 randconfig failures, an ARM randconfig
> failure, and an ARM smoke test failure.
>
> None of these are fair to be raised as objections to a contributor, as
> it leaves the results very noisy.
>
> I think we need to get to 0 known outstanding false positives before
> continuing.
Zero known false positives is clearly the goal, and I would consider it
the required quality before we make the results public CCing xen-devel.
However, I would have thought that we don't need to reach that level to
start CCing contributors. Often the failures are genuine and at the
moment one of us is manually forwarding the failure notifications to the
contributor, which is not ideal.
CCing the contributor with a warning notice that the CC-loop is not yet
stable looks like a good way to start. Maybe after I solve the QEMU
segfault issue in the Dom0less test that you reported this morning.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2020-12-23 16:34 Andrew Cooper
2021-01-08 1:49 ` Stefano Stabellini
@ 2022-12-11 17:21 ` Julien Grall
1 sibling, 0 replies; 13+ messages in thread
From: Julien Grall @ 2022-12-11 17:21 UTC (permalink / raw)
To: Andrew Cooper, Xen-devel
Cc: Jan Beulich, Roger Pau Monné,
Wei Liu, Stefano Stabellini, Volodymyr Babchuk, Tamas K Lengyel
Hi Andrew,
On 23/12/2020 16:34, Andrew Cooper wrote:
> This was not the christmas hacking project that I was planning to do, but it
> has had some exciting results.
>
> After some discussion on an earlier thread, Tamas has successfully got fuzzing
> of Xen working via kfx, and this series is a prototype for providing better
> testing infrastructure.
>
> And to prove a point, this series has already found a memory leak in ARM's
> dom0less smoke test.
You mention this series recently on the ML. So I decided to give a try
and manage to reproduce your "memory leak".
I put it in quote because the problem is not Arm and instead your code.
If you look at the implementation of _dzalloc() you are using
_xmalloc(). So the memory is not guaranteed to be zeroed after been
allocation.
This is breaking the expectation of the callers. What you want is using
"_xzalloc()'.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
2020-12-23 16:34 Andrew Cooper
@ 2021-01-08 1:49 ` Stefano Stabellini
2022-12-11 17:21 ` Julien Grall
1 sibling, 0 replies; 13+ messages in thread
From: Stefano Stabellini @ 2021-01-08 1:49 UTC (permalink / raw)
To: Andrew Cooper
Cc: Xen-devel, Jan Beulich, Roger Pau Monné,
Wei Liu, Stefano Stabellini, Julien Grall, Volodymyr Babchuk,
Tamas K Lengyel
On Wed, 23 Dec 2020, Andrew Cooper wrote:
> This was not the christmas hacking project that I was planning to do, but it
> has had some exciting results.
>
> After some discussion on an earlier thread, Tamas has successfully got fuzzing
> of Xen working via kfx, and this series is a prototype for providing better
> testing infrastructure.
>
> And to prove a point, this series has already found a memory leak in ARM's
> dom0less smoke test.
>
> >From https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/929518792
>
> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
> (XEN) Freed 328kB init memory.
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER4
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER8
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER12
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER16
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER20
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER24
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER28
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER32
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0
> (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=25: not implemented
> (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=15: not implemented
> (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=15: not implemented
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) d1 has 2 outstanding heap allocations
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> For some reason, neither of the evtchn default memory allocations are freed,
> but it's not clear why d1 shut down to being with. Stefano - any ideas?
Right, this is confusing. It is not hard to believe that memory leaks
exist on the dom0less shutdown path because dom0less domains are not
really shutdown today. I imagine there could be issues.
But I don't understand why _domain_destroy gets called in the first
place for d1. Maybe a domain_create failure leads to goto fail and
_domain_destroy(). I wanted to run a test but ran out of time.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 0/4] xen: domain-tracked allocations, and fault injection
@ 2020-12-23 16:34 Andrew Cooper
2021-01-08 1:49 ` Stefano Stabellini
2022-12-11 17:21 ` Julien Grall
0 siblings, 2 replies; 13+ messages in thread
From: Andrew Cooper @ 2020-12-23 16:34 UTC (permalink / raw)
To: Xen-devel
Cc: Andrew Cooper, Jan Beulich, Roger Pau Monné,
Wei Liu, Stefano Stabellini, Julien Grall, Volodymyr Babchuk,
Tamas K Lengyel
This was not the christmas hacking project that I was planning to do, but it
has had some exciting results.
After some discussion on an earlier thread, Tamas has successfully got fuzzing
of Xen working via kfx, and this series is a prototype for providing better
testing infrastructure.
And to prove a point, this series has already found a memory leak in ARM's
dom0less smoke test.
From https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/929518792
(XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
(XEN) Freed 328kB init memory.
(XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER28
(XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER32
(XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0
(XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=25: not implemented
(XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=15: not implemented
(XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=15: not implemented
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) d1 has 2 outstanding heap allocations
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
For some reason, neither of the evtchn default memory allocations are freed,
but it's not clear why d1 shut down to being with. Stefano - any ideas?
Andrew Cooper (4):
xen/dmalloc: Introduce dmalloc() APIs
xen/evtchn: Switch to dmalloc
xen/domctl: Introduce fault_ttl
tools/misc: Test for fault injection
tools/misc/.gitignore | 1 +
tools/misc/Makefile | 5 ++++
tools/misc/xen-fault-ttl.c | 56 +++++++++++++++++++++++++++++++++++++++++++++
xen/common/Makefile | 1 +
xen/common/dmalloc.c | 25 ++++++++++++++++++++
xen/common/domain.c | 14 ++++++++++--
xen/common/event_channel.c | 14 ++++++------
xen/include/public/domctl.h | 1 +
xen/include/xen/dmalloc.h | 29 +++++++++++++++++++++++
xen/include/xen/sched.h | 3 +++
10 files changed, 140 insertions(+), 9 deletions(-)
create mode 100644 tools/misc/xen-fault-ttl.c
create mode 100644 xen/common/dmalloc.c
create mode 100644 xen/include/xen/dmalloc.h
--
2.11.0
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-12-11 17:22 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <160874604800.15699.17952392608790984041@600e7e483b3a>
2020-12-23 19:45 ` [PATCH 0/4] xen: domain-tracked allocations, and fault injection Stefano Stabellini
2020-12-23 20:01 ` Andrew Cooper
2020-12-23 20:10 ` Stefano Stabellini
2021-01-04 9:11 ` Zheng, Fam
2021-01-04 9:38 ` Roger Pau Monné
2021-01-04 10:53 ` Zheng, Fam
2021-01-04 17:30 ` Stefano Stabellini
2021-01-04 17:35 ` Julien Grall
2021-01-04 17:36 ` Andrew Cooper
2021-01-04 18:11 ` Stefano Stabellini
2020-12-23 16:34 Andrew Cooper
2021-01-08 1:49 ` Stefano Stabellini
2022-12-11 17:21 ` Julien Grall
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.