On 10/05/2024 10:13, Jani Nikula wrote:
> On Thu, 09 May 2024, Steven Price <steven.price@xxxxxxx> 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@xxxxxxxxx
>
>
