Re: [PATCH bpf-next v4 3/7] bpf: support epoll from bpf struct_ops links.

Kui-Feng Lee
2024-05-23T18:24:59Z

On 5/23/24 10:23, Martin KaFai Lau wrote:
> On 5/21/24 3:51 PM, Kui-Feng Lee wrote:
>> +static __poll_t bpf_link_poll(struct file *file, struct
>> poll_table_struct *pts)
>> +{
>> +    struct bpf_link *link = file->private_data;
>> +
>> +    if (link->ops->poll)
>> +        return link->ops->poll(file, pts);
>> +
>> +    return 0;
>
> The current bpf_link_fops.poll is NULL before this patch. From vfs_poll,
> it seems to be DEFAULT_POLLMASK for this case. Please double check.

Yes, it returns DEFAULT_POLLMASK if file->f_op->epoll is NULL. But,
before this patch, link can not be added to an epoll. See the
explanation below.

>
>> +}
>> +
>>   static const struct file_operations bpf_link_fops = {
>>   #ifdef CONFIG_PROC_FS
>>       .show_fdinfo    = bpf_link_show_fdinfo,
>> @@ -3157,6 +3167,7 @@ static const struct file_operations
>> bpf_link_fops = {
>>       .release    = bpf_link_release,
>>       .read        = bpf_dummy_read,
>>       .write        = bpf_dummy_write,
>> +    .poll        = bpf_link_poll,
>
> Same here. What does the epoll_ctl(EPOLL_CTL_ADD) currently expect for
> link (e.g. cgroup) that does not support poll?
>

epoll_ctl() always returns -EPERM for files not supporting poll.
Should I add another instance of struct file_operations to keep the
consistency for other types of links?

>>   };
>