lkml.org 
[lkml]   [2022]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V6 02/16] rv: Add runtime reactors interface
On Wed, 20 Jul 2022 18:50:39 +0200
Daniel Bristot de Oliveira <bristot@kernel.org> wrote:

> On 7/20/22 18:41, Steven Rostedt wrote:
> > On Tue, 19 Jul 2022 19:27:07 +0200
> > Daniel Bristot de Oliveira <bristot@kernel.org> 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

\
 
 \ /
  Last update: 2022-07-20 19:04    [W:0.080 / U:1.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site