Messages in this thread | | | From | Mike Frysinger <> | Date | Thu, 9 Jul 2009 11:22:01 -0400 | Subject | Re: truncate on MAP_SHARED files in ramfs filesystems on no-mmu |
| |
On Thu, Jul 9, 2009 at 06:06, David Howells wrote: > Mike Frysinger 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.
you dont need a MMU (virtual memory) to protect against it. you only need a MPU which some systems have.
> 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.
and those too are broken
> 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.
crappy programming is likely to crash regardless of standard functions we attempt to disable in the kernel. this isnt a virtual memory issue at all, it's memory protection.
> Doing it this way also makes things simpler in the kernel and makes the system > more robust.
really ? looks like the kernel is a lot more complicated to me. the fix here would be to delete a whole bunch of code.
> If a process shared mmaps a file and then wants to truncate it, it can always > munmap the excess first.
sure, we could go around changing a whole bunch of things specific to no-mmu, but that's kind of the wrong way to go. applications shouldnt need to know they're running with different MMU features available. -mike -- 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/
| |