All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed()
@ 2022-11-18 19:33 Waiman Long
  2022-11-21 10:38 ` Peter Zijlstra
  0 siblings, 1 reply; 9+ messages in thread
From: Waiman Long @ 2022-11-18 19:33 UTC (permalink / raw)
  To: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
	Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
	Daniel Bristot de Oliveira
  Cc: Phil Auld, linux-kernel, Waiman Long

Commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in
do_set_cpus_allowed()") may call kfree() if user_cpus_ptr was previously
set. Unfortunately, some of the callers of do_set_cpus_allowed()
may not be in a context where kfree() can be safely called. So the
following splats may be printed:

   WARNING: possible circular locking dependency detected
   BUG: sleeping function called from invalid context

To avoid these problems without leaking memory, the free cpumask is now
put into a lockless list to be reused in a later sched_setaffinity()
call instead.

Fixes: 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()")
Signed-off-by: Waiman Long <longman@redhat.com>
---
 kernel/sched/core.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78b2d5cabcc5..8df51b08bb38 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2527,6 +2527,11 @@ int push_cpu_stop(void *arg)
 	return 0;
 }
 
+/*
+ * A lockless list of user cpumask available to be reused.
+ */
+static LLIST_HEAD(free_cpumasks);
+
 /*
  * sched_class::set_cpus_allowed must do the below, but is not required to
  * actually call this function.
@@ -2606,7 +2611,14 @@ void do_set_cpus_allowed(struct task_struct *p, const struct cpumask *new_mask)
 	};
 
 	__do_set_cpus_allowed(p, &ac);
-	kfree(ac.user_mask);
+	if (ac.user_mask) {
+		/*
+		 * We may not be in a context where kfree() can be called.
+		 * Put the free user_mask in free_cpumasks to be freed or
+		 * used later.
+		 */
+		llist_add((struct llist_node *)ac.user_mask, &free_cpumasks);
+	}
 }
 
 int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
@@ -8194,7 +8206,7 @@ __sched_setaffinity(struct task_struct *p, struct affinity_context *ctx)
 long sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
 {
 	struct affinity_context ac;
-	struct cpumask *user_mask;
+	struct cpumask *user_mask = NULL;
 	struct task_struct *p;
 	int retval;
 
@@ -8229,7 +8241,15 @@ long sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
 	if (retval)
 		goto out_put_task;
 
-	user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
+	/*
+	 * Use the element in the free_cpumasks, if available.
+	 */
+	if (!llist_empty(&free_cpumasks))
+		user_mask = (struct cpumask *)llist_del_first(&free_cpumasks);
+
+	if (!user_mask)
+		user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
+
 	if (!user_mask) {
 		retval = -ENOMEM;
 		goto out_put_task;
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed()
  2022-11-18 19:33 [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed() Waiman Long
@ 2022-11-21 10:38 ` Peter Zijlstra
  2022-11-21 15:04   ` Waiman Long
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Zijlstra @ 2022-11-21 10:38 UTC (permalink / raw)
  To: Waiman Long
  Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
	Steven Rostedt, Ben Segall, Mel Gorman,
	Daniel Bristot de Oliveira, Phil Auld, linux-kernel

On Fri, Nov 18, 2022 at 02:33:02PM -0500, Waiman Long wrote:
> Commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in
> do_set_cpus_allowed()") may call kfree() if user_cpus_ptr was previously
> set. Unfortunately, some of the callers of do_set_cpus_allowed()

'some' ? There's only 3 or so, which one triggers this?

> may not be in a context where kfree() can be safely called. So the
> following splats may be printed:
> 
>    WARNING: possible circular locking dependency detected
>    BUG: sleeping function called from invalid context
> 
> To avoid these problems without leaking memory, the free cpumask is now
> put into a lockless list to be reused in a later sched_setaffinity()
> call instead.

Urgh.. depending on which of the callsites it is, it's probably simpler
to just rework the caller to not use do_set_cpus_allowed(), no?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed()
  2022-11-21 10:38 ` Peter Zijlstra
@ 2022-11-21 15:04   ` Waiman Long
  2022-11-22 12:37     ` Peter Zijlstra
  0 siblings, 1 reply; 9+ messages in thread
From: Waiman Long @ 2022-11-21 15:04 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
	Steven Rostedt, Ben Segall, Mel Gorman,
	Daniel Bristot de Oliveira, Phil Auld, linux-kernel


On 11/21/22 05:38, Peter Zijlstra wrote:
> On Fri, Nov 18, 2022 at 02:33:02PM -0500, Waiman Long wrote:
>> Commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in
>> do_set_cpus_allowed()") may call kfree() if user_cpus_ptr was previously
>> set. Unfortunately, some of the callers of do_set_cpus_allowed()
> 'some' ? There's only 3 or so, which one triggers this?

It happenned at __kthread_bind_mask() where do_set_cpus_allowed() is 
called with pi_lock held.

[ 1084.820105]  <TASK>
[ 1084.820110]  dump_stack_lvl+0x57/0x81
[ 1084.820117]  check_noncircular+0x103/0x120
[ 10[ 1084.820160]  lock_acquire+0xba/0x230
[ 1084.820164]  ? kfree+0x10f/0x380
[ 1084.820172]  ? do_set_cpus_allowed+0x40/0x60
[ 1084.820181]  rt_spin_lock+0x27/0xe0
[ 1084.820184]  ? kfree+0x10f/0x380
[ 1084.820188]  kfree+0x10f/0x380
[ 1084.820195]  do_set_cpus_allowed+0x40/0x60
[ 1084.820203]  kthread_bind_mask+0x4a/0x70
[ 1084.820211]  create_worker+0xfb/0x1a0
[ 1084.820220]  worker_thread+0x2e3/0x3c0
[ 1084.820226]  ? process_one_work+0x450/0x450
[ 1084.820230]  kthread+0x111/0x130
[ 1084.820236]  ? kthread_complete_and_exit+0x20/0x20
[ 1084.820244]  ret_from_fork+0x22/0x30
[ 1084.820258]  </TASK>
[ 1084.820260] BUG: sleeping function called from invalid context at 
kernel/locking/spinlock_rt.c:46

It shows up with PREEMPT_RT kernel.

>
>> may not be in a context where kfree() can be safely called. So the
>> following splats may be printed:
>>
>>     WARNING: possible circular locking dependency detected
>>     BUG: sleeping function called from invalid context
>>
>> To avoid these problems without leaking memory, the free cpumask is now
>> put into a lockless list to be reused in a later sched_setaffinity()
>> call instead.
> Urgh.. depending on which of the callsites it is, it's probably simpler
> to just rework the caller to not use do_set_cpus_allowed(), no?

Maybe. One thing that I am not clear about is why user_cpus_ptr is set 
in the first place.

Cheers,
Longman


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed()
  2022-11-21 15:04   ` Waiman Long
@ 2022-11-22 12:37     ` Peter Zijlstra
  2022-11-22 15:23       ` Waiman Long
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Zijlstra @ 2022-11-22 12:37 UTC (permalink / raw)
  To: Waiman Long
  Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
	Steven Rostedt, Ben Segall, Mel Gorman,
	Daniel Bristot de Oliveira, Phil Auld, linux-kernel,
	Paul McKenney

On Mon, Nov 21, 2022 at 10:04:33AM -0500, Waiman Long wrote:
> 
> On 11/21/22 05:38, Peter Zijlstra wrote:
> > On Fri, Nov 18, 2022 at 02:33:02PM -0500, Waiman Long wrote:
> > > Commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in
> > > do_set_cpus_allowed()") may call kfree() if user_cpus_ptr was previously
> > > set. Unfortunately, some of the callers of do_set_cpus_allowed()
> > 'some' ? There's only 3 or so, which one triggers this?
> 
> It happenned at __kthread_bind_mask() where do_set_cpus_allowed() is called
> with pi_lock held.
> 
> [ 1084.820105]  <TASK>
> [ 1084.820110]  dump_stack_lvl+0x57/0x81
> [ 1084.820117]  check_noncircular+0x103/0x120
> [ 10[ 1084.820160]  lock_acquire+0xba/0x230
> [ 1084.820164]  ? kfree+0x10f/0x380
> [ 1084.820172]  ? do_set_cpus_allowed+0x40/0x60
> [ 1084.820181]  rt_spin_lock+0x27/0xe0
> [ 1084.820184]  ? kfree+0x10f/0x380
> [ 1084.820188]  kfree+0x10f/0x380
> [ 1084.820195]  do_set_cpus_allowed+0x40/0x60
> [ 1084.820203]  kthread_bind_mask+0x4a/0x70
> [ 1084.820211]  create_worker+0xfb/0x1a0
> [ 1084.820220]  worker_thread+0x2e3/0x3c0
> [ 1084.820226]  ? process_one_work+0x450/0x450
> [ 1084.820230]  kthread+0x111/0x130
> [ 1084.820236]  ? kthread_complete_and_exit+0x20/0x20
> [ 1084.820244]  ret_from_fork+0x22/0x30
> [ 1084.820258]  </TASK>
> [ 1084.820260] BUG: sleeping function called from invalid context at
> kernel/locking/spinlock_rt.c:46
> 
> It shows up with PREEMPT_RT kernel.

Oh, I see ..

> Maybe. One thing that I am not clear about is why user_cpus_ptr is set in
> the first place.

Perhaps someone set an affinity on kthreadd ?

But I'm thinking this exact problem is also possible (rather more likely
even) with select_fallback_rq() that too holds pi_lock (which account
for both other users of this function).

Bah.

And the allocation is just the one long in size (for small configs)
which is just enough space for a single linked list like you had.

Urgh.

The below is yuck too, and I'm not sure Paul wants us to use
kvfree_call_rcu() without its wrapper.

---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78b2d5cabcc5..0d0af0fc7fcf 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2606,7 +2606,12 @@ void do_set_cpus_allowed(struct task_struct *p, const struct cpumask *new_mask)
 	};
 
 	__do_set_cpus_allowed(p, &ac);
-	kfree(ac.user_mask);
+	/*
+	 * Because this is called with p->pi_lock held, it is not possible
+	 * to use kfree() here (when PREEMPT_RT=y), therefore punt to using
+	 * kfree_rcu().
+	 */
+	kvfree_call_rcu((struct rcu_head *)ac.user_mask, (rcu_callback_t)0);
 }
 
 int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
@@ -8196,7 +8201,7 @@ long sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
 	struct affinity_context ac;
 	struct cpumask *user_mask;
 	struct task_struct *p;
-	int retval;
+	int retval, size;
 
 	rcu_read_lock();
 
@@ -8229,7 +8234,11 @@ long sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
 	if (retval)
 		goto out_put_task;
 
-	user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
+	/*
+	 * See do_set_cpus_allowed() for the rcu_head usage.
+	 */
+	size = max_t(int, cpumask_size(), sizeof(struct rcu_head));
+	user_mask = kmalloc(size, GFP_KERNEL);
 	if (!user_mask) {
 		retval = -ENOMEM;
 		goto out_put_task;

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed()
  2022-11-22 12:37     ` Peter Zijlstra
@ 2022-11-22 15:23       ` Waiman Long
  2022-11-22 16:33         ` Paul E. McKenney
  2022-11-22 19:24         ` Peter Zijlstra
  0 siblings, 2 replies; 9+ messages in thread
From: Waiman Long @ 2022-11-22 15:23 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
	Steven Rostedt, Ben Segall, Mel Gorman,
	Daniel Bristot de Oliveira, Phil Auld, linux-kernel,
	Paul McKenney

On 11/22/22 07:37, Peter Zijlstra wrote:
> On Mon, Nov 21, 2022 at 10:04:33AM -0500, Waiman Long wrote:
>> On 11/21/22 05:38, Peter Zijlstra wrote:
>>> On Fri, Nov 18, 2022 at 02:33:02PM -0500, Waiman Long wrote:
>>>> Commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in
>>>> do_set_cpus_allowed()") may call kfree() if user_cpus_ptr was previously
>>>> set. Unfortunately, some of the callers of do_set_cpus_allowed()
>>> 'some' ? There's only 3 or so, which one triggers this?
>> It happenned at __kthread_bind_mask() where do_set_cpus_allowed() is called
>> with pi_lock held.
>>
>> [ 1084.820105]  <TASK>
>> [ 1084.820110]  dump_stack_lvl+0x57/0x81
>> [ 1084.820117]  check_noncircular+0x103/0x120
>> [ 10[ 1084.820160]  lock_acquire+0xba/0x230
>> [ 1084.820164]  ? kfree+0x10f/0x380
>> [ 1084.820172]  ? do_set_cpus_allowed+0x40/0x60
>> [ 1084.820181]  rt_spin_lock+0x27/0xe0
>> [ 1084.820184]  ? kfree+0x10f/0x380
>> [ 1084.820188]  kfree+0x10f/0x380
>> [ 1084.820195]  do_set_cpus_allowed+0x40/0x60
>> [ 1084.820203]  kthread_bind_mask+0x4a/0x70
>> [ 1084.820211]  create_worker+0xfb/0x1a0
>> [ 1084.820220]  worker_thread+0x2e3/0x3c0
>> [ 1084.820226]  ? process_one_work+0x450/0x450
>> [ 1084.820230]  kthread+0x111/0x130
>> [ 1084.820236]  ? kthread_complete_and_exit+0x20/0x20
>> [ 1084.820244]  ret_from_fork+0x22/0x30
>> [ 1084.820258]  </TASK>
>> [ 1084.820260] BUG: sleeping function called from invalid context at
>> kernel/locking/spinlock_rt.c:46
>>
>> It shows up with PREEMPT_RT kernel.
> Oh, I see ..
>
>> Maybe. One thing that I am not clear about is why user_cpus_ptr is set in
>> the first place.
> Perhaps someone set an affinity on kthreadd ?
>
> But I'm thinking this exact problem is also possible (rather more likely
> even) with select_fallback_rq() that too holds pi_lock (which account
> for both other users of this function).
>
> Bah.
>
> And the allocation is just the one long in size (for small configs)
> which is just enough space for a single linked list like you had.
That is exactly the reason why I use lockless list.
>
> Urgh.
>
> The below is yuck too, and I'm not sure Paul wants us to use
> kvfree_call_rcu() without its wrapper.
>
> ---
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 78b2d5cabcc5..0d0af0fc7fcf 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2606,7 +2606,12 @@ void do_set_cpus_allowed(struct task_struct *p, const struct cpumask *new_mask)
>   	};
>   
>   	__do_set_cpus_allowed(p, &ac);
> -	kfree(ac.user_mask);
> +	/*
> +	 * Because this is called with p->pi_lock held, it is not possible
> +	 * to use kfree() here (when PREEMPT_RT=y), therefore punt to using
> +	 * kfree_rcu().
> +	 */
> +	kvfree_call_rcu((struct rcu_head *)ac.user_mask, (rcu_callback_t)0);
>   }

I guess you need to do a NULL check before calling kvfree_call_rcu() as 
I don't think kvfree_call_rcu() does that. Also it is unlikely that we 
need to call it.

>   
>   int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
> @@ -8196,7 +8201,7 @@ long sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
>   	struct affinity_context ac;
>   	struct cpumask *user_mask;
>   	struct task_struct *p;
> -	int retval;
> +	int retval, size;
>   
>   	rcu_read_lock();
>   
> @@ -8229,7 +8234,11 @@ long sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
>   	if (retval)
>   		goto out_put_task;
>   
> -	user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
> +	/*
> +	 * See do_set_cpus_allowed() for the rcu_head usage.
> +	 */
> +	size = max_t(int, cpumask_size(), sizeof(struct rcu_head));
> +	user_mask = kmalloc(size, GFP_KERNEL);
>   	if (!user_mask) {
>   		retval = -ENOMEM;
>   		goto out_put_task;

I guess that will work too. Just like you, I am a bit uneasy to call 
into kvfree_call_rcu() directly as it may change in the future. How about

iff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78b2d5cabcc5..5fac4aa6ac7f 100644
--- a/kernel/sched/core.c
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78b2d5cabcc5..5fac4aa6ac7f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2593,6 +2593,11 @@ __do_set_cpus_allowed(struct task_struct *p, 
struct affinity_context *ctx)
                 set_next_task(rq, p);
  }

+union cpumask_rcuhead {
+       void *cpumask;
+       struct rcu_head rcu;
+};
+
  /*
   * Used for kthread_bind() and select_fallback_rq(), in both cases the 
user
   * affinity (if any) should be destroyed too.
@@ -2606,7 +2611,12 @@ void do_set_cpus_allowed(struct task_struct *p, 
const struct cpumask *new_mask)
         };

         __do_set_cpus_allowed(p, &ac);
-       kfree(ac.user_mask);
+       /*
+        * Because this is called with p->pi_lock held, it is not possible
+        * to use kfree() here (when PREEMPT_RT=y), therefore punt to using
+        * kfree_rcu().
+        */
+       kfree_rcu((union cpumask_rcuhead *)ac.user_mask, rcu);
  }

  int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
@@ -8196,7 +8206,7 @@ long sched_setaffinity(pid_t pid, const struct 
cpumask *in_mask)
         struct affinity_context ac;
         struct cpumask *user_mask;
         struct task_struct *p;
-       int retval;
+       int retval, size;

         rcu_read_lock();

@@ -8229,7 +8239,11 @@ long sched_setaffinity(pid_t pid, const struct 
cpumask *in_mask)
         if (retval)
                 goto out_put_task;

-       user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
+       /*
+        * See do_set_cpus_allowed() for the rcu_head usage.
+        */
+       size = max_t(int, cpumask_size(), sizeof(union cpumask_rcuhead));
+       user_mask = kmalloc(size, GFP_KERNEL);
         if (!user_mask) {
                 retval = -ENOMEM;
                 goto out_put_task;

Cheers,
Longman



^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed()
  2022-11-22 15:23       ` Waiman Long
@ 2022-11-22 16:33         ` Paul E. McKenney
  2022-11-22 19:24         ` Peter Zijlstra
  1 sibling, 0 replies; 9+ messages in thread
From: Paul E. McKenney @ 2022-11-22 16:33 UTC (permalink / raw)
  To: Waiman Long
  Cc: Peter Zijlstra, Ingo Molnar, Juri Lelli, Vincent Guittot,
	Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
	Daniel Bristot de Oliveira, Phil Auld, linux-kernel

On Tue, Nov 22, 2022 at 10:23:43AM -0500, Waiman Long wrote:
> On 11/22/22 07:37, Peter Zijlstra wrote:
> > On Mon, Nov 21, 2022 at 10:04:33AM -0500, Waiman Long wrote:
> > > On 11/21/22 05:38, Peter Zijlstra wrote:
> > > > On Fri, Nov 18, 2022 at 02:33:02PM -0500, Waiman Long wrote:
> > > > > Commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in
> > > > > do_set_cpus_allowed()") may call kfree() if user_cpus_ptr was previously
> > > > > set. Unfortunately, some of the callers of do_set_cpus_allowed()
> > > > 'some' ? There's only 3 or so, which one triggers this?
> > > It happenned at __kthread_bind_mask() where do_set_cpus_allowed() is called
> > > with pi_lock held.
> > > 
> > > [ 1084.820105]  <TASK>
> > > [ 1084.820110]  dump_stack_lvl+0x57/0x81
> > > [ 1084.820117]  check_noncircular+0x103/0x120
> > > [ 10[ 1084.820160]  lock_acquire+0xba/0x230
> > > [ 1084.820164]  ? kfree+0x10f/0x380
> > > [ 1084.820172]  ? do_set_cpus_allowed+0x40/0x60
> > > [ 1084.820181]  rt_spin_lock+0x27/0xe0
> > > [ 1084.820184]  ? kfree+0x10f/0x380
> > > [ 1084.820188]  kfree+0x10f/0x380
> > > [ 1084.820195]  do_set_cpus_allowed+0x40/0x60
> > > [ 1084.820203]  kthread_bind_mask+0x4a/0x70
> > > [ 1084.820211]  create_worker+0xfb/0x1a0
> > > [ 1084.820220]  worker_thread+0x2e3/0x3c0
> > > [ 1084.820226]  ? process_one_work+0x450/0x450
> > > [ 1084.820230]  kthread+0x111/0x130
> > > [ 1084.820236]  ? kthread_complete_and_exit+0x20/0x20
> > > [ 1084.820244]  ret_from_fork+0x22/0x30
> > > [ 1084.820258]  </TASK>
> > > [ 1084.820260] BUG: sleeping function called from invalid context at
> > > kernel/locking/spinlock_rt.c:46
> > > 
> > > It shows up with PREEMPT_RT kernel.
> > Oh, I see ..
> > 
> > > Maybe. One thing that I am not clear about is why user_cpus_ptr is set in
> > > the first place.
> > Perhaps someone set an affinity on kthreadd ?
> > 
> > But I'm thinking this exact problem is also possible (rather more likely
> > even) with select_fallback_rq() that too holds pi_lock (which account
> > for both other users of this function).
> > 
> > Bah.
> > 
> > And the allocation is just the one long in size (for small configs)
> > which is just enough space for a single linked list like you had.
> That is exactly the reason why I use lockless list.
> > 
> > Urgh.
> > 
> > The below is yuck too, and I'm not sure Paul wants us to use
> > kvfree_call_rcu() without its wrapper.
> > 
> > ---
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 78b2d5cabcc5..0d0af0fc7fcf 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -2606,7 +2606,12 @@ void do_set_cpus_allowed(struct task_struct *p, const struct cpumask *new_mask)
> >   	};
> >   	__do_set_cpus_allowed(p, &ac);
> > -	kfree(ac.user_mask);
> > +	/*
> > +	 * Because this is called with p->pi_lock held, it is not possible
> > +	 * to use kfree() here (when PREEMPT_RT=y), therefore punt to using
> > +	 * kfree_rcu().
> > +	 */
> > +	kvfree_call_rcu((struct rcu_head *)ac.user_mask, (rcu_callback_t)0);
> >   }
> 
> I guess you need to do a NULL check before calling kvfree_call_rcu() as I
> don't think kvfree_call_rcu() does that. Also it is unlikely that we need to
> call it.

Indeed, the NULL check is in kvfree_rcu_arg_2().  By the time you get
to kvfree_call_rcu, the pointer is assumed to be non-NULL.

> >   int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
> > @@ -8196,7 +8201,7 @@ long sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
> >   	struct affinity_context ac;
> >   	struct cpumask *user_mask;
> >   	struct task_struct *p;
> > -	int retval;
> > +	int retval, size;
> >   	rcu_read_lock();
> > @@ -8229,7 +8234,11 @@ long sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
> >   	if (retval)
> >   		goto out_put_task;
> > -	user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
> > +	/*
> > +	 * See do_set_cpus_allowed() for the rcu_head usage.
> > +	 */
> > +	size = max_t(int, cpumask_size(), sizeof(struct rcu_head));
> > +	user_mask = kmalloc(size, GFP_KERNEL);
> >   	if (!user_mask) {
> >   		retval = -ENOMEM;
> >   		goto out_put_task;
> 
> I guess that will work too. Just like you, I am a bit uneasy to call into
> kvfree_call_rcu() directly as it may change in the future. How about
> 
> iff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 78b2d5cabcc5..5fac4aa6ac7f 100644
> --- a/kernel/sched/core.c
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 78b2d5cabcc5..5fac4aa6ac7f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2593,6 +2593,11 @@ __do_set_cpus_allowed(struct task_struct *p, struct
> affinity_context *ctx)
>                 set_next_task(rq, p);
>  }
> 
> +union cpumask_rcuhead {
> +       void *cpumask;
> +       struct rcu_head rcu;
> +};
> +
>  /*
>   * Used for kthread_bind() and select_fallback_rq(), in both cases the user
>   * affinity (if any) should be destroyed too.
> @@ -2606,7 +2611,12 @@ void do_set_cpus_allowed(struct task_struct *p, const
> struct cpumask *new_mask)
>         };
> 
>         __do_set_cpus_allowed(p, &ac);
> -       kfree(ac.user_mask);
> +       /*
> +        * Because this is called with p->pi_lock held, it is not possible
> +        * to use kfree() here (when PREEMPT_RT=y), therefore punt to using
> +        * kfree_rcu().
> +        */
> +       kfree_rcu((union cpumask_rcuhead *)ac.user_mask, rcu);

This looks plausible to me.

							Thanx, Paul

>  }
> 
>  int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
> @@ -8196,7 +8206,7 @@ long sched_setaffinity(pid_t pid, const struct cpumask
> *in_mask)
>         struct affinity_context ac;
>         struct cpumask *user_mask;
>         struct task_struct *p;
> -       int retval;
> +       int retval, size;
> 
>         rcu_read_lock();
> 
> @@ -8229,7 +8239,11 @@ long sched_setaffinity(pid_t pid, const struct
> cpumask *in_mask)
>         if (retval)
>                 goto out_put_task;
> 
> -       user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
> +       /*
> +        * See do_set_cpus_allowed() for the rcu_head usage.
> +        */
> +       size = max_t(int, cpumask_size(), sizeof(union cpumask_rcuhead));
> +       user_mask = kmalloc(size, GFP_KERNEL);
>         if (!user_mask) {
>                 retval = -ENOMEM;
>                 goto out_put_task;
> 
> Cheers,
> Longman
> 
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed()
  2022-11-22 15:23       ` Waiman Long
  2022-11-22 16:33         ` Paul E. McKenney
@ 2022-11-22 19:24         ` Peter Zijlstra
  2022-11-22 19:30           ` Waiman Long
  1 sibling, 1 reply; 9+ messages in thread
From: Peter Zijlstra @ 2022-11-22 19:24 UTC (permalink / raw)
  To: Waiman Long
  Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
	Steven Rostedt, Ben Segall, Mel Gorman,
	Daniel Bristot de Oliveira, Phil Auld, linux-kernel,
	Paul McKenney

On Tue, Nov 22, 2022 at 10:23:43AM -0500, Waiman Long wrote:
> index 78b2d5cabcc5..5fac4aa6ac7f 100644
> --- a/kernel/sched/core.c
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 78b2d5cabcc5..5fac4aa6ac7f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2593,6 +2593,11 @@ __do_set_cpus_allowed(struct task_struct *p, struct
> affinity_context *ctx)
>                 set_next_task(rq, p);
>  }
> 
> +union cpumask_rcuhead {
> +       void *cpumask;
> +       struct rcu_head rcu;
> +};
> +

Hehe; I had this union too; I just figured it'd be nice to not have to
spend these 4 lines to express this. Esp. since we're casting pointers
*anyway*.

>  /*
>   * Used for kthread_bind() and select_fallback_rq(), in both cases the user
>   * affinity (if any) should be destroyed too.
> @@ -2606,7 +2611,12 @@ void do_set_cpus_allowed(struct task_struct *p, const
> struct cpumask *new_mask)
>         };
> 
>         __do_set_cpus_allowed(p, &ac);
> -       kfree(ac.user_mask);
> +       /*
> +        * Because this is called with p->pi_lock held, it is not possible
> +        * to use kfree() here (when PREEMPT_RT=y), therefore punt to using
> +        * kfree_rcu().
> +        */
> +       kfree_rcu((union cpumask_rcuhead *)ac.user_mask, rcu);
>  }
> 
>  int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
> @@ -8196,7 +8206,7 @@ long sched_setaffinity(pid_t pid, const struct cpumask
> *in_mask)
>         struct affinity_context ac;
>         struct cpumask *user_mask;
>         struct task_struct *p;
> -       int retval;
> +       int retval, size;
> 
>         rcu_read_lock();
> 
> @@ -8229,7 +8239,11 @@ long sched_setaffinity(pid_t pid, const struct
> cpumask *in_mask)
>         if (retval)
>                 goto out_put_task;
> 
> -       user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
> +       /*
> +        * See do_set_cpus_allowed() for the rcu_head usage.
> +        */
> +       size = max_t(int, cpumask_size(), sizeof(union cpumask_rcuhead));
> +       user_mask = kmalloc(size, GFP_KERNEL);
>         if (!user_mask) {
>                 retval = -ENOMEM;
>                 goto out_put_task;
> 

We also should fix the allocation in dup_user_cpus_ptr() -- perhaps pull
the thing into a helper.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed()
  2022-11-22 19:24         ` Peter Zijlstra
@ 2022-11-22 19:30           ` Waiman Long
  2022-11-22 19:58             ` Peter Zijlstra
  0 siblings, 1 reply; 9+ messages in thread
From: Waiman Long @ 2022-11-22 19:30 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
	Steven Rostedt, Ben Segall, Mel Gorman,
	Daniel Bristot de Oliveira, Phil Auld, linux-kernel,
	Paul McKenney

On 11/22/22 14:24, Peter Zijlstra wrote:
> On Tue, Nov 22, 2022 at 10:23:43AM -0500, Waiman Long wrote:
>> index 78b2d5cabcc5..5fac4aa6ac7f 100644
>> --- a/kernel/sched/core.c
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 78b2d5cabcc5..5fac4aa6ac7f 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2593,6 +2593,11 @@ __do_set_cpus_allowed(struct task_struct *p, struct
>> affinity_context *ctx)
>>                  set_next_task(rq, p);
>>   }
>>
>> +union cpumask_rcuhead {
>> +       void *cpumask;
>> +       struct rcu_head rcu;
>> +};
>> +
> Hehe; I had this union too; I just figured it'd be nice to not have to
> spend these 4 lines to express this. Esp. since we're casting pointers
> *anyway*.
Well, that is true. As long as the NULL check is there, I am OK with 
calling kvfree_call_rcu() directly if Paul doesn't object.
>>   /*
>>    * Used for kthread_bind() and select_fallback_rq(), in both cases the user
>>    * affinity (if any) should be destroyed too.
>> @@ -2606,7 +2611,12 @@ void do_set_cpus_allowed(struct task_struct *p, const
>> struct cpumask *new_mask)
>>          };
>>
>>          __do_set_cpus_allowed(p, &ac);
>> -       kfree(ac.user_mask);
>> +       /*
>> +        * Because this is called with p->pi_lock held, it is not possible
>> +        * to use kfree() here (when PREEMPT_RT=y), therefore punt to using
>> +        * kfree_rcu().
>> +        */
>> +       kfree_rcu((union cpumask_rcuhead *)ac.user_mask, rcu);
>>   }
>>
>>   int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
>> @@ -8196,7 +8206,7 @@ long sched_setaffinity(pid_t pid, const struct cpumask
>> *in_mask)
>>          struct affinity_context ac;
>>          struct cpumask *user_mask;
>>          struct task_struct *p;
>> -       int retval;
>> +       int retval, size;
>>
>>          rcu_read_lock();
>>
>> @@ -8229,7 +8239,11 @@ long sched_setaffinity(pid_t pid, const struct
>> cpumask *in_mask)
>>          if (retval)
>>                  goto out_put_task;
>>
>> -       user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
>> +       /*
>> +        * See do_set_cpus_allowed() for the rcu_head usage.
>> +        */
>> +       size = max_t(int, cpumask_size(), sizeof(union cpumask_rcuhead));
>> +       user_mask = kmalloc(size, GFP_KERNEL);
>>          if (!user_mask) {
>>                  retval = -ENOMEM;
>>                  goto out_put_task;
>>
> We also should fix the allocation in dup_user_cpus_ptr() -- perhaps pull
> the thing into a helper.
>
I have just sent out a new patch to fix that before I saw your email. I 
do forgot to put -tip in the subject line.

Cheers,
Longman


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed()
  2022-11-22 19:30           ` Waiman Long
@ 2022-11-22 19:58             ` Peter Zijlstra
  0 siblings, 0 replies; 9+ messages in thread
From: Peter Zijlstra @ 2022-11-22 19:58 UTC (permalink / raw)
  To: Waiman Long
  Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
	Steven Rostedt, Ben Segall, Mel Gorman,
	Daniel Bristot de Oliveira, Phil Auld, linux-kernel,
	Paul McKenney

On Tue, Nov 22, 2022 at 02:30:38PM -0500, Waiman Long wrote:

> I have just sent out a new patch to fix that before I saw your email. I do
> forgot to put -tip in the subject line.

I found it; I'll stare at it in the morning. Things don't seem to want
to make much sense anymore today :-)

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-11-22 19:59 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-18 19:33 [PATCH-tip] sched: Don't call kfree() in do_set_cpus_allowed() Waiman Long
2022-11-21 10:38 ` Peter Zijlstra
2022-11-21 15:04   ` Waiman Long
2022-11-22 12:37     ` Peter Zijlstra
2022-11-22 15:23       ` Waiman Long
2022-11-22 16:33         ` Paul E. McKenney
2022-11-22 19:24         ` Peter Zijlstra
2022-11-22 19:30           ` Waiman Long
2022-11-22 19:58             ` Peter Zijlstra

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.