From: Jeff Mahoney <jeffm@suse.com>
To: dsterba@suse.cz,
Joseph Salisbury <joseph.salisbury@canonical.com>,
luke@dashjr.org, luke-jr+git@utopios.org, jbacik@fb.com,
dsterba@suse.com, stable@vger.kernel.org,
linux-kernel@vger.kernel.org, clm@fb.com,
linux-btrfs@vger.kernel.org, 1619918@bugs.launchpad.net
Subject: Re: [Regression 4.7-rc1] btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl
Date: Mon, 6 Feb 2017 19:37:53 -0500 [thread overview]
Message-ID: <f0e0fba1-a142-15f5-9ea7-718766d3b072@suse.com> (raw)
In-Reply-To: <20170109112815.GE12081@twin.jikos.cz>
[-- Attachment #1.1: Type: text/plain, Size: 2605 bytes --]
On 1/9/17 6:28 AM, David Sterba wrote:
> On Fri, Jan 06, 2017 at 12:22:34PM -0500, Joseph Salisbury wrote:
>> A kernel bug report was opened against Ubuntu [0]. This bug was fixed
>> by the following commit in v4.7-rc1:
>>
>> commit 4c63c2454eff996c5e27991221106eb511f7db38
>>
>> Author: Luke Dashjr <luke@dashjr.org>
>> Date: Thu Oct 29 08:22:21 2015 +0000
>>
>> btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in
>> btrfs_ioctl
>>
>>
>> However, this commit introduced a new regression. With this commit
>> applied, "btrfs fi show" no longer works and the btrfs snapshot
>> functionality breaks.
>
> A plain 32bit kernel with 32bit userspace works fine. The bug seems to
> be on a 64bit kernel with 32bit userspace and the CONFIG_COMPAT compiled
> in. Strace does not show anything special:
>
> stat64("subv1", 0xffc64fcc) = -1 ENOENT (No such file or directory)
> statfs64(".", 84, {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096, f_blocks=5110784, f_bfree=4076143, f_bavail=4010951, f_files=0, f_ffree=0, f_fsid={val=[
> 4260464218, 2297804334]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
> stat64(".", {st_mode=S_IFDIR|0700, st_size=228, ...}) = 0
> stat64(".", {st_mode=S_IFDIR|0700, st_size=228, ...}) = 0
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
> fstat64(3, {st_mode=S_IFDIR|0700, st_size=228, ...}) = 0
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
> write(1, "Create subvolume './subv1'\n", 27) = 27
> ioctl(3, BTRFS_IOC_SUBVOL_CREATE, {fd=0, name="subv1"}) = -1 ENOTTY (Inappropriate ioctl for device)
>
> The value of BTRFS_IOC_SUBVOL_CREATE is same on 32bit and 64bit kernels.
> As it returns ENOTTY, the value is not recognized. A candidate function
> is btrfs_compat_ioctl that checks for just the IOC32 numbers and returns
> -ENOIOCTLCMD otherwise.
>
> The callchain in fs/compat_ioctl.c:ioctl cheks for the specific callback
> first, if it retunrs -ENOIOCTLCMD then goes to the normal ioctl
> callback, so there's always a point we reach the handler of
> BTRFS_IOC_SUBVOL_CREATE. So I don't see how it could happen.
I got a minute to look at this today. It doesn't fallback to the normal
ioctl handler. Since we have ->unlocked_ioctl defined, it checks the
hard-coded compat tables and then fails with -ENOTTY.
Fortunately, the fix is simple. The default stanza of that switch
statement in btrfs_compat_ioctl needs to be removed. Then it just
works. I'll post a fix momentarily.
-Jeff
--
Jeff Mahoney
SUSE Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2017-02-07 0:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 17:22 [Regression 4.7-rc1] btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl Joseph Salisbury
2017-01-06 17:38 ` Luke Dashjr
2017-01-06 20:46 ` Chris Mason
2017-01-09 11:28 ` David Sterba
2017-02-07 0:37 ` Jeff Mahoney [this message]
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=f0e0fba1-a142-15f5-9ea7-718766d3b072@suse.com \
--to=jeffm@suse.com \
--cc=1619918@bugs.launchpad.net \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=jbacik@fb.com \
--cc=joseph.salisbury@canonical.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luke-jr+git@utopios.org \
--cc=luke@dashjr.org \
--cc=stable@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;
as well as URLs for NNTP newsgroup(s).