* [PATCH] tcp: Use BIT() for OPTION_* constants
@ 2021-11-03 22:17 Leonard Crestez
2021-11-03 22:49 ` Eric Dumazet
0 siblings, 1 reply; 4+ messages in thread
From: Leonard Crestez @ 2021-11-03 22:17 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, David Ahern
Cc: Dmitry Safonov, Kuniyuki Iwashima, Hideaki YOSHIFUJI,
Jakub Kicinski, Neal Cardwell, Yuchung Cheng, Enke Chen, Wei Wang,
netdev, linux-kernel
Extending these flags using the existing (1 << x) pattern triggers
complaints from checkpatch. Instead of ignoring checkpatch modify the
existing values to use BIT(x) style in a separate commit.
Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
---
This was split away from a longer series implementing RFC5925
Authentication Option for TCP.
Link: https://lore.kernel.org/netdev/dc9dca0006fa1b586da44dcd54e29eb4300fe773.1635784253.git.cdleonard@gmail.com/
net/ipv4/tcp_output.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 6867e5db3e35..96f16386f50e 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -406,17 +406,17 @@ static void tcp_init_nondata_skb(struct sk_buff *skb, u32 seq, u8 flags)
static inline bool tcp_urg_mode(const struct tcp_sock *tp)
{
return tp->snd_una != tp->snd_up;
}
-#define OPTION_SACK_ADVERTISE (1 << 0)
-#define OPTION_TS (1 << 1)
-#define OPTION_MD5 (1 << 2)
-#define OPTION_WSCALE (1 << 3)
-#define OPTION_FAST_OPEN_COOKIE (1 << 8)
-#define OPTION_SMC (1 << 9)
-#define OPTION_MPTCP (1 << 10)
+#define OPTION_SACK_ADVERTISE BIT(0)
+#define OPTION_TS BIT(1)
+#define OPTION_MD5 BIT(2)
+#define OPTION_WSCALE BIT(3)
+#define OPTION_FAST_OPEN_COOKIE BIT(8)
+#define OPTION_SMC BIT(9)
+#define OPTION_MPTCP BIT(10)
static void smc_options_write(__be32 *ptr, u16 *options)
{
#if IS_ENABLED(CONFIG_SMC)
if (static_branch_unlikely(&tcp_have_smc)) {
base-commit: d4a07dc5ac34528f292a4f328cf3c65aba312e1b
--
2.25.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] tcp: Use BIT() for OPTION_* constants
2021-11-03 22:17 [PATCH] tcp: Use BIT() for OPTION_* constants Leonard Crestez
@ 2021-11-03 22:49 ` Eric Dumazet
2021-11-04 9:17 ` David Laight
0 siblings, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2021-11-03 22:49 UTC (permalink / raw)
To: Leonard Crestez, David S. Miller, Eric Dumazet, David Ahern
Cc: Dmitry Safonov, Kuniyuki Iwashima, Hideaki YOSHIFUJI,
Jakub Kicinski, Neal Cardwell, Yuchung Cheng, Enke Chen, Wei Wang,
netdev, linux-kernel
On 11/3/21 3:17 PM, Leonard Crestez wrote:
> Extending these flags using the existing (1 << x) pattern triggers
> complaints from checkpatch. Instead of ignoring checkpatch modify the
> existing values to use BIT(x) style in a separate commit.
>
> Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
>
Yes, I guess checkpatch does not know that we currently use at most 16 bits :)
u16 options = opts->options;
Anyway, this seems fine.
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [PATCH] tcp: Use BIT() for OPTION_* constants
2021-11-03 22:49 ` Eric Dumazet
@ 2021-11-04 9:17 ` David Laight
2021-11-04 16:38 ` Eric Dumazet
0 siblings, 1 reply; 4+ messages in thread
From: David Laight @ 2021-11-04 9:17 UTC (permalink / raw)
To: 'Eric Dumazet', Leonard Crestez, David S. Miller,
Eric Dumazet, David Ahern
Cc: Dmitry Safonov, Kuniyuki Iwashima, Hideaki YOSHIFUJI,
Jakub Kicinski, Neal Cardwell, Yuchung Cheng, Enke Chen, Wei Wang,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
From: Eric Dumazet
> Sent: 03 November 2021 22:50
>
> On 11/3/21 3:17 PM, Leonard Crestez wrote:
> > Extending these flags using the existing (1 << x) pattern triggers
> > complaints from checkpatch. Instead of ignoring checkpatch modify the
> > existing values to use BIT(x) style in a separate commit.
> >
> > Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
> >
>
> Yes, I guess checkpatch does not know that we currently use at most 16 bits :)
>
> u16 options = opts->options;
>
> Anyway, this seems fine.
Doesn't BIT() have a nasty habit of generating 64bit constants
that just cause a different set of issues when inverted?
It may be safe here - but who knows.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] tcp: Use BIT() for OPTION_* constants
2021-11-04 9:17 ` David Laight
@ 2021-11-04 16:38 ` Eric Dumazet
0 siblings, 0 replies; 4+ messages in thread
From: Eric Dumazet @ 2021-11-04 16:38 UTC (permalink / raw)
To: David Laight, 'Eric Dumazet', Leonard Crestez,
David S. Miller, Eric Dumazet, David Ahern
Cc: Dmitry Safonov, Kuniyuki Iwashima, Hideaki YOSHIFUJI,
Jakub Kicinski, Neal Cardwell, Yuchung Cheng, Enke Chen, Wei Wang,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
On 11/4/21 2:17 AM, David Laight wrote:
> From: Eric Dumazet
>> Sent: 03 November 2021 22:50
>>
>> On 11/3/21 3:17 PM, Leonard Crestez wrote:
>>> Extending these flags using the existing (1 << x) pattern triggers
>>> complaints from checkpatch. Instead of ignoring checkpatch modify the
>>> existing values to use BIT(x) style in a separate commit.
>>>
>>> Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
>>>
>>
>> Yes, I guess checkpatch does not know that we currently use at most 16 bits :)
>>
>> u16 options = opts->options;
>>
>> Anyway, this seems fine.
>
> Doesn't BIT() have a nasty habit of generating 64bit constants
> that just cause a different set of issues when inverted?
> It may be safe here - but who knows.
BIT() does not use/force 64bit constants, plain "unsigned long" ones.
Really this patch looks a nop to me.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-11-04 16:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-11-03 22:17 [PATCH] tcp: Use BIT() for OPTION_* constants Leonard Crestez
2021-11-03 22:49 ` Eric Dumazet
2021-11-04 9:17 ` David Laight
2021-11-04 16:38 ` Eric Dumazet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox