On Wed, Jun 14, 2023 at 11:16:19AM +0200, Takashi Iwai wrote:
On Wed, 14 Jun 2023 10:52:54 +0200,
Oswald Buddenhagen wrote:
you're allowing _hypothetical_ crappy 3rd party code to dictate what
you can and cannot do. that's a completely unreasonable and
counterproductive attitude, akin to letting hostage-takers set the
rules.
Oswald, it's no hypothetical, I have seen lots of applications that
did crash with such mixer element changes in the past.
these apps have been meanwhile fixed or become obsolete, which makes it
a hypothetical again.
It's no dictation by 3rd party.
it IS. that's exactly what letting downstream limit your possibilities
is. especially if it's BROKEN downstream.
We simply must not crash things by an
update (unless it's a must, something like a security fix).
and i'm telling you that this is an unreasonable reading of the rule.
_every_ new feature in something already existing has the potential to
blow up some crappy downstream code.
>> > Oh well, that's really not a change to be advertised for creating /
>> > deleting kctls from the put callback at all.
>> > and? it's done, and it's basically impossible to revert. so we
>> may
>> reap its full benefits just as well, as i did in that previous commit.
>
> Well, I can revert your commit, too...
>
sure, but my point was that there are likely many more such commits,
some of them not explicitly marked as such. it would be a very costly
and risky exercise to actually do that revert at this point.
Sure, I didn't mean to do it immediately, it's no easy task.
great! then you can adjust this driver at that later point as well, when
you actually want to go forward with that project. ;-)
> The way you're trying to implement is an anti-pattern,
>
that's something you keep repeating in various ways, but i see no
evidence that there is an _actual_ problem.
There were actual problems, and we had to address them.
what exactly where those problems?
do the circumstances under which they occurred still apply?
The API is there and it should be usable in the ideal world, but we
know that it breaks far more than expected. We don't prohibit that
API, but the actual use should be limited for very special use cases.
that's exactly the wrong way to go about it. the way to make sure that
fewer apps crash is to hammer them as much as possible. if you wanted to
make sure that they all *really* work, you'd randomly create and destroy
fake controls from time to time.
If it were triggered in only certain (rare and race-free) situations,
it'd be acceptable. But your patch allows every user to trigger it by
the normal kctl value adjustment, which is simply no-go.
you are describing a completely contrieved attack scenario. it would
have to be a multi-user system with an e-mu card where one user
intentionally messes with the mixer to crash a broken application
another user is using at the same time. think through the probabilities,
motivations, alternative attack vectors, and how the whole affair would
play out IRL for the attacker.
regards,
ossi
