Bug 95035

Summary: Gallium OSMesa driver is far from being thread-safe
Product: Mesa Reporter: Frederic Devernay <frederic.devernay>
Component: Drivers/OSMesaAssignee: mesa-dev
Status: RESOLVED MOVED QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: frederic.devernay
Version: 11.2   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: patch for Mesa-11.2.0
patch for Mesa-11.1.2
patch for Mesa-11.2.0, v2
patch for Mesa-11.1.2, v2
patch for Mesa-11.2.0, v3
patch for Mesa-11.1.2, v3
patch for Mesa-11.1.2, v3

Description Frederic Devernay 2016-04-20 17:31:08 UTC
see src/gallium/state_trackers/osmesa/osmesa.c

There are at least three global variables with no protection:
- stapi in get_st_api()
- stmgr in get_st_manager()
- BufferList

Consequently:
- OSMesaCreateContext cannot be called simultaneously from two threads
- OSMesaMakeCurrent called from two threads with the same buffer attribs will share the same element in BufferList, and thus render to the same memory!

My guess is that these two objects should simply be stored in the context itself, but I cannot foresee the consequences.

For example, will shared display lists still work?

I am willing to help on solving this (we use OSMesa in highly multithreaded application).
Comment 1 Frederic Devernay 2016-04-21 09:01:19 UTC
Created attachment 123108 [details] [review]
patch for Mesa-11.2.0

Add proposed patch for Mesa 11.2.0, please review
Comment 2 Frederic Devernay 2016-04-21 09:01:52 UTC
Created attachment 123109 [details] [review]
patch for Mesa-11.1.2
Comment 3 Roland Scheidegger 2016-04-21 13:00:38 UTC
I'm not really sure about that. It is possible this was intended for multiple contexts rendering to the same buffer (as is possible with "ordinary" GL), which won't work with this. Though you are certainly right that it's impossible to use multiple buffers right now from different contexts.
As for multiple screens, I'm not quite sure why one wouldn't do? Albeit might need some mutex protection?
I don't really know anything about osmesa though nor why people still use it, Brian would be the person to ask how it's supposed to work.
Comment 4 Chuck Atkins 2016-04-21 13:10:32 UTC
> I don't really know anything about osmesa though nor why people still use
> it

We use OSMesa extensively for rendering on headless servers with no GPUs.  It's *MUCH* better than dealing with having to start up an X server and use GLX.  EGL is in the planned transition but it doesn't quite work yet with a software-only no-X configuration, at least not that I've been able to configure :-(.  Off topic for this bug though.
Comment 5 Frederic Devernay 2016-04-21 14:28:40 UTC
OK, there was another issue, which actually may affect other Gallium drivers as well: 

st_framebuffer_reuse_or_create() uses pointer comparison to check if it can reuse a framebuffer.

The problem is that a call to free followed by a call to malloc may very well return the exact same pointer! Pointer comparison should be used as a safe check but is very unreliable.

The consequence is that osmesa_st_framebuffer_validate() was not called and the textures were not allocated, even though the osbuffer was just allocated.

I added a fix which explicitely sets st->ctx->WinSysDrawBuffer and st->ctx->WinSysReadBuffer to NULL, so that the framebuffer is reallocated and framebuffer_validate() is always called.

This is in the second version of the patch set.
Comment 6 Frederic Devernay 2016-04-21 14:30:08 UTC
Created attachment 123120 [details] [review]
patch for Mesa-11.2.0, v2
Comment 7 Frederic Devernay 2016-04-21 14:30:42 UTC
Created attachment 123121 [details] [review]
patch for Mesa-11.1.2, v2
Comment 8 Roland Scheidegger 2016-04-21 15:09:13 UTC
(In reply to Frederic Devernay from comment #5)
> OK, there was another issue, which actually may affect other Gallium drivers
> as well: 
> 
> st_framebuffer_reuse_or_create() uses pointer comparison to check if it can
> reuse a framebuffer.
> 
> The problem is that a call to free followed by a call to malloc may very
> well return the exact same pointer! Pointer comparison should be used as a
> safe check but is very unreliable.

Yes, I think this is the same issue as originally reported here:
https://bugs.chromium.org/p/chromium/issues/detail?id=395818
Comment 9 Frederic Devernay 2016-04-21 15:45:16 UTC
Created attachment 123123 [details] [review]
patch for Mesa-11.2.0, v3

add a trivial check in osmesa_destroy_buffer (in case context is destroy before being made current)
Comment 10 Frederic Devernay 2016-04-21 15:45:53 UTC
Created attachment 123124 [details]
patch for Mesa-11.1.2, v3

add a trivial check in osmesa_destroy_buffer (in case context is destroyed before being made current)
Comment 11 Frederic Devernay 2016-04-21 15:46:44 UTC
Created attachment 123125 [details] [review]
patch for Mesa-11.1.2, v3

add a trivial check in osmesa_destroy_buffer (in case context is destroyed before being made current)
Comment 12 Emil Velikov 2016-11-24 13:39:02 UTC
Hi Frederic, please send your patches to the ML for review[1].

[1] http://mesa3d.org/devinfo.html#submitting
Comment 13 GitLab Migration User 2019-09-18 20:12:46 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/880.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.