Re: kernel oops with blk-mq-sched latest

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/17/2017 02:00 PM, Jens Axboe wrote:
> On 01/17/2017 04:47 AM, Jens Axboe wrote:
>> On 01/17/2017 12:57 AM, Hannes Reinecke wrote:
>>> Hi Jens,
>>>
>>> I gave your latest patchset from
>>>
>>> git.kernel.dk/linux-block blk-mq-sched
>>>
>>> I see a kernel oops when shutting down:
>>>
>>> [ 2132.708929] systemd-shutdown[1]: Detaching DM devices.
>>> [ 2132.965107] BUG: unable to handle kernel NULL pointer dereference at
>>> 00000000
>>> 00000001
>>> [ 2133.037182] IP: dd_merged_requests+0x6/0x60
>>> [ 2133.077816] PGD 0
>>> [ 2133.077818]
>>> [ 2133.113087] Oops: 0000 [#1] SMP
>>> [ list of modules removed ]
>>> [ 2133.925265] CPU: 20 PID: 1 Comm: systemd-shutdow Not tainted
>>> 4.10.0-rc4+ #543
>>> [ 2133.990034] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 09/18/2013
>>> [ 2134.050522] task: ffff88042d614040 task.stack: ffffc90003150000
>>> [ 2134.106915] RIP: 0010:dd_merged_requests+0x6/0x60
>>> [ 2134.150593] RSP: 0018:ffffc90003153b18 EFLAGS: 00010002
>>> [ 2134.198740] RAX: ffffffff81cc6de0 RBX: ffff8804296d5040 RCX:
>>> 0000000000000001
>>> [ 2134.262708] RDX: 0000000000000001 RSI: 0000000000000001 RDI:
>>> ffff8804296d5040
>>> [ 2134.326987] RBP: ffffc90003153b30 R08: 0000000000000000 R09:
>>> 0000000000000000
>>> [ 2134.391054] R10: 0000000000000000 R11: 0001f8180001f815 R12:
>>> 0000000000000000
>>> [ 2134.456095] R13: ffff8804296d5040 R14: ffff8804099801f0 R15:
>>> 0000000000000004
>>> [ 2134.521196] FS:  00007fd64d3bf840(0000) GS:ffff88042f900000(0000)
>>> knlGS:0000000000000000
>>> [ 2134.595178] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [ 2134.648637] CR2: 0000000000000001 CR3: 000000081b892000 CR4:
>>> 00000000000406e0
>>> [ 2134.713349] Call Trace:
>>> [ 2134.737168]  ? elv_drain_elevator+0x29/0xa0
>>> [ 2134.775821]  __blk_drain_queue+0x52/0x1a0
>>> [ 2134.812473]  blk_queue_bypass_start+0x6e/0xa0
>>> [ 2134.854009]  blkcg_deactivate_policy+0x30/0xf0
>>> [ 2134.894993]  blk_throtl_exit+0x34/0x50
>>> [ 2134.929450]  blkcg_exit_queue+0x35/0x40
>>> [ 2134.965089]  blk_release_queue+0x33/0xe0
>>> [ 2135.001364]  kobject_cleanup+0x63/0x170
>>> [ 2135.037412]  kobject_put+0x25/0x50
>>> [ 2135.068622]  blk_cleanup_queue+0x198/0x260
>>> [ 2135.107780]  cleanup_mapped_device+0xb5/0xf0 [dm_mod]
>>> [ 2135.154741]  __dm_destroy+0x1a5/0x290 [dm_mod]
>>> [ 2135.195009]  dm_destroy+0x13/0x20 [dm_mod]
>>> [ 2135.232149]  dev_remove+0xde/0x120 [dm_mod]
>>> [ 2135.270184]  ? dev_suspend+0x210/0x210 [dm_mod]
>>> [ 2135.311478]  ctl_ioctl+0x20b/0x510 [dm_mod]
>>> [ 2135.349680]  ? terminate_walk+0xc3/0x140
>>> [ 2135.385442]  ? kmem_cache_free+0x10/0x260
>>> [ 2135.422315]  dm_ctl_ioctl+0x13/0x20 [dm_mod]
>>>
>>> Known issue?
>>
>> Try with this, looks like we're calling the old bypass path for the new
>> path, which is now triggering because q->elevator is true.
> 
> Should have grepped, there's one more path that uses the old bypass
> path for q->mq_ops, potentially. This one handles that one, too.
> 
> 
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index 8ba0af780e88..2630f64bed19 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -1223,7 +1223,11 @@ int blkcg_activate_policy(struct request_queue *q,
>  	if (blkcg_policy_enabled(q, pol))
>  		return 0;
>  
> -	blk_queue_bypass_start(q);
> +	if (q->mq_ops) {
> +		blk_mq_freeze_queue(q);
> +		blk_mq_quiesce_queue(q);
> +	} else
> +		blk_queue_bypass_start(q);
>  pd_prealloc:
>  	if (!pd_prealloc) {
>  		pd_prealloc = pol->pd_alloc_fn(GFP_KERNEL, q->node);
> @@ -1261,7 +1265,10 @@ int blkcg_activate_policy(struct request_queue *q,
>  
>  	spin_unlock_irq(q->queue_lock);
>  out_bypass_end:
> -	blk_queue_bypass_end(q);
> +	if (q->mq_ops)
> +		blk_mq_unfreeze_queue(q);
> +	else
> +		blk_queue_bypass_end(q);
>  	if (pd_prealloc)
>  		pol->pd_free_fn(pd_prealloc);
>  	return ret;
> @@ -1284,7 +1291,12 @@ void blkcg_deactivate_policy(struct request_queue *q,
>  	if (!blkcg_policy_enabled(q, pol))
>  		return;
>  
> -	blk_queue_bypass_start(q);
> +	if (q->mq_ops) {
> +		blk_mq_freeze_queue(q);
> +		blk_mq_quiesce_queue(q);
> +	} else
> +		blk_queue_bypass_start(q);
> +
>  	spin_lock_irq(q->queue_lock);
>  
>  	__clear_bit(pol->plid, q->blkcg_pols);
> @@ -1304,7 +1316,11 @@ void blkcg_deactivate_policy(struct request_queue *q,
>  	}
>  
>  	spin_unlock_irq(q->queue_lock);
> -	blk_queue_bypass_end(q);
> +
> +	if (q->mq_ops)
> +		blk_mq_unfreeze_queue(q);
> +	else
> +		blk_queue_bypass_end(q);
>  }
>  EXPORT_SYMBOL_GPL(blkcg_deactivate_policy);
>  
> diff --git a/block/elevator.c b/block/elevator.c
> index d14cb87e6564..464372840774 100644
> --- a/block/elevator.c
> +++ b/block/elevator.c
> @@ -613,6 +613,9 @@ void elv_drain_elevator(struct request_queue *q)
>  {
>  	static int printed;
>  
> +	if (WARN_ON_ONCE(q->mq_ops))
> +		return;
> +
>  	lockdep_assert_held(q->queue_lock);
>  
>  	while (q->elevator->type->ops.sq.elevator_dispatch_fn(q, 1))
> 
Nearly there.
You're missing a 'blk_mq_start_hw_queues(q)' after
blk_mq_unfreeze_queue(); without it the queue will stall after switching
the scheduler.

Also what's quite suspicious is this:

struct blkcg_gq *blkg_lookup_create(struct blkcg *blkcg,
				    struct request_queue *q)
{
	struct blkcg_gq *blkg;

	WARN_ON_ONCE(!rcu_read_lock_held());
	lockdep_assert_held(q->queue_lock);

	/*
	 * This could be the first entry point of blkcg implementation and
	 * we shouldn't allow anything to go through for a bypassing queue.
	 */
	if (unlikely(blk_queue_bypass(q)))
		return ERR_PTR(blk_queue_dying(q) ? -ENODEV : -EBUSY);

which now won't work as the respective flags aren't set anymore.
Not sure if that's a problem, though.
But you might want to look at that, too.

Nevertheless, with the mentioned modifications to your patch the crashes
don't occur anymore.

Sad news is that it doesn't help _that_ much on spinning rust mpt3sas;
there I still see a ~50% performance penalty on reads.
Write's slightly better than sq performance, though.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@xxxxxxx			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux