On Fri, Oct 24, 2014 at 1:59 PM, Yury Gribov wrote:
> On 10/24/2014 01:44 PM, Dmitry Vyukov wrote:
>>
>> On Fri, Oct 24, 2014 at 12:28 PM, Yury Gribov
>> wrote:
>>>
>>> On 10/23/2014 03:10 PM, Andrey Ryabinin wrote:
On 10/23/2014 02:38 PM, Jakub Jelinek wrote:
>
>
> On
On 10/24/2014 01:44 PM, Dmitry Vyukov wrote:
On Fri, Oct 24, 2014 at 12:28 PM, Yury Gribov wrote:
On 10/23/2014 03:10 PM, Andrey Ryabinin wrote:
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
On Fri, Oct 24, 2014 at 11:50:58AM +0200, Jakub Jelinek wrote:
> On Fri, Oct 24, 2014 at 01:44:27PM +0400, Dmitry Vyukov wrote:
> > I am somewhat lost in this thread and probably missing something.
> > But why do we need __asan_load (which is not noabort) at all? Outline
> > instrumentation is non
On Fri, Oct 24, 2014 at 1:50 PM, Jakub Jelinek wrote:
> On Fri, Oct 24, 2014 at 01:44:27PM +0400, Dmitry Vyukov wrote:
>> I am somewhat lost in this thread and probably missing something.
>> But why do we need __asan_load (which is not noabort) at all? Outline
>> instrumentation is non a default m
On Fri, Oct 24, 2014 at 01:44:27PM +0400, Dmitry Vyukov wrote:
> I am somewhat lost in this thread and probably missing something.
> But why do we need __asan_load (which is not noabort) at all? Outline
> instrumentation is non a default mode for both user-space asan and
> kasan (at least in the en
On Fri, Oct 24, 2014 at 12:28 PM, Yury Gribov wrote:
> On 10/23/2014 03:10 PM, Andrey Ryabinin wrote:
>>
>> 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
On 10/23/2014 03:10 PM, Andrey Ryabinin wrote:
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
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 __a
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
On 10/23/2014 02:16 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 02:09:47PM +0400, Andrey Ryabinin wrote:
On 10/23/2014 01:55 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
IMO we don't need different versions of __asan_load* and __asan_load*_noab
On 10/23/2014 02:20 PM, Andrey Ryabinin wrote:
On 10/23/2014 02:00 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 11:55:32AM +0200, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
IMO we don't need different versions of __asan_load* and __asan_load*_noab
On 10/23/2014 02:00 PM, Jakub Jelinek wrote:
> On Thu, Oct 23, 2014 at 11:55:32AM +0200, Jakub Jelinek wrote:
>> On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
>>> IMO we don't need different versions of __asan_load* and
>>> __asan_load*_noabort, because
>>> -fno-sanitize-recover
On Thu, Oct 23, 2014 at 02:09:47PM +0400, Andrey Ryabinin wrote:
> On 10/23/2014 01:55 PM, Jakub Jelinek wrote:
> > On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
> >> IMO we don't need different versions of __asan_load* and
> >> __asan_load*_noabort, because
> >> -fno-sanitize-r
On 10/23/2014 01:55 PM, Jakub Jelinek wrote:
> On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
>> IMO we don't need different versions of __asan_load* and
>> __asan_load*_noabort, because
>> -fno-sanitize-recover=kernel-address will never work with the linux kernel.
>>
>> I alread
On Thu, Oct 23, 2014 at 11:55:32AM +0200, Jakub Jelinek wrote:
> On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
> > IMO we don't need different versions of __asan_load* and
> > __asan_load*_noabort, because
> > -fno-sanitize-recover=kernel-address will never work with the linux k
On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
> IMO we don't need different versions of __asan_load* and
> __asan_load*_noabort, because
> -fno-sanitize-recover=kernel-address will never work with the linux kernel.
>
> I already said this before, and repeat this once again:
> T
On 10/23/2014 11:28 AM, Yury Gribov wrote:
> On 10/23/2014 11:13 AM, Jakub Jelinek wrote:
>> On Thu, Oct 23, 2014 at 11:11:29AM +0400, Yury Gribov wrote:
>>> Hi all,
>>>
>>> On 09/29/2014 09:21 PM, Yury Gribov wrote:
>> This patch enables -fsanitize-recover for KASan by default. This causes
>>>
On 10/23/2014 11:13 AM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 11:11:29AM +0400, Yury Gribov wrote:
Hi all,
On 09/29/2014 09:21 PM, Yury Gribov wrote:
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrum
On Thu, Oct 23, 2014 at 11:11:29AM +0400, Yury Gribov wrote:
> Hi all,
>
> On 09/29/2014 09:21 PM, Yury Gribov wrote:
> >>>This patch enables -fsanitize-recover for KASan by default. This causes
> >>>KASan to continue execution after error in case of inline
> >>>instrumentation. This feature is ne
Hi all,
On 09/29/2014 09:21 PM, Yury Gribov wrote:
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrumentation. This feature is needed because
- reports during early bootstrap won't even be printed
- needed to
20 matches
Mail list logo
