From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D177921F190 for ; Sun, 13 Jan 2013 19:05:40 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id e13so4491931iej.18 for ; Sun, 13 Jan 2013 19:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BlYRHrSAsrlxD2g1M5fThL4Ki3U7pebza0osQkL+Mco=; b=nTq0WJ0OUjoc3zEzEdsADR8qGMEpnkZDVWaW2Da7xuHQYwIskR8PMGm5deHYrgHrEr wEhMbiMkptWMSEx3yToJCntBkwIMt9/O+u48HF7CqAmoFrYOJxXD58vqG6Odo/AoksJC GNQ4u+sLDokXbi+s47bfVZuxpVIHYiE9by4loFJFUYGiRbEhue8uNxcuDb1fJ9XkN13n 2y1/8tYk3uVqvolKUoQa8H1GftzUugJRPdu87cUYkjpKD13EWsIxqu+PlkM8f0aYtD0o ZU2ajJ+RMVgHbF6smqgSKmNpJwis+Iv7Myzx75G9EvajL+02VKDggcJHvxhM/fyxaTeH XROA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=BlYRHrSAsrlxD2g1M5fThL4Ki3U7pebza0osQkL+Mco=; b=JlPU4PBk1csuR8SIq/kmRa+n4NtK3Zr11SlB8Yaj8RYfVVymKXM8qCQQzjQ2gzSPQx Xoskv6jiQ2vhGtNJkUuU04stxHBgf+SrqKyUD2OSeYq74BgSip6owq2s8vkfe1CV+U9m 5LzW93evedlF3LkRX3rCgvr/G0UUCtvtEwt5ig7vdR3CCWfyYAEw2aQFwbTqVaBQzs4a EviSHpZD0ybbDXFu9ThWSMjlSeMmJyF+7OtTtVvrsisVakB22CJfhrmyTd2yaTETzrsZ SZ0OPOH+sk6Q3JfHI7IN8csAgS2A7wvMLLsrNXFc0VGpkC4BM6S8SVN1T1U+DVCghDwJ 7uRA== MIME-Version: 1.0 X-Received: by 10.50.242.73 with SMTP id wo9mr5616499igc.36.1358132740164; Sun, 13 Jan 2013 19:05:40 -0800 (PST) Received: by 10.50.161.227 with HTTP; Sun, 13 Jan 2013 19:05:40 -0800 (PST) In-Reply-To: <50F32981.9080404@openwrt.org> References: <50F32981.9080404@openwrt.org> Date: Sun, 13 Jan 2013 19:05:40 -0800 Message-ID: From: Eric Dumazet To: Felix Fietkau Content-Type: multipart/alternative; boundary=f46d04478757890abe04d336eb12 X-Gm-Message-State: ALoCoQnoIJ1axBEpNwN+wZ887W5DBp9N+KS3VUplK1hs/hgZMeZCjueNdLdC/CXtH5LooEPU6fIDM+uTCnwQCbhqY6d5QtNON3v73aqG3EG/Apzu07pa1tI2ZhvSAo3B8oveqIkd55vClB6quH+QbZsbKT2w/kVlRAn92e6L4Y53RF5pO1Uu3RahpZ3d4aDfVp6dUGrJDHXyaVutuZLCFRrOzTjdicM/pQ== Cc: Jerry Chu , cerowrt-devel , Yuchung Cheng Subject: Re: [Cerowrt-devel] TFO crashes cerowrt 3.7.1-1 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 03:05:41 -0000 --f46d04478757890abe04d336eb12 Content-Type: text/plain; charset=ISO-8859-1 Oh well yes, this doesnt quite work on !SMP. And this kind of bug is frequent.... See following example : commit b9980cdcf2524c5fe15d8cbae9c97b3ed6385563 Author: Hugh Dickins Date: Wed Feb 8 17:13:40 2012 -0800 mm: fix UP THP spin_is_locked BUGs Fix CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_SMP=n CONFIG_DEBUG_VM=y CONFIG_DEBUG_SPINLOCK=n kernel: spin_is_locked() is then always false, and so triggers some BUGs in Transparent HugePage codepaths. asm-generic/bug.h mentions this problem, and provides a WARN_ON_SMP(x); but being too lazy to add VM_BUG_ON_SMP, BUG_ON_SMP, WARN_ON_SMP_ONCE, VM_WARN_ON_SMP_ONCE, just test NR_CPUS != 1 in the existing VM_BUG_ONs. Signed-off-by: Hugh Dickins Cc: Andrea Arcangeli Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds diff --git a/mm/huge_memory.c b/mm/huge_memory.c index b3ffc21..91d3efb 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2083,7 +2083,7 @@ static void collect_mm_slot(struct mm_slot *mm_slot) { struct mm_struct *mm = mm_slot->mm; - VM_BUG_ON(!spin_is_locked(&khugepaged_mm_lock)); + VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(&khugepaged_mm_lock)); On Sun, Jan 13, 2013 at 1:39 PM, Felix Fietkau wrote: > On 2013-01-13 7:03 PM, Eric Dumazet wrote: > > I suspect a bug in the spin_is_locked() implementation on your arch, as > > he socket lock should be held at this point. > I don't think this is an arch implementation bug, this probably happens > on all !SMP systems. See this bit from include/linux/spinlock_up.h: > > #define arch_spin_is_locked(lock) ((void)(lock), 0) > > - Felix > > --f46d04478757890abe04d336eb12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Oh well yes, this doesn= t quite work on !SMP.

And this kind of bug is frequent....
<= div class=3D"gmail_default" style>
See following example :
<= div class=3D"gmail_default" style>
commit b9980cdcf2524c5fe15d8cbae9c97b3ed63= 85563
Author: Hugh Dickins <hughd@google.com>
D= ate: =A0 Wed Feb 8 17:13:40 2012 -0800
=A0 =A0 mm: fix UP THP spin_is_locked BUGs
=A0 =A0=A0
=A0 =A0 Fix CONFIG_TRANSPARENT_HUGEPAGE=3Dy CONFIG_SMP=3Dn CONFIG_DEBUG_VM= =3Dy
=A0 =A0 CONFIG_DEBUG_SPINLOCK=3Dn kernel: spin_is_locked() is then always f= alse,
=A0 =A0 and so triggers some BUGs i= n Transparent HugePage codepaths.
=A0 =A0= =A0
=A0 =A0 asm-generic/bug.h mentions this problem, and provides a WARN_ON_SMP= (x);
=A0 =A0 but being too lazy to add VM= _BUG_ON_SMP, BUG_ON_SMP, WARN_ON_SMP_ONCE,
=A0 =A0 VM_WARN_ON_SMP_ONCE, just test NR_CPUS !=3D 1 in the existing VM_= BUG_ONs.
=A0 =A0=A0
= =A0 =A0 Signed-off-by: Hugh Dickins <hughd@google.com>
=A0 =A0 Cc: And= rea Arcangeli <aarcange@redhat.co= m>
=A0 =A0 Cc: <stable@vger.kernel.org>
=A0 =A0 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
=A0 =A0 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org<= /a>>

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index b3ffc21..91d3efb 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2083,7 +2083,= 7 @@ static void collect_mm_slot(struct mm_slot *mm_slot)
=A0{
=A0 =A0= =A0 =A0 struct mm_struct *mm =3D mm_slot->mm;
=A0
- =A0 =A0 =A0 VM_BUG_ON(!spi= n_is_locked(&khugepaged_mm_lock));
+ =A0 =A0 =A0 VM_BUG_ON(NR_CPUS !=3D 1 &&a= mp; !spin_is_locked(&khugepaged_mm_lock));




On Sun, Jan 13, 2013 at 1:39 PM, Felix Fietkau <nbd@openwrt.org> wrote:
On 2013-01-13 7:03 PM, Eric Dumazet wrote:
> I suspect a bug in the spin_is_locked() implementation on your arch, a= s
> he socket lock should be held at this point.
I don't think this is an arch implementation bug, this probably h= appens
on all !SMP systems. See this bit from include/linux/spinlock_up.h:

#define arch_spin_is_locked(lock) =A0 ((void)(lock), 0)

- Felix


--f46d04478757890abe04d336eb12--