google / kernel-sanitizers Goto Github PK

Linux Kernel Sanitizers, fast bug-detectors for the Linux kernel

Home Page: https://google.github.io/kernel-sanitizers/

Python 100.00%

kernel-sanitizers's Introduction

Linux Kernel Sanitizers

Note: Most Sanitizers are maintained in the Linux kernel repository and are not hosted here.

This repository contains out-of-tree information and prototypes for KASAN, UBSAN, KCSAN, KFENCE, KMSAN, and KTSAN. Note, that KMSAN's code is hosted separately.

Questions about KASAN and other Sanitizers can be asked on the [email protected] mailing list. You can subscribe to it either with a Google account or by sending an email to [email protected].

Kernel bugs found with Sanitizers should be reported to kernel maintainers. Issues in Sanitizers themselves can be reported on the Sanitizers Bugzilla.

See the Symbolizer page for information about symplifying reading bug reports produced by Sanitizers.

kernel-sanitizers's People

Contributors

Stargazers

Watchers

Forkers

kcc dizzy57 rbalint steelannelida aryabinin math4youbyusgroupillinois uikit0 raaka1 tqangxl applewjg juen gongfupanada ramosian-glider abioy triggerstriggert nikkilish lzufalcon wdv4758h suezi shark2016 tempbottle jameslinus telnetgmike rahulpathakgit johnjohnsp1 rzs840707 evdevgit chubbymaggie flankersky bittorrent3389 arcapix kirill2013 runt18 lamproae charlieyqin sergvs sergey-pronin nickdesaulniers fengpeng2017 kent12342004 idkwim yan-1-20 servicefoundation daydayup40 stonezhangqq d-demirci l9sk bmork zhengxle jivthesh isabella232 johnarthur1 neotim zyh329 a-nogikh sonicman exx8 jzck-ty global-localhost global19 global19-atlassian-net tvyavaha cronos996 codesacka zhangbinghua kirito999 deng930602 guguyayak fdlucifer mengjianwei12345 python-repository-hub yifeili0612 rtoax mtkfleet crazyss duzzy-exoduus 5l1v3r1 sohu0106 zf1575192187 asuka39 ghas-results yinxx moyix kylerchang liunix61

kernel-sanitizers's Issues

false positives on irq stack

Interrupt stack irq_stack_ptr is shared between all interrupts on the same CPU. But these interrupts can happen on different threads. As the result KTSAN can produce false positives on IRQ stack. Namely interrupt 1 that executes on thread 1 writes to IRQ stack. Then interrupt 2 that executes on thread 2 writes to the same location of IRQ stack. If thread 2 and thread 1 are not synchronized, KTSAN will report a race. This is a pure mental experiment, but I don't see why it can't happen.

While I fork a process, ktsan.task is null, when does it init?

Does Ktsan support for ARM? If it supports, how to deal with it?

Stack OOB is not always properly reported

According to a user report, stack OOB is reported as just OOB (heap).
Yes, it is:

[  397.648198] kasan test: kasan_stack_oob out-of-bounds on stack
[  397.648612] ==================================================================
[  397.649006] BUG: KASan: out of bounds access in kasan_stack_oob+0xbf/0xe8 [test_kasan] at addr ffff88003eb2fa52
[  397.649006] Read of size 1 by task insmod/2675
[  397.649006] page:ffffea0000facbc0 count:0 mapcount:0 mapping:          (null) index:0x0
[  397.649006] flags: 0x100000000000000()
[  397.649006] page dumped because: kasan: bad access detected
[  397.649006] CPU: 1 PID: 2675 Comm: insmod Tainted: G    B           4.3.0-rc2+ #23
[  397.649006] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[  397.649006]  00000000ffffffff ffff88003eb2f930 ffffffff81a44e70 ffff88003eb2f9b0
[  397.649006]  ffff88003eb2fa52 dffffc0000000000 ffff88003eb2f9a0 ffffffff814639b3
[  397.649006]  ffffea0000f75480 0000000100000010 0000000000000246 ffff88003eb2f988
[  397.649006] Call Trace:
[  397.649006]  [<ffffffff81a44e70>] dump_stack+0x68/0x88
[  397.649006]  [<ffffffff814639b3>] kasan_report_error+0x393/0x3c0
[  397.649006]  [<ffffffffa0008be3>] ? kmem_cache_oob+0x120/0x120 [test_kasan]
[  397.649006]  [<ffffffff81463a1e>] __asan_report_load1_noabort+0x3e/0x40
[  397.649006]  [<ffffffffa00080bf>] ? kasan_stack_oob+0xbf/0xe8 [test_kasan]
[  397.649006]  [<ffffffffa00080bf>] kasan_stack_oob+0xbf/0xe8 [test_kasan]

I think the reason is that we hit shadow '02':

[  397.649006] Memory state around the buggy address:
[  397.649006]  ffff88003eb2f900: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  397.649006]  ffff88003eb2f980: 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1
[  397.649006] >ffff88003eb2fa00: f1 04 f4 f4 f4 f2 f2 f2 f2 00 02 f4 f4 f3 f3 f3
[  397.649006]                                                  ^
[  397.649006]  ffff88003eb2fa80: f3 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
[  397.649006]  ffff88003eb2fb00: 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00

Need to check the next shadow byte, or whatever user-space asan does.

Races on stack

Ensure that we can catch races on stack.

kasan_slab_free can corrupt shadow and object header

bool kasan_slab_free(struct kmem_cache *cache, void *object)
{
        switch (alloc_info->state) {
        case KASAN_STATE_ALLOC:
            alloc_info->state = KASAN_STATE_QUARANTINE;
            quarantine_put(free_info, cache);
            set_track(&free_info->track, GFP_NOWAIT);
            kasan_poison_slab_free(cache, object);
            return true;

We first put the object into quarantine and then poison shadow and update header. The object can be pushed out of the quarantine and reused before we update shadow/header. As the result shadow and header will be corrupted.
We need to update shadow/header before making the object available for reuse.

Detect races on global variables

subj

When does ktsan task destroy?

While testing , I found sometimes ktsan task is not destroy.At this time, task state is TASK_DEAD, but not enter finish_task_switch function.After adding some log, I found during context switch, task is switch.Why?When does ktsan task destroy?

Frequent lockups

[  295.076187] INFO: rcu_sched detected stalls on CPUs/tasks:
[  295.076197]  (detected by 1, t=21003 jiffies, g=7740, c=7739, q=376)
[  295.076197] All QSes seen, last rcu_sched kthread activity 20540 (4294962375-4294941835), jiffies_till_next_fqs=3, root ->qsmask 0x0
[  295.076197] trinity-c14     R  running task    12888  2942   2606 0x0000000c
[  295.076197]  0000000000000000 0000000000003258 ffff8800b8768080 ffff88063fc83d08
[  295.076197]  ffffffff810c8f0a 00000000ffff9c8b 00000000ffffecc7 0000000000000000
[  295.076197]  ffffffff82440e80 ffff88063fc83dd8 ffffffff8110904d 0000000000000000
[  295.076197] Call Trace:
[  295.076197]  <IRQ>  [<ffffffff810c8f0a>] sched_show_task+0xfa/0x160
[  295.076197]  [<ffffffff8110904d>] rcu_check_callbacks+0xc8d/0xcb0
[  295.076197]  [<ffffffff81090508>] ? __raise_softirq_irqoff+0x28/0x90
[  295.076197]  [<ffffffff811105fe>] update_process_times+0x3e/0x70
[  295.076197]  [<ffffffff811298be>] tick_sched_handle.isra.15+0x7e/0xa0
[  295.076197]  [<ffffffff8112a4be>] tick_sched_timer+0x5e/0xb0
[  295.076197]  [<ffffffff81111bb7>] __hrtimer_run_queues+0x237/0x460
[  295.076197]  [<ffffffff8112a460>] ? tick_sched_do_timer+0x70/0x70
[  295.076197]  [<ffffffff811123a5>] ? hrtimer_interrupt+0xe5/0x290
[  295.076197]  [<ffffffff811123be>] hrtimer_interrupt+0xfe/0x290
[  295.076197]  [<ffffffff8105da87>] local_apic_timer_interrupt+0x77/0xc0
[  295.076197]  [<ffffffff8105de9e>] smp_trace_apic_timer_interrupt+0x8e/0x1b0
[  295.076197]  [<ffffffff81eb358b>] trace_apic_timer_interrupt+0x6b/0x70
[  295.076197]  <EOI>  [<ffffffff81251fb0>] ? kt_spin_unlock+0x20/0x30
[  295.076197]  [<ffffffff8124ec92>] ? ktsan_atomic32_load+0x52/0x140
[  295.076197]  [<ffffffff81131b1a>] ? csd_lock_wait+0x2a/0x40
[  295.076197]  [<ffffffff811b4ef0>] ? perf_event_comm_output+0x360/0x360
[  295.076197]  [<ffffffff81131b1a>] csd_lock_wait+0x2a/0x40
[  295.076197]  [<ffffffff81131db9>] smp_call_function_single+0xb9/0x190
[  295.076197]  [<ffffffff811b4ef0>] ? perf_event_comm_output+0x360/0x360
[  295.076197]  [<ffffffff811b3d9e>] perf_event_read+0x19e/0x1b0
[  295.076197]  [<ffffffff811b3f2b>] ? perf_event_read_value+0x17b/0x1c0
[  295.076197]  [<ffffffff811b3ec5>] perf_event_read_value+0x115/0x1c0
[  295.076197]  [<ffffffff811b4647>] perf_read+0x347/0x510
[  295.076197]  [<ffffffff81260319>] ? do_readv_writev+0x3f9/0x420
[  295.076197]  [<ffffffff8125eaef>] ? do_loop_readv_writev+0xbf/0x120
[  295.076197]  [<ffffffff8125eb15>] do_loop_readv_writev+0xe5/0x120
[  295.076197]  [<ffffffff811b4300>] ? perf_try_init_event+0x100/0x100
[  295.076197]  [<ffffffff811b4300>] ? perf_try_init_event+0x100/0x100
[  295.076197]  [<ffffffff81260319>] do_readv_writev+0x3f9/0x420
[  295.076197]  [<ffffffff811138f4>] ? do_setitimer+0x294/0x3b0
[  295.076197]  [<ffffffff8126036f>] ? vfs_readv+0x2f/0x80
[  295.076197]  [<ffffffff8124ac57>] ? kt_access+0x177/0x460
[  295.076197]  [<ffffffff812616bb>] ? SyS_readv+0x6b/0x140
[  295.076197]  [<ffffffff8126036f>] ? vfs_readv+0x2f/0x80
[  295.076197]  [<ffffffff8126039a>] vfs_readv+0x5a/0x80
[  295.076197]  [<ffffffff812616bb>] SyS_readv+0x6b/0x140
[  295.076197]  [<ffffffff81eb26ee>] entry_SYSCALL_64_fastpath+0x12/0x71
[  295.076197] rcu_sched kthread starved for 20592 jiffies! g7740 c7739 f0x2

Print heap block allocation stack

If a race happens on heap block, we need to print description of the heap block: allocation thread/cpu, allocation stack, size, offset.
I've several reports where the racy accesses as if touch different fields. Allocation info would help.

__tsan_init not found error.

Got the following problem:

  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
kernel/Makefile:143: X.509 certificate list changed to "signing_key.x509" from "./signing_key.x509"
  CERTS   kernel/x509_certificate_list
  - Including cert signing_key.x509
  AS      kernel/system_certificates.o
  LD      kernel/built-in.o
  CHK     include/generated/uapi/linux/version.h
  LINK    vmlinux
  LD      vmlinux.o
  MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x32ee86): Section mismatch in reference from the function kt_thr_pool_init() to the function .init.text:kt_cache_init()
The function kt_thr_pool_init() references
the function __init kt_cache_init().
This is often because kt_thr_pool_init lacks a __init 
annotation or the annotation of kt_cache_init is wrong.

  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  LD      init/built-in.o
arch/x86/kernel/head64.o: In function `_GLOBAL__sub_I_00099_0_early_pmd_flags':
head64.c:(.text.startup+0x5): undefined reference to `__tsan_init'
arch/x86/kernel/head.o: In function `_GLOBAL__sub_I_00099_0_reserve_ebda_region':
head.c:(.text.startup+0x5): undefined reference to `__tsan_init'
init/built-in.o: In function `_GLOBAL__sub_I_00099_0___ksymtab_system_state':
main.c:(.text.startup+0x5): undefined reference to `__tsan_init'
init/built-in.o: In function `_GLOBAL__sub_I_00099_0_init_uts_ns':
version.c:(.text.startup+0x15): undefined reference to `__tsan_init'
init/built-in.o: In function `_GLOBAL__sub_I_00099_0_root_mountflags':
do_mounts.c:(.text.startup+0x25): undefined reference to `__tsan_init'
init/built-in.o:do_mounts_initrd.c:(.text.startup+0x35): more undefined references to `__tsan_init' follow
make: *** [vmlinux] Error 1

please help.

quarantine size can be set to 0 or underflow

#define QUARANTINE_FRACTION 32
#define QUARANTINE_PERCPU_SIZE (1 << 20)

void quarantine_reduce(void)
{
    new_quarantine_size = (READ_ONCE(totalram_pages) << PAGE_SHIFT) /
        QUARANTINE_FRACTION;
    new_quarantine_size -= QUARANTINE_PERCPU_SIZE * num_online_cpus();
    WRITE_ONCE(quarantine_size, new_quarantine_size);

When we subtract per-cpu size from quarantine, we can make new_quarantine_size 0 or underflow.
Need a lower bound on quarantine size.

Add GitHub repo description

Would be nice to see it in the list at https://github.com/google. Thanks!

increase default thread stack size

We see weird unexplainable crashes when running under kasan. The crashes usually happen in the scheduler. Here is a typical stack trace:

[ 6478.341912] BUG: unable to handle kernel paging request at 0000000380650980
[ 6478.526633] Call Trace:
[ 6478.529093] [] __schedule+0x2c3/0x970
[ 6478.534410] [] schedule+0x40/0xb0
[ 6478.539376] [] worker_thread+0x37e/0x640
[ 6478.551492] [] kthread+0x126/0x130
[ 6478.570919] [] ret_from_fork+0x9a/0xd0

Presumably this happens due to stack overflow, since kasan slightly increases stack consumption. We need to slightly increase stack size when running under kasan.

What's the difference between KTSAN and KCSAN?

As I known, I found KTSAN is used to find data race problems.But recently I found KCSAN is used to found data race as well, what's the difference between KTSAN and KCSAN?

HELP!!! ktsan kernel booting failed

Hi:

Kernel can not be booted. I don't know the reason. Could anyone give me a hand? Really appreciate.

qemu-system-x86_64 -hda wheezy_ktsan.img -m 4G -smp 4 -net user,hostfwd=tcp::10022-:22 -net nic -nographic -kernel ktsan/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda debug earlyprintk=serial slub_debug=QUZ" -enable-kvm 
early console in setup code
early console in decompress_kernel

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.2.0-tsan (geneblue@pc) (gcc version 6.0.0 20150825 (experimental) (GCC) ) google/ktsan#1 SMP Wed Jul 19 17:52:34 CST 2017
[    0.000000] Command line: console=ttyS0 root=/dev/sda debug earlyprintk=serial slub_debug=QUZ
[    0.000000] x86/fpu: Legacy x87 FPU detected.
[    0.000000] x86/fpu: Using 'lazy' FPU context switches.
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000bfffdfff] usable
[    0.000000] BIOS-e820: [mem 0x00000000bfffe000-0x00000000bfffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usable
[    0.000000] bootconsole [earlyser0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.
[    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[    0.000000] Hypervisor detected: KVM
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] e820: last_pfn = 0x140000 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 00C0000000 mask FFC0000000 uncachable
[    0.000000]   1 disabled
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86/PAT: PAT not supported by CPU.
[    0.000000] e820: last_pfn = 0xbfffe max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [mem 0x000f0ae0-0x000f0aef] mapped at [ffff8800000f0ae0]
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] BRK [0x028d3000, 0x028d3fff] PGTABLE
[    0.000000] BRK [0x028d4000, 0x028d4fff] PGTABLE
[    0.000000] BRK [0x028d5000, 0x028d5fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x13fe00000-0x13fffffff]
[    0.000000]  [mem 0x13fe00000-0x13fffffff] page 2M
[    0.000000] BRK [0x028d6000, 0x028d6fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x120000000-0x13fdfffff]
[    0.000000]  [mem 0x120000000-0x13fdfffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x00100000-0xbfffdfff]
[    0.000000]  [mem 0x00100000-0x001fffff] page 4k
[    0.000000]  [mem 0x00200000-0xbfdfffff] page 2M
[    0.000000]  [mem 0xbfe00000-0xbfffdfff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0x11fffffff]
[    0.000000]  [mem 0x100000000-0x11fffffff] page 2M
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F08B0 000014 (v00 BOCHS )
[    0.000000] ACPI: RSDT 0x00000000BFFFFCFC 000034 (v01 BOCHS  BXPCRSDT 00000001 BXPC 00000001)
[    0.000000] ACPI: FACP 0x00000000BFFFF1C0 000074 (v01 BOCHS  BXPCFACP 00000001 BXPC 00000001)
[    0.000000] ACPI: DSDT 0x00000000BFFFE040 001180 (v01 BOCHS  BXPCDSDT 00000001 BXPC 00000001)
[    0.000000] ACPI: FACS 0x00000000BFFFE000 000040
[    0.000000] ACPI: SSDT 0x00000000BFFFF234 000A00 (v01 BOCHS  BXPCSSDT 00000001 BXPC 00000001)
[    0.000000] ACPI: APIC 0x00000000BFFFFC34 000090 (v01 BOCHS  BXPCAPIC 00000001 BXPC 00000001)
[    0.000000] ACPI: HPET 0x00000000BFFFFCC4 000038 (v01 BOCHS  BXPCHPET 00000001 BXPC 00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000013fffffff]
[    0.000000] NODE_DATA(0) allocated [mem 0x13fff9000-0x13fffcfff]
[    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[    0.000000] kvm-clock: cpu 0, msr 1:3fff8001, primary cpu clock
[    0.000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[    0.000000]  [ffffea0000000000-ffffea0004ffffff] PMD -> [ffff88013b600000-ffff88013f5fffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.000000]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x000000013fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009efff]
[    0.000000]   node   0: [mem 0x0000000000100000-0x00000000bfffdfff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x000000013fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000013fffffff]
[    0.000000] On node 0 totalpages: 1048476
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3998 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 12224 pages used for memmap
[    0.000000]   DMA32 zone: 782334 pages, LIFO batch:31
[    0.000000]   Normal zone: 4096 pages used for memmap
[    0.000000]   Normal zone: 262144 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
[    0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[    0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
[    0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000effff]
[    0.000000] PM: Registered nosave memory: [mem 0x000f0000-0x000fffff]
[    0.000000] PM: Registered nosave memory: [mem 0xbfffe000-0xbfffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xc0000000-0xfeffbfff]
[    0.000000] PM: Registered nosave memory: [mem 0xfeffc000-0xfeffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xff000000-0xfffbffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfffc0000-0xffffffff]
[    0.000000] e820: [mem 0xc0000000-0xfeffbfff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on KVM
[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 32 pages/cpu @ffff88013fc00000 s90328 r8192 d32552 u524288
[    0.000000] pcpu-alloc: s90328 r8192 d32552 u524288 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 
[    0.000000] KVM setup async PF for cpu 0
[    0.000000] kvm-stealtime: cpu 0, msr 13fc0d440
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1032071
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: console=ttyS0 root=/dev/sda debug earlyprintk=serial slub_debug=QUZ
[    0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x3462f3200 bytes below 0x0.
[    0.000000] 
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-tsan google/ktsan#1
[    0.000000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[    0.000000]  0000000000000000 0000000000000000 000000000000a110 ffffffff82403d98
[    0.000000]  ffffffff81ed0d2e ffffffff821bc6f0 00000003462f3200 ffffffff82403e28
[    0.000000]  ffffffff81eceb88 0000000000000000 0000000300000018 ffffffff82403e38
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff81ed0d2e>] dump_stack+0x67/0x86
[    0.000000]  [<ffffffff81eceb88>] panic+0xee/0x29f
[    0.000000]  [<ffffffff82568774>] memblock_alloc_base+0x41/0x54
[    0.000000]  [<ffffffff825687aa>] memblock_alloc+0x23/0x33
[    0.000000]  [<ffffffff8256b40d>] kt_cache_init+0x41/0x97
[    0.000000]  [<ffffffff8256b5fb>] kt_tab_init+0x87/0x96
[    0.000000]  [<ffffffff8256b4ad>] ktsan_init_early+0x32/0xa7
[    0.000000]  [<ffffffff8252e453>] start_kernel+0x27f/0x56f
[    0.000000]  [<ffffffff8252d3ce>] x86_64_start_reservations+0x49/0x52
[    0.000000]  [<ffffffff8252d120>] ? early_idt_handler_array+0x120/0x120
[    0.000000]  [<ffffffff8252d695>] x86_64_start_kernel+0x2be/0x2d2
[    0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x3462f3200 bytes below 0x0.
[    0.000000] 
[    0.000000] BUG: unable to handle kernel paging request at 00000000ffffffff
[    0.000000] IP: [<ffffffff81070e26>] native_restore_fl+0x6/0x10
[    0.000000] PGD 0 
[    0.000000] Oops: 0000 [#1] SMP 
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-tsan google/ktsan#1
[    0.000000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[    0.000000] task: ffffffff824114c0 ti: ffffffff82400000 task.ti: ffffffff82400000
[    0.000000] RIP: 0010:[<ffffffff81070e26>]  [<ffffffff81070e26>] native_restore_fl+0x6/0x10
[    0.000000] RSP: 0000:ffffffff82403d48  EFLAGS: 00000292
[    0.000000] RAX: 0000000000000292 RBX: 00000000000072d8 RCX: 0000000000000001
[    0.000000] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000292
[    0.000000] RBP: ffffffff82403d48 R08: 0000000000000020 R09: 0000000000000020
[    0.000000] R10: 6e6170206c656e72 R11: 746f6e202d206369 R12: 0000000000000292
[    0.000000] R13: ffffffff81eced31 R14: 0000000000000029 R15: ffffffff826a2fa0
[    0.000000] FS:  0000000000000000(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
[    0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.000000] CR2: 00000000ffffffff CR3: 000000000240c000 CR4: 00000000000006b0
[    0.000000] Stack:
[    0.000000]  ffffffff82403d78 ffffffff8124e322 ffffffff82403d78 00000000000072d8
[    0.000000]  0000000001062560 00000000000073a0 ffffffff82403d98 ffffffff8155b277
[    0.000000]  00000000000072d8 0000000000000000 ffffffff82403e28 ffffffff81eced31
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff8124e322>] ktsan_func_entry+0x92/0xa0
[    0.000000]  [<ffffffff8155b277>] __const_udelay+0x17/0x60
[    0.000000]  [<ffffffff81eced31>] panic+0x297/0x29f
[    0.000000]  [<ffffffff82568774>] memblock_alloc_base+0x41/0x54
[    0.000000]  [<ffffffff825687aa>] memblock_alloc+0x23/0x33
[    0.000000]  [<ffffffff8256b40d>] kt_cache_init+0x41/0x97
[    0.000000]  [<ffffffff8256b5fb>] kt_tab_init+0x87/0x96
[    0.000000]  [<ffffffff8256b4ad>] ktsan_init_early+0x32/0xa7
[    0.000000]  [<ffffffff8252e453>] start_kernel+0x27f/0x56f
[    0.000000]  [<ffffffff8252d3ce>] x86_64_start_reservations+0x49/0x52
[    0.000000]  [<ffffffff8252d120>] ? early_idt_handler_array+0x120/0x120
[    0.000000]  [<ffffffff8252d695>] x86_64_start_kernel+0x2be/0x2d2
[    0.000000] Code: 0f 1f 44 00 00 55 48 89 e5 0f 09 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 9c 58 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 57 9d <5d> c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 fa 5d c3 66 0f 1f 84 
[    0.000000] RIP  [<ffffffff81070e26>] native_restore_fl+0x6/0x10
[    0.000000]  RSP <ffffffff82403d48>
[    0.000000] CR2: 00000000ffffffff
[    0.000000] ---[ end trace faaf0b306eda8373 ]---

Check that allocator does not introduce lots of unnecessary synchronization

We need to double check that memory allocator (slab, slub) does not introduce lots of unnecessary synchronization. We need to ignore all synchronization in the allocator. Otherwise even fast-path will synchronize threads on per-cpu cache. Slow path will synchronize even threads running on different cpus. We should ignore that synchronization as much as possible.

false positive in depot_save_stack

Here are two crashes from syzkaller:
https://gist.githubusercontent.com/dvyukov/56c471c2cbf4aaa97aceb415bbb4e874/raw/40823c87465a70d03e05e668cfa82e1e1d16632b/gistfile1.txt
https://gist.githubusercontent.com/dvyukov/d821a21df08e71c1acb396d9ad951752/raw/b699c035ab1f54d6b9d495b50ae13ef8144990c0/gistfile1.txt

Both have similar false positive reports:

[  322.479239] ==================================================================
[  322.480040] BUG: KASAN: stack-out-of-bounds in memcmp+0xe9/0x150 at addr ffff880038bb74e8
[  322.480040] Read of size 1 by task syz-executor/553
[  322.480040] page:ffffea0000e2edc0 count:0 mapcount:0 mapping:          (null) index:0x0
[  322.487260] flags: 0xfffe0000000000()
[  322.487260] page dumped because: kasan: bad access detected
[  322.487260] CPU: 2 PID: 553 Comm: syz-executor Not tainted 4.7.0-rc5+ #28
[  322.487260] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[  322.487260]  ffffffff880b58e0 ffff880038bb7310 ffffffff82cc01af ffffffff38bb73a0
[  322.487260]  fffffbfff1016b1c ffff880038bb73a0 ffff880038bb74e8 ffff880038bb7548
[  322.487260]  ffff880038bb7540 00000000000000b0 ffff880038bb7390 ffffffff817b9a03
[  322.487260] Call Trace:
[  322.487260]  [<ffffffff82cc01af>] dump_stack+0x12e/0x18f
[  322.487260]  [<ffffffff817b9a03>] kasan_report_error+0x573/0x5a0
[  322.487260]  [<ffffffff8151e6e3>] ? __module_text_address+0x13/0x150
[  322.487260]  [<ffffffff817b9a6e>] __asan_report_load1_noabort+0x3e/0x40
[  322.487260]  [<ffffffff82cddcb9>] ? memcmp+0xe9/0x150
[  322.487260]  [<ffffffff82cddcb9>] memcmp+0xe9/0x150
[  322.487260]  [<ffffffff82d8d7e6>] depot_save_stack+0x176/0x5b0
[  322.487260]  [<ffffffff858c0e24>] ? skb_free_head+0x74/0xb0
[  322.487260]  [<ffffffff817b8951>] save_stack+0xb1/0xd0
...
[  322.554627] Memory state around the buggy address:
[  322.554627]  ffff880038bb7380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  322.554627]  ffff880038bb7400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  322.554627] >ffff880038bb7480: 00 00 00 00 00 00 00 00 00 00 00 00 00 f4 f4 00
[  322.554627]                                                           ^
[  322.554627]  ffff880038bb7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  322.554627]  ffff880038bb7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

f4 is leftover of stack frames.

Out-of-bounds report with a zero shadow byte

Here is a report:

==================================================================
BUG: KASan: out of bounds access in get_wchan+0x150/0x180 at addr ffff88006901fc98
Read of size 8 by task ps/1290
page:ffffea0001a407c0 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000000()
page dumped because: kasan: bad access detected
CPU: 1 PID: 1290 Comm: ps Not tainted 4.2.0-rc8-kasan #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffff880069975940 ffff880069a4f758 ffffffff82d57cd4 1ffffd40003480f8
 ffff880069a4f7f0 ffff880069a4f7d8 ffffffff814290f1 ffff880069a4f7c8
 ffffffff811776fe 0000000000000296 0000000000000000 ffff880069a4f9b8
Call Trace:
 [<     inlined    >] dump_stack+0x45/0x57 __dump_stack lib/dump_stack.c:15
 [<ffffffff82d57cd4>] dump_stack+0x45/0x57 lib/dump_stack.c:50
 [<     inlined    >] kasan_report_error+0x391/0x3c0 print_address_description mm/kasan/report.c:132
 [<ffffffff814290f1>] kasan_report_error+0x391/0x3c0 mm/kasan/report.c:193
 [<ffffffff811776fe>] ? cputime_adjust+0x4e/0x470 kernel/sched/cputime.c:594
 [<     inlined    >] __asan_report_load8_noabort+0x3e/0x40 kasan_report mm/kasan/report.c:230
 [<ffffffff8142921e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:251
 [<ffffffff81178f60>] ? task_cputime_adjusted+0x180/0x180 include/linux/sched.h:2005
 [<ffffffff81005ec0>] ? get_wchan+0x150/0x180 arch/x86/kernel/process_64.c:511
 [<ffffffff81005ec0>] get_wchan+0x150/0x180 arch/x86/kernel/process_64.c:511
 [<ffffffff81577030>] do_task_stat+0x13f0/0x18d0 fs/proc/array.c:455
 [<ffffffff81575c40>] ? render_cap_t+0xb0/0xb0 fs/proc/array.c:302
 [<ffffffff814226be>] ? init_object+0x3e/0x70 mm/slub.c:684
 [<ffffffff81422f0f>] ? alloc_debug_processing+0x14f/0x180 mm/slub.c:1049
 [<     inlined    >] ? seq_buf_alloc+0x16/0x40 kmalloc include/linux/slab.h:435
 [<ffffffff8149e156>] ? seq_buf_alloc+0x16/0x40 fs/seq_file.c:32
 [<     inlined    >] ? kasan_unpoison_shadow+0x36/0x50 kasan_poison_shadow mm/kasan/kasan.c:49
 [<ffffffff81428636>] ? kasan_unpoison_shadow+0x36/0x50 mm/kasan/kasan.c:54
 [<     inlined    >] ? kasan_unpoison_shadow+0x36/0x50 kasan_poison_shadow mm/kasan/kasan.c:49
 [<ffffffff81428636>] ? kasan_unpoison_shadow+0x36/0x50 mm/kasan/kasan.c:54
 [<ffffffff815792cf>] proc_tgid_stat+0xf/0x20 fs/proc/array.c:549
 [<ffffffff8156d686>] proc_single_show+0xe6/0x160 fs/proc/base.c:790
 [<ffffffff8149f021>] seq_read+0x2e1/0x1140 fs/seq_file.c:230
 [<ffffffff812424c3>] ? __module_text_address+0x13/0x140 kernel/module.c:4047
 [<ffffffff8149ed40>] ? seq_lseek+0x370/0x370 fs/seq_file.c:321
 [<ffffffff8100f02f>] ? dump_trace+0x10f/0x2f0 arch/x86/kernel/dumpstack_64.c:243
 [<ffffffff81423a9e>] ? deactivate_slab+0x12e/0x3f0 mm/slub.c:1943
 [<ffffffff8143571b>] __vfs_read+0xdb/0x3d0 fs/read_write.c:432
 [<ffffffff81435640>] ? vfs_iter_write+0x2b0/0x2b0 fs/read_write.c:367
 [<ffffffff814226be>] ? init_object+0x3e/0x70 mm/slub.c:684
 [<ffffffff814237ce>] ? free_debug_processing+0x15e/0x250 mm/slub.c:1108
 [<ffffffff8189e255>] ? selinux_file_permission+0x2d5/0x430 security/selinux/hooks.c:3214 (discriminator 2)
 [<     inlined    >] ? security_file_permission+0x148/0x1a0 fsnotify_perm include/linux/fsnotify.h:60
 [<ffffffff81881898>] ? security_file_permission+0x148/0x1a0 security/security.c:742
 [<ffffffff81436f07>] ? rw_verify_area+0xb7/0x290 fs/read_write.c:404 (discriminator 4)
 [<ffffffff8146595c>] ? putname+0xbc/0xf0 fs/namei.c:255
 [<ffffffff814371b3>] vfs_read+0xd3/0x2e0 fs/read_write.c:454
 [<     inlined    >] SyS_read+0x109/0x220 SYSC_read fs/read_write.c:569
 [<ffffffff8143a0c9>] SyS_read+0x109/0x220 fs/read_write.c:562
 [<ffffffff81439fc0>] ? do_sendfile+0x1250/0x1250 include/linux/fs.h:2469
 [<ffffffff82d6e9ae>] entry_SYSCALL_64_fastpath+0x12/0x71 arch/x86/entry/entry_64.S:186
Memory state around the buggy address:
 ffff88006901fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88006901fc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88006901fc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                               ^
 ffff88006901fd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88006901fd80: 00 f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 f4 f4
==================================================================

The shadow byte pointed to in the report epilogue is 0, which is weird.

The report itself looks similar to a one we had before (http://www.spinics.net/lists/kernel/msg1596173.html), but I'm not sure if it's valid though.
BTW, the bug in the old report wasn't fixed, as far as I see.

Tame stand-alone memory barriers

We should:

Reset effects of rmv/wmb after some time (e.g. after several function calls, subject to tuning).
Not create sync objects when we don't need to (e.g. in atomic_set when there is no preceding wmb).
This can improve both memory consumption (don't create unnecessary sync objects) or performance (don't do excessive clock operations).

kernel BUG at mm/ktsan/thr.c:129!

------------[ cut here ]------------
kernel BUG at mm/ktsan/thr.c:129!
invalid opcode: 0000 [#3] SMP
Modules linked in:
CPU: 5 PID: 2758 Comm: sshd Tainted: G      D         4.2.0+ #396
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880485130240 ti: ffff880480788000 task.ti: ffff880480788000
RIP: 0010:[<ffffffff8125adba>]  [<ffffffff8125adba>] kt_thr_start+0xaa/0xb0
RSP: 0018:ffff88048078be40  EFLAGS: 00010082
RAX: ffffe8ffffca0910 RBX: ffff8804d6686e70 RCX: 0000000000000001
RDX: 0000000000000001 RSI: ffffffff810c6393 RDI: 0000000000000082
RBP: 00000ac600050004 R08: ffff880480788000 R09: 0000000000000000
R10: ffff88083fcb4fe8 R11: ffff8804862b8c20 R12: 000000000000951a
R13: ffff88047e261440 R14: ffff880485130240 R15: 0000000000000040
FS:  00007f4c10bf37c0(0000) GS:ffff88083fca0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000485ed4000 CR4: 00000000000006e0
Stack:
 ffff8804d6686e70 0000000000000286 ffff88048594d0c0 ffffffff812531e6
 ffff880485130240 ffff88083fcb4f80 ffff88048078bec0 ffffffff810c6393
 ffff8804862165c0 ffff88083fcb4f80 ffff88047e13a540 ffff88083fcb4f80
Call Trace:
 [<ffffffff812531e6>] ? ktsan_thr_start+0x66/0x90 mm/ktsan/ktsan.c:312 (discriminator 7)
 [<ffffffff810c6393>] ? finish_task_switch+0x1e3/0x240 kernel/sched/core.c:2493
 [<     inline     >] ? context_switch kernel/sched/core.c:2614
 [<ffffffff81edd361>] ? __schedule+0x401/0xb20 kernel/sched/core.c:3076
 [<ffffffff81261976>] ? SyS_write+0xa6/0xd0 include/linux/file.h:39
 [<ffffffff81eddab2>] ? schedule+0x32/0x80 kernel/sched/core.c:3106 (discriminator 1)
 [<ffffffff81ee3f83>] ? int_careful+0x14/0x22 arch/x86/entry/entry_64.S:303
RIP  [<     inline     >] kt_trace_add_event mm/ktsan/ktsan.h:512
RIP  [<ffffffff8125adba>] kt_thr_start+0xaa/0xb0 mm/ktsan/thr.c:124
 RSP <ffff88048078be40>
---[ end trace 08d41ce765fd8efc ]---

This is BUG_ON(thr->cpu->thr != NULL) in kt_thr_start.
How do we run 2 threads on the same cpu?..

Annotate more synchronization primitives

We need to annotate:

include/linux/percpu-rwsem.h / kernel/locking/percpu-rwsem.c

Absence of annotation does not lead to false positives, but adds parasitic synchronization (readers don't synchronize on rwlocks).

False positives due to SLAB_DESTROY_BY_RCU

This is false positives. Free into SLAB_DESTROY_BY_RCU slab must not write to object.

ThreadSanitizer: data-race in kmem_cache_free

Write at 0xffff8804852e1588 of size 8 by thread 2962 on CPU 8:
 [<     inline     >] __cache_free mm/slab.c:3384
 [<ffffffff812451f2>] kmem_cache_free+0x92/0x480 mm/slab.c:3562
 [<ffffffff81086d0b>] __cleanup_sighand+0x5b/0x70 kernel/fork.c:1096
 [<     inline     >] __exit_signal kernel/exit.c:151
 [<ffffffff8108cf25>] release_task+0x855/0xaa0 kernel/exit.c:184
 [<     inline     >] wait_task_zombie kernel/exit.c:1111
 [<ffffffff8108ef41>] wait_consider_task+0x9f1/0x18a0 kernel/exit.c:1354
 [<     inline     >] do_wait_thread kernel/exit.c:1417
 [<ffffffff8108ff9f>] do_wait+0x1af/0x3b0 kernel/exit.c:1488
 [<     inline     >] SYSC_wait4 kernel/exit.c:1615
 [<ffffffff810906d5>] SyS_wait4+0xe5/0x160 kernel/exit.c:1584
 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188

Previous read at 0xffff8804852e1588 of size 1 by thread 2961 on CPU 5:
 [<     inline     >] __raw_spin_unlock include/linux/spinlock_api_smp.h:165
 [<     inline     >] spin_unlock include/linux/spinlock.h:357
 [<ffffffff8109fe28>] __lock_task_sighand+0xe8/0x140 kernel/signal.c:1289
 [<     inline     >] lock_task_sighand include/linux/sched.h:2720
 [<ffffffff8109feb0>] do_send_sig_info+0x30/0xa0 kernel/signal.c:1186
 [<ffffffff810a0595>] group_send_sig_info+0x55/0x70 kernel/signal.c:1309
 [<ffffffff810a0743>] kill_pid_info+0x43/0x90 kernel/signal.c:1343
 [<     inline     >] kill_something_info kernel/signal.c:1426
 [<ffffffff810a0903>] SYSC_kill+0x123/0x2f0 kernel/signal.c:2906
 [<ffffffff810a3520>] SyS_kill+0x20/0x30 kernel/signal.c:2896
 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188

Mutexes locked by thread 2962:
Mutex 195 is locked here:
 [<     inline     >] __raw_write_lock_irq include/linux/rwlock_api_smp.h:217
 [<ffffffff81ee38d4>] _raw_write_lock_irq+0x64/0x70 kernel/locking/spinlock.c:311
 [<ffffffff8108c745>] release_task+0x75/0xaa0 kernel/exit.c:182
 [<     inline     >] wait_task_zombie kernel/exit.c:1111
 [<ffffffff8108ef41>] wait_consider_task+0x9f1/0x18a0 kernel/exit.c:1354
 [<     inline     >] do_wait_thread kernel/exit.c:1417
 [<ffffffff8108ff9f>] do_wait+0x1af/0x3b0 kernel/exit.c:1488
 [<     inline     >] SYSC_wait4 kernel/exit.c:1615
 [<ffffffff810906d5>] SyS_wait4+0xe5/0x160 kernel/exit.c:1584
 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188

Mutexes locked by thread 2961:
Mutex 517812 is locked here:
 [<     inline     >] __raw_spin_lock include/linux/spinlock_api_smp.h:158
 [<ffffffff81ee37d0>] _raw_spin_lock+0x50/0x70 kernel/locking/spinlock.c:151
 [<     inline     >] spin_lock include/linux/spinlock.h:312
 [<ffffffff8109fdad>] __lock_task_sighand+0x6d/0x140 kernel/signal.c:1284
 [<     inline     >] lock_task_sighand include/linux/sched.h:2720
 [<ffffffff8109feb0>] do_send_sig_info+0x30/0xa0 kernel/signal.c:1186
 [<ffffffff810a0595>] group_send_sig_info+0x55/0x70 kernel/signal.c:1309
[<ffffffff810a0743>] kill_pid_info+0x43/0x90
 [<     inline     >] kill_something_info kernel/signal.c:1426
 [<ffffffff810a0903>] SYSC_kill+0x123/0x2f0 kernel/signal.c:2906
 [<ffffffff810a3520>] SyS_kill+0x20/0x30 kernel/signal.c:2896
 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188

false positives with T0

I am seeing false positives with T0. Presumably both racy accesses are executed on the same CPU, but first accesses is executed on a thread context, while another on the scheduler context (T0).

ThreadSanitizer: data-race in rb_insert_color

Write of size 8 by thread T0 (K0):
 [<     inlined    >] rb_insert_color+0x2e6/0x380 rb_set_parent_color include/linux/rbtree_augmented.h:117
 [<     inlined    >] rb_insert_color+0x2e6/0x380 __rb_insert lib/rbtree.c:111
 [<ffffffff81552056>] rb_insert_color+0x2e6/0x380 lib/rbtree.c:420
 [<ffffffff810cf2c7>] __enqueue_entity+0x67/0x70 kernel/sched/fair.c:524
 [<     inlined    >] enqueue_task_fair+0x784/0x1230 enqueue_entity kernel/sched/fair.c:3118
 [<ffffffff810d3b44>] enqueue_task_fair+0x784/0x1230 kernel/sched/fair.c:4239
 [<ffffffff810c4507>] enqueue_task+0x37/0x60 kernel/sched/core.c:834
 [<ffffffff810c7076>] activate_task+0x26/0x30 kernel/sched/core.c:849
 [<     inlined    >] ttwu_do_activate.constprop.95+0x2e/0x60 ttwu_activate kernel/sched/core.c:1643
 [<ffffffff810c72fe>] ttwu_do_activate.constprop.95+0x2e/0x60 kernel/sched/core.c:1696
 [<     inlined    >] try_to_wake_up+0x314/0x3c0 ttwu_queue kernel/sched/core.c:1841
 [<ffffffff810c7e84>] try_to_wake_up+0x314/0x3c0 kernel/sched/core.c:1909
 [<ffffffff810c7f52>] wake_up_process+0x22/0x40 kernel/sched/core.c:1977 (discriminator 3)
 [<ffffffff8110e6cd>] process_timeout+0x1d/0x30 kernel/time/timer.c:1441
 [<ffffffff8110e72c>] call_timer_fn+0x4c/0x1c0 kernel/time/timer.c:1155
 [<     inlined    >] run_timer_softirq+0x313/0x510 __run_timers kernel/time/timer.c:1231
 [<ffffffff8110f683>] run_timer_softirq+0x313/0x510 kernel/time/timer.c:1414
 [<ffffffff81091d1e>] __do_softirq+0xbe/0x300 kernel/softirq.c:273
 [<     inlined    >] irq_exit+0xb0/0xc0 invoke_softirq kernel/softirq.c:350
 [<ffffffff81092100>] irq_exit+0xb0/0xc0 kernel/softirq.c:391
 [<     inlined    >] smp_apic_timer_interrupt+0x7b/0xb0 exiting_irq ./arch/x86/include/asm/apic.h:655
 [<ffffffff8105eb1b>] smp_apic_timer_interrupt+0x7b/0xb0 arch/x86/kernel/apic/apic.c:915
 [<ffffffff81ee529b>] apic_timer_interrupt+0x6b/0x70 arch/x86/entry/entry_64.S:782
 [<     inlined    >] default_idle+0x3f/0x170 arch_safe_halt ./arch/x86/include/asm/paravirt.h:111
 [<ffffffff81015c9f>] default_idle+0x3f/0x170 arch/x86/kernel/process.c:301
 [<ffffffff810165cf>] arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:292
 [<ffffffff810dcf8f>] default_idle_call+0x3f/0x60 kernel/sched/idle.c:89
 [<     inlined    >] cpu_startup_entry+0x37c/0x3f0 cpuidle_idle_call kernel/sched/idle.c:157
 [<     inlined    >] cpu_startup_entry+0x37c/0x3f0 cpu_idle_loop kernel/sched/idle.c:253
 [<ffffffff810dd3bc>] cpu_startup_entry+0x37c/0x3f0 kernel/sched/idle.c:301
 [<ffffffff81ed095d>] rest_init+0x9d/0xb0 init/main.c:413
 [<ffffffff8252c738>] start_kernel+0x564/0x578 init/main.c:687
 [<ffffffff8252b3ce>] x86_64_start_reservations+0x49/0x52 arch/x86/kernel/head64.c:195
 [<ffffffff8252b695>] x86_64_start_kernel+0x2be/0x2d2 arch/x86/kernel/head64.c:184
DBG: cpu = ffffe8ffffc00910
DBG: cpu id = 0

Previous read of size 8 by thread T10 (K0):
 [<     inlined    >] rb_insert_color+0x3e/0x380 __rb_insert lib/rbtree.c:113
 [<ffffffff81551dae>] rb_insert_color+0x3e/0x380 lib/rbtree.c:420
 [<ffffffff810cf2c7>] __enqueue_entity+0x67/0x70 kernel/sched/fair.c:524
 [<ffffffff810af76c>] __queue_work+0x2dc/0x680 kernel/workqueue.c:1394
 [<ffffffff810b0227>] delayed_work_timer_fn+0x37/0x50 kernel/workqueue.c:1433
 [<ffffffff8110e72c>] call_timer_fn+0x4c/0x1c0 kernel/time/timer.c:1155
 [<     inlined    >] run_timer_softirq+0x2c9/0x510 __run_timers kernel/time/timer.c:1227
 [<ffffffff8110f639>] run_timer_softirq+0x2c9/0x510 kernel/time/timer.c:1414
 [<ffffffff81091d1e>] __do_softirq+0xbe/0x300 kernel/softirq.c:273
 [<ffffffff81ee529b>] apic_timer_interrupt+0x6b/0x70 arch/x86/entry/entry_64.S:782
 [<     inlined    >] cpu_startup_entry+0x193/0x3f0 cpu_idle_loop kernel/sched/idle.c:267
 [<ffffffff810dd1d3>] cpu_startup_entry+0x193/0x3f0 kernel/sched/idle.c:301
DBG: cpu = 0

DBG: addr: ffff880139585238
DBG: first offset: 0, second offset: 0
DBG: T0 clock: {T0: 21687551, T10: 23571656}
DBG: T10 clock: {T10: 23571668}

kernel with kasan compiled in fails to boot

early console in decompress_kernel
input_data: 0x0000000002eb324d
input_len: 0x00000000000165d8
output: 0x0000000001000000
output_len: 0x00000000026d6b20
run_size: 0x0000000002a00000

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
_

(where the last line, consisting of one char, namely '_', ominously blinks...
forever)

I tried with and without modules, in all variants (ah, just remembered, haven't tried vanilla kernels yet). But invariably it does not boot.
To see more about my system, pls look up the Gentoo Bugzilla, lots of info on my system there:
https://bugs.gentoo.org/show_bug.cgi?id=597554
such as:
https://bugs.gentoo.org/attachment.cgi?id=451298

Properly report atomic accesses as atomic accesses

Currently we model atomic accesses as 1-byte reads. And that's how they appear in race reports. This can confuse whoever reads the report, because source code contains no 1-byte reads. This in turn can lead to a conclusion that the tool produces bogus reports.
We need to properly report atomic accesses at atomic accesses.

Handle synchronization on struct page

We've removed all synchronization on page struct because it lead to enormous memory consumption for vector clocks (there were millions of sync objects). Initially we've not noticed false positives.
But here is one:
https://groups.google.com/forum/#!topic/ktsan/m1lJug5oAIg
(see the explanation by Theodore that the code is actually synchronized on struct page->flags).
There are hundreds of uses of lock_page and trylock_page throughout kernel code, so we need to restore synchronization on struct page. Otherwise we will be constantly hitting false positives.

How to compile and use ktsan in x86?

Report RCU read critical sections

Mutexset should also capture whether the thread is inside of RCU read critical sections (along with stack). Then this info will be printed in reports, which is useful to understand what happens.

stackdepot runs out of capacity

Syzkaller constantly runs out of stackdepot capacity.
It is reproducible even on a local instance constantly replaying a single program, so I suspect that there is some kind of bug (potentially related to interrupts). Here is one report from local qemu instance:

[ 2346.999011] ------------[ cut here ]------------
[ 2346.999051] WARNING: CPU: 3 PID: 27963 at lib/stackdepot.c:119 depot_save_stack+0x34f/0x5b0
[ 2346.999051] Stack depot reached limit capacity
[ 2346.999051] Modules linked in:
[ 2346.999051] CPU: 3 PID: 27963 Comm: syz-executor Not tainted 4.7.0-rc5+ #28
[ 2346.999051] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[ 2346.999051]  ffffffff880b58e0 ffff88006d5077d8 ffffffff82cc01af ffffffff814955e8
[ 2346.999051]  fffffbfff1016b1c ffff88006d507850 0000000000000000 ffffffff87e76459
[ 2347.003057]  ffffffff82d8d9bf 0000000000000009 ffff88006d507820 ffffffff8136d17f
[ 2347.003057] Call Trace:
[ 2347.003057]  <IRQ>  [<ffffffff82cc01af>] dump_stack+0x12e/0x18f
[ 2347.003057]  [<ffffffff814955e8>] ? vprintk_default+0x28/0x30
[ 2347.003057]  [<ffffffff82d8d9bf>] ? depot_save_stack+0x34f/0x5b0
[ 2347.003057]  [<ffffffff8136d17f>] __warn+0x19f/0x1e0
[ 2347.003057]  [<ffffffff8136d26c>] warn_slowpath_fmt+0xac/0xd0
[ 2347.003057]  [<ffffffff8136d1c0>] ? __warn+0x1e0/0x1e0
[ 2347.003057]  [<ffffffff82d8d9bf>] depot_save_stack+0x34f/0x5b0
[ 2347.003057]  [<ffffffff816a1f1d>] ? mempool_free_slab+0x1d/0x30
[ 2347.003057]  [<ffffffff817b8951>] save_stack+0xb1/0xd0
[ 2347.003057]  [<ffffffff81223756>] ? save_stack_trace+0x26/0x50
[ 2347.003057]  [<ffffffff817b88e6>] ? save_stack+0x46/0xd0
[ 2347.003057]  [<ffffffff817b90cb>] ? kasan_slab_free+0x9b/0xd0
[ 2347.003057]  [<ffffffff817b62f6>] ? kmem_cache_free+0x76/0x310
[ 2347.003057]  [<ffffffff816a1f1d>] ? mempool_free_slab+0x1d/0x30
[ 2347.003057]  [<ffffffff816a3044>] ? mempool_free+0xd4/0x1d0
[ 2347.003057]  [<ffffffff82c1084f>] ? bio_free+0xef/0x1b0
[ 2347.003057]  [<ffffffff82c109a8>] ? bio_put+0x98/0xc0
[ 2347.003057]  [<ffffffff81ad88bf>] ? ext4_end_bio+0x11f/0x460
[ 2347.003057]  [<ffffffff82c10b72>] ? bio_endio+0x1a2/0x200
[ 2347.013074]  [<ffffffff82c30d0c>] ? blk_update_request+0x1bc/0xc80
[ 2347.013074]  [<ffffffff83aa5bbd>] ? scsi_end_request+0x9d/0x5b0
[ 2347.013074]  [<ffffffff83aaf220>] ? scsi_io_completion+0x470/0x1340
[ 2347.013074]  [<ffffffff83a92f6c>] ? scsi_finish_command+0x3ac/0x530
[ 2347.013074]  [<ffffffff83aada19>] ? scsi_softirq_done+0x2a9/0x350
[ 2347.013074]  [<ffffffff82c51018>] ? __blk_mq_complete_request_remote+0x58/0x70
[ 2347.013074]  [<ffffffff81515e2f>] ? flush_smp_call_function_queue+0xdf/0x3e0
[ 2347.013074]  [<ffffffff81517b23>] ? generic_smp_call_function_single_interrupt+0x13/0x80
[ 2347.013074]  [<ffffffff8125a4df>] ? smp_call_function_single_interrupt+0x5f/0x80
[ 2347.013074]  [<ffffffff86a961ec>] ? call_function_single_interrupt+0x8c/0xa0
[ 2347.013074]  [<ffffffff817e6b1d>] ? get_mem_cgroup_from_mm+0x2ad/0x4a0
[ 2347.013074]  [<ffffffff817f662a>] ? mem_cgroup_try_charge+0x17a/0x690
[ 2347.013074]  [<ffffffff8174030c>] ? handle_pte_fault+0x382c/0x4960
[ 2347.013074]  [<ffffffff817428ab>] ? handle_mm_fault+0xeab/0x11a0
[ 2347.013074]  [<ffffffff81290e67>] ? __do_page_fault+0x457/0xbb0
[ 2347.013074]  [<ffffffff8129170f>] ? trace_do_page_fault+0xdf/0x5b0
[ 2347.013074]  [<ffffffff81281c24>] ? do_async_page_fault+0x14/0xd0
[ 2347.013074]  [<ffffffff86a96fb8>] ? async_page_fault+0x28/0x30
[ 2347.013074]  [<ffffffff82cc23d4>] ? __fprop_inc_percpu_max+0x164/0x200
[ 2347.013074]  [<ffffffff814b4be7>] ? debug_lockdep_rcu_enabled+0x77/0x90
[ 2347.013074]  [<ffffffff82ccf120>] ? node_tag_clear+0x190/0x190
[ 2347.013074]  [<ffffffff816ca570>] ? test_clear_page_writeback+0x100/0x830
[ 2347.013074]  [<ffffffff81470fed>] ? trace_hardirqs_off+0xd/0x10
[ 2347.013074]  [<ffffffff817ba16a>] ? quarantine_put+0xea/0x140
[ 2347.013074]  [<ffffffff817b90cb>] kasan_slab_free+0x9b/0xd0
[ 2347.013074]  [<ffffffff817b62f6>] kmem_cache_free+0x76/0x310
[ 2347.013074]  [<ffffffff816a1f00>] ? mempool_kfree+0x20/0x20
[ 2347.013074]  [<ffffffff816a1f1d>] mempool_free_slab+0x1d/0x30
[ 2347.013074]  [<ffffffff816a3044>] mempool_free+0xd4/0x1d0
[ 2347.013074]  [<ffffffff82c1084f>] bio_free+0xef/0x1b0
[ 2347.013074]  [<ffffffff82c109a8>] bio_put+0x98/0xc0
[ 2347.013074]  [<ffffffff81ad88bf>] ext4_end_bio+0x11f/0x460
[ 2347.013074]  [<ffffffff82c30a31>] ? blk_account_io_completion+0x2f1/0x410
[ 2347.013074]  [<ffffffff82c0bc89>] ? bio_advance+0x109/0x380
[ 2347.013074]  [<ffffffff81ad87a0>] ? ext4_put_io_end_defer+0x2f0/0x2f0
[ 2347.013074]  [<ffffffff82c10b72>] bio_endio+0x1a2/0x200
[ 2347.013074]  [<ffffffff82c30d0c>] blk_update_request+0x1bc/0xc80
[ 2347.013074]  [<ffffffff83aa5bbd>] scsi_end_request+0x9d/0x5b0
[ 2347.013074]  [<ffffffff83aaf220>] scsi_io_completion+0x470/0x1340
[ 2347.013074]  [<ffffffff83b960ea>] ? sd_done+0x34a/0xab0
[ 2347.013074]  [<ffffffff83aaedb0>] ? scsi_unblock_requests+0x50/0x50
[ 2347.013074]  [<ffffffff83a99742>] ? scsi_handle_queue_ramp_up+0x332/0x430
[ 2347.013074]  [<ffffffff8126010a>] ? lapic_next_event+0x5a/0x90
[ 2347.013074]  [<ffffffff83a92f6c>] scsi_finish_command+0x3ac/0x530
[ 2347.013074]  [<ffffffff83aada19>] scsi_softirq_done+0x2a9/0x350
[ 2347.013074]  [<ffffffff8162e338>] ? irq_work_run_list+0x128/0x190
[ 2347.013074]  [<ffffffff82c50fc0>] ? blkdev_issue_zeroout+0x3b0/0x3b0
[ 2347.013074]  [<ffffffff82c51018>] __blk_mq_complete_request_remote+0x58/0x70
[ 2347.013074]  [<ffffffff81515e2f>] flush_smp_call_function_queue+0xdf/0x3e0
[ 2347.013074]  [<ffffffff81517b23>] generic_smp_call_function_single_interrupt+0x13/0x80
[ 2347.013074]  [<ffffffff8125a4df>] smp_call_function_single_interrupt+0x5f/0x80
[ 2347.013074]  [<ffffffff86a961ec>] call_function_single_interrupt+0x8c/0xa0
[ 2347.013074]  <EOI>  [<ffffffff8147179d>] ? lock_is_held+0x18d/0x1f0
[ 2347.013074]  [<ffffffff817e6b1d>] get_mem_cgroup_from_mm+0x2ad/0x4a0
[ 2347.013074]  [<ffffffff817e6870>] ? mem_cgroup_count_precharge_pte_range+0x530/0x530
[ 2347.013074]  [<ffffffff817f662a>] mem_cgroup_try_charge+0x17a/0x690
[ 2347.013074]  [<ffffffff8174030c>] handle_pte_fault+0x382c/0x4960
[ 2347.013074]  [<ffffffff81478690>] ? debug_check_no_locks_freed+0x3c0/0x3c0
[ 2347.013074]  [<ffffffff8173cae0>] ? do_set_pte+0x4d0/0x4d0
[ 2347.013074]  [<ffffffff814777e8>] ? mark_held_locks+0xc8/0x120
[ 2347.013074]  [<ffffffff814b4be7>] ? debug_lockdep_rcu_enabled+0x77/0x90
[ 2347.013074]  [<ffffffff817378da>] ? __pte_alloc+0x8a/0x2a0
[ 2347.013074]  [<ffffffff817379f2>] ? __pte_alloc+0x1a2/0x2a0
[ 2347.013074]  [<ffffffff86a941d2>] ? _raw_spin_unlock+0x22/0x30
[ 2347.013074]  [<ffffffff817379f7>] ? __pte_alloc+0x1a7/0x2a0
[ 2347.013074]  [<ffffffff817428ab>] handle_mm_fault+0xeab/0x11a0
[ 2347.013074]  [<ffffffff81741a94>] ? handle_mm_fault+0x94/0x11a0
[ 2347.013074]  [<ffffffff81290e67>] __do_page_fault+0x457/0xbb0
[ 2347.013074]  [<ffffffff8129170f>] trace_do_page_fault+0xdf/0x5b0
[ 2347.013074]  [<ffffffff81281c24>] do_async_page_fault+0x14/0xd0
[ 2347.013074]  [<ffffffff86a96fb8>] async_page_fault+0x28/0x30
[ 2347.013074] ---[ end trace de4bc2d95c3ed682 ]---

The instance was executing:

$ ./syz-execprog -cover=0 -repeat=0 -procs=20 -sandbox=none -threaded=0 -collide=0 fsync

fsync file contained:

mmap(&(0x7f0000000000)=nil, (0xa98000), 0x3, 0x32, 0xffffffffffffffff, 0x0)
r0 = open(&(0x7f0000001000+0x5dd)="2e2f636f6e74726f6c00", 0x50042, 0x41)
write(r0, &(0x7f0000a95000-0xbc4)="87c0af350ba1655c4b7092b149419c0f66233ca5a251076561b5abd986a5b040074ebc290063a4c7b971e6ad7c811232bf6a0d7e1f49529efe8a39daf29bab8fa4bc760e87bef7b7b2ab0e0587d6cb15672d5a6c49be2d5e10600068e28d340298f83eb1d4e8ee817f3d724570aa64e1a7c6cf40265b0ee7a0d548ad7de4161e64f07f501a91315d35342070ef9d465ba7d3b15393762d16374004c6b09db5ccac877d7a25af30a94bcb0e411addc989187b68870a277aa215b63f0d47b9956c46d4fe95b1b6451bf86b895d6e871514adb03c63ddb7e406e0fd23918d8a2c324f34d9fd93f420834cdfda3cccf95aaf27a1ec15e19d520c2f5c5c557a73ca3e86b45f5ed6954fb31c56109821cf326122cb4b24b73ed78eb5493fde2e2e49c141751a9eab90aa9bdaafd42ed651d0f2befd31037f675d7803a7b978315db58ee6e19926b195a9975dbd3c480d900de1919078a0e6404574bea4b0050f518114f6f5480e5a7e7523d944159da4abff79d7ad3a5b1177d9dbfdbcceef18027ee0130ac290ad3bc30934ae9dd4a813c21f00b198ba70a8724922ddab14469f50c023e323677843f6203add4ef27a352670b191955033f1855b18e08550a15eaa2ab6ca6ce1178f96cded08d9bdc1b80b837a4f5b5005015252c9a3aa95bf0d34a6f2e06e13cc02e601527cde5e15e710319b1792dc4e271f7f4ec32de027a863d3592e9a4cf38b41f15b4cc48d07c38216494b4eace7c111a2c6bf8363b29882ade97e34c17a577330c21154173095873121d93d4d6b404b8db9a9ca6b9ba14f4e5d1db6757f247c51ffae37c023f4c70e526c34aa0fd0a3eaf7a44df1cabdd495a240c683414c9d91e45156fa46ab60e837339bea5f62e3d6d9851e9b4254ec07c793d73abeb63f924ce3694a712b343e4b2189e1d9ffdac1946e88906f54a266db77c02078675f24f531e233eb11b4b8ee7d4f6d26a6a106803a463180af38be68ef436a38227305998a26f6fb053f52f1860a923d257737a335b656a1d7d67074f99f76e1365e8787ea149a320669dc79a434018afa181d4257428efccbb3bdb91892b78c7fd16a4a5c0547bef1317b4fc2b6a4736e2e56a89b5a0b479d2fc9eb47e100632cdd090d501cf2ebc8ad2f5e26e211785f5d532ee5a2e2a15cc7d766fbd6d1428cc4976c93e69765f65176ef49329812d231abae5c03b233ed334ec2b2ca0b405e84c041073d6ec1fc1ff661ed657dc119da53da242f8429906ca25d52d1467b0afebe85aeb3f5ed1346aa04f89757a21b2f4239065c9aa827b91b1fe4473a768397377ed0b796217d3633f75417a761bedc1ec9a636f2846c26abae368baaeb9bca7b4b96d8eadc7f280f6ca24b54e211fd70c1677a3ff879e6535db316b7ce002face5410a5f6963f7d7220db4101e5380816432ff5b3983c78cbf9c0bac45801a52fb904abdc4223b654f4e68c5a811dbe94bd0ada6a6691be746bba4cd34093c1c5f81581bc45321aa184797e602b57fa7adb8e5dc001f6ea010cc39ae145f60b0cf0c44b8c9b28e62eef8d725f8610b135a9a740e3fc9c9aaa58a96262454c48df872e90a75b6047c9a115eb2cd51014a80c56bf00643aa087596afdfd4344a9d642f3b601ab1c18e7b9b9f3d87c697b76750194f963c61a3c7bb6e167c1e6d2ef071c67f8f70350c88538f570b1a6d8edcccc28153f613d874bdd759f3fe4fc16f20a17d9de5545dde4921eb0cce71a4006a311b3ec887f0a344dd090a21a44a542ab2ec6b2db73274e694efb7a8c1c31b6ed179b30cc9d34ee32e2c777e7775b24765ea6dee3cb50a0f093153e7879b8d41c1ca6dfce1a35492b8a1e71c17747472c6a8ace5bb0d6d504ee1f3ab40df5115d8f9f29ac395a3b8bd781d603c0691c25218e369fce84444cdc4a92c7da207129b40837c6f477b80b063a5cacc566f60e232ff7045196c5c2f099452aa6c28527e30a8a57fefc37b12c2dfaa5b0f9b9db756b9b473082e58a8283e328878830711ddbce1882889526ce2c94c5e044b4ee77f45e8b350edfa5480e9aeca1b8bf323fa6dc2bef8bf535fcfb58fdbae951a3a837e72ed75c6d93a9872ce522ae59fa5cb0d0a87b2afb0909cf60a8df752b45f1e2e85738be93a9b80253963de51b0c55a132549d717bc210b724ee04094d304f3f6e940c127658a8feb549d401ce939ea569399eaec95b9f4cc1e62d231662b9e4a960c4e46a0e69bb3e58cd9dcefb1bf22933919c083071ce1235826205b74425dea71e6a358c9dccc9de1a138911e8b9cabf5bc854ff11245c37f783351cf5f63bfe2be96e446587580b418261c06889b1b578bd510296313d06e09ee806e4383c94f98365b6214775e5209c7817ab776275583d46807bc879ee25785c7bfda8f4b44772160786544d45fb99ebf5c26480f9258db832078d4ad3bc38e74fe98b0713f590a1e052c21b7da5c73000a41c7287b620b75b90fcdbc6bb75921ffbf7dcf99034d4fed17638dc1f5476c03f55a8f293b475851179e9268534f183055cb4932d12ba7142c26e0dcbc0c565558e90ac1b47efebf7e8e3a150c60bd67d7d0abf178340e81c6c33ec2623c62816a67d186af9224a9f0bc5830e0038edb1ceddac6aeff5573bec5a2e67394f2d5274e27bdc0c9d185415b441294e89e7b8b79d961ffcb8e8144facc5e0dbaf51c3c5c446337504f862e758cf5298aecc5b36e5728c4db23f11d0f54b0c01fc67a61dd475ef351f3d48075b364e4cc199a5e20721099c7a22cb0e90541ea6921084357fe93bff8d1c41d30102acf1980f25c968d29ffb40a8db4cb7f1963150da5a63e2f6102d51ce0e4d67dc676f92b57c3f63a30a9bab49df7415535efbe6bfebca006f82256ba31b664c1920c432feb49de0ddf16359cd83ac669aef34772129e188a42f1258a77c9bc018f72d747d9d3cad67f888db997314de064fbac068975e2585ea128c4ab77d1503615179b81aff0da5d70e92ea4cf2a1f368291c9e9ef4236b1dd6b2161e60da5e37a4698e5cc118ee8e42554607095f8842f7e2289d21f13c34d9585834e635c9f9073e59366d26893aad737ea39140165d1183bace746a770e948e340d340677bd11c9308d74b4f2e014b1ad0a01d56559c75eaa53709162e95e9b8b57174697d743b39806b0239bd2aa33f2a399ee42851ec1f098e78ed18fe10de6da1853a8908e48450296f8dc8975e3831574229878df774e3cdeb4bbd0512c170259624adbbb67e468d08e57d1983ce20758bc37b30cca05533597066bb9a5615ade7012c3c68460ac31057e34c0f2bb69881975d0373e188a0fb45398afd46c864eeb998be1cabc506457b5bacf015dc0e0592457e811b91db3e1916a5c83a4643629373859ac21eb4397408dc847f4e87c6ea62efd19bf1cfd6d34266e2e5d3efaaaa05e5ece5f9597e108cf85c174c478d26bfdbf3f450fa38591725ce8128a69245e2695ff45899c20c56703fbba2067527db0fc4f2bb57fe080ff7d3d15b2be430eb3d3bf1761e106a16fa246bfdaf3ed37638695776ddb065700e79296e9fc6940db23eb1d377e5a1b2f32202fc7df635fba8cf5ee52d71ce81198b32b8a60ba70d53a792d20440fbe485a73f725a2ad70e16dcbfc19e8c9ba476ea47ec5086b59294b1befcebc182701bc5280be12c016542490eec48f37159b869f00f8d16470d572ecaa57edb2ceff43e9b3e0aba24a8562a1b68650c3d9db26622cc40d0979f89ad6d646fe91e304b41a1740cad1087bbf7ad60363e7b652e67fb490a89565c3937aa6fbba5555bd01f7a1720d00fa5b1eb755adcb1dcb1b4bc078f1d98c33bd67774a340d595ca0154735052c6c8c7743349e49ad073eac191a0a2afab59a122a8a9becde5e6ec354c3441f024695f6960c4c49532d4b8ac80a7b9600bdd63e91dfdbe4945440f4745646382a02c6526eeea991a1f568bfad662d53ce57107183cd835307d9fd0cd345bd2d5fd6044823e4cc9dc1b6f91cd3d5cb0e6c4a84c49505d2bc3d749c648b614818b34ae067eb4ba4c75d9d98180fa33c9901bb60949c699375cd6bb08b8f09a4752b69ed505cc119890c9993101b6afc1d42e67df5fd470a8704b8a562180869857044bc86c2903a0bee050d9caa2564e5c0dd94cef010270708d22c875591d94caa2e759d01bbf4b6b01dedf5917e8df06d968cec25db17b9f570d88a2ca991595b0dd42bdf10950e159eb3b933b9ab7b2e6394e623652fd1d0ed9506f41e02869990e4973be997894a0284ccf1a1f23ec9b2a4f4c4f5a1e42a6becc14c4ccef4687cbb956dd6ef7f7a35d69dec96d0bf5c88295c51a46845b2775c7cab679694b63c181cb0af82f33398c97a39e9087b706e89e7f74b56bd9463169b5383b0befb93ae0b5a1c63adb294858407124b3481f42614430873232168bcda382f6b1bfc6175ed9a7abc7a92b58d494eaa94152fac3f17c979e16d88cad1ed940280aecac3c7ebb1e960f350cef0040696dd61e0d97e0792a26ef6240506c9ef2ad377b5d721b95fdee4b63e2e7db326569aaab11b03e889bc03e2797f1d31ef455f2992a82bff8ddc51788ddf5bfefc597dae62c5067ef2a56793aff89377c34b0a664c26df4450f97893c987407b76a8aebb1bff648801d2d551eeafcf86c493140f3fb40db3bc2aa36d01f5873891b54e9870ac2a231ca80aecd8d6d5ebd5219c0d1be8ff6c80efee154cf1137586b582814a405e32975c8c5151a25c2e4d7df81ac206652fe44384b9dadffdeea5df29b17cc1c23feb2600f801f38909da4d5a7547485684f2fc9a15189a186a30657329631ce2f9bb1dddc4449fb2509efbc7f3eb33e4630c9617b31481d7b5b36f10fce94f886ce19495ae77ed237b655eaf80bcd14169434779cc83bc2d066d2bc3e533167bce22f354a211eea9fcbcdadbb6049e6b50b9a335107c0c9f289ceb62a20010ae1936985366212331740755deede32f5bc91f3cb155a8ad854d9d3830cb33e0f5cf6488008175e61ea60d5ff548d9819c6633f699857fdc9550f5528371a5cca0239ec3e4a8edea8fa3d2231e99a654c80943a1b6108b8c8019a5709cca60b0cf12d1a0b1cf02e2080793993c1c223ed78a1c3ed5d663d66f5dc03fbcb1cd66fb2a158637bf15c7a13a3b64c3923e28673016caa57b2dd8917590bafcb6fd70a4a8396b325c9c7506c3c1d6fa29657b2993a94e01115d1e09fc3997774852751bebae6343bc163b2d3b49741e0c80875ae27955325832fd612a9db0833184d2e58461c66a9b2540865535d837c056b9040648df6df7679f37e8a750effb5243b634daab00cddb5dea333b1d8a2d65d7fc6ff2a78ba4251137480ad4c7cfb75126fe6b8e22d56aaf67747870bff6a265aa55ae493e3eafe39934fc97fab663dd7a162237d903048d0e84a6547c2629c1bc2dfff03c627839d97c0d4fd1816eacc3caaeab4556192f045364bfe6e8f13005201c4a347b56535d8eb03244481b86b6d96cf180c476235d33f0e44efc75db1ab744c8f349a49cf032ff7a0d343e585b73e821b77e4203c476973cb8089ffcdd259827808f5daffa9d7954584479b3bdc0e035af52b3a93c477a31a2394eb795002f331d2e9c1419c30a73359ade52c746188a4d345bcc074b77e825ca79db67e8810beb83254daac6bab901aaed39a2cf141693b28729ffc6e47f44db3f46a6c2cae25e154fb313ad924c0a637cfe34edf49845f391589cac96ba65749108ca7a35d54ab68187b5d4a32", 0x1001)
fdatasync(r0)
ftruncate(r0, 0x2)
write$fuse_notify_inval_entry(r0, &(0x7f0000a98000-0x20)={0x20, 0xffffffff, 0x0, 0xffffffffffffffe0, 0x1}, 0x20)

__tsan_init not found with gcc 8.0

Hi,
I got following problem when building ktsan-enabled linux with gcc 8.0 (in order to run it with syzkaller)

arch/x86/kernel/head64.o: In function `_GLOBAL__sub_I_00099_0_early_pmd_flags':
head64.c:(.text.startup+0x5): undefined reference to `__tsan_init'
arch/x86/kernel/head.o: In function `_GLOBAL__sub_I_00099_0_reserve_ebda_region':
head.c:(.text.startup+0x5): undefined reference to `__tsan_init'
init/built-in.o: In function `_GLOBAL__sub_I_00099_0___ksymtab_system_state':
main.c:(.text.startup+0x5): undefined reference to `__tsan_init'
init/built-in.o: In function `_GLOBAL__sub_I_00099_0_init_uts_ns':
version.c:(.text.startup+0x15): undefined reference to `__tsan_init'
init/built-in.o: In function `_GLOBAL__sub_I_00099_0_root_mountflags':
do_mounts.c:(.text.startup+0x25): undefined reference to `__tsan_init'
init/built-in.o:do_mounts_initrd.c:(.text.startup+0x35): more undefined references to `__tsan_init' follow

The patch of issue #190 does not help for this version of gcc.. Could you help me?
Thanks in advance for any advice.

BUG in depot_save_stack

I am getting the following BUGs on 1a0a02d:

------------[ cut here ]------------
kernel BUG at mm/mempolicy.c:1697!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 3 PID: 11267 Comm: syz-executor Not tainted 4.7.0-rc5+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff8800384444c0 ti: ffff880038dc0000 task.ti: ffff880038dc0000
RIP: 0010:[<ffffffff817a356e>]
 [<ffffffff817a356e>] policy_zonelist+0xbe/0x1a0 mm/mempolicy.c:1697
RSP: 0000:ffff880038dc76f0  EFLAGS: 00010097
RAX: ffff8800384444c0 RBX: ffff88006448a230 RCX: 00000000e41703bb
RDX: 0000000000000000 RSI: ffff88006448a230 RDI: ffff88006448a234
RBP: ffff880038dc7710 R08: 000000000000000c R09: 0000000000000000
R10: 0000000000000000 R11: ffffffff89f06360 R12: 0000000000000001
R13: 0000000002000000 R14: ffff880038445520 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88006d500000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000810000 CR3: 0000000063d7d000 CR4: 00000000000006e0
Stack:
 ffff88006448a230 0000000002000000 ffff8800384444c0 ffff880038445520
 ffff880038dc7778 ffffffff817a5158 ffffffff86c55e00 ffff880038dc77f0
 ffffffff86c55e00 ffff8800384444c0 ffff880000000000 0000000203dc7798
Call Trace:
 [<ffffffff817a5158>] alloc_pages_current+0xd8/0x4f0 mm/mempolicy.c:2070
 [<     inline     >] alloc_pages include/linux/gfp.h:468
 [<ffffffff82d8db6f>] depot_save_stack+0x4ff/0x5b0 lib/stackdepot.c:258
 [<ffffffff817b8951>] save_stack+0xb1/0xd0 mm/kasan/kasan.c:482
 [<     inline     >] set_track mm/kasan/kasan.c:488
 [<ffffffff817b90cb>] kasan_slab_free+0x9b/0xd0 mm/kasan/kasan.c:540
 [<     inline     >] __cache_free mm/slab.c:3551
 [<ffffffff817b62f6>] kmem_cache_free+0x76/0x310 mm/slab.c:3811
 [<ffffffff817a7723>] __mpol_put+0x33/0x40 mm/mempolicy.c:299
 [<     inline     >] mpol_put include/linux/mempolicy.h:67
 [<ffffffff8137ba63>] do_exit+0x16f3/0x2c80 kernel/exit.c:773
 [<ffffffff8137d168>] do_group_exit+0x108/0x330 kernel/exit.c:878
 [<ffffffff813a0634>] get_signal+0x634/0x15e0 kernel/signal.c:2307
 [<ffffffff811fa943>] do_signal+0x83/0x1f20 arch/x86/kernel/signal.c:783
 [<ffffffff81006695>] exit_to_usermode_loop+0x1a5/0x210 arch/x86/entry/common.c:229
 [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:264
 [<ffffffff8100885f>] syscall_return_slowpath+0x2bf/0x340 arch/x86/entry/common.c:329
 [<ffffffff86a94e9c>] entry_SYSCALL_64_fastpath+0xbf/0xc1 arch/x86/entry/entry_64.S:241
Code: 45 85 ed 4a 8b 14 e5 80 8f f4 88 0f 95 c0 48 69 c0 10 14 00 00 5b 41 5c 41 5d 48 8d 84 02 c0 26 00 00 41 5e 5d c3 e8 72 22 df ff <0f> 0b e8 6b 22 df ff 48 8d 7b 06 48 b8 00 00 00 00 00 fc ff df
RIP  [<ffffffff817a356e>] policy_zonelist+0xbe/0x1a0 mm/mempolicy.c:1697
 RSP <ffff880038dc76f0>
---[ end trace fa599a524816f07d ]---

do_exit frees current mempolicy here:

    mpol_put(tsk->mempolicy);

And that same free tries to allocate pages in depot_save_stack and accesses the freed mempolicy.

Wiki has invalid link to kernel doc.

On the https://github.com/google/kasan/wiki check link in "More extensive documentation: https://www.kernel.org/doc/Documentation/kasan.txt"

Probably should be https://kernel.org/doc/html/latest/dev-tools/kasan.html
I have no access to the wiki to fix.

(Cosmetic) kt_shadow_clear is dead code and seems broken

kt_shadow_clear appears to be getting the end of the shadow region wrong:

void kt_shadow_clear(uptr_t addr, size_t size)
{
	void *shadow_beg;
	void *shadow_end;
	size_t shadow_size;

	shadow_beg = kt_shadow_get(addr);
	shadow_end = kt_shadow_get(addr);

I'm guessing it should say something like shadow_end = shadow_begin + size; or shadow_end = kt_shadow_get(addr + size); instead. But in either case it's never called, so maybe just scrap it?

Enormous number of sync objects

Most syncs created at (totally 2300000):
 645794 [<     inlined    >] get_page_from_freelist+0x6ca/0xe20 atomic_read ./arch/x86/include/asm/atomic.h:31
 645794 [<     inlined    >] get_page_from_freelist+0x6ca/0xe20 check_new_page mm/page_alloc.c:1299
 645794 [<     inlined    >] get_page_from_freelist+0x6ca/0xe20 prep_new_page mm/page_alloc.c:1327
 645794 [<ffffffff811d583a>] get_page_from_freelist+0x6ca/0xe20 mm/page_alloc.c:2597
 608791 [<     inlined    >] __rmqueue+0x246/0x770 __SetPageBuddy ./arch/x86/include/asm/atomic.h:47
 608791 [<     inlined    >] __rmqueue+0x246/0x770 set_page_order mm/page_alloc.c:550
 608791 [<     inlined    >] __rmqueue+0x246/0x770 expand mm/page_alloc.c:1283
 608791 [<     inlined    >] __rmqueue+0x246/0x770 __rmqueue_smallest mm/page_alloc.c:1384
 608791 [<ffffffff811d4c46>] __rmqueue+0x246/0x770 mm/page_alloc.c:1660
 334873 [<     inlined    >] vunmap_page_range+0x27c/0x320 native_ptep_get_and_clear ./arch/x86/include/asm/pgtable_64.h:76
 334873 [<     inlined    >] vunmap_page_range+0x27c/0x320 ptep_get_and_clear ./arch/x86/include/asm/pgtable.h:749
 334873 [<     inlined    >] vunmap_page_range+0x27c/0x320 vunmap_pte_range mm/vmalloc.c:65
 334873 [<     inlined    >] vunmap_page_range+0x27c/0x320 vunmap_pmd_range mm/vmalloc.c:82
 334873 [<     inlined    >] vunmap_page_range+0x27c/0x320 vunmap_pud_range mm/vmalloc.c:98
 334873 [<ffffffff8122044c>] vunmap_page_range+0x27c/0x320 mm/vmalloc.c:113
 201060 [<     inlined    >] inet_twsk_purge+0x6e/0x1f0 __read_once_size include/linux/compiler.h:241
 201060 [<ffffffff81bfd5de>] inet_twsk_purge+0x6e/0x1f0 net/ipv4/inet_timewait_sock.c:295
  60067 [<     inlined    >] _raw_spin_lock+0x50/0x70 __raw_spin_lock include/linux/spinlock_api_smp.h:158
  60067 [<ffffffff81eb10e0>] _raw_spin_lock+0x50/0x70 kernel/locking/spinlock.c:151
  30868 [<     inlined    >] get_page_from_freelist+0x69f/0xe20 page_mapcount ./arch/x86/include/asm/atomic.h:31
  30868 [<     inlined    >] get_page_from_freelist+0x69f/0xe20 check_new_page mm/page_alloc.c:1295
  30868 [<     inlined    >] get_page_from_freelist+0x69f/0xe20 prep_new_page mm/page_alloc.c:1327
  30868 [<ffffffff811d580f>] get_page_from_freelist+0x69f/0xe20 mm/page_alloc.c:2597
  30308 [<     inlined    >] __d_lookup+0x96/0x2c0 __read_once_size include/linux/compiler.h:241
  30308 [<     inlined    >] __d_lookup+0x96/0x2c0 hlist_bl_first_rcu include/linux/rculist_bl.h:23
  30308 [<ffffffff812884c6>] __d_lookup+0x96/0x2c0 fs/dcache.c:2310
  26121 [<     inlined    >] __d_instantiate+0xc9/0x210 __read_once_size include/linux/compiler.h:240
  26121 [<     inlined    >] __d_instantiate+0xc9/0x210 __d_set_inode_and_type fs/dcache.c:283
  26121 [<ffffffff81283039>] __d_instantiate+0xc9/0x210 fs/dcache.c:1765

failed to boot the kernel

I compiled and ran the kernel as told by Wiki on ktsan branch, but I got a lot of racy errors.
below is one example:

[ OK ] Started Apply Kernel Variables.
[ 19.262492] systemd-journald[1028]: /dev/kmsg buffer overrun, some messages lost.
Starting Raise network interfaces...
[ 19.436711] ==================================================================
[ 19.437699] ThreadSanitizer: data-race in deadline_remove_request
[ 19.437699]
[ 19.438723] Write at 0x000000004f677744 of size 8 by thread 1036 on CPU 3:
[ 19.439652] [<00000000cc0d35a4>] deadline_remove_request+0x73/0x180
[ 19.440511] [<000000005f56ced5>] dd_dispatch_request+0x372/0x440
[ 19.441336] [<000000009b55b522>] blk_mq_do_dispatch_sched+0x16e/0x1e0
[ 19.442226] [<000000001dbed43a>] blk_mq_sched_dispatch_requests+0x26a/0x310
[ 19.443156] [<00000000ef95a321>] __blk_mq_run_hw_queue+0x7a/0x110
[ 19.443997] [<000000004f52a10a>] __blk_mq_delay_run_hw_queue+0x252/0x260
[ 19.444916] [<00000000bf2a6093>] blk_mq_run_hw_queue+0xb8/0x160
[ 19.445708] [<000000003116cc50>] blk_mq_get_tag+0x385/0x530
[ 19.446490] [<000000000832a0a5>] blk_mq_get_request+0x2d1/0x8e0
[ 19.447295] [<00000000584f8d99>] blk_mq_make_request+0x1ac/0x870
[ 19.448262] [<00000000a21bef69>] generic_make_request+0x37a/0x790
[ 19.449157] [<00000000ded495f6>] submit_bio+0xb0/0x210
[ 19.450029] [<000000005c1e03ad>] ext4_mpage_readpages+0x341/0xc70
[ 19.451003] [<000000001d31573e>] ext4_readpages+0x6b/0x90
[ 19.451896] [<0000000088f4e301>] read_pages+0x8c/0x230
[ 19.452704] [<000000005b03acdc>] __do_page_cache_readahead+0x1f5/0x270
[ 19.454086] [<00000000d0165eab>] ondemand_readahead+0x276/0x450
[ 19.455031] [<00000000dc812ddf>] page_cache_sync_readahead+0x5b/0x90
[ 19.455972] [<00000000ab164b97>] generic_file_read_iter+0xd19/0x1140
[ 19.456902] [<000000000b12c675>] ext4_file_read_iter+0x89/0xa0
[ 19.457774] [<0000000082eece19>] __vfs_read+0x23a/0x300
[ 19.458549] [<00000000a399db2b>] vfs_read+0xab/0x1d0
[ 19.459301] [<000000008ae39ffa>] ksys_read+0x74/0xf0
[ 19.460046] [<00000000558d45a4>] __x64_sys_read+0x43/0x60
[ 19.460848] [<0000000095adb388>] do_syscall_64+0x6f/0x1a0
[ 19.461668] [<000000005349d50d>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 19.462656]
[ 19.462900] Previous read at 0x000000004f677744 of size 8 by thread 65534 on CPU 1:
[ 19.463756] [<00000000a617d697>] dd_has_work+0x7e/0xc0
[ 19.464342] [<00000000c8a8c6da>] blk_mq_run_hw_queue+0x136/0x160
[ 19.465013] [<00000000beea10a9>] blk_mq_run_hw_queues+0x6e/0x90
[ 19.465686] [<000000009c0bceac>] scsi_end_request+0x29b/0x2b0
[ 19.466583] [<000000005c77fd58>] scsi_io_completion+0xd7/0x9d0
[ 19.467445] [<0000000057d1586a>] scsi_finish_command+0x17e/0x1e0
[ 19.468335] [<00000000d07a695f>] scsi_softirq_done+0x1ac/0x1f0
[ 19.469260] [<00000000823edf6f>] blk_done_softirq+0x14b/0x1a0
[ 19.470450] [<000000007e424ad0>] __do_softirq+0x110/0x39a
[ 19.471602] [<000000009d4c61e5>] call_function_single_interrupt+0xf/0x20
[ 19.472787] [<0000000037e37d37>] arch_cpu_idle+0x21/0x30
[ 19.473449] [<00000000637a3e6a>] do_idle+0x22c/0x320
[ 19.474132]
[ 19.474390] Mutexes locked by thread 1036:
[ 19.475028] Mutex 145142 is locked here:
[ 19.475649] [<00000000c108c427>] _raw_spin_lock+0x3e/0x50
[ 19.476760] [<000000001a65c4ec>] dd_dispatch_request+0x65/0x440
[ 19.477746] [<000000009b55b522>] blk_mq_do_dispatch_sched+0x16e/0x1e0
[ 19.478684] [<000000001dbed43a>] blk_mq_sched_dispatch_requests+0x26a/0x310
[ 19.479695] [<00000000ef95a321>] __blk_mq_run_hw_queue+0x7a/0x110
[ 19.480592] [<000000004f52a10a>] __blk_mq_delay_run_hw_queue+0x252/0x260
[ 19.481576] [<00000000bf2a6093>] blk_mq_run_hw_queue+0xb8/0x160
[ 19.482458] [<000000003116cc50>] blk_mq_get_tag+0x385/0x530
[ 19.483237] [<000000000832a0a5>] blk_mq_get_request+0x2d1/0x8e0
[ 19.484060] [<00000000584f8d99>] blk_mq_make_request+0x1ac/0x870
[ 19.484890] [<00000000a21bef69>] generic_make_request+0x37a/0x790
[ 19.485740] [<00000000ded495f6>] submit_bio+0xb0/0x210
[ 19.486506] [<000000005c1e03ad>] ext4_mpage_readpages+0x341/0xc70
[ 19.487533] [<000000001d31573e>] ext4_readpages+0x6b/0x90
[ 19.488502] [<0000000088f4e301>] read_pages+0x8c/0x230
[ 19.489340] [<000000005b03acdc>] __do_page_cache_readahead+0x1f5/0x270
[ 19.490126] [<00000000d0165eab>] ondemand_readahead+0x276/0x450
[ 19.490835] [<00000000dc812ddf>] page_cache_sync_readahead+0x5b/0x90
[ 19.491590] [<00000000ab164b97>] generic_file_read_iter+0xd19/0x1140
[ 19.492352] [<000000000b12c675>] ext4_file_read_iter+0x89/0xa0
[ 19.493051] [<0000000082eece19>] __vfs_read+0x23a/0x300
[ 19.493678] [<00000000a399db2b>] vfs_read+0xab/0x1d0
[ 19.494306] [<000000008ae39ffa>] ksys_read+0x74/0xf0
[ 19.494915] [<00000000558d45a4>] __x64_sys_read+0x43/0x60
[ 19.495557] [<0000000095adb388>] do_syscall_64+0x6f/0x1a0
[ 19.496202] [<000000005349d50d>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Still, there are many other similar mistakes.

Print information about globals

If a race happens on global, we need to print description of the global: name, address, size, offset.

Mutex unlocked in another thread

------------[ cut here ]------------
kernel BUG at mm/ktsan/sync_mtx.c:51!
invalid opcode: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 9307 Comm: trinity-c11 Not tainted 4.2.0-tsan #669
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880196333280 ti: ffff8800b0d58000 task.ti: ffff8800b0d58000
RIP: 0010:[<ffffffff81254e1e>]  [<ffffffff81254e1e>] kt_mtx_pre_unlock+0xae/0xc0
RSP: 0018:ffff8800b0d5bb58  EFLAGS: 00010002
RAX: ffff88022bf2b298 RBX: ffff88019ac282c0 RCX: 0000000000000000
RDX: 000000000000014b RSI: 0000000000000000 RDI: ffff88063f9abfe0
RBP: ffff8800b0d5bb78 R08: ffff88028e24fff0 R09: ffffffff81cb2402
R10: ffff88019ac282c0 R11: ffffffff81eaffd8 R12: 0000000000000001
R13: ffff8800bb0c2818 R14: ffffffff81ead0f2 R15: ffff88019ac282c0
FS:  00007f26abc3c700(0000) GS:ffff88063fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 00000000af660000 CR4: 00000000000006f0
Stack:
 0000000000000002 0000000000000001 ffff8800bb0c2818 ffffffff81ead0f2
 ffff8800b0d5bbb8 ffffffff81250297 ffff8800b0d5bbb8 ffff8800bb0c2818
 ffff8800bb0c2540 ffff8800bb4ebd00 ffff8800b0d5bcf0 000000001ac5a458
Call Trace:
 [<ffffffff81ead0f2>] ? mutex_unlock+0x22/0x50 kernel/locking/mutex.c:432
 [<ffffffff81250297>] ktsan_mtx_pre_unlock+0x127/0x130 mm/ktsan/ktsan.c:413
 [<ffffffff81ead0f2>] mutex_unlock+0x22/0x50 kernel/locking/mutex.c:432
 [<ffffffff81cb2310>] unix_dgram_recvmsg+0x530/0x7f0 net/unix/af_unix.c:1965
 [<     inlined    >] ? sock_recvmsg+0x58/0x90 sock_recvmsg_nosec net/socket.c:712
 [<ffffffff81b35038>] ? sock_recvmsg+0x58/0x90 net/socket.c:720
 [<     inlined    >] sock_recvmsg+0x6a/0x90 sock_recvmsg_nosec net/socket.c:712
 [<ffffffff81b3504a>] sock_recvmsg+0x6a/0x90 net/socket.c:720
 [<ffffffff81b35169>] sock_read_iter+0xf9/0x150 net/socket.c:797
 [<     inlined    >] do_readv_writev+0x289/0x420 do_iter_readv_writev fs/read_write.c:664
 [<ffffffff8125e219>] do_readv_writev+0x289/0x420 fs/read_write.c:808
 [<ffffffff81b35070>] ? sock_recvmsg+0x90/0x90 net/socket.c:721 (discriminator 4)
 [<     inlined    >] ? SyS_readv+0x6b/0x140 SYSC_readv fs/read_write.c:860
 [<ffffffff8125f72b>] ? SyS_readv+0x6b/0x140 fs/read_write.c:852
 [<ffffffff8125e3df>] ? vfs_readv+0x2f/0x80 fs/read_write.c:829
 [<ffffffff8125e40a>] vfs_readv+0x5a/0x80 fs/read_write.c:834
 [<     inlined    >] SyS_readv+0x6b/0x140 SYSC_readv fs/read_write.c:860
 [<ffffffff8125f72b>] SyS_readv+0x6b/0x140 fs/read_write.c:852
 [<ffffffff81eb062e>] entry_SYSCALL_64_fastpath+0x12/0x71 arch/x86/entry/entry_64.S:186
Code: be 50 01 00 00 48 c7 c7 48 83 1c 82 e8 ac 4f e3 ff c6 05

followed by

------------[ cut here ]------------
kernel BUG at mm/ktsan/thr.c:82!
invalid opcode: 0000 [#2] SMP
Modules linked in:
CPU: 3 PID: 2699 Comm: trinity-main Tainted: G      D         4.2.0-tsan #669
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880195df0f40 ti: ffff8800ba71c000 task.ti: ffff8800ba71c000
RIP: 0010:[<ffffffff81258d05>]  [<ffffffff81258d05>] kt_thr_destroy+0x175/0x1f0
RSP: 0018:ffff8800ba71fd20  EFLAGS: 00010002
RAX: 0000000000000000 RBX: 0000000000000296 RCX: 0000000000000001
RDX: 0000000000000001 RSI: ffff88019ac282c0 RDI: ffff8801ad985400
RBP: ffff8800ba71fd48 R08: 0000000000000000 R09: ffff8801ad985400
R10: ffffffff810c430e R11: ffffffff81eb032c R12: ffff880196333ae8
R13: ffff8801ad985400 R14: ffff880195df0f40 R15: 0000000000000040
FS:  00007f26abc3c700(0000) GS:ffff88063fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 00000000bafbd000 CR4: 00000000000006e0
Stack:
 ffffffff81250b69 ffff880196333280 ffff88063fd95240 ffff880196333280
 ffff88018a1ceac0 ffff8800ba71fd88 ffffffff810c4320 ffff880193566800
 ffff88063fd95240 ffff880193566800 ffff88018a1ceac0 00000000000006e0
Call Trace:
 [<ffffffff81250b69>] ? ktsan_thr_destroy+0xa9/0xf0 mm/ktsan/ktsan.c:278 (discriminator 7)
 [<ffffffff810c4320>] finish_task_switch+0x210/0x240 kernel/sched/core.c:2501
 [<     inlined    >] __schedule+0x40e/0xb70 context_switch kernel/sched/core.c:2614
 [<ffffffff81ea9d9e>] __schedule+0x40e/0xb70 kernel/sched/core.c:3076
 [<     inlined    >] ? do_wait+0x32e/0x410 __raw_read_unlock include/linux/rwlock_api_smp.h:254
 [<ffffffff8108ee4e>] ? do_wait+0x32e/0x410 kernel/exit.c:1499
 [<ffffffff81eaa532>] schedule+0x32/0x80 kernel/sched/core.c:3106 (discriminator 1)
 [<ffffffff8108ee99>] do_wait+0x379/0x410 kernel/exit.c:1506
 [<     inlined    >] SyS_wait4+0xe5/0x160 SYSC_wait4 kernel/exit.c:1615
 [<ffffffff8108f475>] SyS_wait4+0xe5/0x160 kernel/exit.c:1584
 [<ffffffff8108b140>] ? task_stopped_code+0x90/0x90 kernel/exit.c:1127
 [<ffffffff81eb062e>] entry_SYSCALL_64_fastpath+0x12/0x71 arch/x86/entry/entry_64.S:186
Code: 89 df e8 cf cc ff ff 8b 93 ac 68 08 00 85 d2 0f 84 02 ff ff ff 48 c7 c2 c7 88 1c 82 31 f6 48 89 df e8 b0 cc ff ff e9 ec fe ff ff <0f> 0b 0f 0b 80 3d a1 1c 2b 01 00 74 38 80 3d 98 1c 2b 01 00 0f
RIP  [<ffffffff81258d05>] kt_thr_destroy+0x175/0x1f0 mm/ktsan/thr.c:88
 RSP <ffff8800ba71fd20>
---[ end trace 59138c397ec32637 ]---

Bad page state caused by mlock / munlock

To reproduce run "trinity --dangerous -q -m -C 16 -c mlock -c munlock -c madvise".

BUG: Bad page state in process trinity-c9  pfn:18e40a
page:ffffea0006390280 count:0 mapcount:0 mapping:          (null) index:0x1
flags: 0x20000000028000c(referenced|uptodate|swapbacked|mlocked)
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
bad because of flags:
flags: 0x200000(mlocked)
Modules linked in:
CPU: 2 PID: 7107 Comm: trinity-c9 Not tainted 4.2.0-tsan #670
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffffffff821c3980 0000000000000000 000000010003e268 ffff88018f7c3948
 ffffffff81ea1167 0000000000000000 ffffea0006390280 ffff88018f7c3978
 ffffffff811cf435 ffffffff821c3980 ffffea0006390280 0000000000000001
Call Trace:
 [<     inlined    >] dump_stack+0x63/0x81 __dump_stack lib/dump_stack.c:15
 [<ffffffff81ea1167>] dump_stack+0x63/0x81 lib/dump_stack.c:50
 [<ffffffff811cf435>] bad_page+0x115/0x1a0 mm/page_alloc.c:409
 [<     inlined    >] free_pages_prepare+0x2ff/0x330 free_pages_check mm/page_alloc.c:731
 [<ffffffff811d07af>] free_pages_prepare+0x2ff/0x330 mm/page_alloc.c:922
 [<     inlined    >] ? free_hot_cold_page+0x3f/0x2b0 page_zone include/linux/mm.h:881
 [<ffffffff811d3cff>] ? free_hot_cold_page+0x3f/0x2b0 mm/page_alloc.c:1902
 [<ffffffff811d3d11>] free_hot_cold_page+0x51/0x2b0 mm/page_alloc.c:1908
 [<ffffffff811d3faf>] ? free_hot_cold_page_list+0x3f/0x110 mm/page_alloc.c:1954
 [<     inlined    >] ? free_hot_cold_page_list+0x89/0x110 atomic_read ./arch/x86/include/asm/atomic.h:31 (discriminator 3)
 [<     inlined    >] ? free_hot_cold_page_list+0x89/0x110 static_key_count include/linux/jump_label.h:99 (discriminator 3)
 [<     inlined    >] ? free_hot_cold_page_list+0x89/0x110 static_key_false include/linux/jump_label.h:164 (discriminator 3)
 [<     inlined    >] ? free_hot_cold_page_list+0x89/0x110 trace_mm_page_free_batched include/trace/events/kmem.h:195 (discriminator 3)
 [<ffffffff811d3ff9>] ? free_hot_cold_page_list+0x89/0x110 mm/page_alloc.c:1955 (discriminator 3)
 [<ffffffff811d3fcf>] free_hot_cold_page_list+0x5f/0x110 mm/page_alloc.c:1956 (discriminator 3)
 [<ffffffff811dee11>] release_pages+0x151/0x300 mm/swap.c:967
 [<ffffffff811dfb73>] __pagevec_release+0x43/0x60 mm/swap.c:984
 [<     inlined    >] shmem_undo_range+0x4fa/0x9d0 pagevec_release include/linux/pagevec.h:69
 [<ffffffff811f00aa>] shmem_undo_range+0x4fa/0x9d0 mm/shmem.c:446
 [<ffffffff81255cf2>] ? kt_tab_access+0x122/0x1c0 mm/ktsan/tab.c:129
 [<     inlined    >] ? unmap_mapping_range+0x1bd/0x1d0 unmap_mapping_range_tree mm/memory.c:2370
 [<ffffffff8120c05d>] ? unmap_mapping_range+0x1bd/0x1d0 mm/memory.c:2432
 [<ffffffff810dd64b>] ? up_write+0x4b/0x60 kernel/locking/rwsem.c:112
 [<ffffffff8124bb48>] ? kt_func_exit+0x18/0x60 mm/ktsan/func.c:14
 [<ffffffff811f2a85>] ? shmem_fallocate+0x555/0x6e0 mm/shmem.c:2086
 [<ffffffff8124bad9>] ? kt_func_entry+0x19/0x70 mm/ktsan/func.c:5
 [<     inlined    >] ? shmem_fallocate+0x527/0x6e0 __raw_spin_unlock include/linux/spinlock_api_smp.h:168
 [<     inlined    >] ? shmem_fallocate+0x527/0x6e0 spin_unlock include/linux/spinlock.h:357
 [<ffffffff811f2a57>] ? shmem_fallocate+0x527/0x6e0 mm/shmem.c:2081
 [<ffffffff811f05af>] shmem_truncate_range+0x2f/0x60 mm/shmem.c:540
BUG: Bad page state in process trinity-c6  pfn:18e413
page:ffffea00063904c0 count:0 mapcount:0 mapping:          (null) index:0xd
flags: 0x20000000028000c(referenced|uptodate|swapbacked|mlocked)
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
bad because of flags:
flags: 0x200000(mlocked)
Modules linked in:
 [<ffffffff811f2a85>] shmem_fallocate+0x555/0x6e0 mm/shmem.c:2086
 [<ffffffff8124ab51>] ? kt_access+0x81/0x460 mm/ktsan/access.c:107
 [<ffffffff8124bb48>] ? kt_func_exit+0x18/0x60 mm/ktsan/func.c:14
 [<ffffffff81259aeb>] ? vfs_fallocate+0x1cb/0x310 fs/open.c:303
 [<ffffffff81259b00>] vfs_fallocate+0x1e0/0x310 fs/open.c:303
 [<     inlined    >] SyS_madvise+0x378/0x760 madvise_remove mm/madvise.c:326
 [<     inlined    >] SyS_madvise+0x378/0x760 madvise_vma mm/madvise.c:378
 [<     inlined    >] SyS_madvise+0x378/0x760 SYSC_madvise mm/madvise.c:528
 [<ffffffff81226b18>] SyS_madvise+0x378/0x760 mm/madvise.c:459
 [<ffffffff81eb066e>] entry_SYSCALL_64_fastpath+0x12/0x71 arch/x86/entry/entry_64.S:186
CPU: 0 PID: 7104 Comm: trinity-c6 Not tainted 4.2.0-tsan #670
Disabling lock debugging due to kernel taint
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffffffff821c3980 0000000000000000 0000000000000001 ffff8800b775f948
 ffffffff81ea1167 0000000000000000 ffffea00063904c0 ffff8800b775f978
 ffffffff811cf435 ffffffff821c3980 ffffea00063904c0 0000000000000001
Call Trace:
 [<     inlined    >] dump_stack+0x63/0x81 __dump_stack lib/dump_stack.c:15
 [<ffffffff81ea1167>] dump_stack+0x63/0x81 lib/dump_stack.c:50
 [<ffffffff811cf435>] bad_page+0x115/0x1a0 mm/page_alloc.c:409
 [<     inlined    >] free_pages_prepare+0x2ff/0x330 free_pages_check mm/page_alloc.c:731
 [<ffffffff811d07af>] free_pages_prepare+0x2ff/0x330 mm/page_alloc.c:922
 [<     inlined    >] ? free_hot_cold_page+0x3f/0x2b0 page_zone include/linux/mm.h:881
 [<ffffffff811d3cff>] ? free_hot_cold_page+0x3f/0x2b0 mm/page_alloc.c:1902
 [<ffffffff811d3d11>] free_hot_cold_page+0x51/0x2b0 mm/page_alloc.c:1908
 [<ffffffff811d3faf>] ? free_hot_cold_page_list+0x3f/0x110 mm/page_alloc.c:1954
 [<     inlined    >] ? free_hot_cold_page_list+0x89/0x110 atomic_read ./arch/x86/include/asm/atomic.h:31 (discriminator 3)
 [<     inlined    >] ? free_hot_cold_page_list+0x89/0x110 static_key_count include/linux/jump_label.h:99 (discriminator 3)
 [<     inlined    >] ? free_hot_cold_page_list+0x89/0x110 static_key_false include/linux/jump_label.h:164 (discriminator 3)
 [<     inlined    >] ? free_hot_cold_page_list+0x89/0x110 trace_mm_page_free_batched include/trace/events/kmem.h:195 (discriminator 3)
 [<ffffffff811d3ff9>] ? free_hot_cold_page_list+0x89/0x110 mm/page_alloc.c:1955 (discriminator 3)
 [<ffffffff811d3fcf>] free_hot_cold_page_list+0x5f/0x110 mm/page_alloc.c:1956 (discriminator 3)
 [<ffffffff811dee11>] release_pages+0x151/0x300 mm/swap.c:967
 [<ffffffff811dfb73>] __pagevec_release+0x43/0x60 mm/swap.c:984
 [<     inlined    >] shmem_undo_range+0x4fa/0x9d0 pagevec_release include/linux/pagevec.h:69
 [<ffffffff811f00aa>] shmem_undo_range+0x4fa/0x9d0 mm/shmem.c:446
 [<ffffffff81255cf2>] ? kt_tab_access+0x122/0x1c0 mm/ktsan/tab.c:129
 [<ffffffff811f05af>] shmem_truncate_range+0x2f/0x60 mm/shmem.c:540
 [<ffffffff811f2a85>] shmem_fallocate+0x555/0x6e0 mm/shmem.c:2086
 [<ffffffff8124ab51>] ? kt_access+0x81/0x460 mm/ktsan/access.c:107
 [<ffffffff8124bb48>] ? kt_func_exit+0x18/0x60 mm/ktsan/func.c:14
 [<ffffffff81259aeb>] ? vfs_fallocate+0x1cb/0x310 fs/open.c:303
 [<ffffffff81259b00>] vfs_fallocate+0x1e0/0x310 fs/open.c:303
 [<     inlined    >] SyS_madvise+0x378/0x760 madvise_remove mm/madvise.c:326
 [<     inlined    >] SyS_madvise+0x378/0x760 madvise_vma mm/madvise.c:378
 [<     inlined    >] SyS_madvise+0x378/0x760 SYSC_madvise mm/madvise.c:528
 [<ffffffff81226b18>] SyS_madvise+0x378/0x760 mm/madvise.c:459
 [<ffffffff81eb066e>] entry_SYSCALL_64_fastpath+0x12/0x71 arch/x86/entry/entry_64.S:186

KTSAN: maximum number of threads is reached,how to deal with?

When I do syzkaller to do test, I find thread_create num suddenly increases to the max, and the thread_destroy num increases slowly, how to deal with the problem?

missed synchronization due to IPIs

Here is a false report (on commit 5b3aef6c2ea1):

ThreadSanitizer: data-race in kt_memblock_free

Write of size 8 by thread T544 (K1133, CPU2):
 [<ffffffff81256c40>] kt_memblock_free+0xd0/0x140 mm/ktsan/memblock.c:92
 [<ffffffff81256937>] ktsan_memblock_free+0xb7/0xf0 mm/ktsan/ktsan.c:365 (discriminator 7)
 [<     inlined    >] __cache_free mm/slab.c:3384
 [<ffffffff81246992>] kmem_cache_free+0x92/0x480 mm/slab.c:3562
 [<ffffffff8150ebb0>] free_request_struct+0x30/0x40 block/blk-core.c:597
 [<ffffffff811d1a85>] mempool_free+0x75/0x130 mm/mempool.c:439
 [<     inlined    >] blk_free_request block/blk-core.c:832
 [<ffffffff8150fd3b>] __blk_put_request+0x11b/0x200 block/blk-core.c:1424
 [<ffffffff81516f30>] blk_finish_request+0x140/0x1a0 block/blk-core.c:2646
 [<ffffffff8189e454>] scsi_end_request+0x1a4/0x300 drivers/scsi/scsi_lib.c:729
 [<ffffffff818a2067>] scsi_io_completion+0x137/0x8f0 drivers/scsi/scsi_lib.c:914
 [<ffffffff8189459e>] scsi_finish_command+0x15e/0x1f0 drivers/scsi/scsi.c:607
 [<ffffffff818a12e2>] scsi_softirq_done+0x182/0x1d0 drivers/scsi/scsi_lib.c:1650
 [<ffffffff81522456>] blk_done_softirq+0x136/0x160 block/blk-softirq.c:35
 [<ffffffff81091d7e>] __do_softirq+0xbe/0x300 kernel/softirq.c:273
 [<     inlined    >] invoke_softirq kernel/softirq.c:350
 [<ffffffff81092160>] irq_exit+0xb0/0xc0 kernel/softirq.c:391
 [<     inlined    >] exiting_irq ./arch/x86/include/asm/apic.h:655
 [<ffffffff8105a520>] smp_call_function_single_interrupt+0x60/0x70 arch/x86/kernel/smp.c:317
 [<ffffffff81eeb81b>] call_function_single_interrupt+0x6b/0x70 arch/x86/entry/entry_64.S:803
 [<     inlined    >] atomic_set ./arch/x86/include/asm/atomic.h:47
 [<     inlined    >] osq_lock_init include/linux/osq_lock.h:29
 [<ffffffff810de949>] __mutex_init+0x69/0x80 kernel/locking/mutex.c:59
 [<ffffffff811c846c>] perf_event_init_task+0x6c/0x420 kernel/events/core.c:8876
 [<ffffffff81087746>] copy_process.part.44+0x9e6/0x2cd0 kernel/fork.c:1428
 [<     inlined    >] copy_process kernel/fork.c:1270
 [<ffffffff81089c63>] _do_fork+0x103/0x540 kernel/fork.c:1718
 [<     inlined    >] SYSC_clone kernel/fork.c:1829
 [<ffffffff8108a1bf>] SyS_clone+0x3f/0x60 kernel/fork.c:1823
 [<ffffffff81eea4ae>] entry_SYSCALL_64_fastpath+0x12/0x71 arch/x86/entry/entry_64.S:186

Previous write of size 8 by thread T438 (K985, CPU3):
 [<ffffffff8156d629>] llist_add_batch+0x29/0x60 lib/llist.c:44 (discriminator 16)
 [<     inlined    >] llist_add include/linux/llist.h:180
 [<ffffffff811351c6>] generic_exec_single+0xb6/0x140 kernel/smp.c:181
 [<ffffffff8113558f>] smp_call_function_single_async+0x6f/0xe0 kernel/smp.c:340
 [<     inlined    >] raise_blk_irq block/blk-softirq.c:68
 [<ffffffff8152283f>] __blk_complete_request+0x1af/0x1d0 block/blk-softirq.c:149
 [<ffffffff81522891>] blk_complete_request+0x31/0x40 block/blk-softirq.c:171
 [<ffffffff8189ff73>] scsi_done+0x43/0xc0 drivers/scsi/scsi_lib.c:1749
 [<ffffffff818dae76>] ata_scsi_qc_complete+0xa6/0x580 drivers/ata/libata-scsi.c:1796
 [<ffffffff818cdc75>] __ata_qc_complete+0x155/0x2d0 drivers/ata/libata-core.c:4851
 [<ffffffff818cdf49>] ata_qc_complete+0x159/0x5d0 drivers/ata/libata-core.c:4921
 [<ffffffff818ee7bd>] ata_hsm_qc_complete+0x7d/0x1d0 drivers/ata/libata-sff.c:1021
 [<ffffffff818ef7cd>] ata_sff_hsm_move+0x10d/0xcc0 drivers/ata/libata-sff.c:1293
 [<ffffffff818f049b>] __ata_sff_port_intr+0x11b/0x210 drivers/ata/libata-sff.c:1581
 [<ffffffff818f0a12>] ata_bmdma_port_intr+0x52/0x1f0 drivers/ata/libata-sff.c:2874
 [<     inlined    >] __ata_sff_interrupt drivers/ata/libata-sff.c:1626
 [<ffffffff818f0d08>] ata_bmdma_interrupt+0x158/0x2e0 drivers/ata/libata-sff.c:2899
 [<ffffffff810f79d2>] handle_irq_event_percpu+0x62/0x2c0 kernel/irq/handle.c:143
 [<ffffffff810f7ce7>] handle_irq_event+0xb7/0x110 kernel/irq/handle.c:192
 [<ffffffff810fcccc>] handle_edge_irq+0x12c/0x3b0 kernel/irq/chip.c:608
 [<     inlined    >] generic_handle_irq_desc include/linux/irqdesc.h:146
 [<ffffffff8100a18f>] handle_irq+0x9f/0x230 arch/x86/kernel/irq_64.c:81
 [<ffffffff8100946a>] do_IRQ+0x8a/0x170 arch/x86/kernel/irq.c:223
 [<ffffffff81eeafeb>] ret_from_intr+0x0/0x1f arch/x86/entry/entry_64.S:601
 [<ffffffff81eeb2db>] apic_timer_interrupt+0x6b/0x70 arch/x86/entry/entry_64.S:782
 [<ffffffff811f9dd9>] kvfree+0x39/0x60 mm/util.c:324
 [<ffffffff8129ed98>] seq_release+0x38/0x50 fs/seq_file.c:361
 [<ffffffff813290cf>] kernfs_fop_release+0x6f/0xa0 fs/kernfs/file.c:735
 [<ffffffff8126445f>] __fput+0x15f/0x310 fs/file_table.c:208
 [<ffffffff8126467d>] ____fput+0x1d/0x30 fs/file_table.c:244
 [<ffffffff810b95a5>] task_work_run+0x115/0x130 kernel/task_work.c:123 (discriminator 1)
 [<     inlined    >] tracehook_notify_resume include/linux/tracehook.h:190
 [<ffffffff81006d33>] do_notify_resume+0x73/0x80 arch/x86/kernel/signal.c:753
 [<ffffffff81eea67c>] int_signal+0x12/0x17 arch/x86/entry/entry_64.S:326

What happens is as follows:
T438 on CPU3 adds an item to CPU2 percpu list using an IPI, see raise_blk_irq block/blk-softirq.c:68.
Then T544 on CPU2 grabs the list and frees items.
KTSAN does not see that one happens before another and reports the race.

unified header for reports

For one set of reports we print:

BUG: KASAN: slab-out-of-bounds in memcpy+0x1d/0x40 at addr ffff88003a6bd110
Read of size 8 by task a.out/6260

for another:

BUG: KASAN: null-ptr-deref on address           (null)
Read of size 4 by task syz-executor/22534

This complicates parsing, and the the second case we don't have a function name which complicates unique identification of bugs: null-ptr-deref is too vague, two such bugs may or may not be the same.

We should always print the first form:

KASAN: {TYPE} in {FUNC} at addr {ADDR}
(Read|Write) of size {SIZE} by task

Better handling for modules

Right now when a module is allocated KASan only maps the shadow pages corresponding to that module's address range. In the case of a buffer overflow touching the memory past that address we get a GPF that causes the kernel to crash.
A better way to handle modules would be to map the shadow for the modules' range but poison parts of it that do not mirror loaded modules. Redzones around modules are also nice to have.

quarantine leads to OOMs

The following program leads to OOM after some time when quarantine is enabled.

Without quarantine it runs without OOMs and top shows:

KiB Mem:   6837036 total,    96560 used,  6740476 free,     4636 buffers
KiB Mem:   6837036 total,    96160 used,  6740876 free,     4636 buffers
KiB Mem:   6837036 total,    96232 used,  6740804 free,     4636 buffers
KiB Mem:   6837036 total,    96664 used,  6740372 free,     4636 buffers
KiB Mem:   6837036 total,    97024 used,  6740012 free,     4636 buffers
KiB Mem:   6837036 total,    96840 used,  6740196 free,     4636 buffers

With quarantine top shows:

KiB Mem:   6837036 total,  6788916 used,    48120 free,     2576 buffers
KiB Mem:   6837036 total,  6711124 used,   125912 free,     2576 buffers
KiB Mem:   6837036 total,  6779400 used,    57636 free,     2576 buffers
KiB Mem:   6837036 total,  6757508 used,    79528 free,     2576 buffers
KiB Mem:   6837036 total,  6778356 used,    58680 free,     2576 buffers
KiB Mem:   6837036 total,  6777832 used,    59204 free,     2576 buffers
KiB Mem:   6837036 total,  6768796 used,    68240 free,     2576 buffers

And after some time the program crashes with:

fork: Cannot allocate memory

During the crash kernel says:

[ 1303.352092] a.out: page allocation failure: order:4, mode:0x2080d0
[ 1303.352757] CPU: 5 PID: 2609 Comm: a.out Not tainted 3.18.0-rc1+ #55
[ 1303.353414] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[ 1303.354226]  dfffe90000000000 ffff8800b1a5f880 ffffffff82c2de0e 0000000000000036
[ 1303.354956]  1ffff1001634bf14 ffff8800b1a5f9a0 ffffffff81322f28 0000000000000001
[ 1303.355735]  0000000400000004 0000000041b58ab3 ffffffff8321b8ec ffffffff81322d50
[ 1303.356494] Call Trace:
[ 1303.356744]  [<ffffffff82c2de0e>] dump_stack+0x46/0x58
[ 1303.357290]  [<ffffffff81322f28>] warn_alloc_failed+0x1d8/0x260
[ 1303.357870]  [<ffffffff81322d50>] ? zone_watermark_ok_safe+0x290/0x290
[ 1303.358542]  [<ffffffff8132ab4e>] ? __alloc_pages_direct_compact+0x58e/0x630
[ 1303.359260]  [<ffffffff81321cd0>] ? drain_pages+0x1c0/0x1c0
[ 1303.359801]  [<ffffffff8132a5c0>] ? get_page_from_freelist+0x18d0/0x18d0
[ 1303.360463]  [<ffffffff813226e3>] ? drain_all_pages+0x183/0x220
[ 1303.361061]  [<ffffffff813ea0b2>] ? memset+0xa2/0x260
[ 1303.361532]  [<ffffffff82c394b3>] ? __schedule+0x893/0x1ad0
[ 1303.362087]  [<ffffffff8132af48>] __alloc_pages_nodemask+0x358/0x1320
[ 1303.362682]  [<ffffffff8132abf0>] ? __alloc_pages_direct_compact+0x630/0x630
[ 1303.363464]  [<ffffffff813db5ec>] ? set_track+0x6c/0x140
[ 1303.363999]  [<ffffffff810a6d5b>] ? native_flush_tlb_others+0x6b/0x80
[ 1303.364639]  [<ffffffff810b06d7>] ? copy_process.part.41+0x207/0x52b0
[ 1303.365309]  [<ffffffff813e904f>] ? kasan_poison_shadow+0x2f/0x40
[ 1303.365893]  [<ffffffff813e9f94>] ? kasan_unpoison_shadow+0x14/0x40
[ 1303.366544]  [<ffffffff813e904f>] ? kasan_poison_shadow+0x2f/0x40
[ 1303.367167]  [<ffffffff813ea001>] ? kasan_kmalloc+0x41/0x50
[ 1303.367707]  [<ffffffff813eacbd>] ? kasan_slab_alloc+0xd/0x10
[ 1303.368297]  [<ffffffff8132bf7c>] alloc_kmem_pages_node+0x6c/0x90
[ 1303.368900]  [<ffffffff810b06f5>] copy_process.part.41+0x225/0x52b0
[ 1303.369534]  [<ffffffff81388f14>] ? handle_mm_fault+0xd84/0x1900
[ 1303.370146]  [<ffffffff8137215b>] ? vmacache_find+0x13b/0x2d0
[ 1303.370701]  [<ffffffff8109895c>] ? __do_page_fault+0x43c/0xbf0
[ 1303.371304]  [<ffffffff810b04d0>] ? __cleanup_sighand+0x40/0x40
[ 1303.371874]  [<ffffffff8138fee4>] ? remove_vma+0x124/0x170
[ 1303.372442]  [<ffffffff810b5b71>] do_fork+0x161/0x790
[ 1303.372939]  [<ffffffff8138fee4>] ? remove_vma+0x124/0x170
[ 1303.373504]  [<ffffffff810b5a10>] ? fork_idle+0x230/0x230
[ 1303.374056]  [<ffffffff811f45f0>] ? do_futex+0x1510/0x1510
[ 1303.374584]  [<ffffffff810991aa>] ? trace_do_page_fault+0x6a/0x1d0
[ 1303.375228]  [<ffffffff810b6221>] SyS_clone+0x11/0x20
[ 1303.375717]  [<ffffffff82c44ce9>] stub_clone+0x69/0x90
[ 1303.376250]  [<ffffffff82c449a9>] ? system_call_fastpath+0x12/0x17
[ 1303.376836] Mem-Info:
[ 1303.377103] Node 0 DMA per-cpu:
[ 1303.377429] CPU    0: hi:    0, btch:   1 usd:   0
[ 1303.377890] CPU    1: hi:    0, btch:   1 usd:   0
[ 1303.378490] CPU    2: hi:    0, btch:   1 usd:   0
[ 1303.378957] CPU    3: hi:    0, btch:   1 usd:   0
[ 1303.379447] CPU    4: hi:    0, btch:   1 usd:   0
[ 1303.379915] CPU    5: hi:    0, btch:   1 usd:   0
[ 1303.380402] CPU    6: hi:    0, btch:   1 usd:   0
[ 1303.380876] CPU    7: hi:    0, btch:   1 usd:   0
[ 1303.381352] Node 0 DMA32 per-cpu:
[ 1303.381691] CPU    0: hi:  186, btch:  31 usd:   0
[ 1303.382172] CPU    1: hi:  186, btch:  31 usd:   0
[ 1303.382638] CPU    2: hi:  186, btch:  31 usd:   0
[ 1303.383130] CPU    3: hi:  186, btch:  31 usd:   0
[ 1303.383600] CPU    4: hi:  186, btch:  31 usd:   0
[ 1303.384102] CPU    5: hi:  186, btch:  31 usd:   0
[ 1303.384569] CPU    6: hi:  186, btch:  31 usd:   0
[ 1303.385051] CPU    7: hi:  186, btch:  31 usd:   0
[ 1303.385516] Node 0 Normal per-cpu:
[ 1303.385860] CPU    0: hi:  186, btch:  31 usd:   0
[ 1303.386342] CPU    1: hi:  186, btch:  31 usd:   0
[ 1303.386807] CPU    2: hi:  186, btch:  31 usd:   1
[ 1303.387291] CPU    3: hi:  186, btch:  31 usd:   0
[ 1303.387756] CPU    4: hi:  186, btch:  31 usd:   0
[ 1303.388241] CPU    5: hi:  186, btch:  31 usd:   0
[ 1303.388713] CPU    6: hi:  186, btch:  31 usd:  26
[ 1303.389199] CPU    7: hi:  186, btch:  31 usd:   0
[ 1303.389663] active_anon:2613 inactive_anon:31 isolated_anon:0
[ 1303.389663]  active_file:3308 inactive_file:1353 isolated_file:0
[ 1303.389663]  unevictable:0 dirty:4 writeback:0 unstable:0
[ 1303.389663]  free:42113 slab_reclaimable:1638744 slab_unreclaimable:13886
[ 1303.389663]  mapped:1994 shmem:37 pagetables:292 bounce:0
[ 1303.389663]  free_cma:0
[ 1303.392672] Node 0 DMA free:15876kB min:24kB low:28kB high:36kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:32kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[ 1303.396613] lowmem_reserve[]: 0 2949 6656 6656
[ 1303.397145] Node 0 DMA32 free:81304kB min:4620kB low:5772kB high:6928kB active_anon:4224kB inactive_anon:48kB active_file:6008kB inactive_file:1988kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3129332kB managed:3024924kB mlocked:0kB dirty:4kB writeback:0kB mapped:3356kB shmem:56kB slab_reclaimable:2907768kB slab_unreclaimable:19368kB kernel_stack:2816kB pagetables:448kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1303.401154] lowmem_reserve[]: 0 0 3707 3707
[ 1303.401621] Node 0 Normal free:71272kB min:5804kB low:7252kB high:8704kB active_anon:6228kB inactive_anon:76kB active_file:7224kB inactive_file:3424kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:5242880kB managed:3796204kB mlocked:0kB dirty:12kB writeback:0kB mapped:4620kB shmem:92kB slab_reclaimable:3647208kB slab_unreclaimable:36144kB kernel_stack:5952kB pagetables:720kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1303.405762] lowmem_reserve[]: 0 0 0 0
[ 1303.406197] Node 0 DMA: 1*4kB (U) 0*8kB 0*16kB 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15876kB
[ 1303.407729] Node 0 DMA32: 262*4kB (UEM) 2634*8kB (UEM) 2869*16kB (UEM) 412*32kB (UEM) 8*64kB (UR) 1*128kB (R) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 81848kB
[ 1303.409728] Node 0 Normal: 119*4kB (UE) 2876*8kB (UEM) 2602*16kB (UEM) 206*32kB (UEMR) 1*64kB (M) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 71772kB
[ 1303.411378] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[ 1303.412194] 4697 total pagecache pages
[ 1303.412561] 0 pages in swap cache
[ 1303.412892] Swap cache stats: add 0, delete 0, find 0/0
[ 1303.413416] Free swap  = 0kB
[ 1303.413702] Total swap = 0kB
[ 1303.413988] 2097051 pages RAM
[ 1303.414291] 0 pages HighMem/MovableOnly
[ 1303.414667] 361669 pages reserved

Reproducer program:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#include <errno.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/wait.h>

void myerror(const char *what) {
    perror(what);
    exit(1);
}

static void* thr(void *arg) {
    for (int i = 0;; i++) {
        if ((i % 1000) == 0) {
            printf(".");
            fflush(0);
        }
        int pipefd[2];
        if (pipe(&pipefd[0]))
            myerror("pipe");
        if (write(pipefd[1], "a", 1) <= 0)
            myerror("write");
        if (close(pipefd[0]))
            myerror("close");
        if (close(pipefd[1]))
            myerror("close");
        void *p = mmap(0, 4096, PROT_READ, MAP_ANON|MAP_PRIVATE, -1, 0);
        if (p == MAP_FAILED)
            myerror("mmap");
        if (munmap(p, 4096))
            myerror("munmap");
        int pid = fork();
        if (pid == 0) {
            exit(0);
        } else if (pid > 0) {
            int res = waitpid(pid, 0, 0);
            if (res != pid && (res != -1 || errno != ECHILD))
                myerror("waitpid");
        } else {
            myerror("fork");
        }
    }
    return 0;
}

int main() {
    pthread_t th[16];
    for (int t = 0; t < 16; t++)
        pthread_create(&th[t], 0, thr, 0);
    pthread_join(th[0], 0);
    return 0;
}

CPU numbers in reports are presumably wrong

According to code these memory accesses seem to always happen on the same CPU, while in reports CPUs are always different:

ThreadSanitizer: data-race in tcp_wfree

Write of size 8 by thread T12 (K0, CPU3):
 [<     inlined    >] __list_add include/linux/list.h:43
 [<     inlined    >] list_add include/linux/list.h:63
 [<ffffffff81c4ab60>] tcp_wfree+0x130/0x1a0 net/ipv4/tcp_output.c:891
 [<ffffffff81b6b9e4>] skb_release_head_state+0x94/0x120 net/core/skbuff.c:644 (discriminator 3)
 [<ffffffff81b6d25d>] skb_release_all+0x1d/0x50 net/core/skbuff.c:657
 [<     inlined    >] __kfree_skb net/core/skbuff.c:673
 [<ffffffff81b6d510>] consume_skb+0x60/0x110 net/core/skbuff.c:746
 [<ffffffff81b8cddd>] __dev_kfree_skb_any+0x4d/0x60 net/core/dev.c:2312
 [<     inlined    >] dev_kfree_skb_any include/linux/netdevice.h:2933
 [<ffffffff8194ca33>] e1000_unmap_and_free_tx_resource.isra.42+0xd3/0x120 drivers/net/ethernet/intel/e1000/e1000_main.c:1973
 [<     inlined    >] e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3881
 [<ffffffff8194cccd>] e1000_clean+0x24d/0x11e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3818
 [<     inlined    >] napi_poll net/core/dev.c:4744
 [<ffffffff81b90789>] net_rx_action+0x489/0x690 net/core/dev.c:4809
 [<ffffffff81091d7e>] __do_softirq+0xbe/0x300 kernel/softirq.c:273
 [<ffffffff81ee9e2b>] ret_from_intr+0x0/0x1f arch/x86/entry/entry_64.S:601
 [<ffffffff810166af>] arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:292
 [<ffffffff810dd48f>] default_idle_call+0x3f/0x60 kernel/sched/idle.c:89

Previous write of size 8 by thread T7 (K7, CPU2):
 [<     inlined    >] __list_splice include/linux/list.h:306
 [<     inlined    >] list_splice_init include/linux/list.h:345
 [<ffffffff81c50c21>] tcp_tasklet_func+0xb1/0x260 net/ipv4/tcp_output.c:767
 [<ffffffff81091561>] tasklet_action+0xc1/0x1f0 kernel/softirq.c:505
 [<ffffffff81eea11b>] apic_timer_interrupt+0x6b/0x70 arch/x86/entry/entry_64.S:782
 [<ffffffff810bbe20>] kthread+0x150/0x170 kernel/kthread.c:209
 [<ffffffff81ee96df>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:526

DBG: addr: ffff8804a0258dc8
DBG: first offset: 0, second offset: 0
DBG: T12 clock: {T12: 8804827, T7: 3091553}
DBG: T7 clock: {T7: 3091569}

kernel BUG at mm/ktsan/mutexset.c:32

The reason is probably that the kernel is trying to unlock a mutex in a different thread (which might be a false positive), but we do kt_mutexset_unlock before checking the thread id. And it BUGs when can't find the mutex being unlocked.

[  151.679331] kernel BUG at mm/ktsan/mutexset.c:32!
[  151.679331] invalid opcode: 0000 [#1] SMP 
[  151.679331] Modules linked in:
[  151.679331] CPU: 1 PID: 1192 Comm: ps Not tainted 4.2.0-ktsan google/ktsan#9
[  151.679331] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[  151.679331] task: ffff8800d8878480 ti: ffff88016cbfc000 task.ti: ffff88016cbfc000
[  151.679331] RIP: 0010:[<ffffffff81250ab3>]  [<ffffffff81250ab3>] kt_mutex_unlock+0x113/0x120
[  151.679331] RSP: 0018:ffff88016cbffa88  EFLAGS: 00010046
[  151.679331] RAX: 00000000ffffffff RBX: ffff8801a90ebd78 RCX: 0000000000000000
[  151.679331] RDX: 0000000000000001 RSI: 000000000002ee3b RDI: 0000000000000000
[  151.679331] RBP: 0000000000005707 R08: 0000000000000001 R09: 0000000000000001
[  151.679331] R10: 0000000000000080 R11: 00000000ac3f204b R12: 0000000000000008
[  151.679331] R13: ffff88016d1e1d48 R14: 0000000000000001 R15: ffff88016d1e1d48
[  151.679331] FS:  00007f2d503df700(0000) GS:ffff88051fc80000(0000) knlGS:0000000000000000
[  151.679331] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  151.679331] CR2: 000000000040a2a6 CR3: 00000000d88db000 CR4: 00000000000006e0
[  151.679331] Stack:
[  151.679331]  ffff8801a90ebd78 ffffffff8109fb58 ffff8801e0e619e0 ffff8801a90ebd78
[  151.679331]  ffffffff8109fb58 ffffffff8125413b ffff8801a90ebd78 0000000000000001
[  151.679331]  ffff88016d1e1d48 ffffffff8109fb58 ffff880171e792c0 ffffffff8124e849
[  151.679331] Call Trace:
[  151.679331]  [<ffffffff8109fb58>] ? __lock_task_sighand+0xe8/0x140
[  151.679331]  [<ffffffff8109fb58>] ? __lock_task_sighand+0xe8/0x140
[  151.679331]  [<ffffffff8125413b>] ? kt_mtx_pre_unlock+0x4b/0xc0
[  151.679331]  [<ffffffff8109fb58>] ? __lock_task_sighand+0xe8/0x140
[  151.679331]  [<ffffffff8124e849>] ? ktsan_mtx_pre_unlock+0xb9/0xc0
[  151.679331]  [<ffffffff8109fb58>] ? __lock_task_sighand+0xe8/0x140
[  151.679331]  [<ffffffff81311e36>] ? do_task_stat+0x116/0xda0
[  151.679331]  [<ffffffff81550ed3>] ? memcmp+0x83/0xa0
[  151.679331]  [<ffffffff8125132e>] ? kt_spin_unlock+0xe/0x20
[  151.679331]  [<ffffffff8125132e>] ? kt_spin_unlock+0xe/0x20
[  151.679331]  [<ffffffff81254d0b>] ? kt_tab_access+0x11b/0x1b0
[  151.679331]  [<ffffffff81254ae3>] ? kt_sync_release+0x93/0x160
[  151.679331]  [<ffffffff813138f7>] ? proc_tgid_stat+0x37/0x50
[  151.679331]  [<ffffffff8130ccab>] ? proc_single_show+0x8b/0xd0
[  151.679331]  [<ffffffff8129947e>] ? seq_read+0x16e/0x760
[  151.679331]  [<ffffffff8125c93f>] ? __vfs_read+0x5f/0x1e0
[  151.679331]  [<ffffffff814999cf>] ? security_file_permission+0x6f/0x120
[  151.679331]  [<ffffffff8125d6c1>] ? rw_verify_area+0xa1/0x180
[  151.679331]  [<ffffffff8125d857>] ? vfs_read+0xb7/0x1e0
[  151.679331]  [<ffffffff8125edb0>] ? SyS_read+0x70/0xd0
[  162.392886]  [<ffffffff81ed753a>] ? entry_SYSCALL_64_fastpath+0x1a/0x95
[  162.392886]  [<ffffffff81ed7551>] ? entry_SYSCALL_64_fastpath+0x31/0x95
[  162.392886] Code: 83 c4 10 5b 5d 41 5c c3 89 54 24 0c 48 89 34 24 e8 83 80 00 00 8b 54 24 0c 48 8b 34 24 e9 24 ff ff ff 0f 0b 0f 0b 4c 89 c9 eb 9c <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 44 8b 87 c8 80 08 00 45 
[  162.400899] RIP  [<ffffffff81250ab3>] kt_mutex_unlock+0x113/0x120
[  162.400899]  RSP <ffff88016cbffa88>
[  162.400899] ---[ end trace 0c12083548476300 ]---

False positive in blk_complete_request

Here are two reports on commit c58422d251bc

ThreadSanitizer: data-race in kmem_cache_free

Write at 0xffff880485d5fdd0 of size 8 by thread 1206 on CPU 0:
 [<     inline     >] __cache_free mm/slab.c:3384
 [<ffffffff812451e2>] kmem_cache_free+0x92/0x480 mm/slab.c:3562
 [<ffffffff8150c440>] free_request_struct+0x30/0x40 block/blk-core.c:597
 [<ffffffff811d04a5>] mempool_free+0x75/0x130 mm/mempool.c:439
 [<     inline     >] blk_free_request block/blk-core.c:832
 [<ffffffff8150d5bb>] __blk_put_request+0x11b/0x200 block/blk-core.c:1424
 [<ffffffff8150d71d>] blk_put_request+0x7d/0xb0 block/blk-core.c:1441
 [<ffffffff818991cf>] scsi_execute+0x9f/0x2a0 drivers/scsi/scsi_lib.c:259
 [<ffffffff818baece>] sr_do_ioctl+0x11e/0x360 drivers/scsi/sr_ioctl.c:209
 [<ffffffff818b94c6>] sr_packet+0x56/0xc0 drivers/scsi/sr.c:949
 [<ffffffff81988a18>] cdrom_get_media_event+0xa8/0x130 drivers/cdrom/cdrom.c:673
 [<ffffffff818bba77>] sr_drive_status+0x97/0x1d0 drivers/scsi/sr_ioctl.c:312
 [<     inline     >] cdrom_ioctl_drive_status drivers/cdrom/cdrom.c:2530
 [<ffffffff8198f53e>] cdrom_ioctl+0xdde/0x11f0 drivers/cdrom/cdrom.c:3348
 [<ffffffff818b9eb6>] sr_block_ioctl+0xa6/0xf0 drivers/scsi/sr.c:568
 [<     inline     >] __blkdev_driver_ioctl block/ioctl.c:267
 [<ffffffff8152c69a>] blkdev_ioctl+0x22a/0xa10 block/ioctl.c:453
 [<ffffffff812bed52>] block_ioctl+0x82/0xa0 fs/block_dev.c:1593
 [<     inline     >] vfs_ioctl fs/ioctl.c:43
 [<ffffffff8127ffd9>] do_vfs_ioctl+0x449/0x750 fs/ioctl.c:607
 [<     inline     >] SYSC_ioctl fs/ioctl.c:622
 [<ffffffff81280359>] SyS_ioctl+0x79/0xa0 fs/ioctl.c:613
 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188

Previous read at 0xffff880485d5fdd0 of size 1 by thread 850 on CPU 0:
 [<     inline     >] test_and_set_bit ./arch/x86/include/asm/bitops.h:231
 [<     inline     >] blk_mark_rq_complete block/blk.h:102
 [<ffffffff815200a5>] blk_complete_request+0x25/0x40 block/blk-softirq.c:170
 [<ffffffff8189cb63>] scsi_done+0x43/0xb0 drivers/scsi/scsi_lib.c:1749
 [<ffffffff818d8b24>] atapi_qc_complete+0xd4/0x6d0 drivers/ata/libata-scsi.c:2738
 [<ffffffff818ca835>] __ata_qc_complete+0x155/0x2d0 drivers/ata/libata-core.c:4851
 [<ffffffff818cab09>] ata_qc_complete+0x159/0x5c0 drivers/ata/libata-core.c:4921
 [<ffffffff818eb34d>] ata_hsm_qc_complete+0x7d/0x1d0 drivers/ata/libata-sff.c:1021
 [<ffffffff818ec35d>] ata_sff_hsm_move+0x10d/0xcc0 drivers/ata/libata-sff.c:1293
 [<ffffffff818ed02b>] __ata_sff_port_intr+0x11b/0x210 drivers/ata/libata-sff.c:1581
 [<ffffffff818ed5a2>] ata_bmdma_port_intr+0x52/0x1f0 drivers/ata/libata-sff.c:2874
 [<     inline     >] __ata_sff_interrupt drivers/ata/libata-sff.c:1626
 [<ffffffff818ed898>] ata_bmdma_interrupt+0x158/0x2e0 drivers/ata/libata-sff.c:2899
 [<ffffffff810f7082>] handle_irq_event_percpu+0x62/0x2b0 kernel/irq/handle.c:143
 [<ffffffff810f736b>] handle_irq_event+0x9b/0xd0 kernel/irq/handle.c:192
 [<ffffffff810fc01f>] handle_edge_irq+0x11f/0x370 kernel/irq/chip.c:608
 [<     inline     >] generic_handle_irq_desc include/linux/irqdesc.h:146
 [<ffffffff8100a15f>] handle_irq+0x9f/0x230 arch/x86/kernel/irq_64.c:81
 [<ffffffff8100946a>] do_IRQ+0x8a/0x170 arch/x86/kernel/irq.c:223
 [<ffffffff81ee494a>] common_interrupt+0x8a/0x8f arch/x86/entry/entry_64.S:609
 [<ffffffff81ee494a>] common_interrupt+0x8a/0x8f arch/x86/entry/entry_64.S:609

ThreadSanitizer: data-race in kmem_cache_free

Write at 0xffff880485d5fe00 of size 8 by thread 1206 on CPU 0:
 [<     inline     >] __cache_free mm/slab.c:3384
 [<ffffffff812451e2>] kmem_cache_free+0x92/0x480 mm/slab.c:3562
 [<ffffffff8150c440>] free_request_struct+0x30/0x40 block/blk-core.c:597
 [<ffffffff811d04a5>] mempool_free+0x75/0x130 mm/mempool.c:439
 [<     inline     >] blk_free_request block/blk-core.c:832
 [<ffffffff8150d5bb>] __blk_put_request+0x11b/0x200 block/blk-core.c:1424
 [<ffffffff8150d71d>] blk_put_request+0x7d/0xb0 block/blk-core.c:1441
 [<ffffffff818991cf>] scsi_execute+0x9f/0x2a0 drivers/scsi/scsi_lib.c:259
 [<ffffffff818baece>] sr_do_ioctl+0x11e/0x360 drivers/scsi/sr_ioctl.c:209
 [<ffffffff818b94c6>] sr_packet+0x56/0xc0 drivers/scsi/sr.c:949
 [<ffffffff81988a18>] cdrom_get_media_event+0xa8/0x130 drivers/cdrom/cdrom.c:673
 [<ffffffff818bba77>] sr_drive_status+0x97/0x1d0 drivers/scsi/sr_ioctl.c:312
 [<     inline     >] cdrom_ioctl_drive_status drivers/cdrom/cdrom.c:2530
 [<ffffffff8198f53e>] cdrom_ioctl+0xdde/0x11f0 drivers/cdrom/cdrom.c:3348
 [<ffffffff818b9eb6>] sr_block_ioctl+0xa6/0xf0 drivers/scsi/sr.c:568
 [<     inline     >] __blkdev_driver_ioctl block/ioctl.c:267
 [<ffffffff8152c69a>] blkdev_ioctl+0x22a/0xa10 block/ioctl.c:453
 [<ffffffff812bed52>] block_ioctl+0x82/0xa0 fs/block_dev.c:1593
 [<     inline     >] vfs_ioctl fs/ioctl.c:43
 [<ffffffff8127ffd9>] do_vfs_ioctl+0x449/0x750 fs/ioctl.c:607
 [<     inline     >] SYSC_ioctl fs/ioctl.c:622
 [<ffffffff81280359>] SyS_ioctl+0x79/0xa0 fs/ioctl.c:613
 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188

Previous write at 0xffff880485d5fe00 of size 8 by thread 850 on CPU 0:
 [<     inline     >] __list_add include/linux/list.h:44
 [<     inline     >] list_add_tail include/linux/list.h:77
 [<ffffffff8151ffcc>] __blk_complete_request+0x11c/0x1d0 block/blk-softirq.c:139
 [<ffffffff815200b1>] blk_complete_request+0x31/0x40 block/blk-softirq.c:171
 [<ffffffff8189cb63>] scsi_done+0x43/0xb0 drivers/scsi/scsi_lib.c:1749
 [<ffffffff818d8b24>] atapi_qc_complete+0xd4/0x6d0 drivers/ata/libata-scsi.c:2738
 [<ffffffff818ca835>] __ata_qc_complete+0x155/0x2d0 drivers/ata/libata-core.c:4851
 [<ffffffff818cab09>] ata_qc_complete+0x159/0x5c0 drivers/ata/libata-core.c:4921
 [<ffffffff818eb34d>] ata_hsm_qc_complete+0x7d/0x1d0 drivers/ata/libata-sff.c:1021
 [<ffffffff818ec35d>] ata_sff_hsm_move+0x10d/0xcc0 drivers/ata/libata-sff.c:1293
 [<ffffffff818ed02b>] __ata_sff_port_intr+0x11b/0x210 drivers/ata/libata-sff.c:1581
 [<ffffffff818ed5a2>] ata_bmdma_port_intr+0x52/0x1f0 drivers/ata/libata-sff.c:2874
 [<     inline     >] __ata_sff_interrupt drivers/ata/libata-sff.c:1626
 [<ffffffff818ed898>] ata_bmdma_interrupt+0x158/0x2e0 drivers/ata/libata-sff.c:2899
 [<ffffffff810f7082>] handle_irq_event_percpu+0x62/0x2b0 kernel/irq/handle.c:143
 [<ffffffff810f736b>] handle_irq_event+0x9b/0xd0 kernel/irq/handle.c:192
 [<ffffffff810fc01f>] handle_edge_irq+0x11f/0x370 kernel/irq/chip.c:608
 [<     inline     >] generic_handle_irq_desc include/linux/irqdesc.h:146
 [<ffffffff8100a15f>] handle_irq+0x9f/0x230 arch/x86/kernel/irq_64.c:81
 [<ffffffff8100946a>] do_IRQ+0x8a/0x170 arch/x86/kernel/irq.c:223
 [<ffffffff81ee494a>] common_interrupt+0x8a/0x8f arch/x86/entry/entry_64.S:609
 [<ffffffff81ee494a>] common_interrupt+0x8a/0x8f arch/x86/entry/entry_64.S:609

__blk_complete_request queues softirq that unblocks scsi_execute/blk_execute_rq on a completion.
KTSAN misses that synchronization for some reason.

Bogus reports about wild memory accesses.

We poison shadow memory to catch accesses to shadow outside of kasan code.
But with globals instrumentation there is possibility of valid accesses to shadow memory in non-kasan code. The code in question is vfree().
We call vfree() from kasan_module_free() to free shadow memory backing module's memory.
If module_free() was executed in interrupt context than vfree() could access freeing memory. So it's shadow memory in our case:

void vfree(const void *addr)
{
.....
if (unlikely(in_interrupt())) {
struct vfree_deferred *p = this_cpu_ptr(&vfree_deferred);
if (llist_add((struct llist_node *)addr, &p->list)) <---- access to shadow memory
schedule_work(&p->wq);
.....
}

This causes report like this:

[ 20.476443] ==================================================================
[ 20.476465] BUG: AddressSanitizer: wild memory access in llist_add_batch+0xa7/0xe0 at addr fffffbfff40dc000
[ 20.476467] Write of size 8 by task modprobe/658
[ 20.476474] CPU: 0 PID: 658 Comm: modprobe Not tainted 3.19.0-rc5+ #164
[ 20.476477] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
[ 20.476482] fffffbfff40dc000 ffff88006d007c58 ffffffff82101040 0000000000000024
[ 20.476486] 0000000000000001 ffff88006d007cf8 ffffffff8154012c ffff88006d01a6b0
[ 20.476488] ffff88006d01ea00 ffff88006d01a698 0000000000000296 ffff88006d007ca8
[ 20.476490] Call Trace:
[ 20.476491] [] dump_stack+0x45/0x57
[ 20.476507] [] kasan_report_error+0x63c/0x9c0
[ 20.476516] [] ? wake_up_process+0x49/0x80
[ 20.476521] [] ? insert_work+0x2d4/0x540
[ 20.476524] [] __asan_report_store8_noabort+0x61/0x80
[ 20.476527] [] ? llist_add_batch+0xa7/0xe0
[ 20.476529] [] llist_add_batch+0xa7/0xe0
[ 20.476535] [] vfree+0x6a/0xc0
[ 20.476537] [] ? vfree+0xa1/0xc0
[ 20.476539] [] kasan_module_free+0x1a/0x20
[ 20.476545] [] module_memfree+0x1e/0x30
[ 20.476547] [] do_free_init+0x40/0x80
[ 20.476554] [] rcu_process_callbacks+0x5e9/0x2250
[ 20.476560] [] __do_softirq+0x178/0x890
[ 20.476564] [] irq_exit+0x8d/0xc0

.....
[ 20.476759] Memory state around the buggy address:
[ 20.476766] fffffbfff40dbf00: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.476768] fffffbfff40dbf80: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.476771] >fffffbfff40dc000: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.476773] ^
[ 20.476775] fffffbfff40dc080: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.476778] fffffbfff40dc100: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.476779] ==================================================================

And latter, this one:

[ 20.477198] ==================================================================
[ 20.477203] BUG: AddressSanitizer: wild memory access in free_work+0x84/0x90 at addr fffffbfff40dc000
[ 20.477204] Read of size 8 by task kworker/0:1/36
[ 20.477207] CPU: 0 PID: 36 Comm: kworker/0:1 Not tainted 3.19.0-rc5+ #164
[ 20.477208] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
[ 20.477211] Workqueue: events free_work
[ 20.477213] dffffc0000000000 ffff88006c0ffbe8 ffffffff82101040 0000000000000025
[ 20.477215] 0000000000000000 ffff88006c0ffc88 ffffffff8154012c ffffffff8400d758
[ 20.477217] 0000000000000092 ffff88006c0ffcf8 0000000000000296 000000007c1e7048
[ 20.477220] Call Trace:
[ 20.477225] [] dump_stack+0x45/0x57
[ 20.477229] [] kasan_report_error+0x63c/0x9c0
[ 20.477240] [] ? __debug_check_no_obj_freed+0xe90/0xe90
[ 20.477244] [] __asan_report_load8_noabort+0x61/0x80
[ 20.477248] [] ? free_work+0x84/0x90
[ 20.477252] [] free_work+0x84/0x90
[ 20.477256] [] process_one_work+0x9e2/0x1fd0
[ 20.477261] [] worker_thread+0x645/0x2090
[ 20.477265] [] ? process_one_work+0x1fd0/0x1fd0
[ 20.477269] [] kthread+0x22d/0x380
[ 20.477273] [] ? kthread_worker_fn+0x6f0/0x6f0
[ 20.477278] [] ? schedule_tail+0x1b/0x3e0
[ 20.477282] [] ? kthread_worker_fn+0x6f0/0x6f0
[ 20.477286] [] ret_from_fork+0x7c/0xb0
[ 20.477290] [] ? kthread_worker_fn+0x6f0/0x6f0
[ 20.477292] Memory state around the buggy address:
[ 20.477299] fffffbfff40dbf00: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.477302] fffffbfff40dbf80: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.477305] >fffffbfff40dc000: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.477306] ^
[ 20.477309] fffffbfff40dc080: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.477311] fffffbfff40dc100: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[ 20.477313] ==================================================================

I see couple ways to fix this:

Just unpoison shadow memory
Poison shadow memory but unpoison shadow memory for modules
Shut up kasan with kasan_disable_local()/kasan_enable_local() in kasan_module_free() and free_work()

I think that the first option is the best.
It's the most simple solution. Also we could use kasan_poisoned_page as zero page, so we could get rid of kasan_zero_pte/pmd/pud, so this will save us 12K.

I don't like 2) because this will bring more complexity into arch/x86/mm/kasan_init_64.c code.

I'm strongly against 3), because it looks ugly.

Thoughts, suggestions?

User-memory-access report from copy_user_handle_tail

Here is the report:

==================================================================
BUG: KASan: user-memory-access on address 310000006a690d0d
Write of size 672 by task trinity-c7/16448
CPU: 1 PID: 16448 Comm: trinity-c7 Tainted: G     U          4.2.0-rc8-kasan #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 0000000000000000 ffff8800472f7b98 ffffffff82d57cd4 000000000000002a
 ffff8800472f7bd0 ffff8800472f7bb8 ffffffff81429496 310000006a690d0d
 00000000000002a0 ffff8800472f7bf8 ffffffff81428492 ffff8800667044a8
Call Trace:
 [<     inlined    >] dump_stack+0x45/0x57 __dump_stack lib/dump_stack.c:15
 [<ffffffff82d57cd4>] dump_stack+0x45/0x57 lib/dump_stack.c:50
 [<ffffffff81429496>] kasan_report_user_access+0x76/0xa0 mm/kasan/report.c:212
 [<     inlined    >] __asan_storeN+0x132/0x1b0 check_memory_region mm/kasan/kasan.c:250
 [<ffffffff81428492>] __asan_storeN+0x132/0x1b0 mm/kasan/kasan.c:507
 [<ffffffff8142877e>] ? memset+0x1e/0x40 mm/kasan/kasan.c:266
 [<ffffffff8142877e>] memset+0x1e/0x40 mm/kasan/kasan.c:266
 [<ffffffff82d72bdc>] ? bad_to_user+0x66/0xde5 copy_user_64.o:?
 [<ffffffff81a13e3c>] copy_user_handle_tail+0x8c/0xb0 arch/x86/lib/usercopy_64.c:86
 [<ffffffff82d72b93>] ? bad_to_user+0x1d/0xde5 arch/x86/lib/copy_user_64.S:134
 [<     inlined    >] write_kmem+0x193/0x330 copy_from_user ./arch/x86/include/asm/uaccess.h:718
 [<     inlined    >] write_kmem+0x193/0x330 do_write_kmem drivers/char/mem.c:486
 [<ffffffff81c5ba03>] write_kmem+0x193/0x330 drivers/char/mem.c:518
 [<ffffffff81435aeb>] __vfs_write+0xdb/0x3e0 fs/read_write.c:489
 [<ffffffff82d6e279>] ? _raw_spin_unlock_irqrestore+0x9/0x10 ./arch/x86/include/asm/qrwlock.h:11
 [<     inlined    >] ? hrtimer_start_range_ns+0x61a/0x1250 unlock_hrtimer_base kernel/time/hrtimer.c:805
 [<ffffffff8120a35a>] ? hrtimer_start_range_ns+0x61a/0x1250 kernel/time/hrtimer.c:1005
 [<ffffffff81435a10>] ? __vfs_read+0x3d0/0x3d0 fs/read_write.c:419
 [<ffffffff8189e255>] ? selinux_file_permission+0x2d5/0x430 security/selinux/hooks.c:3214 (discriminator 2)
 [<ffffffff8143d9b0>] ? __sb_end_write+0xc0/0xc0 include/linux/list.h:189
 [<ffffffff818817ba>] ? security_file_permission+0x6a/0x1a0 security/security.c:738 (discriminator 5)
 [<ffffffff81436f07>] ? rw_verify_area+0xb7/0x290 fs/read_write.c:404 (discriminator 4)
 [<ffffffff814374f4>] vfs_write+0x134/0x4c0 fs/read_write.c:538
 [<     inlined    >] SyS_pwrite64+0x11e/0x160 SYSC_pwrite64 fs/read_write.c:627
 [<ffffffff8143a67e>] SyS_pwrite64+0x11e/0x160 fs/read_write.c:614
 [<ffffffff8143a560>] ? SyS_pread64+0x160/0x160 fs/read_write.c:598
 [<ffffffff82d6e9ae>] entry_SYSCALL_64_fastpath+0x12/0x71 arch/x86/entry/entry_64.S:186
==================================================================
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 1 PID: 16448 Comm: trinity-c7 Tainted: G     U          4.2.0-rc8-kasan #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88006b0a3300 ti: ffff8800472f0000 task.ti: ffff8800472f0000
RIP: 0010:[<ffffffff81a13784>]  [<ffffffff81a13784>] __memset+0x24/0x30
RSP: 0018:ffff8800472f7c00  EFLAGS: 00010206
RAX: 0000000000000000 RBX: 310000006a690d0d RCX: 0000000000000054
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 310000006a690d0d
RBP: ffff8800472f7c28 R08: ffffffff8213bed0 R09: 310000006a690d0d
R10: ffffffff83a6c528 R11: fffffbfff073b27b R12: 00000000000002a0
R13: 0000000000000000 R14: 00000000000002a0 R15: 310000006a690d0d
FS:  00007f4eeb12b700(0000) GS:ffff88006d300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 0000000047211000 CR4: 00000000000006e0
Stack:
 ffffffff8142878c ffffffff82d72bdc 00000000000002a0 310000006a690d0d
 ffff8800472f8000 ffff8800472f7c58 ffffffff81a13e3c ffffffff82d72b93
 00000000000002a0 00000000000002a0 310000006a690d0d ffff8800472f7cc8
Call Trace:
 [<ffffffff8142878c>] ? memset+0x2c/0x40 mm/kasan/kasan.c:268
 [<ffffffff82d72bdc>] ? bad_to_user+0x66/0xde5 copy_user_64.o:?
 [<ffffffff81a13e3c>] copy_user_handle_tail+0x8c/0xb0 arch/x86/lib/usercopy_64.c:86
 [<ffffffff82d72b93>] ? bad_to_user+0x1d/0xde5 arch/x86/lib/copy_user_64.S:134
 [<     inlined    >] write_kmem+0x193/0x330 copy_from_user ./arch/x86/include/asm/uaccess.h:718
 [<     inlined    >] write_kmem+0x193/0x330 do_write_kmem drivers/char/mem.c:486
 [<ffffffff81c5ba03>] write_kmem+0x193/0x330 drivers/char/mem.c:518
 [<ffffffff81435aeb>] __vfs_write+0xdb/0x3e0 fs/read_write.c:489
 [<ffffffff82d6e279>] ? _raw_spin_unlock_irqrestore+0x9/0x10 ./arch/x86/include/asm/qrwlock.h:11
 [<     inlined    >] ? hrtimer_start_range_ns+0x61a/0x1250 unlock_hrtimer_base kernel/time/hrtimer.c:805
 [<ffffffff8120a35a>] ? hrtimer_start_range_ns+0x61a/0x1250 kernel/time/hrtimer.c:1005
 [<ffffffff81435a10>] ? __vfs_read+0x3d0/0x3d0 fs/read_write.c:419
 [<ffffffff8189e255>] ? selinux_file_permission+0x2d5/0x430 security/selinux/hooks.c:3214 (discriminator 2)
 [<ffffffff8143d9b0>] ? __sb_end_write+0xc0/0xc0 include/linux/list.h:189
 [<ffffffff818817ba>] ? security_file_permission+0x6a/0x1a0 security/security.c:738 (discriminator 5)
 [<ffffffff81436f07>] ? rw_verify_area+0xb7/0x290 fs/read_write.c:404 (discriminator 4)
 [<ffffffff814374f4>] vfs_write+0x134/0x4c0 fs/read_write.c:538
 [<     inlined    >] SyS_pwrite64+0x11e/0x160 SYSC_pwrite64 fs/read_write.c:627
 [<ffffffff8143a67e>] SyS_pwrite64+0x11e/0x160 fs/read_write.c:614
 [<ffffffff8143a560>] ? SyS_pread64+0x160/0x160 fs/read_write.c:598
 [<ffffffff82d6e9ae>] entry_SYSCALL_64_fastpath+0x12/0x71 arch/x86/entry/entry_64.S:186
Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1
RIP  [<ffffffff81a13784>] __memset+0x24/0x30 arch/x86/lib/memset_64.S:38
 RSP <ffff8800472f7c00>
---[ end trace 51bc733327ab3515 ]---

Even though copy_from_user can validly access user memory, in this case it apparently tries to memset a kernel buffer:

    /* If the destination is a kernel buffer, we always clear the end */
    if (!__addr_ok(to))
        memset(to, 0, len);
    return len;

but the access address turns out to be in userspace.

It's not clear whether this is a bug in kasan or in the kernel.

Does KTSAN support ARM64?

There are many ioctls which can fuzzed on ARM only for android, any way to fuzz those android specific ioctls with the current code if this only supports x86