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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 28, 2014 at 12:18 PM, Srivatsa S. Bhat
<srivatsa.bhat@xxxxxxxxxxxxxxxxxx> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]