linux-kernel - Re: [PATCH] s390/vfio-ap: do not use open locks during VFIO_GROUP_NOTIFY_SET

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]

Message-ID: <20210705141348.GN4459@nvidia.com>
Date:   Mon, 5 Jul 2021 11:13:48 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Tony Krowiak <akrowiak@...ux.ibm.com>
Cc:     Halil Pasic <pasic@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, pasic@...ux.vnet.ibm.com,
        jjherne@...ux.ibm.com
Subject: Re: [PATCH] s390/vfio-ap: do not use open locks during
 VFIO_GROUP_NOTIFY_SET_KVM notification

On Thu, Jul 01, 2021 at 10:28:52AM -0400, Tony Krowiak wrote:

> > I think Jason was talking about open coding locks in general.
> 
> That may be so, but his comments were in support of his
> statement that the  mutex + wait_queue did not resolve
> the issue reported vai the lockdep splat because it turned
> off lockdep.

Rgiht, if this used to be proper locks and lockdep complained then
whatever potential deadlock it found is not magically removed by going
to a wait_queue. It just removes the lockdep annotations that would
identify the issue early.

This is why people should not open code locks, it completely defeats
lockdep. That alone is merit enough for this patch.

Jason