Messages in this thread | | | Date | Sat, 27 Mar 2021 20:33:15 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH 6/9] debugfs: Implement debugfs_create_str() |
| |
On Sat, 27 Mar 2021 22:24:45 +0000 Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Mar 26, 2021 at 11:33:58AM +0100, Peter Zijlstra wrote: > > > +again: > > + rcu_read_lock(); > > + str = rcu_dereference(*(char **)file->private_data); > > + len = strlen(str) + 1; > > + > > + if (!copy || copy_len < len) { > > + rcu_read_unlock(); > > + kfree(copy); > > + copy = kmalloc(len + 1, GFP_KERNEL); > > + if (!copy) { > > + debugfs_file_put(dentry); > > + return -ENOMEM; > > + } > > + copy_len = len; > > + goto again; > > + } > > + > > + strncpy(copy, str, len); > > + copy[len] = '\n'; > > + copy[len+1] = '\0'; > > + rcu_read_unlock(); > > *Ow* > > If the string can't change under you, what is RCU use about? > And if it can, any use of string functions is asking for serious > trouble; they are *not* guaranteed to be safe when any of the strings > involved might be modified under them.
Just from looking at the above, RCU isn't protecting that the string can change under you, but the pointer to file->private_data can.
str = rcu_dereference(*(char **)file->private_data);
That's just getting a pointer to the string. While under rcu, the value of that string wont change nor will it be free. But file->private_data might change, and it might free its old value, but will do so after a RCU grace period (which is why the above has rcu_read_lock).
What the above looks like to me is a way to copy that string safely, without worrying that it will be freed underneath you. But there's no worry that it will change.
-- Steve
| |