This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Backporting KAsan patches to 4.9 branch
- From: Dmitry Vyukov <dvyukov at google dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, gcc <gcc at gcc dot gnu dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Konstantin Khlebnikov <k dot khlebnikov at samsung dot com>, Andrey Ryabinin <a dot ryabinin at samsung dot com>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>
- Date: Tue, 14 Oct 2014 15:19:10 +0400
- Subject: Re: Backporting KAsan patches to 4.9 branch
- Authentication-results: sourceware.org; auth=none
- References: <541AA9ED dot 6040705 at samsung dot com> <20140918095754 dot GC17454 at tucnak dot redhat dot com> <543D03FE dot 1020204 at samsung dot com>
On Tue, Oct 14, 2014 at 3:07 PM, Yury Gribov <y.gribov@samsung.com> wrote:
> On 09/18/2014 01:57 PM, Jakub Jelinek wrote:
>> On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
>>> Kernel Asan patches are currently being discussed in LKML. One of the
>>> points>> raised during review was that KAsan requires GCC 5.0 which is
>>> presumably
>>> unstable (e.g. compilation of kernel modules has been broken for two
>>> months
>>> due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848).
>>>
>>> Would it make sense to backport Kasan-related patches to 4.9 branch to
>>> make
>>> this feature more accessible to kernel developers? Quick analysis showed
>>> that at the very least this would require
>>> ...
>>> Is it ok to backport these to 4.9? Note that I would discard patches for
>>> other sanitizers (UBsan, Tsan).
>>
>> I'd say so, if it doesn't need any library changes
>> (especially not any ABI
>> visible ones, guess bugfixes could be acceptable).
>
> Finally got time to look into this. I've successfully backported 22 patches
> to 4.9:
> * bugfixes (12 patches)
> * install Asan headers (1 patch)
> * libsanitizer merge (1 patch) - this is questionable, see below for
> discussion
> * BUILT_IN_ASAN_REPORT_{LOAD,STORE}_N (2 patches)
> * instrumentation with calls (1 patch)
> * optimize strlen instrumentation (1 patch)
> * move inlining to sanopt pass (2 patches)
> * Kasan (2 patches)
>
> One problem is that for BUILT_IN_ASAN_REPORT_{LOAD,STORE}_N patch I need
> libsanitizer APIs (__asan_loadN, __asan_storeN) which were introduced in a
> giant libsanitizer merge in 5.0. In current patchset I backport the whole
> merge patch (and a bunch of cherry-picks which followed it) but it changes
> libsanitizer ABI (new version of __asan_init_vXXX, etc.) which is probably
> undesirable. Another option would be to backport just the necessary minimum
> (__asan_loadN, __asan_storeN). How should I proceed?
Backporting only __asan_loadN/__asan_storeN looks like the safest option to me.
> Another question: Should I update patch CL dates for backported patches? If
> not - should I insert them to CLs in chronological order or just stack on
> top of previous contents?
>
> -Y