Re: copy_from_user/copy_to_user question

Steven Rostedt
2005-12-03T03:23:50Z

Don't strip CC's

On Fri, 2005-12-02 at 20:47 -0600, Robert Hancock wrote:
> Vinay Venkataraghavan wrote:
> > But this is not always the case right. The point that
> > you mention above is specifically why I posted this
> > question. It could well be the case that the user
> > space page could be swapped out when the user space
> > process is blocked. So when the ioctl is serviced in
> > kernel space, there is no guarantee that the page is
> > still mapped. This could cause a page fault.
> > I think this is why we need to do a
> > copy_to_user/copy_from_user.
>
> I don't think this is actually the case. I'm not entirely sure, but I
> believe that if memcpy from user space works at all on a platform, then
> if the page is swapped out it will still get swapped in when needed. In
> any case, this is not the main reason for using these functions. The
> main reason is that memory addresses passed from userspace might not be
> valid at all, and reading these addresses directly would cause a kernel
> oops in that case. These functions set up an exception handler so that
> invalid address reads/writes return failure instead of crashing the system.

Nope, the kernel is always locked into memory. If you take a page fault
from the kernel world, you will crash and burn. The kernel is never
"swapped out". So if you are in kernel mode, going into do_page_fault
in arch/i386/mm/fault.c there is no path to swap a page in. Even the
vmalloc_fault only handles a page not in the page global descriptor of
the current task. But if this page is not mapped somewhere in memory
(not swapped out), you will get a kernel oops.

Kernel memory may never be swapped out. What happens if an interrupt
tries to use such memory. How does it handle sleeping?

Just change copy_to_user into memcopy, and see how long your system
stays up and running. Do it on a machine that you don't need to worry
about rogue applications. It won't last very long.

-- Steve