Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
I also got the impression that libunwind was mostly for crash debugging, at which point performance is not exactly priority number 1...
msync() and subtle behavioral tweaks
Posted Jun 21, 2012 19:31 UTC (Thu) by nix (subscriber, #2304)
Posted Jun 21, 2012 19:41 UTC (Thu) by Yorick (subscriber, #19241)
Another interesting use of libunwind is for profiling, for which performance is attractive. (Yes, there are alternatives, but libunwind is fairly portable.)
Posted Jun 21, 2012 21:15 UTC (Thu) by cmccabe (guest, #60281)
I'm really curious why you think this. It seems totally bogus to me: the kernel is the one doing the address space checking, not userspace. You would need to add extra code to get the weird and (I think) non-POSIX behavior of delivering a signal to userspace. What gave you the idea that a signal might be delivered?
Posted Jun 21, 2012 22:03 UTC (Thu) by Yorick (subscriber, #19241)
You would then rightly ask why msync() would be exempt from such a behaviour, and to that I have no good answer. I have seen that syscall being used for this purpose (address checking) in a variety of places, however, misguided or not.
Posted Jun 22, 2012 3:40 UTC (Fri) by cmccabe (guest, #60281)
I would guess that the people using msync to check whether an address is valid are using it more because it doesn't require you to have any open file descriptors, than because they're being "careful." In fact, it's not even clear according to the man page that you can use msync on memory that wasn't allocated with mmap. I really have no idea what msync is "supposed" to do on memory allocated with brk, for example. So it's just another case of people relying on some pretty hairy implementation details.
As far as I can see, your best bet for checking address validity probably is "mincore." It definitely doesn't make any sense for a shim library to intercept that function.
Posted Jun 22, 2012 8:40 UTC (Fri) by nix (subscriber, #2304)
EFAULT vs SIGSEGV on write()
Posted Jun 22, 2012 17:59 UTC (Fri) by giraffedata (subscriber, #1954)
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.
Posted Jun 22, 2012 23:48 UTC (Fri) by nix (subscriber, #2304)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds