[PATCH v2 0/2] scsi: ufs: fix an RPMB teardown cycle and a shift UB

[shao.mingyin]

Two independent fixes in the UFS stack, found while reading the probe and
remove paths and the task-management hooks.

Patch 1 is in the core RPMB glue.  ufs_rpmb_probe() registers a child
device whose parent is the RPMB device, then registers an rpmb_dev on top
of it.  device_add() takes a reference on the parent, and
rpmb_dev_unregister() is only called from ufs_rpmb_device_release(), i.e.
when that reference count drops to zero.  The remove path and the probe
error path call device_unregister() on the child directly, so the
reference held by the rpmb_dev never goes away, the release callback never
runs, and the RPMB child stays registered while the devm-allocated
ufs_rpmb is freed together with the host.  Unregister the rpmb_dev first,
as mmc_blk_remove_rpmb_part() does, and let the release callback tolerate
an already unregistered device.

Patch 2 is in the Exynos host driver.  The nexus type masks are built with
(1 << tag); controllers can expose 32 unified task tags, and tag 31
shifts a 32-bit int into its sign bit.  Commit 01aad16c2257 fixed the
same expression in exynos_ufs_post_link() and noted that the UTMRL access
should be changed as well, but the four remaining mask computations were
missed.

The patches share no code: patch 1 is the core RPMB glue, patch 2 is
confined to the Exynos host hooks, so they can be applied in any order and
need review from different people.  Both carry Fixes: and Cc: stable.

Related work: Dmitry Baryshkov's "scsi: ufs: rpmb: register and unregister
the ufs_rpmb bus" (September 2026) is still under review; the teardown fix
in patch 1 becomes reachable once that patch lands.  Stanley Jhu's earlier
series ("scsi: ufs: rpmb: Fix bus registration and device lifecycle", v3,
September 2026) also calls rpmb_dev_unregister() in ufs_rpmb_remove() to
break the cyclic refcount, but it is not in linux-next as of next-20261030.
This patch is the narrower fix: unregister the rpmb_dev before the child
device and let release tolerate an already unregistered device.

Testing: both apply to v7.4-rc1 (Martin's for-next tip, 6628e7d4c6b2), pass
checkpatch.pl --strict with 0 errors/0 warnings/0 checks, and the two
touched objects build with W=1.

Patch 1 was exercised on QEMU/x86-64 with a synthetic hba and a fake RPMB
WLUN, on top of Dmitry's still unmerged "scsi: ufs: rpmb: register and
unregister the ufs_rpmb bus" patch - without it device_register() fails
with -EINVAL and the teardown path is unreachable.  Before this patch,
ufs_rpmb_remove() leaves the rpmb0 class device registered because the
child device is never released; with it, rpmb0 is gone.

Patch 2 was exercised with a synthetic hook that calls both nexus helpers
with tag 31 in a UBSAN kernel.  The unpatched and the patched code write
the same value (0x80000000), because GCC wraps the undefined signed shift
under -fno-strict-overflow; no runtime symptom was observed, and the
patch is a well-definedness cleanup that matches the BIT() usage added by
01aad16c2257.  There is no Exynos board on this machine, so the driver
itself was not probed.

Changes in v2:
- Rebased onto Martin's for-next (v7.4-rc1, 6628e7d4c6b2).  v1 was generated
  against linux-next next-20261030 (7649ba73f9e7), which is not an ancestor
  of for-next, so the series did not apply there.  No code changes.
- Patch 2: dropped the claim that the shift trips UBSAN.  Testing shows GCC
  wraps it under -fno-strict-overflow, so it is a well-definedness cleanup.
- Refreshed the testing paragraph for the new base.

v1: https://lore.kernel.org/all/20261103185229490gmhePBF5_11x_thf4X-Rw@xxxxxxxxxx/

Signed-off-by: Shao Mingyin <shao.mingyin@xxxxxxxxxx>
---
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4