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
next prev parent reply other threads:[~2009-01-05 13:07 UTC|newest]
Thread overview: 22+ 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 15:18 ` Andi Kleen
2009-01-04 16:05 ` Johannes Berg
2009-01-04 16:05 ` Johannes Berg
2009-01-04 16:28 ` Andi Kleen
2009-01-04 16:28 ` Andi Kleen
2009-01-04 16:41 ` Johannes Berg
2009-01-04 16:41 ` Johannes Berg
2009-01-04 17:43 ` Andi Kleen
2009-01-04 17:43 ` Andi Kleen
2009-01-04 17:33 ` Johannes Berg
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: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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.