Subject: Re: [PATCH] null_blk: don't enable irqs when in irq
To: Rabin Vincent <rabin@rab.in>
References: <1451053594-12188-1-git-send-email-rabin@rab.in>
CC: <linux-kernel@vger.kernel.org>
From: Jens Axboe <axboe@fb.com>
Message-ID: <567E1180.8070004@fb.com>
Date: Fri, 25 Dec 2015 21:03:12 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <1451053594-12188-1-git-send-email-rabin@rab.in>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1237
Lines: 26

On 12/25/2015 07:26 AM, Rabin Vincent wrote:
> When using irq_mode=NULL_IRQ_TIMER, blk_start_queue() is called from the
> hrtimer interrupt.  null_request_fn() calls spin_unlock_irq() and this
> causes the following splat from lockdep since interrupts are being
> enabled while we're in an interrupt handler.
>
> When we're in null_request_fn() we can't know the status of the flags
> saved before blk_start_queue() was called, but we can use in_irq() to
> conditionally enable interrupts only if we're not in a hard interrupt in
> order to handle this case.

Using in_irq() to check for this is... nasty. You have two choices here. 
Either you don't enable interrupts ever. That's safe from the 
perspective of the driver, since we don't block in handling the command. 
That means just unconditionally using spin_unlock() in the request_fn. 
Or you punt queue running to process context, by manually clearing the 
queue stopped flag and using blk_run_queue_async() instead.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/