lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 08 Mar 2014 20:18:15 -0700
From:	Jens Axboe <>
To:	Mike Snitzer <>
CC:	Hannes Reinecke <>, Mike Snitzer <>,
	Christoph Hellwig <>,
	Jeff Moyer <>, Shaohua Li <>,
	"" <>
Subject: Re: block: fix q->flush_rq NULL pointer crash on dm-mpath flush

On 2014-03-08 17:57, Mike Snitzer wrote:
> On Sat, Mar 08 2014 at  7:24pm -0500,
> Jens Axboe <> wrote:
>> On 2014-03-08 15:09, Mike Snitzer wrote:
>>> On Sat, Mar 08 2014 at  4:33pm -0500,
>>> Hannes Reinecke <> 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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists