| Message ID | 1438368669-659-1-git-send-email-f.fainelli@gmail.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
On Fri, Jul 31, 2015 at 11:51 AM, Florian Fainelli <f.fainelli@gmail.com> wrote: > On 64-bits hosts, napi_gro_cb is 48 bytes, which is exactly the size of > skb->cb[], while on 32-bits hosts it is 36 bytes, but if it were to > grow, we would not be catching a size inflation as we should. > > Make sure that we have enough room for a napi_gro_cb to be hosted in > skb->cb[], and put this build-time assertion in skb_gro_reset_offset() > since this function is invoked by the GRO layers entry points. > > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> > --- > net/core/dev.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/core/dev.c b/net/core/dev.c > index 4870c3556a5a..20bc82604b75 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -4115,6 +4115,8 @@ static void skb_gro_reset_offset(struct sk_buff *skb) > const struct skb_shared_info *pinfo = skb_shinfo(skb); > const skb_frag_t *frag0 = &pinfo->frags[0]; > > + BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct napi_gro_cb)); > + Maybe sizeof(struct napi_gro_cb) > sizeof(skb->cb) since this about napi_gro_cb being too big, not cb being too small. > NAPI_GRO_CB(skb)->data_offset = 0; > NAPI_GRO_CB(skb)->frag0 = NULL; > NAPI_GRO_CB(skb)->frag0_len = 0; > -- > 2.1.0 > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Florian Fainelli <f.fainelli@gmail.com> wrote: > On 64-bits hosts, napi_gro_cb is 48 bytes, which is exactly the size of > skb->cb[], while on 32-bits hosts it is 36 bytes, but if it were to > grow, we would not be catching a size inflation as we should. > --- > net/core/dev.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/core/dev.c b/net/core/dev.c > index 4870c3556a5a..20bc82604b75 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -4115,6 +4115,8 @@ static void skb_gro_reset_offset(struct sk_buff *skb) > const struct skb_shared_info *pinfo = skb_shinfo(skb); > const skb_frag_t *frag0 = &pinfo->frags[0]; > > + BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct napi_gro_cb)); commit c3c7c254b2e8cd99b0adf288c2a1bddacd7ba255 already added a check for this. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Florian Westphal <fw@strlen.de> Date: Fri, 31 Jul 2015 22:24:03 +0200 > Florian Fainelli <f.fainelli@gmail.com> wrote: >> On 64-bits hosts, napi_gro_cb is 48 bytes, which is exactly the size of >> skb->cb[], while on 32-bits hosts it is 36 bytes, but if it were to >> grow, we would not be catching a size inflation as we should. >> --- >> net/core/dev.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/net/core/dev.c b/net/core/dev.c >> index 4870c3556a5a..20bc82604b75 100644 >> --- a/net/core/dev.c >> +++ b/net/core/dev.c >> @@ -4115,6 +4115,8 @@ static void skb_gro_reset_offset(struct sk_buff *skb) >> const struct skb_shared_info *pinfo = skb_shinfo(skb); >> const skb_frag_t *frag0 = &pinfo->frags[0]; >> >> + BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct napi_gro_cb)); > > commit c3c7c254b2e8cd99b0adf288c2a1bddacd7ba255 > already added a check for this. Indeed. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 31/07/15 13:44, David Miller wrote: > From: Florian Westphal <fw@strlen.de> > Date: Fri, 31 Jul 2015 22:24:03 +0200 > >> Florian Fainelli <f.fainelli@gmail.com> wrote: >>> On 64-bits hosts, napi_gro_cb is 48 bytes, which is exactly the size of >>> skb->cb[], while on 32-bits hosts it is 36 bytes, but if it were to >>> grow, we would not be catching a size inflation as we should. >>> --- >>> net/core/dev.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/net/core/dev.c b/net/core/dev.c >>> index 4870c3556a5a..20bc82604b75 100644 >>> --- a/net/core/dev.c >>> +++ b/net/core/dev.c >>> @@ -4115,6 +4115,8 @@ static void skb_gro_reset_offset(struct sk_buff *skb) >>> const struct skb_shared_info *pinfo = skb_shinfo(skb); >>> const skb_frag_t *frag0 = &pinfo->frags[0]; >>> >>> + BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct napi_gro_cb)); >> >> commit c3c7c254b2e8cd99b0adf288c2a1bddacd7ba255 >> already added a check for this. > > Indeed. Whoops, missed that part, thanks Florian!
diff --git a/net/core/dev.c b/net/core/dev.c index 4870c3556a5a..20bc82604b75 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4115,6 +4115,8 @@ static void skb_gro_reset_offset(struct sk_buff *skb) const struct skb_shared_info *pinfo = skb_shinfo(skb); const skb_frag_t *frag0 = &pinfo->frags[0]; + BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct napi_gro_cb)); + NAPI_GRO_CB(skb)->data_offset = 0; NAPI_GRO_CB(skb)->frag0 = NULL; NAPI_GRO_CB(skb)->frag0_len = 0;
On 64-bits hosts, napi_gro_cb is 48 bytes, which is exactly the size of skb->cb[], while on 32-bits hosts it is 36 bytes, but if it were to grow, we would not be catching a size inflation as we should. Make sure that we have enough room for a napi_gro_cb to be hosted in skb->cb[], and put this build-time assertion in skb_gro_reset_offset() since this function is invoked by the GRO layers entry points. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> --- net/core/dev.c | 2 ++ 1 file changed, 2 insertions(+)