Re: [PATCH 2/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO
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
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
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
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
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
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/