Skip to content
Snippets Groups Projects
Select Git revision
  • fourteen-qpr1
  • fifteen-qpr2
  • fourteen default
  • fifteen-qpr0
  • fifteen-qpr1
  • thirteen
  • staging/fourteen
  • twelve
  • staging/thirteen
  • staging/twelve
10 results
Search by author
  • Any Author
  • Adithya R Adithya R adithya2306
  • Ali Ali ali-nasiri-80
  • Dhina17 Dhina17 Dhina17
  • electimon electimon electimon
  • Erfan Abdi Erfan Abdi erfanoabdi
  • Farzin Kazemzadeh Farzin Kazemzadeh itisFarzin
  • LMO BuildBot LMO BuildBot lmo-buildbot
  • LMO GerritBot LMO GerritBot lmo-gerritbot
  • Mohammad Hasan Keramat J Mohammad Hasan Keramat J ikeramat
  • Nick Nick nift4
10 authors
  1. Oct 07, 2023
  3. Oct 06, 2023
  5. Oct 03, 2023
  7. Sep 29, 2023
  9. Sep 16, 2023
  11. Sep 13, 2023
  13. Sep 12, 2023
  15. Aug 29, 2023
  17. Jun 09, 2023
  19. May 20, 2023
  21. Apr 25, 2023
  23. Apr 20, 2023
  25. Apr 19, 2023
  27. Apr 18, 2023
    • Maciej Żenczykowski's avatar
      allow ingress TCP FINs in doze mode · bdccc508
      Maciej Żenczykowski authored 
      
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: default avatarMaciej Żenczykowski <maze@google.com>
Change-Id: I143f12342f72d89f9450560c8d60dad4c79ffe64
      bdccc508
  29. Apr 14, 2023
    • Maciej Żenczykowski's avatar
      bpf network stats - move double accounting tag!=0 out of bpf · ce7431f1
      Maciej Żenczykowski authored 
      
Instead of also accounting tag!=0 traffic against tag==0 slot,
while the bpf code writes into the map, move this logic into
the userspace jni code which reads from the map.

Simplifies the bpf program making things easier on the
kernel's bpf verifier, and is better for performance,
since a per-packet fixup operation becomes a per-poll fixup.

Test: TreeHugger, atest libnetworkstats_test FrameworksNetTests
Bug: 276296921
Signed-off-by: default avatarMaciej Żenczykowski <maze@google.com>
Change-Id: Ic220a201781a1170bcffe327fe5664fc12b65dd9
      ce7431f1
  31. Mar 02, 2023
  33. Jan 23, 2023
    • Ryan Zuklie's avatar
      Add packet tracing bpf implementation · 9419d25f
      Ryan Zuklie authored 
      This adds the core BPF implementation of Android network packet tracing.
The new code looks into the skb to pull out various bits of information.
Both the program and the ring buffer are restricted to 5.8+ kernels and
userdebug or eng builds.

With the packet_info_config map defaulting to zero, userdebug and eng
builds won't run any of the tracing today. The only effect will be 32k
memory increase for the ringbuf and the check on the config array.

Bug: 246985031
Test: build & flash both userdebug and user
Change-Id: I144da2971c0738b565ad58abc17e456209f13bde
      9419d25f
    • Ryan Zuklie's avatar
      Add BPF helpers for ipv4/ipv6 and tcp/udp offsets. · 1db34f3b
      Ryan Zuklie authored 
      Test: build & install connectivity module
Change-Id: I869810d05ad8266b6a4107a5276864fdbcdbd9b0
      1db34f3b
  35. Jan 20, 2023
  37. Jan 05, 2023
    • Ryan Zuklie's avatar
      Update bpf helpers to support new ignore_on fields · cc72fa8f
      Ryan Zuklie authored 
      This change updates callers to include the new ignore_on and bpfloader
arguments as per the change in aosp/2374598.

Bug: 246985031
Test: tethering build & install, full platform build & install
Change-Id: Id940a6003ae4cb0bbfc65db8ff96590c4f3c847b
      cc72fa8f
  39. Dec 30, 2022
  41. Dec 29, 2022
  43. Dec 18, 2022
  45. Nov 21, 2022
  47. Nov 20, 2022
  49. Oct 28, 2022
  51. Oct 27, 2022
    • Lorenzo Colitti's avatar
      Un-drop support for pre-4.14 kernels. · 3505b584
      Lorenzo Colitti authored 
      This effectively reverts commit 6ed2ab9b,
while ensuring that the program has the right permissions as
defined in r.android.com/2130014 :

oriole:/ # ls -lZ /sys/fs/bpf/netd_shared/prog_netd_cgroupsock_inet_create
-r--r----- 1 root root u:object_r:fs_bpf_netd_readonly:s0  0 2022-10-27 20:05 /sys/fs/bpf/netd_shared/prog_netd_cgroupsock_inet_create

Reason for revert: need to support 4.9 devices upgrading to T.

The only thing that cannot currently be supported on those
devices is the inet_create program which implements the
INTERNET permission.

Also, update bpf_existence_test so it does not check for the
existence of the program on pre-4.14 devices.

Bug: 254001921
Test: atest bpf_existence_test
Change-Id: I14f26cee5feeaae93b4d9710a7b9a2f835ff405f
      3505b584