On Thu, 24 Jan 2019 11:19:34 +0100 Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > On Thu, 24 Jan 2019 11:08:02 +0100 > Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote: > > > On 23/01/2019 11:21, Cornelia Huck wrote: > > > On Tue, 22 Jan 2019 19:33:46 +0100 > > > Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: > > > > > >> On Mon, 21 Jan 2019 12:03:51 +0100 > > >> Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > > >> > > >>> --- a/drivers/s390/cio/vfio_ccw_private.h > > >>> +++ b/drivers/s390/cio/vfio_ccw_private.h > > >>> @@ -28,6 +28,7 @@ > > >>> * @mdev: pointer to the mediated device > > >>> * @nb: notifier for vfio events > > >>> * @io_region: MMIO region to input/output I/O arguments/results > > >>> + * @io_mutex: protect against concurrent update of I/O structures > > >> > > >> We could be a bit more specific about what does this mutex guard. > > >> Is it only io_region, or cp, irb and the new regions a well? ->state does > > >> not seem to be covered, but should need some sort of synchronisation > > >> too, or? > > > > > > I'm not sure. IIRC Pierre had some ideas about locking in the fsm? > > > > > > > Yes I postponed this work to not collide with your patch series. > > > > Do you think I should provide a new version of the FSM reworking series > > based on the last comment I got? > > > > I would take into account that the asynchronous commands will come with > > your patch series and only provide the framework changes. > > This was more an answer to Halil's concerns around state > synchronization. I would prefer to first get this series (or a > variation) into decent shape, and then address state machine handling > on top of that (when we know more about the transitions involved), just > to avoid confusion. > > Does that sound reasonable? > I would like the two hitting the same kernel release. In that case I'm fine with deferring some of the concurrency fixes after the csch/hsch stuff. Otherwise I would have a bad feeling about increasing the complexity without fixing known bugs. Regards, Halil
