linux-kernel - Re: revert: 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]

Date:   Fri, 6 Sep 2019 14:38:24 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Ricard Wanderlof <ricard.wanderlof@...s.com>,
        stable@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
        linux-kernel@...r.kernel.org
Subject: Re: revert: ASoC: Fail card instantiation if DAI format setup fails

On Fri, Sep 06, 2019 at 11:58:24AM +0100, Mark Brown wrote:
>On Fri, Sep 06, 2019 at 10:40:01AM +0200, Ricard Wanderlof wrote:
>
>> But is this being dropped from the master branch as well? To me it makes
>> the kernel behave in an inconsistent way, first reporting a failure to
>> instantiate a specific sound card in the kernel log, but then seemingly
>> bringing it up anyway.
>
>No, this is absolutely a good and positive change to have in
>master and I'm not suggesting that we should drop it there -
>sorry if I sounded like that.  I just want to be conservative for
>stable so that we don't have anyone updating their stable kernel
>and having their audio blow up on them, we don't want to do
>anything that'd discourage people from taking stable updates and
>hence missing out on security or critical stability updates.

Hi Mark,

I'm sorry for not dropping this to begin with: I saw your nack and the
patch ended up still being released because of my fuck up rather than
me purposefuly ignoring your ack, sorry.

However, I'd like to say that I don't agree with it. I understand your
reasoning about keeping the stable trees conservative, but I feel that
going to the extreme with it will just encourage folks to not upgrade
between major versions.

I'd like to think that upgrading major versions should be the same as
upgrading minor ones (because numbers don't matter here). If that's not
the case, let's fix it!

--
Thanks,
Sasha