LinuxLists.cc - [PATCH 0/2] selftests/nolibc: small simplification of test development phase

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Sat, Jan 21, 2023 at 09:53:18AM +0100, Willy Tarreau wrote:
> Hello Paul,
>
> while developing and testing the recent changes for errno/environ/auxv, I
> found that I wasn't relying on the kernel that much and that I was mostly
> using qemu in userland only with my local kernel.
>
> I figured that it was more convenient for this purpose than rebuilding an
> initramfs and kernel for a quick test, and decided to make this approach
> easier to use for everyone by adding a "run-user" target to the Makefile
> to do exactly this. E.g:
>
> Native build:
> $ time make -C tools/testing/selftests/nolibc run-user
> ...
> make: Entering directory '/g/public/linux/master/tools/testing/selftests/nolibc'
> MKDIR sysroot/x86/include
> make[1]: Entering directory '/g/public/linux/master/tools/include/nolibc'
> make[2]: Entering directory '/g/public/linux/master'
> make[2]: Leaving directory '/g/public/linux/master'
> make[2]: Entering directory '/g/public/linux/master'
> INSTALL /g/public/linux/master/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/g/public/linux/master'
> make[1]: Leaving directory '/g/public/linux/master/tools/include/nolibc'
> CC nolibc-test
> 18 chroot_root = -1 EPERM [FAIL]
> 43 link_dir = -1 EACCES != (-1 EPERM) [FAIL]
> See all results in /g/public/linux/master/tools/testing/selftests/nolibc/run.out
> make: Leaving directory '/g/public/linux/master/tools/testing/selftests/nolibc'
>
> real 0m0.966s
> user 0m0.731s
> sys 0m0.164s
>
> Cross build:
> $ time make -C tools/testing/selftests/nolibc run-user ARCH=s390 CROSS_COMPILE=/f/tc/nolibc/gcc-11.3.0-nolibc/s390-linux/bin/s390-linux-
> make: Entering directory '/g/public/linux/master/tools/testing/selftests/nolibc'
> MKDIR sysroot/s390/include
> make[1]: Entering directory '/g/public/linux/master/tools/include/nolibc'
> make[2]: Entering directory '/g/public/linux/master'
> make[2]: Leaving directory '/g/public/linux/master'
> make[2]: Entering directory '/g/public/linux/master'
> INSTALL /g/public/linux/master/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/g/public/linux/master'
> make[1]: Leaving directory '/g/public/linux/master/tools/include/nolibc'
> CC nolibc-test
> 18 chroot_root = -1 EPERM [FAIL]
> 43 link_dir = -1 EACCES != (-1 EPERM) [FAIL]
> See all results in /g/public/linux/master/tools/testing/selftests/nolibc/run.out
> make: Leaving directory '/g/public/linux/master/tools/testing/selftests/nolibc'
>
> real 0m1.014s
> user 0m0.732s
> sys 0m0.183s
>
> In addition, the "x86_64" value for ARCH= is now supported as I got caught
> too many times with it not working in this subdir while it's used for the
> rest of the kernel ("x86" is used instead as coming from subarch.include).
> Generally you don't type it as x86_64 probably is the native build for most
> users, but when you start to test toolchains it's a different thing.
>
> There's no matter of urgency for these patches, they're just a bit of
> user-friendly stuff. As such, if you're fine with stacking them on top of
> what you already have for 6.3, that will be great, otherwise they can
> easily wait.
>
> Thank you!
> Willy

Nice, thank you!

I have these placed on top of the -rcu "dev" branch initially for further
review and testing. If things go well over the next week or so, I will
set it up for the upcoming merge window.

One dependency is of course qemu-x86_64, so in the meantime I will figure
out where I get that from. ;-)

Thanx, Paul

> [CCing Ammar who could benefit from this]
>
> ---
> Willy Tarreau (2):
> selftests/nolibc: support "x86_64" for arch name
> selftests/nolibc: add a "run-user" target to test the program in user
> land
>
> tools/testing/selftests/nolibc/Makefile | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> --
> 2.17.5
>

2023-01-21 21:37:00

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Sat, Jan 21, 2023 at 12:00:38PM -0800, Paul E. McKenney wrote:
> > There's no matter of urgency for these patches, they're just a bit of
> > user-friendly stuff. As such, if you're fine with stacking them on top of
> > what you already have for 6.3, that will be great, otherwise they can
> > easily wait.
> >
> > Thank you!
> > Willy
>
> Nice, thank you!
>
> I have these placed on top of the -rcu "dev" branch initially for further
> review and testing. If things go well over the next week or so, I will
> set it up for the upcoming merge window.

Thanks!

> One dependency is of course qemu-x86_64, so in the meantime I will figure
> out where I get that from. ;-)

I build it from time to time from the sources, it's not that long and
normally doesn't reserve me any surprises. But if you have it for other
platforms it's likely that you have it for most platforms as well,
including this one.

Best regards,
Willy

2023-01-23 16:47:28

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Sat, Jan 21, 2023 at 10:34:55PM +0100, Willy Tarreau wrote:
> On Sat, Jan 21, 2023 at 12:00:38PM -0800, Paul E. McKenney wrote:
> > > There's no matter of urgency for these patches, they're just a bit of
> > > user-friendly stuff. As such, if you're fine with stacking them on top of
> > > what you already have for 6.3, that will be great, otherwise they can
> > > easily wait.
> > >
> > > Thank you!
> > > Willy
> >
> > Nice, thank you!
> >
> > I have these placed on top of the -rcu "dev" branch initially for further
> > review and testing. If things go well over the next week or so, I will
> > set it up for the upcoming merge window.
>
> Thanks!
>
> > One dependency is of course qemu-x86_64, so in the meantime I will figure
> > out where I get that from. ;-)
>
> I build it from time to time from the sources, it's not that long and
> normally doesn't reserve me any surprises. But if you have it for other
> platforms it's likely that you have it for most platforms as well,
> including this one.

And building from sources proved to be reasonably easy, so the test
now passes for me. My initial thought of putting qemu-x86_64 into
my ~/bin directory fails the sudo test, but putting it into /usr/bin
works fine.

Thank you for the hints!

Should I add a sentence to the commit log noting the potential need to
build qemu from the git repo and to install qemu-x86_64, give or take
what architecture one is running?

Thanx, Paul

2023-01-23 16:58:13

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Sat, Jan 21, 2023 at 10:34:55PM +0100, Willy Tarreau wrote:
> On Sat, Jan 21, 2023 at 12:00:38PM -0800, Paul E. McKenney wrote:
> > One dependency is of course qemu-x86_64, so in the meantime I will figure
> > out where I get that from. ;-)
>
> I build it from time to time from the sources, it's not that long and
> normally doesn't reserve me any surprises. But if you have it for other
> platforms it's likely that you have it for most platforms as well,
> including this one.

Willy,

Is there a way to make it work for the default qemu installation?
Or maybe it's a mandatory requirement to build qemu from the source?

I use the qemu that comes from Ubuntu apt. I have "qemu-system-x86_64",
but no "qemu-x86_64". So, something like this...

$ which qemu-x86_64
$ echo $?
1

$ which qemu-system-x86_64
/usr/bin/qemu-system-x86_64

$ time make run-user
MKDIR sysroot/x86/include
make[1]: Entering directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
INSTALL /home/ammarfaizi2/work/linux.work.cc/tools/testing/selftests/nolibc/sysroot/sysroot/include
make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
make[1]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
CC nolibc-test
/bin/sh: 1: qemu-x86_64: not found
0 test(s) passed.

real 0m0.506s
user 0m0.393s
sys 0m0.086s

It would be great if we can avoid building qemu from the source. But if
not, let's go with that.

Thanks!

--
Ammar Faizi

2023-01-23 17:09:19

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Mon, Jan 23, 2023 at 11:57:56PM +0700, Ammar Faizi wrote:
> On Sat, Jan 21, 2023 at 10:34:55PM +0100, Willy Tarreau wrote:
> > On Sat, Jan 21, 2023 at 12:00:38PM -0800, Paul E. McKenney wrote:
> > > One dependency is of course qemu-x86_64, so in the meantime I will figure
> > > out where I get that from. ;-)
> >
> > I build it from time to time from the sources, it's not that long and
> > normally doesn't reserve me any surprises. But if you have it for other
> > platforms it's likely that you have it for most platforms as well,
> > including this one.
>
> Willy,
>
> Is there a way to make it work for the default qemu installation?
> Or maybe it's a mandatory requirement to build qemu from the source?
>
> I use the qemu that comes from Ubuntu apt. I have "qemu-system-x86_64",
> but no "qemu-x86_64". So, something like this...
>
> $ which qemu-x86_64
> $ echo $?
> 1
>
> $ which qemu-system-x86_64
> /usr/bin/qemu-system-x86_64
>
> $ time make run-user
> MKDIR sysroot/x86/include
> make[1]: Entering directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
> make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
> make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
> make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
> INSTALL /home/ammarfaizi2/work/linux.work.cc/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
> make[1]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
> CC nolibc-test
> /bin/sh: 1: qemu-x86_64: not found
> 0 test(s) passed.
>
> real 0m0.506s
> user 0m0.393s
> sys 0m0.086s
>
> It would be great if we can avoid building qemu from the source. But if
> not, let's go with that.

I had no problems building it from source.

One possible enhancement would be to make the error message tell the
user to build from source, but I will let you guys debate the merits
and drawbacks of that approach.

Thanx, Paul

2023-01-23 17:18:14

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

Hello Paul,

On Mon, Jan 23, 2023 at 08:47:21AM -0800, Paul E. McKenney wrote:
> And building from sources proved to be reasonably easy, so the test
> now passes for me. My initial thought of putting qemu-x86_64 into
> my ~/bin directory fails the sudo test, but putting it into /usr/bin
> works fine.

Great!

> Thank you for the hints!
>
> Should I add a sentence to the commit log noting the potential need to
> build qemu from the git repo and to install qemu-x86_64, give or take
> what architecture one is running?

Well, I've always had all the variants for all supported archs and
didn't know that sometimes only part of them could be installed.
I've used and tested qemu-{i386,x86_64,arm,aarch64,mips,s390x,riscv64}
with this with success, and all of them are built by default for me.
Thus I'm not seeing a good reason for making a special case of x86_64.
Or maybe I'm missing the point ?

Thanks,
Willy

2023-01-23 17:20:28

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

Hi Ammar,

On Mon, Jan 23, 2023 at 11:57:56PM +0700, Ammar Faizi wrote:
> Is there a way to make it work for the default qemu installation?
> Or maybe it's a mandatory requirement to build qemu from the source?
>
> I use the qemu that comes from Ubuntu apt. I have "qemu-system-x86_64",
> but no "qemu-x86_64". So, something like this...
>
> $ which qemu-x86_64
> $ echo $?
> 1
>
> $ which qemu-system-x86_64
> /usr/bin/qemu-system-x86_64

Ah now I think I understand Paul's question. I didn't know that the
userland version was not always provided. I've always had both side
by side.

> It would be great if we can avoid building qemu from the source. But if
> not, let's go with that.

As Paul indicated, it's really trouble-free and I think I've only done
that since the very first day I started to use QEMU, reason why I probably
never noticed that not everything was packaged.

Then at least to respond to Paul, it could make sense to add a note that
on some distros the userland version might not always be provided and
might require a pretty simple rebuild of QEMU.

Thanks!
Willy

2023-01-23 17:32:25

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Mon, Jan 23, 2023 at 06:20:16PM +0100, Willy Tarreau wrote:
> Ah now I think I understand Paul's question. I didn't know that the
> userland version was not always provided. I've always had both side
> by side.
>
> > It would be great if we can avoid building qemu from the source. But if
> > not, let's go with that.
>
> As Paul indicated, it's really trouble-free and I think I've only done
> that since the very first day I started to use QEMU, reason why I probably
> never noticed that not everything was packaged.
>
> Then at least to respond to Paul, it could make sense to add a note that
> on some distros the userland version might not always be provided and
> might require a pretty simple rebuild of QEMU.

Ah well...

I figured it out. It turned qemu-user is a different package.
So I have "qemu-system" installed, but not "qemu-user".

Without building from source, just do this on Ubuntu:

$ sudo apt-get install qemu-user -y
...
Preparing to unpack .../qemu-user_1%3a6.2+dfsg-2ubuntu6.6_amd64.deb ...
Unpacking qemu-user (1:6.2+dfsg-2ubuntu6.6) ...
Selecting previously unselected package qemu-user-binfmt.
Preparing to unpack .../qemu-user-binfmt_1%3a6.2+dfsg-2ubuntu6.6_amd64.deb ...
Unpacking qemu-user-binfmt (1:6.2+dfsg-2ubuntu6.6) ...
Setting up qemu-user (1:6.2+dfsg-2ubuntu6.6) ...
Setting up qemu-user-binfmt (1:6.2+dfsg-2ubuntu6.6) ...
Processing triggers for man-db (2.10.2-1) ...

$ which qemu-x86_64
/usr/bin/qemu-x86_64

$ sudo make run-user
MKDIR sysroot/x86/include
make[1]: Entering directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
INSTALL /home/ammarfaizi2/work/linux.work.cc/tools/testing/selftests/nolibc/sysroot/sysroot/include
make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
make[1]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
CC nolibc-test
83 test(s) passed.

Sorry for that. I didn't know that they come from different packages.
It works fine for me now.

--
Ammar Faizi

2023-01-23 17:35:39

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Mon, Jan 23, 2023 at 06:17:12PM +0100, Willy Tarreau wrote:
> Hello Paul,
>
> On Mon, Jan 23, 2023 at 08:47:21AM -0800, Paul E. McKenney wrote:
> > And building from sources proved to be reasonably easy, so the test
> > now passes for me. My initial thought of putting qemu-x86_64 into
> > my ~/bin directory fails the sudo test, but putting it into /usr/bin
> > works fine.
>
> Great!
>
> > Thank you for the hints!
> >
> > Should I add a sentence to the commit log noting the potential need to
> > build qemu from the git repo and to install qemu-x86_64, give or take
> > what architecture one is running?
>
> Well, I've always had all the variants for all supported archs and
> didn't know that sometimes only part of them could be installed.
> I've used and tested qemu-{i386,x86_64,arm,aarch64,mips,s390x,riscv64}
> with this with success, and all of them are built by default for me.
> Thus I'm not seeing a good reason for making a special case of x86_64.
> Or maybe I'm missing the point ?

Fair point, and yes, I am showing the x86-centricity of my test
environment. ;-) This might also apply to non-x86 distro setups,
but I have no idea either way.

I would be OK leaving it as is and responding to problems if and when
they actually occur. But you are quite correct, if we do add some sort of
informative "Just build qemu!" diagnostic, it should be arch-independent.

Thanx, Paul

2023-01-23 17:35:59

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Sat, Jan 21, 2023 at 12:00:38PM -0800, Paul E. McKenney wrote:
> Nice, thank you!
>
> I have these placed on top of the -rcu "dev" branch initially for further
> review and testing. If things go well over the next week or so, I will
> set it up for the upcoming merge window.
>
> One dependency is of course qemu-x86_64, so in the meantime I will figure
> out where I get that from. ;-)

Thank you all, I'll base my work on top of the -rcu "dev" branch.

Tested-by: Ammar Faizi <[email protected]>

--
Ammar Faizi

2023-01-23 17:37:39

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Tue, Jan 24, 2023 at 12:31:01AM +0700, Ammar Faizi wrote:
> I figured it out. It turned qemu-user is a different package.
> So I have "qemu-system" installed, but not "qemu-user".
>
> Without building from source, just do this on Ubuntu:
>
> $ sudo apt-get install qemu-user -y
> ...
> Preparing to unpack .../qemu-user_1%3a6.2+dfsg-2ubuntu6.6_amd64.deb ...
> Unpacking qemu-user (1:6.2+dfsg-2ubuntu6.6) ...
> Selecting previously unselected package qemu-user-binfmt.
> Preparing to unpack .../qemu-user-binfmt_1%3a6.2+dfsg-2ubuntu6.6_amd64.deb ...
> Unpacking qemu-user-binfmt (1:6.2+dfsg-2ubuntu6.6) ...
> Setting up qemu-user (1:6.2+dfsg-2ubuntu6.6) ...
> Setting up qemu-user-binfmt (1:6.2+dfsg-2ubuntu6.6) ...
> Processing triggers for man-db (2.10.2-1) ...
>
> $ which qemu-x86_64
> /usr/bin/qemu-x86_64

Ah cool! I looked for something like this on a remote ubuntu system but
failed to figure it out by myself. Do you also have the other archs with
it ?

> $ sudo make run-user
> MKDIR sysroot/x86/include
> make[1]: Entering directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
> make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
> make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
> make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
> INSTALL /home/ammarfaizi2/work/linux.work.cc/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
> make[1]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
> CC nolibc-test
> 83 test(s) passed.

Great. And without sudo you should see two of them fail. I intend to
implement geteuid() and condition their result to it, that will be
sufficient for most cases. I'd rather avoid seeing users run test
programs under sudo actually, since they're run on the local system :-/

> Sorry for that. I didn't know that they come from different packages.
> It works fine for me now.

No, don't be sorry, quite the opposite, you taught us something useful!

Thank you!
Willy

2023-01-23 17:40:11

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Tue, Jan 24, 2023 at 12:31:01AM +0700, Ammar Faizi wrote:
> On Mon, Jan 23, 2023 at 06:20:16PM +0100, Willy Tarreau wrote:
> > Ah now I think I understand Paul's question. I didn't know that the
> > userland version was not always provided. I've always had both side
> > by side.
> >
> > > It would be great if we can avoid building qemu from the source. But if
> > > not, let's go with that.
> >
> > As Paul indicated, it's really trouble-free and I think I've only done
> > that since the very first day I started to use QEMU, reason why I probably
> > never noticed that not everything was packaged.
> >
> > Then at least to respond to Paul, it could make sense to add a note that
> > on some distros the userland version might not always be provided and
> > might require a pretty simple rebuild of QEMU.
>
> Ah well...
>
> I figured it out. It turned qemu-user is a different package.
> So I have "qemu-system" installed, but not "qemu-user".
>
> Without building from source, just do this on Ubuntu:
>
> $ sudo apt-get install qemu-user -y
> ...
> Preparing to unpack .../qemu-user_1%3a6.2+dfsg-2ubuntu6.6_amd64.deb ...
> Unpacking qemu-user (1:6.2+dfsg-2ubuntu6.6) ...
> Selecting previously unselected package qemu-user-binfmt.
> Preparing to unpack .../qemu-user-binfmt_1%3a6.2+dfsg-2ubuntu6.6_amd64.deb ...
> Unpacking qemu-user-binfmt (1:6.2+dfsg-2ubuntu6.6) ...
> Setting up qemu-user (1:6.2+dfsg-2ubuntu6.6) ...
> Setting up qemu-user-binfmt (1:6.2+dfsg-2ubuntu6.6) ...
> Processing triggers for man-db (2.10.2-1) ...
>
> $ which qemu-x86_64
> /usr/bin/qemu-x86_64
>
> $ sudo make run-user
> MKDIR sysroot/x86/include
> make[1]: Entering directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
> make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
> make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
> make[2]: Entering directory '/home/ammarfaizi2/work/linux.work.cc'
> INSTALL /home/ammarfaizi2/work/linux.work.cc/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc'
> make[1]: Leaving directory '/home/ammarfaizi2/work/linux.work.cc/tools/include/nolibc'
> CC nolibc-test
> 83 test(s) passed.
>
> Sorry for that. I didn't know that they come from different packages.
> It works fine for me now.

I looked for that, but didn't find it, so thank you!

(Yes, I should have used dpkg, but I was lazy.)

Except that when I install Ubuntu 20.04's version, I get this:

------------------------------------------------------------------------

$ sudo make run-user
MKDIR sysroot/x86/include
make[1]: Entering directory '/home/git/linux-rcu/tools/include/nolibc'
make[2]: Entering directory '/home/git/linux-rcu'
make[2]: Leaving directory '/home/git/linux-rcu'
make[2]: Entering directory '/home/git/linux-rcu'
INSTALL /home/git/linux-rcu/tools/testing/selftests/nolibc/sysroot/sysroot/include
make[2]: Leaving directory '/home/git/linux-rcu'
make[1]: Leaving directory '/home/git/linux-rcu/tools/include/nolibc'
CC nolibc-test
32 gettimeofday_null = -1 EFAULT [FAIL]
See all results in /home/git/linux-rcu/tools/testing/selftests/nolibc/run.out

------------------------------------------------------------------------

I have attached run.out.

In contrast, with my hand-built qemu-x86_64, all tests passed.

This might be just a version-related bug, but figured I should let you
guys know.

Thanx, Paul

Attachments:

(No filename) (3.44 kB)
run.out (3.88 kB)
run.out Download all attachments

2023-01-23 17:40:50

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Mon, Jan 23, 2023 at 06:37:07PM +0100, Willy Tarreau wrote:
> Ah cool! I looked for something like this on a remote ubuntu system but
> failed to figure it out by myself. Do you also have the other archs with
> it ?

Yes, they come with many architectures.

$ ls /usr/bin/qemu-* | cat
/usr/bin/qemu-aarch64
/usr/bin/qemu-aarch64_be
/usr/bin/qemu-alpha
/usr/bin/qemu-arm
/usr/bin/qemu-armeb
/usr/bin/qemu-cris
/usr/bin/qemu-hexagon
/usr/bin/qemu-hppa
/usr/bin/qemu-i386
/usr/bin/qemu-img
/usr/bin/qemu-io
/usr/bin/qemu-m68k
/usr/bin/qemu-microblaze
/usr/bin/qemu-microblazeel
/usr/bin/qemu-mips
/usr/bin/qemu-mips64
/usr/bin/qemu-mips64el
/usr/bin/qemu-mipsel
/usr/bin/qemu-mipsn32
/usr/bin/qemu-mipsn32el
/usr/bin/qemu-nbd
/usr/bin/qemu-nios2
/usr/bin/qemu-or1k
/usr/bin/qemu-ppc
/usr/bin/qemu-ppc64
/usr/bin/qemu-ppc64le
/usr/bin/qemu-pr-helper
/usr/bin/qemu-riscv32
/usr/bin/qemu-riscv64
/usr/bin/qemu-s390x
/usr/bin/qemu-sh4
/usr/bin/qemu-sh4eb
/usr/bin/qemu-sparc
/usr/bin/qemu-sparc32plus
/usr/bin/qemu-sparc64
/usr/bin/qemu-storage-daemon
/usr/bin/qemu-system-i386
/usr/bin/qemu-system-x86_64
/usr/bin/qemu-system-x86_64-microvm
/usr/bin/qemu-system-x86_64-spice
/usr/bin/qemu-x86_64
/usr/bin/qemu-xtensa
/usr/bin/qemu-xtensaeb

> Great. And without sudo you should see two of them fail. I intend to
> implement geteuid() and condition their result to it, that will be
> sufficient for most cases. I'd rather avoid seeing users run test
> programs under sudo actually, since they're run on the local system :-/

I see.

--
Ammar Faizi

2023-01-23 17:52:12

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Tue, Jan 24, 2023 at 12:34:43AM +0700, Ammar Faizi wrote:
> On Sat, Jan 21, 2023 at 12:00:38PM -0800, Paul E. McKenney wrote:
> > Nice, thank you!
> >
> > I have these placed on top of the -rcu "dev" branch initially for further
> > review and testing. If things go well over the next week or so, I will
> > set it up for the upcoming merge window.
> >
> > One dependency is of course qemu-x86_64, so in the meantime I will figure
> > out where I get that from. ;-)
>
> Thank you all, I'll base my work on top of the -rcu "dev" branch.
>
> Tested-by: Ammar Faizi <[email protected]>

I will apply this on my next rebase, thank you!

Thanx, Paul

2023-01-23 19:02:03

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Mon, Jan 23, 2023 at 09:40:03AM -0800, Paul E. McKenney wrote:
> I looked for that, but didn't find it, so thank you!
>
> (Yes, I should have used dpkg, but I was lazy.)
>
> Except that when I install Ubuntu 20.04's version, I get this:
>
> ------------------------------------------------------------------------
>
> $ sudo make run-user
> MKDIR sysroot/x86/include
> make[1]: Entering directory '/home/git/linux-rcu/tools/include/nolibc'
> make[2]: Entering directory '/home/git/linux-rcu'
> make[2]: Leaving directory '/home/git/linux-rcu'
> make[2]: Entering directory '/home/git/linux-rcu'
> INSTALL /home/git/linux-rcu/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/home/git/linux-rcu'
> make[1]: Leaving directory '/home/git/linux-rcu/tools/include/nolibc'
> CC nolibc-test
> 32 gettimeofday_null = -1 EFAULT [FAIL]
> See all results in /home/git/linux-rcu/tools/testing/selftests/nolibc/run.out
>
> ------------------------------------------------------------------------
>
> I have attached run.out.
>
> In contrast, with my hand-built qemu-x86_64, all tests passed.
>
> This might be just a version-related bug, but figured I should let you
> guys know.

This is an interesting bug.

I'm a bit reluctant to say that this is a qemu bug. But I can't
reproduce it on my machine. I use qemu that comes from Ubuntu 22.04.

FWIW, my qemu version is:

$ qemu-x86_64 -version
qemu-x86_64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.6)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

I'll take a look at that gettimeofday() code and see if we have a bug in
it. In meantime, could you send your qemu version info?

--
Ammar Faizi

2023-01-23 19:12:50

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Tue, Jan 24, 2023 at 02:01:50AM +0700, Ammar Faizi wrote:
> On Mon, Jan 23, 2023 at 09:40:03AM -0800, Paul E. McKenney wrote:
> > I looked for that, but didn't find it, so thank you!
> >
> > (Yes, I should have used dpkg, but I was lazy.)
> >
> > Except that when I install Ubuntu 20.04's version, I get this:
> >
> > ------------------------------------------------------------------------
> >
> > $ sudo make run-user
> > MKDIR sysroot/x86/include
> > make[1]: Entering directory '/home/git/linux-rcu/tools/include/nolibc'
> > make[2]: Entering directory '/home/git/linux-rcu'
> > make[2]: Leaving directory '/home/git/linux-rcu'
> > make[2]: Entering directory '/home/git/linux-rcu'
> > INSTALL /home/git/linux-rcu/tools/testing/selftests/nolibc/sysroot/sysroot/include
> > make[2]: Leaving directory '/home/git/linux-rcu'
> > make[1]: Leaving directory '/home/git/linux-rcu/tools/include/nolibc'
> > CC nolibc-test
> > 32 gettimeofday_null = -1 EFAULT [FAIL]
> > See all results in /home/git/linux-rcu/tools/testing/selftests/nolibc/run.out
> >
> > ------------------------------------------------------------------------
> >
> > I have attached run.out.
> >
> > In contrast, with my hand-built qemu-x86_64, all tests passed.
> >
> > This might be just a version-related bug, but figured I should let you
> > guys know.
>
> This is an interesting bug.
>
> I'm a bit reluctant to say that this is a qemu bug. But I can't
> reproduce it on my machine. I use qemu that comes from Ubuntu 22.04.
>
> FWIW, my qemu version is:
>
> $ qemu-x86_64 -version
> qemu-x86_64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.6)
> Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
>
> I'll take a look at that gettimeofday() code and see if we have a bug in
> it. In meantime, could you send your qemu version info?

Thank you for looking into this, and here you go:

$ qemu-x86_64 -version
qemu-x86_64 version 4.2.1 (Debian 1:4.2-3ubuntu6.24)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

The version that I built by hand (which passed all tests) is as follows:

$ /home/git/qemu/build/qemu-x86_64 -version
qemu-x86_64 version 7.2.0 (v7.2.0)
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

Thanx, Paul

2023-01-23 19:13:15

[permalink] [raw]

Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

On Mon, Jan 23, 2023 at 09:40:03AM -0800, Paul E. McKenney wrote:
> Except that when I install Ubuntu 20.04's version, I get this:
>
> ------------------------------------------------------------------------
>
> $ sudo make run-user
> MKDIR sysroot/x86/include
> make[1]: Entering directory '/home/git/linux-rcu/tools/include/nolibc'
> make[2]: Entering directory '/home/git/linux-rcu'
> make[2]: Leaving directory '/home/git/linux-rcu'
> make[2]: Entering directory '/home/git/linux-rcu'
> INSTALL /home/git/linux-rcu/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/home/git/linux-rcu'
> make[1]: Leaving directory '/home/git/linux-rcu/tools/include/nolibc'
> CC nolibc-test
> 32 gettimeofday_null = -1 EFAULT [FAIL]
> See all results in /home/git/linux-rcu/tools/testing/selftests/nolibc/run.out
>
> ------------------------------------------------------------------------
>
> I have attached run.out.
>
> In contrast, with my hand-built qemu-x86_64, all tests passed.
>
> This might be just a version-related bug, but figured I should let you
> guys know.

Interesting. Maybe something differs in the way it passes expectedly
invalid pointers to some syscalls. Keep in mind that it's using your
local kernel also, that could make a difference. I'm not that much keen
on trying to investigate that one to be honest, given that this user
mode is really meant to ease the life of test developers like Ammar
and myself who just want to focus on the correctness of the test they're
adding and not that much on the validity of the test itself in this
context. I suggest we keep this one in mind without putting too much
effort on it for now.

Thanks!
Willy

2023-01-23 19:25:49