On Mon, 2020-03-09 at 19:02 -0700, Bart Van Assche wrote: > On 2020-03-09 13:54, Ewan D. Milne wrote: > > The only purpose of the flag is to try to suppress duplicate messages, > > in the common case it is a single thread submitting the queued I/O which > > is going to get rejected. If multiple threads submit I/O there might > > be duplicated messages but that is not all that critical. Hence the > > lack of locking on the flag. > > Hi Ewan, > > My concern is that scsi_prep_state_check() may be called from more than > one thread at the same time and that bitfield changes are not thread-safe. > > Thanks, > > Bart. Yes, I agree that the flag is not thread-safe, but I don't think that is a concern. Because if we get multiple rejecting I/O messages until the other threads see the flag change we are no worse off than before, and once the sdev state changes back to SDEV_RUNNING we won't call scsi_prep_state_check() and examine the flag. -Ewan
