All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.