lkml.org 
[lkml]   [2005]   [Oct]   [25]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
Messages in this thread
/
DateTue, 25 Oct 2005 08:55:56 +0100
FromRussell King <>
SubjectRe: [PATCH 2/9] mm: arm ready for split ptlock
On Mon, Oct 24, 2005 at 10:45:04PM -0400, Nicolas Pitre wrote:
> On Sat, 22 Oct 2005, Russell King wrote:
> > Please contact Nicolas Pitre about that - that was my suggestion,
> > but ISTR apparantly the overhead is too high.
> 
> Going through a kernel buffer will simply double the overhead.  Let's 
> suppose it should not be a big enough issue to stop the patch from being 
> merged though (and it looks cleaner that way). However I'd like for the 
> WARN_ON((unsigned long)frame & 7) to remain as both the kernel and user 
> buffers should be 64-bit aligned.

The WARN_ON is pointless because we guarantee that the stack is always
64-bit aligned on signal handler setup and return.

> I don't see how standard COW could not happen.  The only difference with 
> a true write fault as if we used put_user() is that we bypassed the data 
> abort vector and the code to get the FAR value.  Or am I missing 
> something?

pte_write() just says that the page _may_ be writable.  It doesn't say
that the MMU is programmed to allow writes.  If pte_dirty() doesn't
return true, that means that the page is _not_ writable from userspace.
If you write to it from kernel mode (without using put_user) you'll
bypass the MMU read-only protection and may end up writing to a page
owned by two separate processes.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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: 2005-10-25 07:58    [from the cache]
©2003-2008