lkml.org 
[lkml]   [2006]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
Subjectcopy_from_user / copy_to_user with no swap space
From
I've been trying to find or derive a definitive answer to this question  
for a while now but can't quite get over the hump.

I understand when/why copy_<to|from>_user (and siblings) are required
(address validation, guaranteeing a process is paged in, etc...). The
question is: if you have no swap space (or virtual memory or whatever),
can there ever be a case in which any valid pointer to a buffer in
user-space would be incorrect as a result of another process's PTE being
present? Put another way: can a process be partially paged?

My reasoning (which I obviously have no confidence else I wouldn't be
asking this question) is as follows:

All processes share the same logical address space starting at 0 and
(usually) ending at 3GB, right? Text sections start low and build up,
stacks start high and grow down. Somewhere in there you get your heap and
shared memory regions. Since noting about a logical address can identify
a specific process, then copy_to/from_user can do nothing to guaruntee
that the CORRECT process is paged in. True? So you're absolutely
obligated to DO the copy at the time the kernel is executing on behalf of
that process. Once your process/thread is context swapped, you've lost
the [correct] information on the address mapping.

So, IF you MUST copy_from/to_user when in the context of the process, AND
IF you have no virtual memory/swapping, THEN must it not be true that you
can ALWAYS dereferences your user space pointers?


TIA!


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

\
 
 \ /
  Last update: 2006-10-16 21:21    [W:0.118 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site