All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dan Carpenter <error27@gmail.com>,
	linux-block@vger.kernel.org, Julia Lawall <julia.lawall@inria.fr>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Hongchen Zhang <zhanghongchen@loongson.cn>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Christian Brauner (Microsoft)" <brauner@kernel.org>,
	David Howells <dhowells@redhat.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	"Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	maobibo <maobibo@loongson.cn>,
	Matthew Wilcox <willy@infradead.org>,
	Sedat Dilek <sedat.dilek@gmail.com>
Subject: Re: block: sleeping in atomic warnings
Date: Tue, 7 Feb 2023 19:35:54 +0000	[thread overview]
Message-ID: <Y+KoGikLhfhDoMWv@gmail.com> (raw)
In-Reply-To: <CAHk-=whL+9An7TP-4vCyZUKP_2bZSLe-ZFR1pGA1DbkrTRLyeQ@mail.gmail.com>

On Tue, Feb 07, 2023 at 10:57:08AM -0800, Linus Torvalds wrote:
> On Tue, Feb 7, 2023 at 10:36 AM Eric Biggers <ebiggers@kernel.org> 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?


Sure, they would still need to do most of the same things though.

> Or could we just *fix* the dummy encryption test to actually work like
> real encryption cases, so that it doesn't have this bogus case?

We've wanted to do that for a very long time, but there never has been a way to
actually do it.  Especially with the filesystem-level keyring now, if the kernel
doesn't automatically add the key for test_dummy_encryption, then userspace
would have to do it *every time it mounts the filesystem*.

The point of the "test_dummy_encryption" mount option is that you can just add
it to the mount options and run existing tests, such as a full run of xfstests,
and test all the encrypted I/O paths that way.  Which is extremely useful; it
wouldn't really be possible to properly test the encryption feature without it.

So that's why we've gone through some pain to keep "test_dummy_encryption"
working over time.

Now, it's possible that "the kernel automatically adds the key for
test_dummy_encryption" could be implemented a bit differently.  It maybe could
be done at the last minute, when the key is being looked for due to a user
filesystem operation, instead of during the mount itself.  That would eliminate
the need to call fscrypt_destroy_keyring() from __put_super(), which would avoid
the issue being discussed here.  I'll see if there's a good way to do that.

- Eric

  parent reply	other threads:[~2023-02-07 19:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-29  6:04 [PATCH v4] pipe: use __pipe_{lock,unlock} instead of spinlock Hongchen Zhang
2023-01-29  7:33 ` Linus Torvalds
2023-02-03  2:24   ` Hongchen Zhang
2023-02-06 15:58   ` Luis Chamberlain
2023-02-06 16:07     ` Linus Torvalds
2023-02-06 16:13     ` Julia Lawall
2023-02-06 16:45       ` Dan Carpenter
2023-02-06 17:54         ` Luis Chamberlain
2023-02-07  7:02           ` Dan Carpenter
2023-02-06 18:25         ` Linus Torvalds
2023-02-07 13:37         ` xen: sleeping in atomic warnings Dan Carpenter
2023-02-07 14:03           ` Juergen Gross
2023-02-07 14:06       ` block: " Dan Carpenter
2023-02-07 16:15         ` Linus Torvalds
2023-02-07 17:53           ` Eric Biggers
2023-02-07 18:24             ` Linus Torvalds
2023-02-07 18:36               ` Eric Biggers
2023-02-07 18:57                 ` Linus Torvalds
2023-02-07 19:09                   ` Linus Torvalds
2023-02-07 19:35                   ` Eric Biggers [this message]
2023-02-07 19:49                     ` Linus Torvalds
2023-02-08  6:53                     ` Eric Biggers
2023-02-07 18:31         ` Jens Axboe
2023-02-08  3:15           ` Yu Kuai
2023-02-03  1:42 ` [PATCH v4] pipe: use __pipe_{lock,unlock} instead of spinlock Hongchen Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+KoGikLhfhDoMWv@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=dhowells@redhat.com \
    --cc=edumazet@google.com \
    --cc=error27@gmail.com \
    --cc=fmdefrancesco@gmail.com \
    --cc=julia.lawall@inria.fr \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maobibo@loongson.cn \
    --cc=mcgrof@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sedat.dilek@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=zhanghongchen@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.