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

[Menglong Dong]

On Wed, Mar 17, 2021 at 11:12 PM David Laight  wrote:
>
...
>
> Isn't MSG_CMSG_COMPAT an internal value?
> Could it be changed to 1u << 30 instead of 1u << 31 ?
> Then it wouldn't matter if the high bit of flags got replicated.
>

Yeah, MSG_CMSG_COMPAT is 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_*

[David Miller]

From: Menglong Dong 
Date: Wed, 17 Mar 2021 16:21:14 +0800

> Hello,
> 
> On Wed, Mar 17, 2021 at 9:38 AM Guenter Roeck  wrote:
>>
>> On Wed, Mar 17, 2021 at 01:02:51AM +0200, Andy Shevchenko wrote:
>> > On Wednesday, March 17, 2021, Guenter Roeck  wrote:
>> >
> ...
>>
>> The problem is in net/packet/af_packet.c:packet_recvmsg(). This function,
>> as well as all other rcvmsg functions, is declared as
>>
>> static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t 
>> len,
>>   int flags)
>>
>> MSG_CMSG_COMPAT (0x8000) is set in flags, meaning its value is negative.
>> This is then evaluated in
>>
>>if (flags & 
>> ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
>> goto out;
> So what should I do? Revert this patch? Or fix the usages of 'flags'?

I already reverted this patch from net-next to fix the regression.

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

[Guenter Roeck]

On Wed, Mar 17, 2021 at 09:53:23PM +0800, Menglong Dong wrote:
> On Wed, Mar 17, 2021 at 5:36 PM Andy Shevchenko
>  wrote:
> >
> ...
> >
> > The problematic code is negation of the flags when it's done in
> > operations like &.
> > It maybe fixed by swapping positions of the arguments, i.e. ~(FOO |
> > BAR) & flags.
> >
> > All this is a beast called "integer promotions" in the C standard.
> >
> > The best is to try to get flags to be unsigned. By how invasive it may be?
> 
> 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,
> 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.

Also, flags is used in several other functions, not just recvmsg.

> This patch is already reverted, and I think maybe
> I can resend it after I fix these 'int' flags.

I would suggest to consult with Dave on that. While much of the conversion
could be handled automatically with coccinelle, it touches a lot of files.
I don't think that is worth the effort (or risk).

Guenter

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

[David Laight]

From: Guenter Roeck
> Sent: 17 March 2021 01:38
...
> MSG_CMSG_COMPAT (0x8000) is set in flags, meaning its value is negative.
> This is then evaluated in
> 
>if (flags & 
> ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
> goto out;
> 
> If any of those flags is declared as BIT() and thus long, flags is
> sign-extended to long. Since it is negative, its upper 32 bits will be set,
> the if statement evaluates as true, and the function bails out.
> 
> This is relatively easy to fix here with, for example,
> 
> if ((unsigned int)flags & 
> ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
> goto out;
> 
> but that is just a hack, and it doesn't solve the real problem:
> Each function in struct proto_ops which passes flags passes it as int
> (see include/linux/net.h:struct proto_ops). Each such function, if
> called with MSG_CMSG_COMPAT set, will fail a match against
> ~(MSG_anything) if MSG_anything is declared as BIT() or long.

Isn't MSG_CMSG_COMPAT an internal value?
Could it be changed to 1u << 30 instead of 1u << 31 ?
Then it wouldn't matter if the high bit of flags got replicated.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

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

[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,
> 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.
>

I doubt it now...there are hundreds of functions that are defined as
'proto_ops->recvmsg()'.
enn...will this kind of patch be acceptable? Is it the time to give up?

With Best Regards,
Menglong Dong

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

[Menglong Dong]

On Wed, Mar 17, 2021 at 5:36 PM Andy Shevchenko
 wrote:
>
...
>
> The problematic code is negation of the flags when it's done in
> operations like &.
> It maybe fixed by swapping positions of the arguments, i.e. ~(FOO |
> BAR) & flags.
>
> All this is a beast called "integer promotions" in the C standard.
>
> The best is to try to get flags to be unsigned. By how invasive it may be?

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,
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_*

[Guenter Roeck]

On 3/17/21 2:40 AM, Andy Shevchenko wrote:
> On Wed, Mar 17, 2021 at 11:36 AM Andy Shevchenko
>  wrote:
>> On Wed, Mar 17, 2021 at 10:21 AM Menglong Dong  
>> wrote:
> 
> ...
> 
>> It maybe fixed by swapping positions of the arguments, i.e. ~(FOO |
>> BAR) & flags.
> 
> ...and type casting will be needed anyway here...
> 
> I was thinking about this case
> 
> drivers/i2c/busses/i2c-designware-common.c:420:
> dev->sda_hold_time & ~(u32)DW_IC_SDA_HOLD_RX_MASK
> ,
> > but sda_hold_time there is unsigned.
> 
That is needed because of the %d. Without the (u32), the expression is
promoted to unsigned long and the compiler wants to see %ld.

Guenter

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

[Andy Shevchenko]

On Wed, Mar 17, 2021 at 11:36 AM Andy Shevchenko
 wrote:
> On Wed, Mar 17, 2021 at 10:21 AM Menglong Dong  
> wrote:

...

> It maybe fixed by swapping positions of the arguments, i.e. ~(FOO |
> BAR) & flags.

...and type casting will be needed anyway here...

I was thinking about this case

drivers/i2c/busses/i2c-designware-common.c:420:
dev->sda_hold_time & ~(u32)DW_IC_SDA_HOLD_RX_MASK
,

but sda_hold_time there is unsigned.

-- 
With Best Regards,
Andy Shevchenko

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

[Andy Shevchenko]

On Wed, Mar 17, 2021 at 10:21 AM Menglong Dong  wrote:
> On Wed, Mar 17, 2021 at 9:38 AM Guenter Roeck  wrote:
> > On Wed, Mar 17, 2021 at 01:02:51AM +0200, Andy Shevchenko wrote:
> > > On Wednesday, March 17, 2021, Guenter Roeck  wrote:
> > >
> ...
> >
> > The problem is in net/packet/af_packet.c:packet_recvmsg(). This function,
> > as well as all other rcvmsg functions, is declared as
> >
> > static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t 
> > len,
> >   int flags)
> >
> > MSG_CMSG_COMPAT (0x8000) is set in flags, meaning its value is negative.
> > This is then evaluated in
> >
> >if (flags & 
> > ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
> > goto out;
> >
> > If any of those flags is declared as BIT() and thus long, flags is
> > sign-extended to long. Since it is negative, its upper 32 bits will be set,
> > the if statement evaluates as true, and the function bails out.
> >
> > This is relatively easy to fix here with, for example,
> >
> > if ((unsigned int)flags & 
> > ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
> > goto out;
> >
> > but that is just a hack, and it doesn't solve the real problem:
> > Each function in struct proto_ops which passes flags passes it as int
> > (see include/linux/net.h:struct proto_ops). Each such function, if
> > called with MSG_CMSG_COMPAT set, will fail a match against
> > ~(MSG_anything) if MSG_anything is declared as BIT() or long.
> >
> > As it turns out, I was kind of lucky to catch the problem: So far I have
> > seen it only on mips64 kernels with N32 userspace.
> >
> > Guenter
>
>  Wow, now the usages of 'msg_flag' really puzzle me. Seems that
> it is used as '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).

The problematic code is negation of the flags when it's done in
operations like &.
It maybe fixed by swapping positions of the arguments, i.e. ~(FOO |
BAR) & flags.

All this is a beast called "integer promotions" in the C standard.

The best is to try to get flags to be unsigned. By how invasive it may be?

-- 
With Best Regards,
Andy Shevchenko

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

[Menglong Dong]

Hello,

On Wed, Mar 17, 2021 at 9:38 AM Guenter Roeck  wrote:
>
> On Wed, Mar 17, 2021 at 01:02:51AM +0200, Andy Shevchenko wrote:
> > On Wednesday, March 17, 2021, Guenter Roeck  wrote:
> >
...
>
> The problem is in net/packet/af_packet.c:packet_recvmsg(). This function,
> as well as all other rcvmsg functions, is declared as
>
> static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>   int flags)
>
> MSG_CMSG_COMPAT (0x8000) is set in flags, meaning its value is negative.
> This is then evaluated in
>
>if (flags & 
> ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
> goto out;
>
> If any of those flags is declared as BIT() and thus long, flags is
> sign-extended to long. Since it is negative, its upper 32 bits will be set,
> the if statement evaluates as true, and the function bails out.
>
> This is relatively easy to fix here with, for example,
>
> if ((unsigned int)flags & 
> ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
> goto out;
>
> but that is just a hack, and it doesn't solve the real problem:
> Each function in struct proto_ops which passes flags passes it as int
> (see include/linux/net.h:struct proto_ops). Each such function, if
> called with MSG_CMSG_COMPAT set, will fail a match against
> ~(MSG_anything) if MSG_anything is declared as BIT() or long.
>
> As it turns out, I was kind of lucky to catch the problem: So far I have
> seen it only on mips64 kernels with N32 userspace.
>
> Guenter

 Wow, now the usages of 'msg_flag' really puzzle me. Seems that
it is used as '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 RESEND net-next] net: socket: use BIT() for MSG_*

[Guenter Roeck]

On Wed, Mar 17, 2021 at 01:02:51AM +0200, Andy Shevchenko wrote:
> On Wednesday, March 17, 2021, Guenter Roeck  wrote:
> 
> > Hi,
> >
> > On Tue, Mar 09, 2021 at 05:51:35PM -0800, menglong8.d...@gmail.com wrote:
> > > From: Menglong Dong 
> > >
> > > The bit mask for MSG_* seems a little confused here. Replace it
> > > with BIT() to make it clear to understand.
> > >
> > > Signed-off-by: Menglong Dong 
> >
> > I must admit that I am a bit puzzled,
> 
> 
> I have checked the values and don’t see a problem. So, the only difference
> is the type int vs. unsigned long. I think this simply reveals an issue
> somewhere in the code.
> 
The problem is in net/packet/af_packet.c:packet_recvmsg(). This function,
as well as all other rcvmsg functions, is declared as

static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
  int flags)

MSG_CMSG_COMPAT (0x8000) is set in flags, meaning its value is negative.
This is then evaluated in

   if (flags & 
~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
goto out;

If any of those flags is declared as BIT() and thus long, flags is
sign-extended to long. Since it is negative, its upper 32 bits will be set,
the if statement evaluates as true, and the function bails out.

This is relatively easy to fix here with, for example,

if ((unsigned int)flags & 
~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
goto out;

but that is just a hack, and it doesn't solve the real problem:
Each function in struct proto_ops which passes flags passes it as int
(see include/linux/net.h:struct proto_ops). Each such function, if
called with MSG_CMSG_COMPAT set, will fail a match against
~(MSG_anything) if MSG_anything is declared as BIT() or long.

As it turns out, I was kind of lucky to catch the problem: So far I have
seen it only on mips64 kernels with N32 userspace.

Guenter

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

[Guenter Roeck]

On 3/16/21 4:02 PM, Andy Shevchenko wrote:
> 
> 
> On Wednesday, March 17, 2021, Guenter Roeck  > wrote:
> 
> Hi,
> 
> On Tue, Mar 09, 2021 at 05:51:35PM -0800, menglong8.d...@gmail.com 
>  wrote:
> > From: Menglong Dong  >
> >
> > The bit mask for MSG_* seems a little confused here. Replace it
> > with BIT() to make it clear to understand.
> >
> > Signed-off-by: Menglong Dong  >
> 
> I must admit that I am a bit puzzled,
> 
> 
> I have checked the values and don’t see a problem. So, the only difference is 
> the type int vs. unsigned long. I think this simply reveals an issue 
> somewhere in the code.
>  

I am currently trying to "bisect" the individual bits. We'll see if I can find
the culprit(s).

Guenter

> 
> 
>  but with this patch in the tree
> (in next-20210316) several of my qemu network interface tests fail
> to get an IP address. So far I have only seen this with mips64
> tests, but that may be because I only started running those tests
> on various architectures.
> 
> The tests do nothing special: With CONFIG_IP_PNP_DHCP=n, run udhcpc
> in qemu to get an IP address. With this patch in place, udhcpc fails.
> With this patch reverted, udhcpc gets the IP address as expected.
> The error reported by udhcpc is:
> 
> udhcpc: sending discover
> udhcpc: read error: Invalid argument, reopening socket
> 
> Reverting this patch fixes the problem.
> 
> Guenter
> 
> ---
> bisect log:
> 
> # bad: [0f4b0bb396f6f424a7b074d00cb71f5966edcb8a] Add linux-next specific 
> files for 20210316
> # good: [1e28eed17697bcf343c6743f0028cc3b5dd88bf0] Linux 5.12-rc3
> git bisect start 'HEAD' 'v5.12-rc3'
> # bad: [edd84c42baeffe66740143a04f24588fded94241] Merge remote-tracking 
> branch 'drm-misc/for-linux-next'
> git bisect bad edd84c42baeffe66740143a04f24588fded94241
> # good: [a76f62d56da82bee1a4c35dd6375a8fdd57eca4e] Merge remote-tracking 
> branch 'cel/for-next'
> git bisect good a76f62d56da82bee1a4c35dd6375a8fdd57eca4e
> # good: [e2924c67bae0cc15ca64dbe1ed791c96eed6d149] Merge remote-tracking 
> branch 'rdma/for-next'
> git bisect good e2924c67bae0cc15ca64dbe1ed791c96eed6d149
> # bad: [a8f9952d218d816ff1a13c9385edd821a8da527d] selftests: 
> fib_nexthops: List each test case in a different line
> git bisect bad a8f9952d218d816ff1a13c9385edd821a8da527d
> # bad: [4734a750f4674631ab9896189810b57700597aa7] mlxsw: Adjust some MFDE 
> fields shift and size to fw implementation
> git bisect bad 4734a750f4674631ab9896189810b57700597aa7
> # good: [32e76b187a90de5809d68c2ef3e3964176dacaf0] bpf: Document 
> BPF_PROG_ATTACH syscall command
> git bisect good 32e76b187a90de5809d68c2ef3e3964176dacaf0
> # good: [ee75aef23afe6e88497151c127c13ed69f41aaa2] bpf, xdp: Restructure 
> redirect actions
> git bisect good ee75aef23afe6e88497151c127c13ed69f41aaa2
> # bad: [90d181ca488f466904ea59dd5c836f766b69c71b] net: rose: Fix 
> fall-through warnings for Clang
> git bisect bad 90d181ca488f466904ea59dd5c836f766b69c71b
> # bad: [537a0c5c4218329990dc8973068f3bfe5c882623] net: fddi: skfp: smt: 
> Replace one-element array with flexible-array member
> git bisect bad 537a0c5c4218329990dc8973068f3bfe5c882623
> # bad: [97c2c69e1926260c78c7f1c0b2c987934f1dc7a1] virtio-net: support XDP 
> when not more queues
> git bisect bad 97c2c69e1926260c78c7f1c0b2c987934f1dc7a1
> # good: [c1acda9807e2bbe1d2026b44f37d959d6d8266c8] Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next 
> 
> git bisect good c1acda9807e2bbe1d2026b44f37d959d6d8266c8
> # bad: [0bb3262c0248d44aea3be31076f44beb82a7b120] net: socket: use BIT() 
> for MSG_*
> git bisect bad 0bb3262c0248d44aea3be31076f44beb82a7b120
> # first bad commit: [0bb3262c0248d44aea3be31076f44beb82a7b120] net: 
> socket: use BIT() for MSG_*
> 
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

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

[Guenter Roeck]

Hi,

On Tue, Mar 09, 2021 at 05:51:35PM -0800, menglong8.d...@gmail.com wrote:
> From: Menglong Dong 
> 
> The bit mask for MSG_* seems a little confused here. Replace it
> with BIT() to make it clear to understand.
> 
> Signed-off-by: Menglong Dong 

I must admit that I am a bit puzzled, but with this patch in the tree
(in next-20210316) several of my qemu network interface tests fail
to get an IP address. So far I have only seen this with mips64
tests, but that may be because I only started running those tests
on various architectures.

The tests do nothing special: With CONFIG_IP_PNP_DHCP=n, run udhcpc
in qemu to get an IP address. With this patch in place, udhcpc fails.
With this patch reverted, udhcpc gets the IP address as expected.
The error reported by udhcpc is:

udhcpc: sending discover
udhcpc: read error: Invalid argument, reopening socket

Reverting this patch fixes the problem.

Guenter

---
bisect log:

# bad: [0f4b0bb396f6f424a7b074d00cb71f5966edcb8a] Add linux-next specific files 
for 20210316
# good: [1e28eed17697bcf343c6743f0028cc3b5dd88bf0] Linux 5.12-rc3
git bisect start 'HEAD' 'v5.12-rc3'
# bad: [edd84c42baeffe66740143a04f24588fded94241] Merge remote-tracking branch 
'drm-misc/for-linux-next'
git bisect bad edd84c42baeffe66740143a04f24588fded94241
# good: [a76f62d56da82bee1a4c35dd6375a8fdd57eca4e] Merge remote-tracking branch 
'cel/for-next'
git bisect good a76f62d56da82bee1a4c35dd6375a8fdd57eca4e
# good: [e2924c67bae0cc15ca64dbe1ed791c96eed6d149] Merge remote-tracking branch 
'rdma/for-next'
git bisect good e2924c67bae0cc15ca64dbe1ed791c96eed6d149
# bad: [a8f9952d218d816ff1a13c9385edd821a8da527d] selftests: fib_nexthops: List 
each test case in a different line
git bisect bad a8f9952d218d816ff1a13c9385edd821a8da527d
# bad: [4734a750f4674631ab9896189810b57700597aa7] mlxsw: Adjust some MFDE 
fields shift and size to fw implementation
git bisect bad 4734a750f4674631ab9896189810b57700597aa7
# good: [32e76b187a90de5809d68c2ef3e3964176dacaf0] bpf: Document 
BPF_PROG_ATTACH syscall command
git bisect good 32e76b187a90de5809d68c2ef3e3964176dacaf0
# good: [ee75aef23afe6e88497151c127c13ed69f41aaa2] bpf, xdp: Restructure 
redirect actions
git bisect good ee75aef23afe6e88497151c127c13ed69f41aaa2
# bad: [90d181ca488f466904ea59dd5c836f766b69c71b] net: rose: Fix fall-through 
warnings for Clang
git bisect bad 90d181ca488f466904ea59dd5c836f766b69c71b
# bad: [537a0c5c4218329990dc8973068f3bfe5c882623] net: fddi: skfp: smt: Replace 
one-element array with flexible-array member
git bisect bad 537a0c5c4218329990dc8973068f3bfe5c882623
# bad: [97c2c69e1926260c78c7f1c0b2c987934f1dc7a1] virtio-net: support XDP when 
not more queues
git bisect bad 97c2c69e1926260c78c7f1c0b2c987934f1dc7a1
# good: [c1acda9807e2bbe1d2026b44f37d959d6d8266c8] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
git bisect good c1acda9807e2bbe1d2026b44f37d959d6d8266c8
# bad: [0bb3262c0248d44aea3be31076f44beb82a7b120] net: socket: use BIT() for 
MSG_*
git bisect bad 0bb3262c0248d44aea3be31076f44beb82a7b120
# first bad commit: [0bb3262c0248d44aea3be31076f44beb82a7b120] net: socket: use 
BIT() for MSG_*

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

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Tue,  9 Mar 2021 17:51:35 -0800 you wrote:
> From: Menglong Dong 
> 
> The bit mask for MSG_* seems a little confused here. Replace it
> with BIT() to make it clear to understand.
> 
> Signed-off-by: Menglong Dong 
> 
> [...]

Here is the summary with links:
  - [v4,RESEND,net-next] net: socket: use BIT() for MSG_*
https://git.kernel.org/netdev/net-next/c/0bb3262c0248

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html