* 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
* [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
* 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
* 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
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.