The other way to fix it would be to make the struct sk_buff_headThat general advice might not be compatible with what the kernel
equal in size with struct sk_buff:
struct sk_buff_head {
- /* These two members must be first. */
- struct sk_buff *next;
- struct sk_buff *prev;
+ union {
+ struct {
+ /* These two members must be first. */
+ struct sk_buff *next;
+ struct sk_buff *prev;
- __u32 qlen;
- spinlock_t lock;
+ __u32 qlen;
+ spinlock_t lock;
+ };
+ struct sk_buff __prv;
+ };
};
but that's much more invasive, and I don't even have means to
quantify this in terms of final binary size and performance
impact. I think that would be a flat out no go.
From the other hand if you look at the __skb_queue functions
they don't do much and at all so there is no much room for
other issues really. I followed the suggestion in [1]:
"if your function deliberately contains possible ..., you can
use __attribute__((no_sanitize... "
wants, especially since UBSAN_OBJECT_SIZE is normally disabled and I
think known to cause these issues in the kernel.
I'll defer to maintainers to decide what would be the preferred way of
handling this.