From patchwork Thu Apr 13 14:45:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 9679495 Return-Path: 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 2D55D60381 for ; Thu, 13 Apr 2017 14:45:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1DDF728659 for ; Thu, 13 Apr 2017 14:45:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 112F72867A; Thu, 13 Apr 2017 14:45:27 +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 vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AE9F428659 for ; Thu, 13 Apr 2017 14:45:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752644AbdDMOp0 (ORCPT ); Thu, 13 Apr 2017 10:45:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60788 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752465AbdDMOpZ (ORCPT ); Thu, 13 Apr 2017 10:45:25 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F13A2C059758; Thu, 13 Apr 2017 14:45:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F13A2C059758 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=ming.lei@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com F13A2C059758 Received: from ming.t460p (ovpn-12-21.pek2.redhat.com [10.72.12.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C290AC05BA; Thu, 13 Apr 2017 14:45:13 +0000 (UTC) Date: Thu, 13 Apr 2017 22:45:10 +0800 From: Ming Lei To: Johannes Thumshirn Cc: Jens Axboe , Omar Sandoval , Bart Van Assche , Hannes Reinecke , Christoph Hellwig , Linux Block Layer Mailinglist , Linux Kernel Mailinglist Subject: Re: [PATCH] block: bios with an offset are always gappy Message-ID: <20170413144505.GB10008@ming.t460p> References: <20170413080629.7610-1-jthumshirn@suse.de> <20170413100110.GB5964@ming.t460p> <20170413115328.GH6734@linux-x5ow.site> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170413115328.GH6734@linux-x5ow.site> User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 13 Apr 2017 14:45:25 +0000 (UTC) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Apr 13, 2017 at 01:53:28PM +0200, Johannes Thumshirn wrote: > On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote: > > On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote: > > > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic > > > in nvme_setup_prps() because the dma_len will drop below zero but the > > > length not. > > > > Looks I can't reproduce the issue in QEMU(32G nvme, either partitioned > > or not, just use 'mkfs.btrfs /dev/nvme0n1p1'), could you share the exact > > mkfs command line and size of your emulated NVMe? > > the exact cmdline is mkfs.btrfs -f /dev/nvme0n1p1 (-f because there was a > existing btrfs on the image). The image is 17179869184 (a.k.a 16G) bytes. > > [...] > > > Could you try the following patch to see if it fixes your issue? > > It's back to the old, erratic behaviour, see log below. Johannes, could you test the following patch? Thanks Ming Tested-by: Johannes Thumshirn Reviewed-by: Johannes Thumshirn diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index b75d6fe5a1b9..cc68dfaef528 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -1672,12 +1672,27 @@ static inline bool bios_segs_mergeable(struct request_queue *q, return true; } -static inline bool bio_will_gap(struct request_queue *q, struct bio *prev, - struct bio *next) +static inline bool bio_will_gap(struct request_queue *q, + struct request *prev_rq, + struct bio *prev, + struct bio *next) { if (bio_has_data(prev) && queue_virt_boundary(q)) { struct bio_vec pb, nb; + /* + * don't merge if the 1st bio starts with non-zero + * offset, otherwise it is quite difficult to respect + * sg gap limit. We work hard to merge huge of small + * bios in case of mkfs. + */ + if (prev_rq) + bio_get_first_bvec(prev_rq->bio, &pb); + else + bio_get_first_bvec(prev, &pb); + if (pb.bv_offset) + return true; + bio_get_last_bvec(prev, &pb); bio_get_first_bvec(next, &nb); @@ -1690,12 +1705,12 @@ static inline bool bio_will_gap(struct request_queue *q, struct bio *prev, static inline bool req_gap_back_merge(struct request *req, struct bio *bio) { - return bio_will_gap(req->q, req->biotail, bio); + return bio_will_gap(req->q, req, req->biotail, bio); } static inline bool req_gap_front_merge(struct request *req, struct bio *bio) { - return bio_will_gap(req->q, bio, req->bio); + return bio_will_gap(req->q, NULL, bio, req->bio); } static inline void blk_dump_rq(const struct request *req, const char *msg)