Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Inter Processor Interrupt usage

Tags:

interrupt

An educational principle is: There is not such a thing as a stupid question. The basic idea behind this is that people learn by asking. I was asked to: "Can you show and explain at a programming level what bad will happen if every task could execute all instructions."

I did give the code

    main(){
      _asm_("cli;");
      while(1);
    }

and explained it (the system frozen for good- UP)

Then I was asked: "Is it possible give an example so that system do not freeze even this clearing interrupts is done?"

I did modify the previous example:

I did give the code

    main(){
      _asm_("cli;");
      i=i/0;
      while(1);
    }

and explained it.

Trivially: If we have demand paging i=i/0 causes first a page fault (the data page not present) and an other task can be scheduled to run interrupts enabled during the disk read and later on divide by zero will throw this task away for good.

But the answers were based on UP. What about SMP? I must tell that answers are incomplete. It still easy enough to construct:

    int i;
    main(){
    for(i=0;i<100;i++)// Suppose we have less than 100 CPUs
       if(fork())
        { sleep(5);//The generating task has (most probable) time to do all forks
         _asm_("cli;");
         while(1);
        }
     }

which will disable interrupts for all CPUs, because every CPU gets a poisonous task to run.

Even so far a stupid question did reveal many things good to learn to a beginner: privileged instructions, paging, fault handling, scheduling during DMA, fork..... But a minor doubt remains (shame on me) about the first program running on a SMP.

Will one CPU be out permanently or not? Other CPUs continue and can send re_schedule() IPI message. What happens then? It can be easy to speculate that the frozen CPU do not wake up, because interrupts are disabled. But to be perfectly sure must know more.

My question was: Is the Inter Processor Interrupt (IPI) maskable or non-maskable? I mean in the most common "popular" implementations?

Excuse my stupid question. It can't be very difficult to find an answer. I will seek it. I mean interrupt pin number (telling maskable, I guess).


My own answer - correct? I studied the issue, because nobody else did like it, coming to following thoughts:

With important real-time applications we have had for a long time a watchdog timer (HW interrupting cpu to answer somehow "I am alive"). For example we have main control computer and standby computer taking care of the system if the main computer is down.

What about Linux? What kind watchdog- have we one? We can compile the Linux kernel with or without watchdog.

What the Linux watchdog does? On many(!) x86/x86-64 type hardware there is a feature that enables us to generate 'watchdog NMI interrupts'. It's even possible to disable the NMI watchdog in run-time by writing "0" to /proc/sys/kernel/nmi_watchdog. If any CPU in the system does not execute the period local timer interrupt for more than 5 seconds, APIC tries to fix the situation by a non-maskable interrupt (cpu executes the handler, and kills the process)! (SCC Linux is an different case as to NMI.)

My answers (in the original question) were based on the system without watchdog! It is problematic to answer at a general level and give examples based on some fixed system. The answers can be correct or not depending the cpu and configuration and settings.

Anyway, talking about NMI did make some sense? Did it?

like image 690
SikaS Avatar asked Nov 03 '22 03:11

SikaS


1 Answers

If the CPU didn't restrict access to some instructions, it would be too easy to accidentally or deliberately cause a catastrophe.

push $0
push $0
lidt (%esp)
int $42

This code sequence will reset an x86 processor. Here's why:

  • The code loads the IDTR register with an interrupt descriptor table (IDT) at linear address 0, with a size of one byte.
  • Raises interrupt 42, which can't work because it is beyond the 1-byte limit of the IDT.
  • The CPU tries to raise a general protection fault, interrupt 13. This fails too, because interrupt 13 is beyond the one byte limit.
  • The CPU tries to raise a double fault exception, interrupt 8. This fails too, interrupt 8 is beyond the limit of the IDT.

This is known as a triple-fault. The CPU does a shutdown bus cycle to tell the motherboard that it is now ignoring everything and stopping execution. The motherboard asserts reset, rebooting the machine.

This is actually negligible compared to what code could do. A code sequence could easily hijack the machine altogether and start destroying all of the data on the hard drive, it could send all of your files to a malicious server on the internet, it could change your password, enable remote access, connect out to a malicious server and grant an attacker unlimited shell access. There's no limit on what a program could do.

Processors have privileged instructions for two reasons, the primary purpose is to protect the operating system from buggy programs that might accidentally do something to bring down or hijack the whole machine. The secondary purpose is to restrict deliberately malicious programs from doing the same.

like image 132
doug65536 Avatar answered Nov 08 '22 05:11

doug65536