| |||||||||||||
msync() and subtle behavioral tweaksmsync() and subtle behavioral tweaksPosted Jun 22, 2012 8:40 UTC (Fri) by nix (subscriber, #2304)In reply to: msync() and subtle behavioral tweaks by cmccabe Parent article: msync() and subtle behavioral tweaks
Anyone intercepting relatively-bare syscalls and converting them into library functions like that had better trap SIGSEGV during the call and convert it into an -EFAULT return. It's not like that's terribly hard (though it does require flipping signal dispositions twice, that's fast as syscalls go).
(Log in to post comments)
EFAULT vs SIGSEGV on write() Posted Jun 22, 2012 17:59 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Anyone intercepting relatively-bare syscalls and converting them into library functions like that had better trap SIGSEGV during the call and convert it into an -EFAULT return. But do the standards or conventional architecture really call for that? I don't think the POSIX definition of write() uses the word "kernel" and I believe the general understanding for any library is that if you pass an invalid address to a subroutine, it might generate a SIGSEGV. Or are you just making a practicality argument, since people might be depending on EFAULT. I think it would be a pretty unusual program that passes invalid addresses to write() when the program isn't broken.
EFAULT vs SIGSEGV on write() Posted Jun 22, 2012 23:48 UTC (Fri) by nix (subscriber, #2304) [Link]
It's practicality. If you're trying to transparently, replace a function that normally EFAULTs on events that would cause userspace to SIGSEGV, it behooves you to behave the same way, lest you break some weird program that really depends on this. (I wrote one once. It does happen.)
|
|||||||||||||