All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "André Almeida" <andrealmeid@igalia.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Darren Hart" <dvhart@infradead.org>,
	"Davidlohr Bueso" <dave@stgolabs.net>,
	"Shuah Khan" <shuah@kernel.org>, "Arnd Bergmann" <arnd@arndb.de>,
	"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
	"Waiman Long" <longman@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-api@vger.kernel.org, kernel-dev@igalia.com,
	"André Almeida" <andrealmeid@igalia.com>
Subject: Re: [PATCH v5 5/7] futex: Remove the limit of elements for sys_set_robust_list2 lists
Date: Fri, 27 Jun 2025 14:22:46 +0200	[thread overview]
Message-ID: <87wm8xnzl5.ffs@tglx> (raw)
In-Reply-To: <20250626-tonyk-robust_futex-v5-5-179194dbde8f@igalia.com>

On Thu, Jun 26 2025 at 14:11, André Almeida wrote:
> Remove the limit of ROBUST_LIST_LIMIT elements that a robust list can
> have, for the ones created with the new interface. This is done by

With which new interface?

> overwritten the list as it's proceeded in a way that we avoid circular

overwriting each processed list entry to point at ...., which eliminates
a potential circular list.


> lists.
>
> For the old interface, we keep the limited behavior to avoid changing

s/we//

> the API.

Which API would be violated?

Overwriting the dying tasks robust list entries is not violating any
ABI. The task's memory is on the way to be destroyed.

> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
>  kernel/futex/core.c | 37 +++++++++++++++++++++++++++++--------
>  1 file changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/futex/core.c b/kernel/futex/core.c
> index 1049f8ef3ce3c611b3be0ca12df34a98f710121d..942b66facdea16cd7be2235d95c2bbbae8d7cc63 100644
> --- a/kernel/futex/core.c
> +++ b/kernel/futex/core.c
> @@ -1152,7 +1152,8 @@ static inline int fetch_robust_entry(struct robust_list __user **entry,
>   * We silently return on any sign of list-walking problem.
>   */
>  static void exit_robust_list64(struct task_struct *curr,
> -			       struct robust_list_head __user *head)
> +			       struct robust_list_head __user *head,
> +			       bool destroyable)
>  {
>  	struct robust_list __user *entry, *next_entry, *pending;
>  	unsigned int limit = ROBUST_LIST_LIMIT, pi, pip;
> @@ -1196,13 +1197,17 @@ static void exit_robust_list64(struct task_struct *curr,
>  		}
>  		if (rc)
>  			return;
> -		entry = next_entry;
> -		pi = next_pi;
> +
>  		/*
>  		 * Avoid excessively long or circular lists:
>  		 */
> -		if (!--limit)
> +		if (!destroyable && !--limit)
>  			break;
> +		else
> +			put_user(&head->list, &entry->next);

Unchecked put_user() with zero explanation what it actually does.

> +
> +		entry = next_entry;
> +		pi = next_pi;
>  
>  		cond_resched();
>  	}
> @@ -1214,7 +1219,8 @@ static void exit_robust_list64(struct task_struct *curr,
>  }
>  #else
>  static void exit_robust_list64(struct task_struct *curr,
> -			       struct robust_list_head __user *head)
> +			       struct robust_list_head __user *head,
> +			       bool destroyable)
>  {
>  	pr_warn("32bit kernel should not allow ROBUST_LIST_64BIT");
>  }
> @@ -1252,7 +1258,8 @@ fetch_robust_entry32(u32 *uentry, struct robust_list __user **entry,
>   * We silently return on any sign of list-walking problem.
>   */
>  static void exit_robust_list32(struct task_struct *curr,
> -			       struct robust_list_head32 __user *head)
> +			       struct robust_list_head32 __user *head,
> +			       bool destroyable)
>  {
>  	struct robust_list __user *entry, *next_entry, *pending;
>  	unsigned int limit = ROBUST_LIST_LIMIT, pi, pip;

So this get's a destroyable argument as well, but no implementation?

> @@ -1474,10 +1481,19 @@ static void exit_pi_state_list(struct task_struct *curr)
>  static inline void exit_pi_state_list(struct task_struct *curr) { }
>  #endif
>  
> +/*
> + * futex_cleanup - After the task exists, process the robust lists
> + *
> + * Walk through the linked list, parsing robust lists and freeing the
> + * allocated lists. Lists created with the set_robust_list2 don't have a limit
> + * for sizing and can be destroyed while we walk on it to avoid circular list.
> + */
>  static void futex_cleanup(struct task_struct *tsk)
>  {
>  	struct robust_list2_entry *curr, *n;
>  	struct list_head *list2 = &tsk->robust_list2;
> +	bool destroyable = true;
> +	int i = 0;
>  
>  	/*
>  	 * Walk through the linked list, parsing robust lists and freeing the
> @@ -1485,15 +1501,20 @@ static void futex_cleanup(struct task_struct *tsk)
>  	 */
>  	if (unlikely(!list_empty(list2))) {
>  		list_for_each_entry_safe(curr, n, list2, list) {
> +			destroyable = true;
> +			if (tsk->robust_list_index == i)
> +				destroyable = false;

Oh well.....

  reply	other threads:[~2025-06-27 12:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-26 17:11 [PATCH v5 0/7] futex: Create set_robust_list2 André Almeida
2025-06-26 17:11 ` [PATCH v5 1/7] selftests/futex: Add ASSERT_ macros André Almeida
2025-06-26 22:07   ` Thomas Gleixner
2025-06-26 22:09     ` Thomas Gleixner
2025-06-27 20:23     ` André Almeida
2025-07-01  9:20       ` Thomas Gleixner
2025-06-26 17:11 ` [PATCH v5 2/7] selftests/futex: Create test for robust list André Almeida
2025-06-26 22:36   ` Thomas Gleixner
2025-06-26 17:11 ` [PATCH v5 3/7] futex: Use explicit sizes for compat_exit_robust_list André Almeida
2025-06-26 22:56   ` Thomas Gleixner
2025-06-28 14:27   ` kernel test robot
2025-06-26 17:11 ` [PATCH v5 4/7] futex: Create set_robust_list2 André Almeida
2025-06-27 12:06   ` Thomas Gleixner
2025-06-26 17:11 ` [PATCH v5 5/7] futex: Remove the limit of elements for sys_set_robust_list2 lists André Almeida
2025-06-27 12:22   ` Thomas Gleixner [this message]
2025-06-26 17:11 ` [PATCH v5 6/7] futex: Wire up set_robust_list2 syscall André Almeida
2025-06-26 17:11 ` [PATCH v5 7/7] selftests: futex: Expand robust list test for the new interface André Almeida
2025-06-27 12:48   ` Thomas Gleixner

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=87wm8xnzl5.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=andrealmeid@igalia.com \
    --cc=arnd@arndb.de \
    --cc=bigeasy@linutronix.de \
    --cc=dave@stgolabs.net \
    --cc=dvhart@infradead.org \
    --cc=kernel-dev@igalia.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=shuah@kernel.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 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.