On Mon, Oct 22, 2012 at 05:53:45PM +0200, Michael Kerrisk (man-pages) wrote: > I'm not sure whether anything is using the high 8 bits of prot, bun > passing I note that there seems to be no check that the unused bits > are zeroed so there's a small chance existing apps are passing random > garbage there. (Of course, mmap() is hardly the only API to have that > fault, and it hasn't stopped us from reusing bits in those APIs, > though sometimes we've gotten bitten by apps that did pass in random > garbage). Ok. > > >> But there seems an obvious solution here: given your value in those > >> bits (call it 'n'), the why not apply a multiplier. I mean, certainly > >> you never want a value <= 12 for n, and I suspect that the reasonable > >> minimum could be much larger (e.g., 2^16). Call that minimum M. Then > >> you could interpret the value in your bits as meaning a page size of > >> > >> (2^n) * M > > > > I considered that, but it would seem ugly and does not add that > > many bits. > > > >> > >> > So this will use up all remaining flag bits now. > >> > >> On the other hand, that seems really bad. It looks like that kills the > >> ability to further extend the mmap() API with new flags in the future. > >> It doesn't sound like we should be doing that. > > > > You can always add flags to PROT or add a mmap3(). Has been done before. > > Or just don't do any new MAP_SECURITY_HOLEs > > There seems to be a reasonable argument here for an mmap3() with a > 64-bit flags argument... It's just a pain to deploy. I think I would rather do the offset then. That could still handle PowerPC 14 + 31 = 44 = 16GB (minimum size 16K) -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>