All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack@google.com>
To: Ding Yihan <dingyihan@uniontech.com>
Cc: "Günther Noack" <gnoack3000@gmail.com>,
	syzbot <syzbot+7ea2f5e9dfd468201817@syzkaller.appspotmail.com>,
	"Mickaël Salaün" <mic@digikod.net>,
	linux-security-module@vger.kernel.org,
	"Jann Horn" <jannh@google.com>,
	"Paul Moore" <paul@paul-moore.com>
Subject: Re: [syzbot] [kernel?] INFO: task hung in restrict_one_thread_callback
Date: Mon, 23 Feb 2026 16:16:44 +0100	[thread overview]
Message-ID: <aZxvXARvYf6aQBUv@google.com> (raw)
In-Reply-To: <32095877A7CB47CB+bb9e1be8-59c2-46d9-b1ef-f22d2d8c386e@uniontech.com>

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

  reply	other threads:[~2026-02-23 15:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <F1E9B1BEBD8867CA+092eea18-94c7-4c65-a466-95cd3628a88c@uniontech.com>
2026-02-21  7:11 ` [syzbot] [kernel?] INFO: task hung in restrict_one_thread_callback syzbot
2026-02-21  7:28   ` Ding Yihan
2026-02-21 12:00     ` Günther Noack
2026-02-21 13:19       ` Günther Noack
2026-02-23  9:42         ` Günther Noack
2026-02-23 11:29           ` Ding Yihan
2026-02-23 15:16             ` Günther Noack [this message]
2026-02-24  3:02               ` Ding Yihan
2026-02-24  3:03                 ` syzbot
2026-02-24  6:27           ` [PATCH] landlock: Fix deadlock " Yihan Ding
2026-02-24  8:48             ` Günther Noack
2026-02-24 14:43     ` [syzbot] [kernel?] INFO: task hung " Günther Noack
     [not found] <7F45E41D790CD8A4+f1dcffc7-5b69-432f-8ad7-e96a3ef66219@uniontech.com>
2026-02-24  5:07 ` syzbot
     [not found] <F4E5EFD28BFB7AA6+108340fb-0592-4dd0-9f93-b7a2b760dc5d@uniontech.com>
2026-02-24  4:08 ` syzbot
2026-02-20 11:11 syzbot
2026-02-23 13:40 ` Frederic Weisbecker
2026-02-23 15:15   ` Günther Noack
2026-02-24  0:10 ` Hillf Danton
2026-02-24  3:05   ` syzbot
2026-02-24 10:00   ` Günther Noack
2026-02-25  5:10 ` Hillf Danton
2026-02-25 10:22 ` Hillf Danton
2026-02-25 12:21 ` Hillf Danton
2026-02-25 22:32 ` Hillf Danton
2026-02-26  2:19 ` Hillf Danton
2026-02-26 10:04 ` Hillf Danton
2026-02-27  0:03 ` Hillf Danton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZxvXARvYf6aQBUv@google.com \
    --to=gnoack@google.com \
    --cc=dingyihan@uniontech.com \
    --cc=gnoack3000@gmail.com \
    --cc=jannh@google.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=paul@paul-moore.com \
    --cc=syzbot+7ea2f5e9dfd468201817@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.