[lkml]   [2017]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
On Thu, Sep 28, 2017 at 6:09 AM, Andrey Ryabinin
<> wrote:
> On 09/27/2017 04:26 PM, Arnd Bergmann wrote:
>> On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin
>> <> wrote:

>> --- a/include/linux/string.h
>> +++ b/include/linux/string.h
>> @@ -227,7 +227,7 @@ static inline const char *kbasename(const char *path)
>> #define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
>> #define __RENAME(x) __asm__(#x)
>> -void fortify_panic(const char *name) __noreturn __cold;
>> +void fortify_panic(const char *name) __cold;
>> void __read_overflow(void) __compiletime_error("detected read beyond
>> size of object passed as 1st parameter");
>> void __read_overflow2(void) __compiletime_error("detected read beyond
>> size of object passed as 2nd parameter");
>> void __read_overflow3(void) __compiletime_error("detected read beyond
>> size of object passed as 3rd parameter");
>> I don't immediately see why the __noreturn changes the behavior here, any idea?
> At first I thought that this somehow might be related to __asan_handle_no_return(). GCC calls it
> before noreturn function. So I made patch to remove generation of these calls (we don't need them in the kernel anyway)
> but it didn't help. It must be something else than.

I made a reduced test case yesterday (see,
and it shows the same behavior with and without the sanitizer, it uses 128
bytes without the noreturn attribute and 480 bytes when its added, the sanitizer
adds a factor of 1.5x on top. It's possible that I did something wrong while
reducing, since the original driver file uses very little stack (a few hundred
bytes) without -fsanitize=kernel-address, but finding out what happens in
the reduced case may still help understand the other one.


 \ /
  Last update: 2017-09-28 16:32    [W:0.177 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site