[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxs7Cc30fCiENw0R+XDJhUJ-w=z=NLLzYfT5gF2Qh-60Q@mail.gmail.com>
Date: Wed, 27 Jun 2018 19:37:01 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Eric Sandeen <sandeen@...deen.net>
Cc: Eric Sandeen <sandeen@...hat.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>,
Linux API <linux-api@...r.kernel.org>,
linux-xfs <linux-xfs@...r.kernel.org>,
linux-ext4@...r.kernel.org,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
Dan Williams <dan.j.williams@...el.com>,
Jan Kara <jack@...e.cz>, Christoph Hellwig <hch@...radead.org>,
zhibli@...hat.com
Subject: Re: [PATCH] mm: reject MAP_SHARED_VALIDATE without new flags
On Wed, Jun 27, 2018 at 7:17 PM Eric Sandeen <sandeen@...deen.net> 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
Powered by blists - more mailing lists