Linux Changes Pipe Behavior After Breaking Problematic Android Apps On Recent Kernels

[phoronix]

Phoronix: Linux Changes Pipe Behavior After Breaking Problematic Android Apps On Recent Kernels

At the end of 2019 a rework to the Linux kernel's pipe code saw some of its logic reworked to only wake up readers if needed and avoid a possible thundering herd problem. But it turns out some Android libraries abused the functionality and this has led to broken Android applications when moving to recent kernels. While the user-space software is in the wrong, the kernel is sticking to its policy of not breaking user-space and as such Linus Torvalds has changed the code's behavior for Linux 5.14 and to be back-ported to prior stable kernels...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Broke-Android-Apps-Pipe

[bachchain]

I understand that "WE DO NOT BREAK USERSPACE", but I can't help but feeling that API abuse shouldn't be included in that guarantee.

[stormcrow]

I understand that "WE DO NOT BREAK USERSPACE", but I can't help but feeling that API abuse shouldn't be included in that guarantee.

I do believe this is one of the few times Linus is in the wrong on that pledge and it's come back to bite.

[skeevy420]

I do believe this is one of the few times Linus is in the wrong on that pledge and it's come back to bite.

Couldn't this just be an option at compile or startup?

use_old_pipe=y/n

[Vistaus]

Why would this be an issue? I thought all Android phones used ancient kernel versions?

[leo_sk]

If someone depends on a bug for his workflow, its called a feature.

I see it can be bad when security is compromised, but in most other situations, its a good philosophy, and no one is foolish enough to apply a general statement everywhere indiscriminately, instead of a case by case basis. That said, hopefully these libraries are updated by the time android moves on to next LTS kernel

[NathanSamson]

If someone depends on a bug for his workflow, its called a feature.

I see it can be bad when security is compromised, but in most other situations, its a good philosophy, and no one is foolish enough to apply a general statement everywhere indiscriminately, instead of a case by case basis. That said, hopefully these libraries are updated by the time android moves on to next LTS kernel

What incentive do they have to upgrade/change their behaviour? It seems Linux would support their use-case forever?

Unless the post wasn't complete and Linus is planning to depreceate the old behaviour in the future and just giving these apps a few more months/years to change, but I dont think that was specified...

[perpetually high]

Why would this be an issue? I thought all Android phones used ancient kernel versions?

longterm: 4.19.200 2021-07-31 [tarball] [pgp] [patch] [inc. patch] [view diff] [browse] [changelog]
longterm: 4.14.241 2021-07-28 [tarball] [pgp] [patch] [inc. patch] [view diff] [browse] [changelog]
longterm: 4.9.277 2021-07-28 [tarball] [pgp] [patch] [inc. patch] [view diff] [browse] [changelog]
longterm: 4.4.277 2021-07-28 [tarball] [pgp] [patch] [inc. patch] [view diff] [browse] [changelog]

All those longterm kernels are probably getting lots of new code, that are being backported in. I'm just guessing, but I think that's what's happening. It's not just security patches that make it through, other stuff does as well.

[loganj]

this is definitely strange. i never expected that linux will revert a good patch for the sake of some applications.
nicely done.
and to think that they have issues with nvidia not being opensource friendly.

[stormcrow]

If someone depends on a bug for his workflow, its called a feature.

I see it can be bad when security is compromised, but in most other situations, its a good philosophy, and no one is foolish enough to apply a general statement everywhere indiscriminately, instead of a case by case basis. That said, hopefully these libraries are updated by the time android moves on to next LTS kernel

No, it's still called a bug. Just because someone decided they liked the bug doesn't mean it's any less a bug - unintended consequences by the creator. Depending on buggy behavior is on the program dev to fix their program, no matter how widespread use that program happens to be. I know I may be in the minority with that point of view, but the other point of view leads to the awful state of mainstream software today. There is no easy way to tell if buggy behavior (or feature as you call it) winds up an exploit in tomorrow's security breach. Fixing it today means that exploit couldn't use that particular bug to begin with.