linux-kernel - Re: [BUG] kernel BUG at mm/vmacache.c:85!

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]

Message-ID: <CA+55aFxgW0fS=6xJsKP-WiOUw=aiCEvydj+pc+zDF8Pvn4v+Jw@mail.gmail.com>
Date:	Mon, 28 Apr 2014 14:20:49 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc:	Linux MM <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Davidlohr Bueso <davidlohr@...com>,
	Rik van Riel <riel@...hat.com>,
	Michel Lespinasse <walken@...gle.com>,
	Hugh Dickins <hughd@...gle.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [BUG] kernel BUG at mm/vmacache.c:85!

On Mon, Apr 28, 2014 at 12:18 PM, Srivatsa S. Bhat
<srivatsa.bhat@...ux.vnet.ibm.com> wrote:
>
> I hit this during boot on v3.15-rc3, just once so far.
> Subsequent reboots went fine, and a few quick runs of multi-
> threaded ebizzy also didn't recreate the problem.
>
> The kernel I was running was v3.15-rc3 + some totally
> unrelated cpufreq patches.
>
> The BUG_ON triggered from the following code:
>
>  74 struct vm_area_struct *vmacache_find(struct mm_struct *mm, unsigned long addr)
>  84                 if (vma && vma->vm_start <= addr && vma->vm_end > addr) {
>  85                         BUG_ON(vma->vm_mm != mm);
>  86                         return vma;
>  87                 }

Hmm. Andrew, Davidlohr, I thought we agreed that he non-current mm
case can actually happen, and that the BUG_ON() was wrong and we
should compare the mm pointer. But the patch that got merged obviously
has the BUG_ON(), so my memory must be wrong.

Regardless, I absolutely *detest* random BUG_ON() calls that turn a
debuggability problem totally unnecessarily into a hard failure, so
that BUG_ON() really needs to go away. I *know* I suggested using
WARN_ON_ONCE() when the discussion was about whether the condition
could happen or not, and the fact that it got turned into a BUG_ON()
is a damn shame.

Andrew, I think I blame you for that particular BUG_ON() addition,
because I don't see it in the original patch. There is *no* excuse for
a BUG_ON(), when a

   if (WARN_ON_ONCE(vma->vm_mm != mm))
      return NULL;

would have worked equally well without killing the box and making
things harder to debug.

This BUG_ON() insanity needs to stop. The thing is a f*cking menace,
and it's not the first time we hit a BUG_ON() that damn well shouldn't
have been a BUG_ON() to begin with.

That said, the bug does seem to be that some path doesn't invalidate
the vmacache sufficiently, or something inserts a vmacache entry into
the current process when looking up a remote process or whatever.
Davidlohr, ideas?

              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/