[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4cb3cc81-23b6-2df4-41b-853e34b78fb8@linux.intel.com>
Date: Tue, 30 Aug 2022 12:03:52 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc: Jiri Slaby <jirislaby@...nel.org>,
linux-serial <linux-serial@...r.kernel.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>,
Lino Sanfilippo <LinoSanfilippo@....de>,
Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v2 1/4] serial: Rename vars in uart_get_rs485_config()
On Tue, 30 Aug 2022, Greg Kroah-Hartman wrote:
> On Tue, Aug 30, 2022 at 10:29:53AM +0300, Ilpo Järvinen wrote:
> > Make variable names to match uart_set_rs485_config() ones:
> > - rs485 -> rs485_user
> > - aux -> rs485
> >
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@...il.com>
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
> > ---
> > drivers/tty/serial/serial_core.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > index 12c87cd201a7..8834414a0b2f 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -1408,16 +1408,16 @@ int uart_rs485_config(struct uart_port *port)
> > EXPORT_SYMBOL_GPL(uart_rs485_config);
> >
> > static int uart_get_rs485_config(struct uart_port *port,
> > - struct serial_rs485 __user *rs485)
> > + struct serial_rs485 __user *rs485_user)
> > {
> > + struct serial_rs485 rs485;
> > unsigned long flags;
> > - struct serial_rs485 aux;
> >
> > spin_lock_irqsave(&port->lock, flags);
> > - aux = port->rs485;
> > + rs485 = port->rs485;
> > spin_unlock_irqrestore(&port->lock, flags);
>
> I missed this originally, but why does the lock matter here at all? You
> are just copying all data out of the structure into an on-stack one, why
> the extra step at all?
>
> As the structure can change instantly after you release the lock, I
> don't see what the lock is protecting.
At least it cannot return inconsistent serial_rs485 because of the lock.
Probably not an end of the world if the lock wouldn't be taken and a
concurrent update of port->rs485 would be allowed to mess up a getted
serial_rs485 as it seems kind of a high-level/userland concurrency issue
on the tty. Anyway, that seems to be the only reason really.
It's orthogonal to the patch series though.
--
i.
Powered by blists - more mailing lists