public inbox for [email protected]
 help / color / mirror / Atom feed
* [PATCH] io_uring: execute task_work_run() before dropping mm
@ 2020-06-06 15:12 Xiaoguang Wang
  2020-06-06 15:55 ` Pavel Begunkov
  2020-06-06 18:50 ` Jens Axboe
  0 siblings, 2 replies; 7+ messages in thread
From: Xiaoguang Wang @ 2020-06-06 15:12 UTC (permalink / raw)
  To: io-uring; +Cc: axboe, asml.silence, joseph.qi, Xiaoguang Wang

While testing io_uring in our internal kernel, note it's not upstream
kernel, we see below panic:
[  872.498723] x29: ffff00002d553cf0 x28: 0000000000000000
[  872.508973] x27: ffff807ef691a0e0 x26: 0000000000000000
[  872.519116] x25: 0000000000000000 x24: ffff0000090a7980
[  872.529184] x23: ffff000009272060 x22: 0000000100022b11
[  872.539144] x21: 0000000046aa5668 x20: ffff80bee8562b18
[  872.549000] x19: ffff80bee8562080 x18: 0000000000000000
[  872.558876] x17: 0000000000000000 x16: 0000000000000000
[  872.568976] x15: 0000000000000000 x14: 0000000000000000
[  872.578762] x13: 0000000000000000 x12: 0000000000000000
[  872.588474] x11: 0000000000000000 x10: 0000000000000c40
[  872.598324] x9 : ffff000008100c00 x8 : 000000007ffff000
[  872.608014] x7 : ffff80bee8562080 x6 : ffff80beea862d30
[  872.617709] x5 : 0000000000000000 x4 : ffff80beea862d48
[  872.627399] x3 : ffff80bee8562b18 x2 : 0000000000000000
[  872.637044] x1 : ffff0000090a7000 x0 : 0000000000208040
[  872.646575] Call trace:
[  872.653139]  task_numa_work+0x4c/0x310
[  872.660916]  task_work_run+0xb0/0xe0
[  872.668400]  io_sq_thread+0x164/0x388
[  872.675829]  kthread+0x108/0x138

The reason is that once io_sq_thread has a valid mm, schedule subsystem
may call task_tick_numa() adding a task_numa_work() callback, which will
visit mm, then above panic will happen.

To fix this bug, only call task_work_run() before dropping mm.

Signed-off-by: Xiaoguang Wang <[email protected]>
---
 fs/io_uring.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 6391a00ff8b7..32381984b2a6 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -6134,6 +6134,13 @@ static int io_sq_thread(void *data)
 		 * to enter the kernel to reap and flush events.
 		 */
 		if (!to_submit || ret == -EBUSY) {
+			/*
+			 * Current task context may already have valid mm, that
+			 * means some works that visit mm may have been queued,
+			 * so we must execute the works before dropping mm.
+			 */
+			if (current->task_works)
+				task_work_run();
 			/*
 			 * Drop cur_mm before scheduling, we can't hold it for
 			 * long periods (or over schedule()). Do this before
@@ -6152,8 +6159,6 @@ static int io_sq_thread(void *data)
 			if (!list_empty(&ctx->poll_list) ||
 			    (!time_after(jiffies, timeout) && ret != -EBUSY &&
 			    !percpu_ref_is_dying(&ctx->refs))) {
-				if (current->task_works)
-					task_work_run();
 				cond_resched();
 				continue;
 			}
@@ -6185,11 +6190,7 @@ static int io_sq_thread(void *data)
 					finish_wait(&ctx->sqo_wait, &wait);
 					break;
 				}
-				if (current->task_works) {
-					task_work_run();
-					finish_wait(&ctx->sqo_wait, &wait);
-					continue;
-				}
+
 				if (signal_pending(current))
 					flush_signals(current);
 				schedule();
-- 
2.17.2


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

* Re: [PATCH] io_uring: execute task_work_run() before dropping mm
  2020-06-06 15:12 [PATCH] io_uring: execute task_work_run() before dropping mm Xiaoguang Wang
@ 2020-06-06 15:55 ` Pavel Begunkov
  2020-06-06 16:39   ` Pavel Begunkov
  2020-06-07 12:37   ` Xiaoguang Wang
  2020-06-06 18:50 ` Jens Axboe
  1 sibling, 2 replies; 7+ messages in thread
From: Pavel Begunkov @ 2020-06-06 15:55 UTC (permalink / raw)
  To: Xiaoguang Wang, io-uring; +Cc: axboe, joseph.qi

On 06/06/2020 18:12, Xiaoguang Wang wrote:
> While testing io_uring in our internal kernel, note it's not upstream
> kernel, we see below panic:
> [  872.498723] x29: ffff00002d553cf0 x28: 0000000000000000
> [  872.508973] x27: ffff807ef691a0e0 x26: 0000000000000000
> [  872.519116] x25: 0000000000000000 x24: ffff0000090a7980
> [  872.529184] x23: ffff000009272060 x22: 0000000100022b11
> [  872.539144] x21: 0000000046aa5668 x20: ffff80bee8562b18
> [  872.549000] x19: ffff80bee8562080 x18: 0000000000000000
> [  872.558876] x17: 0000000000000000 x16: 0000000000000000
> [  872.568976] x15: 0000000000000000 x14: 0000000000000000
> [  872.578762] x13: 0000000000000000 x12: 0000000000000000
> [  872.588474] x11: 0000000000000000 x10: 0000000000000c40
> [  872.598324] x9 : ffff000008100c00 x8 : 000000007ffff000
> [  872.608014] x7 : ffff80bee8562080 x6 : ffff80beea862d30
> [  872.617709] x5 : 0000000000000000 x4 : ffff80beea862d48
> [  872.627399] x3 : ffff80bee8562b18 x2 : 0000000000000000
> [  872.637044] x1 : ffff0000090a7000 x0 : 0000000000208040
> [  872.646575] Call trace:
> [  872.653139]  task_numa_work+0x4c/0x310
> [  872.660916]  task_work_run+0xb0/0xe0
> [  872.668400]  io_sq_thread+0x164/0x388
> [  872.675829]  kthread+0x108/0x138
> 
> The reason is that once io_sq_thread has a valid mm, schedule subsystem
> may call task_tick_numa() adding a task_numa_work() callback, which will
> visit mm, then above panic will happen.
> 
> To fix this bug, only call task_work_run() before dropping mm.

So, the problem is that poll/async paths re-issue requests with
__io_queue_sqe(), which doesn't care about current->mm, and which
can be NULL for io_sq_thread(). Right?

> 
> Signed-off-by: Xiaoguang Wang <[email protected]>
> ---
>  fs/io_uring.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 6391a00ff8b7..32381984b2a6 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -6134,6 +6134,13 @@ static int io_sq_thread(void *data)
>  		 * to enter the kernel to reap and flush events.
>  		 */
>  		if (!to_submit || ret == -EBUSY) {
> +			/*
> +			 * Current task context may already have valid mm, that
> +			 * means some works that visit mm may have been queued,
> +			 * so we must execute the works before dropping mm.
> +			 */
> +			if (current->task_works)
> +				task_work_run();

Even though you're not dropping mm, the thread might not have it in the first
place. see how it's done in io_init_req(). How about setting mm either lazily
in io_poll_task_func()/io_async_task_func(), or before task_work_run() in
io_sq_thread().

>  			/*
>  			 * Drop cur_mm before scheduling, we can't hold it for
>  			 * long periods (or over schedule()). Do this before
> @@ -6152,8 +6159,6 @@ static int io_sq_thread(void *data)
>  			if (!list_empty(&ctx->poll_list) ||
>  			    (!time_after(jiffies, timeout) && ret != -EBUSY &&
>  			    !percpu_ref_is_dying(&ctx->refs))) {
> -				if (current->task_works)
> -					task_work_run();
>  				cond_resched();
>  				continue;
>  			}
> @@ -6185,11 +6190,7 @@ static int io_sq_thread(void *data)
>  					finish_wait(&ctx->sqo_wait, &wait);
>  					break;
>  				}
> -				if (current->task_works) {
> -					task_work_run();
> -					finish_wait(&ctx->sqo_wait, &wait);
> -					continue;
> -				}
> +
>  				if (signal_pending(current))
>  					flush_signals(current);
>  				schedule();
> 

-- 
Pavel Begunkov

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

* Re: [PATCH] io_uring: execute task_work_run() before dropping mm
  2020-06-06 15:55 ` Pavel Begunkov
@ 2020-06-06 16:39   ` Pavel Begunkov
  2020-06-07 12:37   ` Xiaoguang Wang
  1 sibling, 0 replies; 7+ messages in thread
From: Pavel Begunkov @ 2020-06-06 16:39 UTC (permalink / raw)
  To: Xiaoguang Wang, io-uring; +Cc: axboe, joseph.qi

On 06/06/2020 18:55, Pavel Begunkov wrote:
> On 06/06/2020 18:12, Xiaoguang Wang wrote:
>> While testing io_uring in our internal kernel, note it's not upstream
>> kernel, we see below panic:
>> [  872.498723] x29: ffff00002d553cf0 x28: 0000000000000000
>> [  872.508973] x27: ffff807ef691a0e0 x26: 0000000000000000
>> [  872.519116] x25: 0000000000000000 x24: ffff0000090a7980
>> [  872.529184] x23: ffff000009272060 x22: 0000000100022b11
>> [  872.539144] x21: 0000000046aa5668 x20: ffff80bee8562b18
>> [  872.549000] x19: ffff80bee8562080 x18: 0000000000000000
>> [  872.558876] x17: 0000000000000000 x16: 0000000000000000
>> [  872.568976] x15: 0000000000000000 x14: 0000000000000000
>> [  872.578762] x13: 0000000000000000 x12: 0000000000000000
>> [  872.588474] x11: 0000000000000000 x10: 0000000000000c40
>> [  872.598324] x9 : ffff000008100c00 x8 : 000000007ffff000
>> [  872.608014] x7 : ffff80bee8562080 x6 : ffff80beea862d30
>> [  872.617709] x5 : 0000000000000000 x4 : ffff80beea862d48
>> [  872.627399] x3 : ffff80bee8562b18 x2 : 0000000000000000
>> [  872.637044] x1 : ffff0000090a7000 x0 : 0000000000208040
>> [  872.646575] Call trace:
>> [  872.653139]  task_numa_work+0x4c/0x310
>> [  872.660916]  task_work_run+0xb0/0xe0
>> [  872.668400]  io_sq_thread+0x164/0x388
>> [  872.675829]  kthread+0x108/0x138
>>
>> The reason is that once io_sq_thread has a valid mm, schedule subsystem
>> may call task_tick_numa() adding a task_numa_work() callback, which will
>> visit mm, then above panic will happen.
>>
>> To fix this bug, only call task_work_run() before dropping mm.
> 
> So, the problem is that poll/async paths re-issue requests with
> __io_queue_sqe(), which doesn't care about current->mm, and which
> can be NULL for io_sq_thread(). Right?
> 
>>
>> Signed-off-by: Xiaoguang Wang <[email protected]>
>> ---
>>  fs/io_uring.c | 15 ++++++++-------
>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>> index 6391a00ff8b7..32381984b2a6 100644
>> --- a/fs/io_uring.c
>> +++ b/fs/io_uring.c
>> @@ -6134,6 +6134,13 @@ static int io_sq_thread(void *data)
>>  		 * to enter the kernel to reap and flush events.
>>  		 */
>>  		if (!to_submit || ret == -EBUSY) {
>> +			/*
>> +			 * Current task context may already have valid mm, that
>> +			 * means some works that visit mm may have been queued,
>> +			 * so we must execute the works before dropping mm.
>> +			 */
>> +			if (current->task_works)
>> +				task_work_run();
> 
> Even though you're not dropping mm, the thread might not have it in the first
> place. see how it's done in io_init_req(). How about setting mm either lazily
> in io_poll_task_func()/io_async_task_func(), or before task_work_run() in
> io_sq_thread().

Thinking about use_mm(), it's more about setting up env before execution rather
than request intialisation. Another way would be to move use_mm() from io_init_req()
into __io_queue_sqe(), more clearly separating responsibilities.

BTW, it may need adding extra io_sq_thread_drop_mm() either way

> 
>>  			/*
>>  			 * Drop cur_mm before scheduling, we can't hold it for
>>  			 * long periods (or over schedule()). Do this before
>> @@ -6152,8 +6159,6 @@ static int io_sq_thread(void *data)
>>  			if (!list_empty(&ctx->poll_list) ||
>>  			    (!time_after(jiffies, timeout) && ret != -EBUSY &&
>>  			    !percpu_ref_is_dying(&ctx->refs))) {
>> -				if (current->task_works)
>> -					task_work_run();
>>  				cond_resched();
>>  				continue;
>>  			}
>> @@ -6185,11 +6190,7 @@ static int io_sq_thread(void *data)
>>  					finish_wait(&ctx->sqo_wait, &wait);
>>  					break;
>>  				}
>> -				if (current->task_works) {
>> -					task_work_run();
>> -					finish_wait(&ctx->sqo_wait, &wait);
>> -					continue;
>> -				}
>> +
>>  				if (signal_pending(current))
>>  					flush_signals(current);
>>  				schedule();
>>
> 

-- 
Pavel Begunkov

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

* Re: [PATCH] io_uring: execute task_work_run() before dropping mm
  2020-06-06 15:12 [PATCH] io_uring: execute task_work_run() before dropping mm Xiaoguang Wang
  2020-06-06 15:55 ` Pavel Begunkov
@ 2020-06-06 18:50 ` Jens Axboe
  2020-06-07 11:41   ` Xiaoguang Wang
  1 sibling, 1 reply; 7+ messages in thread
From: Jens Axboe @ 2020-06-06 18:50 UTC (permalink / raw)
  To: Xiaoguang Wang, io-uring; +Cc: asml.silence, joseph.qi

On 6/6/20 9:12 AM, Xiaoguang Wang wrote:
> While testing io_uring in our internal kernel, note it's not upstream
> kernel, we see below panic:
> [  872.498723] x29: ffff00002d553cf0 x28: 0000000000000000
> [  872.508973] x27: ffff807ef691a0e0 x26: 0000000000000000
> [  872.519116] x25: 0000000000000000 x24: ffff0000090a7980
> [  872.529184] x23: ffff000009272060 x22: 0000000100022b11
> [  872.539144] x21: 0000000046aa5668 x20: ffff80bee8562b18
> [  872.549000] x19: ffff80bee8562080 x18: 0000000000000000
> [  872.558876] x17: 0000000000000000 x16: 0000000000000000
> [  872.568976] x15: 0000000000000000 x14: 0000000000000000
> [  872.578762] x13: 0000000000000000 x12: 0000000000000000
> [  872.588474] x11: 0000000000000000 x10: 0000000000000c40
> [  872.598324] x9 : ffff000008100c00 x8 : 000000007ffff000
> [  872.608014] x7 : ffff80bee8562080 x6 : ffff80beea862d30
> [  872.617709] x5 : 0000000000000000 x4 : ffff80beea862d48
> [  872.627399] x3 : ffff80bee8562b18 x2 : 0000000000000000
> [  872.637044] x1 : ffff0000090a7000 x0 : 0000000000208040
> [  872.646575] Call trace:
> [  872.653139]  task_numa_work+0x4c/0x310
> [  872.660916]  task_work_run+0xb0/0xe0
> [  872.668400]  io_sq_thread+0x164/0x388
> [  872.675829]  kthread+0x108/0x138
> 
> The reason is that once io_sq_thread has a valid mm, schedule subsystem
> may call task_tick_numa() adding a task_numa_work() callback, which will
> visit mm, then above panic will happen.> 
> To fix this bug, only call task_work_run() before dropping mm.

That's a bug outside of io_uring, you'll want to backport this patch
from 5.7:

commit 18f855e574d9799a0e7489f8ae6fd8447d0dd74a
Author: Jens Axboe <[email protected]>
Date:   Tue May 26 09:38:31 2020 -0600

    sched/fair: Don't NUMA balance for kthreads


-- 
Jens Axboe


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

* Re: [PATCH] io_uring: execute task_work_run() before dropping mm
  2020-06-06 18:50 ` Jens Axboe
@ 2020-06-07 11:41   ` Xiaoguang Wang
  0 siblings, 0 replies; 7+ messages in thread
From: Xiaoguang Wang @ 2020-06-07 11:41 UTC (permalink / raw)
  To: Jens Axboe, io-uring; +Cc: asml.silence, joseph.qi

hi,

> On 6/6/20 9:12 AM, Xiaoguang Wang wrote:
>> While testing io_uring in our internal kernel, note it's not upstream
>> kernel, we see below panic:
>> [  872.498723] x29: ffff00002d553cf0 x28: 0000000000000000
>> [  872.508973] x27: ffff807ef691a0e0 x26: 0000000000000000
>> [  872.519116] x25: 0000000000000000 x24: ffff0000090a7980
>> [  872.529184] x23: ffff000009272060 x22: 0000000100022b11
>> [  872.539144] x21: 0000000046aa5668 x20: ffff80bee8562b18
>> [  872.549000] x19: ffff80bee8562080 x18: 0000000000000000
>> [  872.558876] x17: 0000000000000000 x16: 0000000000000000
>> [  872.568976] x15: 0000000000000000 x14: 0000000000000000
>> [  872.578762] x13: 0000000000000000 x12: 0000000000000000
>> [  872.588474] x11: 0000000000000000 x10: 0000000000000c40
>> [  872.598324] x9 : ffff000008100c00 x8 : 000000007ffff000
>> [  872.608014] x7 : ffff80bee8562080 x6 : ffff80beea862d30
>> [  872.617709] x5 : 0000000000000000 x4 : ffff80beea862d48
>> [  872.627399] x3 : ffff80bee8562b18 x2 : 0000000000000000
>> [  872.637044] x1 : ffff0000090a7000 x0 : 0000000000208040
>> [  872.646575] Call trace:
>> [  872.653139]  task_numa_work+0x4c/0x310
>> [  872.660916]  task_work_run+0xb0/0xe0
>> [  872.668400]  io_sq_thread+0x164/0x388
>> [  872.675829]  kthread+0x108/0x138
>>
>> The reason is that once io_sq_thread has a valid mm, schedule subsystem
>> may call task_tick_numa() adding a task_numa_work() callback, which will
>> visit mm, then above panic will happen.>
>> To fix this bug, only call task_work_run() before dropping mm.
> 
> That's a bug outside of io_uring, you'll want to backport this patch
> from 5.7:
> 
> commit 18f855e574d9799a0e7489f8ae6fd8447d0dd74a
> Author: Jens Axboe <[email protected]>
> Date:   Tue May 26 09:38:31 2020 -0600
> 
>      sched/fair: Don't NUMA balance for kthreadsThanks, it's a better fix than mine, will backport it.

Regards,
Xiaoguang Wang

> 
> 

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

* Re: [PATCH] io_uring: execute task_work_run() before dropping mm
  2020-06-06 15:55 ` Pavel Begunkov
  2020-06-06 16:39   ` Pavel Begunkov
@ 2020-06-07 12:37   ` Xiaoguang Wang
  2020-06-07 15:36     ` Pavel Begunkov
  1 sibling, 1 reply; 7+ messages in thread
From: Xiaoguang Wang @ 2020-06-07 12:37 UTC (permalink / raw)
  To: Pavel Begunkov, io-uring; +Cc: axboe, joseph.qi

hi,

> On 06/06/2020 18:12, Xiaoguang Wang wrote:
>> While testing io_uring in our internal kernel, note it's not upstream
>> kernel, we see below panic:
>> [  872.498723] x29: ffff00002d553cf0 x28: 0000000000000000
>> [  872.508973] x27: ffff807ef691a0e0 x26: 0000000000000000
>> [  872.519116] x25: 0000000000000000 x24: ffff0000090a7980
>> [  872.529184] x23: ffff000009272060 x22: 0000000100022b11
>> [  872.539144] x21: 0000000046aa5668 x20: ffff80bee8562b18
>> [  872.549000] x19: ffff80bee8562080 x18: 0000000000000000
>> [  872.558876] x17: 0000000000000000 x16: 0000000000000000
>> [  872.568976] x15: 0000000000000000 x14: 0000000000000000
>> [  872.578762] x13: 0000000000000000 x12: 0000000000000000
>> [  872.588474] x11: 0000000000000000 x10: 0000000000000c40
>> [  872.598324] x9 : ffff000008100c00 x8 : 000000007ffff000
>> [  872.608014] x7 : ffff80bee8562080 x6 : ffff80beea862d30
>> [  872.617709] x5 : 0000000000000000 x4 : ffff80beea862d48
>> [  872.627399] x3 : ffff80bee8562b18 x2 : 0000000000000000
>> [  872.637044] x1 : ffff0000090a7000 x0 : 0000000000208040
>> [  872.646575] Call trace:
>> [  872.653139]  task_numa_work+0x4c/0x310
>> [  872.660916]  task_work_run+0xb0/0xe0
>> [  872.668400]  io_sq_thread+0x164/0x388
>> [  872.675829]  kthread+0x108/0x138
>>
>> The reason is that once io_sq_thread has a valid mm, schedule subsystem
>> may call task_tick_numa() adding a task_numa_work() callback, which will
>> visit mm, then above panic will happen.
>>
>> To fix this bug, only call task_work_run() before dropping mm.
> 
> So, the problem is that poll/async paths re-issue requests with
> __io_queue_sqe(), which doesn't care about current->mm, and which
> can be NULL for io_sq_thread(). Right?
No, above panic is not triggered by poll/async paths.
See below code path:
==> task_tick_fair()
====> task_tick_numa()
======> task_work_add, work is task_numa_work, which will visit mm.

In sqpoll mode, there maybe are sqes that need mm, then above codes
maybe executed by schedule subsystem. In io_sq_thread, we drop mm before
task_work_run, if there is a task_numa_work, panic occurs.

Regards,
Xiaoguang Wang
> 
>>
>> Signed-off-by: Xiaoguang Wang <[email protected]>
>> ---
>>   fs/io_uring.c | 15 ++++++++-------
>>   1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>> index 6391a00ff8b7..32381984b2a6 100644
>> --- a/fs/io_uring.c
>> +++ b/fs/io_uring.c
>> @@ -6134,6 +6134,13 @@ static int io_sq_thread(void *data)
>>   		 * to enter the kernel to reap and flush events.
>>   		 */
>>   		if (!to_submit || ret == -EBUSY) {
>> +			/*
>> +			 * Current task context may already have valid mm, that
>> +			 * means some works that visit mm may have been queued,
>> +			 * so we must execute the works before dropping mm.
>> +			 */
>> +			if (current->task_works)
>> +				task_work_run();
> 
> Even though you're not dropping mm, the thread might not have it in the first
> place. see how it's done in io_init_req(). How about setting mm either lazily
> in io_poll_task_func()/io_async_task_func(), or before task_work_run() in
> io_sq_thread().
> 
>>   			/*
>>   			 * Drop cur_mm before scheduling, we can't hold it for
>>   			 * long periods (or over schedule()). Do this before
>> @@ -6152,8 +6159,6 @@ static int io_sq_thread(void *data)
>>   			if (!list_empty(&ctx->poll_list) ||
>>   			    (!time_after(jiffies, timeout) && ret != -EBUSY &&
>>   			    !percpu_ref_is_dying(&ctx->refs))) {
>> -				if (current->task_works)
>> -					task_work_run();
>>   				cond_resched();
>>   				continue;
>>   			}
>> @@ -6185,11 +6190,7 @@ static int io_sq_thread(void *data)
>>   					finish_wait(&ctx->sqo_wait, &wait);
>>   					break;
>>   				}
>> -				if (current->task_works) {
>> -					task_work_run();
>> -					finish_wait(&ctx->sqo_wait, &wait);
>> -					continue;
>> -				}
>> +
>>   				if (signal_pending(current))
>>   					flush_signals(current);
>>   				schedule();
>>
> 

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

* Re: [PATCH] io_uring: execute task_work_run() before dropping mm
  2020-06-07 12:37   ` Xiaoguang Wang
@ 2020-06-07 15:36     ` Pavel Begunkov
  0 siblings, 0 replies; 7+ messages in thread
From: Pavel Begunkov @ 2020-06-07 15:36 UTC (permalink / raw)
  To: Xiaoguang Wang, io-uring; +Cc: axboe, joseph.qi

On 07/06/2020 15:37, Xiaoguang Wang wrote:
>>> The reason is that once io_sq_thread has a valid mm, schedule subsystem
>>> may call task_tick_numa() adding a task_numa_work() callback, which will
>>> visit mm, then above panic will happen.
>>>
>>> To fix this bug, only call task_work_run() before dropping mm.
>>
>> So, the problem is that poll/async paths re-issue requests with
>> __io_queue_sqe(), which doesn't care about current->mm, and which
>> can be NULL for io_sq_thread(). Right?
> No, above panic is not triggered by poll/async paths.
> See below code path:
> ==> task_tick_fair()
> ====> task_tick_numa()
> ======> task_work_add, work is task_numa_work, which will visit mm.
> 
> In sqpoll mode, there maybe are sqes that need mm, then above codes
> maybe executed by schedule subsystem. In io_sq_thread, we drop mm before
> task_work_run, if there is a task_numa_work, panic occurs.
> 

Got it, thanks for explaining

-- 
Pavel Begunkov

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

end of thread, other threads:[~2020-06-07 15:38 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-06-06 15:12 [PATCH] io_uring: execute task_work_run() before dropping mm Xiaoguang Wang
2020-06-06 15:55 ` Pavel Begunkov
2020-06-06 16:39   ` Pavel Begunkov
2020-06-07 12:37   ` Xiaoguang Wang
2020-06-07 15:36     ` Pavel Begunkov
2020-06-06 18:50 ` Jens Axboe
2020-06-07 11:41   ` Xiaoguang Wang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox