Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932870AbaJGX2p (ORCPT ); Tue, 7 Oct 2014 19:28:45 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:39740 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932269AbaJGXUH (ORCPT ); Tue, 7 Oct 2014 19:20:07 -0400 From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Srivatsa S. Bhat" , Davidlohr Bueso , Andrew Morton , Linus Torvalds , Mel Gorman Subject: [PATCH 3.14 37/37] mm: dont pointlessly use BUG_ON() for sanity check Date: Tue, 7 Oct 2014 16:19:54 -0700 Message-Id: <20141007231828.192941716@linuxfoundation.org> X-Mailer: git-send-email 2.1.2 In-Reply-To: <20141007231827.043235686@linuxfoundation.org> References: <20141007231827.043235686@linuxfoundation.org> User-Agent: quilt/0.63-1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Linus Torvalds commit 50f5aa8a9b248fa4262cf379863ec9a531b49737 upstream. BUG_ON() is a big hammer, and should be used _only_ if there is some major corruption that you cannot possibly recover from, making it imperative that the current process (and possibly the whole machine) be terminated with extreme prejudice. The trivial sanity check in the vmacache code is *not* such a fatal error. Recovering from it is absolutely trivial, and using BUG_ON() just makes it harder to debug for no actual advantage. To make matters worse, the placement of the BUG_ON() (only if the range check matched) actually makes it harder to hit the sanity check to begin with, so _if_ there is a bug (and we just got a report from Srivatsa Bhat that this can indeed trigger), it is harder to debug not just because the machine is possibly dead, but because we don't have better coverage. BUG_ON() must *die*. Maybe we should add a checkpatch warning for it, because it is simply just about the worst thing you can ever do if you hit some "this cannot happen" situation. Reported-by: Srivatsa S. Bhat Cc: Davidlohr Bueso Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman --- mm/vmacache.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/mm/vmacache.c +++ b/mm/vmacache.c @@ -81,10 +81,12 @@ struct vm_area_struct *vmacache_find(str for (i = 0; i < VMACACHE_SIZE; i++) { struct vm_area_struct *vma = current->vmacache[i]; - if (vma && vma->vm_start <= addr && vma->vm_end > addr) { - BUG_ON(vma->vm_mm != mm); + if (!vma) + continue; + if (WARN_ON_ONCE(vma->vm_mm != mm)) + break; + if (vma->vm_start <= addr && vma->vm_end > addr) return vma; - } } return NULL; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/