Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1927842pxb; Fri, 29 Jan 2021 08:36:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJzm3E5ORpHRRhZ6I6ohxdzJGXuTaBjPF4Dry0UJ3V8I+soKNw/Kx5qsLSsQhQFEPHNEIBa1 X-Received: by 2002:a17:906:3146:: with SMTP id e6mr5213242eje.363.1611938174601; Fri, 29 Jan 2021 08:36:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611938174; cv=none; d=google.com; s=arc-20160816; b=gTqSxSPd4Ks+UP4HSmw63Iins+Ar0uN/0v+yuL5gdrkrLV8GRJ+nCN06f+jcqnZKPE VvLCUbshX2fIPsZi6lI0/dYIBtgeDe/Q7cB+he//5htHfNyDbKDwd5ZY31+m2lSEV4+1 KmMF7W1PurqUXKW8gsU4/iGvWaGd+8RRpQsPPv51RmYezfyQC/SdEQ1OtfDanSFhAf5a kMUbTNity4RPSXr5vr64Gb6sv2EYmnAryaEYvYLjBezuPOwzZnaMfwu6VgWZLqkhGEM/ 2UKHi5vCraggeUAZlLYpR7ul5SFkA8ZVXHpO3Z5OJZuO50+F74gQE7fk+JkTiocowVaV Plxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=yXyKT6zDbMFAkEFtdwkMYtTPfLe2fKWTThL1c/z6Psc=; b=djufHARJQE9zXed/ed063XOhlbK1e85RrQfP2rq32uUGjqbDu7YhDzYE8OVBMT69g5 5Yg4Ct/BawpSqy6ehrjBXEacTpgRDCVdzyjFnQ8C1GQ/VL+M+D0+9rPdRfLLJS1J44p1 cHN0+BNUw1hq11INih/YFNDFnVBXaRZJZCRmkua5D2yOAL5rYr7pMCx5p2Hr6sQMXq33 TFHcK5m6+F9kh6cPj+zEeYW/PAmEsbEZ1/MEEc87Rq39rvaV6haGqYaRGV9+tvjPtLe+ thsXNugJm8EnSvg4bvg1kchBwd7IEYTVB7TdqrdcgRpbefMJUdhhA4OUluypp/4ZoIfq 4lJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=MMERDHwQ; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u1si5023821ejg.476.2021.01.29.08.35.49; Fri, 29 Jan 2021 08:36:14 -0800 (PST) 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=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=MMERDHwQ; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231335AbhA2Qcm (ORCPT + 99 others); Fri, 29 Jan 2021 11:32:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231256AbhA2Qbd (ORCPT ); Fri, 29 Jan 2021 11:31:33 -0500 Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9785C061574 for ; Fri, 29 Jan 2021 08:22:51 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id t17so7062819qtq.2 for ; Fri, 29 Jan 2021 08:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yXyKT6zDbMFAkEFtdwkMYtTPfLe2fKWTThL1c/z6Psc=; b=MMERDHwQ05b9QD93YJaPU4AMCvbvs6S+sHWJcGZk9jtXgp/6oRB0vL3vXX8V8ji15K lN511PomIO8KM0Tfiil2oSMCIc76lMSeqqJ/c5VoVJSyDfR5fMrNdGiBitjkAV4MXgOv wqdiSnmw59YSiJSh4ZXQhtS5djVOy6TGQHepG5Vs4KOOjUTOzJuHcfaC3F5UvNK0fC6O l58UuFLu7fh4+7DDhn+6BdC1ZEyqC6RTKtJU+qs5oru4Quq8neBmkRABFKehgyiFyJ66 6WxemP26L6riW4fyt/MgCKOrreFZqIPoq0gafnwFPI5UHbnzCDEyj+CGXXAgkt/hI11B o9HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yXyKT6zDbMFAkEFtdwkMYtTPfLe2fKWTThL1c/z6Psc=; b=mYkYS/FIE99802VTAXoGLw/HeyDwQX2h/N0feCHmqn+E23Dqwffyq7PVaDv9dupN+K BYsuBj87crcZDH12AEwqWMaoSvQXqr0JFxqhiP0cEjgSaHfsh4gUxYauxXbyIekg+S+6 02VEuDSvURNvoGxV4XytF421nnYC+uppAEp4v32soQr2bu0EJ0aOgCB975q5XPRMaew5 PKCeSNtlwbfYuMVPtiKygbQEP76fIN0VylurTT+4zHnC7oP2P7ls/E9y5vquZgT0qaeH QF7VBtTIGbAWS2sLn/Uqs0ZhjcSm0fHzhu/wv2+XlC4/Ybb4xcLY8ZsJdjtovTckB55Z 9+sQ== X-Gm-Message-State: AOAM531KgDLj3CfFh2B+ZNDHG1wiDSPS8e+SSfDM5BFHioxP/U+LJ/8/ JwIPbY+ogh9uhmOjd9k013r97g== X-Received: by 2002:ac8:4e8b:: with SMTP id 11mr5039195qtp.292.1611937370596; Fri, 29 Jan 2021 08:22:50 -0800 (PST) Received: from [192.168.1.45] (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id q15sm6330066qkj.9.2021.01.29.08.22.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Jan 2021 08:22:49 -0800 (PST) Subject: Re: [PATCH v2] btrfs: Avoid calling btrfs_get_chunk_map() twice To: Michal Rostecki , Chris Mason , David Sterba , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Michal Rostecki References: <20210127135728.30276-1-mrostecki@suse.de> From: Josef Bacik Message-ID: <18dab74b-aea9-0e34-1be5-39d62f44cfd2@toxicpanda.com> Date: Fri, 29 Jan 2021 11:22:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <20210127135728.30276-1-mrostecki@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/27/21 8:57 AM, Michal Rostecki wrote: > From: Michal Rostecki > > Before this change, the btrfs_get_io_geometry() function was calling > btrfs_get_chunk_map() to get the extent mapping, necessary for > calculating the I/O geometry. It was using that extent mapping only > internally and freeing the pointer after its execution. > > That resulted in calling btrfs_get_chunk_map() de facto twice by the > __btrfs_map_block() function. It was calling btrfs_get_io_geometry() > first and then calling btrfs_get_chunk_map() directly to get the extent > mapping, used by the rest of the function. > > This change fixes that by passing the extent mapping to the > btrfs_get_io_geometry() function as an argument. > > v2: > When btrfs_get_chunk_map() returns an error in btrfs_submit_direct(): > - Use errno_to_blk_status(PTR_ERR(em)) as the status > - Set em to NULL > > Signed-off-by: Michal Rostecki This panic'ed all of my test vms in their overnight xfstests runs, the panic is this [ 2449.936502] BTRFS critical (device dm-7): mapping failed logical 1113825280 bio len 40960 len 24576 [ 2449.937073] ------------[ cut here ]------------ [ 2449.937329] kernel BUG at fs/btrfs/volumes.c:6450! [ 2449.937604] invalid opcode: 0000 [#1] SMP NOPTI [ 2449.937855] CPU: 0 PID: 259045 Comm: kworker/u5:0 Not tainted 5.11.0-rc5+ #122 [ 2449.938252] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 [ 2449.938713] Workqueue: btrfs-worker-high btrfs_work_helper [ 2449.939016] RIP: 0010:btrfs_map_bio.cold+0x5a/0x5c [ 2449.939392] Code: 37 87 ff ff e8 ed d4 8a ff 48 83 c4 18 e9 b5 52 8b ff 49 89 c8 4c 89 fa 4c 89 f1 48 c7 c6 b0 c0 61 8b 48 89 ef e8 11 87 ff ff <0f> 0b 4c 89 e7 e8 42 09 86 ff e9 fd 59 8b ff 49 8b 7a 50 44 89 f2 [ 2449.940402] RSP: 0000:ffff9f24c1637d90 EFLAGS: 00010282 [ 2449.940689] RAX: 0000000000000057 RBX: ffff90c78ff716b8 RCX: 0000000000000000 [ 2449.941080] RDX: ffff90c7fbc27ae0 RSI: ffff90c7fbc19110 RDI: ffff90c7fbc19110 [ 2449.941467] RBP: ffff90c7911d4000 R08: 0000000000000000 R09: 0000000000000000 [ 2449.941853] R10: ffff9f24c1637b48 R11: ffffffff8b9723e8 R12: 0000000000000000 [ 2449.942243] R13: 0000000000000000 R14: 000000000000a000 R15: 000000004263a000 [ 2449.942632] FS: 0000000000000000(0000) GS:ffff90c7fbc00000(0000) knlGS:0000000000000000 [ 2449.943072] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2449.943386] CR2: 00005575163c3080 CR3: 000000010ad6c004 CR4: 0000000000370ef0 [ 2449.943772] Call Trace: [ 2449.943915] ? lock_release+0x1c3/0x290 [ 2449.944135] run_one_async_done+0x3a/0x60 [ 2449.944360] btrfs_work_helper+0x136/0x520 [ 2449.944588] process_one_work+0x26e/0x570 [ 2449.944812] worker_thread+0x55/0x3c0 [ 2449.945016] ? process_one_work+0x570/0x570 [ 2449.945250] kthread+0x137/0x150 [ 2449.945430] ? __kthread_bind_mask+0x60/0x60 [ 2449.945666] ret_from_fork+0x1f/0x30 it happens when you run btrfs/060. Please make sure to run xfstests against patches before you submit them upstream. Thanks, Josef