Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933144AbdCGRr5 (ORCPT ); Tue, 7 Mar 2017 12:47:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42306 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932931AbdCGRp5 (ORCPT ); Tue, 7 Mar 2017 12:45:57 -0500 Date: Tue, 7 Mar 2017 11:52:33 -0500 From: Mike Snitzer To: Jens Axboe Cc: Jack Wang , NeilBrown , LKML , Lars Ellenberg , Kent Overstreet , Pavel Machek , Mikulas Patocka Subject: Re: blk: improve order of bio handling in generic_make_request() Message-ID: <20170307165233.GB30230@redhat.com> References: <87h93blz6g.fsf@notabene.neil.brown.name> <71562c2c-97f4-9a0a-32ec-30e0702ca575@profitbricks.com> <87lgsjj9w8.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 07 Mar 2017 16:52:34 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2216 Lines: 58 On Tue, Mar 07 2017 at 3:49am -0500, Jack Wang wrote: > > > On 06.03.2017 21:18, Jens Axboe wrote: > > On 03/05/2017 09:40 PM, NeilBrown wrote: > >> On Fri, Mar 03 2017, Jack Wang wrote: > >>> > >>> Thanks Neil for pushing the fix. > >>> > >>> We can optimize generic_make_request a little bit: > >>> - assign bio_list struct hold directly instead init and merge > >>> - remove duplicate code > >>> > >>> I think better to squash into your fix. > >> > >> Hi Jack, > >> I don't object to your changes, but I'd like to see a response from > >> Jens first. > >> My preference would be to get the original patch in, then other changes > >> that build on it, such as this one, can be added. Until the core > >> changes lands, any other work is pointless. > >> > >> Of course if Jens wants a this merged before he'll apply it, I'll > >> happily do that. > > > > I like the change, and thanks for tackling this. It's been a pending > > issue for way too long. I do think we should squash Jack's patch > > into the original, as it does clean up the code nicely. > > > > Do we have a proper test case for this, so we can verify that it > > does indeed also work in practice? > > > Hi Jens, > > I can trigger deadlock with in RAID1 with test below: > > I create one md with one local loop device and one remote scsi > exported by SRP. running fio with mix rw on top of md, force_close > session on storage side. mdx_raid1 is wait on free_array in D state, > and a lot of fio also in D state in wait_barrier. > > With the patch from Neil above, I can no longer trigger it anymore. > > The discussion was in link below: > http://www.spinics.net/lists/raid/msg54680.html In addition to Jack's MD raid test there is a DM snapshot deadlock test, albeit unpolished/needy to get running, see: https://www.redhat.com/archives/dm-devel/2017-January/msg00064.html But to actually test block core's ability to handle this, upstream commit d67a5f4b5947aba4bfe9a80a2b86079c215ca755 ("dm: flush queued bios when process blocks to avoid deadlock") would need to be reverted. Also, I know Lars had a drbd deadlock too. Not sure if Jack's MD test is sufficient to coverage for drbd. Lars?