lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20191202.184704.723174427717421022.davem@davemloft.net>
Date:   Mon, 02 Dec 2019 18:47:04 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     liuhangbin@...il.com
Cc:     netdev@...r.kernel.org, ja@....bg, marcelo.leitner@...il.com,
        dsahern@...il.com, edumazet@...gle.com
Subject: Re: [PATCHv2 net] ipv6/route: should not update neigh confirm time
 during PMTU update

From: Hangbin Liu <liuhangbin@...il.com>
Date: Tue,  3 Dec 2019 10:11:37 +0800

> Fix it by removing the dst_confirm_neigh() in __ip6_rt_update_pmtu() as
> there is no two-way communication during PMTU update.
> 
> v2: remove dst_confirm_neigh directly as David Miller pointed out.

That's not what I said.

I said that this interface is designed for situations where the neigh
update is appropriate, and that's what happens for most callers _except_
these tunnel cases.

The tunnel use is the exception and invoking the interface
inappropriately.

It is important to keep the neigh reachability fresh for TCP flows so
you cannot remove this dst_confirm_neigh() call.

Instead, make a new interface that the tunnel use cases can call into
to elide the neigh update.

Yes, this means you will have too update all of the tunnel callers
into these calls chains but that's the price we have to pay in this
situation unfortunately.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ