[PATCH net] mptcp: Avoid unsequenced accesses to jiffies in mptcp_reset_tout_timer()

[Nathan Chancellor <nathan@kernel.org>]

After a recent improvement in clang to warn on unsequenced accesses to
volatile variables [1], an instance appears in mptcp_reset_tout_timer(),
which can break the build with CONFIG_WERROR=y / W=e:

  net/mptcp/protocol.c:3044:20: error: unsequenced accesses to volatile qualified 'jiffies' [-Werror,-Wunsequenced]
   3044 |                         tcp_jiffies32 + jiffies + mptcp_close_timeout(sk);
        |                         ~~~~~~~~~~~~~   ^

Per C11 5.1.2.3.2, accessing a volatile object is a side effect. Per C11
6.5.2, unsequenced side effects on the same scalar object are undefined
behavior. Per C11 6.5.3, unless otherwise specified, side effects and
value computations of subexpressions are unsequenced within expressions.

Add an explicit sequence point by splitting the addition expression in
half, eliminating the undefined behavior and clearing up the warning.

Cc: stable@vger.kernel.org
Fixes: 76a13b315709 ("mptcp: invoke MP_FAIL response when needed")
Closes: https://github.com/ClangBuiltLinux/linux/issues/2193
Link: https://github.com/llvm/llvm-project/commit/955715460eaf9188c241c74750637fc82dfcc423 [1]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 net/mptcp/protocol.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 8968db58083e..8a9efebf3497 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3041,7 +3041,8 @@ void mptcp_reset_tout_timer(struct mptcp_sock *msk, unsigned long fail_tout)
 		return;
 
 	close_timeout = (unsigned long)inet_csk(sk)->icsk_mtup.probe_timestamp -
-			tcp_jiffies32 + jiffies + mptcp_close_timeout(sk);
+			tcp_jiffies32;
+	close_timeout += jiffies + mptcp_close_timeout(sk);
 
 	/* the close timeout takes precedence on the fail one, and here at least one of
 	 * them is active

---
base-commit: aa40afa831ebfe45e40a23721711059f2ac584d4
change-id: 20261114-mptcp-wunsequenced-ccbb861b3d4c

Best regards,
--  
Cheers,
Nathan