[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2P5YsTuko5tgYJK@pevik>
Date: Thu, 3 Nov 2022 18:24:50 +0100
From: Petr Vorel <pvorel@...e.cz>
To: Xin Long <lucien.xin@...il.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Michal Kubecek <mkubecek@...e.cz>,
Toke Høiland-Jørgensen <toke@...hat.com>,
David Ahern <dsahern@...il.com>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Vasiliy Kulikov <segoon@...nwall.com>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: ping (iputils) review (call for help)
Hi Xin,
> On Thu, Nov 3, 2022 at 7:30 AM Petr Vorel <pvorel@...e.cz> wrote:
> > Hi,
> > I'm sorry to bother you about userspace. I'm preparing new iputils release and
> > I'm not sure about these two patches. As there has been many regressions,
> > review from experts is more than welcome.
> > If you have time to review them, it does not matter if you post your
> > comments/RBT in github or here (as long as you keep Cc me so that I don't
> > overlook it).
> > BTW I wonder if it make sense to list Hideaki YOSHIFUJI as NETWORKING
> > IPv4/IPv6 maintainer. If I'm not mistaken, it has been a decade since he was active.
> > * ping: Call connect() before sending/receiving
> > https://github.com/iputils/iputils/pull/391
> > => I did not even knew it's possible to connect to ping socket, but looks like
> > it works on both raw socket and on ICMP datagram socket.
> The workaround of not using the PING socket is:
> # sysctl -w net.ipv4.ping_group_range="1 0"
Well raw socket requires capabilities or setuid. Because some distros has moved to
ICMP datagram socket, this approach requires root.
> > * ping: revert "ping: do not bind to device when destination IP is on device
> > https://github.com/iputils/iputils/pull/396
> > => the problem has been fixed in mainline and stable/LTS kernels therefore I
> > suppose we can revert cc44f4c as done in this PR. It's just a question if we
> > should care about people who run new iputils on older (unfixed) kernels.
> cc44f4c has also caused some regression though it's only seen in the
> kselftests, and that is why I made the kernel fix. I don't know which
> regression is more serious regardless of the patch's correctness. :-).
I'd prefer users not being affected than fixed tests and ping not working.
BTW can you be more specific, which kselftests is affected?
Ideally link to lore. In [1] you just mentioned "Jianlin noticed", I haven't
found anything on lore.
> or can we put some changelog to say that this revert should be
> backported together with the kernel commit?
Well, this practically means new iputils (compiled from git) will not work on
older (unfixed) kernel. Probably not many people will be affected, but why
to upset anybody?
If the problem now is just broken kselftests, I'd prefer keeping it long enough
(at least 1 year?) before reverting it.
Kind regards,
Petr
[1] https://lore.kernel.org/all/ea03066bc7256ab86df8d3501f3440819305be57.1644988852.git.lucien.xin@gmail.com/
Powered by blists - more mailing lists