All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <edumazet@google.com>
To: Dmitry Safonov <dima@arista.com>
Cc: David Ahern <dsahern@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	linux-kernel@vger.kernel.org,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Francesco Ruggeri <fruggeri05@gmail.com>,
	Salam Noureddine <noureddine@arista.com>,
	Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH v4 6/7] net/tcp: Store SNEs + SEQs on ao_info
Date: Wed, 29 Nov 2023 19:34:07 +0100	[thread overview]
Message-ID: <CANn89iLZx-SiV0BqHkEt9vS4LZzDxW2omvfOvNX6XWSRPFs7sw@mail.gmail.com> (raw)
In-Reply-To: <df55eb1d-b63a-4652-8103-d2bd7b5d7eda@arista.com>

On Wed, Nov 29, 2023 at 7:14 PM Dmitry Safonov <dima@arista.com> wrote:
>
> On 11/29/23 18:09, Eric Dumazet wrote:
> > On Wed, Nov 29, 2023 at 5:57 PM Dmitry Safonov <dima@arista.com> wrote:
> >>
> >> RFC 5925 (6.2):
> >>> TCP-AO emulates a 64-bit sequence number space by inferring when to
> >>> increment the high-order 32-bit portion (the SNE) based on
> >>> transitions in the low-order portion (the TCP sequence number).
> >>
> >> snd_sne and rcv_sne are the upper 4 bytes of extended SEQ number.
> >> Unfortunately, reading two 4-bytes pointers can't be performed
> >> atomically (without synchronization).
> >>
> >> In order to avoid locks on TCP fastpath, let's just double-account for
> >> SEQ changes: snd_una/rcv_nxt will be lower 4 bytes of snd_sne/rcv_sne.
> >>
> >
> > This will not work on 32bit kernels ?
>
> Yeah, unsure if there's someone who wants to run BGP on 32bit box, so at
> this moment it's already limited:
>
> config TCP_AO
>         bool "TCP: Authentication Option (RFC5925)"
>         select CRYPTO
>         select TCP_SIGPOOL
>         depends on 64BIT && IPV6 != m # seq-number extension needs WRITE_ONCE(u64)
>

Oh well, this seems quite strange to have such a limitation.

> Probably, if there will be a person who is interested in this, it can
> get a spinlock for !CONFIG_64BIT.


>
> > Unless ao->snd_sne and ao->rcv_sneare only read/written under the
> > socket lock (and in this case no READ_ONCE()/WRITE_ONCE() should be
> > necessary)
>

You have not commented on where these are read without the socket lock held ?

tcp_ao_get_repair() can lock the socket.

In TW state, I guess these values can not be changed ?

I think you can remove all these READ_ONCE()/WRITE_ONCE() which are not needed,
or please add a comment if they really are.

Then, you might be able to remove the 64BIT dependency ...

  reply	other threads:[~2023-11-29 18:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 16:57 [PATCH v4 0/7] TCP-AO fixes Dmitry Safonov
2023-11-29 16:57 ` [PATCH v4 1/7] Documentation/tcp: Fix an obvious typo Dmitry Safonov
2023-11-29 16:57 ` [PATCH v4 2/7] net/tcp: Consistently align TCP-AO option in the header Dmitry Safonov
2023-11-29 17:02   ` Eric Dumazet
2023-11-29 16:57 ` [PATCH v4 3/7] net/tcp: Limit TCP_AO_REPAIR to non-listen sockets Dmitry Safonov
2023-11-29 17:38   ` Eric Dumazet
2023-11-29 16:57 ` [PATCH v4 4/7] net/tcp: Allow removing current/rnext TCP-AO keys on TCP_LISTEN sockets Dmitry Safonov
2023-11-29 17:53   ` Eric Dumazet
2023-11-29 18:11     ` Dmitry Safonov
2023-11-29 16:57 ` [PATCH v4 5/7] net/tcp: Don't add key with non-matching VRF on connected sockets Dmitry Safonov
2023-11-29 17:59   ` Eric Dumazet
2023-11-29 16:57 ` [PATCH v4 6/7] net/tcp: Store SNEs + SEQs on ao_info Dmitry Safonov
2023-11-29 18:09   ` Eric Dumazet
2023-11-29 18:14     ` Dmitry Safonov
2023-11-29 18:34       ` Eric Dumazet [this message]
2023-11-29 19:57         ` Dmitry Safonov
2023-11-29 21:01           ` Eric Dumazet
2023-11-29 22:12             ` Dmitry Safonov
2023-12-02 17:16   ` Simon Horman
2023-12-04 17:08     ` Dmitry Safonov
2023-12-07 10:52       ` Simon Horman
2023-11-29 16:57 ` [PATCH v4 7/7] net/tcp: Don't store TCP-AO maclen on reqsk Dmitry Safonov
2023-11-29 18:10   ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANn89iLZx-SiV0BqHkEt9vS4LZzDxW2omvfOvNX6XWSRPFs7sw@mail.gmail.com \
    --to=edumazet@google.com \
    --cc=0x7f454c46@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dima@arista.com \
    --cc=dsahern@kernel.org \
    --cc=fruggeri05@gmail.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=noureddine@arista.com \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.