Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753497AbbH3MyB (ORCPT ); Sun, 30 Aug 2015 08:54:01 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:51855 "EHLO e23smtp01.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753358AbbH3MyA (ORCPT ); Sun, 30 Aug 2015 08:54:00 -0400 X-Helo: d23dlp01.au.ibm.com X-MailFrom: aneesh.kumar@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org From: "Aneesh Kumar K.V" To: Andrey Ryabinin Cc: Benjamin Herrenschmidt , paulus@samba.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, LKML Subject: Re: [PATCH V2 09/10] kasan: Prevent deadlock in kasan reporting In-Reply-To: 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> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sun, 30 Aug 2015 18:23:02 +0530 Message-ID: <8737z1q6oh.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15083012-1618-0000-0000-000002B10B04 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1159 Lines: 28 Andrey Ryabinin writes: > 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. > I still haven't fully isolated all the .c files which should not be kasan instrumented. That means in case of ppc64 i ended up calling kasan _load/_store in real mode. That will result in failure w.r.t to the above spin_lock code. -aneesh -- 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/