[PATCH 7/7] um: simplify IRQ handling code
Anton Ivanov
anton.ivanov at kot-begemot.co.uk
Wed Dec 2 06:31:53 EST 2020
On 02/12/2020 11:29, Johannes Berg wrote:
> On Wed, 2020-12-02 at 09:03 +0000, Anton Ivanov wrote:
>>
>> raw sockets on a vEth pair.
>>
>> I avoid tap as it does not exercise the full vector IO code for now.
>> One day I will find a way to extract from the kernel the underlying
>> socket which tap uses internally and it will become 100% equivalent to
>> the other transports.
>
> OK, thanks.
>
>>>> Try to ifup/ifdown the vecX interface inside the UML.
>>>>
>>>> With master it works fine. With this patch it fails.
>>> How does it fail?
>>
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 401 at arch/um/kernel/irq.c:177 um_request_irq+0xff/0x22e
>
> Hm, interesting. So that means the IRQ was still busy after
> vector_net_close()?
>
> I'm still digging and trying to build a test case, but if you have a
> test case at hand .. I wonder if IRQ aliasing happened - if you remove
> the "goto out;" in free_irq_by_irq_and_dev(), does that help?
>
>
> johannes
>
>
I think we should just handle EPOLLHUP and do an IRQ + fd disable if it HUPS.
This way a close will always be handled correctly regardless of where and how it closed.
I am about to try a patch on top of your 7 which does that.
--
Anton R. Ivanov
https://www.kot-begemot.co.uk/
More information about the linux-um
mailing list