[bug-libsigsegv] Re: sigsegv on s390 only giving start address of page in segv handler

Eric Blake eblake at redhat.com
Tue Mar 15 20:56:06 UTC 2011


On 03/15/2011 05:04 AM, Christian Borntraeger wrote:
> Am 15.03.2011 10:50, schrieb Bruno Haible:
>> Martin Schwidefsky wrote:
>>> Even with the access-exception-fetch/store-indication facility you'll find
>>> on the latest machine it is not possible to distinguish read from write
>>> faults in all cases ... On older machines the TEID does not carry an
>>> indication if the page translation exception has been for a read or a
>>> write.
>>
>> Oh well then. Thank you for having considered the question.
>>
>> libsigsegv will now offer the page-aligned fault address approximation to
>> userland, together with a C macro that warns the programmer that it is
>> page-aligned.
> 
> Can you give some insights about the other use cases? Userspace page faults can
> be handled just fine with the page address (I have done that for the s390x
> port of valgrind). Would a "works most of the time but might return the page
> address in 10% of the cases" be ok for your other use cases? (e.g. just
> for pretty printing this is certainly ok)

POSIX already documents that for si_addr of a siginfo created for
SIG{ILL,FPE,SEGV,BUS}: "For some implementations, the value of si_addr
may be inaccurate."  So the s390 implementation of returning a
page-aligned fault certainly seems compliant.

For purposes of mapping and permissions, as long as the fault lands in
the right page, you have enough information to resolve the fault.  But
having the extra granularity can let you track faults for multiple
objects that live in one page (temporarily restoring access, do the
instruction, then revert access), whereas page granularity requires one
page boundary per object where you want to rely on faults to detect
boundary overflow, thus chewing through more virtual memory.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20110315/246aec72/attachment.pgp>


More information about the pkg-common-lisp-devel mailing list