linux-kernel - Re: [PATCH] ASoC: qdsp6: q6apm: use dai link pcm id as pcm device number

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: <00ac35ee-b507-43ee-b596-801b76972946@sirena.org.uk>
Date:   Thu, 29 Jun 2023 22:23:53 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Greg KH <greg@...ah.com>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        johan+linaro@...nel.org, perex@...ex.cz, tiwai@...e.com,
        lgirdwood@...il.com, ckeepax@...nsource.cirrus.com,
        kuninori.morimoto.gx@...esas.com, linux-kernel@...r.kernel.org,
        pierre-louis.bossart@...ux.intel.com, alsa-devel@...a-project.org,
        Stable@...r.kernel.org
Subject: Re: [PATCH] ASoC: qdsp6: q6apm: use dai link pcm id as pcm device
 number

On Thu, Jun 29, 2023 at 08:48:42PM +0200, Greg KH wrote:
> On Thu, Jun 29, 2023 at 06:38:38PM +0100, Mark Brown wrote:

> > As discussed before your tolerance for risk in stable is *far* higher
> > than mine, if there's any value in doing this at all it's probably
> > within what would get taken but that doesn't mean that it's something
> > that it's sensible to highlight as an important fix like tagging for
> > stable does.  It's extremely unclear that it fits the severity criteria
> > that are supposed to be being applied to stable, though obviously the
> > documentation doesn't fit the actual practice these days.

> It's not a matter of "tolerance for risk", it's a "if this change is
> good enough for future releases, why isn't it good enough for older
> releases as well?"

> As you know, we don't break user interfaces, so either this is a break
> or it isn't, stable trees have nothing to do with it as a normal user
> would "hit" this when updating to run Linus's tree, just as easily as
> they would "hit" it updating their stable kernel version.

You know as well as I do that we have a bunch of interfaces where things
end up getting dynamically numbered as they appear, and provided to
userspace together with identifying information that allows userspace to
figure out what's what in a stable fashion even though the numbers might
change.  Like I said earlier in the thread this is one of them, better
hardware support also has some risk of disturbing things (and some of
the numbering is going to be hotplug dependent, though this patch isn't
likely to run into that particular bit of things).

ABI stability is a continuum, from for example things relying on race
conditions or other timing things that were lucky they ever worked to
changes in interfaces that break clear and documented guarantees.
Reliance on stability is similar, and how much of an issue it is when
something does change and someone notices is going to vary depending on
what changed and why.  While the risk here seems low if the reasoning is
just to make things neater then it's even harder to justify for a stable
kernel than it is for mainline.

Note also that the patch is still under discussion for mainline...

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)