Re: [PATCH 0/7 um: IRQ handling cleanups

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2020-11-24 at 17:07 +0000, Anton Ivanov wrote:
> 
> Looks like chan_kern.c handles it now. It schedules delayed work
> itself instead of trying to kill the IRQ out of IRQ context.
> 
> So the ->purge in irq.c and everything dealing with it should not be
> necessary any more.

Aha, ok, great :)

Looking at the commit, I don't think I even had to care about ->purge
because it's basically just there to avoid possible use-after-free? And
then even if you did remove it from IRQ context, we'd not be freeing the
data anyway, we'd only be setting some data?

And actually, wouldn't it have been broken before, because
garbage_collect_entries() was still called in free_irq_by_irq_and_dev()?
So it's not like it wouldn't have been freed in the interrupt handler if
you were going to call that from within the interrupt handler? Or did I
misunderstand?

I guess what I'm trying to say is that since I removed the dynamic
allocation of what was previously "struct irq_fd", and
garbage_collect_entries() was called in the relevant places and would
free it, I didn't really see how that was any different?
do_free_by_irq_and_dev() previously marked as purge,
but garbage_collect_irq_entries() was immediately called ...

johannes


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um