drivers/gpu/drm/amd/amdgpu/amdgpu.o: error: objtool: amdgpu_vm_handle_fault+0x16b: sibling call from callable instruction with modified stack frame

drivers/gpu/drm/amd/amdgpu/amdgpu.o: error: objtool: amdgpu_vm_handle_fault+0x16b: sibling call from callable instruction with modified stack frame

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   d2c9a99135da931377240942d44f3dea104cedb8
commit: 7152b248dc3c8d5fa8629e99ed5655dd41b51562 drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format
date:   2 weeks ago
config: x86_64-randconfig-004 (https://download.01.org/0day-ci/archive/20260703/202607031837.HSmBj8pr-lkp@intel.com/config)
compiler: clang version 22.1.3 (https://github.com/llvm/llvm-project e9846648fd6183ee6d8cbdb4502213fcf902a211)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260703/202607031837.HSmBj8pr-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Fixes: 7152b248dc3c ("drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format")
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202607031837.HSmBj8pr-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/amdgpu.o: error: objtool: amdgpu_vm_handle_fault+0x16b: sibling call from callable instruction with modified stack frame

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: drivers/gpu/drm/amd/amdgpu/amdgpu.o: error: objtool: amdgpu_vm_handle_fault+0x16b: sibling call from callable instruction with modified stack frame

[Mikhail Gavrilov]

On Fri, Jul 3, 2026 at 3:17 PM kernel test robot <lkp@intel.com> wrote:
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   d2c9a99135da931377240942d44f3dea104cedb8
> commit: 7152b248dc3c8d5fa8629e99ed5655dd41b51562 drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format
> date:   2 weeks ago
> config: x86_64-randconfig-004 (https://download.01.org/0day-ci/archive/20260703/202607031837.HSmBj8pr-lkp@intel.com/config)
> compiler: clang version 22.1.3 (https://github.com/llvm/llvm-project e9846648fd6183ee6d8cbdb4502213fcf902a211)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260703/202607031837.HSmBj8pr-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Fixes: 7152b248dc3c ("drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format")
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202607031837.HSmBj8pr-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> >> drivers/gpu/drm/amd/amdgpu/amdgpu.o: error: objtool: amdgpu_vm_handle_fault+0x16b: sibling call from callable instruction with modified stack frame
>

Same drm_exec computed-goto issue as the other two reports, now on
Linus' master. +0x16b is the drm_exec_retry_on_contention() computed
goto in amdgpu_vm_handle_fault() lowered to an indirect jmp (jmp *reg
to an in-function label loaded via an R_X86_64_32S relocation), which
objtool can't resolve to an intra-function jump and so treats as an
indirect sibling call. Same mechanism analyzed here for clang and gcc:

  https://lore.kernel.org/oe-kbuild-all/20260624092806.GX48970@noisy.programming.kicks-ass.net/
  https://github.com/llvm/llvm-project/issues/205544

Note the bisect: this instance is attributed to 7152b248dc3c
("drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_
format"), but that commit only touches amdgpu_dev_coredump.c and does
not change amdgpu_vm_handle_fault(). The drm_exec conversion that
introduced the pattern is 9920249a5288 ("drm/amdgpu: convert
amdgpu_vm_lock_by_pasid() to drm_exec"). The randconfig-004 attribution
here is a bisect artifact, so the suggested Fixes: tag points at the
wrong commit.

The drm_exec macros are being reworked to drop the computed goto, which
will fix this on both compilers. Not respinning the series; happy to
test the drm_exec.h change once it lands.

-- 
Best Regards,
Mike Gavrilov.