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

[arQon]

I do believe this is one of the few times Linus is in the wrong on that pledge

Agreed. What's puzzling though is I think the "right" solution here is obvious: this is something that *mainline* should fix, and Android should carry the hack out of tree.

"We don't break userspace" notwithstanding, I don't see why that isn't the path he's chosen here. Especially since Android is realistically a closed-source project anyway. I don't see any reason for the kernel not to treat it the same as nvidia drivers or any other such case where non-GPL software is involved, and the responsibility for coping with kernel changes lies with the people who've chosen to opt out of the GPL ecosystem.

[pmorph]

Quick, just write a program that relies on the new behavior, then you can claim regression if and when it does switch back to the 4.x behavior in 5.14.

I suppose what matters is how bad the end user effect will be. Similarly as no company would choose to break the products their customers are using, just to make something technically correct.

[uxmkt]

Quick, just write a program that relies on the new behavior, then you can claim regression if and when it does switch back to the 4.x behavior in 5.14.

[Azrael5]

Fixing an issue after 9 kernels is too long. It's absurd!

[xeekei]

Wait, so technically anyone who has found a bug that needs to be adressed, can write some dumbass code that uses it, and then effectively hold the entire Linux kernel hostage?
Surprising that it hasn't happened before.

[uxmkt]

Ridiculous... This is just the tip of the iceberg of what's to come.
Can't start a fire on an iceberg.

Unless it's an iceberg with methane in it.

[You-]

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

I can see that you definitely read the article:

This has broken "numerous Android applications" since Linux 5.5, but given the long period of times between kernel versions shipped by Android, it only has become a problem recently with Android transitioning to Linux 5.10 LTS

Assuming Android 12 defaults to supporting 5.10, you can expect devices released this year and early next to use this as the base kernel version (and then never move to a higher version).

[indepe]

As far as I understand, only a small part of the original improvement was reverted (a probably minor optimization that avoids checking for readers).

Without knowing the API or its use, it seems the strange thing is that the API allows blocked readers even when the pipe isn't empty anymore. However as long as the API allows that situation, then what else should wake those readers? So I guess the correct behavior is to wake blocked readers on any write. And I guess an application which doesn't want that behavior would not have any blocked readers waiting for a non-empty pipe, in the first place.

Again, I am saying this without knowing the API or its use, just from the description here and in the links. However if I understood it correctly, this partial revert shouldn't be a problem.

[rogerx]

Ridiculous... This is just the tip of the iceberg of what's to come.

Can't start a fire on an iceberg.

[milkylainen]

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

use_old_pipe=y/n

sysctl knob? The "feature" is a two line patch.