Re: [Xenomai-help] RTDM mmap alternative

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Em Quinta 09 Fevereiro 2006 06:53, Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>> One more doubt: how would I munmap that memory? do_munmap and passing
>>> current->mm as the first parameter and the physical address as start? I'm
>>> not
>> Yes, but better save current->mm at mmap time and pass *this* value on
>> unmap. I'm thinking about a way to include this in RTDM.
> 
> Why should I make a backup of mm? Why would it change? Just for curiosity...

Because current may change, at least with the currently lacking
auto-cleanup of RT objects (including devices and sockets) on process
termination. If we then invoke an enforced closure (e.g. via "echo
<fildes> > /proc/xenomai/rtdm/open_fildes"), mm or current has to be known.

> 
>>> sure... Maybe the user can call munmap directly since it doesn't need the
>>> file descriptor. But which address should (s)he pass to start parameter,
>>> the virtual or the physical one?
>> This is also an option. The user would have to pass the virtual address
>> the driver returned.
> 
> I'm curious. How do you know in which circunstances should one pass the 
> virtual or the physical address? I never know which to use...

The user typically only knows the virtual one, at least when looking at
mmap/munmap. Only if there is some specific agreement between driver and
user (see /dev/mem), the physical address behind it may be known as
well. Still, [do_]munmap takes the virtual one.

> 
>> But I think we still need a cleanup on RTDM device closure to avoid
>> access to the mapped physical buffers after that point. I wonder how
>> this is done in standard drivers, will have to look at some of them.
> 
> Sorry, I can't help here, since the user munmap don't pass through the 
> driver... :( I don't know if it is even done by the drivers. The mmap man 
> page states:
> 
> "The  munmap()  system  call deletes the mappings for the specified address 
> range, and causes further references to addresses within the range to 
> generate invalid memory references.  The region is  also automatically 
> unmapped when the process is terminated.  On the other hand, closing the file 
> descriptor does not unmap the region."
> 
> So, the mmap will be undone when the program finishes, I think.

Indeed, this is also what I quickly verified in practice. E.g., if you
do not munmap the region I provided in my test driver, the user-space
tool will still be able to access the physical memory behind it. In that
case, the user kmalloc'ing (or whatever) that region again after a kfree
would access memory that is probably used in a totally different way
meanwhile. Dangerous!

If it is just RAM, you may track the releases (register vma_fops) and
call kfree only when the last user finished. But when it's physical
device memory, you may want to have access earlier. Thus we need
"enforced" munmap on rt_dev_close, maintained by the individual driver.
Therefore, I will introduce also rtdm_munmap() or so.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]