From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30194 invoked by alias); 23 Oct 2014 10:38:14 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 30184 invoked by uid 89); 23 Oct 2014 10:38:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 23 Oct 2014 10:38:10 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NAc8lf000766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 23 Oct 2014 06:38:09 -0400 Received: from tucnak.zalov.cz (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NAc6Pc001192 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Oct 2014 06:38:08 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id s9NAc4hV017819; Thu, 23 Oct 2014 12:38:04 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id s9NAc24c017818; Thu, 23 Oct 2014 12:38:02 +0200 Date: Thu, 23 Oct 2014 10:39:00 -0000 From: Jakub Jelinek To: Yury Gribov Cc: Andrey Ryabinin , GCC Patches , Konstantin Serebryany , Dmitry Vyukov , Konstantin Khlebnikov Subject: Re: [PATCHv4] Enable -fsanitize-recover for KASan Message-ID: <20141023103802.GG10376@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <5416B3A2.4050200@samsung.com> <54299507.7090800@samsung.com> <5448AA21.9080601@samsung.com> <20141023071353.GY10376@tucnak.redhat.com> <5448AE0D.2080207@samsung.com> <5448CF90.2040001@samsung.com> <20141023095532.GD10376@tucnak.redhat.com> <5448D3EB.9030402@samsung.com> <20141023101649.GF10376@tucnak.redhat.com> <5448D986.5020300@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5448D986.5020300@samsung.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg02371.txt.bz2 On Thu, Oct 23, 2014 at 02:33:42PM +0400, Yury Gribov wrote: > Actually this is a historical artifact. If inlining proves to be > significantly faster, they may want to switch. Ok. > >So, at that point you can include your ugly hacks in __asan_load* logic in > >the kernel, the difference between __asan_load4 and __asan_load4_noabort > >will be just that the latter will always return, while the former will not > >if some error has been reported. > >All the __asan_load* and __asan_store* entrypoints, regardless of > >-f{,no-}sanitize-recover=kernel-address are by definition not noreturn, they > >in the common case (if the code is not buggy) return. > > Perhaps we should just keep __asan_load* as is and leave the decision > whether to abort or continue for the runtime? This would make semantics of > -fsanitize-recover cumbersome though (because it wouldn't work if user > selects outline instrumentation). Well, the "don't ever report anything while some per-CPU flag is set" thing can be considered as part of the "is this memory access ok" test, it is pretending everything is accessible. But, otherwise, if it is supposed to be developer's decision at compile time, __asan_load*_noabort should better always continue, even if it reported issues, and __asan_load* should better not return after reporting errors. Jakub