[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/2] libxl/devd: fix a race with concurrent device addition/removal
Roger Pau Monne writes ("[PATCH v2 1/2] libxl/devd: fix a race with concurrent device addition/removal"): > Current code can free the libxl__device inside of the libxl__ddomain_device > before the addition has finished if a removal happens while an addition is > still in process: ... > Fix this by creating a temporary copy of the libxl__device, that's > tracked by the GC of the nested async operation. This ensures that > the libxl__device used by the async operations cannot be freed while > being used. ... > GCNEW(aodev); > libxl__prepare_ao_device(ao, aodev); > - aodev->dev = dev; > + /* > + * Clone the libxl__device to avoid races if remove_device is called > + * before the device addition has finished. > + */ > + GCNEW(aodev->dev); > + *aodev->dev = *dev; This does conveniently disentangle the memory management, so I think it's a good approach. But it reads kind of oddly to me. I think it is not buggy, but can you add a comment to the definition of libxl__device, saying that it is a transparent structure containing no external memory references ? Otherwise this copy is not really justifiable, because in C, in general, structs might contain private fields, or memory references or linked list entries or something. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |