diff options
| author | Lucas De Marchi <lucas.demarchi@intel.com> | 2019-11-15 17:15:39 -0800 |
|---|---|---|
| committer | Lucas De Marchi <lucas.demarchi@intel.com> | 2019-11-18 13:27:09 -0800 |
| commit | ac4eead3796579bdadd12e2fa99c4ddc920eda30 (patch) | |
| tree | de35c9ccbcf48b1aeaeb9c9536c99dd7ac3e3ce1 /tools/perf/scripts | |
| parent | c50bb4dd1fa52fb58274609afc415fcbd9ee6264 (diff) | |
| download | linux-ac4eead3796579bdadd12e2fa99c4ddc920eda30.tar.gz linux-ac4eead3796579bdadd12e2fa99c4ddc920eda30.zip | |
drm/i915/dsb: remove atomic operations
The current dsb API is not really prepared to handle multithread access.
I was debugging an issue that ended up fixed by commit a096883dda2c
("drm/i915/dsb: Remove PIN_MAPPABLE from the DSB object VMA") and was
puzzled how these atomic operations were guaranteeing atomicity.
if (atomic_add_return(1, &dsb->refcount) != 1)
return dsb;
Thread A could still be initializing dsb struct (and even fail in the
middle) while thread B would take a reference and use it (even
derefencing a NULL cmd_buf).
I don't think the atomic operations here will help much if this were
to support multithreaded scenario in future, so just remove them to
avoid confusion.
v2: Use refcount++ != 0 instead of ++refcount != 1 (from Ville)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111205024.22853-2-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20191116011539.18230-1-lucas.demarchi@intel.com
Diffstat (limited to 'tools/perf/scripts')
0 files changed, 0 insertions, 0 deletions
