[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9eb1e48e-b273-475a-9740-52deedf11ee2@sirena.org.uk>
Date: Mon, 3 Jun 2024 18:22:32 +0100
From: Mark Brown <broonie@...nel.org>
To: Mickaël Salaün <mic@...ikod.net>
Cc: Christian Brauner <brauner@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jakub Kicinski <kuba@...nel.org>, Kees Cook <keescook@...omium.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Sasha Levin <sashal@...nel.org>,
Sean Christopherson <seanjc@...gle.com>,
Shengyu Li <shengyu.li.evgeny@...il.com>,
Shuah Khan <shuah@...nel.org>,
Shuah Khan <skhan@...uxfoundation.org>,
Bagas Sanjaya <bagasdotme@...il.com>,
Brendan Higgins <brendanhiggins@...gle.com>,
David Gow <davidgow@...gle.com>,
"David S . Miller" <davem@...emloft.net>,
Florian Fainelli <florian.fainelli@...adcom.com>,
Günther Noack <gnoack@...gle.com>,
Jon Hunter <jonathanh@...dia.com>, Ron Economos <re@...z.net>,
Ronald Warsow <rwarsow@....de>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Will Drewry <wad@...omium.org>,
kernel test robot <oliver.sang@...el.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
netdev@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v7 04/10] selftests/harness: Fix interleaved scheduling
leading to race conditions
On Mon, Jun 03, 2024 at 05:27:52PM +0100, Mark Brown wrote:
> On Mon, May 27, 2024 at 08:07:40PM +0100, Mark Brown wrote:
> > This is now in mainline and appears to be causing several tests (at
> > least the ptrace vmaccess global_attach test on arm64, possibly also
> > some of the epoll tests) that previously were timed out by the harness
> > to to hang instead. A bisect seems to point at this patch in
> > particular, there was a bunch of discussion of the fallout of these
> > patches but I'm afraid I lost track of it, is there something in flight
> > for this? -next is affected as well from the looks of it.
> FWIW I'm still seeing this on -rc2...
AFAICT this is due to the switch to using clone3() with CLONE_VFORK
to start the test which means we never even call alarm() to set up the
timeout for the test, let alone have the signal for it delivered. I'm a
confused about how this could ever work, with clone_vfork() the parent
shouldn't run until the child execs (which won't happen here) or exits.
Since we don't call alarm() until after we started the child we never
actually get that far, but even if we reorder things we'll not get the
signal for the alarm if the child messes up since the parent is
suspended.
I'm not clear what the original race being fixed here was but it seems
like we should revert this since the timeout functionality is pretty
important?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists