Messages in this thread |  | | From | (Eric W. Biederman) | Date | 11 Nov 2000 01:50:23 -0700 |
| |
Andrew Morton <andrewm@uow.edu.au> writes:
> George Anzinger wrote: > > > > The notion of releasing a spin lock by initializing it seems IMHO, on > > the face of it, way off. Firstly the protected area is no longer > > protected which could lead to undefined errors/ crashes and secondly, > > any future use of spinlocks to control preemption could have a lot of > > trouble with this, principally because the locker is unknown. > > > > In the case at hand, it would seem that an unlocked path to the console > > is a more correct answer that gives the system a far better chance of > > actually remaining viable. > > > > Does bust_spinlocks() muck up the preemptive kernel's spinlock > counting? Would you prefer spin_trylock()/spin_unlock()? > It doesn't matter - if we call bust_spinlocks() the kernel is > known to be dead meat and there is a fsck in your near future. > > We are still trying to find out why kumon@fujitsu's 8-way is > crashing on the test10-pre5 sched.c. Looks like it's fixed > in test11-pre2 but we want to know _why_ it's fixed. And at > present each time he hits the bug, his printk() deadlocks. > > So bust_spinlocks() is a RAS feature :) A very important one - > it's terrible when your one-in-a-trillion bug happens and there > are no diagnostics. > > It's a work-in-progress. There are a lot of things which > can cause printk to deadlock: > > - console_lock > - timerlist_lock > - global_irq_lock (console code does global_cli) > - log_wait.lock > - tasklist_lock (printk does wake_up) (*) > - runqueue_lock (printk does wake_up) > > I'll be proposing a better patch for this in a few days.
Hmm. I would like to suggest we look at non locking variants of things. i.e. Data structure version changing with swap.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |