From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
daniel@ffwll.ch, airlied@gmail.com, deller@gmx.de,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
geoff@infradead.org, mpe@ellerman.id.au, npiggin@gmail.com,
christophe.leroy@csgroup.eu
Cc: linux-fbdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Thomas Zimmermann <tzimmermann@suse.de>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 02/11] fbdev: Transfer video= option strings to caller; clarify ownership
Date: Fri, 17 Feb 2023 09:37:46 +0100 [thread overview]
Message-ID: <87a61cy9et.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <20230209135509.7786-3-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
> In fb_get_options(), always duplicate the returned option string and
> transfer ownership of the memory to the function's caller.
>
> Until now, only the global option string got duplicated and transferred
> to the caller; the per-driver options were owned by fb_get_options().
> In the end, it was impossible for the function's caller to detect if
> it had to release the string's memory buffer. Hence, all calling drivers
> leak the memory buffer. The leaks have existed ever since, but drivers
> only call fb_get_option() once as part of module initialization. So the
> amount of leaked memory is not significant.
>
> Fix the semantics of fb_get_option() by unconditionally transferring
> ownership of the memory buffer to the caller. Later patches can resolve
> the memory leaks in the fbdev drivers.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
[...]
> + if (option) {
> + if (options)
> + *option = kstrdup(options, GFP_KERNEL);
> + else
> + *option = NULL;
> + }
>
I know the old code wasn't checking if kstrdup() succeeded, but you should
do it here and let the caller know. And same if (!options). So I guess the
following check can be added (to be consistent with the rest of the code):
if (!*option)
retval = 1;
> return retval;
> }
> --
> 2.39.1
Best regards,
Javier
next prev parent reply other threads:[~2023-02-17 8:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 13:54 [PATCH 00/11] drm,fbdev: Move video= option to drivers/video Thomas Zimmermann
2023-02-09 13:54 ` [PATCH 01/11] fbdev: Fix contact info in fb_cmdline.c Thomas Zimmermann
2023-02-17 8:17 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 02/11] fbdev: Transfer video= option strings to caller; clarify ownership Thomas Zimmermann
2023-02-17 8:37 ` Javier Martinez Canillas [this message]
2023-02-17 9:44 ` Thomas Zimmermann
2023-02-17 11:23 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 03/11] fbdev: Support NULL for name in option-string lookup Thomas Zimmermann
2023-02-17 8:45 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 04/11] drivers/ps3: Read video= option with fb_get_option() Thomas Zimmermann
2023-02-12 16:53 ` Geoff Levand
2023-02-13 11:29 ` Thomas Zimmermann
2023-02-13 16:31 ` Geoff Levand
2023-02-17 8:46 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 05/11] fbdev: Read video= option with fb_get_option() in modedb Thomas Zimmermann
2023-02-17 8:47 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 06/11] fbdev: Unexport fb_mode_option Thomas Zimmermann
2023-02-17 8:48 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 07/11] fbdev: Move option-string lookup into helper Thomas Zimmermann
2023-02-17 8:49 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 08/11] fbdev: Handle video= parameter in video/cmdline.c Thomas Zimmermann
2023-02-17 9:00 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 09/11] driver/ps3: Include <video/cmdline.h> for mode parsing Thomas Zimmermann
2023-02-17 9:01 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 10/11] drm: " Thomas Zimmermann
2023-02-17 9:03 ` Javier Martinez Canillas
2023-02-09 13:55 ` [PATCH 11/11] drm: Fix comment on " Thomas Zimmermann
2023-02-17 9:04 ` Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a61cy9et.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=airlied@gmail.com \
--cc=christophe.leroy@csgroup.eu \
--cc=daniel@ffwll.ch \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=geoff@infradead.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mpe@ellerman.id.au \
--cc=mripard@kernel.org \
--cc=npiggin@gmail.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).