[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <91ab6f52-c345-540f-703b-844293eda297@iogearbox.net>
Date: Thu, 23 Nov 2023 14:31:30 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Pengcheng Yang <yangpc@...gsu.com>,
'John Fastabend' <john.fastabend@...il.com>,
'Jakub Sitnicki' <jakub@...udflare.com>, 'Eric Dumazet'
<edumazet@...gle.com>, 'Jakub Kicinski' <kuba@...nel.org>,
bpf@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 0/3] skmsg: Add the data length in skmsg to
SIOCINQ ioctl and rx_queue
On 11/23/23 12:20 PM, Pengcheng Yang wrote:
> Daniel Borkmann <daniel@...earbox.net> wrote:
>> On 11/21/23 12:22 PM, Pengcheng Yang wrote:
>>> When using skmsg redirect, the msg is queued in psock->ingress_msg,
>>> and the application calling SIOCINQ ioctl will return a readable
>>> length of 0, and we cannot track the data length of ingress_msg with
>>> the ss tool.
>>>
>>> In this patch set, we added the data length in ingress_msg to the
>>> SIOCINQ ioctl and the rx_queue of tcp_diag.
>>>
>>> v2:
>>> - Add READ_ONCE()/WRITE_ONCE() on accesses to psock->msg_len
>>> - Mask out the increment msg_len where its not needed
>>
>> Please double check BPF CI, this series might be breaking sockmap selftests :
>>
>> https://github.com/kernel-patches/bpf/actions/runs/6922624338/job/18829650043
>
> Is this a misunderstanding?
> The selftests failure above were run on patch set v1 4 days ago, and this patch v2
> is the fix for this case.
Indeed looks like there were two CI emails on v2 as well, one pointing to
failure (which was also linked from patchwork), and one to success, both
pointing to:
https://patchwork.kernel.org/project/netdevbpf/list/?series=802821&state=*
Let me rerun, meanwhile, I placed it back to 'under review'.
Powered by blists - more mailing lists