kernel/linux.git/drivers/gpu/drm/drm_drv.c, branch v5.10.263

drm/drv: propagate errors from drm_modeset_register_all()

2024-01-25T22:37:47+00:00

[ Upstream commit 5f8dec200923a76dc57187965fd59c1136f5d085 ] In case the drm_modeset_register_all() function fails, its error code will be ignored. Instead make the drm_dev_register() bail out in case of such an error. Fixes: 79190ea2658a ("drm: Add callbacks for late registering") Reviewed-by: Neil Armstrong Signed-off-by: Dmitry Baryshkov Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20231202225552.1283638-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin

drm/drv: Fix potential memory leak in drm_dev_init()

2022-11-25T16:45:44+00:00

[ Upstream commit ff963634f7b2e0dc011349abb3fb81a0d074f443 ] drm_dev_init() will add drm_dev_init_release() as a callback. When drmm_add_action() failed, the release function won't be added. As the result, the ref cnt added by device_get() in drm_dev_init() won't be put by drm_dev_init_release(), which leads to the memleak. Use drmm_add_action_or_reset() instead of drmm_add_action() to prevent memleak. unreferenced object 0xffff88810bc0c800 (size 2048): comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s) hex dump (first 32 bytes): e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................ 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<............. backtrace: [<000000007251f72d>] __kmalloc+0x4b/0x1c0 [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0 [<000000004452a479>] platform_device_register_full+0x24/0x1c0 [<0000000089f4ea61>] 0xffffffffa0736051 [<00000000235b2441>] do_one_initcall+0x7a/0x380 [<0000000001a4a177>] do_init_module+0x5c/0x230 [<000000002bf8a8e2>] load_module+0x227d/0x2420 [<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140 [<00000000c99fc324>] do_syscall_64+0x3f/0x90 [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 2cbf7fc6718b ("drm: Use drmm_ for drm_dev_init cleanup") Signed-off-by: Shang XiaoJing Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20221101070716.9189-2-shangxiaojing@huawei.com Signed-off-by: Sasha Levin

drm: fix null-ptr-deref in drm_dev_init_release()

2022-01-27T09:53:44+00:00

[ Upstream commit acf20ed020ffa4d6cc8347e8d356509b95df3cbe ] I got a null-ptr-deref report: [drm:drm_dev_init [drm]] *ERROR* Cannot allocate anonymous inode: -12 ================================================================== BUG: KASAN: null-ptr-deref in iput+0x3c/0x4a0 ... Call Trace: dump_stack_lvl+0x6c/0x8b kasan_report.cold+0x64/0xdb __asan_load8+0x69/0x90 iput+0x3c/0x4a0 drm_dev_init_release+0x39/0xb0 [drm] drm_managed_release+0x158/0x2d0 [drm] drm_dev_init+0x3a7/0x4c0 [drm] __devm_drm_dev_alloc+0x55/0xd0 [drm] mi0283qt_probe+0x8a/0x2b5 [mi0283qt] spi_probe+0xeb/0x130 ... entry_SYSCALL_64_after_hwframe+0x44/0xae If drm_fs_inode_new() fails in drm_dev_init(), dev->anon_inode will point to PTR_ERR(...) instead of NULL. This will result in null-ptr-deref when drm_fs_inode_free(dev->anon_inode) is called. drm_dev_init() drm_fs_inode_new() // fail, dev->anon_inode = PTR_ERR(...) drm_managed_release() drm_dev_init_release() drm_fs_inode_free() // access non-existent anon_inode Define a temp variable and assign it to dev->anon_inode if the temp variable is not PTR_ERR. Fixes: 2cbf7fc6718b ("drm: Use drmm_ for drm_dev_init cleanup") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20211013114139.4042207-1-wanghai38@huawei.com Signed-off-by: Sasha Levin

drm/dev: Remove drm_dev_init

2020-09-21T08:45:08+00:00

We can now also delete drm_dev_init, now that vkms, vgem and i915 selftests are resolved. Reviewed-by: Thomas Zimmermann Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200918132505.2316382-5-daniel.vetter@ffwll.ch

drm/managed: Cleanup of unused functions and polishing docs

2020-09-03T14:25:06+00:00

Following functions are only used internally, not by drivers: - devm_drm_dev_init Also, now that we have a very slick and polished way to allocate a drm_device with devm_drm_dev_alloc, update all the docs to reflect the new reality. Mostly this consists of deleting old and misleading hints. Two main ones: - it is no longer required that the drm_device base class is first in the structure. devm_drm_dev_alloc can cope with it being anywhere - obviously embedded now strongly recommends using devm_drm_dev_alloc v2: Fix typos (Noralf) v3: Split out the removal of drm_dev_init, that's blocked on some discussions on how to convert vgem/vkms/i915-selftests. Adjust commit message to reflect that. Cc: Noralf Trønnes Acked-by: Noralf Trønnes (v2) Acked-by: Sam Ravnborg Cc: Luben Tuikov Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200902072627.3617301-1-daniel.vetter@ffwll.ch

drm: Remove redundant NULL check

2020-07-27T20:06:13+00:00

Fix below warnings reported by coccicheck: ./drivers/gpu/drm/drm_drv.c:819:2-7: WARNING: NULL check before some freeing functions is not needed. Fixes: 5dad34f3c444 ("drm: Cleanups after drmm_add_final_kfree rollout") Signed-off-by: Li Heng Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1595474863-33112-1-git-send-email-liheng40@huawei.com

drm: Add devm_drm_dev_alloc macro

2020-04-28T13:05:19+00:00

Add a new macro helper to combine the usual init sequence in drivers, consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree triplet. This allows us to remove the rather unsightly drmm_add_final_kfree from all currently merged drivers. The kerneldoc is only added for this new function. Existing kerneldoc and examples will be udated at the very end, since once all drivers are converted over to devm_drm_dev_alloc we can unexport a lot of interim functions and make the documentation for driver authors a lot cleaner and less confusing. There will be only one true way to initialize a drm_device at the end of this, which is going to be devm_drm_dev_alloc. v2: - Actually explain what this is for in the commit message (Sam) - Fix checkpatch issues (Sam) Acked-by: Noralf Trønnes Cc: Noralf Trønnes Reviewed-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Paul Kocialkowski Cc: Laurent Pinchart Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-2-daniel.vetter@ffwll.ch

drm: Fix wrong kfree() in managed resource usage example

2020-04-02T11:04:57+00:00

The example code showing how to use the managed resource API calls kfree() on the wrong pointer. Fix it. Signed-off-by: Laurent Pinchart Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200402095325.5266-1-laurent.pinchart+renesas@ideasonboard.com

drm: Add docs for managed resources

2020-03-26T15:09:48+00:00

All collected together to provide a consistent story in one patch, instead of the somewhat bumpy refactor-evolution leading to this. Also some thoughts on what the next steps could be: - Create a macro called devm_drm_dev_alloc() which essentially wraps the kzalloc(); devm_drm_dev_init(); drmm_add_final_kfree() combo. Needs to be a macro since we'll have to do some typeof trickery and casting to make this fully generic for all drivers that embed struct drm_device into their own thing. - A lot of the simple drivers now have essentially just drm_dev_unplug(); drm_atomic_helper_shutdown(); as their $bus_driver->remove hook. We could create a devm_mode_config_reset which sets drm_atomic_helper_shutdown as it's cleanup action, and a devm_drm_dev_register with drm_dev_unplug as it's cleanup action, and simple drivers wouldn't have a need for a ->remove function at all, and we could delete them. - For more complicated drivers we need drmm_ versions of a _lot_ more things. All the userspace visible objects (crtc, plane, encoder, crtc), anything else hanging of those (maybe a drmm_get_edid, at least for panels and other built-in stuff). Also some more thoughts on why we're not reusing devm_ with maybe a fake struct device embedded into the drm_device (we can't use the kdev, since that's in each drm_minor). - Code review gets extremely tricky, since every time you see a devm_ you need to carefully check whether the fake device (with the drm_device lifetim) or the real device (with the lifetim of the underlying physical device and driver binding) are used. That's not going to help at all, and we have enormous amounts of drivers who use devm_ where they really shouldn't. Having different types makes sure the compiler type checks this for us and ensures correctness. - The set of functions are very much non-overlapping. E.g. devm_ioremap makes total sense, drmm_ioremap has the wrong lifetime, since hw resources need to be cleaned out at driver unbind and wont outlive that like a drm_device. Similar, but other way round for drmm_connector_init (which is the only correct version, devm_ for drm_connector is just buggy). Simply not having the wrong version again prevents bugs. Finally I guess this opens a huge todo for all the drivers. I'm semi-tempted to do a tree-wide s/devm_kzalloc/drmm_kzalloc/ since most likely that'll fix an enormous amount of bugs and most likely not cause any issues at all (aside from maybe holding onto memory slightly too long). v2: - Doc improvements from Laurent. - Also add kerneldoc for the new drmm_add_action_or_reset. v3: - Remove kerneldoc for drmm_remove_action. Reviewed-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Cc: Laurent Pinchart Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Signed-off-by: Daniel Vetter fixup docs Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-52-daniel.vetter@ffwll.ch

drm: Manage drm_mode_config_init with drmm_

2020-03-26T14:45:43+00:00

drm_mode_config_cleanup is idempotent, so no harm in calling this twice. This allows us to gradually switch drivers over by removing explicit drm_mode_config_cleanup calls. With this step it's now also possible that (at least for simple drivers) automatic resource cleanup can be done correctly without a drm_driver->release hook. Therefore allow this now in devm_drm_dev_init(). Also with drmm_ explicit drm_driver->release hooks are kinda not the best option: Drivers can always just register their current release hook with drmm_add_action, but even better they could split them up to simplify the unwinding for the driver load failure case. So deprecate that hook to discourage future users. v2: Fixup the example in the kerneldoc too. v3: - For paranoia, double check that minor->dev == dev in the release hook, because I botched the pointer math in the drmm library. - Call drm_mode_config_cleanup when drmm_add_action fails, we'd be missing some mutex_destroy and ida_cleanup otherwise (Laurent) v4: Add a drmm_add_action_or_reset (like devm_ has) to encapsulate this pattern (Noralf). v5: Fix oversight in the new drmm_add_action_or_reset macro (Noralf) v4: Review from Sam: - drmm_mode_config_init wrapper (also suggested by Thomas) - improve commit message, explain better why ->relase is deprecated v5: - Make drmm_ the main function, with the old one as compat wrapper (Sam) - Add FIXME comments to drm_mode_config_cleanup/init() that drivers shouldn't use these anymore. - Move drmm_add_action_or_reset helper to an earlier patch. Reviewed-by: Sam Ravnborg Cc: Laurent Pinchart Cc: "Noralf Trønnes" Cc: Sam Ravnborg Cc: Thomas Zimmermann Acked-by: Noralf Trønnes Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-27-daniel.vetter@ffwll.ch