Re: [PATCH bpf-next v5 2/5] selftests/bpf: Add tests for open-coded style process file iterator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 10, 2024 at 8:23 AM Juntong Deng <juntong.deng@xxxxxxxxxxx> wrote:
>
> >> +SEC("fentry/" SYS_PREFIX "sys_nanosleep")
> >> +int test_bpf_iter_task_file(void *ctx)
> >> +{
> >> +    struct bpf_iter_task_file task_file_it;
> >> +    struct bpf_iter_task_file_item *item;
> >> +    struct task_struct *task;
> >> +
> >> +    task = bpf_get_current_task_btf();
> >> +    if (task->parent->pid != parent_pid)
> >> +            return 0;
> >> +
> >> +    count++;
> >> +
> >> +    bpf_rcu_read_lock();
> >
> > What does the RCU read lock do here exactly?
> >
>
> Thanks for your reply.
>
> This is used to solve the problem previously discussed in v3 [0].
>
> Task ref may be released during iteration.
>
> [0]:
> https://lore.kernel.org/bpf/CAADnVQ+0LUXxmfm1YgyGDz=cciy3+dGGM-Zysq84fpAdaB74Qw@xxxxxxxxxxxxxx/

I think you misunderstood my comment.

"If this object _was_ RCU protected ..."

Adding rcu_read_lock doesn't make 'task' pointer RCU protected.
That's not how RCU works.

So patch 1 doing:

item->task = task;

is not correct.

See bpf_iter_task_vma_new(). It's doing:
kit->data->task = get_task_struct(task);
to make sure task stays valid while iterating.

pw-bot: cr





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux