On Tue, Oct 14, 2014 at 03:07:42PM +0400, Yury Gribov wrote:
> 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?
Yeah, such library changes are definitely not acceptable for 4.9 branch.
So, can you throw away all the patches which depend on the new libsanitizer
entry points? If you need those for KAsan which doesn't need the library
(right?), then tweak the patches so that the new functions are used in
-fsanitize=kernel-address mode only, and never in 4.9 for -fsanitize=address
-?
> 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?
Usually, if you backport patches (not the same committer or committed
on later date to branch from the commit date to trunk), one writes
2014-xx-yy You <y...@where.com>
Backported from mainline
2014-zz-nn Somebody <someb...@somewhe.re>
...
See branch ChangeLog for examples.
Jakub
