Dave Howorth wrote:
On Sat, 21 Mar 2020 12:37:23 +0100 Per Jessen <per@computer.org> wrote:
Dave Howorth wrote:
On Sat, 21 Mar 2020 09:28:41 +0100 Per Jessen <per@computer.org> wrote:
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?
No and maybe, in that order :-)
It _is_ supposed to suspend indefinitely, but usually not for very long. (in the order of microseconds probably). Yes, it probably has been QAed and shown to work fine.
Ah, I think I understand. When the term 'interrupt' is used, Carlos and I think of a hardware capability. I gather you're thinking of an emulated software capability.
Yes, I'm looking at it as being "sat" inside a process. Hardware interrupts are usually not serviced by a process (kernel or user), but by an interrupt handler which then queues whatever it is (for processing). (I'm not sure how HPET interrupts are handled though).
Carlos' 'midnight commander' is just a process, accessing the fuse filesystem that is mounted with sshfs. As it has disabled SIGKILL, it must be in kernel mode. I think disabling SIGKILL can only be interpreted to mean "this _must_ complete, to avoid corrupting data".
OK, I think the difficulty we've had is that you've been using the word 'interrupt' when you should have been using the word 'signal'.
I guess I tend to think of signals causing interrupts, i.e. asynchronous execution of code. Signals can be blocked. Yes, I use the two words interchangeably, mea culpa. -- Per Jessen, Zürich (7.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org