Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	"Zheng, Fam" <famzheng@amazon.com>
Cc: "roger.pau@citrix.com" <roger.pau@citrix.com>,
	"julien@xen.org" <julien@xen.org>,
	"cardoe@cardoe.com" <cardoe@cardoe.com>,
	"wl@xen.org" <wl@xen.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Bertrand.Marquis@arm.com" <Bertrand.Marquis@arm.com>
Subject: Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
Date: Mon, 4 Jan 2021 17:36:04 +0000	[thread overview]
Message-ID: <429efe8c-7c41-b297-47a4-865b148886a3@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2101040930090.3465@sstabellini-ThinkPad-T480s>

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