Date: Mon, 03 Dec 2007 10:16:56 +0800 From: David Xu <davidxu@FreeBSD.org> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-current@FreeBSD.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, Carl Shapiro <carl.shapiro@gmail.com> Subject: Re: Serious compatibility breakage in -current. Message-ID: <47536718.1020107@freebsd.org> In-Reply-To: <20071130162409.C8D3D5B59@mail.bitblocks.com> References: <20071130162409.C8D3D5B59@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47536718.1020107>