linux-kernel - Re: [PATCH v3 08/12] selftests/nolibc: allow quit qemu-system when poweroff fails

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230729082950.GL956@1wt.eu>
Date:   Sat, 29 Jul 2023 10:29:50 +0200
From:   Willy Tarreau <w@....eu>
To:     Thomas Weißschuh <thomas@...ch.de>
Cc:     Zhangjin Wu <falcon@...ylab.org>, arnd@...db.de,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v3 08/12] selftests/nolibc: allow quit qemu-system when
 poweroff fails

On Sat, Jul 29, 2023 at 09:59:55AM +0200, Thomas Weißschuh wrote:
> On 2023-07-28 04:30:31+0800, Zhangjin Wu wrote:
> > The kernel of some architectures can not poweroff qemu-system normally,
> > especially for tinyconfig.
(...)
> This feels fairly hacky.

and totally unmaintainable in the long term. It may even fail for
some users having localization.

> Before we complicated nolibc-test to handle the no-procfs case to save a
> few seconds building the kernel and now we have fairly big timeouts.
> And a statemachine that relies on the specific strings emitted by the
> testsuite.
> 
> I would like to get back to something more deterministic and obvious,
> even at the cost of some time spent compiling the test kernels.
> (saying this as somebody developing on a 2016 ultrabook)

Agreed!

> "Since the low-level poweroff support is heavily kernel & qemu dependent"
> 
> The kernel we can control.
> 
> How common are qemus with that are missing poweroff support? 
> As this worked before I guess the only architecture where this could
> pose a problem would be ppc.
> 
> 
> An alternative I would like to put up for discussion:
> 
> qemu could provide a watchdog device that is pinged by nolibc-test for
> each testcase.
> After nolibc-test is done and didn't poweroff properly the watchdog will
> reset the machine. ( -watchog-action poweroff ).
> 
> The disadvantages are that we would need to add watchdog drivers to the
> kernels and figure out the correct watchdog devices and drivers for each arch.

It's an interesting idea, though at first glance it does not seem to
have one for PPC.

I think I have a much simpler idea: we don't care about PPC32. I mean
OK it can be supported if it happens to work, we will just not include
it in default runs, because it will require Ctrl-C to finish, and so
what ? nolibc has been in the kernel for 5 years or so, nobody ever
cared about PPC, why should we suddenly break or complicate everything
just to support a sub-arch that nobody found interesting to add till
now?

> It seems virtio-watchdog is not yet usable.

Then it might become an option for the future when it eventually works.

Thanks,
Willy