netdev - Re: [PATCH 1/1] s390/ism: fix concurrency management in ism

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: <20250721123548.31401ac2.pasic@linux.ibm.com>
Date: Mon, 21 Jul 2025 12:35:48 +0200
From: Halil Pasic <pasic@...ux.ibm.com>
To: Alexandra Winter <wintera@...ux.ibm.com>
Cc: Alexander Gordeev <agordeev@...ux.ibm.com>,
        Andrew Lunn
 <andrew+netdev@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo
 Abeni <pabeni@...hat.com>,
        Thorsten Winkler <twinkler@...ux.ibm.com>,
        Heiko
 Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Christian
 Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle
 <svens@...ux.ibm.com>,
        Sebastian Ott <sebott@...ux.ibm.com>,
        Ursula Braun
 <ubraun@...ux.ibm.com>, netdev@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        Aliaksei Makarau <Aliaksei.Makarau@....com>,
        Mahanta Jambigi <mjambigi@...ux.ibm.com>,
        Halil Pasic <pasic@...ux.ibm.com>
Subject: Re: [PATCH 1/1] s390/ism: fix concurrency management in ism_cmd()

On Mon, 21 Jul 2025 10:17:30 +0200
Alexandra Winter <wintera@...ux.ibm.com> wrote:

> >> +	spin_lock_irqsave(&ism->cmd_lock, flags);  
> > 
> > I only found smcd_handle_irq() scheduling a tasklet, but no commands issued.
> > Do we really need disable interrupts?  
> 
> You are right in current code, the interrupt and event handlers of ism and smcd
> never issue a control command that calls ism_cmd().
> OTOH, future ism clients could do that.
> The control commands are not part of the data path, but of connection establish.
> So I don't really expect a performance impact.
> I have it on my ToDo list, to change this to threaded interrupts in the future.
> So no strong opinion on my side.
> Simple spin_lock is fine with me.

I agree!

My train of thought was, lets go with the safe option and look if the
maintainers want something different. I didn't feel confident about
trying to understand the details including the contract between the
clients and the driver.

I will change to simple spin_lock() at the end of the day if nobody
objects since the sentiment seems to be going into this direction and
spin a v2 no later than on Wed.

Thanks for having a look!

Regards,
Halil