Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp933463pxj; Fri, 4 Jun 2021 01:41:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHWWzvujZnCj4NC4KRD/akMR/THPfcJ37gvcCg5Ao3AUm/qbxU/JbUDFqrGl7kZXvju5tg X-Received: by 2002:a17:907:3e1a:: with SMTP id hp26mr3147533ejc.77.1622796074073; Fri, 04 Jun 2021 01:41:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622796074; cv=none; d=google.com; s=arc-20160816; b=KUtExtveiOLAiaenf+zZJ6olPFdcwAkWh/cVItZSYkZqOXs4I+/6VHAevfK5oBqfKc /aLeNAPyzVUEOvr6QZqx2OatfQ/72lWNQdLl+NzeycWqiqa4y8XPBN/n9hNnqN6Q8nN4 5C+Kns05xAi1Q2mjb4CNQR8vm+gIXJ4L5UVz+EcXoX/cocJihsjclICs6YrAaD6wJ1gm oLri1PkuGSwLI9UtfbOgaIkUMbxMVZ/Tl4RoXHDer7muXSANB6IeaW1TaP2ce1Z2Ru2A 5kTwDLR0sBmuFfiPVgAvava9e9DlMNrHwsPZC+xzZ2qwGy1XxBVBOpD9EaDQgSRm2TR6 7/sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=uTBsVe7bzRrdJ/bmHfQYhbyvvHpibsEBI/sRQslKSu4=; b=UjHrAQ7ZkfCil6mA+Phlzow37Y26iooBwKLJx9Xwk4vBZ/gvPq5lXhBv6KYLPp9dVm 9R8AMrCsKHpheiUt9ZagoXqIxFoAgjdynzycQeguLx6FLw6faytLk8dutq9+ZtUtyy31 ooLXc99deeIyfskFTAozzcMomKy+oaTduMx0g52GD9xz8l4+goe2ZEr6vKLTq6cQPbW5 9PV1uL2MzxZbaRxyR12KPAE0zhkP94Cqy8ogXOAv6sK5RKECYNhpvP41WgVBcagTKIi4 qyRLHDwf2Yw5eq6FNe1m3WKLSi3t6LEyC9uuFtIV6DlCjqXtjaZ7zXCEUAqfJ0a5CKrk 8PEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=g5nbSJxa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hq27si4054345ejc.34.2021.06.04.01.40.48; Fri, 04 Jun 2021 01:41:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=g5nbSJxa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229980AbhFDIkf (ORCPT + 99 others); Fri, 4 Jun 2021 04:40:35 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:40814 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229975AbhFDIke (ORCPT ); Fri, 4 Jun 2021 04:40:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622795928; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uTBsVe7bzRrdJ/bmHfQYhbyvvHpibsEBI/sRQslKSu4=; b=g5nbSJxaBZZii3ZWZnyt1xxpAt7v97lfkHs2I0yskX2CDw5nX9GW8Np0m4f92VDygqWNPB CJsvyBD1mFCGYx2RyxQAAxt4d3+D5cXUvk5oMckXeDOz5iCzK3BK1D/oudYQrX8Yf8UPjd BuAqBvMQNynpc5tm7Ni3Ehe6rBKBlnQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-294-1dhOmYYIOl61qf6ITT0eZQ-1; Fri, 04 Jun 2021 04:38:47 -0400 X-MC-Unique: 1dhOmYYIOl61qf6ITT0eZQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F2CFF1009446; Fri, 4 Jun 2021 08:38:45 +0000 (UTC) Received: from T590 (ovpn-12-139.pek2.redhat.com [10.72.12.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5B88510013D6; Fri, 4 Jun 2021 08:38:37 +0000 (UTC) Date: Fri, 4 Jun 2021 16:38:27 +0800 From: Ming Lei To: Long Li Cc: "longli@linuxonhyperv.com" , "linux-block@vger.kernel.org" , Jens Axboe , Johannes Thumshirn , Pavel Begunkov , Tejun Heo , "Matthew Wilcox (Oracle)" , Jeffle Xu , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Subject: Re: [PATCH] block: return the correct bvec when checking for gaps Message-ID: References: <1622759671-14059-1-git-send-email-longli@linuxonhyperv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 04, 2021 at 06:38:45AM +0000, Long Li wrote: > > Subject: Re: [PATCH] block: return the correct bvec when checking for gaps > > > > Hello Long, > > > > On Thu, Jun 03, 2021 at 03:34:31PM -0700, longli@linuxonhyperv.com wrote: > > > From: Long Li > > > > > > After commit 07173c3ec276 ("block: enable multipage bvecs"), a bvec > > > can have multiple pages. But bio_will_gap() still assumes one page > > > bvec while checking for merging. This causes data corruption on > > > drivers relying on the correct merging on virt_boundary_mask. > > > > Can you explain the data corruption a bit? > > > > IMO, either single page bvec or multipage bvec should be fine, because > > bio_will_gap() just checks if the last bvec of prev bio and the 1st bvec of next > > bio can be merged. > > Hi Ming, > > When bio_will_gap() calls into biovec_phys_mergeable (), seg_boundary_mask (queue_segment_boundary()) is used to test if the two bio_vecs can be merged. This test can succeed if only the 1st page in bvec is used, but at the same time it can fail if all the pages in bvec are used. In other words, if the pages in bvec go across the seg_boundary_mask, the test can potentially succeed if only the 1st page is tested, but can fail if all the pages are tested. > > Later, when SCSI builds the SG list from BIOs (that calls into __blk_bios_map_sg), __blk_segment_map_sg_merge() calls biovec_phys_mergeable() doing the same test . This time it may fail if the pages in bvec go across the seg_boundary_mask (but tested okay in bio_will_gap() earlier, so those two BIOs were merged). If __blk_segment_map_sg_merge() fails, we end up with a broken SG list for drivers assuming the SG list not having offsets in intermediate pages. > OK, the reason is that both bio_will_gap() and __blk_segment_map_sg_merge() have to use same approach to check if two bvecs from two bios can be mergeable. Now __blk_segment_map_sg_merge() won't merge the 1st bvec of next bio into previous bio if the 1st bvec of next bio crosses segment boundary, so bio_will_gap() has to take same way to check if the two bvecs can be merged. Please add the segment boundary and map SG list story in commit log, then the patch looks fine. Thanks, Ming