tree c1b67e25829b884ab4e0de20b5ed81f5b8633be9
parent c4732276d4fa059b70b1862aef37d5614762302d
author Maciej Żenczykowski <maze@google.com> 1681800335 +0000
committer Maciej Żenczykowski <maze@google.com> 1681801500 +0000

allow ingress TCP FINs in doze mode

I don't know if this will truly help:

We'll still drop the expected egress TCP ACK (or FIN-ACK) reply
to the newly allowed ingress TCP FIN...

However: I don't think this will make things worse.

The presence of an ingress packet is proof the hardware already woke up to receive it.  This behaviour doesn't change when allowing ingress *anything*.

ie. the main reason we don't allow ingress packets is
that it would be illogical to be asymmetrical.

So even if we do immediately send back a reply (I think a RST is the only real possibility at the moment, since ACK would still be dropped).  Worst case we're waking the hardware up from RX processing to full blown TX processing.

Furthermore if an inbound FIN causes an outbound RST, then that
RST will most likely prevent receiving future FIN retransmits.

So we're trading an RX->TX hardware wake up now,
for less RX wakeups in the (near) future.

This *might* just be an overall win.

I think a true solution likely needs to be smarter still
and allow skb->sk state != BPF_TCP_ESTABLISHED (or something)

Bug: 259199087
Bug: 264903985
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I143f12342f72d89f9450560c8d60dad4c79ffe64