Re: Serious compatibility breakage in -current.

From: David Xu <davidxu_at_FreeBSD.org>
Date: Mon, 03 Dec 2007 10:16:56 +0800
Bakul Shah wrote:
>>>The switch from SIGBUS to SIGSEGV is well motivated.
>>
>>Is it?  I see no mention of it in the commit log for the revision that
>>actually implemented the change.  David argued on -CURRENT that it is
>>more POSIXly correct, provided that he interpreted POSIX correctly; how
>>do other operating systems behave in this case?
> 
> 
> There are two issues: the right thing to do for POSIX and
> compatibility with older versions.
> 
> See the memory protection section in
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_08.html
> 
> Excerpt:
> * Write attempts to memory that was mapped without write access, or any
>   access to memory mapped PROT_NONE, shall result in a SIGSEGV signal.
> 
> * References to unmapped addresses shall result in a SIGSEGV signal.
> 
> * Reference to whole pages within the mapping, but beyond the current
>   length of the object, shall result in a SIGBUS signal.
> 
> FreeBSD's behavior until 7.0 was opposite of this!  It has
> followed what has been done at least since 4.3BSD (1986?)
> which gave SIGBUS on a protection violation and SIGSEG for
> access outside any mapped area.
> 
> Solaris mmap man page is not clear on this -- it says you can
> get SIGSEGV or SIGBUS but doesn't indicate which under what
> condition.
> 
> The change made for 7.0 doesn't quite do the right thing
> either as it doesn't distinguish between unmapped area and
> wrong kind of access -- you get SIGSEGV for both.
> 
> So you are breaking compatibility for no good reason.
> 
> Kris Kennaway argus
> 
>>it is far too late in the release cycle to identify and revert the ports 
>>that already caught up to expecting SIGSEGV, so we'd be breaking a 
>>different set of applications instead).
> 
> 
> This is a mess but IMHO the two kinds of breakages are not
> equal.  For better standards compliance another kernel change
> will have to be made in the future in any case.
> 
> FWIW.

Er, there was a talk about the the return code from VM API, but I can
not find it now, nobody answered my question that the reason why the 
code is returned from the VM API. I did read POSIX specification
carefully before making this change, but I may still missed something.

Regards,
David Xu
Received on Mon Dec 03 2007 - 01:16:00 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:23 UTC