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-26 16:35:20
Also in: linux-wireless, lkml

On Thu, Nov 26, 2020 at 3:19 AM Marco Elver [off-list ref] wrote:
On Wed, 25 Nov 2020 at 21:43, Jakub Kicinski [off-list ref] wrote:
quoted
On Wed, 25 Nov 2020 18:34:36 +0100 Marco Elver wrote:
quoted
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index ffe3dcc0ebea..070b1077d976 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -233,6 +233,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
      skb->end = skb->tail + size;
      skb->mac_header = (typeof(skb->mac_header))~0U;
      skb->transport_header = (typeof(skb->transport_header))~0U;
+     skb_set_kcov_handle(skb, kcov_common_handle());

      /* make sure we initialize shinfo sequentially */
      shinfo = skb_shinfo(skb);
@@ -249,9 +250,6 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,

              fclones->skb2.fclone = SKB_FCLONE_CLONE;
      }
-
-     skb_set_kcov_handle(skb, kcov_common_handle());
Why the move?
v2 of the original series had it above. I frankly don't mind.

1. Group it with the other fields above?

2. Leave it at the end here?
quoted
quoted
 out:
      return skb;
 nodata:
@@ -285,8 +283,6 @@ static struct sk_buff *__build_skb_around(struct sk_buff *skb,
      memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
      atomic_set(&shinfo->dataref, 1);

-     skb_set_kcov_handle(skb, kcov_common_handle());
-
      return skb;
 }
And why are we dropping this?
It wasn't here originally.
quoted
If this was omitted in earlier versions it's just a independent bug,
I don't think build_skb() will call __alloc_skb(), so we need a to
set the handle here.
Correct, that was an original omission.

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?

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.

The skb_extensions idea was mine. Apologies for steering
this into an apparently unsuccessful direction. Adding new fields
to skb is very rare because possibly problematic wrt allocation.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help