[PATCH 1/4] drm/plane: Make init functions panic consitently and explicitly

Maxime Ripard mripard at kernel.org
Thu Dec 7 13:05:37 UTC 2023


On Thu, Dec 07, 2023 at 12:18:13PM +0200, Jani Nikula wrote:
> On Wed, 06 Dec 2023, Maxime Ripard <mripard at kernel.org> wrote:
> > All of the current plane init / allocation functions behave slightly
> > differently when it comes to argument sanitizing:
> >
> >  - drm_universal_plane_init() implicitly panics if the drm_device
> >    pointer or the drm_plane_funcs pointer are NULL, and calls WARN_ON if
> >    there's no destroy implementation but goes on with the initialization.
> >
> >  - drm_universal_plane_alloc() implicitly panics if the drm_device
> >    pointer is NULL, and will call WARN_ON and return an error if the
> >    drm_plane_funcs pointer is NULL.
> >
> >  - drmm_universal_plane_alloc() implicitly panics if the drm_device
> >    pointer is NULL, and will call WARN_ON and return an error if the
> >    drm_plane_funcs pointer is NULL or if there is a destroy
> >    implementation.
> 
> NULL deref oopses but doesn't necessarily panic, right? Adding BUG() or
> BUG_ON() to unconditionally panic is not the way to go, either.

Sigh...

Your whole argument was that it was a precondition, and what the current
code was doing is just like an assertion. An assertion will stop the
execution of the program it's in.

If panicking isn't the way to go, then what is?

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20231207/4ccdb9b8/attachment.sig>


More information about the dri-devel mailing list