From patchwork Mon Nov 30 06:11:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 7721321 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 4FAAC9F387 for ; Mon, 30 Nov 2015 06:12:16 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6510720648 for ; Mon, 30 Nov 2015 06:12:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7601420641 for ; Mon, 30 Nov 2015 06:12:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751907AbbK3GLy (ORCPT ); Mon, 30 Nov 2015 01:11:54 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:35759 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbbK3GLx convert rfc822-to-8bit (ORCPT ); Mon, 30 Nov 2015 01:11:53 -0500 Received: by pacej9 with SMTP id ej9so173939839pac.2; Sun, 29 Nov 2015 22:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-type:content-transfer-encoding; bh=gflddyAtzF29Z9Z8i/dZ+rocxBwhUZqQB2QZ3fu44mU=; b=lqMQ8/wLmU8jDcJ7JV+Ah9ddrViwCTutZn/uDg1Vvfy6MHUCNnKjj0Ct6mcF/katUO WFd8hqmJovlq/x7UYEVYYHSuxj45GzxJkvtalpA1C1SxlNuZPFq+WCAmKSpBvuqD2f3I 5irbnjLrCZ+K806p2Uh9lwydcGRTdZAQEdMV9I6kGb+mAh4qpV9bRlAzz9zS4s+h8wQP qruYBTLVnLf1E0zmsvrC88wlw5D/XQYiUoMG7mrgfrm7jrpuaYQ0CkALvjkXlb6MY34D emUXZdXFliOmnGYctr0j8HaYOCRHsx1fMQ3abv5FVKcVjj7JFm3RltsBg/bvYhvCIQTT atwQ== X-Received: by 10.98.13.211 with SMTP id 80mr67921300pfn.112.1448863912747; Sun, 29 Nov 2015 22:11:52 -0800 (PST) Received: from tom-T450 ([103.192.227.7]) by smtp.gmail.com with ESMTPSA id om8sm28359726pac.17.2015.11.29.22.11.50 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 29 Nov 2015 22:11:52 -0800 (PST) Date: Mon, 30 Nov 2015 14:11:41 +0800 From: Ming Lei To: Markus Trippelsdorf Cc: Mike Snitzer , Hannes Reinecke , Jens Axboe , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, Christoph Hellwig , "Martin K. Petersen" , Ewan Milne , Jeff Moyer , Ming Lei Subject: Re: block: Always check queue limits for cloned requests Message-ID: <20151130141141.6ce3fadb@tom-T450> In-Reply-To: <20151129170506.GB302@x4> References: <1448524017-130967-1-git-send-email-hare@suse.de> <20151126131104.GA24297@redhat.com> <20151129114956.GA321@x4> <565B1D2A.5010603@suse.de> <20151129161532.GA302@x4> <20151129164947.GA15021@redhat.com> <20151129170506.GB302@x4> Organization: Ming X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Sun, 29 Nov 2015 18:05:06 +0100 Markus Trippelsdorf wrote: > On 2015.11.29 at 11:49 -0500, Mike Snitzer wrote: > > On Sun, Nov 29 2015 at 11:15am -0500, > > Markus Trippelsdorf wrote: > > > > > On 2015.11.29 at 16:43 +0100, Hannes Reinecke wrote: > > > > On 11/29/2015 12:49 PM, Markus Trippelsdorf wrote: > > > > > > > > > > I'm still seeing the issue (BUG at drivers/scsi/scsi_lib.c:1096!) even > > > > > with this patch applied. > > > > > > > > > > markus@x4 linux % git describe > > > > > v4.4-rc2-215-g081f3698e606 > > > > > > > > > Can you generate a crashdump? > > > > I would need to cross-check with the other dumps I'm having to figure > > > > out if this really is the same issue. > > > > There have been other reports (and fixes) which show we're fighting > > > > several distinct issues here. > > > > > > Unfortunately no. The crash happens on the disk where I store my log > > > files. And after it happened the magic SysRq keys don't work anymore. > > > > > > The crash only happens on my spinning rust drive that uses the cfq > > > scheduler. The SSDs (deadline) are fine. > > > > > > The BUG happens reproducibly when building http://www.sagemath.org/ on > > > that drive. > > > > Are you using DM multipath? If unsure, please let us know which > > device(s) map to the "spinning rust drive", and provide output from: > > lsblk > > No, I'm not using DM multipath. OK, I guess it is still one block merge issue, care to test the following patch? The patch can address one issue when bio->bi_seg_front_size is set as too small mistakenly, then fewer physical segment may be figured out. --- From 7aa725205f400ee6823a0d19bf9f41a2464725ce Mon Sep 17 00:00:00 2001 From: Ming Lei Date: Mon, 30 Nov 2015 13:10:12 +0800 Subject: [PATCH] blk-merge: fix computing bio->bi_seg_front_size in case of single segment When bio has only one physical segment, we should set bio's bi_seg_front_size as the real(final) size of the single segment. Fixes: 02e707424c2ea(blk-merge: fix blk_bio_segment_split) Reported-by: Markus Trippelsdorf Signed-off-by: Ming Lei --- block/blk-merge.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/block/blk-merge.c b/block/blk-merge.c index 41a55ba..e01405a 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -103,6 +103,9 @@ static struct bio *blk_bio_segment_split(struct request_queue *q, bvprv = bv; bvprvp = &bvprv; sectors += bv.bv_len >> 9; + + if (nsegs == 1 && seg_size > front_seg_size) + front_seg_size = seg_size; continue; } new_segment: