On Thu, Nov 9, 2017 at 4:43 PM, Alexei Starovoitov <a...@fb.com> wrote:
> On 11/10/17 8:04 AM, Vlad Dumitrescu wrote:
>>
>> From: Vlad Dumitrescu <vla...@google.com>
>>
>> Allows BPF_PROG_TYPE_SOCK_OPS programs to read sk_priority.
>>
>> Signed-off-by: Vlad Dumitrescu <vla...@google.com>
>> ---
>> net/core/filter.c | 16 ++++++++++++++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/core/filter.c b/net/core/filter.c
>> index 1afa17935954..61c791f9f628 100644
>> --- a/net/core/filter.c
>> +++ b/net/core/filter.c
>> @@ -3292,8 +3292,20 @@ BPF_CALL_5(bpf_getsockopt, struct bpf_sock_ops_kern
>> *, bpf_sock,
>> if (!sk_fullsock(sk))
>> goto err_clear;
>>
>> + if (level == SOL_SOCKET) {
>> + if (optlen != sizeof(int))
>> + goto err_clear;
>> +
>> + switch (optname) {
>> + case SO_PRIORITY:
>> + *((int *)optval) = sk->sk_priority;
>
>
> would be cleaner to add sk_priority to 'struct bpf_sock_ops' instead.
> Faster runtime too.
>
I agree it will be faster, and I considered that as well. However, I
was aiming for consistency with the set function, which supports
SO_PRIORITY.
Maybe both (I have no preference)? I'll prepare the patch for
bpf_sock_ops in the meantime.
