> but whether the kernel returns EFAULT or not, might depend upon your
> kernel version, which is the point I was making about not making too
> many assumptions about the validity of passing possilby bogus
> pointers and then checking for EFAULT.
again, 'bogus' to the kernel, but not necessarily to user-space. The
inconsistency between 2.0 and 2.1 is sad but inevitable. Actually, 2.1 is
more consistent in faulting only when it has come so far to access that
piece of memory.
> In general, passing bogus pointers isn't something most applications
> should do.
no, it's _not_ a bogus pointer, it's an invalid pointer. Wether it's
'bogus' should be decided in user-space.
> > 2.0 and 2.1 simply has a different granularity of detecting memory
> > faults, but we have no information anyway where the fault occured,
>
> in 2.1.x - we know, in the case of the example I quoted, that if the
> file is over a certain size, where it occured, because the read will
> be short.
system calls have only a single, integer return value. So if it returns
-EFAULT, then it cannot be short. Yes you can query the file position.
(this is what i ment by hard, because there are atomicity issues with
multithreaded apps) it's a messy area :(
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/