On Wed, 20 Jul 2022 18:50:39 +0200
Daniel Bristot de Oliveira <bristot@xxxxxxxxxx> wrote:
> On 7/20/22 18:41, Steven Rostedt wrote:
> > On Tue, 19 Jul 2022 19:27:07 +0200
> > Daniel Bristot de Oliveira <bristot@xxxxxxxxxx> wrote:
> >
> >> +/*
> >> + * reacting_on interface.
> >> + */
> >> +static ssize_t reacting_on_read_data(struct file *filp,
> >> + char __user *user_buf,
> >> + size_t count, loff_t *ppos)
> >> +{
> >> + char *buff;
> >> +
> >> + mutex_lock(&rv_interface_lock);
> >> + buff = reacting_on ? "1\n" : "0\n";
> >> + mutex_unlock(&rv_interface_lock);
> > Again, no need for the locks, but perhaps just to keep things sane:
> >
> > buf = READ_ONCE(reacting_on) ? "1\n" : "0\n";
>
> So, for all files that only read/write a single variable, use READ_ONCE/WRITE_ONCE without
> locks? (and in all usage of that variable too).
Only if there's no races.
That is, taking the locks here provide no benefit over a READ_ONCE().
If there was some logic that checks if the value is still valid or not,
then that would be a different story.
For example:
static int enable_monitor(struct rv_monitor_def *mdef)
{
int retval;
if (!mdef->monitor->enabled) {
retval = mdef->monitor->enable();
if (retval)
return retval;
}
mdef->monitor->enabled = 1;
return 0;
}
That has logic that looks to require a lock to protect things from changing
from underneath.
-- Steve
