On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote: > On Wed, 26 Jan 2005, Rik van Riel wrote: > >With some programs the 2.6 kernel can end up allocating memory > >at address zero, for a non-MAP_FIXED mmap call! This causes > >problems with some programs and is generally rude to do. This > >simple patch fixes the problem in my tests. > > Does this mean that we can't mmap the screen regen buffer at > 0x000b8000 anymore?
That would be a MAP_FIXED call, so not affected by this change. > How do I look at the real-mode interrupt table starting at > offset 0? You know that the return value of mmap is to be > checked for MAP_FAILED, not for NULL, don't you? All MAP_FIXED, too. > What 'C' standard do you refer to? Seg-faults on null pointers > have nothing to do with the 'C' standard and everything to > do with the platform. Obviously having malloc() return NULL for a successful allocation would be a bad thing, no? That's precisely what could happen if an anonymous allocation got mapped at 0x0. > >+#define SHLIB_BASE 0x00111000 Any particular thoughts as to how large a window should be reserved? SHLIB_BASE is a bit more than 1MB, which is fairly small in the grand scheme of things, but I guess I don't see why you'd reserve more than PAGE_SIZE (or maybe PAGE_SIZE*2, though I can't actually articulate why that seems like a good idea). FWIW, mmap(2) also will return NULL if length==0. That sure did confuse me the first time I noticed. -andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
