[XEN PATCH v2 0/7] automation: Update containers to allow HTTPS access to xenbits

Anthony PERARD posted 7 patches 1 year, 2 months ago
Test gitlab-ci failed
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20230221165542.7642-1-anthony.perard@citrix.com
There is a newer version of this series
automation/build/centos/7.2.dockerfile        | 52 ----------------
automation/build/centos/7.dockerfile          |  3 +-
automation/build/centos/CentOS-7.2.repo       | 35 -----------
.../build/debian/jessie-i386.dockerfile       |  7 ++-
automation/build/debian/jessie.dockerfile     |  7 ++-
automation/build/debian/unstable-llvm-8.list  |  3 -
automation/build/debian/unstable.dockerfile   | 12 ----
automation/build/ubuntu/trusty.dockerfile     |  5 ++
automation/gitlab-ci/build.yaml               | 60 -------------------
automation/scripts/containerize               |  3 +
10 files changed, 22 insertions(+), 165 deletions(-)
delete mode 100644 automation/build/centos/7.2.dockerfile
delete mode 100644 automation/build/centos/CentOS-7.2.repo
delete mode 100644 automation/build/debian/unstable-llvm-8.list
[XEN PATCH v2 0/7] automation: Update containers to allow HTTPS access to xenbits
Posted by Anthony PERARD 1 year, 2 months ago
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.gitlab-containers-update-v2

v2:
- Remove CentOS 7.2
- Remove Debian Jessie test, but update container recipe for the benefit of
  older branches.
- Fix CentOS 7 containner recipe to update all packages. (Fix missing update of
  HTTPS root certificates)

There is work in progress [1] to update urls in our repo to use https, but
those https urls to xenbits don't work in our containers, due to an expired
root certificate. So we need to update those containers.

This series update the dockerfile where just rebuilding the container isn't enough.

I've tested the new containers but didn't updated them yet. You can see the
result in the following links (if you can access them). There are other
containers been test which didn't need dockerfile update.
(That was with v1 of the series)
    https://gitlab.com/xen-project/people/anthonyper/xen/-/pipelines/777474218
    https://gitlab.com/xen-project/people/anthonyper/xen/-/pipelines/778218868

Building randconfig on debian unstable seems to be an issue.

[1] https://lore.kernel.org/xen-devel/75d91def8234bceb41548147ee8af5fea52bd1d6.1675889602.git.demi@invisiblethingslab.com/

Cheers,

Anthony PERARD (7):
  automation: Remove CentOS 7.2 containers and builds
  automation: Ensure that all packages are up-to-dates in CentOS 7
    container
  automation: Remove clang-8 from Debian unstable container
  automation: Use EOL tag for Jessie container
  automation: Add more aliases in containerize
  automation: Remove testing on Debian Jessie
  automation: Remove expired root certificates used to be used by let's
    encrypt

 automation/build/centos/7.2.dockerfile        | 52 ----------------
 automation/build/centos/7.dockerfile          |  3 +-
 automation/build/centos/CentOS-7.2.repo       | 35 -----------
 .../build/debian/jessie-i386.dockerfile       |  7 ++-
 automation/build/debian/jessie.dockerfile     |  7 ++-
 automation/build/debian/unstable-llvm-8.list  |  3 -
 automation/build/debian/unstable.dockerfile   | 12 ----
 automation/build/ubuntu/trusty.dockerfile     |  5 ++
 automation/gitlab-ci/build.yaml               | 60 -------------------
 automation/scripts/containerize               |  3 +
 10 files changed, 22 insertions(+), 165 deletions(-)
 delete mode 100644 automation/build/centos/7.2.dockerfile
 delete mode 100644 automation/build/centos/CentOS-7.2.repo
 delete mode 100644 automation/build/debian/unstable-llvm-8.list

-- 
Anthony PERARD
Debian randconfig failure, Was Re: [XEN PATCH v2 0/7] automation: Update containers to allow HTTPS access to xenbits
Posted by Andrew Cooper 1 year, 2 months ago
On 21/02/2023 4:55 pm, Anthony PERARD wrote:
> Building randconfig on debian unstable seems to be an issue.

You're talking about
https://gitlab.com/xen-project/people/anthonyper/xen/-/jobs/3769926509 ?

+ gcc --version
gcc (Debian 12.2.0-14) 12.2.0

arch/x86/extable.c: In function 'search_pre_exception_table':
arch/x86/extable.c:200:27: error: array subscript -1 is outside array
bounds of 'struct exception_table_entry[1152921504606846975]'
[-Werror=array-bounds]
  200 |     unsigned long fixup = search_one_extable(
      |                           ^~~~~~~~~~~~~~~~~~~
  201 |         __start___pre_ex_table, __stop___pre_ex_table-1, addr);
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from arch/x86/extable.c:8:
./arch/x86/include/asm/uaccess.h:414:37: note: at offset -8 into object
'__stop___pre_ex_table' of size [0, 9223372036854775807]
  414 | extern struct exception_table_entry __stop___pre_ex_table[];
      |                                     ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[3]: *** [Rules.mk:246: arch/x86/extable.o] Error 1

Jan: do we need some more gcc-wrap sprinkled around?

~Andrew

Re: Debian randconfig failure, Was Re: [XEN PATCH v2 0/7] automation: Update containers to allow HTTPS access to xenbits
Posted by Jan Beulich 1 year, 2 months ago
On 21.02.2023 19:05, Andrew Cooper wrote:
> On 21/02/2023 4:55 pm, Anthony PERARD wrote:
>> Building randconfig on debian unstable seems to be an issue.
> 
> You're talking about
> https://gitlab.com/xen-project/people/anthonyper/xen/-/jobs/3769926509 ?
> 
> + gcc --version
> gcc (Debian 12.2.0-14) 12.2.0
> 
> arch/x86/extable.c: In function 'search_pre_exception_table':
> arch/x86/extable.c:200:27: error: array subscript -1 is outside array
> bounds of 'struct exception_table_entry[1152921504606846975]'
> [-Werror=array-bounds]
>   200 |     unsigned long fixup = search_one_extable(
>       |                           ^~~~~~~~~~~~~~~~~~~
>   201 |         __start___pre_ex_table, __stop___pre_ex_table-1, addr);
>       |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from arch/x86/extable.c:8:
> ./arch/x86/include/asm/uaccess.h:414:37: note: at offset -8 into object
> '__stop___pre_ex_table' of size [0, 9223372036854775807]
>   414 | extern struct exception_table_entry __stop___pre_ex_table[];
>       |                                     ^~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make[3]: *** [Rules.mk:246: arch/x86/extable.o] Error 1
> 
> Jan: do we need some more gcc-wrap sprinkled around?

I think we can get away without, but first of all I'm curious why gcc12
spots an issue there, but not in my (and perhaps also your) local builds.
Being a randconfig failure, is this tied to a specific setting in .config?
Off the top of my head I can't think of any which might affect this code.

To work around this, instead of adding gcc-wrap-ery, I'd favor simply
changing search_one_extable()'s 2nd parameter's meaning from "last" to
"end" (i.e. the range passed in from [,] to [,) in mathematical spelling).

Jan

Re: Debian randconfig failure, Was Re: [XEN PATCH v2 0/7] automation: Update containers to allow HTTPS access to xenbits
Posted by Jan Beulich 1 year, 2 months ago
On 22.02.2023 10:42, Jan Beulich wrote:
> On 21.02.2023 19:05, Andrew Cooper wrote:
>> On 21/02/2023 4:55 pm, Anthony PERARD wrote:
>>> Building randconfig on debian unstable seems to be an issue.
>>
>> You're talking about
>> https://gitlab.com/xen-project/people/anthonyper/xen/-/jobs/3769926509 ?
>>
>> + gcc --version
>> gcc (Debian 12.2.0-14) 12.2.0
>>
>> arch/x86/extable.c: In function 'search_pre_exception_table':
>> arch/x86/extable.c:200:27: error: array subscript -1 is outside array
>> bounds of 'struct exception_table_entry[1152921504606846975]'
>> [-Werror=array-bounds]
>>   200 |     unsigned long fixup = search_one_extable(
>>       |                           ^~~~~~~~~~~~~~~~~~~
>>   201 |         __start___pre_ex_table, __stop___pre_ex_table-1, addr);
>>       |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> In file included from arch/x86/extable.c:8:
>> ./arch/x86/include/asm/uaccess.h:414:37: note: at offset -8 into object
>> '__stop___pre_ex_table' of size [0, 9223372036854775807]
>>   414 | extern struct exception_table_entry __stop___pre_ex_table[];
>>       |                                     ^~~~~~~~~~~~~~~~~~~~~
>> cc1: all warnings being treated as errors
>> make[3]: *** [Rules.mk:246: arch/x86/extable.o] Error 1
>>
>> Jan: do we need some more gcc-wrap sprinkled around?
> 
> I think we can get away without, but first of all I'm curious why gcc12
> spots an issue there, but not in my (and perhaps also your) local builds.
> Being a randconfig failure, is this tied to a specific setting in .config?
> Off the top of my head I can't think of any which might affect this code.

Looks to be the combination of DEBUG=n and COVERAGE=y.

> To work around this, instead of adding gcc-wrap-ery, I'd favor simply
> changing search_one_extable()'s 2nd parameter's meaning from "last" to
> "end" (i.e. the range passed in from [,] to [,) in mathematical spelling).

I'll make a patch along these lines then, I guess. Should I credit Anthony,
you, or both of you as the reporter?

Jan

Re: Debian randconfig failure, Was Re: [XEN PATCH v2 0/7] automation: Update containers to allow HTTPS access to xenbits
Posted by Andrew Cooper 1 year, 2 months ago
On 22/02/2023 9:53 am, Jan Beulich wrote:
> On 22.02.2023 10:42, Jan Beulich wrote:
>> On 21.02.2023 19:05, Andrew Cooper wrote:
>>> On 21/02/2023 4:55 pm, Anthony PERARD wrote:
>>>> Building randconfig on debian unstable seems to be an issue.
>>> You're talking about
>>> https://gitlab.com/xen-project/people/anthonyper/xen/-/jobs/3769926509 ?
>>>
>>> + gcc --version
>>> gcc (Debian 12.2.0-14) 12.2.0
>>>
>>> arch/x86/extable.c: In function 'search_pre_exception_table':
>>> arch/x86/extable.c:200:27: error: array subscript -1 is outside array
>>> bounds of 'struct exception_table_entry[1152921504606846975]'
>>> [-Werror=array-bounds]
>>>   200 |     unsigned long fixup = search_one_extable(
>>>       |                           ^~~~~~~~~~~~~~~~~~~
>>>   201 |         __start___pre_ex_table, __stop___pre_ex_table-1, addr);
>>>       |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> In file included from arch/x86/extable.c:8:
>>> ./arch/x86/include/asm/uaccess.h:414:37: note: at offset -8 into object
>>> '__stop___pre_ex_table' of size [0, 9223372036854775807]
>>>   414 | extern struct exception_table_entry __stop___pre_ex_table[];
>>>       |                                     ^~~~~~~~~~~~~~~~~~~~~
>>> cc1: all warnings being treated as errors
>>> make[3]: *** [Rules.mk:246: arch/x86/extable.o] Error 1
>>>
>>> Jan: do we need some more gcc-wrap sprinkled around?
>> I think we can get away without, but first of all I'm curious why gcc12
>> spots an issue there, but not in my (and perhaps also your) local builds.
>> Being a randconfig failure, is this tied to a specific setting in .config?
>> Off the top of my head I can't think of any which might affect this code.
> Looks to be the combination of DEBUG=n and COVERAGE=y.
>
>> To work around this, instead of adding gcc-wrap-ery, I'd favor simply
>> changing search_one_extable()'s 2nd parameter's meaning from "last" to
>> "end" (i.e. the range passed in from [,] to [,) in mathematical spelling).
> I'll make a patch along these lines then, I guess. Should I credit Anthony,
> you, or both of you as the reporter?

Yeah, I did wonder about changing the final parameter after sending this
email.  It stands a reasonable change of simplifying
search_one_extable() anyway.

Probably Anthony.  All I did was look through some logs.

~Andrew