public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH 1/8] tcp: Fix address type for tcp_sock_init_af()
Date: Wed, 27 Dec 2023 21:25:06 +0100	[thread overview]
Message-ID: <20231227212506.75eb41c7@elisabeth> (raw)
In-Reply-To: <20231207143140.1851378-2-david@gibson.dropbear.id.au>

On Fri,  8 Dec 2023 01:31:33 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> This takes a struct in_addr * (i.e. an IPv4 address), although it's
> explicitly supposed to handle IPv6 as well.  Both its caller and sock_l4()
> which it calls use a void * for the address, which can be either an in_addr
> or an in6_addr.
> 
> We get away with this, because we don't do anything with the pointer other
> than transfer it from the caller to sock_l4(), but it's misleading.  And
> quite possibly technically UB, because C is like that.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  tcp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tcp.c b/tcp.c
> index f506cfd..bda95b2 100644
> --- a/tcp.c
> +++ b/tcp.c
> @@ -2905,7 +2905,7 @@ void tcp_sock_handler(struct ctx *c, union epoll_ref ref, uint32_t events)
>   * Return: fd for the new listening socket, negative error code on failure
>   */
>  static int tcp_sock_init_af(const struct ctx *c, int af, in_port_t port,
> -			    const struct in_addr *addr, const char *ifname)
> +			    const void *addr, const char *ifname)

This is obviously correct.

However, after a lot of thinking: (gcc) optimisations based on
Type-Based Alias Analysis, which we don't disable on this path, could,
now, happily defer filling 'addr' with inet_pton() in conf_ports() to a
point *after* the tcp_sock_init() call.

Without this patch, at least 32 bits must be updated before the call.

It might sound like a joke because... it actually is. But look at what
we had to do for the functions in checksum.c. We pass const void *buf,
and anything that buf points to can be updated (with TBAA) after the
call.

I don't see any conceptual difference between this case and those
functions.

Anyway, that won't reasonably happen here, and in any case this would
have been broken for IPv6, so I'll go ahead and apply this.

But, eventually, I think we should switch all these usages to union
inany_addr *.

-- 
Stefano


  reply	other threads:[~2023-12-27 20:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 14:31 [PATCH 0/8] Small cleanups related to addresses and binding David Gibson
2023-12-07 14:31 ` [PATCH 1/8] tcp: Fix address type for tcp_sock_init_af() David Gibson
2023-12-27 20:25   ` Stefano Brivio [this message]
2023-12-28  2:42     ` David Gibson
2023-12-28 10:11       ` Stefano Brivio
2024-01-07  5:35         ` David Gibson
2024-01-13 22:50           ` Stefano Brivio
2023-12-07 14:31 ` [PATCH 2/8] treewide: Use IN4ADDR_LOOPBACK_INIT more widely David Gibson
2023-12-07 14:31 ` [PATCH 3/8] treewide: Add IN4ADDR_ANY_INIT macro David Gibson
2023-12-07 14:31 ` [PATCH 4/8] util: Use htonl_constant() in more places David Gibson
2023-12-07 14:31 ` [PATCH 5/8] util: Improve sockaddr initialisation in sock_l4() David Gibson
2023-12-27 20:25   ` Stefano Brivio
2024-01-07  5:34     ` David Gibson
2023-12-07 14:31 ` [PATCH 6/8] icmp: Avoid unnecessary handling of unspecified bind address David Gibson
2023-12-07 14:31 ` [PATCH 7/8] treewide: Avoid in_addr_t David Gibson
2023-12-07 14:31 ` [PATCH 8/8] util: Make sock_l4() treat empty string ifname like NULL David Gibson
2023-12-27 20:25 ` [PATCH 0/8] Small cleanups related to addresses and binding Stefano Brivio

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=20231227212506.75eb41c7@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    /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.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).