Re: [PATCH net-next 2/2] net: socket: change MSG_CMSG_COMPAT to BIT(21)

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

Re: [PATCH v4 RESEND net-next] net: socket: use BIT() for MSG_*

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

Re: [PATCH v4 RESEND net-next] net: socket: use BIT() for MSG_*

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

Re: [PATCH v4 RESEND net-next] net: socket: use BIT() for MSG_*

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

Re: [PATCH v4 RESEND net-next] net: socket: use BIT() for MSG_*

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

Re: [PATCH v4 net-next] net: socket: use BIT() for MSG_*

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

Re: make sendmsg/recvmsg process multiple messages at once

have the same source until we meet a different one, in one cycle. However, in view of the exist of "recvmmsg/sendmmsg", my idea seems unnecessary~~~ Thanks~ Menglong Dong

make sendmsg/recvmsg process multiple messages at once

idea? This idea seems clumsy compared to the incoming 'io-uring' based zerocopy, but maybe it can help... Regards Menglong Dong

Re: [PATCH net-next 3/3] net: core: Namespace-ify sysctl_rmem_max and sysctl_wmem_max

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

Re: [PATCH] net: sched: fix misspellings using misspell-fixer tool

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

Re: [PATCH] net: tcp: ratelimit warnings in tcp_recvmsg

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

[PATCH v2] net: ipv4: remove redundant initialization in inet_rtm_deladdr

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/

Re: [PATCH] net: ipv4: remove redundant initialization in inet_rtm_deladdr

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

Re: [PATCH] net: bridge: disable multicast while delete bridge

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.

[PATCH] net: bridge: disable multicast while delete bridge

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

[PATCH] net: ipv6: remove redundant blank in ip6_frags_ns_sysctl_register

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

Re: [PATCH] net: udp: increase UDP_MIB_RCVBUFERRORS when ENOBUFS

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

[PATCH] net: udp: increase UDP_MIB_RCVBUFERRORS when ENOBUFS

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