From: Valtteri Vuorikoski <vuori@notcom.org>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: ip_nonlocal_bind causes havoc with local connection detection
Date: Thu, 20 Jul 2023 11:53:07 +0300 [thread overview]
Message-ID: <csjaofdmurrugpj6ktlthe676yer3g6l6kqzrmbmx2ndfoe2ah@4seihxkn5dpf> (raw)
In-Reply-To: <20230719161052.5b28568e@elisabeth>
On Wed, Jul 19, 2023 at 04:10:52PM +0200, Stefano Brivio wrote:
> > If that doesn't seem reasonable,
> > then maybe show a warning at start and/or just document that the
> > ip_nonlocal_bind setting shouldn't be used with passt?
>
> That's not really friendly, nor future-proof:
>
> https://bugs.passt.top/show_bug.cgi?id=48
>
> I think we should go the relatively hard way of extracting the relevant
> logic from procfs_scan_listen(), and understand from there if there's a
> local bind for the port at hand.
>
> I'm not sure, then, if we should always use this mechanism, even if
> ip_nonlocal_bind isn't set, because bind() gives us a lightweight way to
> check for three conditions in one, and we're on a latency-critical path
> here, so if this results in more syscalls, I would read from procfs
> just in case we really need to.
>
> Feel free to send a patch, or file a bug, or both, or none. :)
Thanks for checking this out. But yeah, I looked at the alternatives
a bit and none seemed really appealing. Maybe go for the proc route if
nonlocal binds were enabled at startup?
Luckily for me, it turned out that ip_nonlocal_bind was enabled on
some servers due to a service that had since been removed, so this
time we could solve the problem by just turning the sysctl off. I'll
try to get something into bugzilla for this issue anyway.
-Valtteri
prev parent reply other threads:[~2023-07-20 8:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 8:14 ip_nonlocal_bind causes havoc with local connection detection Valtteri Vuorikoski
2023-07-19 14:10 ` Stefano Brivio
2023-07-20 8:53 ` Valtteri Vuorikoski [this message]
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=csjaofdmurrugpj6ktlthe676yer3g6l6kqzrmbmx2ndfoe2ah@4seihxkn5dpf \
--to=vuori@notcom.org \
--cc=passt-dev@passt.top \
--cc=sbrivio@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.
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).