linux-kernel - Re: [PATCH AUTOSEL 5.10 30/62] ASoC: rt5645: add error checking to rt5645

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: <YK129caVtNBthNDG@equinox>
Date:   Tue, 25 May 2021 23:15:17 +0100
From:   Phillip Potter <phil@...lpotter.co.uk>
To:     Mark Brown <broonie@...nel.org>
Cc:     Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        alsa-devel@...a-project.org
Subject: Re: [PATCH AUTOSEL 5.10 30/62] ASoC: rt5645: add error checking to
 rt5645_probe function

On Tue, May 25, 2021 at 10:49:44PM +0100, Mark Brown wrote:
> On Mon, May 24, 2021 at 10:47:11AM -0400, Sasha Levin wrote:
> > From: Phillip Potter <phil@...lpotter.co.uk>
> > 
> > [ Upstream commit 5e70b8e22b64eed13d5bbebcb5911dae65bf8c6b ]
> > 
> > Check for return value from various snd_soc_dapm_* calls, as many of
> > them can return errors and this should be handled. Also, reintroduce
> > the allocation failure check for rt5645->eq_param as well. Make all
> 
> Now I've looked at the patch I don't think it's appropriate for
> stable, it's essentially equivalent to a patch that adds -Werror
> - the changes in it are upgrading things from error messages that
> would be generated by what are essentially static checks (even
> though we do do them at runtime they're on hard coded strings) to
> probe failures which would be a regression.  Unfortunately people
> do ignore warnings like that in shipping stuff so it's possible
> it's happening, we could do an audit to see if it is but it seems
> like more effort than it's worth.
> 
> The only case I can think where it might help is if we're
> managing to OOM during probe() but that feels very unlikely to
> happen, and improved handling unlikely to make substantial
> difference compared to the risk that the routing warnings are
> triggering but being ignored so someone's sound stops working due
> to a stable update.  Otherwise it won't do much so why risk it?

Dear Mark,

So I frankly don't have the experience to disagree with you :-) Your
reasoning certainly seems sound to me. My original motivation for the
patch (after discussion with others within the mentorship process) was
that some other sound SoC drivers do this, an example being the Ux500. I
defer to the decision of the community as a whole of course, and am
happy with whatever is decided.

Regards,
Phil