[0/2] Refactor Logging Infrastructure#485
[0/2] Refactor Logging Infrastructure#485yaakov-stein wants to merge 3 commits intofacebook:mainfrom
Conversation
Claude review of PR #485 (12b8bcf)Clean refactoring that renames Must fix
Suggestions
Nits
|
CGROUP_SOCK_ADDR Logging] Refactor Log Infrastructure
2bb9a67 to
c911410
Compare
c911410 to
7aeeab0
Compare
| /** Destination address (4 bytes for IPv4, 16 for IPv6). */ | ||
| bf_aligned(8) __u8 daddr[sizeof(struct in6_addr)]; | ||
| } sock_addr; | ||
| } payload; |
There was a problem hiding this comment.
I'd ideally have left this unnamed as there isn't much of a benefit of naming it and it now requires ->payload.pkt/sock_addr, but doxygen requires unions to be named :(
There was a problem hiding this comment.
Leave it unnamed, we'll find a way to deal with the Doxygen issue differently.
7aeeab0 to
4a18e6d
Compare
4a18e6d to
4c82f48
Compare
4c82f48 to
fe77c33
Compare
5c7c805 to
61e87f4
Compare
61e87f4 to
3634fd4
Compare
| /** | ||
| * @brief Packet log payload fields (XDP, TC, NF, cgroup_skb). | ||
| */ | ||
| struct _bf_log_pkt |
There was a problem hiding this comment.
This are only necessary internally but live in a public header file... I went with the approach of using the _bf prefix, but there weren't any examples to follow. Let me know if there's a better appraoch (maybe defining the structs directly inside the union?).
There was a problem hiding this comment.
Why is it only internal? This file can be included by clients reading from the ring buffer. I would suggest removing the _ prefix, as it's reserved in C. It's fine to use it in our own translation unit, as we control includes and naming, but it's not for public headers.
CGROUP_SOCK_ADDR Logging] Refactor Log InfrastructureRename the packet logging ELF stub from `log` to `pkt_log` to establish naming symmetry with the upcoming `sock_log` stub for socket-based hooks.
Add a bf_log_type discriminator and restructure bf_log as a tagged union with packet and socket variants. Packet-specific fields (pkt_size, headers, l2hdr/l3hdr/l4hdr) move into the pkt variant. The sock variant (pid, comm) is defined but not yet populated. The struct sizes to the larger packet variant, so total size is unchanged for ring buffer reservations.
3634fd4 to
12b8bcf
Compare
| /** Destination address (4 bytes for IPv4, 16 for IPv6). */ | ||
| bf_aligned(8) __u8 daddr[sizeof(struct in6_addr)]; | ||
| } sock_addr; | ||
| } payload; |
There was a problem hiding this comment.
Leave it unnamed, we'll find a way to deal with the Doxygen issue differently.
| /** | ||
| * @brief Packet log payload fields (XDP, TC, NF, cgroup_skb). | ||
| */ | ||
| struct _bf_log_pkt |
There was a problem hiding this comment.
Why is it only internal? This file can be included by clients reading from the ring buffer. I would suggest removing the _ prefix, as it's reserved in C. It's fine to use it in our own translation unit, as we control includes and naming, but it's not for public headers.
| /** User-requested headers, as defined in the rule. */ | ||
| __u8 req_headers; | ||
|
|
||
| /** Logged headers, as not all hooks can access all headers. */ | ||
| __u8 headers; |
There was a problem hiding this comment.
Why did you remove the :4 bitfield?
|
|
||
| for (int i = 0; i < _BF_LOG_OPT_MAX; ++i) { | ||
| if (bf_streq_i(str, _bf_log_opt_strs[i])) { | ||
| *opt = (enum bf_log_opt)i; |
There was a problem hiding this comment.
I don't think we need sock_addr logging to be configurable, there isn't that much data to log, and the only helper we'll use do current->tgid << 32 | current->pid. Hence, we can keep bf_pkthdr for packet logging options.
| static const char *_bf_log_type_strs[] = { | ||
| [BF_LOG_TYPE_PACKET] = "packet", | ||
| [BF_LOG_TYPE_SOCK_ADDR] = "sock_addr", | ||
| }; | ||
| static_assert_enum_mapping(_bf_pkthdr_strs, _BF_PKTHDR_MAX); | ||
| static_assert_enum_mapping(_bf_log_type_strs, _BF_LOG_TYPE_MAX); | ||
|
|
||
| const char *bf_pkthdr_to_str(enum bf_pkthdr hdr) | ||
| const char *bf_log_type_to_str(enum bf_log_type log_type) | ||
| { | ||
| if (hdr < 0 || hdr >= _BF_PKTHDR_MAX) | ||
| return "<bf_pkthdr unknown>"; | ||
| if (log_type < 0 || log_type >= _BF_LOG_TYPE_MAX) | ||
| return "<bf_log_type unknown>"; | ||
|
|
||
| return _bf_pkthdr_strs[hdr]; | ||
| return _bf_log_type_strs[log_type]; | ||
| } | ||
|
|
||
| int bf_pkthdr_from_str(const char *str, enum bf_pkthdr *hdr) | ||
| int bf_log_type_from_str(const char *str, enum bf_log_type *log_type) | ||
| { | ||
| assert(hdr); | ||
| assert(log_type); | ||
|
|
||
| for (int i = 0; i < _BF_PKTHDR_MAX; ++i) { | ||
| if (bf_streq_i(str, _bf_pkthdr_strs[i])) { | ||
| *hdr = (enum bf_pkthdr)i; | ||
| for (int i = 0; i < _BF_LOG_TYPE_MAX; ++i) { | ||
| if (bf_streq_i(str, _bf_log_type_strs[i])) { | ||
| *log_type = (enum bf_log_type)i; | ||
| return 0; | ||
| } | ||
| } | ||
|
|
||
| return -EINVAL; | ||
| } |
There was a problem hiding this comment.
We don't need this as we don't use it.
Stack:
CGROUP_SOCK_ADDRLogging Infrastructure #491Summary
This sets the stage for adding logging support for
CGROUP_SOCK_ADDR. The first step is renaming the logging infrastructure in a way that isn't packet-specific (or making it clear that certain parts are packet-specific and naming accordingly), and adding aunionthat allows us to add the necessary fields tobf_logto support this change.No functional change (besides the
bf_log_typeenum helper methods).