-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
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
>
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 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 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
e efficient.
>
> Signed-off-by: fuyuanli
> Link:
> https://lore.kernel.org/netdev/20240229052813.GA23899@didi-ThinkCentre-M920t-N000/
Reviewed-by: Jason Xing
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
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 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 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
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
thanks!
Reviewed-by: Jason Xing
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
[...]
> >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 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
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
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 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
>
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 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
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
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
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
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
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
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
>
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 (
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
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
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 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
On Sun, Aug 3, 2025 at 12:00 PM Menglong Dong wrote:
>
> On Sun, Aug 3, 2025 at 10:54 AM Jason Xing wrote:
> >
> > On Sun, Aug 3, 2025 at 9:59 AM Menglong Dong
> > wrote:
> > >
> > > On Sat, Aug 2, 2025 at 9:06 PM Jason Xing
> > > wrote:
On Sun, Aug 3, 2025 at 9:59 AM Menglong Dong wrote:
>
> On Sat, Aug 2, 2025 at 9:06 PM Jason Xing wrote:
> >
> > Hi Menglong,
> >
> > On Sat, Aug 2, 2025 at 5:28 PM Menglong Dong
> > wrote:
> > >
> > > For now, the tcp socket look
Hi Menglong,
On Sat, Aug 2, 2025 at 5:28 PM Menglong Dong wrote:
>
> For now, the tcp socket lookup will terminate if the socket is reuse port
> in inet_lhash2_lookup(), which makes the socket is not the best match.
>
> For example, we have socket1 and socket2 both listen on "0.0.0.0:1234",
> but
37 matches
Mail list logo
