Re: [PATCH v6 01/18] mtd: rawnand: sunxi: drain interrupts before reusing the completion

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	 Chen-Yu Tsai <wens@kernel.org>,
	 Jernej Skrabec <jernej.skrabec@gmail.com>,
	 Samuel Holland <samuel@sholland.org>,
	 Maxime Ripard <mripard@kernel.org>,
	Richard Genoud <richard.genoud@bootlin.com>,
	 Masahiro Yamada <yamada.masahiro@socionext.com>,
	 Boris Brezillon <bbrezillon@kernel.org>,
	Brian Norris <computersforpeace@gmail.com>,
	linux-mtd@lists.infradead.org,  devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	 linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org
Subject: Re: [PATCH v6 01/18] mtd: rawnand: sunxi: drain interrupts before reusing the completion
Date: Mon, 12 Oct 2026 22:53:22 +0200	[thread overview]
Message-ID: <87pkxey725.fsf@bootlin.com> (raw)
In-Reply-To: <CADvTj4ppQannShF+dkLreST94g_vSAg4QdMqxhNORzkvci3O1A@mail.gmail.com> (James Hilliard's message of "Mon, 12 Oct 2026 13:17:23 -0600")

>> >> commit log, I now disagree with the first part of:
>> >>
>> >> >The old handler can also complete the new wait or restore an obsolete interrupt mask.
>> >>
>> >> "complete the new wait"? I don't see how a stale handler completes the
>> >> next wait given the handler is a hard IRQ and the interrupt enable
>> >> register is cleared on timeout.
>> >
>> > The case I had in mind is an already-running handler on another CPU:
>> >
>> > CPU 0: Read st and ien for operation A.
>> > CPU 1: Time out operation A, mask/acknowledge its interrupts,
>> >        then eventually reinitialize the completion for operation B.
>> > CPU 0: Call complete() based on the saved st and ien from operation A.
>>
>> For this to fire, the hard IRQ handler on CPU0 would have to be stopped
>> between reading st/ien and calling complete() long enough to span:
>> - A's timeout
>> - A's cleanup
>> - B's wait being rearmed
>> On this hardware, how is this reachable?
>
> CONFIG_PREEMPT_RT provides a concrete mechanism. The driver requests this
> IRQ with flags = 0, without IRQF_NO_THREAD, so the handler is
> forced-threaded. A higher-priority task can preempt that IRQ thread
> after it reads st/ien:

That argument only appears in this reply. It is not in the commit log
nor in the diff, both of which reason about a hard IRQ, no? I'll happily
take the PREEMPT_RT case into account: in that configuration the case is
reachable, but it reads as a justification added after the fact.

Then, I'm curious to know how the AI justifies the use of disable_irq()
as the RT-appropriate choice: doesn't it block without a timeout on the
very IRQ thread the scenario relies on being starved (and gives no
priority inheritance)?

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/