lists.openwall.net   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  linux-cve-announce  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]
Message-ID: <531B74B6.4070004@suse.de>
Date:	Sat, 08 Mar 2014 20:51:18 +0100
From:	Hannes Reinecke <hare@...e.de>
To:	Mike Snitzer <snitzer@...hat.com>,
	Christoph Hellwig <hch@...radead.org>
CC:	Jeff Moyer <jmoyer@...hat.com>, Jens Axboe <axboe@...nel.dk>,
	Shaohua Li <shli@...ionio.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	msnitzer <msnitzer@...hat.com>
Subject: Re: [PATCH 1/1] block: rework flush sequencing for blk-mq

On 03/08/2014 06:33 PM, Mike Snitzer wrote:
> On Sat, Mar 8, 2014 at 10:52 AM, Christoph Hellwig <hch@...radead.org> wrote:
>> On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
>>> Hi, Christoph,
>>>
>>> Did you mean to switch from list_add to list_add_tail?  That seems like
>>> a change that warrants mention.
>>
>> No, that wasn't intentional and should be fixed.  Btw, there was another
>> issue with that commit, in that dm-multipath also needs to allocate
>> ->flush_rq.  I saw a patch from Hannes fixing it in the SuSE tree, and
>> would really love to see him submit that for mainline as well.
>
> Ugh, rq-based DM calls blk_init_allocated_queue.. (ah, looks like best
> to move q->flush_rq allocation from blk_init_queue_node to
> blk_alloc_queue_node?).  Anyway, this all makes sense given the
> crashes we've been dealing with.. we couldn't immediately understand
> how the q->flush_rq would be NULL... grr.  I guess I should've checked
> with you sooner.  I reverted commit 1874198 "blk-mq: rework flush
> sequencing logic" from RHEL7 just yesterday because we were seeing
> crashes on flush with dm-mpath.  But can easily re-apply for RHEL7.1
> (since the request_queue's embedded flush_rq takes up so much space we
> get ample kABI padding).
>
> Not overly proud of the revert, but I deemed easier to revert than
> hunt down the fix given RHEL7 won't actually be providing any blk-mq
> enabled drivers.  That'll change for RHEL7.1.
>
>> Unfortunately SuSE seems to have lots of block and dm fixes and even
>> features that they don't submit upstream.
>
> Yeah, it is certainly disturbing.  No excuse for sitting on fixes like this.
>
> Hannes, _please_ get this dm-mpath flush_rq fix for 3.14 posted ASAP.
> Jens or I will need to get it to Linus next week.
>
Hey, calm down.
I've made the fix just two days ago. And was quite surprised that I've 
been the first hitting that; should've crashed for everybody using 
dm-multipath.
And given the pushback I've gotten recently from patches I would have 
thought that it would work for most users; sure the author would've done 
due diligence on the original patchset ...
Plus I've gotten the reports from S/390, so I put it down to mainframe 
weirdness.

BTW, it not _my_ decision to sit on tons of SUSE specific patches.
I really try to get things upstream. But I cannot do more than sending 
patches upstream, answer patiently any questions, and redo the patchset.
Which I did. Frequently, But, alas, it's up to the maintainer to apply 
them. And I can only ask and hope. The usual story...

I'll be sending the patch soon, Monday at latest.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@...e.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ