linux-kernel - Re: drm/i915: Use the i915_device name for identifying our, request fences

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 12 Dec 2019 20:58:39 +0000
From:   Colin Ian King <colin.king@...onical.com>
To:     Chris Wilson <chris@...is-wilson.co.uk>
Cc:     Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@...el.com>,
        intel-gfx <intel-gfx@...ts.freedesktop.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: drm/i915: Use the i915_device name for identifying our, request
 fences

On 12/12/2019 20:38, Chris Wilson wrote:
> Quoting Colin Ian King (2019-12-12 19:53:33)
>> Hi,
>>
>> Static analysis with Coverity has picked up an issue with the following
>> commit:
>>
>> commit 65c29dbb19b2451990c5c477fef7ada3b8218f05
>> Author: Chris Wilson <chris@...is-wilson.co.uk>
>> Date:   Wed Dec 11 15:02:04 2019 +0000
>>
>>     drm/i915: Use the i915_device name for identifying our request fences
>>
>> In source drivers/gpu/drm/i915/i915_request.c and function
>> i915_fence_get_timeline_name there is the following:
>>
>>         return to_request(fence)->gem_context->name ?: "[" DRIVER_NAME "]";
>>
>> However name is an array: char name[TASK_COMM_LEN + 8], so it can never
>> be null, so the ternary operator will always return name and will never
>> reaturn "[" DRIVER_NAME "]".  Should it instead be checking if name[0]
>> is '\0' instead?
> 
> It's older than that patch, we made it a char[] some time ago. There's a
> patch pending to make it conditional on ce->gem_context instead.
> -Chris
> 
Ah, thanks for looking into that.

Colin