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:
> > >
> > > Hi Menglong,
> > >
> > > On Sat, Aug 2, 2025 at 5:28 PM Menglon
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 lookup will terminate if the socket is reuse port
> > in inet_lhash2_lookup(), which makes the socket is n
The test script is provided by Kuniyuki in [1], which is used to test the
selection of the TCP reuseport socket problem.
Link:
https://lore.kernel.org/netdev/20250801040757.156-1-kun...@google.com/ [1]
Signed-off-by: Menglong Dong
---
tools/testing/selftests/net/Makefile | 1
do the reuse
port logic. This can increase some overhead if there are many reuse port
socket :/
Fixes: c125e80b8868 ("soreuseport: fast reuseport TCP socket selection")
Signed-off-by: Menglong Dong
---
v3:
* use the approach in V1
* add the Fixes tag
---
net/ipv4/inet_hashtable
x27;, 43146))
SUCCESS: assigned properly: (, ('127.0.0.1', 43162))
ok 1 tcp_reuseport.test_reuseport_select
Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
Changes since V2:
* use the approach in V1
* add the Fixes tag in the 1st patch
* introduce the selftests
Menglong Dong (2):
ole, so we still can fail during attaching the
FENTRY_MULTI to all the kernel functions. This is something that we need
to fix in the feature.
Signed-off-by: Menglong Dong
---
tools/testing/selftests/bpf/Makefile | 2 +-
.../selftests/bpf/prog_tests/fentry_fexit.c | 22 +-
.../self
We need to get all the kernel function that can be traced sometimes, so we
move the get_syms() and get_addrs() in kprobe_multi_test.c to
trace_helpers.c and rename it to bpf_get_ksyms() and bpf_get_addrs().
Signed-off-by: Menglong Dong
---
.../bpf/prog_tests/kprobe_multi_test.c| 220
Add bench testcase for fentry_multi, fexit_multi and fmodret_multi in
bench_trigger.c.
Signed-off-by: Menglong Dong
---
v2:
- use the existing bpf bench framework instead of introducing new one
---
tools/testing/selftests/bpf/bench.c | 8 +++
.../selftests/bpf/benchs/bench_trigger.c
After the commit 5ad2f102 ("tracing/kprobe: bpf: Compare instruction
pointer with original one"), "bpf_kprobe_override" is not used anywhere
anymore, and we can remove it now.
Fixes: 5ad2f102 ("tracing/kprobe: bpf: Compare instruction pointer with
original one&
On Wed, Jul 10, 2024 at 10:18 PM Masami Hiramatsu wrote:
>
> On Wed, 10 Jul 2024 15:13:07 +0200
> Jiri Olsa wrote:
>
> > On Wed, Jul 10, 2024 at 04:59:39PM +0800, Menglong Dong wrote:
> > > After the commit 5ad2f102 ("tracing/kprobe: bpf: Compare instruction
After the commit 5ad2f102 ("tracing/kprobe: bpf: Compare instruction
pointer with original one"), "bpf_kprobe_override" is not used anywhere
anymore, and we can remove it now.
Signed-off-by: Menglong Dong
---
include/linux/trace_events.h | 1 -
1 file changed, 1 delet
On Sun, Mar 21, 2021 at 8:49 PM Herbert Xu wrote:
>
...
>
> Shouldn't you add some comment here to stop people from trying to
> use BIT(31) in the future?
>
> Thanks,
Yeah, I think it's necessary. Thank you for your reminder~
With Regards,
Menglong Dong
an internal value, and maybe
it's why it is defined as 1<< 31, to make it look different.
I think it's a good idea to change it to other value which is
not used, such as 1u<<21.
I will test it and resend this patch later, thanks~
With Regards,
Menglong Dong
On Wed, Mar 17, 2021 at 9:53 PM Menglong Dong wrote:
>
...
>
> Seems that the inconsistent usages of 'msg_flags' is a lot, for example the
> 'recvmsg()' in 'struct proto' and 'recvmsg()' in 'struct proto_ops':
>
> int (*rec
27;recvmsg()' in 'struct proto_ops':
int (*recvmsg)(struct sock *sk, struct msghdr *msg,
size_t len, int noblock, int flags,
int *addr_len);
This function prototype is used in many places, It's not easy to fix them.
This patch is already reverted, and I think maybe
I can resend it after I fix these 'int' flags.
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks!
Menglong Dong
7;unsigned int' somewhere, but 'int' somewhere
else.
As I found, It is used as 'int' in 'netlink_recvmsg()',
'io_sr_msg->msg_flags', 'atalk_sendmsg()',
'dn_recvmsg()', 'proto_ops->recvmsg()', etc.
So what should I do? Revert this patch? Or fix the usages of 'flags'?
Or change the type of MSG_* to 'unsigned int'? I prefer the last
one(the usages of 'flags' can be fixed too, maybe later).
Thanks!
Menglong Dong
are obviously welcome at any time.
Is 'net-next' open? Can I resend this patch now? It seems that a long
time has passed.
Thanks~
Menglong Dong
On Sun, Feb 7, 2021 at 7:52 PM Andy Shevchenko
wrote:
>
> On Sun, Feb 7, 2021 at 6:32 AM wrote:
> >
> > From: Menglong Dong
> >
> > The bit mask for MSG_* seems a little confused here. Replace it
> > with BIT() to make it clear to understand.
>
> N
Hello!
On Sat, Feb 6, 2021 at 4:20 PM Andy Shevchenko
wrote:
>
>
>
> On Saturday, February 6, 2021, wrote:
>>
>> From: Menglong Dong
>>
>> The bit mask for MSG_* seems a little confused here. Replace it
>> with BIT_MASK to make it clear to understan
these values per-namespace can be more flexible,
and users can have more choices. Is there any bad influence that I didn't
realize?
Thanks~
Menglong Dong
er to replace 'platform_get_irq' with
> > 'platform_get_irq_optional' here?
>
> No. You should stop overriding the result to -ENOENT and pass the result
> up the call chain instead. In order to do it, you should only check for (irq
> < 0).
Well, I didn't even notice this. It does seem to be another problem...
---
Best Regards
Menglong Dong
So, is it better to replace 'platform_get_irq' with
'platform_get_irq_optional' here?
--
Best Regards
Menglong Dong
ut OK.
Thanks for your suggestion, and I will pay attention to the [PATCH *] next time.
As for the bpf@, I guess that 'get_maintainer.pl' listed it to me
because of 'act_bpf.c'.
Cheers,
Menglong Dong
ment.
I notice that the codes for tcp skb receiving didn't change much
between v3.10 and the latest upstream version, and guess the latest
version can be triggered too.
If something is fixed and this WARN() won't be triggered, just ignore me.
Cheers,
Menglong Dong
The initialization for 'err' with '-EINVAL' is redundant and
can be removed, as it is updated soon.
Changes since v1:
- Remove redundant empty line
Signed-off-by: Menglong Dong
---
net/ipv4/devinet.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/
Dear Jakub,
On Sun, Nov 8, 2020 at 7:48 AM Jakub Kicinski wrote:
>
> On Fri, 6 Nov 2020 01:42:37 -0500 menglong8.d...@gmail.com wrote:
> > From: Menglong Dong
> >
> > The initialization for 'err' with '-EINVAL' is redundant and
> > can be rem
Dear Nik,
On Wed, Nov 4, 2020 at 12:26 AM Nikolay Aleksandrov wrote:
>
> On Mon, 2020-11-02 at 22:38 +0800, Menglong Dong wrote:
> > From: Menglong Dong
> >
> > This commit seems make no sense, as bridge is destroyed when
> > br_multicast_dev_del is called.
From: Menglong Dong
This commit seems make no sense, as bridge is destroyed when
br_multicast_dev_del is called.
In commit b1b9d366028f
("bridge: move bridge multicast cleanup to ndo_uninit"), Xin Long
fixed the use-after-free panic in br_multicast_group_expired by
moving br_multica
From: Menglong Dong
This blank seems redundant.
Signed-off-by: Menglong Dong
---
net/ipv6/reassembly.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 1f5d4d196dcc..b1b8d104063b 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6
Hello~
On Mon, Oct 26, 2020 at 5:52 PM Paolo Abeni wrote:
>
> Hello,
>
> On Mon, 2020-10-26 at 17:39 +0800, Menglong Dong wrote:
> > The error returned from __udp_enqueue_schedule_skb is ENOMEM or ENOBUFS.
> > For now, only ENOMEM is counted into UDP_MIB_RCVBUFERRORS in
FS from __udp_enqueue_schedule_skb should be counted, too.
It means that the buffer used by all of the UDP sock is to the limit, and
it ought to be counted.
Signed-off-by: Menglong Dong
---
net/ipv4/udp.c | 4 +---
net/ipv6/udp.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --gi
31 matches
Mail list logo
