netdev - Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Nov 2011 10:16:28 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Markus Trippelsdorf <markus@...ppelsdorf.de>
Cc:	"Alex,Shi" <alex.shi@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>,
	Matt Mackall <mpm@...enic.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

Le lundi 21 novembre 2011 à 09:24 +0100, Markus Trippelsdorf a écrit :
> On 2011.11.21 at 09:05 +0100, Markus Trippelsdorf wrote:
> > On 2011.11.21 at 08:44 +0800, Alex,Shi wrote:
> > > On Fri, 2011-11-18 at 20:02 +0800, Markus Trippelsdorf wrote:
> > > > On 2011.11.18 at 09:54 +0100, Markus Trippelsdorf wrote:
> > > > > On 2011.11.18 at 16:43 +0800, Alex,Shi wrote:
> > > > > > > > 
> > > > > > > > The dirty flag comes from a bunch of unrelated xfs patches from Christoph, that
> > > > > > > > I'm testing right now.
> > > > > > 
> > > > > > Where is the xfs patchset? I am wondering if it is due to slub code. 
> > > > 
> > > > I begin to wonder if this might be the result of a compiler bug. 
> > > > The kernel in question was compiled with gcc version 4.7.0 20111117. And
> > > > there was commit to the gcc repository today that looks suspicious:
> > > > http://gcc.gnu.org/viewcvs?view=revision&revision=181466
> > > > 
> > > 
> > > Tell us if it is still there and you can reproduce it.
> > 
> > Hm, just noticed the "3.2.0-rc1 panic on PowerPC" thread:
> > http://thread.gmane.org/gmane.linux.kernel/1215584
> > 
> > The backtraces look suspiciously similar to mine.
> 
> So everything points to commit 87fb4b7b533:
> "net: more accurate skb truesize"
> 
> Can you take a look Eric?


This commit was followed by a fix (for SLOB, since SLUB/SLAB were not
affected)

Check commit bc417e30f8df (net: Add back alignment for size for
__alloc_skb)

If current kernel still crash, I believe there is a problem elsewhere (a
refcounting problem) that makes underlying page being reused :

The ksize(skb->head) call in pskb_expand_head() assumes skb->head is a
valid zone, not an already freed one...

By the way, we probably can remove (almost dead) code from
pskb_expand_head() since we now place struct skb_shared_info at the end
of skb->head at skb creation.

I'll send this patch later for net-next

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 18a3ceb..5fd67a8 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -892,17 +892,6 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
 		fastpath = atomic_read(&skb_shinfo(skb)->dataref) == delta;
 	}
 
-	if (fastpath &&
-	    size + sizeof(struct skb_shared_info) <= ksize(skb->head)) {
-		memmove(skb->head + size, skb_shinfo(skb),
-			offsetof(struct skb_shared_info,
-				 frags[skb_shinfo(skb)->nr_frags]));
-		memmove(skb->head + nhead, skb->head,
-			skb_tail_pointer(skb) - skb->head);
-		off = nhead;
-		goto adjust_others;
-	}
-
 	data = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask);
 	if (!data)
 		goto nodata;
@@ -935,7 +924,6 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
 	off = (data + nhead) - skb->head;
 
 	skb->head     = data;
-adjust_others:
 	skb->data    += off;
 #ifdef NET_SKBUFF_DATA_USES_OFFSET
 	skb->end      = size;








--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html