Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3631662imu; Mon, 28 Jan 2019 08:08:41 -0800 (PST) X-Google-Smtp-Source: ALg8bN5PpLMJNN96pTSMsiBt54j0/KprGnZBWCPnCriDwQH67RYvUjbw7ELr9E4/ijzQOBaapEKm X-Received: by 2002:a63:e655:: with SMTP id p21mr20136722pgj.70.1548691721502; Mon, 28 Jan 2019 08:08:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548691721; cv=none; d=google.com; s=arc-20160816; b=QH5AMALmfAHBwo90l7dSGQhq7Mo1z/GD43lW6ejKei3XNPCGrlxD0ibBFgowKqcW11 Lrg2c2hIjETyJEGn4deFODdo7tsG61ArY2NlR6F8JhtTqWaULNZCl8Gp4QdA3nfsbWUd FQTTNjHSnidSzQ7VVvwW04sG3Cf86/cfXU4XaK0Ix8fupOHnG1UCDaQBzNuwXhXIuwPC MAEmEkpD+vTOk8hdQ2MFiOKgN03CP+9+X+AIuV+riJN6CBfMOmufhg3MH4wPAzZgKoBP IPii/L89xtRZv8vUuocQCtkjnDch8PoAf7dJqS+H0nFQUBKdwPxhn/a1U932BRz5Uo6p kU8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=zI/OIWTDu1ojFQes0gMNz13Hj5+gR+7FVDPV5WAyCS4=; b=NyTLBKbqfCYLIt/JFGkoRaDq70t2n9TQ5FpRpvXW1w+Mc4T4Zx062DpQZlh8vcJIKF Lm2j54qK53ZmEL4w9zdXB2O3L9FhPh6wup6XkuP2j8WQcOV+KOR7RJEUVpntuel8WVvp 8pfX7dq5kjjDeFBV5mA0EkrzPSxvP6H05oQqUkDQ51h/pjf/QKURqYKEm4aYPKz0HTqx OFoPfanYZLHAd2V9AJAaCCxNaEqPVK4EEAdGnZNY3wB/55NlQoLzo00lv4vv/EWOg1Eg vlr5eHLNcgf7amjJlVIJcCH5DyXwCpwh5K6zk7aHPxN66YNdfw5i4cBkFVTaybG6r5ZH ZO0g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3si11881685plo.217.2019.01.28.08.08.26; Mon, 28 Jan 2019 08:08:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731334AbfA1QGM (ORCPT + 99 others); Mon, 28 Jan 2019 11:06:12 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:2687 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731956AbfA1QGI (ORCPT ); Mon, 28 Jan 2019 11:06:08 -0500 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id B7849267FA9724854A59; Tue, 29 Jan 2019 00:06:02 +0800 (CST) Received: from [127.0.0.1] (10.202.226.43) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.408.0; Tue, 29 Jan 2019 00:05:53 +0800 Subject: Re: [PATCH] block: set rq->cmd_flags with bio->opf instead of data->cmd_flags when bio is not Null To: Christoph Hellwig References: <1548337430-66690-1-git-send-email-chenxiang66@hisilicon.com> <1c34d6f9-8c3c-a7ff-a956-46e9dc3c2298@hisilicon.com> <20190128140716.GA18162@infradead.org> <55972c1a-051a-1396-6796-84f349830a35@huawei.com> <20190128155752.GA29076@infradead.org> CC: "chenxiang (M)" , , , , , , , "linux-block@vger.kernel.org" From: John Garry Message-ID: <872f8c26-1c88-fe50-ffec-01c1e882245b@huawei.com> Date: Mon, 28 Jan 2019 16:05:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20190128155752.GA29076@infradead.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.226.43] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28/01/2019 15:57, Christoph Hellwig wrote: > On Mon, Jan 28, 2019 at 03:36:58PM +0000, John Garry wrote: >> As I understood, the problem is the scenario of calling >> blk_mq_make_request()->bio_integrity_prep() where we then allocate a bio >> integrity payload in calling bio_integrity_alloc(). >> >> In this case, bio_integrity_alloc() sets bio->bi_opf |= REQ_INTEGRITY, which >> is no longer consistent with data.cmd_flags. > > I don't see how that could happen: > > static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio) > { > ... > > if (!bio_integrity_prep(bio)) > return BLK_QC_T_NONE; > > ... > > data.cmd_flags = bio->bi_opf; > rq = blk_mq_get_request(q, bio, &data); > > Your code is different to mine, then I see that this has been fixed in 5.0-rc3: commit 7809167da5c86fd6bf309b33dee7a797e263342f Author: Ming Lei Date: Wed Jan 16 19:08:15 2019 +0800 block: don't lose track of REQ_INTEGRITY flag We need to pass bio->bi_opf after bio intergrity preparing, otherwise the flag of REQ_INTEGRITY may not be set on the allocated request, then breaks block integrity. Fixes: f9afca4d367b ("blk-mq: pass in request/bio flags to queue mapping") Cc: Hannes Reinecke Cc: Keith Busch Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Sorry for the noise, John > . >