> buf = malloc(8192+4095) & -4095; /* two pages */
>
> mprotect(&buf[4096],4096,PROT_NONE); /* second page no good */
>
> read(fd,buf,8192);
>
>
> under 2.0.x, this will ALWAYS fail.
>
> under 2.1.x - this will never fail, it reads either the entire file
> if its less than 4k or the first 4k - advancing the file pointer.
this makes no difference to the memory management application i outlined.
2.0 and 2.1 simply has a different granularity of detecting memory faults,
but we have no information anyway where the fault occured, user-space has
to find out if it wants to deal with this. But returning no -EFAULT on a
fault makes it impossible (well, hard) for user-space to detect this.
User-space also has to deal with side-effects of failed syscalls. Tough.
> > ? we have not changed any semantics.
>
> see above. (the details might not be exact, I have code to show this
> though, I'll dig it up if you want)
(ok, i though you refered to the -EFAULT behavior on completely bad
pointers)
-- 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/