ub: ubmad: do not release a tjetty the retransmission work never found · Pull Request !1139 · OpenCloudOS/OpenCloudOS-Kernel

## Problem

`ubmad_rt_work_handler()` looks the target jetty up with `ubmad_get_tjetty()`,
tolerates a failed lookup when it releases the initial retransmission buffer,
and then drops the reference unconditionally:

```c
	if (!IS_ERR_OR_NULL(tjetty))
		ubmad_release_ini_rtbuffer(tjetty, rt_work->msn);
	...
	ubmad_put_tjetty(tjetty);
```

`ubmad_get_tjetty()` returns `NULL` when the peer's jetty is no longer in the
hash, which is expected for this delayed work: the tjetty can be removed by a
close request while the retransmission is still queued. `ubmad_put_tjetty()`
dereferences its argument (`kref_put(&tjetty->kref, ...)`), so the NULL case
faults inside the workqueue handler instead of finishing the work.

The other two call sites of `ubmad_get_tjetty()` in the same file that can fail
(`ubmad_jetty_work_handler()`, and the lookup in `ubmad_do_post_send()`) already
guard their put.

## Fix

Use the same `IS_ERR_OR_NULL()` check for the put that the buffer release above
uses.

## Verification

- `scripts/checkpatch.pl --no-signoff --strict`: 0 errors, 0 warnings.
- arm64 build (`CONFIG_UB=y` + `CONFIG_UB_URMA=y`, target `drivers/ub/urma/ubcore/`, Bootlin aarch64 gcc 15.3.0, `W=1`): baseline and patched trees both build with exit 0, all 24 objects force-recompiled in both cases, and both show the same 5 pre-existing `-Wmissing-prototypes` warnings in `ubcore_connect_adapter.c`; no new diagnostics.
- Not run: runtime test. No UB hardware is available in the development environment, and the path needs a close request to race a queued retransmission.

Type	Assign personnel	Status
Reviewer	zoucao Huang Cun Jianping Liu	Completed (0/0 )
Tester	Jianping Liu	Completed (0/0 )

GVPOpenCloudOS / OpenCloudOS-Kernel

Search

GVP OpenCloudOS / OpenCloudOS-Kernel