Re: The disappearing sys_call_table export.

Christoph Hellwig (hch@infradead.org)
Mon, 5 May 2003 13:52:11 +0100


On Mon, May 05, 2003 at 01:23:19PM +0200, Terje Eggestad wrote:
> The problem occur when you
> 1. pinn a buffer
> 2. sbrk(-n) or munmap() (usually thru free()) the area the buffer
> 3. a new malloc() resulting in a sbrk(+n) or mmap()
> 4. then my new buffer has the exactly same virtual address as the prev.
>
> (belive it or not this happens, and relatively frequently).

That only shows that you really don't want to use glibc's malloc and
sbrk implementations, but ones that are implemented as mmap in your
driver so you can keep track of it properly. LD_PRELOAD is your friend.

> Lets deal, I'll GPL the trace module if you get me a
> EXPORT_SYMBOL_GPL(sys_call_table);

Who cares about your trace module? That's the wrong approach to start
with. And the removal of the sys_call_table export is not a political
issue but a technical one. The interesting thing would be your memory
manager, but given the above hints you really should be able to fix it yourself
now..

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