LWN: Comments on "Revisiting the MAP_SHARED_VALIDATE hack"

POSIX

Wol — Thu, 12 Jul 2018 14:35:46 +0000

Too many, probably :-(

You've only got to set the flags you want in a variable that you forgot to initialise to zero...

And what's the betting that programmers have done that in times gone by. We tend to be rather more careful now, having been bitten once too many.

Cheers,
Wol

Revisiting the MAP_SHARED_VALIDATE hack

Wol — Thu, 12 Jul 2018 14:22:13 +0000

What the documentation needs is a state table. Unfortunately these can be big.

This gives us two things. (a) if it isn't in the state table it isn't guaranteed to work. And (b) if it should be in the state table then it's undefined.

This brings me to one of my big programming bugbears - the state table of "do you want me to ignore these problems". When a programmer add the "do you want me to remember your choice?" they usually, only define three of the four possible states. "ignore error", "ignore error now and in future", and "fail on error". The option "fail on error and remember this choice" very rarely works :-(

Cheers,
Wol

Revisiting the MAP_SHARED_VALIDATE hack

mina86 — Thu, 05 Jul 2018 12:14:05 +0000

That doesn't clarify anything. What does it mean for an API to be stable? In particular, for this topic, is returning an “unsupported operation” error part of the API?

POSIX

josh — Mon, 02 Jul 2018 00:07:32 +0000

What programs, in practice, called mmap with unknown flags and expected them to pass silently?

Revisiting the MAP_SHARED_VALIDATE hack

tao — Sun, 01 Jul 2018 16:38:16 +0000

A much better rule: any export that isn't explicitly documented to be experimental, for internal use, testing purposes, or similar, can be considered to be a stable part of the API (unless serious security concerns necessitates its removal).

While we ideally want all APIs to be well documented, I think it's a fair assumption that it's easier to simply to "document" the non-API than to write proper documentation for the API.

POSIX

corbet — Sun, 01 Jul 2018 14:05:28 +0000

Sigh, it looks like I got caught going with what I thought I knew and not actually checking it, sorry. The behavior of mmap() is defined by decades of actual practice, though.

Revisiting the MAP_SHARED_VALIDATE hack

Jandar — Sun, 01 Jul 2018 11:58:22 +0000

> mmap() is not allowed (by standards like POSIX) to return an error when given unknown flags

I've reread the relevant sections of POSIX and can't find this. Where in http://pubs.opengroup.org/onlinepubs/9699919799/ is mmap() prohibited from returning an error when given unknown flags?

Revisiting the MAP_SHARED_VALIDATE hack

willy — Sun, 01 Jul 2018 05:35:59 +0000

POSIX allows functions to return errors that are not documented. For example, almost any syscall may return ENOMEM (maybe not getppid ;-)

"Implementations may support additional errors not included in this list, may generate errors included in this list under circumstances other than those described here, or may contain extensions or limitations that prevent some errors from occurring." (1003.1-2017 section 2.3 of System Interfaces)

Revisiting the MAP_SHARED_VALIDATE hack

eru — Sat, 30 Jun 2018 17:33:30 +0000

To me this smells like an implementation error made when mmap() was first introduced, which was later codified as official behaviour, because some user code failed to initialize all flag bits...

Revisiting the MAP_SHARED_VALIDATE hack

smurf — Sat, 30 Jun 2018 14:43:56 +0000

" mmap() is not allowed (by standards like POSIX) to return an error when given unknown flags."

So f…ing what? not the first instance where Linux basically ignores POSIX because it makes no sense.

Are there really programs out there that do call mmap() with random flag bits, or is that an overabundance of unnecessary caution?

Revisiting the MAP_SHARED_VALIDATE hack

Paf — Sat, 30 Jun 2018 13:06:40 +0000

That’s sort of the point of Hyrum’s Law:
With enough users, we can’t. Some of the “we” won’t listen or will never get the chance to hear it or will be unable to follow the requirement (which is what the previous poster suggests). And for a big open project we can’t just say “you’re wrong, fix it”, at least, not if you want to keep users.

So if you follow the Linus philosophy of “don’t break real users if at all possible” (and I think that’s almost the only sane way to run a big, open low level (ie many things built atop it) project like the kernel), then you’re extra stuck.

Revisiting the MAP_SHARED_VALIDATE hack

ballombe — Sat, 30 Jun 2018 10:21:33 +0000

Alas, no documentation is complete enough to allow the programmer to relie solely on documented behaviour and not on implicit behaviour.

Revisiting the MAP_SHARED_VALIDATE hack

alison — Sat, 30 Jun 2018 05:21:07 +0000

Perhaps we can simply agree that features of a library or interface that are not mentioned in the official documentation are not guaranteed to appear in future versions?