Re: [PATCH 2/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO

2014-11-30 Thread Omar Sandoval 
On Sun, Nov 30, 2014 at 10:11:41AM -0500, Pranith Kumar wrote:
> On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval  wrote:
> > A naked read of the value of an RCU pointer isn't safe. Put the whole 
> > access in
> > an RCU critical section, not just the pointer dereference.
> >
> > Signed-off-by: Omar Sandoval 
> 
> You can use rcu_access_pointer() in the if() condition check rather
> than increasing the read critical section. We should try to keep the
> critical section as small as possible.
> 
> Also, since we have rcu_str_deref() we can use that instead of
> rcu_dereference() on device->name. Thoughts?
> 
That's right, I forgot about rcu_access_pointer. The difference is probably
negligible, and I doubt the performance of this ioctl is very important. Since
we're going to be dereferencing the pointer anyways in some (most?) cases, I
think this is a bit more readable.

-- 
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO

2014-11-30 Thread Pranith Kumar 
On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval  wrote:
> A naked read of the value of an RCU pointer isn't safe. Put the whole access 
> in
> an RCU critical section, not just the pointer dereference.
>
> Signed-off-by: Omar Sandoval 

You can use rcu_access_pointer() in the if() condition check rather
than increasing the read critical section. We should try to keep the
critical section as small as possible.

Also, since we have rcu_str_deref() we can use that instead of
rcu_dereference() on device->name. Thoughts?

> ---
>  fs/btrfs/ioctl.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index ecdf68f..dd55844 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2706,6 +2706,7 @@ static long btrfs_ioctl_dev_info(struct btrfs_root 
> *root, void __user *arg)
> struct btrfs_fs_devices *fs_devices = root->fs_info->fs_devices;
> int ret = 0;
> char *s_uuid = NULL;
> +   struct rcu_string *name;
>
> di_args = memdup_user(arg, sizeof(*di_args));
> if (IS_ERR(di_args))
> @@ -2726,17 +2727,16 @@ static long btrfs_ioctl_dev_info(struct btrfs_root 
> *root, void __user *arg)
> di_args->bytes_used = btrfs_device_get_bytes_used(dev);
> di_args->total_bytes = btrfs_device_get_total_bytes(dev);
> memcpy(di_args->uuid, dev->uuid, sizeof(di_args->uuid));
> -   if (dev->name) {
> -   struct rcu_string *name;
>
> -   rcu_read_lock();
> -   name = rcu_dereference(dev->name);
> +   rcu_read_lock();
> +   name = rcu_dereference(dev->name);
> +   if (name) {
> strncpy(di_args->path, name->str, sizeof(di_args->path));
> -   rcu_read_unlock();
> di_args->path[sizeof(di_args->path) - 1] = 0;
> } else {
> di_args->path[0] = '\0';
> }
> +   rcu_read_unlock();
>
>  out:
> mutex_unlock(_devices->device_list_mutex);
> --
> 2.1.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO

2014-11-30 Thread Omar Sandoval 
A naked read of the value of an RCU pointer isn't safe. Put the whole access in
an RCU critical section, not just the pointer dereference.

Signed-off-by: Omar Sandoval 
---
 fs/btrfs/ioctl.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index ecdf68f..dd55844 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2706,6 +2706,7 @@ static long btrfs_ioctl_dev_info(struct btrfs_root *root, 
void __user *arg)
struct btrfs_fs_devices *fs_devices = root->fs_info->fs_devices;
int ret = 0;
char *s_uuid = NULL;
+   struct rcu_string *name;
 
di_args = memdup_user(arg, sizeof(*di_args));
if (IS_ERR(di_args))
@@ -2726,17 +2727,16 @@ static long btrfs_ioctl_dev_info(struct btrfs_root 
*root, void __user *arg)
di_args->bytes_used = btrfs_device_get_bytes_used(dev);
di_args->total_bytes = btrfs_device_get_total_bytes(dev);
memcpy(di_args->uuid, dev->uuid, sizeof(di_args->uuid));
-   if (dev->name) {
-   struct rcu_string *name;
 
-   rcu_read_lock();
-   name = rcu_dereference(dev->name);
+   rcu_read_lock();
+   name = rcu_dereference(dev->name);
+   if (name) {
strncpy(di_args->path, name->str, sizeof(di_args->path));
-   rcu_read_unlock();
di_args->path[sizeof(di_args->path) - 1] = 0;
} else {
di_args->path[0] = '\0';
}
+   rcu_read_unlock();
 
 out:
mutex_unlock(_devices->device_list_mutex);
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO

2014-11-30 Thread Omar Sandoval 
A naked read of the value of an RCU pointer isn't safe. Put the whole access in
an RCU critical section, not just the pointer dereference.

Signed-off-by: Omar Sandoval osan...@osandov.com
---
 fs/btrfs/ioctl.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index ecdf68f..dd55844 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2706,6 +2706,7 @@ static long btrfs_ioctl_dev_info(struct btrfs_root *root, 
void __user *arg)
struct btrfs_fs_devices *fs_devices = root-fs_info-fs_devices;
int ret = 0;
char *s_uuid = NULL;
+   struct rcu_string *name;
 
di_args = memdup_user(arg, sizeof(*di_args));
if (IS_ERR(di_args))
@@ -2726,17 +2727,16 @@ static long btrfs_ioctl_dev_info(struct btrfs_root 
*root, void __user *arg)
di_args-bytes_used = btrfs_device_get_bytes_used(dev);
di_args-total_bytes = btrfs_device_get_total_bytes(dev);
memcpy(di_args-uuid, dev-uuid, sizeof(di_args-uuid));
-   if (dev-name) {
-   struct rcu_string *name;
 
-   rcu_read_lock();
-   name = rcu_dereference(dev-name);
+   rcu_read_lock();
+   name = rcu_dereference(dev-name);
+   if (name) {
strncpy(di_args-path, name-str, sizeof(di_args-path));
-   rcu_read_unlock();
di_args-path[sizeof(di_args-path) - 1] = 0;
} else {
di_args-path[0] = '\0';
}
+   rcu_read_unlock();
 
 out:
mutex_unlock(fs_devices-device_list_mutex);
-- 
2.1.3

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO

2014-11-30 Thread Pranith Kumar 
On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval osan...@osandov.com wrote:
 A naked read of the value of an RCU pointer isn't safe. Put the whole access 
 in
 an RCU critical section, not just the pointer dereference.

 Signed-off-by: Omar Sandoval osan...@osandov.com

You can use rcu_access_pointer() in the if() condition check rather
than increasing the read critical section. We should try to keep the
critical section as small as possible.

Also, since we have rcu_str_deref() we can use that instead of
rcu_dereference() on device-name. Thoughts?

 ---
  fs/btrfs/ioctl.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

 diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
 index ecdf68f..dd55844 100644
 --- a/fs/btrfs/ioctl.c
 +++ b/fs/btrfs/ioctl.c
 @@ -2706,6 +2706,7 @@ static long btrfs_ioctl_dev_info(struct btrfs_root 
 *root, void __user *arg)
 struct btrfs_fs_devices *fs_devices = root-fs_info-fs_devices;
 int ret = 0;
 char *s_uuid = NULL;
 +   struct rcu_string *name;

 di_args = memdup_user(arg, sizeof(*di_args));
 if (IS_ERR(di_args))
 @@ -2726,17 +2727,16 @@ static long btrfs_ioctl_dev_info(struct btrfs_root 
 *root, void __user *arg)
 di_args-bytes_used = btrfs_device_get_bytes_used(dev);
 di_args-total_bytes = btrfs_device_get_total_bytes(dev);
 memcpy(di_args-uuid, dev-uuid, sizeof(di_args-uuid));
 -   if (dev-name) {
 -   struct rcu_string *name;

 -   rcu_read_lock();
 -   name = rcu_dereference(dev-name);
 +   rcu_read_lock();
 +   name = rcu_dereference(dev-name);
 +   if (name) {
 strncpy(di_args-path, name-str, sizeof(di_args-path));
 -   rcu_read_unlock();
 di_args-path[sizeof(di_args-path) - 1] = 0;
 } else {
 di_args-path[0] = '\0';
 }
 +   rcu_read_unlock();

  out:
 mutex_unlock(fs_devices-device_list_mutex);
 --
 2.1.3

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO

2014-11-30 Thread Omar Sandoval 
On Sun, Nov 30, 2014 at 10:11:41AM -0500, Pranith Kumar wrote:
 On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval osan...@osandov.com wrote:
  A naked read of the value of an RCU pointer isn't safe. Put the whole 
  access in
  an RCU critical section, not just the pointer dereference.
 
  Signed-off-by: Omar Sandoval osan...@osandov.com
 
 You can use rcu_access_pointer() in the if() condition check rather
 than increasing the read critical section. We should try to keep the
 critical section as small as possible.
 
 Also, since we have rcu_str_deref() we can use that instead of
 rcu_dereference() on device-name. Thoughts?
 
That's right, I forgot about rcu_access_pointer. The difference is probably
negligible, and I doubt the performance of this ioctl is very important. Since
we're going to be dereferencing the pointer anyways in some (most?) cases, I
think this is a bit more readable.

-- 
Omar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/