From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C590CC636CC for ; Tue, 7 Feb 2023 18:57:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231301AbjBGS5e (ORCPT ); Tue, 7 Feb 2023 13:57:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231805AbjBGS5b (ORCPT ); Tue, 7 Feb 2023 13:57:31 -0500 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC83823660 for ; Tue, 7 Feb 2023 10:57:29 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id u21so17380618edv.3 for ; Tue, 07 Feb 2023 10:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UBj6mQus6ryOdHxfJUZE61s4ML7ZKSWKaLSWveVYJ8E=; b=DtNvCWwPk8FH+RYNhBkyQ+Ieu1H5KuuVGuFo/51V0G4ysuENTf6Oy9VDbDfVyTQhgM e1rJDpJuuqvXg24gmansVexLblPeFPM51zzzfIfCzAx3iUalOso3rSSzQ4z3UYIFJQCo FPSVrTcgjVEGTlcAJYhZkiTl+nCb1pTyZxpOo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UBj6mQus6ryOdHxfJUZE61s4ML7ZKSWKaLSWveVYJ8E=; b=Orkw79iYioC7Ve3ae2Yy02DdZ6DxJlOHoZMajbCCwqRlXfCNUHuGkdnJjeFbKi4qAa D16T4iQZMeQprrgPOfBhvPyJrE7GNsN2qWcGAYb9dRbErveha0Se/d/RC5IR/bJq2UuD 5zh4LY+3pxXRCnOxfvIYBaK868aI83Sktma7zloFe2ZhVDzOtBeDfeUNIj3Fu6wFjcBh WjLlSyZMlhFPqAr2K0lPpw4l66oAE+6YglwT5JZKj3C255MYI3bOkoUwRFMLuVriTi2J 7p9zbxln7TUYxj0gUjCFk3qtoQCSNf8oW+spDYP0zaPVUvFnbnAxt8k2kOmc/y+oOJG1 S17A== X-Gm-Message-State: AO0yUKU0s5TLtmLDp97/jWrWztVGT/RUS2oSNBsHFREycJzQLJ3pupWw sUz9R4OTZ+xGoPJ03v1jEaQT32/mEv2rvi+lTEarXw== X-Google-Smtp-Source: AK7set9JIVSA1d9QcxlJe+8sGZQwuhlyqMkYvOoqNEtjtxgshoIe7rBlLgu9Ii+3ikYwSb6NRyQlUA== X-Received: by 2002:a50:cd13:0:b0:4a3:f31f:93a6 with SMTP id z19-20020a50cd13000000b004a3f31f93a6mr5293115edi.4.1675796247912; Tue, 07 Feb 2023 10:57:27 -0800 (PST) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com. [209.85.208.49]) by smtp.gmail.com with ESMTPSA id c21-20020a056402101500b004a2440f0150sm6749523edu.97.2023.02.07.10.57.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Feb 2023 10:57:26 -0800 (PST) Received: by mail-ed1-f49.google.com with SMTP id a10so10288147edu.9 for ; Tue, 07 Feb 2023 10:57:26 -0800 (PST) X-Received: by 2002:a50:9fa8:0:b0:49d:ec5d:28af with SMTP id c37-20020a509fa8000000b0049dec5d28afmr946530edf.5.1675796246043; Tue, 07 Feb 2023 10:57:26 -0800 (PST) MIME-Version: 1.0 References: <20230129060452.7380-1-zhanghongchen@loongson.cn> <4ffbb0c8-c5d0-73b3-7a4e-2da9a7b03669@inria.fr> In-Reply-To: From: Linus Torvalds Date: Tue, 7 Feb 2023 10:57:08 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: block: sleeping in atomic warnings To: Eric Biggers Cc: Dan Carpenter , linux-block@vger.kernel.org, Julia Lawall , Luis Chamberlain , Hongchen Zhang , Alexander Viro , Andrew Morton , "Christian Brauner (Microsoft)" , David Howells , Mauro Carvalho Chehab , Eric Dumazet , "Fabio M. De Francesco" , Christophe JAILLET , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, maobibo , Matthew Wilcox , Sedat Dilek Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 7, 2023 at 10:36 AM Eric Biggers wrote: > > Also note that keys are normally added using an ioctl, which can only be > executed after the filesystem was mounted. The only exception is the key > associated with the "test_dummy_encryption" mount option. Could we perhaps then replace the fscrypt_destroy_keyring(s); with a more specific fscrypt_destroy_dummy_keyring(s); thing, that would only handle the dummy encryption case? Ot could we just *fix* the dummy encryption test to actually work like real encryption cases, so that it doesn't have this bogus case? > By the way, the following code is in generic_shutdown_super(), and not in > __put_super(), for a very similar reason: Well, but that isn't a problem, exactly because that code isn't in __put_super(). Put another way: the problem with the dummy encryption appears to be exactly that it doesn't actually act like any real encryption would, and then triggers that "this whole sequence gets called even under the spinlock, even though it's documented to not be valid for that case, because we added a bogus test-case that doesn't actually match reality". Looking at Jens' reply to the other cases, Dan's tool seems to be on the money here except for this self-inflicted bogus crypto key thing. Linus