public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anders Torger <torger@ludd.luth.se>
To: linux-kernel@vger.kernel.org
Subject: How to transfer memory from PCI memory directly to user space safely and portable?
Date: Sun, 26 Nov 2000 14:21:31 +0100	[thread overview]
Message-ID: <00112614213105.05228@paganini> (raw)


I'm writing a sound card driver where I need to transfer memory from the card 
to user space using the CPU. Ideally I'd like to do that without needing to 
have an intermediate buffer in kernel memory. I have implemented the copy 
functions like this:

>From user space to the sound card:

	if (verify_area(VERIFY_READ, user_space_src, count) != 0) {
	    return -EFAULT;
	}
	memcpy_toio(iobase, user_space_src, count);
	return 0;

>From the sound card to user space:

	if (verify_area(VERIFY_WRITE, user_space_dst, count) != 0) {
	    return -EFAULT;
	}
	memcpy_fromio(user_space_dst, iobase, count);
	return 0;


These functions are called on the behalf of the user, so the current process 
should be the correct one. The iobase is ioremapped: 

	iobase = ioremap(sound_card_port, sound_card_io_size);

Now, this code works, I have a working driver. However, some questions have 
been raised about the code, namely the following:

1. What happens if the user space memory is swapped to disk? Will 
verify_area() make sure that the memory is in physical RAM when it returns, 
or will it return -EFAULT, or will something even worse happen?

2. Is this code really portable? I currently have an I386 architecture, and I 
could use copy_to/from_user on that instead, but that is not portable. Now, 
by using memcpy_to/fromio instead, is this code fully portable?

3. Will the current process always be the correct one? The copy functions is 
directly initiated by the user, and not through an interrupt, so I think the 
user space mapping will always be to the correct process. Is that correct?

Since I'm not on the list, I'd like to have answers CC'd to my address. Thank 
you.

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

             reply	other threads:[~2000-11-26 13:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-26 13:21 Anders Torger [this message]
2000-11-26 15:11 ` How to transfer memory from PCI memory directly to user space safely and portable? Philipp Rumpf
2000-11-26 15:36   ` Anders Torger
2000-11-27 18:36   ` H. Peter Anvin
2000-11-27 19:29     ` Philipp Rumpf
2000-11-27 19:30       ` H. Peter Anvin
2000-11-27 13:51 ` Richard B. Johnson
  -- strict thread matches above, loose matches on Subject: below --
2000-11-27 13:27 aprasad
2000-11-26 13:54 ` Anders Torger

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=00112614213105.05228@paganini \
    --to=torger@ludd.luth.se \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox