Messages in this thread |  | | | Date | Wed, 26 Aug 1998 14:02:07 +1000 | | From | Richard Gooch <> | | Subject | Re: copy_from_user() fixu |
| |
Chris Wedgwood writes: > On Tue, Aug 25, 1998 at 06:21:11PM +1000, Richard Gooch wrote: > > > Sigh. I should have put a smiley there. > > No. Smilies are only for humor challenged (of fuck, how PC is that?) > and thin skinned people. Don't be a moron - smilies suck. > > > I'm staring at the read(2) man page for Solaris 2.5 and it talks > > about EFAULT. I don't see where it implies that EFAULT is optional. > > Solaris != POSIX
Yes, I know that. But in the context of the science I'm doing, a pure POSIX-only system is not useful. A Unix system, however, is useful. And one of my points is that most (all?) existing Unix systems have EFAULT, and we should avoid diverging from that behaviour.
I have no problem with optional SEGV behaviour. But to abolish EFAULT is a Bad Thing.
> POSIX/Unix98 say that if the pointer is bogus, the behavour is > undefined. Solaris goes further to defined this behaviour as > returning EFAULT.
Solaris and every other Unix I've come across.
> You could write GoochOS and have it defined appropriate behaviour as > execve("rm",{"-rf","/*"}) if you wanted to.
Bugger that! That's not useful to me. Unix is useful, and being compatibile with Unix practice is useful.
> I think hpa argument is because POSIX/whatever don't define EFAULT as > _required_ behaviour, its not correct to write code assuming > otherwise just because some OSs do otherwise.
But since most (all?) Unix systems have EFAULT, is it wise to deviate from that? Espectially considering that EFAULT is actually *useful* and is *used in real life*.
> > You haven't responded to this part. Wrapping *every* call to > > read(2) with a signal/setjmp save/restore is a performance killer. > > Can you actually be serious that an application/library that tries > > to trap bad addresses has to put up with this? > > wrapping libc sucks badly. I did this trying to work out how often > read/write were called and and how often the buffes were page > aligned, and it noticably slowed down some applications... (results > were logged, so each syscall became several).
Agreed! Having to save/restore signal handlers for SEGV will kill performance. Been there, done that.
Regards,
Richard.... - 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.altern.org/andrebalsa/doc/lkml-faq.html
|  |