Claude review: dma-buf: fix order of trace and fput

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**The bug (confirmed):** The `DMA_BUF_TRACE` macro (defined at `drivers/dma-buf/dma-buf.c:47`) acquires `dmabuf->name_lock` and then the tracepoint itself accesses `dmabuf->exp_name`, `dmabuf->size`, and `dmabuf->file->f_inode->i_ino`. Calling this after `fput()` is a use-after-free if that `fput()` drops the last reference, since the file's release callback will free the dma-buf.

**The fix is correct:**

```diff
-	fput(dmabuf->file);
-
 	DMA_BUF_TRACE(trace_dma_buf_put, dmabuf);
+	fput(dmabuf->file);
```

Moving the trace before `fput()` ensures the dmabuf and its file are still alive when the tracepoint accesses their fields. The `WARN_ON(!dmabuf || !dmabuf->file)` guard above already validates both pointers before we reach this code.

**Tag issue:** The commit message uses `Fixed:` but the standard kernel tag is `Fixes:` (with an 's'). This should be corrected:

```
Fixed: 281a22631423 ("dma-buf: add some tracepoints to debug.")
```
should be:
```
Fixes: 281a22631423 ("dma-buf: add some tracepoints to debug.")
```

Scripts like `scripts/checkpatch.pl` and automated stable-kernel backport tooling rely on the `Fixes:` tag being spelled correctly.

**Minor note:** The commit message says "Only compile tested!" — this is appreciated transparency, but given how straightforward the reordering is, the fix is clearly correct by inspection. The tracepoint just needs to read fields before they're potentially freed; there's no subtle ordering dependency in the other direction (the trace doesn't need to observe post-fput state).

**Verdict:** The fix itself is good — one clear use-after-free fixed with a minimal, obviously-correct reordering. Just fix `Fixed:` → `Fixes:` before applying.

---
Generated by Claude Code Patch Reviewer