Re: kernel trap 9 with interrupts disabled
On Thu, Apr 25, 2002 at 03:31:21PM -0700, JJ Behrens wrote: > Dear Sir, > > > The classic priority inversion problem occurs when you have a low > > priority process blocked on I/O and a higher priority process > > monopolizing the cpu. Even though the lower priority process is > > woken up by the kernel, it doesn't get cpu until there are no > > runnable higher priority processes and so it is unable to release > > any locks it might have been holding for the I/O. > > I beg to differ. As I know it, the priority inversion problem occurs when a > lower priority process owns a resource that a higher priority process > blocks on. The lower priority process cannot run because it has a lower > priority, and the higher priority process cannot run because it is blocked on a > resource--thus deadlock. Reading below, I think you understand this, but got > mixed up in the details. Almost, but not quite. In your scenario the low-priority task would get to run since the high-priority task is blocked and would thus eventually release the resource. No deadlock, no problem. The classic priority inversion that I have heard about is the following scenario: Three processes of low, medium and high priority respectively. The low-priority task locks some resource. Before this resource is released both the medium-priority and the high-proiority task starts to run. Since these have higher priority the low-priority task doesn't get any CPU. The medium-priority task is CPU-intensive and uses all CPU-time it gets (but it won't get any while the HP-task is running.) Eventually the high-priority task tries to lock the resource that the low-priority task is holding. The high-priority task is then blocked and the medium-priority task gets to run. Now the high-priority task is blocked waiting for the resource that the low-priority task is holding. The LP-task does not get to run since the MP-task has higher priority and thus can't release the resource. This means that the priority between the HP task and the MP task has in effect been inverted, since the medium priority task blocks the high-priority task from running even if there is no resource that both of them are trying to lock. The problem is that when the high-priority task got blocked trying to acquire the resource that the low-priority task held it effectively inherited the priority of the low-priority task and can therefore be preempted by the medium-priority task. To get a priority inversion like this one needs at least three tasks with different priorities. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kernel trap 9 with interrupts disabled
> Almost, but not quite. In your scenario the low-priority task would > get to run since the high-priority task is blocked and would thus > eventually release the resource. No deadlock, no problem. > > The classic priority inversion that I have heard about is the following > scenario: > > Three processes of low, medium and high priority respectively. > The low-priority task locks some resource. Before this resource is > released both the medium-priority and the high-proiority task starts to > run. Since these have higher priority the low-priority task doesn't get > any CPU. The medium-priority task is CPU-intensive and uses all > CPU-time it gets (but it won't get any while the HP-task is running.) > Eventually the high-priority task tries to lock the resource that the > low-priority task is holding. The high-priority task is then blocked > and the medium-priority task gets to run. > > Now the high-priority task is blocked waiting for the resource that the > low-priority task is holding. The LP-task does not get to run since the > MP-task has higher priority and thus can't release the resource. > > This means that the priority between the HP task and the MP task has in > effect been inverted, since the medium priority task blocks the > high-priority task from running even if there is no resource that both > of them are trying to lock. > > The problem is that when the high-priority task got blocked trying to > acquire the resource that the low-priority task held it effectively > inherited the priority of the low-priority task and can therefore be > preempted by the medium-priority task. > > > To get a priority inversion like this one needs at least three tasks > with different priorities. Ah, yes. I stand corrected :) Thanks, -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Re[2]: FreeBSD security hole?
My wife files my email, so I can't say with surety, but I don't recall seeing the SA on stdio either. I've grepped for the headers and found several (zlib, squid, openssh) but not this one. Fortunately, the volume of mail on the topic has given me pause to take notice. Kevin Kinsey, DaleCo, S.P. - Original Message - From: "Lucky Green" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 25, 2002 5:29 PM Subject: Re[2]: FreeBSD security hole? > Vladimir G. Drobyshevsky wrote: > - > [...] > That's really strange - I subscribed to freebsd-security-notifications, > but didn't receved that message. Or just readed it by Delete key. ;-) > - > > I too am subscribed to the security notifications list and did not > receive the announcement. Fortunately, I read Bugtraq on a daily basis. > Perhaps there is a problem with the announcements mailing list? > > --Lucky > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Re[2]: FreeBSD security hole?
In <057a01c1ecb7$7a0e1c80$b9e2910c@daleco>, Kevin Kinsey, DaleCo, S.P. <[EMAIL PROTECTED]> typed: > My wife files my email, so I can't say with > surety, but I don't recall seeing the SA on stdio > either. I've grepped for the headers and found > several (zlib, squid, openssh) but not this one. Well, I handle my own mail, and *I* certainly got it. I even chmod'ed /usr/bin/keyinit to close the known hole this bug created. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD security hole?
Mike Meyer wrote: > Well, I handle my own mail, and *I* certainly got it. I even chmod'ed > /usr/bin/keyinit to close the known hole this bug created. This just occurred to me -- it isn't possible that this is being routed through an MTA whose A and PTR records don't match, is it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD security hole?
Mike Meyer wrote: > Well, I handle my own mail, and *I* certainly got it. I even chmod'ed > /usr/bin/keyinit to close the known hole this bug created. I handle my own mail and didn't receive it. Isn't in the mailing list archive, either. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: gdb doesn't work over NFS ?
On Thursday, 25 April 2002 at 23:18:34 +1000, Darren Reed wrote: > > Can someone explain why when I use gdb under FreeBSD 4.5, I cannot open > files on an NFS partition that I can outside of gdb ? > > ie. i can do: > > $ wc Makefile > > but I cannot do: > > $ gdb `which wc` > (gdb) run Makefile > > and if I do, I get: > wc: Makefile: open: No such file or directory No, I can't explain this, but I'd guess that you're looking in the wrong place. It works fine here: $ df . Filesystem1048576-blocks UsedAvail Capacity Mounted on wantadilla:/home9722 6477 246772%/wantadilla/home $ wc Makefile 10264858 38315 Makefile $ gdb `which wc` GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... (gdb) run Makefile Starting program: /usr/bin/wc Makefile 10264858 38315 Makefile (no debugging symbols found)...(no debugging symbols found)... Program exited normally. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: EtherExpress 16 not probed at boot on 4.5R
I had a shutdown issue as well, come to think of it. I didn't have any page faults, but I didn't do much with the system other than some basic tests of the card. Does this driver have a maintainer? Any volunteers? JN - Original Message - From: "Karl Heller" <[EMAIL PROTECTED]> To: "John Nielsen" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Karl Heller" <[EMAIL PROTECTED]> Sent: Thursday, April 25, 2002 9:27 PM Subject: Re: EtherExpress 16 not probed at boot on 4.5R > > > Thanks for the patch. It does detect the card now. However, the system is now a bit unstable. It won't shutdown properly.. never gets to the "press any key to reboot" screenk and has a page fault every now and then. Not sure if this is related to the patch or not. But I was surprised to see the dates from 2000. > > Karl > > > - Original Message - > > From: "Karl Heller" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, April 24, 2002 10:39 AM > > Subject: EtherExpress 16 not probed at boot on 4.5R > > > Hello, > > > > > > I posted a bug report about this but haven't heard anything back. I'll > > > post here instead. =) > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=37240 > > > > > > I have a Intel EtherExpress 16 that will not probe on boot, or with a > > > custom kernel. However, under 3.4R it does find it. I'm just switching > > > boot floppies and notice this. I've since installed 4.5R using CDRom, > > > however, I'd like to get it working. Any thoughts or anyone want to help > > > debug this one. There was a previous bug report for another version with > > > similar problems but the issue was dropped. > > > > > > Please respond via email as I'm having some problems getting on the stable > > > email list. > > > > There was a thread about this a while ago on the newsgroup (the subject was > > "Ether16 NIC" if you want to look it up on google). Martin Birgmeier posted > > a patch which I successfully applied to a -stable machine and got my card > > working. I'm attaching a copy of Martin's patch so you can use it. > > > > To the list: PR kern/16937 is marked as closed even though this is an issue > > with -stable. There may be other PR's on this issue as well, but I don't > > know if any of them have patches included. If one of you wants to > > submit/test/commit this I think that would be great. > > > > JN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Lame DNS question (can't set maxfiles to default after upgrade to Bind 8.2.4/FreeBSD 4.5-RELEASE-p3)
Dear Sir, Thank you for your reply. On Thu, Apr 25, 2002 at 08:39:21PM -0700, Doug Barton wrote: > This would actually be better on freebsd-stable, for future > reference. > > > What do you mean by replication? Copying zone files from the master to the secondary; the problem servers are secondaries. > In any case, does this still > happen if you start named as root? That should give you an indication of > whether it's a login.conf problem. There is no problem when running named as root. However, I would like to run it as bind. > Also, did you run cap_mkdb after > editing login.conf? Yes. A couple of times: I tried again when it failed. >If the problem persists when starting the server as > root, post your login.conf file in your response. > > Thank you, Yours sincerely. -- Stanley Hopcroft Network Specialist '...No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friend's or of thine own were. Any man's death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee...' from Meditation 17, J Donne. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Lame DNS question (can't set maxfiles to default after upgradeto Bind 8.2.4/FreeBSD 4.5-RELEASE-p3)
On Fri, 26 Apr 2002, Stanley Hopcroft wrote: > Copying zone files from the master to the secondary; the problem servers > are secondaries. How many zones are you talking about? named does not need to open a file descriptor for every single zone file for the whole life of the daemon. > > In any case, does this still > > happen if you start named as root? That should give you an indication of > > whether it's a login.conf problem. > > There is no problem when running named as root. By which you mean that you don't see the error message when you start it as root? > >If the problem persists when starting the server as > > root, post your login.conf file in your response. You didn't attach the file. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kernel trap 9 with interrupts disabled
:> :> :> To get a priority inversion like this one needs at least three tasks :> with different priorities. : :Ah, yes. I stand corrected :) : :Thanks, :-jj Right, you need three tasks, but one of them has absolutely nothing to do with the process holding the resource or the processing trying to get the resource... it simply needs to eat cpu at a priority higher then the process holding the resource. So while you need three processes, the situation winds up being quite common in a heavily loaded system and utterly trivial to reproduce. The reason this is a major problem in -stable instead of just a minor problem is due to the fact that the 'idle priority queue' is a totally separate queue that was hacked together and thrown into the system without any consideration for the consequences. The kernel's normal priority raising mechanism in tsleep() fails utterly when faced with a totally separate queue. This has been a well known problem in -stable for a long time, which is why I changed the 'idprio' to be a root-only command. It's messy to fix in -stable which is why it hasn't been... but it -current is in much better shape. In fact, for a while in -stable nice +20 and nice -20 processes could interfere with each other in the same way even without using 'idprio'. Fortunately that was fixed a few years ago. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
