[PATCH v2 09/30] cxlflash: Fix to stop interrupt processing on remove

Matthew R. Ochs mrochs at linux.vnet.ibm.com
Fri Sep 18 02:55:25 AEST 2015

> On Sep 17, 2015, at 6:58 AM, David Laight <David.Laight at ACULAB.COM> wrote:
> From: Linuxppc-dev Matthew R. Ochs
>> Sent: 16 September 2015 22:28
>> Interrupt processing can run in parallel to a remove operation. This
>> can lead to a condition where the interrupt handler is processing with
>> memory that has been freed.
>> To avoid processing an interrupt while memory may be yanked, check for
>> removal while in the interrupt handler. Bail when removal is imminent.
> On the face of it this just reduces the size of the window somewhat.


> What happens if the interrupt routine reads the flag just before it is set
> (so is processing the entry that is being removed) and is then (say)
> interrupted by a higher priority interrupt that takes longer to execute than
> the remove code?

Understood. To completely close we'd need to either introduce a lock or a
reciprocal flag/count such that the remove doesn't make forward progress
until after interrupt processing has completed. I can look at introducing such
a mechanism in a later patch to fully remove the exposure.


More information about the Linuxppc-dev mailing list