linux-kernel - Re: [PATCH v1 2/5] KVM: s390: remove unneeded srcu lock

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: <faa9ad1e-2497-42da-a825-c25986251005@de.ibm.com>
Date: Fri, 27 Jun 2025 10:45:05 +0200
From: Christian Borntraeger <borntraeger@...ibm.com>
To: Nina Schoetterl-Glausch <nsg@...ux.ibm.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        linux-kernel@...r.kernel.org
Cc: kvm@...r.kernel.org, linux-s390@...r.kernel.org, frankja@...ux.ibm.com,
        seiden@...ux.ibm.com, nrb@...ux.ibm.com, david@...hat.com,
        hca@...ux.ibm.com, agordeev@...ux.ibm.com, svens@...ux.ibm.com,
        gor@...ux.ibm.com
Subject: Re: [PATCH v1 2/5] KVM: s390: remove unneeded srcu lock



Am 20.05.25 um 16:34 schrieb Nina Schoetterl-Glausch:
> On Mon, 2025-05-19 at 16:42 +0200, Nina Schoetterl-Glausch wrote:
>> On Wed, 2025-05-14 at 18:38 +0200, Claudio Imbrenda wrote:
>>> All paths leading to handle_essa() already hold the kvm->srcu.
>>> Remove unneeded srcu locking from handle_essa().
>>>
>>> Signed-off-by: Claudio Imbrenda <imbrenda@...ux.ibm.com>
>>
>> Reviewed-by: Nina Schoetterl-Glausch <nsg@...ux.ibm.com>
>>
>> Why are you removing it tho?
>> It should be very low cost and it makes the code more robust,
>> since handle_essa itself ensures that it has the lock.
>> It is also easier to understand which synchronization the function does.
>> You could of course add a comment stating that the kvm srcu read side needs
>> to be held. I think this would be good to have if you really don't want the
>> srcu_read_lock here.
>> But then you might also want that documented up the call chain.
> 
> Actually, can we use __must_hold or have some assert?

Yes, that might be the best way.