linux-kernel - Re: [PATCH v2] USB: serial: xr: Add TIOCGRS485 and TIOCSRS485 ioctls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 13 Mar 2023 12:27:15 +0100
From:   Oliver Neukum <oneukum@...e.com>
To:     Jarkko Sonninen <kasper@....fi>, Oliver Neukum <oneukum@...e.com>
Cc:     Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] USB: serial: xr: Add TIOCGRS485 and TIOCSRS485 ioctls

On 13.03.23 11:47, Jarkko Sonninen wrote:
>      Hello,
> 
> It uses only one flag from the struct from user. Would it be better to store only that to state ?
> 
> Do I need locking at all in that case ?
> 
> The whole struct is stored just in case, if someone would implement other functionality later.

Well,

1. would you be happy if you were the one to implement additional
features and found that you'd have to reinvent locking?

2. That would mean discarding the values given for delay_rts_before_send
and delay_rts_after_send. That wouldn't be nice.

It seems to me that all our algorithmic complexity goes away
if you just turn "lock" into a mutex and just take it.

	Regards
		Oliver