On Wed, Aug 18 2021, Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > On Wed, 18 Aug 2021 17:59:51 +0200 > Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > >> On 02.08.21 18:32, Tony Krowiak wrote: >> > >> > >> > On 8/2/21 9:53 AM, Halil Pasic wrote: >> >> On Mon, 2 Aug 2021 09:10:26 -0400 >> >> Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote: >> >> >> >>> PING! >> >>> >> >>> This patch will pre-req version 17 of a patch series I have waiting in >> >>> the wings, >> >>> so I'd like to get this one merged ASAP. In particular, if a KVM >> >>> maintainer can >> >>> take a look at the comments concerning the taking of the kvm->lock >> >>> before the >> >>> matrix_mdev->lock it would be greatly appreciated. Those comments begin with >> >>> Message ID <20210727004329.3bcc7d4f.pasic@xxxxxxxxxxxxx> from Halil Pasic. >> >> As far as I'm concerned, we can move forward with this. Was this >> >> supposed to go in via Alex's tree? >> > >> > I am not certain, Christian queued the previous patches related to >> > this on: >> > >> > >> > https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/log/?h=fixes >> > >> > Jason G., since this will need to be integrated with your other patches, >> > where should this be queued? >> >> >> This previous patch (s390/vfio-ap: clean up mdev resources when remove callback invoked) is >> already in master. >> Can you respin the series with all Acks and RBs? >> >> Alex, can you then take these 2 patches via your tree? Thanks >> >> Acked-by: Christian Borntraeger <borntraeger@xxxxxxxxxx> >> for this series. > > > I see some review feedback that seems to suggest a new version would be > posted: > > https://lore.kernel.org/linux-s390/0f03ab0b-2dfd-e1c1-fe43-be2a59030a71@xxxxxxxxxxxxx/ Yeah, I thought so as well. But it also looks like something that could be a fixup on top. > > I also see in this thread: > > https://lore.kernel.org/linux-s390/20210721164550.5402fe1c.pasic@xxxxxxxxxxxxx/ > > that Halil's concern's around open/close races are addressed by Jason's > device_open/close series that's already in my next branch and he > provided an Ack, but there's still the above question regarding the > kvm->lock that was looking for a review from... I'm not sure, maybe > Connie or Paolo. Christian, is this specifically what you're ack'ing? I'm also unsure about the kvm->lock thing. Is taking the lock buried somewhere deep in the code that will ultimately trigger the release? I would at least like a pointer. > > It can ultimately go in through my tree, but not being familiar with > this code I'd hope for more closure. Thanks, > > Alex
