Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data

From: Thomas Gleixner <tglx@linutronix.de>
To: Sergei Temerkhanov <s.temerkhanov@gmail.com>
Cc: "Jürgen Groß" <jgross@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
Date: Sat, 22 Aug 2020 02:16:58 +0200	[thread overview]
Message-ID: <87k0xrr0ud.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAPEA6dbdePG2V0MmRo0jFH5Q82Kk5cD=hsvqnDYymFrZ1K=aGg@mail.gmail.com>

On Fri, Aug 21 2020 at 23:38, Sergei Temerkhanov wrote:
> On Fri, Aug 21, 2020 at 11:07 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>> Fiddling in irqchip is wrong to begin with.
>>
>> int irq_set_handler_data(unsigned int irq, void *data);
>> static inline void *irq_get_handler_data(unsigned int irq)
>> static inline void *irq_data_get_irq_handler_data(struct irq_data *d)
>>
>> are accessors to handler_data. Am I missing something?
>
> Well, the patches in question are meant to solve the issue discussed
> in this thread:
> https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00957.html
> All in all, the Dom0 kernel crashes due to a conflict between Xen and
> GPIO pinctrl code both trying to use hander data to track some private
> data. The patch series adds a separate pointer along with a few
> functions for Xen. There may be other ideas on how to resolve this
> issue though
> Here are web archive :-) links:
> https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg01144.html
> https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg01145.html

As I said before, I'm not going to wade through a web archive simply
because it's tideous and I can't reply and quote properly.

Can you please just resend this series with the appropriate maintainers
and mailing lists in Cc which you should have done in the first place,
instead of offering me web links?

Just upfront, adding something just for XEN is wrong to begin with. This
is a conceptual problem and XEN is just triggering it, but the
argumentation must be on the concept level, not at the XEN level.

Without having looked at the patches, I bet that this new pointer has a
XEN name tag on it and the changelogs do not explain anything about the
conceptual problem the patches try to solve.

If I'm right, you might want to fix that before resending. If I'm wrong,
then I owe you a beer.

Thanks,

        tglx