Re:Nasty Lockup Issue Still Being Investigated for Linux 3.18
by Someone on Monday December 01, 2014 @06:35PM
(#8684786)
Divide and conquer. For every modular part in the kernel, define what it is supposed to do: are calls reentrant? What combinations of calls are allowed? What interrupts can it generate? Etc.
If you don't make rules as to how the parts are to behave, how are writers of device drivers going to know how to make a working driver? Tweak it until it doesn't hang the system in a few days?
And how are you going to fix that deadlock you find during debugging? You may know (simple exampe) that thread T1 holds lock L1 while trying to get L2, while thread T2 holds L2 while trying to get L1, but without guidance on how things are supposed to work, how do you even know whether to fix T1 or T2?
IMO, the more complex the system, the greater the need for simpe rules that limit what different parts can do.
Chances are there will still be lockup bugs, but that is not a reason not to try and avoid them.
If you don't make rules as to how the parts are to behave, how are writers of device drivers going to know how to make a working driver? Tweak it until it doesn't hang the system in a few days?
And how are you going to fix that deadlock you find during debugging? You may know (simple exampe) that thread T1 holds lock L1 while trying to get L2, while thread T2 holds L2 while trying to get L1, but without guidance on how things are supposed to work, how do you even know whether to fix T1 or T2?
IMO, the more complex the system, the greater the need for simpe rules that limit what different parts can do.
Chances are there will still be lockup bugs, but that is not a reason not to try and avoid them.