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]
Message-ID: <4c39dd4f-0aab-47b5-8424-4e0f23221623@linux.dev>
Date: Fri, 1 Aug 2025 09:29:17 +0800
From: Lance Yang <lance.yang@...ux.dev>
To: Nathan Chancellor <nathan@...nel.org>
Cc: lkp@...el.com, akpm@...ux-foundation.org, zi.li@...ux.dev,
 llvm@...ts.linux.dev, mhiramat@...nel.org, oe-kbuild-all@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] hung_task: fix objtool sibling call warning in
 watchdog()



On 2025/8/1 01:59, Nathan Chancellor wrote:
> On Thu, Jul 31, 2025 at 10:39:34AM +0800, Lance Yang wrote:
>> From: Lance Yang <lance.yang@...ux.dev>
>>
>> The kernel test robot reported an objtool warning on the loongarch
>> architecture with clang:
>>
>>          vmlinux.o: warning: objtool: watchdog+0x418: sibling call from
>> callable instruction with modified stack frame
>>
>> To resolve this, explicitly prevent the compiler from inlining or
>> performing a tail call on check_hung_uninterruptible_tasks() by marking
>> it with the noinline attribute. This ensures a standard function call
>> with a proper stack frame, satisfying objtool's validation requirements.
>>
>> Reported-by: kernel test robot <lkp@...el.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202507301256.cZlxQ10s-lkp@intel.com/
>> Signed-off-by: Lance Yang <lance.yang@...ux.dev>
> 
> While this may solve that particular instance of the warning, the fact
> there are many, many more with that configuration indicates that there
> will need to be a more generalized fix. I have started a separate thread
> with some LoongArch folks around this issue:

Thanks for the heads-up!

Yes, you're right, a more general fix is definitely the way to go.

I'll keep an eye on that thread and see how I can help ;)

Thanks,
Lance

> 
> https://lore.kernel.org/20250731175655.GA1455142@ax162/
> 
> Cheers,
> Nathan
> 
>> ---
>>   kernel/hung_task.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
>> index 8708a1205f82..a5b5a0a2c262 100644
>> --- a/kernel/hung_task.c
>> +++ b/kernel/hung_task.c
>> @@ -283,7 +283,7 @@ static bool rcu_lock_break(struct task_struct *g, struct task_struct *t)
>>    * a really long time (120 seconds). If that happens, print out
>>    * a warning.
>>    */
>> -static void check_hung_uninterruptible_tasks(unsigned long timeout)
>> +static noinline void check_hung_uninterruptible_tasks(unsigned long timeout)
>>   {
>>   	int max_count = sysctl_hung_task_check_count;
>>   	unsigned long last_break = jiffies;
>> -- 
>> 2.49.0
>>
>>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ