Date: Thu, 4 Oct 2001 10:29:13 +0930 From: Greg Lehey <grog@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Anjali Kulkarni <anjali@indranetworks.com>, Peter Pentchev <roam@ringlet.net>, Gersh <gersh@sonn.com>, Bernd Walter <ticso@mail.cicely.de>, freebsd-hackers@FreeBSD.ORG Subject: Re: setjmp/longjmp Message-ID: <20011004102913.C69005@wantadilla.lemis.com> In-Reply-To: <Pine.BSF.4.21.0110031211470.92100-100000@InterJet.elischer.org>; from julian@elischer.org on Wed, Oct 03, 2001 at 12:12:14PM -0700 References: <009801c14bcf$d63e5fd0$0a00a8c0@indranet> <Pine.BSF.4.21.0110031211470.92100-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 3 October 2001 at 12:12:14 -0700, Julian Elischer wrote: > I suppose it must have been Peter Penchev who wrote: >> On Wednesday, October 03, 2001 6:14 AM, Greg Lehey <grog@FreeBSD.org> wrote: >>> On Tuesday, 2 October 2001 at 12:43:54 -0700, Julian Elischer wrote: >>>> On Tue, 2 Oct 2001, Peter Pentchev wrote: >>>>> On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote: >>>>>> [Format recovered--see http://www.lemis.com/email/email-format.html] >>>>>> >>>>>> On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: >>>>>>> On Fri, 28 Sep 2001, Gersh wrote: >>>>>>>> On Fri, 28 Sep 2001, Bernd Walter wrote: >>>>>>>>> On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: >>>>>>>>>> Does anyone know whether it is advisable or not to use >>>>>>>>>> setjmp/longjmp within kernel code? I could not see any >>>>>>>>>> setjmp/longjmp in kernel source code. Is there a good reason for >>>>>>>>>> this or can it be used? >>>>>>>>> >>>>>>>>> You need to look again, it's used in several places in the kernel. >>>>>>>> >>>>>>>> Look at sys/i386/i386/db_interface.c >>>>>>> >>>>>>> Yeah but it would probably be a pretty bad idea to use it without >>>>>>> very careful thought. Especialy with the kernel becoming >>>>>>> pre-emptable in the future.. >>>>>> >>>>>> Can you think of a scenario where it wouldn't work? Preemption >>>>>> doesn't tear stacks apart, right? >>>>> >>>>> How about a case of a longjmp() back from under an acquired lock/mutex? >>>>> Like function A sets up a jump buffer, calls function B, B acquires >>>>> a lock, B calls C, C longjmp()'s back to A; what happens to the lock? >>>>> >>>>> It would work if A were aware of B's lock and the possibility of a code >>>>> path that would end up with it still being held; I presume that this is >>>>> what Julian meant by 'very careful thought'. >>>> >>>> pretty much... >>> >>> That's wrong, of course, but I don't see what this has to do with >>> preemptive kernels. This is the same incorrect usages as performing >>> malloc() and then longjmp()ing over the free(). >> >> Right, that was my question too, doesent seem connected with pre-emptive >> kernels... > > basically it's just that pre-emtion just muddies the waters more.. Or statements which aren't backed up with examples? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011004102913.C69005>