On Jun 17, 2014 3:01 AM, "David Herrmann" [off-list ref] wrote:

Hi

On Tue, Jun 17, 2014 at 11:54 AM, Florian Weimer [off-list ref]

wrote:

quoted

On 06/13/2014 05:33 PM, David Herrmann wrote:

quoted

On Fri, Jun 13, 2014 at 5:17 PM, Andy Lutomirski [off-list ref]
wrote:

quoted

Isn't the point of SEAL_SHRINK to allow servers to mmap and read
safely without worrying about SIGBUS?

No, I don't think so.
The point of SEAL_SHRINK is to prevent a file from shrinking. SIGBUS
is an effect, not a cause. It's only a coincidence that "OOM during
reads" and "reading beyond file-boundaries" has the same effect:
SIGBUS.
We only protect against reading beyond file-boundaries due to
shrinking. Therefore, OOM-SIGBUS is unrelated to SEAL_SHRINK.

Anyone dealing with mmap() _has_ to use mlock() to protect against
OOM-SIGBUS. Making SEAL_SHRINK protect against OOM-SIGBUS would be
redundant, because you can achieve the same with SEAL_SHRINK+mlock().

I don't think this is what potential users expect because mlock requires
capabilities which are not available to them.

A couple of weeks ago, sealing was to be applied to anonymous shared

memory.

quoted

Has this changed?  Why should *reading* it trigger OOM?

The file might have holes, therefore, you'd have to allocate backing
pages. This might hit a soft-limit and fail. To avoid this, use
fallocate() to allocate pages prior to mmap() or mlock() to make the
kernel lock them in memory.

Can you summarize why holes can't be reliably backed by the zero page?

(I realize the kernel could OOM on PTE allocation, but fallocate won't fix
that. OTOH MAP_POPULATE should work.)

And I don't think I like hole filling being allowed on write-sealed files.
Holes are observable these days with SEEK_HOLE and such.

Alternatively, we could add a new syscall or madvise option to populate a
mapping.

--Andy