linux-kernel - Re: [PATCH] drm/i915: Remove unneeded double drm_rect_visible call in check_overlay

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ecfb0f31-a454-4a51-9fb8-9cd0aca3195c@ancud.ru>
Date: Fri, 1 Mar 2024 21:56:41 +0300
From: Nikita Kiryushin <kiryushin@...ud.ru>
To: Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc: Jani Nikula <jani.nikula@...ux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>,
 Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
 Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
 David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 Manasi Navare <manasi.d.navare@...el.com>, intel-gfx@...ts.freedesktop.org,
 intel-xe@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, lvc-project@...uxtesting.org
Subject: Re: [PATCH] drm/i915: Remove unneeded double drm_rect_visible call in
 check_overlay_dst

On 2/29/24 15:30, Ville Syrjälä wrote:
> I prefer the current way where we have no side effects in
> the if statement.
>

This seem like a valid concern from readability and maintainability 
standpoint. My patch was aimed mostly at performance and maintainability 
using tools: some more pedantic analyzers are sensitive to non-checked 
return values (as of now, drm_rect_intersect is ignored).

Would it be a better idea to make an update to the patch with second 
drm_rect_visible call changed to an appropriately named state flag set 
with drm_rect_intersect result?

BTW, the original patch somehow got mangled while it made its way to the 
patchwork: source list line in patch got broken, which permits the patch 
from being applied (the original version did not have that line break). 
Any ideas how to prevent this happening with the second version of patch 
(in case the idea is viable)?