From: Jason Xing
The output goes like this if I make samples/bpf:
...warning: no previous prototype for ‘get_cgroup_id_from_path’...
Make this function static could solve the warning problem since
no one outside of the file calls it.
Signed-off-by: Jason Xing
---
tools/testing/selftests/bpf
Hello Jon,
On Sat, Aug 24, 2024 at 5:19 AM wrote:
>
> From: Jon Maloy
>
> We add a selftest to check that the new feature added in
> commit 05ea491641d3 ("tcp: add support for SO_PEEK_OFF socket option")
> works correctly.
>
> Reviewed-by: Stefano Brivio
> Tested-by: Stefano Brivio
> Signed-of
>
> We do that here.
>
> Fixes: 05ea491641d3 ("tcp: add support for SO_PEEK_OFF socket option")
> Reviewed-by: David Gibson
> Reviewed-by: Stefano Brivio
> Tested-by: Stefano Brivio
> Signed-off-by: Jon Maloy
Reviewed-by: Jason Xing
You seem to forg
K_OFF socket option")
> Reviewed-by: Eric Dumazet
> Reviewed-by: David Gibson
> Reviewed-by: Stefano Brivio
> Tested-by: Stefano Brivio
> Signed-off-by: Jon Maloy
Reviewed-by: Jason Xing
From: Jason Xing
Add the SO_PEEK_OFF selftest for UDP. In this patch, I mainly do
three things:
1. rename tcp_so_peek_off.c
2. adjust for UDP protocol
3. add selftests into it
Suggested-by: Jon Maloy
Signed-off-by: Jason Xing
---
Link:
https://lore.kernel.org/all/9f4dd14d-fbe3-4c61-b04c
Hello Jon,
On Tue, Aug 27, 2024 at 3:58 AM Jon Maloy wrote:
>
>
>
> On 2024-08-23 19:44, Jason Xing wrote:
> > Hello Jon,
> >
> > On Sat, Aug 24, 2024 at 5:19 AM wrote:
> >> From: Jon Maloy
> >>
> >> We add a selftest to check that the
On Mon, Sep 2, 2024 at 9:07 AM Stanislav Fomichev wrote:
>
> On 09/01, Jason Xing wrote:
> > From: Jason Xing
> >
> > Add the SO_PEEK_OFF selftest for UDP. In this patch, I mainly do
> > three things:
> > 1. rename tcp_so_peek_off.c
> > 2. adjust for
On Mon, Sep 2, 2024 at 11:02 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > Add the SO_PEEK_OFF selftest for UDP. In this patch, I mainly do
> > three things:
> > 1. rename tcp_so_peek_off.c
> > 2. adjust for
From: Jason Xing
Add the SO_PEEK_OFF selftest for UDP. In this patch, I mainly do
three things:
1. rename tcp_so_peek_off.c
2. adjust for UDP protocol
3. add selftests into it
Suggested-by: Jon Maloy
Reviewed-by: Willem de Bruijn
Signed-off-by: Jason Xing
---
v2
Link:
https
From: Jason Xing
When I was trying to modify the tx timestamping feature, I found that
running "./txtimestamp -4 -C -L 127.0.0.1" didn't reflect the fact
properly.
In this selftest file, we respectively test three tx generation flags.
With the generation and report flag enabled,
On Thu, Sep 5, 2024 at 5:16 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > When I was trying to modify the tx timestamping feature, I found that
> > running "./txtimestamp -4 -C -L 127.0.0.1" didn't reflect the fac
From: Jason Xing
When one socket is set SOF_TIMESTAMPING_RX_SOFTWARE which means the
whole system turns on the netstamp_needed_key button, other sockets
that only have SOF_TIMESTAMPING_SOFTWARE will be affected and then
print the rx timestamp information even without setting
From: Jason Xing
introduce a new flag SOF_TIMESTAMPING_OPT_RX_FILTER in the receive
path. User can set it with SOF_TIMESTAMPING_SOFTWARE to filter
out rx software timestamp report, especially after a process turns on
netstamp_needed_key which can time stamp every incoming skb.
Previously, we
From: Jason Xing
SOF_TIMESTAMPING_RAW_HARDWARE is a report flag which passes the
timestamps generated by either SOF_TIMESTAMPING_TX_HARDWARE or
SOF_TIMESTAMPING_RX_HARDWARE to the userspace all the time.
So let us revise the doc here.
Suggested-by: Willem de Bruijn
Signed-off-by: Jason Xing
From: Jason Xing
In the previous patch, we found things could happen in the rx software
timestamp. Here, we also noticed that, for rx hardware timestamp case,
it could happen when one process enables the rx hardware timestamp
generating flag first, then another process only setting
From: Jason Xing
Test when we use SOF_TIMESTAMPING_OPT_RX_FILTER with software
or hardware report flag. The expected result is no rx timestamp
report.
Reviewed-by: Willem de Bruijn
Signed-off-by: Jason Xing
---
tools/testing/selftests/net/rxtimestamp.c | 11 +++
1 file changed, 11
On Thu, Sep 5, 2024 at 3:18 PM Jason Xing wrote:
>
> From: Jason Xing
>
> Test when we use SOF_TIMESTAMPING_OPT_RX_FILTER with software
> or hardware report flag. The expected result is no rx timestamp
> report.
>
> Reviewed-by: Willem de Bruijn
> Signed-off-by:
On Thu, Sep 5, 2024 at 5:16 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > When I was trying to modify the tx timestamping feature, I found that
> > running "./txtimestamp -4 -C -L 127.0.0.1" didn't reflect the fac
On Thu, Sep 5, 2024 at 7:04 PM Jason Xing wrote:
>
> On Thu, Sep 5, 2024 at 5:16 AM Willem de Bruijn
> wrote:
> >
> > Jason Xing wrote:
> > > From: Jason Xing
> > >
> > > When I was trying to modify the tx timestamping feature, I found that
On Thu, Sep 5, 2024 at 9:37 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > introduce a new flag SOF_TIMESTAMPING_OPT_RX_FILTER in the receive
> > path. User can set it with SOF_TIMESTAMPING_SOFTWARE to filter
> > out rx software
On Thu, Sep 5, 2024 at 9:45 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > In the previous patch, we found things could happen in the rx software
> > timestamp. Here, we also noticed that, for rx hardware timestamp case,
> > it c
On Thu, Sep 5, 2024 at 9:38 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > SOF_TIMESTAMPING_RAW_HARDWARE is a report flag which passes the
> > timestamps generated by either SOF_TIMESTAMPING_TX_HARDWARE or
> > SOF_TIMESTAMPING_
On Thu, Sep 5, 2024 at 10:45 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Thu, Sep 5, 2024 at 9:38 PM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > From: Jason Xing
> > > >
> > > > SOF_TIMEST
On Thu, Sep 5, 2024 at 10:46 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Thu, Sep 5, 2024 at 9:45 PM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > From: Jason Xing
> > > >
> > > >
From: Jason Xing
When I was trying to modify the tx timestamping feature, I found that
running "./txtimestamp -4 -C -L 127.0.0.1" didn't reflect the error:
I succeeded to generate timestamp stored in the skb but later failed
to report it to the userspace (which means failed to pu
On Fri, Sep 6, 2024 at 12:41 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Thu, Sep 5, 2024 at 10:46 PM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > On Thu, Sep 5, 2024 at 9:45 PM Willem de Bruijn
>
From: Jason Xing
When one socket is set SOF_TIMESTAMPING_RX_SOFTWARE which means the
whole system turns on the netstamp_needed_key button, other sockets
that only have SOF_TIMESTAMPING_SOFTWARE will be affected and then
print the rx timestamp information even without setting
From: Jason Xing
introduce a new flag SOF_TIMESTAMPING_OPT_RX_FILTER in the receive
path. User can set it with SOF_TIMESTAMPING_SOFTWARE to filter
out rx software timestamp report, especially after a process turns on
netstamp_needed_key which can time stamp every incoming skb.
Previously, we
From: Jason Xing
Test a few possible cases where we use SOF_TIMESTAMPING_OPT_RX_FILTER
with software or hardware report/generation flag.
Signed-off-by: Jason Xing
---
1. add a new combination test when both flags are set at once
---
tools/testing/selftests/net/rxtimestamp.c | 18
From: Jason Xing
SOF_TIMESTAMPING_RAW_HARDWARE is a report flag which passes the
timestamps generated by either SOF_TIMESTAMPING_TX_HARDWARE or
SOF_TIMESTAMPING_RX_HARDWARE to the userspace all the time.
So let us revise the doc here.
Link: Link:
https://lore.kernel.org/all
On Fri, Sep 6, 2024 at 11:26 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > SOF_TIMESTAMPING_RAW_HARDWARE is a report flag which passes the
> > timestamps generated by either SOF_TIMESTAMPING_TX_HARDWARE or
> > SOF_TIMESTAMPING_
On Sat, Sep 7, 2024 at 7:24 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > introduce a new flag SOF_TIMESTAMPING_OPT_RX_FILTER in the receive
> > path. User can set it with SOF_TIMESTAMPING_SOFTWARE to filter
> > out rx software
On Sat, Sep 7, 2024 at 9:23 AM Jason Xing wrote:
>
> On Sat, Sep 7, 2024 at 7:24 AM Willem de Bruijn
> wrote:
> >
> > Jason Xing wrote:
> > > From: Jason Xing
> > >
> > > introduce a new flag SOF_TIMESTAMPING_OPT_RX_FILTER
On Sat, Sep 7, 2024 at 10:34 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Sat, Sep 7, 2024 at 7:24 AM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > From: Jason Xing
> > > >
> > > > introdu
Hello Willem,
On Mon, Sep 9, 2024 at 3:41 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Sat, Sep 7, 2024 at 10:34 AM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > On Sat, Sep 7, 2024 at 7:24 AM Willem de Bruijn
>
From: Jason Xing
Even though this case is unlikely to happen, we have to avoid such
a case occurring at an earlier point: the sk_rmem_alloc could get
increased because of inserting more and more skbs into the errqueue
when calling __skb_complete_tx_timestamp(). This bad case would stop
the
From: Jason Xing
Let it be tuned in per netns by admins.
Signed-off-by: Jason Xing
---
include/net/netns/core.h | 1 +
include/net/sock.h | 2 --
net/core/net_namespace.c | 1 +
net/core/skbuff.c | 2 +-
net/core/sysctl_net_core.c | 18 +-
5 files
From: Jason Xing
Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so
that we can get aware of whether using write_seq as an initial key
value works as expected.
Signed-off-by: Jason Xing
---
tools/testing/selftests/net/txtimestamp.c | 6 ++
1 file changed, 6 insertions
From: Jason Xing
When reading through the whole feature, I feel we can do these things to
make it more robust. They are trivial changes, not big ones.
Jason Xing (3):
net-timestamp: add strict check when setting tx flags
net-timestamp: add OPT_ID_TCP test in selftests
net-timestamp
From: Jason Xing
When I compiled the tools/testing/selftests/bpf, the following error
pops out:
uprobe_multi.c: In function ‘trigger_uprobe’:
uprobe_multi.c:109:26: error: ‘MADV_PAGEOUT’ undeclared (first use in this
function); did you mean ‘MADV_RANDOM’?
madvise(addr, page_sz, MADV_PAGEOUT
On Sun, Oct 20, 2024 at 12:10 PM Jason Xing wrote:
>
> On Sun, Oct 20, 2024 at 11:14 AM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > When I compiled the tools/testing/selftests/bpf, the following error
> > pops out:
> > uprobe_multi.c: In functio
On Sun, Oct 20, 2024 at 11:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> When I compiled the tools/testing/selftests/bpf, the following error
> pops out:
> uprobe_multi.c: In function ‘trigger_uprobe’:
> uprobe_multi.c:109:26: error: ‘MADV_PAGEOUT’ undeclared (first us
From: Jason Xing
When I compiled the tools/testing/selftests/bpf, the following error
pops out:
uprobe_multi.c: In function ‘trigger_uprobe’:
uprobe_multi.c:109:26: error: ‘MADV_PAGEOUT’ undeclared (first use in this
function); did you mean ‘MADV_RANDOM’?
madvise(addr, page_sz, MADV_PAGEOUT
On Mon, Oct 21, 2024 at 3:41 PM Jiri Olsa wrote:
>
> On Mon, Oct 21, 2024 at 01:07:06PM +0800, Jason Xing wrote:
> > From: Jason Xing
> >
> > When I compiled the tools/testing/selftests/bpf, the following error
> > pops out:
> > uprobe_multi.c: In function
On Mon, Oct 21, 2024 at 3:51 PM Jason Xing wrote:
>
> On Mon, Oct 21, 2024 at 3:41 PM Jiri Olsa wrote:
> >
> > On Mon, Oct 21, 2024 at 01:07:06PM +0800, Jason Xing wrote:
> > > From: Jason Xing
> > >
> > > When I compiled the tools/testing/self
On Mon, Oct 21, 2024 at 5:34 PM Jiri Olsa wrote:
>
> On Mon, Oct 21, 2024 at 04:07:15PM +0800, Jason Xing wrote:
> > On Mon, Oct 21, 2024 at 3:51 PM Jason Xing
> > wrote:
> > >
> > > On Mon, Oct 21, 2024 at 3:41 PM Jiri Olsa wrote:
> > > >
On Tue, Oct 29, 2024 at 12:20 AM Andrii Nakryiko
wrote:
>
> On Sun, Oct 27, 2024 at 8:41 PM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > As we can see from the title, when I compiled the selftests/bpf, I
> > saw the error:
> > implicit decla
From: Jason Xing
As we can see from the title, when I compiled the selftests/bpf, I
saw the error:
implicit declaration of function ‘gettid’ ; did you mean ‘getgid’?
[-Werror=implicit-function-declaration]
skel->bss->tid = gettid();
^~
From: Jason Xing
As we can see from the title, when I compiled the selftests/bpf, I
saw the error:
implicit declaration of function ‘gettid’ ; did you mean ‘getgid’?
[-Werror=implicit-function-declaration]
skel->bss->tid = gettid();
^~
getgid
On Mon, Sep 30, 2024 at 7:49 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Mon, Sep 30, 2024 at 6:39 PM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > From: Jason Xing
> > > >
> > > > Even thou
On Tue, Oct 1, 2024 at 2:15 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Tue, Oct 1, 2024 at 1:14 AM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > On Mon, Sep 30, 2024 at 7:49 PM Willem de Bruijn
> > > >
On Mon, Sep 30, 2024 at 6:39 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > Even though this case is unlikely to happen, we have to avoid such
> > a case occurring at an earlier point: the sk_rmem_alloc could get
> > increase
On Mon, Sep 30, 2024 at 6:47 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > Let it be tuned in per netns by admins.
> >
> > Signed-off-by: Jason Xing
>
> +1 on the idea
>
> > ---
> > include/net/n
On Mon, Sep 30, 2024 at 6:48 PM Vadim Fedorenko
wrote:
>
> On 30/09/2024 10:24, Jason Xing wrote:
> > From: Jason Xing
> >
> > Even though this case is unlikely to happen, we have to avoid such
> > a case occurring at an earlier point: the sk_rmem_alloc coul
On Mon, Sep 30, 2024 at 6:42 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so
> > that we can get aware of whether using write_seq as an initial key
> > value
On Mon, Sep 30, 2024 at 7:54 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Mon, Sep 30, 2024 at 6:42 PM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > From: Jason Xing
> > > >
> > > > Introduce
On Tue, Oct 1, 2024 at 1:14 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Mon, Sep 30, 2024 at 7:49 PM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > On Mon, Sep 30, 2024 at 6:39 PM Willem de Bruijn
>
-by: Jason Xing
---
tools/testing/selftests/bpf/prog_tests/setget_sockopt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/setget_sockopt.c
b/tools/testing/selftests/bpf/prog_tests/setget_sockopt.c
index e12255121c15..e4dac529d424 100644
--
;
^~~~
Fix it by replacing with 'main_data'.
Signed-off-by: Jason Xing
---
.../selftests/bpf/prog_tests/changes_pkt_data.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/changes_pkt_data.c
b/too
: ‘TCP_ZEROCOPY_RECEIVE’
undeclared (first use in this function)
err = getsockopt(fd, SOL_TCP, TCP_ZEROCOPY_RECEIVE, &buf, &optlen);
^~~~
Fix it by introducing the right header.
Signed-off-by: Jason Xing
---
tools/testing/selftests/bpf/pr
Fix them separately in each patch.
Jason Xing (2):
bpf: changes_pkt_data: correct the 'main' error
bpf: sockopt_sk: fix 'undeclared' definition error
.../selftests/bpf/prog_tests/changes_pkt_data.c | 12 ++--
tools/testing/selftests/bpf/prog_tests/sockopt_sk
On Wed, Feb 5, 2025 at 10:57 AM Hou Tao wrote:
>
> Hi,
>
> On 2/4/2025 10:39 AM, Jason Xing wrote:
> > Error messages:
> > selftests/bpf/prog_tests/sockopt_sk.c: In function ‘getsetsockopt’:
> > selftests/bpf/prog_tests/sockopt_sk.c:22:31: error: field ‘zc’ has
>
On Wed, Feb 5, 2025 at 5:30 PM Hou Tao wrote:
>
> Hi,
>
> On 2/5/2025 11:27 AM, Jason Xing wrote:
> > On Wed, Feb 5, 2025 at 10:57 AM Hou Tao wrote:
> >> Hi,
> >>
> >> On 2/4/2025 10:39 AM, Jason Xing wrote:
> >>> Error messages:
On Fri, Feb 7, 2025 at 2:04 PM Martin KaFai Lau wrote:
>
> On 2/3/25 6:39 PM, Jason Xing wrote:
> > When compiling the selftests, the following error is printed out:
> > selftests/bpf/prog_tests/changes_pkt_data.c: In function ‘test_aux’:
> > selftests/bpf/prog_tests/
Hi Maintainers from bpf,
On Tue, Feb 4, 2025 at 10:39 AM Jason Xing wrote:
>
> Fix them separately in each patch.
I'd like to know if it's possible to merge the series because it does
harm to some old distro with only updating the kernel?
Thanks,
Jason
>
> J
65 matches
Mail list logo
