Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Double free / refcount underflow on the global static `dma_fence_stub` in `unwrap_merge_complex()`. --
commit 361d06ca0291c480e1aafadac1b89e324d9431ab Author: WenTao Liang <[email protected]> fix: dma-buf: unwrap_merge_complex: dma_fence_get_stub reference leaked on all paths This commit fixes a reference leak on the global stub fence in unwrap_merge_complex() by adding dma_fence_put() calls to the success and error paths. > diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c > b/drivers/dma-buf/st-dma-fence-unwrap.c > --- a/drivers/dma-buf/st-dma-fence-unwrap.c > +++ b/drivers/dma-buf/st-dma-fence-unwrap.c [ ... ] > @@ -530,8 +531,10 @@ static int unwrap_merge_complex(void *arg) > err = -EINVAL; > } > > + dma_fence_put(stub); > dma_fence_put(f5); > -error_put_f4: > +error_put_stub: > + dma_fence_put(stub); [Severity: Medium] Does this cause a double-put of the stub on the success path? When unwrap_merge_complex() successfully completes, it appears execution will call dma_fence_put(stub) just before putting f5, and then fall right through into the error_put_stub label where it calls dma_fence_put(stub) a second time. Since dma_fence_get_stub() only acquires a single reference, putting it twice would underflow the refcount and trigger dma_fence_release(). This could result in an attempt to call kfree_rcu() on the statically allocated dma_fence_stub global variable, causing a panic during the selftest. Would it be better to only place dma_fence_put(stub) after the error_put_stub label, allowing the success path to fall through and clean it up once naturally along with the other fences? > dma_fence_put(f4); > error_put_f3: > dma_fence_put(f3); -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
