Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
	Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
	Kingdom.
	Registered in England and Wales under Company Registration No. 3798903
From: David Howells <dhowells@redhat.com>
In-Reply-To: <8bd0f97a0907090104h5d4984dfkbeb82616a01128c8@mail.gmail.com>
References: <8bd0f97a0907090104h5d4984dfkbeb82616a01128c8@mail.gmail.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: dhowells@redhat.com,
       Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: truncate on MAP_SHARED files in ramfs filesystems on no-mmu
Date: Thu, 09 Jul 2009 11:06:58 +0100
Message-ID: <24005.1247134018@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1703
Lines: 44

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/