From: Steven Price <steven.price@arm.com>
To: Jani Nikula <jani.nikula@intel.com>, dri-devel@lists.freedesktop.org
Cc: Hamza Mahfooz <hamza.mahfooz@amd.com>,
Daniel Vetter <daniel@ffwll.ch>, Simon Ser <contact@emersion.fr>,
Javier Martinez Canillas <javierm@redhat.com>
Subject: Re: [PATCH] drm: deprecate driver date
Date: Fri, 10 May 2024 10:36:28 +0100 [thread overview]
Message-ID: <821f8348-a3ea-42b5-b990-6d1520d70d89@arm.com> (raw)
In-Reply-To: <8734qqjahi.fsf@intel.com>
On 10/05/2024 10:13, Jani Nikula wrote:
> On Thu, 09 May 2024, Steven Price <steven.price@arm.com> wrote:
>> On 29/04/2024 17:43, Jani Nikula wrote:
>>> The driver date serves no useful purpose, because it's hardly ever
>>> updated. The information is misleading at best.
>>>
>>> As described in Documentation/gpu/drm-internals.rst:
>>>
>>> The driver date, formatted as YYYYMMDD, is meant to identify the date
>>> of the latest modification to the driver. However, as most drivers
>>> fail to update it, its value is mostly useless. The DRM core prints it
>>> to the kernel log at initialization time and passes it to userspace
>>> through the DRM_IOCTL_VERSION ioctl.
>>>
>>> Stop printing the driver date at init, and start returning the empty
>>> string "" as driver date through the DRM_IOCTL_VERSION ioctl.
>>
>> I agree with the idea of this, unfortuantly it breaks user space :(
>>
>> It's a bug in libdrm, but given this breaks existing user space I think
>> we'll need to revert/reconsider.
>>
>> The issue is in drmGetVersion() [1]:
>>
>>> if (version->date_len)
>>> version->date = drmMalloc(version->date_len + 1);
>>
>> So if date_len == 0, then version->date isn't populated (and isn't
>> initialized at all). But then later on in drmCopyVersion() [2] the
>> (unset) version->date is passed to strdup():
>>
>>> static void drmCopyVersion(drmVersionPtr d, const drm_version_t *s)
>>> {
>>> d->version_major = s->version_major;
>>> d->version_minor = s->version_minor;
>>> d->version_patchlevel = s->version_patchlevel;
>>> d->name_len = s->name_len;
>>> d->name = strdup(s->name);
>>> d->date_len = s->date_len;
>>> d->date = strdup(s->date);
>>> d->desc_len = s->desc_len;
>>> d->desc = strdup(s->desc);
>>> }
>>
>> Which then segfaults if the uninitialized value points off somewhere
>> bad. And this does happen (my test setup reproduced this).
>
> Thanks for the report!
>
>> A simple fix is to make sure the string isn't empty - so return
>> "unknown" or just a space, or even "\0".
>
> I don't think "\0" works, because strlen() will still return 0 for it.
Ah, true - you'd have to hack up drm_copy_field() to someone return a
length of 1 in this case. And I'd be a little worried that it would
break something else...
> I went ahead with "0", because that's already been used by virtio until
> now. Fix at [1].
Yep, that seems like the best solution.
Thanks,
Steve
> BR,
> Jani.
>
>
> [1] https://lore.kernel.org/r/20240510090951.3398882-1-jani.nikula@intel.com
>
>
prev parent reply other threads:[~2024-05-10 9:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 16:43 [PATCH] drm: deprecate driver date Jani Nikula
2024-04-29 17:41 ` Hamza Mahfooz
2024-04-29 17:53 ` Jani Nikula
2024-04-30 13:08 ` Daniel Vetter
2024-04-30 13:38 ` Jani Nikula
2024-04-30 14:15 ` Daniel Vetter
2024-04-30 7:53 ` Simon Ser
2024-04-30 9:08 ` Jani Nikula
2024-04-30 8:55 ` Javier Martinez Canillas
2024-05-08 12:57 ` Jani Nikula
2024-05-09 12:20 ` Steven Price
2024-05-10 9:13 ` Jani Nikula
2024-05-10 9:36 ` Steven Price [this message]
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=821f8348-a3ea-42b5-b990-6d1520d70d89@arm.com \
--to=steven.price@arm.com \
--cc=contact@emersion.fr \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamza.mahfooz@amd.com \
--cc=jani.nikula@intel.com \
--cc=javierm@redhat.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).