[PATCH 06/10] scsi/ibmvscsi_tgt: Replace work tasklet with threaded irq
Sebastian Andrzej Siewior
bigeasy at linutronix.de
Fri Jun 3 21:05:54 AEST 2022
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
More information about the Linuxppc-dev
mailing list