Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753200AbbH0MIR (ORCPT ); Thu, 27 Aug 2015 08:08:17 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:36231 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751694AbbH0MIQ (ORCPT ); Thu, 27 Aug 2015 08:08:16 -0400 MIME-Version: 1.0 In-Reply-To: <1440577578-15813-10-git-send-email-aneesh.kumar@linux.vnet.ibm.com> References: <1440577578-15813-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1440577578-15813-10-git-send-email-aneesh.kumar@linux.vnet.ibm.com> Date: Thu, 27 Aug 2015 15:08:14 +0300 Message-ID: Subject: Re: [PATCH V2 09/10] kasan: Prevent deadlock in kasan reporting From: Andrey Ryabinin To: "Aneesh Kumar K.V" Cc: Benjamin Herrenschmidt , paulus@samba.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2723 Lines: 72 2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V : > We we end up calling kasan_report in real mode, our shadow mapping > for even spinlock variable will show poisoned. Generally I agree with this patch. We should disable reports when we print report as early as possible to prevent recursion in case of bug in spinlock or printk etc. But I don't understand what is the problem that you observing. How we ended up with shadow poisoned for a valid spinlock struct? And since shadow poisoned for some valid memory we should get enormous amount of false positive reports. > This will result > in us calling kasan_report_error with lock_report spin lock held. > To prevent this disable kasan reporting when we are priting > error w.r.t kasan. > > Signed-off-by: Aneesh Kumar K.V > --- > mm/kasan/report.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c > index 79fbc5d14bd2..82b41eb83e43 100644 > --- a/mm/kasan/report.c > +++ b/mm/kasan/report.c > @@ -185,6 +185,10 @@ void kasan_report_error(struct kasan_access_info *info) > { > unsigned long flags; > > + /* > + * Make sure we don't end up in loop. > + */ > + kasan_disable_current(); > spin_lock_irqsave(&report_lock, flags); > pr_err("=================================" > "=================================\n"); > @@ -194,12 +198,17 @@ void kasan_report_error(struct kasan_access_info *info) > pr_err("=================================" > "=================================\n"); > spin_unlock_irqrestore(&report_lock, flags); > + kasan_enable_current(); > } > > void kasan_report_user_access(struct kasan_access_info *info) > { > unsigned long flags; > > + /* > + * Make sure we don't end up in loop. > + */ > + kasan_disable_current(); > spin_lock_irqsave(&report_lock, flags); > pr_err("=================================" > "=================================\n"); > @@ -212,6 +221,7 @@ void kasan_report_user_access(struct kasan_access_info *info) > pr_err("=================================" > "=================================\n"); > spin_unlock_irqrestore(&report_lock, flags); > + kasan_enable_current(); > } > > void kasan_report(unsigned long addr, size_t size, > -- > 2.5.0 > -- 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/