Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues: - [High] Missing `of_node_put()` for the device node returned by `of_get_available_child_by_name()` causes a reference leak. - [High] Unratelimited log spam and invalid `-EPROBE_DEFER` return to userspace on DRM open. -- --- Patch [1]: [REGRESSION] qcom PAS TZ API migration breaks GPU and modem on TrustZone without PAS (sc7180 trogdor) --- commit d49d60f9528ef181555257c9db8b08e995f71893 Author: Paul Hollinsky <[email protected]> qcom PAS TZ API migration breaks GPU and modem on TrustZone without PAS (sc7180 trogdor) This commit fixes boot failures on SC7180 Chromebooks caused by a recent TZ API migration. It restores SCM availability checks for the modem and delays the PAS check for the GPU until after discovering the zap-shader device tree node. > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c > index 8cd2020d4b7e9..ca5e4e560cded 100644 > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c > @@ -52,6 +52,12 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const > char *fwname, > return -ENODEV; > } > > + /* We need PAS to be able to load the firmware */ > + if (!qcom_pas_is_available()) { > + DRM_DEV_ERROR(dev, "PAS is not available\n"); > + return -EPROBE_DEFER; > + } > + > ret = of_reserved_mem_region_to_resource(np, 0, &r); [Severity: High] This is a pre-existing issue, but does this early return in zap_shader_load_mdt() leak the device node reference? The np pointer is obtained via of_get_available_child_by_name() just before this block, which increments the reference count. However, of_node_put(np) is never called before returning -EPROBE_DEFER. Because zap_available remains true, an unprivileged user can repeatedly open the DRM device and trigger this error path on every call. Can this result in an unbounded device node reference leak? [Severity: High] This is also a pre-existing issue, but does this unratelimited DRM_DEV_ERROR in zap_shader_load_mdt() allow an unprivileged user to spam the kernel log by repeatedly calling the DRM open syscall? Furthermore, is it appropriate to return -EPROBE_DEFER here? Since this function is reached during the DRM open syscall and not during the device probe sequence, this propagates an internal driver core deferral code directly to userspace. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
