On 11/21/2014 02:14 AM, Thomas Gleixner wrote:
> On Thu, 20 Nov 2014, Andrew Morton wrote:
>
>> On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov wrote:
>>
>>> Let me provide some background first.
>>
>> Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
>> changelog?
>
> And
On 11/21/2014 10:32 AM, Dmitry Vyukov wrote:
> On Fri, Nov 21, 2014 at 2:00 AM, Andrew Morton
> wrote:
>> On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov wrote:
>>
>>> Let me provide some background first.
>>
>> Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
>>
On 11/21/2014 02:00 AM, Andrew Morton wrote:
> On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov wrote:
>
>> Let me provide some background first.
>
> Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
> changelog?
>
Sure.
> Also, some quantitative info about the kmemleak
On 11/21/2014 02:00 AM, Andrew Morton wrote:
On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov dvyu...@google.com wrote:
Let me provide some background first.
Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
changelog?
Sure.
Also, some quantitative info about the
On 11/21/2014 10:32 AM, Dmitry Vyukov wrote:
On Fri, Nov 21, 2014 at 2:00 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov dvyu...@google.com wrote:
Let me provide some background first.
Well that was useful. Andrey, please slurp Dmitry's
On 11/21/2014 02:14 AM, Thomas Gleixner wrote:
On Thu, 20 Nov 2014, Andrew Morton wrote:
On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov dvyu...@google.com wrote:
Let me provide some background first.
Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
changelog?
On Fri, Nov 21, 2014 at 2:00 AM, Andrew Morton
wrote:
> On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov wrote:
>
>> Let me provide some background first.
>
> Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
> changelog?
>
> Also, some quantitative info about the kmemleak
On Thu, 20 Nov 2014, Andrew Morton wrote:
> On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov wrote:
>
> > Let me provide some background first.
>
> Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
> changelog?
And into Documentation/UBSan or whatever the favourite place
On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov wrote:
> Let me provide some background first.
Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
changelog?
Also, some quantitative info about the kmemleak overhead would be
useful.
In this discussion you've mentioned a few
On Thu, Nov 20, 2014 at 12:03 PM, Ingo Molnar wrote:
>
> * Andrey Ryabinin wrote:
>
>> I've counted 16:
>>
>> aab515d (fib_trie: remove potential out of bound access)
>> 984f173 ([SCSI] sd: Fix potential out-of-bounds access)
>> 5e9ae2e (aio: fix use-after-free in aio_migratepage)
>> 2811eba
On 11/20/2014 12:03 PM, Ingo Molnar wrote:
>
> * Andrey Ryabinin wrote:
>
>> I've counted 16:
>>
>> aab515d (fib_trie: remove potential out of bound access)
>> 984f173 ([SCSI] sd: Fix potential out-of-bounds access)
>> 5e9ae2e (aio: fix use-after-free in aio_migratepage)
>> 2811eba (ipv6: udp
* Andrey Ryabinin wrote:
> I've counted 16:
>
> aab515d (fib_trie: remove potential out of bound access)
> 984f173 ([SCSI] sd: Fix potential out-of-bounds access)
> 5e9ae2e (aio: fix use-after-free in aio_migratepage)
> 2811eba (ipv6: udp packets following an UFO enqueued packet need also
> be
* Andrey Ryabinin ryabinin@gmail.com wrote:
I've counted 16:
aab515d (fib_trie: remove potential out of bound access)
984f173 ([SCSI] sd: Fix potential out-of-bounds access)
5e9ae2e (aio: fix use-after-free in aio_migratepage)
2811eba (ipv6: udp packets following an UFO enqueued
On 11/20/2014 12:03 PM, Ingo Molnar wrote:
* Andrey Ryabinin ryabinin@gmail.com wrote:
I've counted 16:
aab515d (fib_trie: remove potential out of bound access)
984f173 ([SCSI] sd: Fix potential out-of-bounds access)
5e9ae2e (aio: fix use-after-free in aio_migratepage)
2811eba
On Thu, Nov 20, 2014 at 12:03 PM, Ingo Molnar mi...@kernel.org wrote:
* Andrey Ryabinin ryabinin@gmail.com wrote:
I've counted 16:
aab515d (fib_trie: remove potential out of bound access)
984f173 ([SCSI] sd: Fix potential out-of-bounds access)
5e9ae2e (aio: fix use-after-free in
On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov dvyu...@google.com wrote:
Let me provide some background first.
Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
changelog?
Also, some quantitative info about the kmemleak overhead would be
useful.
In this discussion
On Thu, 20 Nov 2014, Andrew Morton wrote:
On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov dvyu...@google.com wrote:
Let me provide some background first.
Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
changelog?
And into Documentation/UBSan or whatever the
On Fri, Nov 21, 2014 at 2:00 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov dvyu...@google.com wrote:
Let me provide some background first.
Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
changelog?
Also, some
On 11/19/2014 03:44 AM, Sasha Levin wrote:
> On 11/18/2014 07:09 PM, Andrey Ryabinin wrote:
>> Yes with CONFIG_KASAN_INLINE you will get GPF instead of kasan report.
>> For userspaces addresses we don't have shadow memory. In outline case
>> I just check address itself before checking shadow. In
On 11/19/2014 03:44 AM, Sasha Levin wrote:
On 11/18/2014 07:09 PM, Andrey Ryabinin wrote:
Yes with CONFIG_KASAN_INLINE you will get GPF instead of kasan report.
For userspaces addresses we don't have shadow memory. In outline case
I just check address itself before checking shadow. In inline
On 11/18/2014 07:09 PM, Andrey Ryabinin wrote:
> Yes with CONFIG_KASAN_INLINE you will get GPF instead of kasan report.
> For userspaces addresses we don't have shadow memory. In outline case
> I just check address itself before checking shadow. In inline case compiler
> just checks shadow, so
2014-11-19 2:38 GMT+03:00 Sasha Levin :
> Hi Andrey,
>
> After the recent exchange of mails about kasan it came to me that I haven't
> seen a kasan warning for a while now. To give kasan a quick test I added a
> rather
> simple error which should generate a kasan warning about accessing userspace
2014-11-18 23:58 GMT+03:00 Andrew Morton :
> On Tue, 11 Nov 2014 10:21:42 +0300 Andrey Ryabinin
> wrote:
>
>> Hi Andrew,
>>
>> Now we have stable GCC(4.9.2) which supports kasan and from my point of view
>> patchset is ready for merging.
>> I could have sent v7 (it's just rebased v6), but I see
Hi Andrey,
After the recent exchange of mails about kasan it came to me that I haven't
seen a kasan warning for a while now. To give kasan a quick test I added a
rather
simple error which should generate a kasan warning about accessing userspace
memory (yes, I know kasan has a test module but my
On 11/18/2014 01:15 PM, Andi Kleen wrote:
>> > If kasan will permit us to remove kmemcheck/debug_pagealloc/slub_debug
>> > then that tips the balance a little. What's the feasibility of that?
> Maybe removing kmemcheck. slub_debug/debug_pagealloc are simple, and are in
> different niches (lower
> It's a huge pile of tricky code we'll need to maintain. To justify its
> inclusion I think we need to be confident that kasan will find a
> significant number of significant bugs that
> kmemcheck/debug_pagealloc/slub_debug failed to detect.
I would put it differently. kmemcheck is effectively
On 11/18/2014 03:58 PM, Andrew Morton wrote:
> On Tue, 11 Nov 2014 10:21:42 +0300 Andrey Ryabinin
> wrote:
>
>> Hi Andrew,
>>
>> Now we have stable GCC(4.9.2) which supports kasan and from my point of view
>> patchset is ready for merging.
>> I could have sent v7 (it's just rebased v6), but I
On Tue, 11 Nov 2014 10:21:42 +0300 Andrey Ryabinin
wrote:
> Hi Andrew,
>
> Now we have stable GCC(4.9.2) which supports kasan and from my point of view
> patchset is ready for merging.
> I could have sent v7 (it's just rebased v6), but I see no point in doing that
> and bothering people,
>
On 11/11/2014 10:21 AM, Andrey Ryabinin wrote:
> Hi Andrew,
>
> Now we have stable GCC(4.9.2) which supports kasan and from my point of view
> patchset is ready for merging.
> I could have sent v7 (it's just rebased v6), but I see no point in doing that
> and bothering people,
> unless you are
On 11/11/2014 10:21 AM, Andrey Ryabinin wrote:
Hi Andrew,
Now we have stable GCC(4.9.2) which supports kasan and from my point of view
patchset is ready for merging.
I could have sent v7 (it's just rebased v6), but I see no point in doing that
and bothering people,
unless you are ready
On Tue, 11 Nov 2014 10:21:42 +0300 Andrey Ryabinin a.ryabi...@samsung.com
wrote:
Hi Andrew,
Now we have stable GCC(4.9.2) which supports kasan and from my point of view
patchset is ready for merging.
I could have sent v7 (it's just rebased v6), but I see no point in doing that
and
On 11/18/2014 03:58 PM, Andrew Morton wrote:
On Tue, 11 Nov 2014 10:21:42 +0300 Andrey Ryabinin a.ryabi...@samsung.com
wrote:
Hi Andrew,
Now we have stable GCC(4.9.2) which supports kasan and from my point of view
patchset is ready for merging.
I could have sent v7 (it's just rebased
It's a huge pile of tricky code we'll need to maintain. To justify its
inclusion I think we need to be confident that kasan will find a
significant number of significant bugs that
kmemcheck/debug_pagealloc/slub_debug failed to detect.
I would put it differently. kmemcheck is effectively too
On 11/18/2014 01:15 PM, Andi Kleen wrote:
If kasan will permit us to remove kmemcheck/debug_pagealloc/slub_debug
then that tips the balance a little. What's the feasibility of that?
Maybe removing kmemcheck. slub_debug/debug_pagealloc are simple, and are in
different niches (lower overhead
Hi Andrey,
After the recent exchange of mails about kasan it came to me that I haven't
seen a kasan warning for a while now. To give kasan a quick test I added a
rather
simple error which should generate a kasan warning about accessing userspace
memory (yes, I know kasan has a test module but my
2014-11-18 23:58 GMT+03:00 Andrew Morton a...@linux-foundation.org:
On Tue, 11 Nov 2014 10:21:42 +0300 Andrey Ryabinin a.ryabi...@samsung.com
wrote:
Hi Andrew,
Now we have stable GCC(4.9.2) which supports kasan and from my point of view
patchset is ready for merging.
I could have sent v7
2014-11-19 2:38 GMT+03:00 Sasha Levin sasha.le...@oracle.com:
Hi Andrey,
After the recent exchange of mails about kasan it came to me that I haven't
seen a kasan warning for a while now. To give kasan a quick test I added a
rather
simple error which should generate a kasan warning about
On 11/18/2014 07:09 PM, Andrey Ryabinin wrote:
Yes with CONFIG_KASAN_INLINE you will get GPF instead of kasan report.
For userspaces addresses we don't have shadow memory. In outline case
I just check address itself before checking shadow. In inline case compiler
just checks shadow, so there
Hi Andrew,
Now we have stable GCC(4.9.2) which supports kasan and from my point of view
patchset is ready for merging.
I could have sent v7 (it's just rebased v6), but I see no point in doing that
and bothering people,
unless you are ready to take it.
So how should I proceed?
Thanks,
Andrey.
Hi Andrew,
Now we have stable GCC(4.9.2) which supports kasan and from my point of view
patchset is ready for merging.
I could have sent v7 (it's just rebased v6), but I see no point in doing that
and bothering people,
unless you are ready to take it.
So how should I proceed?
Thanks,
Andrey.
KASan is a runtime memory debugger designed to find use-after-free
and out-of-bounds bugs.
Currently KASAN supported only for x86_64 architecture and requires kernel
to be build with SLUB allocator.
KASAN uses compile-time instrumentation for checking every memory access,
therefore you
will need
KASan is a runtime memory debugger designed to find use-after-free
and out-of-bounds bugs.
Currently KASAN supported only for x86_64 architecture and requires kernel
to be build with SLUB allocator.
KASAN uses compile-time instrumentation for checking every memory access,
therefore you
will need
42 matches
Mail list logo
