All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/3 v4 bpf-next] bpf: increment and use correct thread iterator
@ 2020-12-18 18:50 Jonathan Lemon
  2020-12-18 18:50 ` [PATCH 1/3 v4 bpf-next] bpf: save correct stopping point in file seq iteration Jonathan Lemon
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Jonathan Lemon @ 2020-12-18 18:50 UTC (permalink / raw)
  To: netdev, ast, daniel, yhs, bpf; +Cc: kernel-team

From: Jonathan Lemon <bsd@fb.com>

v3->v4:
  Split commit into separate patches.
v2->v3:
  Add splat to commitlog descriptions
v1->v2
  Use Fixes: shas from correct tree

Jonathan Lemon (3):
  bpf: save correct stopping point in file seq iteration.
  bpf: Use thread_group_leader()
  bpf: optimize task iteration

 kernel/bpf/task_iter.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

-- 
2.24.1


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

* [PATCH 1/3 v4 bpf-next] bpf: save correct stopping point in file seq iteration.
  2020-12-18 18:50 [PATCH 0/3 v4 bpf-next] bpf: increment and use correct thread iterator Jonathan Lemon
@ 2020-12-18 18:50 ` Jonathan Lemon
  2020-12-18 21:01   ` Andrii Nakryiko
  2020-12-18 18:50 ` [PATCH 2/3 v4 bpf-next] bpf: Use thread_group_leader() Jonathan Lemon
  2020-12-18 18:50 ` [PATCH 3/3 v4 bpf-next] bpf: optimize task iteration Jonathan Lemon
  2 siblings, 1 reply; 8+ messages in thread
From: Jonathan Lemon @ 2020-12-18 18:50 UTC (permalink / raw)
  To: netdev, ast, daniel, yhs, bpf; +Cc: kernel-team

From: Jonathan Lemon <bsd@fb.com>

On some systems, some variant of the following splat is
repeatedly seen.  The common factor in all traces seems
to be the entry point to task_file_seq_next().  With the
patch, all warnings go away.

    rcu: INFO: rcu_sched self-detected stall on CPU
    rcu: \x0926-....: (20992 ticks this GP) idle=d7e/1/0x4000000000000002 softirq=81556231/81556231 fqs=4876
    \x09(t=21033 jiffies g=159148529 q=223125)
    NMI backtrace for cpu 26
    CPU: 26 PID: 2015853 Comm: bpftool Kdump: loaded Not tainted 5.6.13-0_fbk4_3876_gd8d1f9bf80bb #1
    Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A12 10/08/2018
    Call Trace:
     <IRQ>
     dump_stack+0x50/0x70
     nmi_cpu_backtrace.cold.6+0x13/0x50
     ? lapic_can_unplug_cpu.cold.30+0x40/0x40
     nmi_trigger_cpumask_backtrace+0xba/0xca
     rcu_dump_cpu_stacks+0x99/0xc7
     rcu_sched_clock_irq.cold.90+0x1b4/0x3aa
     ? tick_sched_do_timer+0x60/0x60
     update_process_times+0x24/0x50
     tick_sched_timer+0x37/0x70
     __hrtimer_run_queues+0xfe/0x270
     hrtimer_interrupt+0xf4/0x210
     smp_apic_timer_interrupt+0x5e/0x120
     apic_timer_interrupt+0xf/0x20
     </IRQ>
    RIP: 0010:get_pid_task+0x38/0x80
    Code: 89 f6 48 8d 44 f7 08 48 8b 00 48 85 c0 74 2b 48 83 c6 55 48 c1 e6 04 48 29 f0 74 19 48 8d 78 20 ba 01 00 00 00 f0 0f c1 50 20 <85> d2 74 27 78 11 83 c2 01 78 0c 48 83 c4 08 c3 31 c0 48 83 c4 08
    RSP: 0018:ffffc9000d293dc8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13
    RAX: ffff888637c05600 RBX: ffffc9000d293e0c RCX: 0000000000000000
    RDX: 0000000000000001 RSI: 0000000000000550 RDI: ffff888637c05620
    RBP: ffffffff8284eb80 R08: ffff88831341d300 R09: ffff88822ffd8248
    R10: ffff88822ffd82d0 R11: 00000000003a93c0 R12: 0000000000000001
    R13: 00000000ffffffff R14: ffff88831341d300 R15: 0000000000000000
     ? find_ge_pid+0x1b/0x20
     task_seq_get_next+0x52/0xc0
     task_file_seq_get_next+0x159/0x220
     task_file_seq_next+0x4f/0xa0
     bpf_seq_read+0x159/0x390
     vfs_read+0x8a/0x140
     ksys_read+0x59/0xd0
     do_syscall_64+0x42/0x110
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x7f95ae73e76e
    Code: Bad RIP value.
    RSP: 002b:00007ffc02c1dbf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
    RAX: ffffffffffffffda RBX: 000000000170faa0 RCX: 00007f95ae73e76e
    RDX: 0000000000001000 RSI: 00007ffc02c1dc30 RDI: 0000000000000007
    RBP: 00007ffc02c1ec70 R08: 0000000000000005 R09: 0000000000000006
    R10: fffffffffffff20b R11: 0000000000000246 R12: 00000000019112a0
    R13: 0000000000000000 R14: 0000000000000007 R15: 00000000004283c0

If unable to obtain the file structure for the current task,
proceed to the next task number after the one returned from
task_seq_get_next(), instead of the next task number from the
original iterator.

Also, save the stopping task number from task_seq_get_next()
on failure in case of restarts.

Fixes: a650da2ee52a ("bpf: Add task and task/file iterator targets")
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
---
 kernel/bpf/task_iter.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
index 0458a40edf10..8033ab19138a 100644
--- a/kernel/bpf/task_iter.c
+++ b/kernel/bpf/task_iter.c
@@ -158,13 +158,14 @@ task_file_seq_get_next(struct bpf_iter_seq_task_file_info *info)
 		if (!curr_task) {
 			info->task = NULL;
 			info->files = NULL;
+			info->tid = curr_tid;
 			return NULL;
 		}
 
 		curr_files = get_files_struct(curr_task);
 		if (!curr_files) {
 			put_task_struct(curr_task);
-			curr_tid = ++(info->tid);
+			curr_tid = curr_tid + 1;
 			info->fd = 0;
 			goto again;
 		}
-- 
2.24.1


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

* [PATCH 2/3 v4 bpf-next] bpf: Use thread_group_leader()
  2020-12-18 18:50 [PATCH 0/3 v4 bpf-next] bpf: increment and use correct thread iterator Jonathan Lemon
  2020-12-18 18:50 ` [PATCH 1/3 v4 bpf-next] bpf: save correct stopping point in file seq iteration Jonathan Lemon
@ 2020-12-18 18:50 ` Jonathan Lemon
  2020-12-18 21:02   ` Andrii Nakryiko
  2020-12-18 18:50 ` [PATCH 3/3 v4 bpf-next] bpf: optimize task iteration Jonathan Lemon
  2 siblings, 1 reply; 8+ messages in thread
From: Jonathan Lemon @ 2020-12-18 18:50 UTC (permalink / raw)
  To: netdev, ast, daniel, yhs, bpf; +Cc: kernel-team

From: Jonathan Lemon <bsd@fb.com>

Instead of directly comparing task->tgid and task->pid, use the
thread_group_leader() helper.  This helps with readability, and
there should be no functional change.

Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
---
 kernel/bpf/task_iter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
index 8033ab19138a..dc4007f1843b 100644
--- a/kernel/bpf/task_iter.c
+++ b/kernel/bpf/task_iter.c
@@ -37,7 +37,7 @@ static struct task_struct *task_seq_get_next(struct pid_namespace *ns,
 		if (!task) {
 			++*tid;
 			goto retry;
-		} else if (skip_if_dup_files && task->tgid != task->pid &&
+		} else if (skip_if_dup_files && !thread_group_leader(task) &&
 			   task->files == task->group_leader->files) {
 			put_task_struct(task);
 			task = NULL;
-- 
2.24.1


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

* [PATCH 3/3 v4 bpf-next] bpf: optimize task iteration
  2020-12-18 18:50 [PATCH 0/3 v4 bpf-next] bpf: increment and use correct thread iterator Jonathan Lemon
  2020-12-18 18:50 ` [PATCH 1/3 v4 bpf-next] bpf: save correct stopping point in file seq iteration Jonathan Lemon
  2020-12-18 18:50 ` [PATCH 2/3 v4 bpf-next] bpf: Use thread_group_leader() Jonathan Lemon
@ 2020-12-18 18:50 ` Jonathan Lemon
  2020-12-18 21:03   ` Andrii Nakryiko
  2 siblings, 1 reply; 8+ messages in thread
From: Jonathan Lemon @ 2020-12-18 18:50 UTC (permalink / raw)
  To: netdev, ast, daniel, yhs, bpf; +Cc: kernel-team

From: Jonathan Lemon <bsd@fb.com>

Only obtain the task reference count at the end of the RCU section
instead of repeatedly obtaining/releasing it when iterating though
a thread group.

Jump to the correct branch when it is known that the task is NULL.

Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
---
 kernel/bpf/task_iter.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
index dc4007f1843b..598a8d7da5bf 100644
--- a/kernel/bpf/task_iter.c
+++ b/kernel/bpf/task_iter.c
@@ -33,7 +33,7 @@ static struct task_struct *task_seq_get_next(struct pid_namespace *ns,
 	pid = find_ge_pid(*tid, ns);
 	if (pid) {
 		*tid = pid_nr_ns(pid, ns);
-		task = get_pid_task(pid, PIDTYPE_PID);
+		task = pid_task(pid, PIDTYPE_PID);
 		if (!task) {
 			++*tid;
 			goto retry;
@@ -44,6 +44,7 @@ static struct task_struct *task_seq_get_next(struct pid_namespace *ns,
 			++*tid;
 			goto retry;
 		}
+		get_task_struct(task);
 	}
 	rcu_read_unlock();
 
@@ -148,12 +149,12 @@ task_file_seq_get_next(struct bpf_iter_seq_task_file_info *info)
 	 * it held a reference to the task/files_struct/file.
 	 * Otherwise, it does not hold any reference.
 	 */
-again:
 	if (info->task) {
 		curr_task = info->task;
 		curr_files = info->files;
 		curr_fd = info->fd;
 	} else {
+again:
 		curr_task = task_seq_get_next(ns, &curr_tid, true);
 		if (!curr_task) {
 			info->task = NULL;
-- 
2.24.1


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

* Re: [PATCH 1/3 v4 bpf-next] bpf: save correct stopping point in file seq iteration.
  2020-12-18 18:50 ` [PATCH 1/3 v4 bpf-next] bpf: save correct stopping point in file seq iteration Jonathan Lemon
@ 2020-12-18 21:01   ` Andrii Nakryiko
  2020-12-24  1:08     ` Daniel Borkmann
  0 siblings, 1 reply; 8+ messages in thread
From: Andrii Nakryiko @ 2020-12-18 21:01 UTC (permalink / raw)
  To: Jonathan Lemon
  Cc: Networking, Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
	bpf, Kernel Team

On Fri, Dec 18, 2020 at 12:47 PM Jonathan Lemon
<jonathan.lemon@gmail.com> wrote:
>
> From: Jonathan Lemon <bsd@fb.com>
>
> On some systems, some variant of the following splat is
> repeatedly seen.  The common factor in all traces seems
> to be the entry point to task_file_seq_next().  With the
> patch, all warnings go away.
>
>     rcu: INFO: rcu_sched self-detected stall on CPU
>     rcu: \x0926-....: (20992 ticks this GP) idle=d7e/1/0x4000000000000002 softirq=81556231/81556231 fqs=4876
>     \x09(t=21033 jiffies g=159148529 q=223125)
>     NMI backtrace for cpu 26
>     CPU: 26 PID: 2015853 Comm: bpftool Kdump: loaded Not tainted 5.6.13-0_fbk4_3876_gd8d1f9bf80bb #1
>     Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A12 10/08/2018
>     Call Trace:
>      <IRQ>
>      dump_stack+0x50/0x70
>      nmi_cpu_backtrace.cold.6+0x13/0x50
>      ? lapic_can_unplug_cpu.cold.30+0x40/0x40
>      nmi_trigger_cpumask_backtrace+0xba/0xca
>      rcu_dump_cpu_stacks+0x99/0xc7
>      rcu_sched_clock_irq.cold.90+0x1b4/0x3aa
>      ? tick_sched_do_timer+0x60/0x60
>      update_process_times+0x24/0x50
>      tick_sched_timer+0x37/0x70
>      __hrtimer_run_queues+0xfe/0x270
>      hrtimer_interrupt+0xf4/0x210
>      smp_apic_timer_interrupt+0x5e/0x120
>      apic_timer_interrupt+0xf/0x20
>      </IRQ>
>     RIP: 0010:get_pid_task+0x38/0x80
>     Code: 89 f6 48 8d 44 f7 08 48 8b 00 48 85 c0 74 2b 48 83 c6 55 48 c1 e6 04 48 29 f0 74 19 48 8d 78 20 ba 01 00 00 00 f0 0f c1 50 20 <85> d2 74 27 78 11 83 c2 01 78 0c 48 83 c4 08 c3 31 c0 48 83 c4 08
>     RSP: 0018:ffffc9000d293dc8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13
>     RAX: ffff888637c05600 RBX: ffffc9000d293e0c RCX: 0000000000000000
>     RDX: 0000000000000001 RSI: 0000000000000550 RDI: ffff888637c05620
>     RBP: ffffffff8284eb80 R08: ffff88831341d300 R09: ffff88822ffd8248
>     R10: ffff88822ffd82d0 R11: 00000000003a93c0 R12: 0000000000000001
>     R13: 00000000ffffffff R14: ffff88831341d300 R15: 0000000000000000
>      ? find_ge_pid+0x1b/0x20
>      task_seq_get_next+0x52/0xc0
>      task_file_seq_get_next+0x159/0x220
>      task_file_seq_next+0x4f/0xa0
>      bpf_seq_read+0x159/0x390
>      vfs_read+0x8a/0x140
>      ksys_read+0x59/0xd0
>      do_syscall_64+0x42/0x110
>      entry_SYSCALL_64_after_hwframe+0x44/0xa9
>     RIP: 0033:0x7f95ae73e76e
>     Code: Bad RIP value.
>     RSP: 002b:00007ffc02c1dbf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
>     RAX: ffffffffffffffda RBX: 000000000170faa0 RCX: 00007f95ae73e76e
>     RDX: 0000000000001000 RSI: 00007ffc02c1dc30 RDI: 0000000000000007
>     RBP: 00007ffc02c1ec70 R08: 0000000000000005 R09: 0000000000000006
>     R10: fffffffffffff20b R11: 0000000000000246 R12: 00000000019112a0
>     R13: 0000000000000000 R14: 0000000000000007 R15: 00000000004283c0
>
> If unable to obtain the file structure for the current task,
> proceed to the next task number after the one returned from
> task_seq_get_next(), instead of the next task number from the
> original iterator.
>
> Also, save the stopping task number from task_seq_get_next()
> on failure in case of restarts.
>
> Fixes: a650da2ee52a ("bpf: Add task and task/file iterator targets")
> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
> ---

LGTM, thanks!

Acked-by: Andrii Nakryiko <andrii@kernel.org>

>  kernel/bpf/task_iter.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
> index 0458a40edf10..8033ab19138a 100644
> --- a/kernel/bpf/task_iter.c
> +++ b/kernel/bpf/task_iter.c
> @@ -158,13 +158,14 @@ task_file_seq_get_next(struct bpf_iter_seq_task_file_info *info)
>                 if (!curr_task) {
>                         info->task = NULL;
>                         info->files = NULL;
> +                       info->tid = curr_tid;
>                         return NULL;
>                 }
>
>                 curr_files = get_files_struct(curr_task);
>                 if (!curr_files) {
>                         put_task_struct(curr_task);
> -                       curr_tid = ++(info->tid);
> +                       curr_tid = curr_tid + 1;
>                         info->fd = 0;
>                         goto again;
>                 }
> --
> 2.24.1
>

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

* Re: [PATCH 2/3 v4 bpf-next] bpf: Use thread_group_leader()
  2020-12-18 18:50 ` [PATCH 2/3 v4 bpf-next] bpf: Use thread_group_leader() Jonathan Lemon
@ 2020-12-18 21:02   ` Andrii Nakryiko
  0 siblings, 0 replies; 8+ messages in thread
From: Andrii Nakryiko @ 2020-12-18 21:02 UTC (permalink / raw)
  To: Jonathan Lemon
  Cc: Networking, Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
	bpf, Kernel Team

On Fri, Dec 18, 2020 at 12:47 PM Jonathan Lemon
<jonathan.lemon@gmail.com> wrote:
>
> From: Jonathan Lemon <bsd@fb.com>
>
> Instead of directly comparing task->tgid and task->pid, use the
> thread_group_leader() helper.  This helps with readability, and
> there should be no functional change.
>
> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
> ---

Acked-by: Andrii Nakryiko <andrii@kernel.org>

>  kernel/bpf/task_iter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
> index 8033ab19138a..dc4007f1843b 100644
> --- a/kernel/bpf/task_iter.c
> +++ b/kernel/bpf/task_iter.c
> @@ -37,7 +37,7 @@ static struct task_struct *task_seq_get_next(struct pid_namespace *ns,
>                 if (!task) {
>                         ++*tid;
>                         goto retry;
> -               } else if (skip_if_dup_files && task->tgid != task->pid &&
> +               } else if (skip_if_dup_files && !thread_group_leader(task) &&
>                            task->files == task->group_leader->files) {
>                         put_task_struct(task);
>                         task = NULL;
> --
> 2.24.1
>

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

* Re: [PATCH 3/3 v4 bpf-next] bpf: optimize task iteration
  2020-12-18 18:50 ` [PATCH 3/3 v4 bpf-next] bpf: optimize task iteration Jonathan Lemon
@ 2020-12-18 21:03   ` Andrii Nakryiko
  0 siblings, 0 replies; 8+ messages in thread
From: Andrii Nakryiko @ 2020-12-18 21:03 UTC (permalink / raw)
  To: Jonathan Lemon
  Cc: Networking, Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
	bpf, Kernel Team

On Fri, Dec 18, 2020 at 12:47 PM Jonathan Lemon
<jonathan.lemon@gmail.com> wrote:
>
> From: Jonathan Lemon <bsd@fb.com>
>
> Only obtain the task reference count at the end of the RCU section
> instead of repeatedly obtaining/releasing it when iterating though
> a thread group.
>
> Jump to the correct branch when it is known that the task is NULL.
>
> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
> ---

Acked-by: Andrii Nakryiko <andrii@kernel.org>

>  kernel/bpf/task_iter.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
> index dc4007f1843b..598a8d7da5bf 100644
> --- a/kernel/bpf/task_iter.c
> +++ b/kernel/bpf/task_iter.c
> @@ -33,7 +33,7 @@ static struct task_struct *task_seq_get_next(struct pid_namespace *ns,
>         pid = find_ge_pid(*tid, ns);
>         if (pid) {
>                 *tid = pid_nr_ns(pid, ns);
> -               task = get_pid_task(pid, PIDTYPE_PID);
> +               task = pid_task(pid, PIDTYPE_PID);
>                 if (!task) {
>                         ++*tid;
>                         goto retry;
> @@ -44,6 +44,7 @@ static struct task_struct *task_seq_get_next(struct pid_namespace *ns,
>                         ++*tid;
>                         goto retry;
>                 }
> +               get_task_struct(task);
>         }
>         rcu_read_unlock();
>
> @@ -148,12 +149,12 @@ task_file_seq_get_next(struct bpf_iter_seq_task_file_info *info)
>          * it held a reference to the task/files_struct/file.
>          * Otherwise, it does not hold any reference.
>          */
> -again:
>         if (info->task) {
>                 curr_task = info->task;
>                 curr_files = info->files;
>                 curr_fd = info->fd;
>         } else {
> +again:
>                 curr_task = task_seq_get_next(ns, &curr_tid, true);
>                 if (!curr_task) {
>                         info->task = NULL;
> --
> 2.24.1
>

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

* Re: [PATCH 1/3 v4 bpf-next] bpf: save correct stopping point in file seq iteration.
  2020-12-18 21:01   ` Andrii Nakryiko
@ 2020-12-24  1:08     ` Daniel Borkmann
  0 siblings, 0 replies; 8+ messages in thread
From: Daniel Borkmann @ 2020-12-24  1:08 UTC (permalink / raw)
  To: Andrii Nakryiko, Jonathan Lemon
  Cc: Networking, Alexei Starovoitov, Yonghong Song, bpf, Kernel Team

On 12/18/20 10:01 PM, Andrii Nakryiko wrote:
> On Fri, Dec 18, 2020 at 12:47 PM Jonathan Lemon
> <jonathan.lemon@gmail.com> wrote:
>>
>> From: Jonathan Lemon <bsd@fb.com>
>>
>> On some systems, some variant of the following splat is
>> repeatedly seen.  The common factor in all traces seems
>> to be the entry point to task_file_seq_next().  With the
>> patch, all warnings go away.
>>
>>      rcu: INFO: rcu_sched self-detected stall on CPU
>>      rcu: \x0926-....: (20992 ticks this GP) idle=d7e/1/0x4000000000000002 softirq=81556231/81556231 fqs=4876
>>      \x09(t=21033 jiffies g=159148529 q=223125)
>>      NMI backtrace for cpu 26
>>      CPU: 26 PID: 2015853 Comm: bpftool Kdump: loaded Not tainted 5.6.13-0_fbk4_3876_gd8d1f9bf80bb #1
>>      Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A12 10/08/2018
>>      Call Trace:
>>       <IRQ>
>>       dump_stack+0x50/0x70
>>       nmi_cpu_backtrace.cold.6+0x13/0x50
>>       ? lapic_can_unplug_cpu.cold.30+0x40/0x40
>>       nmi_trigger_cpumask_backtrace+0xba/0xca
>>       rcu_dump_cpu_stacks+0x99/0xc7
>>       rcu_sched_clock_irq.cold.90+0x1b4/0x3aa
>>       ? tick_sched_do_timer+0x60/0x60
>>       update_process_times+0x24/0x50
>>       tick_sched_timer+0x37/0x70
>>       __hrtimer_run_queues+0xfe/0x270
>>       hrtimer_interrupt+0xf4/0x210
>>       smp_apic_timer_interrupt+0x5e/0x120
>>       apic_timer_interrupt+0xf/0x20
>>       </IRQ>
>>      RIP: 0010:get_pid_task+0x38/0x80
>>      Code: 89 f6 48 8d 44 f7 08 48 8b 00 48 85 c0 74 2b 48 83 c6 55 48 c1 e6 04 48 29 f0 74 19 48 8d 78 20 ba 01 00 00 00 f0 0f c1 50 20 <85> d2 74 27 78 11 83 c2 01 78 0c 48 83 c4 08 c3 31 c0 48 83 c4 08
>>      RSP: 0018:ffffc9000d293dc8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13
>>      RAX: ffff888637c05600 RBX: ffffc9000d293e0c RCX: 0000000000000000
>>      RDX: 0000000000000001 RSI: 0000000000000550 RDI: ffff888637c05620
>>      RBP: ffffffff8284eb80 R08: ffff88831341d300 R09: ffff88822ffd8248
>>      R10: ffff88822ffd82d0 R11: 00000000003a93c0 R12: 0000000000000001
>>      R13: 00000000ffffffff R14: ffff88831341d300 R15: 0000000000000000
>>       ? find_ge_pid+0x1b/0x20
>>       task_seq_get_next+0x52/0xc0
>>       task_file_seq_get_next+0x159/0x220
>>       task_file_seq_next+0x4f/0xa0
>>       bpf_seq_read+0x159/0x390
>>       vfs_read+0x8a/0x140
>>       ksys_read+0x59/0xd0
>>       do_syscall_64+0x42/0x110
>>       entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>      RIP: 0033:0x7f95ae73e76e
>>      Code: Bad RIP value.
>>      RSP: 002b:00007ffc02c1dbf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
>>      RAX: ffffffffffffffda RBX: 000000000170faa0 RCX: 00007f95ae73e76e
>>      RDX: 0000000000001000 RSI: 00007ffc02c1dc30 RDI: 0000000000000007
>>      RBP: 00007ffc02c1ec70 R08: 0000000000000005 R09: 0000000000000006
>>      R10: fffffffffffff20b R11: 0000000000000246 R12: 00000000019112a0
>>      R13: 0000000000000000 R14: 0000000000000007 R15: 00000000004283c0
>>
>> If unable to obtain the file structure for the current task,
>> proceed to the next task number after the one returned from
>> task_seq_get_next(), instead of the next task number from the
>> original iterator.
>>
>> Also, save the stopping task number from task_seq_get_next()
>> on failure in case of restarts.
>>
>> Fixes: a650da2ee52a ("bpf: Add task and task/file iterator targets")

Commit sha is non-existent, I fixed it up. Took first 2 into bpf given first in
particular is a fix. Please submit 3/3 individually once we synced trees back.

>> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
>> ---
> 
> LGTM, thanks!
> 
> Acked-by: Andrii Nakryiko <andrii@kernel.org>

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

end of thread, other threads:[~2020-12-24  1:09 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-18 18:50 [PATCH 0/3 v4 bpf-next] bpf: increment and use correct thread iterator Jonathan Lemon
2020-12-18 18:50 ` [PATCH 1/3 v4 bpf-next] bpf: save correct stopping point in file seq iteration Jonathan Lemon
2020-12-18 21:01   ` Andrii Nakryiko
2020-12-24  1:08     ` Daniel Borkmann
2020-12-18 18:50 ` [PATCH 2/3 v4 bpf-next] bpf: Use thread_group_leader() Jonathan Lemon
2020-12-18 21:02   ` Andrii Nakryiko
2020-12-18 18:50 ` [PATCH 3/3 v4 bpf-next] bpf: optimize task iteration Jonathan Lemon
2020-12-18 21:03   ` Andrii Nakryiko

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.