On Tue, 5 Jun 2018 15:10:11 +0200
Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote:
On 05/06/2018 13:38, Cornelia Huck wrote:But wouldn't that imply that you need to either take the mutex if you
On Fri, 25 May 2018 12:21:14 +0200yes to all
Pierre Morel <pmorel@xxxxxxxxxxxxxxxxxx> wrote:
We use mutex around the FSM function call to make the FSMI'm still not really clear as to what this mutex is supposed to
event handling and state change atomic.
- Modification of the state?
- Any calls in the state machine?
- A combination? (That would imply that we only deal with the state in
the state machine.)
do something dependent on the state, or fire an event in that case?
So, should that go into another patch?It is moved to fsm_irq() which is called under mutex.Signed-off-by: Pierre Morel <pmorel@xxxxxxxxxxxxxxxxxx>Looks like an unrelated change? If you want to do all state changes
drivers/s390/cio/vfio_ccw_drv.c | 3 +--
drivers/s390/cio/vfio_ccw_private.h | 3 +++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 6b7112e..98951d5 100644
@@ -73,8 +73,6 @@ static void vfio_ccw_sch_io_todo(struct work_struct *work)
private = container_of(work, struct vfio_ccw_private, io_work);
- if (private->mdev)
- private->state = VFIO_CCW_STATE_IDLE;
under the mutex, that should rather be moved than deleted, shouldn't it?
fsm_irq() returns VFIO_CCW_STATE_IDLE.