No description. Add one?
- Java 78%
- Kotlin 11.8%
- AIDL 4.4%
- C++ 3.7%
- C 1.5%
- Other 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
bdccc50824
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 |
||
| bpf_progs | ||
| common | ||
| Cronet | ||
| framework | ||
| framework-t | ||
| nearby | ||
| netd | ||
| service | ||
| service-t | ||
| tests | ||
| Tethering | ||
| tools | ||
| .gitignore | ||
| OWNERS | ||
| OWNERS_core_networking | ||
| OWNERS_core_networking_xts | ||
| PREUPLOAD.cfg | ||
| TEST_MAPPING | ||