linux-kernel - Re: [PATCH 2/2] kselftest/alsa: pcm-test: Decrease stream duration from 4 to 2 seconds

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: <5c2d5213-5299-44f1-9611-26002c8a5d3a@notapiano>
Date:   Wed, 21 Jun 2023 12:03:22 -0400
From:   Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Jaroslav Kysela <perex@...ex.cz>, kernel@...labora.com,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        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 2/2] kselftest/alsa: pcm-test: Decrease stream duration
 from 4 to 2 seconds

On Wed, Jun 21, 2023 at 03:39:12PM +0100, Mark Brown wrote:
> On Wed, Jun 21, 2023 at 04:08:47PM +0200, Jaroslav Kysela wrote:
> 
> > I think that the problem is somewhere else here. The overall test timeout
> > should be calculated dynamically. All tests may be queried for the maximal
> > expected interval based on the hardware/software capabilities. It's a bit
> > pitfall to have a fixed time limit where the realtime tests depend on the
> > number of devices.
> 
> I tend to agree here, unfortunately Shuah hasn't responded to queries
> from Nícolas about this which I imagine is what inspired this patch.  We
> also have problems with mixer-test on one of the Dialog CODECs with a
> couple of 64k value controls and no cache only mode.

Yes, exactly. I've tried increasing the timeout for this test to a larger fixed
value previously, and later asked for more information on how to deal with the
kselftest timeout. [1]

Since I didn't hear back, I thought this patch would be a way to at least
mitigate the issue for now, without limiting the test coverage, which was a
concern with having limited scopes for the test.

I've just noticed that in the mean time a way to override the timeout when
running kselftest has been introduced [2], so I suppose we could use that to
work around the timeout limitation in CI systems and be able to run through
completion on the different hardware at the lab. But I still believe, like you
do, that calculating the timeout at runtime based on the hardware would make
much more sense, though if there's such a desire to keep kselftests under the
45s mark, I'm not sure if it would be acceptable.

[1] https://lore.kernel.org/all/5302e70d-cb58-4e70-b44f-ff81b138a2e1@notapiano/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f6a01213e3f8

Thanks,
Nícolas