On 2022-05-30 16:15:08 [-0700], Davidlohr Bueso wrote: > diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > index eee1a24f7e15..fafadb7158a3 100644 > --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > @@ -2948,9 +2948,8 @@ static irqreturn_t ibmvscsis_interrupt(int dummy, void > *data) > struct scsi_info *vscsi = data; > > vio_disable_interrupts(vscsi->dma_dev); > - tasklet_schedule(&vscsi->work_task); looks good.
> - return IRQ_HANDLED; > + return IRQ_WAKE_THREAD; > } > > /** > @@ -3340,7 +3339,7 @@ static void ibmvscsis_handle_crq(unsigned long data) > dev_dbg(&vscsi->dev, "handle_crq, don't process: flags 0x%x, > state 0x%hx\n", > vscsi->flags, vscsi->state); > spin_unlock_bh(&vscsi->intr_lock); So if you move it away from from tasklet you can replace the spin_lock_bh() with spin_lock() since BH does not matter anymore. Except if there is a timer because it matters for a timer_list timer which is invoked in softirq context. This isn't the case except that there is a hrtimer invoking ibmvscsis_service_wait_q(). This is bad because a hrtimer is which is invoked in hard-irq context so a BH lock must not be acquired. lockdep would scream here. You could use HRTIMER_MODE_REL_SOFT which would make it a BH timer. Then you could keep the BH locking but actually you want to get rid of it ;) > - return; > + goto done; > } > > rc = vscsi->flags & SCHEDULE_DISCONNECT; Sebastian
