linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	linville@tuxdriver.com, davem <davem@davemloft.net>
Subject: Re: [PATCH] Fix up truesize after pskb_expand_head() in wireless stack
Date: Mon, 5 Jan 2009 14:21:41 +0100	[thread overview]
Message-ID: <20090105132141.GO496@one.firstfloor.org> (raw)
In-Reply-To: <1231144574.3286.15.camel@johannes>

On Mon, Jan 05, 2009 at 09:36:14AM +0100, Johannes Berg wrote:
> On Sun, 2009-01-04 at 19:41 +0100, Andi Kleen wrote:
> 
> > I think most adjustments are too small to be noticed. Typically
> > they are just for a few bytes in the header. truesize
> > is already larger, so it can tolerate some slag.
> 
> 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.


> > I also only see it occasionally (maybe 5-10 times/day) when
> > the wireless stack appends a lot of data.
> 
> Except the data it appends should generally be of the same or very
> similar size under unchanging conditions, so that doesn't make a lot of
> sense either.

I don't know too much about the packet dynamics of the wireless stack,
but I can only report what my machine printed out.  

Here are some excerpts:

 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=769, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1404, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=769, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=920, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=462, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=1452, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=1452, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=1452, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=1452, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=1452, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=468, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=820, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=820, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=468, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=533, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=468, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=542, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (600) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1349, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216
 SKB BUG: Invalid truesize (920) len=1440, sizeof(sk_buff)=216

> I disagree, obviously. I knew there was some truesize corruption, and I
> think you for tracing down where it occurs. I'll investigate a proper
> fix when I get around to that, meanwhile I don't think the problem is
> awfully urgent since we've had this going on for quite a while and, if
> any, it probably only affects/corrupts the raw monitor sockets.

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

-Andi

-- 
ak@linux.intel.com

  reply	other threads:[~2009-01-05 13:07 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
2009-01-04 16:05 ` Johannes Berg
2009-01-04 16:28   ` Andi Kleen
2009-01-04 16:41     ` Johannes Berg
2009-01-04 17:43       ` Andi Kleen
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 [this message]
2009-01-05 13:16                 ` Johannes Berg
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=20090105132141.GO496@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=davem@davemloft.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.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).