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

Robin Getz
2009-07-10T16:53:00Z

On Thu 9 Jul 2009 12:07, David Howells pondered:
> Note that it would be very easy to add (if such does not already exist)
> an LTP test that creates a file, expands it, maps it, shrinks it and then
> attempts to alter the removed part of the mapping in the expectation
> of receiving a SIGBUS.
>
> As it stands, such a test will work on MMU, but go wrong on NOMMU in a
> different way in these two cases. With the current behaviour, the
> shrink request will be rejected, but the system will survive. With your
> proposed behaviour, the system will potentially be wrecked.
>
> The NOMMU situation behaves differently to the MMU situation in either
> case.

I guess what we were looking at - was the normal case of when userspace
doesn't go wrong.

The kernel (today in noMMU) assumes the userspace is going to do something bad
after it does the shrink - but for those people who are using things
properly - it doesn't allow it to work at all.