Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 1 Sep 2021 15:27:51 +0800
From:   Leo Yan <leo.yan@linaro.org>
To:     Marc Zyngier <maz@kernel.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>, linux-kernel@vger.kernel.org,
        Orito Takao <orito.takao@socionext.com>
Subject: Re: [RFC PATCH] irqchip/gic, gic-v3: Ensure data visibility in
 peripheral
Message-ID: <20210901072751.GB303522@leoy-ThinkPad-X240s>
References: <20210901063115.383026-1-leo.yan@linaro.org>
 <87bl5cwzdz.wl-maz@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87bl5cwzdz.wl-maz@kernel.org>
Precedence: bulk

Hi Marc,

On Wed, Sep 01, 2021 at 08:03:52AM +0100, Marc Zyngier wrote:
> On Wed, 01 Sep 2021 07:31:15 +0100,
> Leo Yan <leo.yan@linaro.org> wrote:
> > 
> > When an interrupt line is assered, GIC handles interrupt with the flow
> > (with EOImode == 1):
> > 
> >   gic_handle_irq()
> >    `> do_read_iar()                          => Change int state to active
> >    `> gic_write_eoir()                       => Drop int priority
> >    `> handle_domain_irq()
> >        `> generic_handle_irq_desc()
> >        `> handle_fasteoi_irq()
> >            `> handle_irq_event()             => Peripheral handler and
> > 	                                        de-assert int line
> >            `> cond_unmask_eoi_irq()
> > 	       `> chip->irq_eoi()
> > 	           `> gic_eoimode1_eoi_irq() => Change int state to inactive
> > 
> > In this flow, it has no explicit memory barrier between the functions
> > handle_irq_event() and chip->irq_eoi(), it's possible that the
> > outstanding data has not reached device in handle_irq_event() but the
> > callback chip->irq_eoi() is invoked, this can lead to state transition
> > for level triggered interrupt:
> > 
> >   Flow                             |  Interrupt state in GIC
> >   ---------------------------------+-------------------------------------
> >   Interrupt line is asserted       |  'inactive' -> 'pending'
> >   do_read_iar()                    |  'pending'  -> 'pending & active'
> >   handle_irq_event()               |  Write peripheral register but it's
> >                                    |    not visible for device, so the
> > 				   |    interrupt line is still asserted
> >   chip->irq_eoi()                  |  'pending & active' -> 'pending'
> >                                   ...
> >   Produce spurious interrupt       |
> >       with interrupt ID: 1024      |
> 
> 1024? Surely not.

Sorry for typo, should be 1023.

> 
> >                                    |  Finally the peripheral reigster is
> > 				   |  updated and the interrupt line is
> > 				   |  deasserted: 'pending' -> 'inactive'
> > 
> > To avoid this potential issue, this patch adds wmb() barrier prior to
> > invoke EOI operation, this can make sure the interrupt line is
> > de-asserted in peripheral before deactivating interrupt in GIC.  At the
> > end, this can avoid spurious interrupt.
> 
> If you want to ensure completion of device-specific writes, why isn't
> this the job of the device driver to implement whatever semantic it
> desires?

Seems to me, it's a common requirement for all device drivers to
ensure the outstanding transactions to the endpoint to de-assert the
interrupt line before the GIC driver deactivates the interrupt line.

> What if the interrupt is (shock, horror!) driven by a system
> register instead?

Okay, this is good reason that it's not always to need barrier.

> I think this is merely papering over a driver bug, and adds a
> significant cost to all interrupts for no good reasons.

Understand.  The memory barrier can be added per device driver.

Thanks for quick response,
Leo