Thread (6 messages) 6 messages, 3 authors, 2020-11-27

Re: [PATCH net-next] net: switch to storing KCOV handle directly in sk_buff

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2020-11-27 16:51:31
Also in: linux-wireless, lkml

On Fri, Nov 27, 2020 at 7:26 AM Marco Elver [off-list ref] wrote:
On Thu, 26 Nov 2020 at 17:35, Willem de Bruijn
[off-list ref] wrote:
quoted
On Thu, Nov 26, 2020 at 3:19 AM Marco Elver [off-list ref] wrote:
[...]
quoted
quoted
Will send v2.
Does it make more sense to revert the patch that added the extensions
and the follow-on fixes and add a separate new patch instead?
That doesn't work, because then we'll end up with a build-broken
commit in between the reverts and the new version, because mac80211
uses skb_get_kcov_handle().
quoted
If adding a new field to the skb, even if only in debug builds,
please check with pahole how it affects struct layout if you
haven't yet.
Without KCOV:

        /* size: 224, cachelines: 4, members: 72 */
        /* sum members: 217, holes: 1, sum holes: 2 */
        /* sum bitfield members: 36 bits, bit holes: 2, sum bit holes: 4 bits */
        /* forced alignments: 2 */
        /* last cacheline: 32 bytes */

With KCOV:

        /* size: 232, cachelines: 4, members: 73 */
        /* sum members: 225, holes: 1, sum holes: 2 */
        /* sum bitfield members: 36 bits, bit holes: 2, sum bit holes: 4 bits */
        /* forced alignments: 2 */
        /* last cacheline: 40 bytes */
Thanks. defconfig leaves some symbols disabled, but manually enabling
them just fills a hole, so 232 is indeed the worst case allocation.

I recall a firm edict against growing skb, but I don't know of a
hard limit at exactly 224.

There is a limit at 2048 - sizeof(struct skb_shared_data) == 1728B
when using pages for two ETH_FRAME_LEN (1514) allocations.

This would leave 1728 - 1514 == 214B if also squeezing the skb itself
in with the same allocation.

But I have no idea if this is used anywhere. Certainly have no example
ready. And as you show, the previous default already is at 224.

If no one else knows of a hard limit at 224 or below, I suppose the
next technical limit is just 256 for kmem cache purposes.

My understanding was that skb_extensions was supposed to solve this
problem of extending the skb without growing the main structure. Not
for this patch, but I wonder if we can resolve the issues exposed here
and make usable in more conditions.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help