Re: [RFC PATCH 05/13] x86/irq: Reserve a user IPI notification vector

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/23/2021 4:07 PM, Thomas Gleixner wrote:
On Mon, Sep 13 2021 at 13:01, Sohil Mehta wrote:
A user interrupt notification vector is used on the receiver's cpu to
identify an interrupt as a user interrupt (and not a kernel interrupt).
Hardware uses the same notification vector to generate an IPI from a
sender's cpu core when the SENDUIPI instruction is executed.

Typically, the kernel shouldn't receive an interrupt with this vector.
However, it is possible that the kernel might receive this vector.

Scenario that can cause the spurious interrupt:

Step	cpu 0 (receiver task)		cpu 1 (sender task)
----	---------------------		-------------------
1	task is running
2					executes SENDUIPI
3					IPI sent
4	context switched out
5	IPI delivered
	(kernel interrupt detected)

A kernel interrupt can be detected, if a receiver task gets scheduled
out after the SENDUIPI-based IPI was sent but before the IPI was
delivered.
What happens if the SENDUIPI is issued when the target task is not on
the CPU? How is that any different from the above?


This didn't get covered in the other thread. Thought, I would clarify this a bit more.

A notification IPI is sent from the CPU that executes SENDUIPI if the target task is running (SN is 0).

If the target task is not running SN bit in the UPID is set, which prevents any notification interrupts from being generated.

However, it is possible that SN is 0 when SENDUIPI was executed which generates the notification IPI. But when the IPI arrives on receiver CPU, SN has been set, the task state has been saved and UINV has been cleared.

A kernel interrupt is detected in this case. I have a sample that demos this. I'll fix the current code and then send out the results.


The kernel doesn't need to do anything in this case other than receiving
the interrupt and clearing the local APIC. The user interrupt is always
stored in the receiver's UPID before the IPI is generated. When the
receiver gets scheduled back the interrupt would be delivered based on
its UPID.
So why on earth is that vector reaching the CPU at all?

You covered this in the other thread.

+#ifdef CONFIG_X86_USER_INTERRUPTS
+	seq_printf(p, "%*s: ", prec, "UIS");
No point in printing that when user interrupts are not available/enabled
on the system.

Will fix this.

Thanks,

Sohil




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux