Message ID | 87k1vepqzk.fsf@notabene.neil.brown.name (mailing list archive) |
---|---|
State | Accepted, archived |
Delegated to: | Mike Snitzer |
Headers | show
Return-Path: <dm-devel-bounces@redhat.com> Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 92E7960467 for <patchwork-dm-devel@patchwork.kernel.org>; Thu, 15 Feb 2018 09:05:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 87E65290B3 for <patchwork-dm-devel@patchwork.kernel.org>; Thu, 15 Feb 2018 09:05:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7C317290C8; Thu, 15 Feb 2018 09:05:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 5FD40290B3 for <patchwork-dm-devel@patchwork.kernel.org>; Thu, 15 Feb 2018 09:05:54 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 78D7F54150; Thu, 15 Feb 2018 09:05:53 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 57D645D70A; Thu, 15 Feb 2018 09:05:53 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id E7348180BAE2; Thu, 15 Feb 2018 09:05:52 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id w1F90UxB017915 for <dm-devel@listman.util.phx.redhat.com>; Thu, 15 Feb 2018 04:00:30 -0500 Received: by smtp.corp.redhat.com (Postfix) id 33A68620C9; Thu, 15 Feb 2018 09:00:30 +0000 (UTC) Delivered-To: dm-devel@redhat.com Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2D8EF60474; Thu, 15 Feb 2018 09:00:24 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1FA6F2823D; Thu, 15 Feb 2018 09:00:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 75A2FAC9C; Thu, 15 Feb 2018 09:00:21 +0000 (UTC) From: NeilBrown <neilb@suse.com> To: Milan Broz <gmazyland@gmail.com>, Mike Snitzer <snitzer@redhat.com>, device-mapper development <dm-devel@redhat.com> Date: Thu, 15 Feb 2018 20:00:15 +1100 In-Reply-To: <70cda2a3-f246-d45b-f600-1f9d15ba22ff@gmail.com> References: <70cda2a3-f246-d45b-f600-1f9d15ba22ff@gmail.com> Message-ID: <87k1vepqzk.fsf@notabene.neil.brown.name> MIME-Version: 1.0 X-Greylist: Sender passed SPF test, Sender IP whitelisted by DNSRBL, ACL 207 matched, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 15 Feb 2018 09:00:23 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 15 Feb 2018 09:00:23 +0000 (UTC) for IP:'195.135.220.15' DOMAIN:'mx2.suse.de' HELO:'mx2.suse.de' FROM:'neilb@suse.com' RCPT:'' X-RedHat-Spam-Score: -2.301 (RCVD_IN_DNSWL_MED, SPF_PASS) 195.135.220.15 mx2.suse.de 195.135.220.15 mx2.suse.de <neilb@suse.com> X-Scanned-By: MIMEDefang 2.78 on 10.5.110.30 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: dm-devel@redhat.com Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: [dm-devel] [PATCH] dm: correctly handle chained bios in dec_pending() X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development <dm-devel.redhat.com> List-Unsubscribe: <https://www.redhat.com/mailman/options/dm-devel>, <mailto:dm-devel-request@redhat.com?subject=unsubscribe> List-Archive: <https://www.redhat.com/archives/dm-devel> List-Post: <mailto:dm-devel@redhat.com> List-Help: <mailto:dm-devel-request@redhat.com?subject=help> List-Subscribe: <https://www.redhat.com/mailman/listinfo/dm-devel>, <mailto:dm-devel-request@redhat.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============5853002174658893782==" Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 15 Feb 2018 09:05:53 +0000 (UTC) X-Virus-Scanned: ClamAV using ClamSMTP |
diff --git a/drivers/md/dm.c b/drivers/md/dm.c index d6de00f367ef..68136806d365 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -903,7 +903,8 @@ static void dec_pending(struct dm_io *io, blk_status_t error) queue_io(md, bio); } else { /* done with normal IO or empty flush */ - bio->bi_status = io_error; + if (io_error) + bio->bi_status = io_error; bio_endio(bio); } }
dec_pending() is given an error status (possibly 0) to be recorded against a bio. It can be called several times on the one 'struct dm_io', and it is careful to only assign a non-zero error to io->status. However when it then assigned io->status to bio->bi_status, it is not careful and could overwrite a genuine error status with zero. This can happen when chained bios are in use. If a bio is chained beneath the bio that this dm_io is handling, the child bio might complete and set bio->bi_status before the dm_io completes. This has been possible since chained bios were introduced in 3.14, and become a lot easier to trigger with commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") as that commit caused dm to start using chained bios itself. A particular failure mode is that if a bio spans an 'error' target and a working target, the 'error' fragment will complete instantly and set the ->bi_status, and the other fragment will normally complete a little later, and will clear ->bi_status. The fix is simply to only assign io_error to bio->bi_status when io_error is not zero. Reported-and-tested-by: Milan Broz <gmazyland@gmail.com> Cc: stable@vger.kernel.org (v3.14+) Signed-off-by: NeilBrown <neilb@suse.com> --- drivers/md/dm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)