Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [Medium] DMA buffers for GSP logging (`gsp->libos`) and boot firmware (`gsp->boot.fw`) are leaked on the initialization error path. -- --- Patch [2]: [PATCH 2/6] nouveau/gsp: make libos init per-gsp version. --- commit 85ebb9d2d6335df98fac564dbbe77909c7d38c2b Author: Dave Airlie <[email protected]> nouveau/gsp: make libos init per-gsp version. This makes libos initialization a per-gsp version feature. It adds r570 as a copy of r535 for now, with enhancements to r570 expected next. > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c > index 996941c668ba9..64011430f4c0a 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c [ ... ] > @@ -205,8 +205,76 @@ r570_gsp_set_rmargs(struct nvkm_gsp *gsp, bool resume) [ ... ] > +/** > + * r570_gsp_libos_init() -- create the libos arguments structure > + * @gsp: gsp pointer > + */ > +static int > +r570_gsp_libos_init(struct nvkm_gsp *gsp) > +{ > + LibosMemoryRegionInitArgument *args; > + int ret; > + > + ret = nvkm_gsp_mem_ctor(gsp, 0x1000, &gsp->libos); [Severity: Medium] This is a pre-existing issue, but does this leak the gsp->libos and gsp->boot.fw DMA buffers on the initialization error path? If GSP initialization fails after libos_init is called but before postinit executes (for example, if set_system_info or RPC registry configuration fails), the initialization falls back to tearing down the subdevice via r535_gsp_dtor(). While postinit frees these buffers on a successful boot, r535_gsp_dtor() appears to skip freeing gsp->libos and gsp->boot.fw when cleaning up on the error path. > + if (ret) > + return ret; > + > + args = gsp->libos.data; > + > + ret = gsp_fill_libos_entry(gsp, &args[0], 0x10000, &gsp->loginit, > "LOGINIT"); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
