On 12/10/2012 08:10 AM, Dmitry Antipov wrote:
On 12/08/2012 04:32 AM, John Stultz wrote:
This looks right to me. Seems like that ashmem.h is just really old. You should submit this to AOSP.
One suggestion: For your own test case, you might want to copy in the kernel's (or bionic's) ashmem.h into the test, rather then including the frameworks/native..../ashmem.h header, as this will allow the test case to build with both standard GNU as well as Android environments.
Thanks, I'll do #ifdef ANDROID for that.
BTW, why it's possible to mmap() more than ASHMEM_SET_SIZE? Basically it is:
open("/dev/ashmem", O_RDWR) = 3 ioctl(3, 0x40047703, 0x4000) = 0 // ASHMEM_SET_SIZE for 4 pages - OK mmap2(NULL, 20480, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xb6eff000 // next mmap() 5 pages - OK???
So looking at the code, the mmap handler doesn't look at the size of the vma passed to it. But It will generate the specified _SET_SIZE sized shmem file as the file backing for the vma.
So I think if you were to access the 5th page there I suspect you'd get a SIGBUS.
And if I recall, this mirrors what happens if you mmap() 5 pages of a normal file that is really 4 pages (as the file may be extended later while mmapped via a write or ftruncate).
So I suspect this behavior is expected.
thanks -john