[syzbot] [kernel?] INFO: task hung in restrict_one_thread_callback
Günther Noack
gnoack at google.com
Mon Feb 23 15:16:44 UTC 2026
Hello!
On Mon, Feb 23, 2026 at 07:29:56PM +0800, Ding Yihan wrote:
> Thank you for the detailed analysis and the clear breakdown.
> Apologies for the delayed response. I spent the last couple of days
> thoroughly reading through the previous mailing list discussions. I
> was trying hard to see if there was any viable pure lockless design
> that could solve this concurrency issue while preserving the original
> architecture.
>
> However, after looking at the complexities you outlined, I completely
> agree with your conclusion: serializing the TSYNC operations is indeed
> the most robust and reasonable path forward to prevent the deadlock.
>
> Regarding the lock choice, since 'cred_guard_mutex' is explicitly
> marked as deprecated for new code in the kernel,maybe we can use its
> modern replacement: 'exec_update_lock' (using down_write_trylock /
> up_write on current->signal). This aligns with the current subsystem
> standards and was also briefly touched upon by Jann in the older
> discussions.
>
> I fully understand the requirement for the two-part patch series:
> 1. Cleaning up the cancellation logic and comments.
> 2. Introducing the serialization lock for TSYNC.
>
> I will take some time to draft and test this patch series properly.
> I also plan to discuss this with my kernel colleagues here at
> UnionTech to see if they have any additional suggestions on the
> implementation details before I submit it.
>
> I will send out the v1 patch series to the list as soon as it is
> ready. Thanks again for your guidance and the great discussion!
Thank you, Ding, this is much appreciated!
I agree, the `exec_update_lock` might be the better solution;
I also need to familiarize myself more with it to double-check.
—Günther
More information about the Linux-security-module-archive
mailing list