Announcement

Collapse
No announcement yet.

Linux Pipe Code Again Sees Patch To Restore Buggy/Improper User-Space Behavior

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

  • Linux Pipe Code Again Sees Patch To Restore Buggy/Improper User-Space Behavior

    Phoronix: Linux Pipe Code Again Sees Patch To Restore Buggy/Improper User-Space Behavior

    It was just last month that the Linux kernel saw a pipe code change to address a user-space regression due to the kernel's policy about not breaking the user-space even if that non-kernel code is in the wrong. A similar kernel regression fix was merged today...

    https://www.phoronix.com/scan.php?pa...ken-User-Again

  • #2
    I can just imagine a few years from now someone trying to do a rewrite of epoll that makes it 10x faster, but being rejected because it breaks this one buggy version of this one library that nobody uses anymore
    Last edited by bachchain; 25 August 2021, 08:15 PM.

    Comment


    • #3
      Backward compatibility is fine, but the userspace libraries should be changed to detect this. E.g. the library works if it is built for release, but asserts an error if debugging.

      Comment


      • #4
        Originally posted by bachchain View Post
        I can just imagine a few years from now someone trying to do a rewrite of epoll that makes it 10x faster, but being rejected because it breaks this one buggy version of this one library that nobody uses anymore
        That’s where a new bitflag is required for creating epoll using the new implementation.

        Comment


        • #5

          Originally posted by bachchain View Post

          I can just imagine a few years from now someone trying to do a rewrite of epoll that makes it 10x faster, but being rejected because it breaks this one buggy version of this one library that nobody uses anymore

          Originally posted by NobodyXu View Post
          That’s where a new bitflag is required for creating epoll using the new implementation.
          Or Indeed, as has happened many times when the original syscall did not have a flags argument, create an new syscall; we have lots of them like openat2, pipe2, etc. In the case of epoll, there is not one syscall, but a collection that constitute an API, one of which takes a variety of flags to determine behaviour. One aspect of this particular regression was a misapprehension of what EPOLLET implied-- userspace relying on a behaviour that was not promised by the API, and having trouble when that changed. They are not playing by 8 year old autistic child rules... userspace can mostly rely upon not being broken, and progress can be made, bugs fixed, security issues dealt with...

          Comment


          • #6
            Originally posted by bachchain View Post
            I can just imagine a few years from now someone trying to do a rewrite of epoll that makes it 10x faster, but being rejected because it breaks this one buggy version of this one library that nobody uses anymore
            The issue here is that, given the wide use of these syscalls, if one popular open source library is noticably broken then there is likely hundreds or thousands of private, personal and/or internal use cases broken as well. It's not like the only users of the linux syscall interface are large major OSS projects

            Comment


            • #7
              This is how it should be done. All user space libraries should take notice. Never, ever break the ABI of the library once it has been declared stable. Furthermore, never change the behavior of a function in your library in such a way that applications that used to work suddenly misbehave or crash when using a new version of your library. The only exception to this rule is changes that fixes a security issue. It does not matter if applications were using some "undocumented behavior" of the function, they should not have to pay the price that you did not design the function right in the first place.
              Just implement a new "function2" or use symbol versioning.
              Like Linus said

              "it's a regression when that behavior changes. It's on us: we were silly to have that non-optimal historical behavior..."

              Now that is the right attitude.
              Last edited by tomas; 26 August 2021, 02:32 AM.

              Comment


              • #8
                Don't agree. There have to be borders for every stupid call. You don't go throw yourself off a cliff because "everybody else does it".
                This is a living codebase. If literally NOBODY beside stupid Android libraries cared for several years, then it's not an issue.
                And it's not like they can't fix the behavior into something sane?

                This is just Linus being compelled to following his own rules because he told people off so many times,
                he can't go breaking the rules himself.
                Last edited by milkylainen; 26 August 2021, 02:41 AM. Reason: Edit: Add the real reason...

                Comment


                • #9
                  For better or worse, Linux is a server OS first. From this perspective it makes sense, you would like to have your 10 year old docker image run unmodified forever.

                  ​​​​​

                  Comment


                  • #10
                    Originally posted by milkylainen View Post
                    This is a living codebase.
                    The code base yes. The syscall ABI no, it's a contract that should not be broken. Applications that used to work should continue to work, unless they rely on some security flaw of a syscall.
                    If literally NOBODY beside stupid Android libraries cared for several years, then it's not an issue.
                    Except that those "stupid Android libraries" constitute a HUGE user base. Much bigger than for example desktop Linux.
                    And it's not like they can't fix the behavior into something sane?
                    Yes, of course. By using a new version of said syscall, transitioning at their own pace, at a point in time of their choice. Perhaps some of these "stupid Android libraries" will never change, and that is fine too. It's not like the old behavior was problematic from a security perspective or severe in some other way. Its behavior was non-optimal but that is hardly a reason for breaking backwards-compatibility.

                    Besides, do you know of any other operating system that does not take the same approach as Linux? From what I know both the BSDs and other proprietary operating systems take a similar stance when it comes to not breaking user space.

                    Comment

                    Working...
                    X