netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
	davem <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: Re: [PATCH] Fix up truesize after pskb_expand_head() in wireless stack
Date: Mon, 05 Jan 2009 14:16:19 +0100	[thread overview]
Message-ID: <1231161379.3334.14.camel@johannes> (raw)
In-Reply-To: <20090105132141.GO496-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

On Mon, 2009-01-05 at 14:21 +0100, Andi Kleen wrote:

> > This statement is incompatible with your patch when you think about the
> > exact definition of truesize and the (unconditional!) adjustments your
> > patch makes.
> 
> __alloc_skb does 
> 
>         size = SKB_DATA_ALIGN(size);
>         skb->truesize = size + sizeof(struct sk_buff);
> 
> [ BTW it would be probably better if alloc_skb() just asked
> slab what the truesize is for kmalloc instead of guessing wrong like this.
> But that's a different topic]
> 
> and SKB_DATA_ALIGN is 
> 
> #define SKB_DATA_ALIGN(X)       (((X) + (SMP_CACHE_BYTES - 1)) & \
>                                  ~(SMP_CACHE_BYTES - 1))
> 
> and on my configuration SMP_CACHE_BYTES is 64
> 
> skb_truesize_check does 
> 
>  int len = sizeof(struct sk_buff) + skb->len;
> 
>         if (unlikely((int)skb->truesize < len))
>                 skb_truesize_bug(skb);
> 
> This means if the change is less than the 64byte cache alignment 
> (or more commonly 128 bytes on GENERIC_CPU distro kernels)
> it won't be reported. To my knowledge header adjustments are usually
> smaller and that is what pskb_expand_head() is usually used for.

Ah, indeed, I thought I remembered that truesize had to match exactly,
but obviously that wasn't done either. We should experiment with that
though, and let pskb_expand_head() adjust things.

> I didn't use any monitoring with this. No tcpdump, no wireless
> sniffer tools or anything. It happened all the time during
> normal operation.

You did have a monitor interface up though, didn't you? If nothing
actually used those skbs then it's likely that the warning didn't result
in any corruption at all.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2009-01-05 13:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-04 15:18 [PATCH] Fix up truesize after pskb_expand_head() in wireless stack Andi Kleen
     [not found] ` <20090104151819.GA6590-3rXA9MLqAseW/qJFnhkgxti2O/JbrIOy@public.gmane.org>
2009-01-04 16:05   ` Johannes Berg
2009-01-04 16:28     ` Andi Kleen
     [not found]       ` <20090104162826.GT496-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org>
2009-01-04 16:41         ` Johannes Berg
2009-01-04 17:43           ` Andi Kleen
     [not found]             ` <20090104174339.GX496-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org>
2009-01-04 17:33               ` Johannes Berg
2009-01-04 18:41                 ` Andi Kleen
2009-01-05  6:49                   ` David Miller
2009-01-05 13:32                     ` Andi Kleen
2009-01-05  8:36                   ` Johannes Berg
2009-01-05 13:21                     ` Andi Kleen
     [not found]                       ` <20090105132141.GO496-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org>
2009-01-05 13:16                         ` Johannes Berg [this message]
2009-01-05 13:36                           ` Andi Kleen
2009-01-05 13:31                             ` Johannes Berg
2009-01-05 14:05                               ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1231161379.3334.14.camel@johannes \
    --to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
    --cc=andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).