linux-kernel - Re: [PATCH AUTOSEL 5.2 040/123] ASoC: Fail card instantiation if DAI format setup fails

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: <20190828021311.GV5281@sasha-vm>
Date:   Tue, 27 Aug 2019 22:13:11 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Ricard Wanderlof <ricard.wanderlof@...s.com>,
        Ricard Wanderlof <ricardw@...s.com>
Subject: Re: [PATCH AUTOSEL 5.2 040/123] ASoC: Fail card instantiation if DAI
 format setup fails

On Tue, Aug 27, 2019 at 12:00:14PM +0100, Mark Brown wrote:
>On Sun, Aug 25, 2019 at 09:35:15PM -0400, Sasha Levin wrote:
>> On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
>
>> > > If the DAI format setup fails, there is no valid communication format
>> > > between CPU and CODEC, so fail card instantiation, rather than continue
>> > > with a card that will most likely not function properly.
>
>> > This is another one where if nobody noticed a problem already and things
>> > just happened to be working this might break things, it's vanishingly
>> > unlikely to fix anything that was broken.
>
>> Same as the other patch: this patch suggests it fixes a real bug, and if
>> this patch is broken let's fix it.
>
>If anyone ran into this on the older kernel and fixed or worked
>around it locally there's a reasonable chance this will then
>break what they're doing.  The patch itself is perfectly fine but

But there's not much we can do here. We can't hold off on fixing
breakage such as this because existing users have workarounds for this.
Are we breaking kernel ABI with this patch then?

And what about new users? We'll let them get hit by the issue and
develop their own workarounds?

>that doesn't mean the rest of the changes it's being backported
>into are also fine.

This is fair, and we can always hold off on patches if you want more
time for them to be tested/reviewed. Is it the case here?

--
Thanks,
Sasha