lkml.org 
[lkml]   [2014]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v7 11/12] lib: add kasan test module
On 11/25/2014 02:14 PM, Dmitry Chernenkov wrote:
> I have a bit of concern about tests.
> A) they are not fully automated, there is no checking whether they
> pass or not. This is implemented in our repository using special tags
> in the log (https://github.com/google/kasan/commit/33b267553e7ffe66d5207152a3294112361b75fe;
> don't mmind the TODOs, they weren't broken to begin with), and a
> parser script (https://code.google.com/p/address-sanitizer/source/browse/trunk/tools/kernel_test_parse.py)
> to feed the kernel log to.
>
> B) They are not thorough enough - they don't check false negatives,

False negative means kasan's report on valid access, right? Most of the memory accesses
in kernel are valid, so just booting kernel should give you the best check for false
negatives you can ever write.

Though I agree that it's not very thorough. Currently this more demonstrational module,
and there are a lot of cases not covered by it.

> accesses more than 1 byte away etc.
>
> C) (more of general concern for current Kasan realiability) - when
> running multiple times, some tests are flaky, specificially oob_right
> and uaf2. The latter needs quarantine to work reliably (I know
> Konstantin is working on it). oob_right needs redzones in the
> beginning of the slabs.
>
> I know all of these may seem like long shots, but if we want a
> reliable solution (also a backportable solution), we need to at least
> consider them.
>
> Otherwise, LGTM
>




\
 
 \ /
  Last update: 2014-11-25 14:41    [W:0.206 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site