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

[Robin Getz]

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