All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Keno Fischer <keno@juliahub.com>
Cc: "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>,
	"Yang Tao" <yang.tao172@zte.com.cn>,
	"Yi Wang" <wang.yi59@zte.com.cn>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH] futex: Prevent robust futex exit race more
Date: Thu, 30 Jul 2026 08:58:44 +0200	[thread overview]
Message-ID: <87tsphezff.ffs@fw13> (raw)
In-Reply-To: <CABV8kRy2tQ50sBD-EGbKg-TANbVyE2m29eciCAomGGeZ2FeL3Q@mail.gmail.com>

On Wed, Jul 29 2026 at 10:47, Keno Fischer wrote:
> On Wed, 29 Jul 2026 15:47:17 +0200, Thomas Gleixner <tglx@kernel.org> wrote:
>> On Tue, Jul 28 2026 at 18:13, Keno Fischer wrote:
>>
>>> On Tue, Jul 28, 2026 at 6:05 PM Thomas Gleixner <tglx@kernel.org> wrote:
>>>> Seems your mail client mangled the patch. See:
>>>
>>> Yeah, sorry about that, I've fixed that since. Gmail is a huge pain here.
>>
>> Can you please resend then?
>>
> Of course - resent below. Sorry again for the hassle.

It's slightly less mangled than the original one, which replaced tabs
with spaces in some places, but still fails to apply out of the box.

> --- a/kernel/futex/core.c
> +++ b/kernel/futex/core.c
> @@ -982,8 +982,11 @@ static int handle_futex_death(u32 __user *uaddr,
> struct task_struct *curr,

Forced line break. Still causes:

Applying: futex: Prevent robust futex exit race more
error: corrupt patch at line 10

>  		return -1;
>
>  	/*
> -	 * Special case for regular (non PI) futexes. The unlock path in
> -	 * user space has two race scenarios:
> +	 * Special case for regular (non PI) futexes. Ordinarily, we do
> +	 * not perform any processing here unless the current thread was
> +	 * the owner of the futex (by the TID check below).
> +	 *
> +	 * However, the unlock path has three race scenarios:
>  	 *
>  	 * 1. The unlock path releases the user space futex value and
>  	 *    before it can execute the futex() syscall to wake up
> @@ -992,42 +995,70 @@ static int handle_futex_death(u32 __user *uaddr,
> struct task_struct *curr,

Ditto

>  	 * 2. A woken up waiter is killed before it can acquire the
>  	 *    futex in user space.
>  	 *
>  	 */
>  	owner = uval & FUTEX_TID_MASK;
>

This empty line got the leading space, which is prepended by diff,
stripped off. Some tools tolerate that, some not.

> -	if (pending_op && !pi && !owner) {
> -		futex_wake(uaddr, FLAGS_SIZE_32 | FLAGS_SHARED, NULL, 1,
> -			   FUTEX_BITSET_MATCH_ANY);
> +	if (owner != task_pid_vnr(curr)) {
> +		if (pending_op && !pi &&
> +		    (!owner || !(uval & FUTEX_WAITERS)))
> +			futex_wake(uaddr, FLAGS_SIZE_32 | FLAGS_SHARED, NULL, 1,
> +				   FUTEX_BITSET_MATCH_ANY);
>  		return 0;
>  	}
>

Same here.

> -	if (owner != task_pid_vnr(curr))
> -		return 0;
> -
>  	/*
>  	 * Ok, this dying thread is truly holding a futex
>  	 * of interest. Set the OWNER_DIED bit atomically

Please send the patch to yourself, save the mail and try to apply
it with git am.



      reply	other threads:[~2026-07-30  6:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21  3:26 [PATCH] futex: Prevent robust futex exit race more Keno Fischer
2026-07-21 12:24 ` Thomas Gleixner
2026-07-21 16:50   ` Keno Fischer
2026-07-22 14:21     ` Thomas Gleixner
2026-07-23 12:53       ` Christian Brauner
2026-07-23 13:24         ` Florian Weimer
2026-07-24  8:20           ` Christian Brauner
2026-07-23 19:59         ` Keno Fischer
2026-07-23 19:44       ` Keno Fischer
2026-07-26 20:39         ` Thomas Gleixner
2026-07-26 22:54           ` Keno Fischer
2026-07-27 13:12             ` Thomas Gleixner
2026-07-27 17:23               ` Keno Fischer
2026-07-28 19:43                 ` Thomas Gleixner
2026-07-28 21:29                   ` Thomas Gleixner
2026-07-28 22:05 ` Thomas Gleixner
2026-07-28 22:13   ` Keno Fischer
2026-07-29 13:47     ` Thomas Gleixner
2026-07-29 14:47       ` Keno Fischer
2026-07-30  6:58         ` Thomas Gleixner [this message]

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=87tsphezff.ffs@fw13 \
    --to=tglx@kernel.org \
    --cc=andrealmeid@igalia.com \
    --cc=dave@stgolabs.net \
    --cc=dvhart@infradead.org \
    --cc=keno@juliahub.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=wang.yi59@zte.com.cn \
    --cc=yang.tao172@zte.com.cn \
    /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.