On 20/03/2020 20.55, Dave Howorth wrote:
On Fri, 20 Mar 2020 19:58:44 +0100 Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
On 20/03/2020 16.25, Dave Howorth wrote:
On Fri, 20 Mar 2020 13:21:17 +0100 Per Jessen <> wrote:
Carlos E. R. wrote:
On Friday, 2020-03-20 at 14:12 +0300, Andrei Borzenkov wrote:
>> >> The user run application 'mc' (Midnight Commander) was blocking >> hibernation (and now I see there was another application named >> 'pool'). >> >> I tried to kill 'mc' with killall -9. It still refused. I >> killed the terminal that had it, no way. In the end, I had to >> poweroff the machine instead. >> >> I think that mc was blocked because it had open a remote >> directory externally: >> >> sshfs cer@192.168.1.134:/ ~/fusermount/ >> >> and that other machine had been hibernated a minute before. >> >> >> >> How can it be that a plebeian app stops the almighty kernel in >> its tracks? >> > > Both threads are in kernel mode and as you yourself said cannot > be interrupted. So there is little kernel can do.
Sorry, I still do not understand why a user process such as mc can not be destroyed on order. No excuses.
A user process can enter kernel mode - this one did, and then disabled interrupts. I.e. it has to complete.
Disabled interrupts? But all the processes were working, only this one was stuck. My training said that when interrupts were disabled, noone got access to them.
I don't understand a word of that ?
When one process blocks interrupts, my teachers told me it applied to the entire computer, all processes. Nothing, not even the kernel, can intervene. The keyboard gets blocked, the clock interrupts gets blocked. It is impossible to block interrupts for minutes - and the entire machine was responsive - except a single process. I also do not understand how a user process can block interrupts, that should be reserved to the kernel.
You have one process which disabled interrupts whilst in some bit of kernel code, maybe a driver, who knows. Disabling interrupts just means a bit of code that must complete without any asynchronous calls happening. Most probably to guarantee data integrity. It's perfectly normal.
Right, but kernel code that suspends interrupts is not supposed to persist indefinitely and should have been QAd by kernel devs, no?
Plus as Carlos says, since when has a network connection disappearing been unexpected and have any effect on data integrity?
Right. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)