lkml.org 
[lkml]   [2004]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.8.1-mm4
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Llu, 2004-08-23 at 19:21, Tomasz Torcz wrote:
> > >- This kernel has an x86 patch which alters the copy_*_user() functions so
> > > they will return -EFAULT on a fault rather than the number of bytes which
> > > remain to be copied. This is a bit of an experiment, because this seems to
> > > be the preferred API for those functions. It's a see-what-breaks thing.
> > >
> >
> > Things appear to broke. Sometimes kernel starts to spit page allocation
> > failures into log for few minutes, despite memory beeing available:
>
> The kernel relies on copy_from_user returning the number of bytes copied
> so no suprise there.

Noooo. copy_*_user() returns zero on success and "number of bytes
remaining to be copied" on fault. The number of places in the kernel which
actually care about the precision of the "number remaining to be copied"
thing is very small. Most places just test for non-zeroness.

The problem is that the current semantics are hard to implement on several
architectures. To get it right, sparc64 has to go back and copy one byte
at a time just to work out the address at which the fault really occurred.

-
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-03-22 14:05    [W:0.073 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site