linux-kernel - Re: [PATCH] ASoC: soc-pcm: fix fe and be race when accessing substream->runtime

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]

Date:   Wed, 28 Sep 2022 16:24:43 +0200
From:   Cezary Rojewski <cezary.rojewski@...el.com>
To:     Eugeniu Rosca <erosca@...adit-jv.com>
CC:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, <alsa-devel@...a-project.org>,
        <linux-kernel@...r.kernel.org>,
        Yanmin Zhang <yanmin_zhang@...ux.intel.com>,
        Eugeniu Rosca <roscaeugeniu@...il.com>,
        "Jiada Wang" <jiada_wang@...tor.com>,
        Zhang Yanmin <yanmin.zhang@...el.com>,
        "Ramesh Babu" <ramesh.babu@...el.com>,
        Dean Jenkins <Dean_Jenkins@...tor.com>,
        "Ramesh Babu B" <ramesh.babu.b@...el.com>,
        xiao jin <jin.xiao@...el.com>,
        "Pierre-Louis Bossart" <pierre-louis.bossart@...ux.intel.com>,
        Amadeusz Sławiński 
        <amadeuszx.slawinski@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Bard Liao <yung-chuan.liao@...ux.intel.com>,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
        Guennadi Liakhovetski <guennadi.liakhovetski@...ux.intel.com>,
        Rander Wang <rander.wang@...ux.intel.com>
Subject: Re: [PATCH] ASoC: soc-pcm: fix fe and be race when accessing
 substream->runtime

On 2022-09-27 1:00 PM, Eugeniu Rosca wrote:
> Hello Czarek,

...

>> I'd like to know more about the scenario you guys reproduced the problem in.
> 
> This patch was originally identified in the Intel Apollo Lake v4.1 KNLs.
> Given that the change itself is in the core sound subsystem, our internal
> assessment was that the patch might potentially be relevant/helpful
> on other HW platforms.
> 
> Our intention is to confirm or invalidate this assumption with the
> original developers of the patch, as well as with the audio maintainers
> and the members of the alsa-devel ML.
> 
>> Configuration details and kernel base would be good to know too. Since our
>> CI did not detect problem of such sort, if the problem actually exists, we
>> would like to append a test or two to cover it later on.
> 
> If there is no evidence that the patch is fixing a real-life issue
> occurring in the latest vanilla, I agree to drop the patch.
> 
> So far, I do not possess this evidence myself.


I've spent some time to locate the change. Found it and it seems 
obsolete. Some tags are missing in the revision of yours and the 
original date does not match either - it's Apr 2018 for the original. 
Won't be mentioning the tags as some engineers no longer bear @intel.com.

soc-pcm and skylake-driver valuable bits from those trees are already 
part of the upstream. Most of what is left was later proven obsolete or 
redundant by my or Pierre's engineers. There seems to be no patch 
missing except for few fixes from the recent SKL/KBL up-revs for our 
clients. Nothing APL specific.

Following kernels related to APL are maintained by the IPG team from 
software perspective:
	4.1.42, 4.1.49, 4.4, 4.9, 4.14, 4.19

Multiple OSes. And then there are flavors for kernels/OS both. It's 
quite likely kernel base of yours fits into one of these buckets or at 
least have had changes ported from one of them.

TLDR: I agree here with my colleagues - if you believe the change is 
necessary, a proof e.g.: in form of reproduction steps, is needed. 
Otherwise it's no-go. Happy to hop on a call should you need any 
additional information.


Regards,
Czarek