From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: fstests@vger.kernel.org, linux-fscrypt@vger.kernel.org
Subject: Re: [PATCH] generic/395: remove workarounds for wrong error codes
Date: Sat, 31 Oct 2020 13:34:39 -0400 [thread overview]
Message-ID: <20201031173439.GA1750809@mit.edu> (raw)
In-Reply-To: <20201031054018.695314-1-ebiggers@kernel.org>
On Fri, Oct 30, 2020 at 10:40:18PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> generic/395 contains workarounds to allow for some of the fscrypt ioctls
> to fail with different error codes. However, the error codes were all
> fixed up and documented years ago:
>
> - FS_IOC_GET_ENCRYPTION_POLICY on ext4 failed with ENOENT instead of
> ENODATA on unencrypted files. Fixed by commit db717d8e26c2
> ("fscrypto: move ioctl processing more fully into common code").
>
> - FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of EEXIST
> on encrypted files. Fixed by commit 8488cd96ff88 ("fscrypt: use
> EEXIST when file already uses different policy").
>
> - FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of ENOTDIR
> on nondirectories. Fixed by commit dffd0cfa06d4 ("fscrypt: use
> ENOTDIR when setting encryption policy on nondirectory").
>
> It's been long enough, so update the test to expect the correct behavior
> only, so we don't accidentally reintroduce the wrong behavior.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
LGTM
Did these fixes get backported into the stable kernels (and the
relevant Android trees)?
- Ted
next prev parent reply other threads:[~2020-10-31 17:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-31 5:40 [PATCH] generic/395: remove workarounds for wrong error codes Eric Biggers
2020-10-31 17:34 ` Theodore Y. Ts'o [this message]
2020-10-31 18:10 ` Eric Biggers
2020-11-09 23:40 ` Eric Biggers
2020-11-10 4:41 ` Eric Biggers
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=20201031173439.GA1750809@mit.edu \
--to=tytso@mit.edu \
--cc=ebiggers@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox