qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [PATCH v3 1/6] vfio-ccw: make it safe to access channel


From: Cornelia Huck
Subject: Re: [qemu-s390x] [PATCH v3 1/6] vfio-ccw: make it safe to access channel programs
Date: Mon, 4 Feb 2019 16:31:02 +0100

On Thu, 31 Jan 2019 13:34:55 +0100
Halil Pasic <address@hidden> wrote:

> On Thu, 31 Jan 2019 12:52:20 +0100
> Cornelia Huck <address@hidden> wrote:
> 
> > On Wed, 30 Jan 2019 19:51:27 +0100
> > Halil Pasic <address@hidden> wrote:
> >   
> > > On Wed, 30 Jan 2019 14:22:07 +0100
> > > Cornelia Huck <address@hidden> wrote:
> > >   
> > > > When we get a solicited interrupt, the start function may have
> > > > been cleared by a csch, but we still have a channel program
> > > > structure allocated. Make it safe to call the cp accessors in
> > > > any case, so we can call them unconditionally.    
> > > 
> > > I read this like it is supposed to be safe regardless of
> > > parallelism and threads. However I don't see any explicit
> > > synchronization done for cp->initialized.
> > > 
> > > I've managed to figure out how is that supposed to be safe
> > > for the cp_free() (which is probably our main concern) in
> > > vfio_ccw_sch_io_todo(), but if fail when it comes to the one
> > > in vfio_ccw_mdev_notifier().
> > > 
> > > Can you explain us how does the synchronization work?  
> > 
> > You read that wrong, I don't add synchronization, I just add a check.
> >   
> 
> Now I'm confused. Does that mean we don't need synchronization for this?

If we lack synchronization (that is not provided by the current state
machine handling, or the rework here), we should do a patch on top
(preferably on top of the whole series, so this does not get even more
tangled up.) This is really just about the extra check.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]