Created attachment 129030 [details]
gdb script to verify use after free
Our application enables and disables GL_POLYGON_OFFSET_FILL multiple times per frame, and it has been crashing on Ubuntu 16.04. (We are aware that our usage pattern is probably not ideal.) We believe the crash is occurring because the radeonsi driver is using the memory pointed to by si_context->queued.named.poly_offset after it has been freed.
We have verified the use after free behavior by running the attached gdb script against the master branch (commit 1e1bddf15a1720917b11e44dc639351ad613c3dc). Unfortunately we are not yet able to provide a sample application to run this against.
The following scenario may not be completely accurate, but hopefully it should give a feel for the sequence of events leading up to this issue:
* sets pipe_rasterizer_state->offset_tri to true
* callocs rasterizer A
* sets A->uses_poly_offset to true because pipe_rasterizer_state->offset_tri is true
* changes si_context->queued.named.rasterizer to rasterizer A
* calls si_update_poly_offset_state to make queued.named.poly_offset point into rasterizer A
* sets pipe_rasterizer_state->offset_tri to false
* callocs rasterizer B
* sets B->uses_poly_offset to false because pipe_rasterizer_state->offset_tri is false
* changes the rasterizer to rasterizer B
* calls si_update_poly_offset_state to make sure poly_offset is up to date
* sets rs to si_context.queued.named.rasterizer, which is B
* returns without updating poly_offset because B->uses_poly_offset is false
* poly_offset still points into rasterizer A
* does NOT set poly_offset to NULL because queued.named.rasterizer no longer points to rasterizer A
* frees rasterizer A via si_pm4_delete_state
* calls si_pm4_emit_dirty
* follows poly_offset into rasterizer A, which has been freed
* bad things happen
The patch attached below ensures si_update_poly_offset sets poly_offset to NULL if uses_poly_offset is false. We think this makes sense because it always leaves poly_offset in a valid state. Either it points into the currently queued rasterizer, or it is NULL. If this does turn out to be the correct fix, the attempt to NULL poly_offset from si_delete_rs_state should probably be removed as well.
Created attachment 129031 [details] [review]
Created attachment 129032 [details] [review]
Thanks for the clear report and fix. I've cleaned up the commit message slightly and pushed it to master, commit d7d32b3bfe86bd89d94d59393907bce1cb9dab7c.