Date: Mon, 23 Oct 2006 12:17:50 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Kris Kennaway <kris@obsecurity.org> Cc: Jeremy Messenger <mezz7@cox.net>, freebsd-stable@freebsd.org Subject: Re: Do anyone has any problem with sem_open() crash? Message-ID: <20061023121528.L60062@fledge.watson.org> In-Reply-To: <20061023020119.GA30219@xor.obsecurity.org> References: <op.thun54ec9aq2h7@mezz.mezzweb.com> <1161567368.30822.31.camel@shumai.marcuscom.com> <op.thupyub59aq2h7@mezz.mezzweb.com> <20061023020119.GA30219@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Oct 2006, Kris Kennaway wrote: > On Sun, Oct 22, 2006 at 08:48:20PM -0500, Jeremy Messenger wrote: > >> I guess I am safe then as I can ignore these cores.. Thanks! Isn't kernel >> supposed to be avoid the crash? I don't see any of crash before I upgraded >> to last night of RELENG_6. > > It's not a crash, it's a configure script testing whether the syscall > exists, and the the test program gets the signal 12 to tell it that it > doesn't. This is expected behaviour. We have several levels of "But that's not implemented". The level used for system calls that are simply not defined is SIGSYS+ENOSYS. By default, application calling these (undefined) system calls can catch the error if they choose to, but will exit otherwise. The next level is to provide ENOSYS stubs that return ENOSYS without generating SIGSYS; in some situations, this is preferred. For example, we use this when AUDIT isn't compiled into the kernel but login(1) calls an audit system call to see if audit is present. Finally, there are a number of situations where a system call is implemented, but the underlying object doesn't support the operation, in which case we often return EOPNOTSUPP or variations on that them. The SIGSYS+ENOSYS error code isn't a bug, but it seems likely that configure would be a lot happier if we returned ENOSYS without SIGSYS. Right now, that means hand-defining a stub that's conditionally compiled based on the feature not being present. It might be nicer if we had a way to indicate that in the system call table. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061023121528.L60062>