On Wed, Jun 27, 2018 at 7:17 PM Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > > What broke is that mmap(MAP_SHARED|MAP_PRIVATE) now succeeds without error, > whereas before it rightly returned -EINVAL. You're still confusing *behavior* with breakage. Yes. New *behavior* is that MAP_SHARED|MAP_PRIVATE is now a valid thing. It means "MAP_SHARED_VALIDATE". Behavior changed. That's normal. Every single time we add a system call, behavior changes: a system call that used to return -ENOSYS now returns something else. That's not breakage, that's just intentional new behavior. > What behavior should a user expect from a successful mmap(MAP_SHARED|MAP_PRIVATE)? MAP_SHARED|MAP_PRIVATE makes no sense and nobody uses it (because it has always returned an error and never done anything interesting). Nobody uses it, and it used to return an error is *exactly* why it was defined to be MAP_SHARED_VALIDATE. So you should expect MAP_SHARED_VALIDATE behavior - which is MAP_SHARED together with "validate that all the flags are things that we support". Actual BREAKAGE is if some application or user workflow no longer works. Did LibreOffice stop working? That is breakage. And by application, I mean exactly that: a real program. Not some manual-page, and not some test-program that people don't actually rely on, and that just reports on some particular behavior. Because I can write a test program that verifies that system call #335 doesn't exist: #define _GNU_SOURCE #include <unistd.h> #include <sys/syscall.h> #include <errno.h> #include <assert.h> int main(int argc, char **argv) { assert(syscall(335, 0) == -1 && errno == ENOSYS); return 0; } and the next system call we add will break that test program on x86-64. And that's still not a "regression" - it's just a change in behavior. But if firefox no longer runs, because it depended on that system call not existing (or it depended on that MAP_SHARED_VALIDATE returning EINVAL) then it's a regression. See the difference? One case is "we added new behavior". The other case is "we have a regression". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html