From: Anand Jain <Anand.Jain@oracle.com>
To: Zach Brown <zab@redhat.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: add framework to read fs info from btrfs-control
Date: Mon, 04 Nov 2013 11:39:49 +0800 [thread overview]
Message-ID: <52771705.4050008@oracle.com> (raw)
In-Reply-To: <20131029213331.GC17681@lenny.home.zabbo.net>
(sorry for the delay, various external issues)
I have sent out the new patch set. Thanks for the comments.
more inline.
On 10/30/13 05:33 AM, Zach Brown wrote:
>
>> This adds ioctl BTRFS_IOC_GET_FSIDS which reads the fs
>> info through the btrfs-control
>
> Why not use sysfs?
various sysfs interface for btrfs is still being a RFC
ioctl would much simpler to get the bug fixed.
>> + sz_fslist_arg = sizeof(*fslist_arg);
>> + fslist_arg = memdup_user(arg, sz_fslist_arg);
>
> Doesn't check allocation failure.
fixed it.
>> +
>> + sz_fslist = sizeof(*fslist) * fslist_arg->count;
>> + kfree(fslist_arg);
>
> That allocation and copy and free gets a single u64. Use
> copy_from_user() for the u64.
oh yes. thanks.
>> + fslist_arg = memdup_user(arg, sz_fslist_arg + sz_fslist);
>
> Allocates an arbitrarily huge size that depends only on user input.
> Doesn't check failure again. And I bet you can scribble on kernel
> memory if you wrap the size.
fixed it. now it finds the number of fsid and then allocates mem.
>> + if (copy_to_user(arg, fslist_arg, sz_fslist_arg + sz_fslist))
>> + ret = -EFAULT;
>
> And there's no reason to buffer all this in the kernel to begin with.
> Just copy_to_user() as you iterate over each fs_devices.
Ok in the v2 patch I have narrowed the allocation and copy to
just what is present. but I still feel one-shot copy is better.
Now I have also used uuid_mutex its bit less granular for the
purpose here but taking into consideration that thread is from
btrfs-control (and so no root pointer is readily available) for
which it should be fine IMO. any comments. thanks.
>> + fslist = (struct btrfs_ioctl_fslist *) fslist +
>> + sizeof(*fslist);
>
> AKA fslist++.
fixed it.
> - z
Posted V2.
Thanks, Anand
next prev parent reply other threads:[~2013-11-04 3:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 17:10 [PATCH] btrfs: add framework to read fs info from btrfs-control Anand Jain
2013-10-25 17:10 ` [PATCH 1/2] btrfs-progs: mechanism to fetch fsinfo " Anand Jain
2013-10-29 16:34 ` [PATCH 2/3 v2] " Anand Jain
2013-10-25 17:10 ` [PATCH 2/2] btrfs-progs: fs show should handle if subvol(s) mounted Anand Jain
2013-10-29 21:33 ` [PATCH] btrfs: add framework to read fs info from btrfs-control Zach Brown
2013-11-04 3:39 ` Anand Jain [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-11-04 3:45 Anand Jain
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=52771705.4050008@oracle.com \
--to=anand.jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=zab@redhat.com \
/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.