Re: block: fix q->flush_rq NULL pointer crash on dm-mpath flush

From: Jens Axboe
Date: Sat Mar 08 2014 - 22:18:57 EST


On 2014-03-08 17:57, Mike Snitzer wrote:
On Sat, Mar 08 2014 at 7:24pm -0500,
Jens Axboe <axboe@xxxxxxxxx> wrote:

On 2014-03-08 15:09, Mike Snitzer wrote:
On Sat, Mar 08 2014 at 4:33pm -0500,
Hannes Reinecke <hare@xxxxxxx> wrote:

On 03/08/2014 07:13 PM, Mike Snitzer wrote:

I'm calm.. was just a bit frustrated. But this isn't a big deal.
I'll make an effort to reach out to relevant people sooner when
similar stuff is reported against recently upstreamed code. Would be
cool if you did the same. I can relate to needing to have the distro
vendor hat on (first needing to determine/answer "is this issue
specific to our hacked distro kernel?", etc).

The patch I made wasn't in the context of 'recently upstreamed
code', it was due to a backport Jan Kara did for our next distro
kernels (3.12-based).

"3.12-based" means nothing given all the backporting for SLES, much like
"3.10-based" means nothing in the context of RHEL7.

The only way this fix is applicable is in the context of "recently
upstreamed code", commit 1874198 ("blk-mq: rework flush sequencing
logic") went upstream for v3.14-rc3.

Jens, please feel free to queue this tested fix for 3.14-rc:

Thanks Mike, queued up.

Thanks.

Also queued up the list addition reversal change.

I had a look at what you queued, thing is commit 1874198 replaced code
in blk_kick_flush() that did use list_add_tail(). So getting back to
the way the original code was (before 1874198) would need something
like the following patch.

But it isn't clear to me why we'd have the duality of front vs tail
additions for flushes. Maybe Christoph knows?

Not sure it'd even make a difference with the use case, but always tail would be broken. But the flushing in general is a bit of a nightmare, so I'd be inclined to add your full fix too, at least this late in -rc.

--
Jens Axboe

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