Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    I wonder if any applications depend on the new (now reverted) behaviour. And what they will do if that is the case.

    Comment


    • #12
      Originally posted by loganj View Post
      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.
      You don't put out a fire by pointing fingers and figuring out who started it.

      You put it out, then you go back and see what happened. This was the right course, they'll address this in the future so it seldom happens, but of course, it will happen. I agree with the post earlier about API abuse, though.

      Comment


      • #13
        I do believe in "We do not break userspace".
        But not at any cost. This was a reasonable change.
        If it took 2 bloody years to notice enough to make it revert then it's not an issue.
        They can recompile their code or patch their release.

        Better yet. Give me back non-stupid behavior and let Android #¤%#¤% tune a knob with sysctl for stupid behavior.

        Comment


        • #14
          Originally posted by skeevy420 View Post

          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.

          Comment


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

            Can't start a fire on an iceberg.

            Comment


            • #16
              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.
              Last edited by indepe; 31 July 2021, 03:15 PM.

              Comment


              • #17
                Originally posted by Vistaus View Post
                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).

                Comment


                • #18
                  Originally posted by rogerx View Post
                  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.

                  Comment


                  • #19
                    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.

                    Comment


                    • #20
                      Fixing an issue after 9 kernels is too long. It's absurd!
                      Last edited by Azrael5; 01 August 2021, 10:31 AM.

                      Comment

                      Working...
                      X