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
rnal 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 (*recvmsg)(struct sock *sk, struct msghdr *msg,
>
t (*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
where, 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
o 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
o replace 'platform_get_irq' with
'platform_get_irq_optional' here?
--
Best Regards
Menglong Dong
.
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
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/ipv4/devinet.c b/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 removed, as it is up
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
rom __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 --git a/net/i
20 matches
Mail list logo
