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 tracepoin
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 i
[...]
> >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.
> >
On Mon, Apr 1, 2024 at 8:34 PM wrote:
>
> From: hepeilin
>
> 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 experienc
thanks!
Reviewed-by: Jason Xing
tation now uses an argument to the L4 header and
> uses that to extract the source/destination ports, which happen
> to be named the same in "struct tcphdr" and "struct udphdr"
>
> Signed-off-by: Balazs Scheidler
The patch itself looks good to me, feel free to add:
Reviewed-by: Jason Xing
On Tue, Mar 26, 2024 at 10:28 AM Jakub Kicinski wrote:
>
> On Mon, 25 Mar 2024 11:29:18 +0100 Balazs Scheidler wrote:
> > +memset(__entry->saddr, 0, sizeof(struct sockaddr_in6));
> > +memset(__entry->daddr, 0, sizeof(struct sockaddr_in6));
>
> Indent with tabs pleas
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 p
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 experi
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 applicat
e efficient.
>
> Signed-off-by: fuyuanli
> Link:
> https://lore.kernel.org/netdev/20240229052813.GA23899@didi-ThinkCentre-M920t-N000/
Reviewed-by: Jason Xing
On Thu, Feb 29, 2024 at 1:33 PM fuyuanli wrote:
>
> It is useful to expose skb addr and sock addr to user in tracepoint
> tcp_probe, so that we can get more information while monitoring
> receiving of tcp data, by ebpf or other ways.
>
> For example, we need to identify a packet by seq and end_seq
On Tue, Feb 27, 2024 at 1:49 PM Eric Dumazet wrote:
>
> On Tue, Feb 27, 2024 at 3:50 AM wrote:
> >
> > From: xu xin
> >
> > 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 ex
On Fri, Feb 23, 2024 at 7:59 PM Breno Leitao wrote:
>
> Do not set rtnl_link_stats64 fields to zero, since they are zeroed
> before ops->ndo_get_stats64 is called in core dev_get_stats() function.
>
> Signed-off-by: Breno Leitao
Reviewed-by: Jason Xing
Another similar code
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 kernel to
>
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
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
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 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 un
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) disca
give up pacing'. 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
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 (
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
>
headline
and cc Greg.
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
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 a
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 sy
answer is 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-b
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 PO
er 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(s
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
>
-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
34 matches
Mail list logo
