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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z-VumXiqJJkZKNZZ@eleanor-wkdl>
Date: Thu, 27 Mar 2025 23:28:25 +0800
From: Yu-Chun Lin <eleanor15x@...il.com>
To: Simon Horman <horms@...nel.org>
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 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/

Regards,
Yu-Chun