On Sat, Jun 22, 2019 at 8:35 AM David Ahern <dsah...@gmail.com> wrote: > > On 6/21/19 6:45 PM, Mahesh Bandewar wrote: > > When we invalidate dst or mark it "dead", we assign 'lo' to > > dst->dev. First of all this assignment is racy and more over, > > it has MTU implications. > > > > The standard dev MTU is 1500 while the Loopback MTU is 64k. TCP > > code when dereferencing the dst don't check if the dst is valid > > or not. TCP when dereferencing a dead-dst while negotiating a > > new connection, may use dst device which is 'lo' instead of > > using the correct device. Consider the following scenario: > > > > Why doesn't the TCP code (or any code) check if a cached dst is valid? > That's the whole point of marking it dead - to tell users not to rely on > it.
Well, I'm not an expert in TCP, but I could guess. Eric, please help me being honest with my guess. The code that marks it dead (control path) and the code that need to check the validity (data-path) need to have some sort of synchronization and that could be costly in the data-path. Also what is the worst case scenario? ... that packet is going to get dropped since the under-lying device or route has issues (minus this corner case). May be that was the reason. As I mentioned in the log, we could remove the racy-ness with barriers or locks but then that would be an additional cost in the data-path. having a dummy/backhole dev is the cheapest solution with no changes to the data-path.
