linux-kernel - Re: [PATCH] mISDN: hfcsusb: Optimize performance by replacing rw

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] [day] [month] [year] [list]

Message-ID: <20250327170044.GA1883535@horms.kernel.org>
Date: Thu, 27 Mar 2025 17:00:44 +0000
From: Simon Horman <horms@...nel.org>
To: Yu-Chun Lin <eleanor15x@...il.com>
Cc: isdn@...ux-pingi.de, kuba@...nel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, jserv@...s.ncku.edu.tw,
	visitorckw@...il.com
Subject: Re: [PATCH] mISDN: hfcsusb: Optimize performance by replacing
 rw_lock with spinlock

On Thu, Mar 27, 2025 at 11:28:25PM +0800, Yu-Chun Lin wrote:
> On Mon, Mar 24, 2025 at 02:21:15PM +0000, Simon Horman wrote:
> > On Sat, Mar 22, 2025 at 01:20:24AM +0800, Yu-Chun Lin wrote:
> > > The 'HFClock', an rwlock, is only used by writers, making it functionally
> > > equivalent to a spinlock.
> > > 
> > > According to Documentation/locking/spinlocks.rst:
> > > 
> > > "Reader-writer locks require more atomic memory operations than simple
> > > spinlocks. Unless the reader critical section is long, you are better
> > > off just using spinlocks."
> > > 
> > > Since read_lock() is never called, switching to a spinlock reduces
> > > overhead and improves efficiency.
> > > 
> > > Signed-off-by: Yu-Chun Lin <eleanor15x@...il.com>
> > > ---
> > > Build tested only, as I don't have the hardware. 
> > > Ensured all rw_lock -> spinlock conversions are complete, and replacing
> > > rw_lock with spinlock should always be safe.
> > > 
> > >  drivers/isdn/hardware/mISDN/hfcsusb.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > Hi Yu-Chun Lin,
> > 
> > Thanks for your patch.
> > 
> > Unfortunately I think it would be best to leave this rather old
> > and probably little used driver as-is in this regard unless there
> > is a demonstrable improvement on real hardware.
> > 
> > Otherwise the small risk of regression and overhead of driver
> > changes seems to outweigh the theoretical benefit.
> 
> Thank you for your feedback.
> 
> I noticed that the MAINTAINERS file lists a maintainer for ISDN, so I
> was wondering if he might have access to the necessary hardware for
> quick testing.
> 
> Since I am new to the kernel, I would like to ask if there have been
> any past cases or experiences where similar changes were considered
> unsafe. Additionally, I have seen instances where the crypto maintainer
> accepted similar patches even without hardware testing. [1]
> 
> [1]: https://lore.kernel.org/lkml/20240823183856.561166-1-visitorckw@gmail.com/

I think it is a judgement call, and certainly the crypto maintainer is
free to make their own call. But in this case I do lean towards leaving
the code unchanged in the absence of hardware testing.