contigmalloc() and mmap()
apachexm at hotmail.com
Thu Jun 16 05:43:59 GMT 2005
>I'm unsure about this usage of the timer (callout(?) )
>how does the timer know which buffer pages to remove?
>and if each userspace process does an ioctl to allocate a different buffer,
>the new pages also visible to other processes?
Use mmap() we can ensure different process access different buffer in user
>in FreeBSD your driver can register with at_exit() in 4.x
>and with eventhandler_register() in 5.x or 6.x to have stuff done
>when the process exits.
Yes, I use this macro and register my handler.
>(there are also at_fork and at_exec handlers too.)
>see man at_exit (etc.) in 4.x
>and man 9 EVENTHANDLER in 5.x and 6.x
>You could also make a hash table on the PID so that you keep different
>available for different processes and look them up
>using curproc->p_pid (for 4.x) and curthhread->td_proc->p_pid for 5.x and
>to look up the
>Using these primatives you should be able to simulate what you need I
>>In FreeBSD, the driver works in the same pattern, but when a user process
>>mmap driver's buffer (allocated by contigmalloc()) and is killed, then
>>another process mmap the same buffer again, sometimes it cannot get
>>data from the mmaped pages, which means the user space virtual aderess may
>>not point to the correct physical page of driver's buffer, sometimes the
>>even panic with some information such as "Trap 12, Page not present" etc.
>sounds like you are getting the buffers confused..
>are you doing correc treference counting on the buffers?
In Linux, before kernel memory is mmap to user space, memory pages must be
set a reserved flag, no corresponding operations in FreeBSD, is it right?
>>And recently, I modified my driver, I allocated a big chunk of contiguous
>>physical memory using contigmalloc() in the driver's _attach() function,
>>and I use a simple first-fit algorithm to manage this memory myself, which
>>mean in ioctl() I use my allocate/deallocate functions instead of
>>in _detach() function contigfree() is called to free the big chunk of
>>no panic again, but sometimes, process cannot get the correct data from
>>the mmaped memory. I don't know why.
>it does sound a bit like you are not keeping the information
>separated between processes enough.
I find a bug in my test program, because the big chunk memory in my driver
is reused by new process, but it don't zero it before using it, so some data
last process set interfere the new process.
FREE pop-up blocking with the new MSN Toolbar - get it now!
More information about the freebsd-hackers