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
| ||
|
Message-ID: <145477fb-0408-d5c9-2366-139d44e2cc91@linux.ibm.com> Date: Mon, 7 Feb 2022 22:27:03 -0500 From: Tony Krowiak <akrowiak@...ux.ibm.com> To: Halil Pasic <pasic@...ux.ibm.com> Cc: linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org, jjherne@...ux.ibm.com, freude@...ux.ibm.com, borntraeger@...ibm.com, cohuck@...hat.com, mjrosato@...ux.ibm.com, alex.williamson@...hat.com, kwankhede@...dia.com, fiuczy@...ux.ibm.com Subject: Re: [PATCH v17 14/15] s390/ap: notify drivers on config changed and scan complete callbacks On 2/7/22 20:38, Halil Pasic wrote: > On Mon, 7 Feb 2022 14:39:31 -0500 > Tony Krowiak <akrowiak@...ux.ibm.com> wrote: > >>> Back to the topic of locking: it looks to me that on this path you >>> do the filtering and thus the accesses to matrix_mdev->shadow_apcb, >>> matrix_mdev->matrix and matrix_dev->config_info some of which are >>> of type write whithout the matrix_dev->lock held. More precisely >>> only with the matrix_dev->guests_lock held in "read" mode. >>> >>> Did I misread the code? If not, how is that OK? >> You make a valid point, a struct rw_semaphore is not adequate for the >> purposes >> it is used in this patch series. It needs to be a mutex. >> > Good we agree that v17 is racy. > >> For v18 which is forthcoming probably this week, I've been reworking the >> locking >> based on your observation that the struct ap_guest is not necessary given we >> already have a list of the mediated devices which contain the KVM >> pointer. On the other > [..] >>> BTW I got delayed on my "locking rules" writeup. Sorry for that! >> No worries, I've been writing up a vfio-ap-locking.rst document to >> include with the next >> version of the patch series. > I'm looking forward to v18 including that document. I prefer not to > discuss what you wrote about the approach taken in v18 now. It is easier > to me when I have both the text stating the intended design, and the > code that is supposed to adhere to this design. > > Regards, > Halil Coming soon to a theater near you:) >
Powered by blists - more mailing lists