On Wed, Jan 21, 2026 at 3:01 PM Paul Moses [off-list ref] wrote:
padding? why does fzero-init-padding-bits exist?
Which padding are you referring to?
$ pahole -C tc_gate --hex net/sched/act_gate.o
struct tc_gate {
__u32 index; /* 0 0x4 */
__u32 capab; /* 0x4 0x4 */
int action; /* 0x8 0x4 */
int refcnt; /* 0xc 0x4 */
int bindcnt; /* 0x10 0x4 */
/* size: 20, cachelines: 1, members: 5 */
/* last cacheline: 20 bytes */
};
I see no padding.
On Wednesday, January 21st, 2026 at 7:48 AM, Eric Dumazet [off-list ref] wrote:
quoted
On Wed, Jan 21, 2026 at 2:39 PM Paul Moses p@1g4.org wrote:
quoted
Yes, it's not proven so you might be right, I knew it was 4 bytes at best. We can do next or toss it, I don't feel strongly either way.
These bytes are cleared by C compilers.
https://en.cppreference.com/w/c/language/struct_initialization.html
Only holes might be left uninitialized.
quoted
On Wednesday, January 21st, 2026 at 7:25 AM, Eric Dumazet edumazet@google.com wrote:
quoted
On Wed, Jan 21, 2026 at 2:20 PM Paul Moses p@1g4.org wrote:
quoted
Zero-initialize the dump struct before selective assignment to avoid
leaking stack padding in netlink replies. This matches other actions
(e.g. act_connmark) that zero-init their dump structs.
Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
Cc: <redacted>
Signed-off-by: Paul Moses <redacted>
---
I do not see a bug to fix, current code is fine.
act_connmark problem was that "struct tc_connmark" had a 16bit hole.
No such issue for struct tc_gate.