linux-kernel - Re: [PATCH] drm/msm: Fix objtool warning in submit_lock

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aJSkIJPbvj5xuu77@lappy>
Date: Thu, 7 Aug 2025 09:03:28 -0400
From: Sasha Levin <sashal@...nel.org>
To: Rob Clark <rob.clark@....qualcomm.com>
Cc: lumag@...nel.org, abhinav.kumar@...ux.dev,
	jessica.zhang@....qualcomm.com, sean@...rly.run,
	marijn.suijten@...ainline.org, airlied@...il.com, simona@...ll.ch,
	antomani103@...il.com, linux-arm-msm@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/msm: Fix objtool warning in submit_lock_objects()

On Wed, Aug 06, 2025 at 04:38:19PM -0700, Rob Clark wrote:
>On Tue, Aug 5, 2025 at 3:56 PM Sasha Levin <sashal@...nel.org> wrote:
>>
>> Restructure submit_lock_objects() to use a single loop with break
>> statements to fix objtool warning:
>>
>>   drivers/gpu/drm/msm/msm.o: warning: objtool: submit_lock_objects+0x451:
>>   sibling call from callable instruction with modified stack frame
>>
>> The drm_exec_until_all_locked() macro uses computed gotos internally
>> for its retry loop. Having return statements inside this macro, or
>> immediately after it in certain code paths, confuses objtool's static
>> analysis of stack frames, causing it to incorrectly flag tail call
>> optimizations.
>
>Maybe we should instead just split out a separate
>submit_lock_objects_vmbind() and restore the error path 'goto error'
>instead of returning from within the loop?  Ie. basically revert
>submit_lock_objects to the way it was before commit 92395af63a99
>("drm/msm: Add VM_BIND submitqueue"), and then move the rest into a
>new fxn (with 'goto error' instead of 'return ret'?  In retrospect the
>vmbind case is kinda just shoehorned into the existing fxn.
>
>I can type up this version if you have better things to do.

I'll send it out :)

-- 
Thanks,
Sasha