On Fri, Jul 9, 2021 at 10:20 PM Greg Kroah-Hartman
[off-list ref] wrote:

On Fri, Jul 09, 2021 at 10:00:32PM +0800, Zheyu Ma wrote:

quoted

On Thu, Jul 8, 2021 at 3:13 AM Jiri Slaby [off-list ref] wrote:

quoted

On 07. 07. 21, 14:52, Andy Shevchenko wrote:

quoted

On Wed, Jul 7, 2021 at 10:50 AM Jiri Slaby [off-list ref] wrote:

quoted

On 05. 07. 21, 14:53, Zheyu Ma wrote:

quoted

So how it comes an interrupt came before
neo_param() in jsm_tty_open was called?

If IRQ is shared we have a special debug feature to test shared IRQs
on freeing IRQ stage (*).
But it doesn't matter, the IRQ handler must survive at any stage after
the action has been listed.

Yes, but IRQ_NONE is returned from the ISR in that case.

The issue the patch is fixing is for a "malicious" device and I am not
sure we want to fix this -- if I can put in a malicious device, I can
use hammer to kill the box too…

Well, this threat assumption is indeed strong, but this attack may be
real. For example, some programmable USB devices (such as FaceDancer)
may exploit vulnerabilities in the USB device driver to attack. Of
course, there has not been such an attack in the real world for PCI
devices. Or, some devices with DMA functions may also send malicious
data and some previous kernel commits have also fixed such bugs.

Anyway, thanks for your patient comments.

Right now, yes, we treat USB devices as "possibly malicious".  We do not
do so for PCI devices yet.  If we want to do that, then we need to do a
lot of work, not just "this one call in this one driver" type of thing
as there are much bigger issues involved here.

If you wish to take on this work, as you feel PCI devices should be
treated this way, please do so!  But start in the PCI core at the very
least, before worrying about the thousands of individual drivers.

Alright, I understand.

Thank you for your valuable suggestions, I will continue to learn and
make more contributions to the kernel.

Regards,
Zheyu Ma