Re: truncate on MAP_SHARED files in ramfs filesystems on no-mmu

[David Howells <dhowells@redhat.com>]

Mike Frysinger <vapier.adi@gmail.com> wrote:

> reviewing LTP tests shows mmap09 failing.  this test creates a file of
> a certain length, opens it and creates a shared mapping, and then
> tries various truncate tests:
> truncate to a smaller size
> truncate to a larger size
> truncate to size 0
> 
> the first and last fail on no-mmu due to
> file-nommu.c:ramfs_nommu_resize() rejecting attempts to shrink on a
> shared mapping:

Yes.  That's exactly right.

> my question is why?  if an application maps a fd with MAP_SHARED,
> truncates it, and then it or someone else who has that fd mapped tries
> to access the now-invalid tail end, that is a bug in the application.
> i dont see why we should be protecting users here from their own buggy
> code ?

This is protecting the kernel as much as the user.  There's no MMU to enforce
denial of access on the pages that truncate returns to the system.

This doesn't only protect the process with a mapping on that file against its
own truncate, but also other processes that have made mappings against that
file.

Whilst you can argue it either way, you need a better reason to change this
than it causes some LTP failures.  You cannot expect all the MM-related LTP
tests to work against a NOMMU system.

Doing it this way also makes things simpler in the kernel and makes the system
more robust.

If a process shared mmaps a file and then wants to truncate it, it can always
munmap the excess first.

David