[Xen-devel] Re: [PATCH 0 of 3] xl: free allocations made at top level

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("[Xen-devel] Re: [PATCH 0 of 3] xl: free allocations made 
at top level"):
> This seems to work. I'm not entirely sure about it though -- it's not
> clear what happens if the thread which calls xc_interface_close is not
> the final thread to exit and whether we would still leak the buffer from
> the thread which does the final exit() call.

Yers.  We don't impose a requirement that the thread that calls
xc_interface_open has to be the one which calls _close, so you can
still leak the buffer from the original thread.

OTOH if you don't want memory leaks you do need to do
xc_interface_close.  So perhaps we should have a reference count or
something ?  Is it even possible to destroy thread-specific data for
another thread ?


Also, while I was reading this code I noticed this:

    pthread_once(&hcall_buf_pkey_once, _xc_init_hcall_buf);

and:

    static void _xc_init_hcall_buf(void)
    {
        pthread_key_create(&hcall_buf_pkey, _xc_clean_hcall_buf);
    }

It seems to me that this is possibly racy, if two threads call
hcall_buf_prep simultaneously for the first time (which is not at all
implausible in some possible scenarios).  pthread_once doesn't seem to
guarantee that the first two calls arrive at once, the 2nd call
doesn't return before the first call has even entered the user
function.  So the thread which loses the race can read an
uninitialised hcall_buf_pkey.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel