From: Thomas Gleixner <tglx@kernel.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev,
"Ingo Molnar" <mingo@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Darren Hart" <dvhart@infradead.org>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"André Almeida" <andrealmeid@igalia.com>,
"Clark Williams" <clrkwllms@kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Ji'an Zhou" <eilaimemedsnaimel@gmail.com>,
"Michael Bommarito" <michael.bommarito@gmail.com>
Subject: Re: [PATCH] futex/requeue: Revert "Prevent NULL pointer dereference in remove_waiter() on self-deadlock""
Date: Wed, 01 Jul 2026 21:13:21 +0200 [thread overview]
Message-ID: <87echmplpq.ffs@fw13> (raw)
In-Reply-To: <20260701154517.0u_G4dkO@linutronix.de>
On Wed, Jul 01 2026 at 17:45, Sebastian Andrzej Siewior wrote:
> On 2026-07-01 17:25:05 [+0200], Thomas Gleixner wrote:
>> > That has been already handled by Davidlohr in commit 40a25d59e85b3
>> > ("locking/rtmutex: Skip remove_waiter() when waiter is not enqueued")
>> > and requires no further acting.
>>
>> No. If the self deadlock is obvious, then this should not even go into
>> the proxy lock code. I clearly failed to notice the leak problem, but
>> reverting it and relying on some magic down the road to handle it
>> correctly is not really solid.
>
> Davidlohr fixed the issue that has been fixed again. We don't need two
> changes for the same thing.
He hardened the remove() function against that scenario.
> We have deadlock detection down the road, why special case it here?
It's not special, but there is no point to actucally call into complex
and as demonstrated fragile code when you can avoid it upfront, no?
next prev parent reply other threads:[~2026-07-01 19:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 13:11 [PATCH] futex/requeue: Revert "Prevent NULL pointer dereference in remove_waiter() on self-deadlock"" Sebastian Andrzej Siewior
2026-07-01 15:25 ` Thomas Gleixner
2026-07-01 15:45 ` Sebastian Andrzej Siewior
2026-07-01 19:13 ` Thomas Gleixner [this message]
2026-07-02 6:33 ` Sebastian Andrzej Siewior
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=87echmplpq.ffs@fw13 \
--to=tglx@kernel.org \
--cc=andrealmeid@igalia.com \
--cc=bigeasy@linutronix.de \
--cc=clrkwllms@kernel.org \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=eilaimemedsnaimel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=michael.bommarito@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox