> On Sep 17, 2015, at 6:58 AM, David Laight <david.lai...@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.
Agreed. > > 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. -matt -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
