Received: by 10.213.65.68 with SMTP id h4csp755241imn; Thu, 22 Mar 2018 07:55:14 -0700 (PDT) X-Google-Smtp-Source: AG47ELuzp3/JW7satPiZ1fTHgYUAc+9cVUDhxbSXAcLBz6+7v2uX0ZD+nN8+87imI0w/vf/H8xRA X-Received: by 2002:a17:902:b10c:: with SMTP id q12-v6mr26026997plr.197.1521730514160; Thu, 22 Mar 2018 07:55:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521730514; cv=none; d=google.com; s=arc-20160816; b=REsEqFk1rwuJhLxGV/Mrdf5oOQuMLHYruWHywi0sRhN669auvM6XDpGhWVGS3EDNhj ehxwLa8aUJKHdYp3Wu5B/y/ObkxH/u0F9hCrbXi96MMaGWHjaHuiFx0vWPEuAwtwqwMp n79IJFWsyhRM0L4sS6G8IduSTTSW0g5a1Cs2ouwgGRg4ScGAbOMDots9b/NxbIx27ASp 8ATO8ksCm2aN66Ss+gn6AHaSbyadmFDv5YFJA4PKMU0nKhvBISF/9jncak65StUL371z tFvpz/iB0QsZa401Tzz18aM3Lshcacpe6xJJnDNhQQVHCsSKYtv/pdXrfwRWtGCCzQOD 5SNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:cc:date:message-id:subject :mime-version:from:dkim-signature:arc-authentication-results; bh=Hi0KDuOdTTpLxudacionhI1agJ8o7x61BwUccuKEYpM=; b=Wo7HeWBIpHSZAWaY79gpWrMW3GWY+X/fZw22yQTYyxH2MVYTRk3UEM9IQYvY1vMQde Hqsjwq4HBmhROkCyM8VTuPCcfDISempNsfMsv9gpnLi8ntWE8CJNOZmVQPHqg0tzcZcg TPyRjDZjZYzFhv39v5E960ZhHjsIMIGQ6oP8trYBHH3eRkujugNI7fm2Ho0IKhAjvC8S TUGs4bigYzPuAHDzv+YlAibdOngaohb/UCrvj1yF7wJ5H0UGrmmr0mOOoJeOVlRFMdpo OVLTzEKs9cRy0tqazvMdTHZ/RPU0l16bzD0jd31BQ+fHbAarnY3LyRa1s9jmVV+b0Q+3 8wcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@javigon-com.20150623.gappssmtp.com header.s=20150623 header.b=pHIF5D7J; 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 q12-v6si6932303pli.492.2018.03.22.07.54.59; Thu, 22 Mar 2018 07:55:14 -0700 (PDT) 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; dkim=pass header.i=@javigon-com.20150623.gappssmtp.com header.s=20150623 header.b=pHIF5D7J; 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 S1755596AbeCVOeo (ORCPT + 99 others); Thu, 22 Mar 2018 10:34:44 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:39327 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755184AbeCVOem (ORCPT ); Thu, 22 Mar 2018 10:34:42 -0400 Received: by mail-wm0-f51.google.com with SMTP id f125so16481393wme.4 for ; Thu, 22 Mar 2018 07:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=javigon-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=Hi0KDuOdTTpLxudacionhI1agJ8o7x61BwUccuKEYpM=; b=pHIF5D7JxApTpdU5ME2SexUptEMbDIlCtd/mDMT38ReM9aQ389YeFk3VsxojccuCcR AthxFzxDWUESFqyyQCNjXUWvWR+ZXkBtKqdm7XG2GusbBwwz4r6pvkuOzkM0O30lWAal zGg2lpT0gNbzFiOx9TJH5Tjh7d2q7DuSi3dny/5iu3UwdZ9/A69B1j7q4Ul/ziK9+rgD FZeQCmLtzi5zWeadG8KuWO40sPTfI60DUVpNfxhCZSJcZ05i+TE+ojJ+AvcjuRyxFlc4 Fc//71JfC/IO8A3B0lwPtJbUBxEJ5LsBqPHrLXaSazIynIQ/egAZNyifEBo59wt4tzik 9WjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=Hi0KDuOdTTpLxudacionhI1agJ8o7x61BwUccuKEYpM=; b=MsZ71K5TmB4IZZ1WyXGXHL0b713sfj0mxJ8uNA/iA8aZ2JpR4NvjN5NhL4xLW+ISUW KfOtCiMuqjBpsaJTF4iplBVWSASEroxZKoHpOgYBUj9eaNWESYTNkYNYoLZp06w8hJpj vtnWpFrKyDyklkxNWUs1XrKa9tmf2X3YEHPSAatVmThbhDmUO1KsgWRHVdXTkPFnAi7D 9+HrwGFBhUqAX80TrWmGCTgicxALN9mQTuGQyaL5/8Wc/LXIwq8xd/AHIYD7LkOGFU/g IUtaYbcH3EM+ivnuNvklcICt3bBWyv9V2Ym+qZI46P5c/1Y7cVwZyyqqrcpjblf4mXAU YtaQ== X-Gm-Message-State: AElRT7EE4ucAD/Enld5iwHSOog2ufGMcdCT8Y5y7hyhCjx3nODgs2u6v WiiSphMrtHeavyKJmz4rp9oD4Q== X-Received: by 10.80.136.229 with SMTP id d92mr25626136edd.239.1521729280688; Thu, 22 Mar 2018 07:34:40 -0700 (PDT) Received: from mac-halley13.cnexlabs.com (6164211-cl69.boa.fiberby.dk. [193.106.164.211]) by smtp.gmail.com with ESMTPSA id c9sm5095107edl.23.2018.03.22.07.34.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Mar 2018 07:34:40 -0700 (PDT) From: =?utf-8?Q?Javier_Gonz=C3=A1lez?= Content-Type: multipart/signed; boundary="Apple-Mail=_7E61F688-60F6-4A74-827F-1A88F10C6422"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: problem with bio handling on raid5 and pblk Message-Id: <66350920-EC5E-447F-B5DF-0F3C2CDEAA65@javigon.com> Date: Thu, 22 Mar 2018 15:34:37 +0100 Cc: linux-raid@vger.kernel.org, linux-block@vger.kernel.org, LKML , Huaicheng Li To: Jens Axboe , shli@kernel.org X-Mailer: Apple Mail (2.3445.5.20) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Apple-Mail=_7E61F688-60F6-4A74-827F-1A88F10C6422 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, I have been looking into a bug report when using pblk and raid5 on top and I am having problems understanding if the problem is in pblk's bio handling or on raid5's bio assumptions on the completion path. The problem occurs on the read path. In pblk, we take a reference to every read bio as it enters, and release it after completing the bio. generic_make_request() pblk_submit_read() bio_get() ... bio_endio() bio_put() The problem seems to be that on raid5's bi_end_io completion path, raid5_end_read_request(), bio_reset() is called. When put together with pblk's bio handling: generic_make_request() pblk_submit_read() bio_get() ... bio_endio() raid5_end_read_request() bio_reset() bio_put() it results in the newly reset bio being put immediately, thus freed. When the bio is reused then, we have an invalid pointer. In the report we received things crash at BUG_ON(bio->bi_next) at generic_make_request(). As far as I understand, it is part of the bio normal operation for drivers under generic_make_request() to be able to take references and release them after bio completion. Thus, in this case, the assumption made by raid5, that it can issue a bio_reset() is incorrect. But I might be missing an implicit cross layer rule that we are violating in pblk. Any ideas? This said, after analyzing the problem from pblk's perspective, I see not reason to use bio_get()/bio_put() in the read path as it is at the pblk level that we are submitting bio_endio(), thus we cannot risk the bio being freed underneath us. Is this reasoning correct? I remember I introduced these at the time there was a bug on the aio path, which was not cleaning up correctly and could trigger an early bio free, but revisiting it now, it seems unnecessary. Thanks for the help! Javier --Apple-Mail=_7E61F688-60F6-4A74-827F-1A88F10C6422 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEU1dMZpvMIkj0jATvPEYBfS0leOAFAlqzvv0ACgkQPEYBfS0l eOCKNw//QmOPW7HQftRvCqGo7EGFfnFPmtDbwrSwFBAKMv3QJtgONYGlw/jfGW5w w9Gm9smOTGzcpDNjZR6sYwgO28Tdg+dkce+CbR99tsLgxhlvVUQD7lDDD9g7elow N0Nf5O7o8Zrm2jks3fMIf6tkPMcJry/35wF1xtZX1ZQ25e3RwK0qzmhovkFuW9Od rfLlOrW32/pYjt5VeIy4JTiidmEhq86gpdF6gdU7adPqBoiCBSD0Xw44izkw0Ewh J8MvYO11dCwmBjAsufaqnUYc2nswqoP8/rCBSdYjCUBU71dCSp+65fSp8NhqKcfl ZlKmzf3WoflvExIp5lZnHgRIzLYILzHlQVrdotnM/qz3M5OHw1Sg9om3bfWR7Qwq 9c3Q73U4m7Wsl99idrItSDjNFESUQoT+Zp1UIxF48CiA2uRdYC8o4ldI90IFxyeS 7j0fDjtZZjXnDla5d1rlIAVIZr9Ehhl4O3zLldrKxfdNz9XrqiOhgFJAc27heCW3 g1+ENKmojNrYmtONpV2i4466ieAShPd6ZhsYZM3VubuAhJebvsy6XHamuW5+TQvk k43stHv9NYXl1S6d9Z6kDt2I1GnZxk6hpDNqfEge8jAnG1+3y4trfr7Q8E1r4tE1 7oqEuzpWFRZwJbsw66Rb3N01hVokQuW832j+RsU4/pXqIqTy8VM= =6EuD -----END PGP SIGNATURE----- --Apple-Mail=_7E61F688-60F6-4A74-827F-1A88F10C6422--