Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp5877869pxu; Wed, 23 Dec 2020 07:39:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJw9mfzP3KwdDZrcvZybe9uN8ksg1RsDFp+Y0kQ8F1Up7WO5sNTkj0DQniqKHspYUodJRyQK X-Received: by 2002:a50:84a9:: with SMTP id 38mr24936177edq.378.1608737942495; Wed, 23 Dec 2020 07:39:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608737942; cv=none; d=google.com; s=arc-20160816; b=wKT4FYUtEHmkx6A+E294cNWul48Nt5/l9nBlyZp6zqWEteTv+ta/pa5ua/CAK+u5sE R0G7RYLSJ9zOE864jdyvLEd21WStqKi5c16k7GY9Fm2cF2ae8Cx8FaaRrtIFTNONa3g1 kJ+Z4mLHdc9bFsDlUJJOBF7JhaU9laSiYc033Oe3/pM/mg8WmeTzUm8JYjBdQENW/UAO Znv9QRPFqAlqM2BsUm20iejalYEhn+dkHQJ+C7Am+JhfLPtZw1EMNLKE5a28cH1X1jck r5xndskW0wYOM/FJdOXY/lNPS09bA0Fl0ESViCwla54y/lu06PtHE1J2N4lhbfvH5l0m QdtQ== 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:subject :references:cc:to:from; bh=tfTHi83yWa2Hln5+Y+dc+OHV8UtwCEsGJ5PfQbjjz70=; b=Yfd2Id7ZsZFTwl58gAbxMGq7bh8DndIyZnTb1okBnIA8pbZsoV0HPXstCgi1XbbLvU DJquZ2ZML5D4DiLWgabMaLiRBiyOXldFXAyJg+XKF884CMBABpx33EFZefxdU8mGcPRc Up0UwlMy5LbmiiBl1dsompkriqXWr/btace3hkdukBZ23tUDBLJSfthbr4AqwVDtkRHX et2lwhBTmV+CBfVzfs6fLBVLCQYMOI8mylMbdB2f7day71aAT8uGwPm123F6Ztdol7VH 90FzNBRX/WxgO0N0ai4DrtjaK0dRweZtoyuupg5VdYiXv3PwWnIxYxV+4sWZtK+5S6Ki jTFw== ARC-Authentication-Results: i=1; mx.google.com; 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 s30si13762153edi.465.2020.12.23.07.38.40; Wed, 23 Dec 2020 07:39:02 -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; 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 S1727845AbgLWPia (ORCPT + 99 others); Wed, 23 Dec 2020 10:38:30 -0500 Received: from vps-vb.mhejs.net ([37.28.154.113]:34618 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726477AbgLWPi3 (ORCPT ); Wed, 23 Dec 2020 10:38:29 -0500 Received: from MUA by vps-vb.mhejs.net with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.93.0.4) (envelope-from ) id 1ks6Cp-0004Hq-UK; Wed, 23 Dec 2020 16:37:39 +0100 From: "Maciej S. Szmigiero" To: Ignat Korchagin Cc: agk@redhat.com, snitzer@redhat.com, dm-devel@redhat.com, dm-crypt@saout.de, linux-kernel@vger.kernel.org, ebiggers@kernel.org, Damien.LeMoal@wdc.com, mpatocka@redhat.com, herbert@gondor.apana.org.au, kernel-team@cloudflare.com, nobuto.murata@canonical.com, Chris Mason , Josef Bacik , David Sterba , linux-btrfs@vger.kernel.org, linux-crypto References: <16ffadab-42ba-f9c7-8203-87fda3dc9b44@maciej.szmigiero.name> Subject: Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG() Message-ID: <74c7129b-a437-ebc4-1466-7fb9f034e006@maciej.szmigiero.name> Date: Wed, 23 Dec 2020 16:37:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <16ffadab-42ba-f9c7-8203-87fda3dc9b44@maciej.szmigiero.name> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14.12.2020 19:11, Maciej S. Szmigiero wrote: > Hi, > > I hit a reproducible BUG() when scrubbing a btrfs fs on top of > a dm-crypt device with no_read_workqueue and no_write_workqueue > flags enabled. Still happens on the current torvalds/master. Due to this bug it is not possible to use btrfs on top of a dm-crypt device with no_read_workqueue and no_write_workqueue flags enabled. @Ignat: Can you have a look at this as the person who added these flags? It looks like to me that the skcipher API might not be safe to call from a softirq context, after all. Maciej