From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23769 invoked by alias); 23 Oct 2014 11:10:35 -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 23750 invoked by uid 89); 23 Oct 2014 11:10:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mailout1.w1.samsung.com Received: from mailout1.w1.samsung.com (HELO mailout1.w1.samsung.com) (210.118.77.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (DES-CBC3-SHA encrypted) ESMTPS; Thu, 23 Oct 2014 11:10:32 +0000 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NDW008PT9UBQE70@mailout1.w1.samsung.com> for gcc-patches@gcc.gnu.org; Thu, 23 Oct 2014 12:13:23 +0100 (BST) Received: from eusync4.samsung.com ( [203.254.199.214]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 65.54.24279.422E8445; Thu, 23 Oct 2014 12:10:28 +0100 (BST) Received: from a.ryabinin ([106.109.129.143]) by eusync4.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0NDW0053G9PGGQ00@eusync4.samsung.com>; Thu, 23 Oct 2014 12:10:28 +0100 (BST) Message-id: <5448E223.3020804@samsung.com> Date: Thu, 23 Oct 2014 11:12:00 -0000 From: Andrey Ryabinin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-version: 1.0 To: Jakub Jelinek , Yury Gribov Cc: GCC Patches , Konstantin Serebryany , Dmitry Vyukov , Konstantin Khlebnikov Subject: Re: [PATCHv4] Enable -fsanitize-recover for KASan 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> <20141023103802.GG10376@tucnak.redhat.com> In-reply-to: <20141023103802.GG10376@tucnak.redhat.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-SW-Source: 2014-10/txt/msg02379.txt.bz2 On 10/23/2014 02:38 PM, Jakub Jelinek wrote: > 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. > True, but why we need new functions for that. __asan_load could also abort or not depending on what user/developer wants. Why we have to rebuild the entire kernel if someone wants to switch from abort to noabort? I'm not against __asan_load_noabort, I'm just saying that this is no point to have separate __asan_load/__asan_load_noabort functions in kernel.