-by: Jason Xing <kerneljasonx...@gmail.com>
---
fs/ecryptfs/crypto.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index e5e29f8..895140f 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/cr
Could anyone take a look at this patch which fixes the xattr-read
issue? Thanks anyway.
Jason
On Thu, Jun 22, 2017 at 3:21 PM, Jason Xing <kerneljasonx...@gmail.com> wrote:
> When doing ecryptfs_read_and_validate_xattr_region(), eCryptfs
> reads only 16 bytes from xattr reg
Could anyone take a look at this patch which fixes the xattr-read
issue? Thanks anyway.
Jason
On Thu, Jun 22, 2017 at 3:21 PM, Jason Xing wrote:
> When doing ecryptfs_read_and_validate_xattr_region(), eCryptfs
> reads only 16 bytes from xattr region. However, the lower filesystem
>
Hi everyone,
Could anyone take a look at this issue? I believe it is of high-importance.
Though Eric gave the proper patch a few months ago, the stable branch
still hasn't applied or merged this fix. It seems this patch was
forgotten :(
Thanks,
Jason
On Thu, Jun 4, 2020 at 9:47 PM Jason Xing
because the
scheduling side sees group->poll_kworker under RCU protection and then
schedules it, but here we cancel the work and destroy the worker. The
cancel needs to pair with resetting the poll_scheduled flag."
Signed-off-by: Jason Xing
Reviewed-by: Caspar Zhang
Reviewed-by: Joseph Qi
Re
is destroyed.
Signed-off-by: Jason Xing
---
kernel/sched/psi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7acc632..66f4385 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -1133,6 +1133,12 @@ static void psi_trigger_destroy(struct
Hi all,
According to the reviews from Johoannes, I've changed the old patch and
then submitted the version 2 patch a few days ago.
Please let me know if all this sounds good, or if there are any issues.
Thanks,
Jason
On 2019/7/30 下午1:16, Jason Xing wrote:
Only when calling the poll syscall
Hello,
It's been delayed for no reason a couple of days. Any comments and
suggestions on this patch V2 would be appreciated.
Thanks,
Jason
On 2019/7/30 下午1:16, Jason Xing wrote:
Only when calling the poll syscall the first time can user
receive POLLPRI correctly. After that, user always
Hello,
Could someone take a quick look at this patch? It's not complicated at
all, just one line added into PSI which can make the poll() run in the
right way.
Thanks,
Jason
On 2019/7/23 下午2:45, Jason Xing wrote:
Only when calling the poll syscall the first time can user
receive POLLPRI
.
Thanks,
Jason
On Tue, Jun 2, 2020 at 9:05 PM Eric Dumazet wrote:
>
> On Tue, Jun 2, 2020 at 1:05 AM wrote:
> >
> > From: Jason Xing
> >
> > TCP socks cannot be released because of the sock_hold() increasing the
> > sk_refcnt in the manner of tcp_internal_paci
the fix to the correct tree soon :)
Thanks again,
Jason
On Wed, Jun 3, 2020 at 10:29 AM Eric Dumazet wrote:
>
> On Tue, Jun 2, 2020 at 6:53 PM Jason Xing wrote:
> >
> > Hi Eric,
> >
> > I'm sorry that I didn't write enough clearly. We're running the
> > pristine 4
Thanks for reminding me.
I will test the cases through using sch_fq.
Jason
On Wed, Jun 3, 2020 at 10:44 AM Eric Dumazet wrote:
>
> On Tue, Jun 2, 2020 at 7:42 PM Jason Xing wrote:
> >
> > I agree with you. The upstream has already dropped and optimized this
> > part (
'. Meanwhile,
should we introduce the tcp_wstamp_ns socket field as commit
(864e5c090749) does?
Thanks,
Jason
On Wed, Jun 3, 2020 at 10:44 AM Eric Dumazet wrote:
>
> On Tue, Jun 2, 2020 at 7:42 PM Jason Xing wrote:
> >
> > I agree with you. The upstream has already dro
On Wed, Jun 3, 2020 at 1:44 PM Eric Dumazet wrote:
>
> On Tue, Jun 2, 2020 at 10:05 PM Jason Xing wrote:
> >
> > Hi Eric,
> >
> > I'm still trying to understand what you're saying before. Would this
> > be better as following:
> > 1) discard the tcp
On Wed, Jun 3, 2020 at 8:02 PM Neal Cardwell wrote:
>
> On Wed, Jun 3, 2020 at 1:44 AM Eric Dumazet wrote:
> >
> > On Tue, Jun 2, 2020 at 10:05 PM Jason Xing
> > wrote:
> > >
> > > Hi Eric,
> > >
> > > I'm still trying to unde
On Wed, Jun 3, 2020 at 10:08 PM Neal Cardwell wrote:
>
> On Wed, Jun 3, 2020 at 9:55 AM Eric Dumazet wrote:
> >
> > On Wed, Jun 3, 2020 at 5:02 AM Neal Cardwell wrote:
> > >
> > > On Wed, Jun 3, 2020 at 1:44 AM Eric Dumazet wrote:
> > > >
&g
On Thu, Jun 4, 2020 at 9:10 PM Eric Dumazet wrote:
>
> On Thu, Jun 4, 2020 at 2:01 AM wrote:
> >
> > From: Jason Xing
> >
> > When using BBR mode, too many tcp socks cannot be released because of
> > duplicate use of the sock_hold() in the manner of tcp_in
-by: Jason Xing
---
fs/ecryptfs/crypto.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index e5e29f8..895140f 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1389,19 +1389,36 @@ int
On Thu, Apr 15, 2021 at 10:08 AM Jesse Brandeburg
wrote:
>
> Jason Xing wrote:
>
> > On Wed, Apr 14, 2021 at 12:27 AM Jesse Brandeburg
> > wrote:
> > >
> > > kerneljasonx...@gmail.com wrote:
> > >
> > > > From: Jason Xing
> > &g
On Wed, Apr 14, 2021 at 12:27 AM Jesse Brandeburg
wrote:
>
> kerneljasonx...@gmail.com wrote:
>
> > From: Jason Xing
>
> Hi Jason,
>
> Sorry, I missed this on the first time: Added intel-wired-lan,
> please include on any future submissions for Intel drivers.
>
On Wed, Apr 14, 2021 at 12:27 AM Jesse Brandeburg
wrote:
>
> kerneljasonx...@gmail.com wrote:
>
> > From: Jason Xing
>
> Hi Jason,
>
> Sorry, I missed this on the first time: Added intel-wired-lan,
> please include on any future submissions for Intel drivers.
>
On Tue, Apr 13, 2021 at 5:52 AM Jesse Brandeburg
wrote:
>
> kerneljasonx...@gmail.com wrote:
>
> > From: Jason Xing
> >
> > Re: [PATCH] i40e: fix the panic when running bpf in xdpdrv mode
>
> Please use netdev style subject lines when patching net kerne
[...]
> >I think my understanding based on what Eric depicted differs from you:
> >we're supposed to filter out those many invalid cases and only trace
> >the valid action of sending a icmp, so where to add a new tracepoint
> >is important instead of adding more checks in the tracepoint itself.
>
Hi Antoine,
On Wed, Apr 10, 2024 at 8:14 PM Antoine Tenart wrote:
>
> Quoting Jason Xing (2024-04-09 12:09:30)
> > void(*send_reset)(const struct sock *sk,
> > - struct sk_buff *skb);
> > +
On Wed, Apr 10, 2024 at 9:21 PM Antoine Tenart wrote:
>
> Quoting Jason Xing (2024-04-10 14:54:51)
> > Hi Antoine,
> >
> > On Wed, Apr 10, 2024 at 8:14 PM Antoine Tenart wrote:
> > >
> > > Quoting Jason Xing (2024-04-09 12:09:30)
> > > >
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
net/ipv4
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we don't need to implement those duplicated reset reasons.
This patch replaces all the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/ipv4/tcp_ipv4.c | 8
net/ipv6/tcp_ipv6.c | 8
From: Jason Xing
It relys on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/subflow.c | 22 +-
1 file changed, 17 insertions
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
From: Jason Xing
Since we have mapped every mptcp reset reason definition
in enum sk_rst_reason, introducing a new helper can cover
some missing places where we have already set the
subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
Hello Eric,
On Wed, Apr 17, 2024 at 5:02 PM Eric Dumazet wrote:
>
> On Wed, Apr 17, 2024 at 10:51 AM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > Add a new standalone file for the easy future extension to support
> > both active reset and passive r
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
net/ipv4
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we don't need to implement those duplicated reset reasons.
This patch replaces all the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/ipv4/tcp_ipv4.c | 8
net/ipv6/tcp_ipv6.c | 8
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
From: Jason Xing
It relys on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/subflow.c | 22 +-
1 file changed, 17 insertions
From: Jason Xing
Since we have mapped every mptcp reset reason definition
in enum sk_rst_reason, introducing a new helper can cover
some missing places where we have already set the
subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
Hello Steven,
On Sat, Apr 20, 2024 at 10:36 AM Steven Rostedt wrote:
>
> On Fri, 19 Apr 2024 16:00:20 +0800
> Jason Xing wrote:
>
> > If other experts see this thread, please help me. I would appreciate
> > it. I have strong interests and feel strong responsibility to
On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
>
> On Thu, 18 Apr 2024 11:30:02 +0800 Jason Xing wrote:
> > I'm not sure why the patch series has been changed to 'Changes
> > Requested', until now I don't think I need to change something.
> >
> > Should
On Fri, Apr 19, 2024 at 2:51 AM Eric Dumazet wrote:
>
> On Thu, Apr 18, 2024 at 6:24 PM Jason Xing wrote:
> >
> > On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
> > >
> > > On Thu, 18 Apr 2024 11:30:02 +0800 Jason Xing wrote:
> > > > I'
On Fri, Apr 19, 2024 at 6:29 AM Jason Xing wrote:
>
> On Fri, Apr 19, 2024 at 2:51 AM Eric Dumazet wrote:
> >
> > On Thu, Apr 18, 2024 at 6:24 PM Jason Xing
> > wrote:
> > >
> > > On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
> > >
> When I said "If you feel the need to put them in a special group, this
> is fine by me.",
> this was really about partitioning the existing enum into groups, if
> you prefer having a group of 'RES reasons'
Are you suggesting copying what we need from enum skb_drop_reason{} to
enum
On Fri, Apr 19, 2024 at 4:00 PM Jason Xing wrote:
>
> On Fri, Apr 19, 2024 at 3:44 PM Eric Dumazet wrote:
> >
> > On Fri, Apr 19, 2024 at 9:29 AM Jason Xing
> > wrote:
> > >
> > > On Fri, Apr 19, 2024 at 3:02 PM Eric Dumazet wrote:
> > > &
On Fri, Apr 19, 2024 at 3:44 PM Eric Dumazet wrote:
>
> On Fri, Apr 19, 2024 at 9:29 AM Jason Xing wrote:
> >
> > On Fri, Apr 19, 2024 at 3:02 PM Eric Dumazet wrote:
> > >
> > > On Fri, Apr 19, 2024 at 4:31 AM Jason Xing
> > > wrote:
> > >
On Fri, Apr 19, 2024 at 7:26 AM Jason Xing wrote:
>
> > When I said "If you feel the need to put them in a special group, this
> > is fine by me.",
> > this was really about partitioning the existing enum into groups, if
> > you prefer having a group of
Hello Matthieu,
On Mon, Apr 22, 2024 at 4:47 PM Matthieu Baerts wrote:
>
> Hi Jason,
>
> On 22/04/2024 05:01, Jason Xing wrote:
> > From: Jason Xing
> >
> > Add a new standalone file for the easy future extension to support
> > both active reset and passive r
On Tue, Apr 23, 2024 at 10:14 AM Jason Xing wrote:
>
> Hi Simon,
>
> On Tue, Apr 23, 2024 at 2:28 AM Simon Horman wrote:
> >
> > On Mon, Apr 22, 2024 at 11:01:03AM +0800, Jason Xing wrote:
> >
> > ...
> >
> > > diff --git
Hi Simon,
On Tue, Apr 23, 2024 at 2:28 AM Simon Horman wrote:
>
> On Mon, Apr 22, 2024 at 11:01:03AM +0800, Jason Xing wrote:
>
> ...
>
> > diff --git a/include/net/rstreason.h b/include/net/rstreason.h
>
> ...
>
> > +/**
> > + * There are three parts
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset
From: Jason Xing
It relys on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/protocol.h | 28
net/mptcp/subflow.c
From: Jason Xing
Since we have mapped every mptcp reset reason definition in enum
sk_rst_reason, introducing a new helper can cover some missing places
where we have already set the subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
net/ipv4
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we can finally display the corresponding item in enum sk_reset_reason
instead of reinventing new reset reasons. This patch replaces all
the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
include
On Thu, Apr 11, 2024 at 10:34 AM Peilin He wrote:
>
> >[...]
> >> >I think my understanding based on what Eric depicted differs from you:
> >> >we're supposed to filter out those many invalid cases and only trace
> >> >the valid action of sending a icmp, so where to add a new tracepoint
> >> >is
On Thu, Apr 11, 2024 at 12:57 PM Peilin He wrote:
>
> >> >[...]
> >> >> >I think my understanding based on what Eric depicted differs from you:
> >> >> >we're supposed to filter out those many invalid cases and only trace
> >> >> >the valid action of sending a icmp, so where to add a new
From: Jason Xing
It relies on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
Reviewed-by: Matthieu Baerts (NGI0)
---
net/mptcp/protocol.h | 27
From: Jason Xing
Since we have mapped every mptcp reset reason definition in enum
sk_rst_reason, introducing a new helper can cover some missing places
where we have already set the subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
Acked-by: Matthieu Baerts (NGI0)
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
Acked-by: Matthieu Baerts (NGI0)
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we can finally display the corresponding item in enum sk_reset_reason
instead of reinventing new reset reasons. This patch replaces all
the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
include
On Fri, Apr 19, 2024 at 3:02 PM Eric Dumazet wrote:
>
> On Fri, Apr 19, 2024 at 4:31 AM Jason Xing wrote:
> >
> > On Fri, Apr 19, 2024 at 7:26 AM Jason Xing
> > wrote:
> > >
> > > > When I said "If you feel the need to put t
On Wed, Apr 17, 2024 at 4:51 PM Jason Xing wrote:
>
> From: Jason Xing
>
> In production, there are so many cases about why the RST skb is sent but
> we don't have a very convenient/fast method to detect the exact underlying
> reasons.
>
> RST is implemented in two k
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
net/ipv4
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we can finally display the corresponding item in enum sk_reset_reason
instead of reinventing new reset reasons. This patch replaces all
the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/ipv4
From: Jason Xing
It relys on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/subflow.c | 22 +-
1 file changed, 17 insertions
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
From: Jason Xing
Since we have mapped every mptcp reset reason definition in enum
sk_rst_reason, introducing a new helper can cover some missing places
where we have already set the subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1
On Tue, Apr 23, 2024 at 7:57 PM Simon Horman wrote:
>
> On Tue, Apr 23, 2024 at 10:17:31AM +0800, Jason Xing wrote:
> > On Tue, Apr 23, 2024 at 10:14 AM Jason Xing
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > On Tue, Apr 23, 2024 at 2:28
Hello Matthieu,
On Tue, Apr 23, 2024 at 6:02 PM Matthieu Baerts wrote:
>
> Hi Jason,
>
> On 23/04/2024 09:21, Jason Xing wrote:
> > From: Jason Xing
> >
> > It relys on what reset options in the skb are as rfc8684 says. Reusing
>
> (if you have something els
From: Jason Xing
Using the macro for other tracepoints use to be more concise.
No functional change.
Jason Xing (3):
trace: move to TP_STORE_ADDRS related macro to net_probe_common.h
trace: use TP_STORE_ADDRS() macro in inet_sk_error_report()
trace: use TP_STORE_ADDRS() macro
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/s
From: Jason Xing
Put the macro into another standalone file for better extension.
Some tracepoints can use this common part in the future.
Signed-off-by: Jason Xing
---
include/trace/events/net_probe_common.h | 29 +
include/trace/events/tcp.h | 29
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/s
From: Jason Xing
Introducing entry_saddr and entry_daddr parameters in this macro
for later use can help us record the reverse 4-turple by analyzing
the 4-turple of the incoming skb when receiving.
Signed-off-by: Jason Xing
---
include/trace/events/tcp.h | 21 +++--
1 file
From: Jason Xing
Prior to this patch, what we can see by enabling trace_tcp_send is
only happening under two circumstances:
1) active rst mode
2) non-active rst mode and based on the full socket
That means the inconsistency occurs if we use tcpdump and trace
simultaneously to see how rst
From: Jason Xing
Before this, we miss some cases where the TCP layer could send rst but
we cannot trace it. So I decided to complete it :)
Jason Xing (2):
trace: adjust TP_STORE_ADDR_PORTS_SKB() parameters
trace: tcp: fully support trace_tcp_send_reset
include/trace/events/tcp.h | 60
On Mon, Mar 11, 2024 at 11:23 AM Ratheesh Kannoth wrote:
>
> On 2024-03-11 at 08:11:03, Jason Xing (kerneljasonx...@gmail.com) wrote:
> > From: Jason Xing
> >
> > Introducing entry_saddr and entry_daddr parameters in this macro
> > for later use can help
On Mon, Mar 11, 2024 at 11:27 AM Ratheesh Kannoth wrote:
>
> On 2024-03-11 at 08:11:04, Jason Xing (kerneljasonx...@gmail.com) wrote:
> > From: Jason Xing
> >
> > Prior to this patch, what we can see by enabling trace_tcp_send is
> > only happening under two circums
On Thu, Mar 21, 2024 at 11:09 AM wrote:
>
> From: he peilin
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application
On Thu, Mar 21, 2024 at 10:12 AM wrote:
>
> From: he peilin
>
>
> Introduce a tracepoint for icmp_send, which can help users to get more
>
> detail information conveniently when icmp abnormal events happen.
>
>
> 1. Giving an usecase example:
>
> =
>
> When an
From: Jason Xing
Before this, we miss some cases where the TCP layer could send rst but
we cannot trace it. So I decided to complete it :)
v2
1. fix spelling mistakes
Jason Xing (3):
trace: adjust TP_STORE_ADDR_PORTS_SKB() parameters
trace: tcp: fully support trace_tcp_send_reset
tcp
From: Jason Xing
Prior to this patch, what we can see by enabling trace_tcp_send is
only happening under two circumstances:
1) active rst mode
2) non-active rst mode and based on the full socket
That means the inconsistency occurs if we use tcpdump and trace
simultaneously to see how rst
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/s
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/s
From: Jason Xing
Using the macro for other tracepoints use to be more concise.
No functional change.
Jason Xing (3):
trace: move to TP_STORE_ADDRS related macro to net_probe_common.h
trace: use TP_STORE_ADDRS() macro in inet_sk_error_report()
trace: use TP_STORE_ADDRS() macro
On Mon, Mar 25, 2024 at 12:05 PM Peilin He wrote:
>
> >> -
> >> v2->v3:
> >> Some fixes according to
> >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
> >> 1. Change the tracking directory to/sys/kernel/tracking.
> >> 2. Adjust the layout of the TP-STRUCT_entry
1 - 100 of 158 matches
Mail list logo
