On Jun 17, 2014 3:01 AM, "David Herrmann" <dh.herrmann@gmail.com> wrote:
>
> Hi
>
> On Tue, Jun 17, 2014 at 11:54 AM, Florian Weimer <fweimer@redhat.com>
wrote:
> > On 06/13/2014 05:33 PM, David Herrmann wrote:
> >>
> >> On Fri, Jun 13, 2014 at 5:17 PM, Andy Lutomirski <luto@amacapital.net>
> >> wrote:
> >>>
> >>> 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.
> > 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