Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Unchecked ERR_PTR and dangling pointers from drm_gem_huge_mnt_create cause catastrophic GEM allocation failures or Use-After-Free. -- commit cb4549ef63304d3139dafdf100bc5423a484100d Author: Rob Clark <[email protected]> drm/msm: Enable THP for GEM buffers This patch enables Transparent Hugepage (THP) support for GEM buffers in the MSM DRM driver by introducing a module parameter and initializing it during device setup. > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c > index db1b655dd055b..b96bad6e154a6 100644 > --- a/drivers/gpu/drm/msm/msm_drv.c > +++ b/drivers/gpu/drm/msm/msm_drv.c > @@ -58,9 +58,31 @@ static bool separate_gpu_kms; [ ... ] > +static void msm_gem_thp_init(struct drm_device *dev) > +{ > + int err; > + > + if (!transparent_hugepage) > + return; > + > + err = drm_gem_huge_mnt_create(dev, "within_size"); > + if (drm_gem_get_huge_mnt(dev)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [Severity: High] This is a pre-existing issue, but does this correctly handle error returns from drm_gem_huge_mnt_create()? If drm_gem_huge_mnt_create() fails, it can leave an ERR_PTR or a dangling pointer in dev->huge_mnt. Because this code evaluates the truthiness of drm_gem_get_huge_mnt(dev) before checking the err variable, it will evaluate to true for these error pointers and falsely indicate success. Later, when drm_gem_object_init() passes this invalid pointer to shmem_file_setup_with_mnt(), it can lead to a use-after-free or continuous allocation failures. Should this code check for IS_ERR() or check the err variable first before assuming the mount was successful? > + drm_info(dev, "Using Transparent Hugepage\n"); > + else if (err) > + drm_warn(dev, "Can't use Transparent Hugepage (%d)\n", err); > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
