From: Jakub Jelinek <jakub@redhat.com>
To: Yury Gribov <y.gribov@samsung.com>
Cc: Andrey Ryabinin <a.ryabinin@samsung.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Konstantin Serebryany <konstantin.s.serebryany@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Subject: Re: [PATCHv4] Enable -fsanitize-recover for KASan
Date: Thu, 23 Oct 2014 10:39:00 -0000 [thread overview]
Message-ID: <20141023103802.GG10376@tucnak.redhat.com> (raw)
In-Reply-To: <5448D986.5020300@samsung.com>
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
next prev parent reply other threads:[~2014-10-23 10:38 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-05 6:54 [PATCH] " Yury Gribov
2014-09-05 7:32 ` Dmitry Vyukov
2014-09-05 8:12 ` Yury Gribov
2014-09-05 8:23 ` Dmitry Vyukov
2014-09-05 8:33 ` Yury Gribov
2014-09-05 9:28 ` Jakub Jelinek
2014-09-05 9:32 ` Yury Gribov
2014-09-05 9:05 ` Andrey Ryabinin
2014-09-05 9:12 ` Yury Gribov
2014-09-15 9:38 ` [PATCH][PING] " Yury Gribov
2014-09-18 10:53 ` Jakub Jelinek
2014-09-18 13:14 ` Yury Gribov
2014-09-18 23:47 ` Joseph S. Myers
2014-09-29 17:21 ` [PATCHv3][PING] " Yury Gribov
2014-09-29 17:44 ` Jakub Jelinek
2014-09-29 21:20 ` Konstantin Serebryany
2014-09-29 22:37 ` Alexey Samsonov
[not found] ` <CAGSYnCPwbgZ++2Jt2vE6-ytveSJwSQPZT5umLeKPVWsVjWzwPQ@mail.gmail.com>
2014-09-29 23:17 ` Jakub Jelinek
2014-09-29 23:26 ` Alexey Samsonov
2014-09-30 0:24 ` Konstantin Serebryany
2014-09-30 1:05 ` Alexey Samsonov
2014-09-30 1:49 ` Konstantin Serebryany
2014-09-30 5:40 ` Jakub Jelinek
2014-09-30 7:07 ` Yury Gribov
2014-09-30 17:26 ` Alexey Samsonov
2014-09-30 17:33 ` Jakub Jelinek
2014-09-30 17:36 ` Alexey Samsonov
2014-09-30 17:39 ` Jakub Jelinek
2014-10-01 23:21 ` Alexey Samsonov
2014-10-02 5:58 ` Jakub Jelinek
2014-10-03 18:54 ` Alexey Samsonov
[not found] ` <543BADAB.4090000@samsung.com>
2014-10-17 16:16 ` [PATCH] -fsanitize-recover=list Jakub Jelinek
2014-10-20 10:44 ` Yury Gribov
2014-10-22 8:05 ` Yury Gribov
2014-10-22 10:02 ` Jakub Jelinek
2014-11-18 2:50 ` Alexey Samsonov
2014-11-18 7:27 ` Jakub Jelinek
2014-11-18 8:29 ` Alexey Samsonov
2014-11-18 8:34 ` Jakub Jelinek
2014-11-18 20:25 ` Alexey Samsonov
2014-12-19 2:47 ` Alexey Samsonov
2014-12-19 8:14 ` Jakub Jelinek
[not found] ` <CAGSYnCNLoU0p3FGDwb6mMAAOWFz2Te1m7wmWD94PhcADsQs9rQ@mail.gmail.com>
2015-01-05 17:40 ` [PATCH] -f{no-sanitize,{,no-}sanitize-recover}=all support Jakub Jelinek
2015-01-05 20:32 ` Jeff Law
2015-01-05 21:40 ` Jakub Jelinek
2015-01-05 22:02 ` Jakub Jelinek
2015-01-06 9:00 ` Dodji Seketeli
2014-11-18 7:39 ` [PATCH] -fsanitize-recover=list Yury Gribov
2014-09-30 6:57 ` [PATCHv3][PING] Enable -fsanitize-recover for KASan Yury Gribov
2014-09-30 7:14 ` Yury Gribov
2014-10-23 7:15 ` [PATCHv4] " Yury Gribov
2014-10-23 7:20 ` Jakub Jelinek
2014-10-23 7:30 ` Yury Gribov
2014-10-23 9:55 ` Andrey Ryabinin
2014-10-23 10:00 ` Jakub Jelinek
2014-10-23 10:07 ` Jakub Jelinek
2014-10-23 10:24 ` Andrey Ryabinin
2014-10-23 10:27 ` Yury Gribov
2014-10-23 10:11 ` Andrey Ryabinin
2014-10-23 10:17 ` Jakub Jelinek
2014-10-23 10:38 ` Yury Gribov
2014-10-23 10:39 ` Jakub Jelinek [this message]
2014-10-23 11:12 ` Andrey Ryabinin
2014-10-24 8:37 ` Yury Gribov
2014-10-24 9:46 ` Dmitry Vyukov
2014-10-24 9:52 ` Jakub Jelinek
2014-10-24 9:56 ` Dmitry Vyukov
2014-10-24 9:59 ` Jakub Jelinek
2014-10-24 10:01 ` Yury Gribov
2014-10-24 10:21 ` Dmitry Vyukov
2014-10-28 8:46 ` [PATCH v5] " Yury Gribov
2014-10-28 9:31 ` Jakub Jelinek
2014-10-28 10:15 ` Yury Gribov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141023103802.GG10376@tucnak.redhat.com \
--to=jakub@redhat.com \
--cc=a.ryabinin@samsung.com \
--cc=dvyukov@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=k.khlebnikov@samsung.com \
--cc=konstantin.s.serebryany@gmail.com \
--cc=y.gribov@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).