All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Rosenfeld Rosas <lbocseg@domain.hid>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] RTDM mmap alternative
Date: Thu, 9 Feb 2006 15:58:45 -0200	[thread overview]
Message-ID: <200602091558.46201.lbocseg@domain.hid> (raw)
In-Reply-To: <43EB737A.3010704@domain.hid>

Em Quinta 09 Fevereiro 2006 14:53, Jan Kiszka escreveu:

> ...
>>> 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.

Even if the application was closed and then rerun using a stored address? It 
would not conform to documentations in this case... I think you're talking 
about just closing the file descriptor with rtdm_dev_close, right?

>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!

But, anyway it would be a user error. Not a driver issue... But I agree that 
it would be great to undone the mapping on closing the file descriptor, 
although it would not be compatible with normal mmap behaviour.

>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.

It would be nice to be able to call rtdm_munmap. :)

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 




      reply	other threads:[~2006-02-09 17:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-03 19:27 [Xenomai-help] RTDM mmap alternative Rodrigo Rosenfeld Rosas
2006-02-04  9:07 ` Jan Kiszka
2006-02-04 12:44   ` Rodrigo Rosenfeld Rosas
2006-02-04 12:41     ` Jan Kiszka
2006-02-04 14:19       ` Rodrigo Rosenfeld Rosas
2006-02-06 21:00       ` Rodrigo Rosenfeld Rosas
2006-02-07 17:38         ` Jan Kiszka
2006-02-07 19:22           ` Rodrigo Rosenfeld Rosas
2006-02-07 20:03             ` Jan Kiszka
2006-02-08  2:15               ` Rodrigo Rosenfeld Rosas
2006-02-08 12:43           ` Rodrigo Rosenfeld Rosas
2006-02-08 13:14             ` Jan Kiszka
2006-02-08 18:03               ` Rodrigo Rosenfeld Rosas
2006-02-08 18:26                 ` Jan Kiszka
2006-02-08 19:35                   ` Rodrigo Rosenfeld Rosas
2006-02-08 19:07                 ` Rodrigo Rosenfeld Rosas
2006-02-08 21:28           ` Rodrigo Rosenfeld Rosas
2006-02-09  8:53             ` Jan Kiszka
2006-02-09 16:04               ` Rodrigo Rosenfeld Rosas
2006-02-09 16:53                 ` Jan Kiszka
2006-02-09 17:58                   ` Rodrigo Rosenfeld Rosas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200602091558.46201.lbocseg@domain.hid \
    --to=lbocseg@domain.hid \
    --cc=jan.kiszka@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.