Re: copy_from_user/copy_to_user question

[Steven Rostedt <rostedt@goodmis.org>]

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


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