linux-kernel - Re: [PATCH] kselftest/alsa: Increase kselftest timeout

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: <20230515094310.hulpyhhtb4sxxn7i@rcn-XPS-13-9305>
Date:   Mon, 15 May 2023 11:43:10 +0200
From:   Ricardo Cañuelo <ricardo.canuelo@...labora.com>
To:     Shuah Khan <skhan@...uxfoundation.org>
Cc:     Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>, Mark Brown <broonie@...nel.org>,
        kernel@...labora.com, Jaroslav Kysela <perex@...ex.cz>,
        Shuah Khan <shuah@...nel.org>, Takashi Iwai <tiwai@...e.com>,
        alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH] kselftest/alsa: Increase kselftest timeout

Hi Shuah,

Bumping an old thread, this is still an issue for this test [1] and it
could end up affecting many others.

On mar 13-12-2022 11:37:56, Shuah Khan wrote:
> On 12/13/22 11:32, Nícolas F. R. A. Prado wrote:
> > The default timeout for kselftests is 45 seconds, but pcm-test can take
> > longer than that to run depending on the number of PCMs present on a
> > device.
> > 
> > As a data point, running pcm-test on mt8192-asurada-spherion takes about
> > 1m15s.
> > 
> > Set the timeout to 10 minutes, which should give enough slack to run the
> > test even on devices with many PCMs.
> > 
> 
> 10 minutes is way too long.

Is there a downside to that? There'll be some tests that take more time,
I don't think that's a problem with the tests or a reason to let them
timeout. IMO it's the test framework which should adapt to the needs of
different types of tests, and the solution provided by this patch is
good enough, it addresses the problem for this particular test suite.

If the solution is still unacceptable, do you have an alternative
proposal in mind that we can try to implement?

Thanks,
Ricardo

[1] https://linux.kernelci.org/test/case/id/646127cf62438996ba2e8648/