* [rcu] kernel BUG at include/linux/pagemap.h:149!
@ 2015-09-10 0:57 Fengguang Wu
2015-09-10 10:25 ` Boqun Feng
0 siblings, 1 reply; 62+ messages in thread
From: Fengguang Wu @ 2015-09-10 0:57 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: LKP, LKML
[-- Attachment #1: Type: text/plain, Size: 8254 bytes --]
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2015.09.01a
commit d0a795e7964cca98fbefefef5e0c330b24d04f50
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
AuthorDate: Thu Jul 30 16:55:38 2015 -0700
Commit: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
CommitDate: Mon Aug 31 14:38:03 2015 -0700
rcu: Don't disable preemption for Tiny and Tree RCU readers
Because preempt_disable() maps to barrier() for non-debug builds,
it forces the compiler to spill and reload registers. Because Tree
RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
barrier() instances generate needless extra code for each instance of
rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
RCU and bloats Tiny RCU.
This commit therefore removes the preempt_disable() and preempt_enable()
from the non-preemptible implementations of __rcu_read_lock() and
__rcu_read_unlock(), respectively.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+------------------------------------------------+------------+------------+------------+
| | 2d0f6efd31 | d0a795e796 | d0a795e796 |
+------------------------------------------------+------------+------------+------------+
| boot_successes | 63 | 0 | 0 |
| boot_failures | 2 | 42 | 42 |
| IP-Config:Auto-configuration_of_network_failed | 2 | | |
| kernel_BUG_at_include/linux/pagemap.h | 0 | 42 | 42 |
| invalid_opcode | 0 | 42 | 42 |
| EIP_is_at_page_cache_get_speculative | 0 | 42 | 42 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 42 | 42 |
| backtrace:vfs_write | 0 | 42 | 42 |
| backtrace:SyS_write | 0 | 42 | 42 |
| backtrace:populate_rootfs | 0 | 42 | 42 |
| backtrace:kernel_init_freeable | 0 | 42 | 42 |
+------------------------------------------------+------------+------------+------------+
dmesg for d0a795e796 and 2d0f6efd31 are both attached.
[ 0.205937] PCI: CLS 0 bytes, default 32
[ 0.206554] Unpacking initramfs...
[ 0.208263] ------------[ cut here ]------------
[ 0.209011] kernel BUG at include/linux/pagemap.h:149!
[ 0.209033] invalid opcode: 0000 [#1] DEBUG_PAGEALLOC
[ 0.209033] CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-rc1-00078-gd0a795e #1
[ 0.209033] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 0.209033] task: 8b1aa040 ti: 8b1ac000 task.ti: 8b1ac000
[ 0.209033] EIP: 0060:[<7dccf506>] EFLAGS: 00010202 CPU: 0
[ 0.209033] EIP is at page_cache_get_speculative+0x6c/0x149
[ 0.209033] EAX: 00000001 EBX: 8ac00101 ECX: 00000000 EDX: 00000001
[ 0.209033] ESI: 8bb946e0 EDI: 00000001 EBP: 8b1adc7c ESP: 8b1adc70
[ 0.209033] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 0.209033] CR0: 8005003b CR2: ffffffff CR3: 069fb000 CR4: 00000690
[ 0.209033] Stack:
[ 0.209033] 8ac0012c 8bb946e0 00000000 8b1adc9c 7dcd1219 8ad5ac7c 00000007 00000002
[ 0.209033] 000200d2 00000000 00000000 8b1adcc0 7dcd136c 00000007 00000000 8ad5ac78
[ 0.209033] 0000000f 000200d2 00000000 00000000 8b1adcd4 7dcd3609 000200d2 000009e8
[ 0.209033] Call Trace:
[ 0.209033] [<7dcd1219>] find_get_entry+0xce/0x133
[ 0.209033] [<7dcd136c>] pagecache_get_page+0x1d/0x39d
[ 0.209033] [<7dcd3609>] grab_cache_page_write_begin+0x3a/0x68
[ 0.209033] [<7dd58353>] simple_write_begin+0x2d/0xbf
[ 0.209033] [<7dcd3703>] generic_perform_write+0xcc/0x26f
[ 0.209033] [<7dd4c3e5>] ? file_update_time+0x12b/0x135
[ 0.209033] [<7dcd3a79>] __generic_file_write_iter+0x1d3/0x233
[ 0.209033] [<7dcd3b2f>] generic_file_write_iter+0x56/0x128
[ 0.209033] [<7dd2d866>] __vfs_write+0x99/0x106
[ 0.209033] [<7dd2da75>] vfs_write+0xf7/0x136
[ 0.209033] [<7dd2dbbc>] SyS_write+0x61/0xa7
[ 0.209033] [<7e967bdd>] xwrite+0x23/0xa1
[ 0.209033] [<7e967d10>] do_copy+0xb5/0xf9
[ 0.209033] [<7e96781a>] write_buffer+0x1d/0x2c
[ 0.209033] [<7e9679c1>] flush_buffer+0x3c/0xb0
[ 0.209033] [<7e98e1dc>] gunzip+0x3a0/0x4b0
[ 0.209033] [<7e98de34>] ? bunzip2+0x60c/0x60c
[ 0.209033] [<7e98de3c>] ? nofill+0x8/0x8
[ 0.209033] [<7e96838a>] unpack_to_rootfs+0x1b0/0x2ee
[ 0.209033] [<7e967985>] ? error+0x2c/0x2c
[ 0.209033] [<7e967959>] ? do_start+0x1b/0x1b
[ 0.209033] [<7e968546>] populate_rootfs+0x7e/0x199
[ 0.209033] [<7e966f01>] do_one_initcall+0x130/0x216
[ 0.209033] [<7e966506>] ? repair_env_string+0x29/0x96
[ 0.209033] [<7e9684c8>] ? unpack_to_rootfs+0x2ee/0x2ee
[ 0.209033] [<7dc59bec>] ? parse_args+0x343/0x40a
[ 0.209033] [<7e9670be>] ? kernel_init_freeable+0xd7/0x1b4
[ 0.209033] [<7e9670de>] kernel_init_freeable+0xf7/0x1b4
[ 0.209033] [<7e2736cf>] kernel_init+0x9/0x139
[ 0.209033] [<7e281f00>] ret_from_kernel_thread+0x20/0x30
[ 0.209033] [<7e2736c6>] ? rest_init+0x11e/0x11e
[ 0.209033] Code: ff ff ff 7f b8 dc 98 77 7e 0f 94 c3 31 c9 0f b6 fb 89 fa e8 c7 50 fe ff 8b 04 bd dc 8a 7d 7e 40 84 db 89 04 bd dc 8a 7d 7e 74 02 <0f> 0b 8b 1e 31 c9 b8 a0 98 77 7e c1 eb 0f 83 e3 01 89 da e8 9c
[ 0.209033] EIP: [<7dccf506>] page_cache_get_speculative+0x6c/0x149 SS:ESP 0068:8b1adc70
[ 0.240927] ---[ end trace b15ce49b08a81922 ]---
[ 0.241403] Kernel panic - not syncing: Fatal exception
git bisect start d0a795e7964cca98fbefefef5e0c330b24d04f50 d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754 --
git bisect good 8ff4fbfd69a6c7b9598f8c1f2df34f89bac02c1a # 06:49 22+ 0 Merge branches 'fixes.2015.07.22a' and 'initexp.2015.08.04a' into HEAD
git bisect good 8611bc8cfdb809852e15c8c8786fe0fbd72e7da7 # 06:54 22+ 0 rcu_sync: Introduce rcu_sync_dtor()
git bisect good d74251b8bae07a4957c9f3ccecbdb7f84d790f38 # 07:03 22+ 0 locking/percpu-rwsem: Clean up the lockdep annotations in percpu_down_read()
git bisect good 51899e3fb9b8de48dff0ab1a9cc5250c6d4020ac # 07:09 22+ 0 rcu: Use rcu_callback_t in call_rcu*() and friends
git bisect good e8ee682bcce44c81d8363009b08f115e964dbd0b # 07:14 21+ 2 rcu: Use call_rcu_func_to to replace explicit type equivalents
git bisect good 2d0f6efd311165fe06cecb29475e89e550b92d8c # 07:22 22+ 0 rcu: Use rsp->expedited_wq instead of sync_rcu_preempt_exp_wq
# first bad commit: [d0a795e7964cca98fbefefef5e0c330b24d04f50] rcu: Don't disable preemption for Tiny and Tree RCU readers
git bisect good 2d0f6efd311165fe06cecb29475e89e550b92d8c # 07:26 63+ 2 rcu: Use rsp->expedited_wq instead of sync_rcu_preempt_exp_wq
# extra tests on HEAD of linux-devel/devel-spot-201509091835
git bisect bad 325c0efb5f89af4e5e3d0575ea1b042375dedf6b # 07:31 0- 2 0day head guard for 'devel-spot-201509091835'
# extra tests on tree/branch rcu/dev.2015.09.01a
git bisect bad caa7dd68d68438b256ee830f4aa6b2ddd04b4575 # 07:36 0- 11 locktorture: Fix module unwind when bad torture_type specified
# extra tests with first bad commit reverted
git bisect good 9ff21ff24e5557ad2c1bd72b63f969609e0d28f8 # 07:42 66+ 2 Revert "rcu: Don't disable preemption for Tiny and Tree RCU readers"
# extra tests on tree/branch linus/master
git bisect good b8889c4fc6ba03e289cec6a4d692f6f080a55e53 # 07:50 66+ 0 Merge tag 'tty-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
# extra tests on tree/branch linux-next/master
git bisect good 72c9d8043fdc87832802de0b7a7129d6fc4c4c70 # 07:58 63+ 0 Add linux-next specific files for 20150909
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
[-- Attachment #2: dmesg-vm-kbuild-yocto-i386-53:20150910063126:i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED:4.2.0-rc1-00078-gd0a795e:1 --]
[-- Type: text/plain, Size: 29298 bytes --]
early console in setup code
[ 0.000000] Linux version 4.2.0-rc1-00078-gd0a795e (kbuild@athens) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 Thu Sep 10 06:30:39 CST 2015
[ 0.000000] KERNEL supported cpus:
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] Transmeta GenuineTMx86
[ 0.000000] Transmeta TransmetaCPU
[ 0.000000] UMC UMC UMC UMC
[ 0.000000] CPU: vendor_id 'GenuineIntel' unknown, using generic init.
[ 0.000000] CPU: Your system may be unstable.
[ 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-0x0000000013fdffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000013fe0000-0x0000000013ffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ 0.000000] Notice: NX (Execute Disable) protection missing in CPU!
[ 0.000000] SMBIOS 2.8 present.
[ 0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 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 = 0x13fe0 max_arch_pfn = 0x100000
[ 0.000000] initial memory mapped: [mem 0x00000000-0x077fffff]
[ 0.000000] Base memory trampoline at [7809b000] 9b000 size 16384
[ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[ 0.000000] [mem 0x00000000-0x000fffff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x13400000-0x137fffff]
[ 0.000000] [mem 0x13400000-0x137fffff] page 4k
[ 0.000000] BRK [0x0726e000, 0x0726efff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x00100000-0x133fffff]
[ 0.000000] [mem 0x00100000-0x133fffff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x13800000-0x13fdffff]
[ 0.000000] [mem 0x13800000-0x13fdffff] page 4k
[ 0.000000] BRK [0x0726f000, 0x0726ffff] PGTABLE
[ 0.000000] BRK [0x07270000, 0x07270fff] PGTABLE
[ 0.000000] RAMDISK: [mem 0x13baf000-0x13fd7fff]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x00000000000F0C90 000014 (v00 BOCHS )
[ 0.000000] ACPI: RSDT 0x0000000013FE18BD 000034 (v01 BOCHS BXPCRSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: FACP 0x0000000013FE0B37 000074 (v01 BOCHS BXPCFACP 00000001 BXPC 00000001)
[ 0.000000] ACPI: DSDT 0x0000000013FE0040 000AF7 (v01 BOCHS BXPCDSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: FACS 0x0000000013FE0000 000040
[ 0.000000] ACPI: SSDT 0x0000000013FE0BAB 000C5A (v01 BOCHS BXPCSSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: APIC 0x0000000013FE1805 000080 (v01 BOCHS BXPCAPIC 00000001 BXPC 00000001)
[ 0.000000] ACPI: HPET 0x0000000013FE1885 000038 (v01 BOCHS BXPCHPET 00000001 BXPC 00000001)
[ 0.000000] 0MB HIGHMEM available.
[ 0.000000] 319MB LOWMEM available.
[ 0.000000] mapped low ram: 0 - 13fe0000
[ 0.000000] low ram: 0 - 13fe0000
[ 0.000000] cma: dma_contiguous_reserve(limit 13fe0000)
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.000000] kvm-clock: cpu 0, msr 0:13fdf001, primary cpu clock
[ 0.000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.000000] BRK [0x07271000, 0x07271fff] PGTABLE
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.000000] Normal [mem 0x0000000001000000-0x0000000013fdffff]
[ 0.000000] HighMem empty
[ 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-0x0000000013fdffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x0000000013fdffff]
[ 0.000000] On node 0 totalpages: 81790
[ 0.000000] free_area_init_node: node 0, pgdat 7e769aa0, node_mem_map 8b92f020
[ 0.000000] DMA zone: 32 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 3998 pages, LIFO batch:0
[ 0.000000] Normal zone: 608 pages used for memmap
[ 0.000000] Normal zone: 77792 pages, LIFO batch:15
[ 0.000000] ACPI: PM-Timer IO Port: 0x608
[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.000000] KVM setup async PF for cpu 0
[ 0.000000] kvm-stealtime: cpu 0, msr 66d2480
[ 0.000000] e820: [mem 0x14000000-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] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 81150
[ 0.000000] Kernel command line: root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-kbuild-yocto-i386-53/validate_boot-1-yocto-minimal-i386.cgz-i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED-d0a795e7964cca98fbefefef5e0c330b24d04f50-20150910-58380-otjz37-6.yaml ARCH=i386 kconfig=i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED branch=linux-devel/devel-spot-201509091835 commit=d0a795e7964cca98fbefefef5e0c330b24d04f50 BOOT_IMAGE=/pkg/linux/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/d0a795e7964cca98fbefefef5e0c330b24d04f50/vmlinuz-4.2.0-rc1-00078-gd0a795e max_uptime=600 RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-i386/yocto-minimal-i386.cgz/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/d0a795e7964cca98fbefefef5e0c330b24d04f50/5 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 c
[ 0.000000] sysrq: sysrq always enabled.
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Initializing CPU#0
[ 0.000000] Initializing HighMem for node 0 (00000000:00000000)
[ 0.000000] Memory: 296624K/327160K available (6669K kernel code, 2694K rwdata, 4344K rodata, 584K init, 8540K bss, 30536K reserved, 0K cma-reserved, 0K highmem)
[ 0.000000] virtual kernel memory layout:
[ 0.000000] fixmap : 0xfffe3000 - 0xfffff000 ( 112 kB)
[ 0.000000] pkmap : 0xff800000 - 0xffc00000 (4096 kB)
[ 0.000000] vmalloc : 0x8c7e0000 - 0xff7fe000 (1840 MB)
[ 0.000000] lowmem : 0x78000000 - 0x8bfe0000 ( 319 MB)
[ 0.000000] .init : 0x7e966000 - 0x7e9f8000 ( 584 kB)
[ 0.000000] .data : 0x7e2837cc - 0x7e964a40 (7044 kB)
[ 0.000000] .text : 0x7dc00000 - 0x7e2837cc (6669 kB)
[ 0.000000] Checking if this processor honours the WP bit even in supervisor mode...Ok.
[ 0.000000] Running RCU self tests
[ 0.000000]
[ 0.000000] **********************************************************
[ 0.000000] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
[ 0.000000] ** **
[ 0.000000] ** trace_printk() being used. Allocating extra memory. **
[ 0.000000] ** **
[ 0.000000] ** This means that this is a DEBUG kernel and it is **
[ 0.000000] ** unsafe for production use. **
[ 0.000000] ** **
[ 0.000000] ** If you see this message and you are not debugging **
[ 0.000000] ** the kernel, report this immediately to your vendor! **
[ 0.000000] ** **
[ 0.000000] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
[ 0.000000] **********************************************************
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] CPU 0 irqstacks, hard=8b182000 soft=8b184000
[ 0.000000] console [ttyS0] enabled
[ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.000000] ... MAX_LOCK_DEPTH: 48
[ 0.000000] ... MAX_LOCKDEP_KEYS: 8191
[ 0.000000] ... CLASSHASH_SIZE: 4096
[ 0.000000] ... MAX_LOCKDEP_ENTRIES: 32768
[ 0.000000] ... MAX_LOCKDEP_CHAINS: 65536
[ 0.000000] ... CHAINHASH_SIZE: 32768
[ 0.000000] memory used by lock dependency info: 4911 kB
[ 0.000000] per task-struct memory footprint: 1344 bytes
[ 0.000000] ------------------------
[ 0.000000] | Locking API testsuite:
[ 0.000000] ----------------------------------------------------------------------------
[ 0.000000] | spin |wlock |rlock |mutex | wsem | rsem |
[ 0.000000] --------------------------------------------------------------------------
[ 0.000000] A-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-B-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] double unlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] initialize held: ok | ok | ok | ok | ok | ok |
[ 0.000000] bad unlock order: ok | ok | ok | ok | ok | ok |
[ 0.000000] --------------------------------------------------------------------------
[ 0.000000] recursive read-lock: | ok | | ok |
[ 0.000000] recursive read-lock #2: | ok | | ok |
[ 0.000000] mixed read-write-lock: | ok | | ok |
[ 0.000000] mixed write-read-lock: | ok | | ok |
[ 0.000000] --------------------------------------------------------------------------
[ 0.000000] hard-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 0.000000] soft-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 0.000000] hard-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 0.000000] soft-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 0.000000] sirq-safe-A => hirqs-on/12: ok | ok | ok |
[ 0.000000] sirq-safe-A => hirqs-on/21: ok | ok | ok |
[ 0.000000] hard-safe-A + irqs-on/12: ok | ok | ok |
[ 0.000000] soft-safe-A + irqs-on/12: ok | ok | ok |
[ 0.000000] hard-safe-A + irqs-on/21: ok | ok | ok |
[ 0.000000] soft-safe-A + irqs-on/21: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/123: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/123: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/132: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/132: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/213: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/213: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/231: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/231: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/312: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/312: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/321: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/321: ok | ok | ok |
[ 0.000000] hard-irq read-recursion/123: ok |
[ 0.000000] soft-irq read-recursion/123: ok |
[ 0.000000] hard-irq read-recursion/132: ok |
[ 0.000000] soft-irq read-recursion/132: ok |
[ 0.000000] hard-irq read-recursion/213: ok |
[ 0.000000] soft-irq read-recursion/213: ok |
[ 0.000000] hard-irq read-recursion/231: ok |
[ 0.000000] soft-irq read-recursion/231: ok |
[ 0.000000] hard-irq read-recursion/312: ok |
[ 0.000000] soft-irq read-recursion/312: ok |
[ 0.000000] hard-irq read-recursion/321: ok |
[ 0.000000] soft-irq read-recursion/321: ok |
[ 0.000000] --------------------------------------------------------------------------
[ 0.000000] | Wound/wait tests |
[ 0.000000] ---------------------
[ 0.000000] ww api failures: ok | ok | ok |
[ 0.000000] ww contexts mixing: ok | ok |
[ 0.000000] finishing ww context: ok | ok | ok | ok |
[ 0.000000] locking mismatches: ok | ok | ok |
[ 0.000000] EDEADLK handling: ok | ok | ok | ok | ok | ok | ok | ok | ok | ok |
[ 0.000000] spinlock nest unlocked: ok |
[ 0.000000] -----------------------------------------------------
[ 0.000000] |block | try |context|
[ 0.000000] -----------------------------------------------------
[ 0.000000] context: ok | ok | ok |
[ 0.000000] try: ok | ok | ok |
[ 0.000000] block: ok | ok | ok |
[ 0.000000] spinlock: ok | ok | ok |
[ 0.000000] -------------------------------------------------------
[ 0.000000] Good, all 253 testcases passed! |
[ 0.000000] ---------------------------------
[ 0.000000] ODEBUG: selftest passed
[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
[ 0.000000] hpet clockevent registered
[ 0.000000] tsc: Detected 2693.508 MHz processor
[ 0.003000] Calibrating delay loop (skipped) preset value.. 5387.01 BogoMIPS (lpj=2693508)
[ 0.003410] pid_max: default: 4096 minimum: 301
[ 0.004035] ACPI: Core revision 20150619
[ 0.012262] ACPI: All ACPI Tables successfully acquired
[ 0.013065] ACPI: setting ELCR to 0200 (from 0c00)
[ 0.013818] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.014012] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.016798] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[ 0.017009] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[ 0.018008] CPU: GenuineIntel QEMU Virtual CPU version 2.1.2 (fam: 06, model: 06, stepping: 03)
[ 0.021564] Performance Events: no PMU driver, software events only.
[ 0.024494] devtmpfs: initialized
[ 0.027143] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[ 0.028288] atomic64_test: passed for i586+ platform with CX8 and with SSE
[ 0.031459] NET: Registered protocol family 16
[ 0.034229] cpuidle: using governor ladder
[ 0.034578] cpuidle: using governor menu
[ 0.035472] ACPI: bus type PCI registered
[ 0.036069] PCI: PCI BIOS revision 2.10 entry at 0xfd456, last bus=0
[ 0.036574] PCI: Using configuration type 1 for base access
[ 0.044512] gpio-f7188x: Not a Fintek device at 0x0000002e
[ 0.044980] gpio-f7188x: Not a Fintek device at 0x0000004e
[ 0.045322] ACPI: Added _OSI(Module Device)
[ 0.046015] ACPI: Added _OSI(Processor Device)
[ 0.046372] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.046738] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.052557] ACPI: Interpreter enabled
[ 0.052874] ACPI: (supports S0 S5)
[ 0.053007] ACPI: Using PIC for interrupt routing
[ 0.053436] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.065675] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.066015] acpi PNP0A03:00: _OSC: OS supports [Segments]
[ 0.066498] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[ 0.067212] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[ 0.068204] PCI host bridge to bus 0000:00
[ 0.069011] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.069481] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
[ 0.070009] pci_bus 0000:00: root bus resource [io 0x0d00-0xadff window]
[ 0.070544] pci_bus 0000:00: root bus resource [io 0xae0f-0xaeff window]
[ 0.071008] pci_bus 0000:00: root bus resource [io 0xaf20-0xafdf window]
[ 0.071545] pci_bus 0000:00: root bus resource [io 0xafe4-0xffff window]
[ 0.072009] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 0.073008] pci_bus 0000:00: root bus resource [mem 0x14000000-0xfebfffff window]
[ 0.073695] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[ 0.074575] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[ 0.076107] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[ 0.080000] pci 0000:00:01.1: reg 0x20: [io 0xc080-0xc08f]
[ 0.082022] pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7]
[ 0.082611] pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io 0x03f6]
[ 0.083008] pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177]
[ 0.083564] pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io 0x0376]
[ 0.084341] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
[ 0.085303] pci 0000:00:01.3: can't claim BAR 7 [io 0x0600-0x063f]: address conflict with ACPI PM1a_EVT_BLK [io 0x0600-0x0603]
[ 0.086018] pci 0000:00:01.3: quirk: [io 0x0700-0x070f] claimed by PIIX4 SMB
[ 0.087381] pci 0000:00:02.0: [1013:00b8] type 00 class 0x030000
[ 0.089628] pci 0000:00:02.0: reg 0x10: [mem 0xfc000000-0xfdffffff pref]
[ 0.091614] pci 0000:00:02.0: reg 0x14: [mem 0xfebf0000-0xfebf0fff]
[ 0.098619] pci 0000:00:02.0: reg 0x30: [mem 0xfebe0000-0xfebeffff pref]
[ 0.099392] pci 0000:00:03.0: [8086:100e] type 00 class 0x020000
[ 0.101696] pci 0000:00:03.0: reg 0x10: [mem 0xfebc0000-0xfebdffff]
[ 0.103648] pci 0000:00:03.0: reg 0x14: [io 0xc000-0xc03f]
[ 0.110000] pci 0000:00:03.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref]
[ 0.111411] pci 0000:00:04.0: [1af4:1001] type 00 class 0x010000
[ 0.113000] pci 0000:00:04.0: reg 0x10: [io 0xc040-0xc07f]
[ 0.114574] pci 0000:00:04.0: reg 0x14: [mem 0xfebf1000-0xfebf1fff]
[ 0.122080] pci 0000:00:05.0: [8086:25ab] type 00 class 0x088000
[ 0.123000] pci 0000:00:05.0: reg 0x10: [mem 0xfebf2000-0xfebf200f]
[ 0.127771] pci_bus 0000:00: on NUMA node 0
[ 0.129351] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[ 0.130121] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[ 0.130870] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[ 0.131367] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[ 0.132256] ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
[ 0.133489] ACPI: Enabled 16 GPEs in block 00 to 0F
[ 0.135109] vgaarb: setting as boot device: PCI:0000:00:02.0
[ 0.135562] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.136008] vgaarb: loaded
[ 0.136231] vgaarb: bridge control possible 0000:00:02.0
[ 0.137657] media: Linux media interface: v0.10
[ 0.138042] Linux video capture interface: v2.00
[ 0.138696] PCI: Using ACPI for IRQ routing
[ 0.139007] PCI: pci_cache_line_size set to 32 bytes
[ 0.139501] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
[ 0.140018] e820: reserve RAM buffer [mem 0x13fe0000-0x13ffffff]
[ 0.141783] clocksource: Switched to clocksource kvm-clock
[ 0.142920] Warning: could not register all branches stats
[ 0.143440] Warning: could not register annotated branches stats
[ 0.155860] FS-Cache: Loaded
[ 0.156240] pnp: PnP ACPI init
[ 0.156711] pnp 00:00: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.157384] pnp 00:01: Plug and Play ACPI device, IDs PNP0303 (active)
[ 0.157998] pnp 00:02: Plug and Play ACPI device, IDs PNP0f13 (active)
[ 0.158640] pnp 00:03: [dma 2]
[ 0.158941] pnp 00:03: Plug and Play ACPI device, IDs PNP0700 (active)
[ 0.159655] pnp 00:04: Plug and Play ACPI device, IDs PNP0400 (active)
[ 0.160369] pnp 00:05: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.161574] pnp: PnP ACPI: found 6 devices
[ 0.197351] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 0.198357] pci 0000:00:01.3: BAR 7: [io size 0x0040] has bogus alignment
[ 0.199175] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window]
[ 0.199969] pci_bus 0000:00: resource 5 [io 0x0d00-0xadff window]
[ 0.200722] pci_bus 0000:00: resource 6 [io 0xae0f-0xaeff window]
[ 0.201362] pci_bus 0000:00: resource 7 [io 0xaf20-0xafdf window]
[ 0.201846] pci_bus 0000:00: resource 8 [io 0xafe4-0xffff window]
[ 0.202369] pci_bus 0000:00: resource 9 [mem 0x000a0000-0x000bffff window]
[ 0.202904] pci_bus 0000:00: resource 10 [mem 0x14000000-0xfebfffff window]
[ 0.203534] NET: Registered protocol family 1
[ 0.203917] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[ 0.204440] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[ 0.204917] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[ 0.205463] pci 0000:00:02.0: Video device with shadowed ROM
[ 0.205937] PCI: CLS 0 bytes, default 32
[ 0.206554] Unpacking initramfs...
[ 0.208263] ------------[ cut here ]------------
[ 0.209011] kernel BUG at include/linux/pagemap.h:149!
[ 0.209033] invalid opcode: 0000 [#1] DEBUG_PAGEALLOC
[ 0.209033] CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-rc1-00078-gd0a795e #1
[ 0.209033] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 0.209033] task: 8b1aa040 ti: 8b1ac000 task.ti: 8b1ac000
[ 0.209033] EIP: 0060:[<7dccf506>] EFLAGS: 00010202 CPU: 0
[ 0.209033] EIP is at page_cache_get_speculative+0x6c/0x149
[ 0.209033] EAX: 00000001 EBX: 8ac00101 ECX: 00000000 EDX: 00000001
[ 0.209033] ESI: 8bb946e0 EDI: 00000001 EBP: 8b1adc7c ESP: 8b1adc70
[ 0.209033] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 0.209033] CR0: 8005003b CR2: ffffffff CR3: 069fb000 CR4: 00000690
[ 0.209033] Stack:
[ 0.209033] 8ac0012c 8bb946e0 00000000 8b1adc9c 7dcd1219 8ad5ac7c 00000007 00000002
[ 0.209033] 000200d2 00000000 00000000 8b1adcc0 7dcd136c 00000007 00000000 8ad5ac78
[ 0.209033] 0000000f 000200d2 00000000 00000000 8b1adcd4 7dcd3609 000200d2 000009e8
[ 0.209033] Call Trace:
[ 0.209033] [<7dcd1219>] find_get_entry+0xce/0x133
[ 0.209033] [<7dcd136c>] pagecache_get_page+0x1d/0x39d
[ 0.209033] [<7dcd3609>] grab_cache_page_write_begin+0x3a/0x68
[ 0.209033] [<7dd58353>] simple_write_begin+0x2d/0xbf
[ 0.209033] [<7dcd3703>] generic_perform_write+0xcc/0x26f
[ 0.209033] [<7dd4c3e5>] ? file_update_time+0x12b/0x135
[ 0.209033] [<7dcd3a79>] __generic_file_write_iter+0x1d3/0x233
[ 0.209033] [<7dcd3b2f>] generic_file_write_iter+0x56/0x128
[ 0.209033] [<7dd2d866>] __vfs_write+0x99/0x106
[ 0.209033] [<7dd2da75>] vfs_write+0xf7/0x136
[ 0.209033] [<7dd2dbbc>] SyS_write+0x61/0xa7
[ 0.209033] [<7e967bdd>] xwrite+0x23/0xa1
[ 0.209033] [<7e967d10>] do_copy+0xb5/0xf9
[ 0.209033] [<7e96781a>] write_buffer+0x1d/0x2c
[ 0.209033] [<7e9679c1>] flush_buffer+0x3c/0xb0
[ 0.209033] [<7e98e1dc>] gunzip+0x3a0/0x4b0
[ 0.209033] [<7e98de34>] ? bunzip2+0x60c/0x60c
[ 0.209033] [<7e98de3c>] ? nofill+0x8/0x8
[ 0.209033] [<7e96838a>] unpack_to_rootfs+0x1b0/0x2ee
[ 0.209033] [<7e967985>] ? error+0x2c/0x2c
[ 0.209033] [<7e967959>] ? do_start+0x1b/0x1b
[ 0.209033] [<7e968546>] populate_rootfs+0x7e/0x199
[ 0.209033] [<7e966f01>] do_one_initcall+0x130/0x216
[ 0.209033] [<7e966506>] ? repair_env_string+0x29/0x96
[ 0.209033] [<7e9684c8>] ? unpack_to_rootfs+0x2ee/0x2ee
[ 0.209033] [<7dc59bec>] ? parse_args+0x343/0x40a
[ 0.209033] [<7e9670be>] ? kernel_init_freeable+0xd7/0x1b4
[ 0.209033] [<7e9670de>] kernel_init_freeable+0xf7/0x1b4
[ 0.209033] [<7e2736cf>] kernel_init+0x9/0x139
[ 0.209033] [<7e281f00>] ret_from_kernel_thread+0x20/0x30
[ 0.209033] [<7e2736c6>] ? rest_init+0x11e/0x11e
[ 0.209033] Code: ff ff ff 7f b8 dc 98 77 7e 0f 94 c3 31 c9 0f b6 fb 89 fa e8 c7 50 fe ff 8b 04 bd dc 8a 7d 7e 40 84 db 89 04 bd dc 8a 7d 7e 74 02 <0f> 0b 8b 1e 31 c9 b8 a0 98 77 7e c1 eb 0f 83 e3 01 89 da e8 9c
[ 0.209033] EIP: [<7dccf506>] page_cache_get_speculative+0x6c/0x149 SS:ESP 0068:8b1adc70
[ 0.240927] ---[ end trace b15ce49b08a81922 ]---
[ 0.241403] Kernel panic - not syncing: Fatal exception
Elapsed time: 10
qemu-system-i386 -enable-kvm -kernel /pkg/linux/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/d0a795e7964cca98fbefefef5e0c330b24d04f50/vmlinuz-4.2.0-rc1-00078-gd0a795e -append 'root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-kbuild-yocto-i386-53/validate_boot-1-yocto-minimal-i386.cgz-i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED-d0a795e7964cca98fbefefef5e0c330b24d04f50-20150910-58380-otjz37-6.yaml ARCH=i386 kconfig=i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED branch=linux-devel/devel-spot-201509091835 commit=d0a795e7964cca98fbefefef5e0c330b24d04f50 BOOT_IMAGE=/pkg/linux/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/d0a795e7964cca98fbefefef5e0c330b24d04f50/vmlinuz-4.2.0-rc1-00078-gd0a795e max_uptime=600 RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-i386/yocto-minimal-i386.cgz/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/d0a795e7964cca98fbefefef5e0c330b24d04f50/5 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw ip=::::vm-kbuild-yocto-i386-53::dhcp drbd.minor_count=8' -initrd /fs/sdd1/initrd-vm-kbuild-yocto-i386-53 -m 320 -smp 2 -device e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -rtc base=localtime -drive file=/fs/sdd1/disk0-vm-kbuild-yocto-i386-53,media=disk,if=virtio -pidfile /dev/shm/kboot/pid-vm-kbuild-yocto-i386-53 -serial file:/dev/shm/kboot/serial-vm-kbuild-yocto-i386-53 -daemonize -display none -monitor null
[-- Attachment #3: dmesg-vm-vp-quantal-i386-14:20150910072356:i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED:4.2.0-rc1-00077-g2d0f6ef:1 --]
[-- Type: text/plain, Size: 41761 bytes --]
early console in setup code
[ 0.000000] Linux version 4.2.0-rc1-00077-g2d0f6ef (kbuild@ivytown2) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 Thu Sep 10 07:20:01 CST 2015
[ 0.000000] KERNEL supported cpus:
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] Transmeta GenuineTMx86
[ 0.000000] Transmeta TransmetaCPU
[ 0.000000] UMC UMC UMC UMC
[ 0.000000] CPU: vendor_id 'GenuineIntel' unknown, using generic init.
[ 0.000000] CPU: Your system may be unstable.
[ 0.000000] x86/fpu: xstate_offset[2]: 0240, xstate_sizes[2]: 0100
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 0x340 bytes, using 'standard' format.
[ 0.000000] x86/fpu: Using 'eager' 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-0x00000000167dffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000167e0000-0x00000000167fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ 0.000000] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!
[ 0.000000] SMBIOS 2.8 present.
[ 0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 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 = 0x167e0 max_arch_pfn = 0x100000
[ 0.000000] initial memory mapped: [mem 0x00000000-0x09ffffff]
[ 0.000000] Base memory trampoline at [7809b000] 9b000 size 16384
[ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[ 0.000000] [mem 0x00000000-0x000fffff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x14800000-0x14bfffff]
[ 0.000000] [mem 0x14800000-0x14bfffff] page 4k
[ 0.000000] BRK [0x09878000, 0x09878fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x00100000-0x147fffff]
[ 0.000000] [mem 0x00100000-0x147fffff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x14c00000-0x167dffff]
[ 0.000000] [mem 0x14c00000-0x167dffff] page 4k
[ 0.000000] BRK [0x09879000, 0x09879fff] PGTABLE
[ 0.000000] BRK [0x0987a000, 0x0987afff] PGTABLE
[ 0.000000] BRK [0x0987b000, 0x0987bfff] PGTABLE
[ 0.000000] BRK [0x0987c000, 0x0987cfff] PGTABLE
[ 0.000000] BRK [0x0987d000, 0x0987dfff] PGTABLE
[ 0.000000] RAMDISK: [mem 0x14e9c000-0x167d7fff]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x00000000000F0CF0 000014 (v00 BOCHS )
[ 0.000000] ACPI: RSDT 0x00000000167E1854 000034 (v01 BOCHS BXPCRSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: FACP 0x00000000167E0B37 000074 (v01 BOCHS BXPCFACP 00000001 BXPC 00000001)
[ 0.000000] ACPI: DSDT 0x00000000167E0040 000AF7 (v01 BOCHS BXPCDSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: FACS 0x00000000167E0000 000040
[ 0.000000] ACPI: SSDT 0x00000000167E0BAB 000BF9 (v01 BOCHS BXPCSSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: APIC 0x00000000167E17A4 000078 (v01 BOCHS BXPCAPIC 00000001 BXPC 00000001)
[ 0.000000] ACPI: HPET 0x00000000167E181C 000038 (v01 BOCHS BXPCHPET 00000001 BXPC 00000001)
[ 0.000000] 0MB HIGHMEM available.
[ 0.000000] 359MB LOWMEM available.
[ 0.000000] mapped low ram: 0 - 167e0000
[ 0.000000] low ram: 0 - 167e0000
[ 0.000000] cma: dma_contiguous_reserve(limit 167e0000)
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.000000] kvm-clock: cpu 0, msr 0:167df001, primary cpu clock
[ 0.000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.000000] Normal [mem 0x0000000001000000-0x00000000167dffff]
[ 0.000000] HighMem empty
[ 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-0x00000000167dffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x00000000167dffff]
[ 0.000000] On node 0 totalpages: 92030
[ 0.000000] free_area_init_node: node 0, pgdat 80d69aa0, node_mem_map 8c904020
[ 0.000000] DMA zone: 32 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 3998 pages, LIFO batch:0
[ 0.000000] Normal zone: 688 pages used for memmap
[ 0.000000] Normal zone: 88032 pages, LIFO batch:15
[ 0.000000] ACPI: PM-Timer IO Port: 0x608
[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.000000] KVM setup async PF for cpu 0
[ 0.000000] kvm-stealtime: cpu 0, msr 8cd2480
[ 0.000000] e820: [mem 0x16800000-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] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 91310
[ 0.000000] Kernel command line: root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-vp-quantal-i386-14/rand_boot-1-quantal-core-i386.cgz-i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED-2d0f6efd311165fe06cecb29475e89e550b92d8c-20150910-115223-4s69ck-1.yaml ARCH=i386 kconfig=i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED branch=linux-devel/devel-spot-201509091835 commit=2d0f6efd311165fe06cecb29475e89e550b92d8c BOOT_IMAGE=/pkg/linux/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/2d0f6efd311165fe06cecb29475e89e550b92d8c/vmlinuz-4.2.0-rc1-00077-g2d0f6ef max_uptime=600 RESULT_ROOT=/result/boot/1/vm-vp-quantal-i386/quantal-core-i386.cgz/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/2d0f6efd311165fe06cecb29475e89e550b92d8c/1 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 console=tt
[ 0.000000] sysrq: sysrq always enabled.
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Initializing CPU#0
[ 0.000000] Initializing HighMem for node 0 (00000000:00000000)
[ 0.000000] Memory: 315652K/368120K available (6670K kernel code, 2694K rwdata, 4344K rodata, 584K init, 8540K bss, 52468K reserved, 0K cma-reserved, 0K highmem)
[ 0.000000] virtual kernel memory layout:
[ 0.000000] fixmap : 0xfffe3000 - 0xfffff000 ( 112 kB)
[ 0.000000] pkmap : 0xff800000 - 0xffc00000 (4096 kB)
[ 0.000000] vmalloc : 0x8efe0000 - 0xff7fe000 (1800 MB)
[ 0.000000] lowmem : 0x78000000 - 0x8e7e0000 ( 359 MB)
[ 0.000000] .init : 0x80f66000 - 0x80ff8000 ( 584 kB)
[ 0.000000] .data : 0x80883c6c - 0x80f64a40 (7043 kB)
[ 0.000000] .text : 0x80200000 - 0x80883c6c (6671 kB)
[ 0.000000] Checking if this processor honours the WP bit even in supervisor mode...Ok.
[ 0.000000] Running RCU self tests
[ 0.000000]
[ 0.000000] **********************************************************
[ 0.000000] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
[ 0.000000] ** **
[ 0.000000] ** trace_printk() being used. Allocating extra memory. **
[ 0.000000] ** **
[ 0.000000] ** This means that this is a DEBUG kernel and it is **
[ 0.000000] ** unsafe for production use. **
[ 0.000000] ** **
[ 0.000000] ** If you see this message and you are not debugging **
[ 0.000000] ** the kernel, report this immediately to your vendor! **
[ 0.000000] ** **
[ 0.000000] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
[ 0.000000] **********************************************************
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] CPU 0 irqstacks, hard=8c586000 soft=8c588000
[ 0.000000] console [ttyS0] enabled
[ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.000000] ... MAX_LOCK_DEPTH: 48
[ 0.000000] ... MAX_LOCKDEP_KEYS: 8191
[ 0.000000] ... CLASSHASH_SIZE: 4096
[ 0.000000] ... MAX_LOCKDEP_ENTRIES: 32768
[ 0.000000] ... MAX_LOCKDEP_CHAINS: 65536
[ 0.000000] ... CHAINHASH_SIZE: 32768
[ 0.000000] memory used by lock dependency info: 4911 kB
[ 0.000000] per task-struct memory footprint: 1344 bytes
[ 0.000000] ------------------------
[ 0.000000] | Locking API testsuite:
[ 0.000000] ----------------------------------------------------------------------------
[ 0.000000] | spin |wlock |rlock |mutex | wsem | rsem |
[ 0.000000] --------------------------------------------------------------------------
[ 0.000000] A-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-B-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] double unlock: ok | ok | ok | ok | ok | ok |
[ 0.000000] initialize held: ok | ok | ok | ok | ok | ok |
[ 0.000000] bad unlock order: ok | ok | ok | ok | ok | ok |
[ 0.000000] --------------------------------------------------------------------------
[ 0.000000] recursive read-lock: | ok | | ok |
[ 0.000000] recursive read-lock #2: | ok | | ok |
[ 0.000000] mixed read-write-lock: | ok | | ok |
[ 0.000000] mixed write-read-lock: | ok | | ok |
[ 0.000000] --------------------------------------------------------------------------
[ 0.000000] hard-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 0.000000] soft-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 0.000000] hard-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 0.000000] soft-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 0.000000] sirq-safe-A => hirqs-on/12: ok | ok | ok |
[ 0.000000] sirq-safe-A => hirqs-on/21: ok | ok | ok |
[ 0.000000] hard-safe-A + irqs-on/12: ok | ok | ok |
[ 0.000000] soft-safe-A + irqs-on/12: ok | ok | ok |
[ 0.000000] hard-safe-A + irqs-on/21: ok | ok | ok |
[ 0.000000] soft-safe-A + irqs-on/21: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 0.000000] hard-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 0.000000] soft-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/123: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/123: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/132: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/132: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/213: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/213: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/231: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/231: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/312: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/312: ok | ok | ok |
[ 0.000000] hard-irq lock-inversion/321: ok | ok | ok |
[ 0.000000] soft-irq lock-inversion/321: ok | ok | ok |
[ 0.000000] hard-irq read-recursion/123: ok |
[ 0.000000] soft-irq read-recursion/123: ok |
[ 0.000000] hard-irq read-recursion/132: ok |
[ 0.000000] soft-irq read-recursion/132: ok |
[ 0.000000] hard-irq read-recursion/213: ok |
[ 0.000000] soft-irq read-recursion/213: ok |
[ 0.000000] hard-irq read-recursion/231: ok |
[ 0.000000] soft-irq read-recursion/231: ok |
[ 0.000000] hard-irq read-recursion/312: ok |
[ 0.000000] soft-irq read-recursion/312: ok |
[ 0.000000] hard-irq read-recursion/321: ok |
[ 0.000000] soft-irq read-recursion/321: ok |
[ 0.000000] --------------------------------------------------------------------------
[ 0.000000] | Wound/wait tests |
[ 0.000000] ---------------------
[ 0.000000] ww api failures: ok | ok | ok |
[ 0.000000] ww contexts mixing: ok | ok |
[ 0.000000] finishing ww context: ok | ok | ok | ok |
[ 0.000000] locking mismatches: ok | ok | ok |
[ 0.000000] EDEADLK handling: ok | ok | ok | ok | ok | ok | ok | ok | ok | ok |
[ 0.000000] spinlock nest unlocked: ok |
[ 0.000000] -----------------------------------------------------
[ 0.000000] |block | try |context|
[ 0.000000] -----------------------------------------------------
[ 0.000000] context: ok | ok | ok |
[ 0.000000] try: ok | ok | ok |
[ 0.000000] block: ok | ok | ok |
[ 0.000000] spinlock: ok | ok | ok |
[ 0.000000] -------------------------------------------------------
[ 0.000000] Good, all 253 testcases passed! |
[ 0.000000] ---------------------------------
[ 0.000000] ODEBUG: selftest passed
[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
[ 0.000000] hpet clockevent registered
[ 0.000000] tsc: Detected 2693.508 MHz processor
[ 0.299252] Calibrating delay loop (skipped) preset value.. 5387.01 BogoMIPS (lpj=2693508)
[ 0.300486] pid_max: default: 4096 minimum: 301
[ 0.301182] ACPI: Core revision 20150619
[ 0.307648] ACPI: All ACPI Tables successfully acquired
[ 0.308215] ACPI: setting ELCR to 0200 (from 0c00)
[ 0.308692] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.309310] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.310563] mce: CPU supports 10 MCE banks
[ 0.310998] mce: unknown CPU type - not enabling MCE support
[ 0.311495] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[ 0.312015] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[ 0.312528] CPU: GenuineIntel Intel Core Processor (Haswell) (fam: 06, model: 3c, stepping: 01)
[ 0.314560] Performance Events: no PMU driver, software events only.
[ 0.316373] devtmpfs: initialized
[ 0.318127] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[ 0.319205] atomic64_test: passed for i586+ platform with CX8 and with SSE
[ 0.320856] NET: Registered protocol family 16
[ 0.322213] cpuidle: using governor ladder
[ 0.322594] cpuidle: using governor menu
[ 0.323546] ACPI: bus type PCI registered
[ 0.324245] PCI: PCI BIOS revision 2.10 entry at 0xfd456, last bus=0
[ 0.324879] PCI: Using configuration type 1 for base access
[ 0.333253] gpio-f7188x: Not a Fintek device at 0x0000002e
[ 0.333780] gpio-f7188x: Not a Fintek device at 0x0000004e
[ 0.334648] ACPI: Added _OSI(Module Device)
[ 0.335087] ACPI: Added _OSI(Processor Device)
[ 0.335510] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.335986] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.341379] ACPI: Interpreter enabled
[ 0.341733] ACPI: (supports S0 S5)
[ 0.342087] ACPI: Using PIC for interrupt routing
[ 0.342572] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.354243] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.354864] acpi PNP0A03:00: _OSC: OS supports [Segments]
[ 0.355437] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[ 0.356298] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[ 0.357567] PCI host bridge to bus 0000:00
[ 0.357998] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.358514] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
[ 0.359184] pci_bus 0000:00: root bus resource [io 0x0d00-0xadff window]
[ 0.359827] pci_bus 0000:00: root bus resource [io 0xae0f-0xaeff window]
[ 0.360458] pci_bus 0000:00: root bus resource [io 0xaf20-0xafdf window]
[ 0.361111] pci_bus 0000:00: root bus resource [io 0xafe4-0xffff window]
[ 0.361743] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 0.362456] pci_bus 0000:00: root bus resource [mem 0x16800000-0xfebfffff window]
[ 0.363257] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[ 0.364455] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[ 0.365708] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[ 0.368668] pci 0000:00:01.1: reg 0x20: [io 0xc040-0xc04f]
[ 0.370156] pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7]
[ 0.370854] pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io 0x03f6]
[ 0.371462] pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177]
[ 0.372153] pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io 0x0376]
[ 0.373113] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
[ 0.374043] pci 0000:00:01.3: can't claim BAR 7 [io 0x0600-0x063f]: address conflict with ACPI PM1a_EVT_BLK [io 0x0600-0x0603]
[ 0.375175] pci 0000:00:01.3: quirk: [io 0x0700-0x070f] claimed by PIIX4 SMB
[ 0.376277] pci 0000:00:02.0: [1013:00b8] type 00 class 0x030000
[ 0.377900] pci 0000:00:02.0: reg 0x10: [mem 0xfc000000-0xfdffffff pref]
[ 0.379465] pci 0000:00:02.0: reg 0x14: [mem 0xfebf0000-0xfebf0fff]
[ 0.385037] pci 0000:00:02.0: reg 0x30: [mem 0xfebe0000-0xfebeffff pref]
[ 0.386711] pci 0000:00:03.0: [8086:100e] type 00 class 0x020000
[ 0.388894] pci 0000:00:03.0: reg 0x10: [mem 0xfebc0000-0xfebdffff]
[ 0.390970] pci 0000:00:03.0: reg 0x14: [io 0xc000-0xc03f]
[ 0.397403] pci 0000:00:03.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref]
[ 0.398927] pci 0000:00:04.0: [8086:25ab] type 00 class 0x088000
[ 0.400265] pci 0000:00:04.0: reg 0x10: [mem 0xfebf1000-0xfebf100f]
[ 0.404866] pci_bus 0000:00: on NUMA node 0
[ 0.406289] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[ 0.407161] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[ 0.407998] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[ 0.408788] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[ 0.409498] ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
[ 0.410520] ACPI: Enabled 16 GPEs in block 00 to 0F
[ 0.412056] vgaarb: setting as boot device: PCI:0000:00:02.0
[ 0.412558] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.413322] vgaarb: loaded
[ 0.413573] vgaarb: bridge control possible 0000:00:02.0
[ 0.414774] media: Linux media interface: v0.10
[ 0.415256] Linux video capture interface: v2.00
[ 0.415998] PCI: Using ACPI for IRQ routing
[ 0.416382] PCI: pci_cache_line_size set to 64 bytes
[ 0.416984] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
[ 0.417526] e820: reserve RAM buffer [mem 0x167e0000-0x17ffffff]
[ 0.419292] clocksource: Switched to clocksource kvm-clock
[ 0.421304] Warning: could not register all branches stats
[ 0.421872] Warning: could not register annotated branches stats
[ 0.434690] FS-Cache: Loaded
[ 0.435033] pnp: PnP ACPI init
[ 0.435573] pnp 00:00: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.436258] pnp 00:01: Plug and Play ACPI device, IDs PNP0303 (active)
[ 0.436978] pnp 00:02: Plug and Play ACPI device, IDs PNP0f13 (active)
[ 0.437739] pnp 00:03: [dma 2]
[ 0.438075] pnp 00:03: Plug and Play ACPI device, IDs PNP0700 (active)
[ 0.438865] pnp 00:04: Plug and Play ACPI device, IDs PNP0400 (active)
[ 0.439646] pnp 00:05: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.440926] pnp: PnP ACPI: found 6 devices
[ 0.476686] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 0.477668] pci 0000:00:01.3: BAR 7: [io size 0x0040] has bogus alignment
[ 0.478290] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window]
[ 0.478898] pci_bus 0000:00: resource 5 [io 0x0d00-0xadff window]
[ 0.479520] pci_bus 0000:00: resource 6 [io 0xae0f-0xaeff window]
[ 0.480073] pci_bus 0000:00: resource 7 [io 0xaf20-0xafdf window]
[ 0.480683] pci_bus 0000:00: resource 8 [io 0xafe4-0xffff window]
[ 0.481230] pci_bus 0000:00: resource 9 [mem 0x000a0000-0x000bffff window]
[ 0.481894] pci_bus 0000:00: resource 10 [mem 0x16800000-0xfebfffff window]
[ 0.482641] NET: Registered protocol family 1
[ 0.483062] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[ 0.483672] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[ 0.484203] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[ 0.484841] pci 0000:00:02.0: Video device with shadowed ROM
[ 0.485452] PCI: CLS 0 bytes, default 64
[ 0.486071] Unpacking initramfs...
[ 1.559938] debug: unmapping init [mem 0x8ce9c000-0x8e7d7fff]
[ 1.561495] Machine check injector initialized
[ 1.561925] microcode: no support for this CPU vendor
[ 1.563854] NatSemi SCx200 Driver
[ 1.564274] spin_lock-torture:--- Start of test [debug]: nwriters_stress=2 nreaders_stress=0 stat_interval=60 verbose=1 shuffle_interval=3 stutter=5 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0
[ 1.565793] spin_lock-torture: Creating torture_shuffle task
[ 1.566423] spin_lock-torture: Creating torture_stutter task
[ 1.566956] spin_lock-torture: torture_shuffle task started
[ 1.567504] spin_lock-torture: Creating lock_torture_writer task
[ 1.568066] spin_lock-torture: torture_stutter task started
[ 1.568609] spin_lock-torture: Creating lock_torture_writer task
[ 1.569165] spin_lock-torture: lock_torture_writer task started
[ 1.569762] spin_lock-torture: Creating lock_torture_stats task
[ 1.570393] spin_lock-torture: lock_torture_writer task started
[ 1.571253] futex hash table entries: 16 (order: -3, 704 bytes)
[ 1.571833] Initialise system trusted keyring
[ 1.573022] spin_lock-torture: lock_torture_stats task started
[ 1.575957] HugeTLB registered 4 MB page size, pre-allocated 0 pages
[ 1.576640] zpool: loaded
[ 1.577084] VFS: Disk quotas dquot_6.6.0
[ 1.577501] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 1.579397] romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
[ 1.579852] fuse init (API version 7.23)
[ 1.590756] Key type asymmetric registered
[ 1.591140] start plist test
[ 1.597292] end plist test
[ 1.597582] test_hexdump: Running tests...
[ 1.598376] test_firmware: interface ready
[ 1.598804] rbtree testing -> 17612 cycles
[ 2.319108] augmented rbtree testing -> 28440 cycles
[ 3.466240] ipmi message handler version 39.2
[ 3.466720] IPMI System Interface driver.
[ 3.467170] ipmi_si: Adding default-specified kcs state machine
[ 3.467756] ipmi_si: Trying default-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0
[ 3.468656] ipmi_si: Interface detection failed
[ 3.469104] tsc: Refined TSC clocksource calibration: 2693.507 MHz
[ 3.469702] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x26d348cd811, max_idle_ns: 440795335366 ns
[ 3.534398] ipmi_si: Adding default-specified smic state machine
[ 3.534974] ipmi_si: Trying default-specified smic state machine at i/o address 0xca9, slave address 0x0, irq 0
[ 3.535891] ipmi_si: Interface detection failed
[ 3.536306] ipmi_si: Adding default-specified bt state machine
[ 3.536867] ipmi_si: Trying default-specified bt state machine at i/o address 0xe4, slave address 0x0, irq 0
[ 3.537763] ipmi_si: Interface detection failed
[ 3.538421] ipmi_si: Unable to find any System Interface(s)
[ 3.538961] IPMI Watchdog: driver initialized
[ 3.539669] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[ 3.540413] ACPI: Power Button [PWRF]
[ 3.569952] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 3.594247] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 3.596137] lp: driver loaded but no devices found
[ 3.596626] toshiba: not a supported Toshiba laptop
[ 3.597086] ppdev: user-space parallel port driver
[ 3.597563] scx200_gpio: no SCx200 gpio present
[ 3.597982] nsc_gpio initializing
[ 3.598297] telclk_interrupt = 0xf non-mcpbl0010 hw.
[ 3.598794] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds).
[ 3.599892] [drm] Initialized drm 1.1.0 20060810
[ 3.601957] dummy-irq: no IRQ given. Use irq=N
[ 3.603596] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 3.604200] L440GX flash mapping: failed to find PIIX4 ISA bridge, cannot continue
[ 3.605022] slram: not enough parameters.
[ 3.607959] HSI/SSI char device loaded
[ 3.608657] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
[ 3.610102] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 3.610619] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 3.611109] parkbd: no such parport
[ 3.657005] walkera0701: parport 0 does not exist
[ 3.657854] mk712: device not present
[ 3.658579] i2c /dev entries driver
[ 3.659517] Error: Driver 'adv7511' is already registered, aborting...
[ 3.661021] Driver for 1-wire Dallas network protocol.
[ 3.661598] DS1WM w1 busmaster driver - (c) 2004 Szabolcs Gyurko
[ 3.662242] 1-Wire driver for the DS2760 battery monitor chip - (c) 2004-2005, Szabolcs Gyurko
[ 3.664131] f71882fg: Not a Fintek device
[ 3.664578] f71882fg: Not a Fintek device
[ 3.665972] pc87360: PC8736x not detected, module not inserted
[ 3.668618] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
[ 3.672219] cros_ec_lpc: unsupported system.
[ 3.673113] pss: mss_io, mss_dma, mss_irq and pss_io must be set.
[ 3.673705] ad1848/cs4248 codec driver Copyright (C) by Hannu Savolainen 1993-1996
[ 3.674419] ad1848: No ISAPnP cards found, trying standard ones...
[ 3.674999] MediaTrix audio driver Copyright (C) by Hannu Savolainen 1993-1996
[ 3.675665] I/O, IRQ, DMA and type are mandatory
[ 3.676108] uart6850: irq and io must be set.
[ 3.676540] YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft 1993-1996
[ 3.677291] MIDI Loopback device driver
[ 3.677845] mce: Unable to init device /dev/mcelog (rc: -5)
[ 3.679945] Loading compiled-in X.509 certificates
[ 3.680447] page_owner is disabled
[ 3.683389] device-tree: Duplicate name in testcase-data, renamed to "duplicate-name#1"
[ 3.686019] ### dt-test ### start of unittest - you will see error messages
[ 3.686890] /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider1
[ 3.687953] /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider1
[ 3.689024] /testcase-data/phandle-tests/consumer-a: could not find phandle
[ 3.689689] /testcase-data/phandle-tests/consumer-a: could not find phandle
[ 3.690359] /testcase-data/phandle-tests/consumer-a: arguments longer than property
[ 3.691040] /testcase-data/phandle-tests/consumer-a: arguments longer than property
[ 3.692074] irq: no irq domain found for /testcase-data/interrupts/intc0 !
[ 3.695880] overlay_is_topmost: #5 clashes #6 @/testcase-data/overlay-node/test-bus/test-unittest8
[ 3.696708] overlay_removal_is_ok: overlay #5 is not topmost
[ 3.697231] of_overlay_destroy: removal check failed for overlay #5
[ 3.700512] i2c i2c-0: Added multiplexed i2c bus 1
[ 3.702213] i2c i2c-0: Added multiplexed i2c bus 2
[ 3.702716] i2c i2c-2: Failed to register i2c client unittest-i2c-dev at 0x20 (-16)
[ 3.703443] i2c i2c-2: of_i2c: Failure registering /testcase-data/overlay-node/test-bus/i2c-test-bus/test-unittest15/i2c@0/test-mux-dev
[ 3.704548] of_i2c_notify: failed to create for '/testcase-data/overlay-node/test-bus/i2c-test-bus/test-unittest15/i2c@0/test-mux-dev'
[ 3.705649] __of_changeset_entry_notify: notifier error @/testcase-data/overlay-node/test-bus/i2c-test-bus/test-unittest15/i2c@0/test-mux-dev
[ 3.709135] ### dt-test ### end of unittest - 149 passed, 0 failed
[ 3.710543] debug: unmapping init [mem 0x80f66000-0x80ff7fff]
[ 3.711206] Write protecting the kernel text: 6672k
[ 3.711762] Write protecting the kernel read-only data: 4348k
[ 3.721065] random: init urandom read with 53 bits of entropy available
[ 3.806105] init: Failed to create pty - disabling logging for job
[ 3.806815] init: Temporary process spawn error: No space left on device
[ 3.932735] udevd[200]: starting version 175
udevd[207]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:LNXSYSTM:': No such file or directory
udevd[220]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv pci:v00008086d00007000sv00001AF4sd00001100bc06sc01i00': No such file or directory
udevd[221]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv pci:v00008086d00007010sv00001AF4sd00001100bc01sc01i80': No such file or directory
udevd[222]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv pci:v00008086d00007113sv00001AF4sd00001100bc06sc80i00': No such file or directory
udevd[228]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv pci:v00001013d000000B8sv00001AF4sd00001100bc03sc00i00': No such file or directory
udevd[229]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv pci:v00008086d0000100Esv00001AF4sd00001100bc02sc00i00': No such file or directory
udevd[230]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv pci:v00008086d00001237sv00001AF4sd00001100bc06sc00i00': No such file or directory
udevd[231]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv pci:v00008086d000025ABsv00001AF4sd00001100bc08sc80i00': No such file or directory
udevd[232]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0103:': No such file or directory
udevd[233]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv platform:platform-framebuffer': No such file or directory
udevd[234]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv of:Ni2c-test-busT<NULL>Cunittest-i2c-bus': No such file or directory
udevd[235]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:LNXSYBUS:': No such file or directory
udevd[236]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:LNXSYBUS:': No such file or directory
udevd[237]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv serio:ty01pr00id00ex00': No such file or directory
udevd[239]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv input:b0019v0000p0001e0000-e0,1,k74,ramlsfw': No such file or directory
udevd[247]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0C0F:': No such file or directory
udevd[248]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0C0F:': No such file or directory
udevd[245]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0C0F:': No such file or directory
udevd[246]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0C0F:': No such file or directory
udevd[244]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0C0F:': No such file or directory
udevd[243]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0A06:': No such file or directory
udevd[242]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0A03:': No such file or directory
udevd[241]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0103:': No such file or directory
udevd[240]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:LNXCPU:': No such file or directory
udevd[249]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv input:b0011v0001p0001eAB41-e0,1,4,11,14,k71,72,73,74,75,76,77,79,7A,7B,7C,7D,7E,7F,80,8C,8E,8F,9B,9C,9D,9E,9F,A3,A4,A5,A6,AC,AD,B7,B8,B9,D9,E2,ram4,l0,1,2,sfw': No such file or directory
udevd[250]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv of:Ntestcase-device1T<NULL>Ctestcase-device': No such file or directory
udevd[251]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0A06:': No such file or directory
udevd[277]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:APP0001:': No such file or directory
udevd[278]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0303:': No such file or directory
udevd[279]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv of:Ntestcase-device2T<NULL>Ctestcase-device': No such file or directory
udevd[280]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0400:': No such file or directory
udevd[281]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0501:': No such file or directory
udevd[285]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0F13:': No such file or directory
udevd[286]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:QEMU0001:': No such file or directory
udevd[284]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0B00:': No such file or directory
udevd[283]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0700:': No such file or directory
udevd[282]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0501:': No such file or directory
[ 4.584484] init: failsafe main process (295) killed by TERM signal
start: Job is already running: rc
[ 5.072617] init: udev-fallback-graphics main process (343) terminated with status 127
==> /tmp/stdout <==
==> /tmp/stderr <==
==> /tmp/stdout <==
==> /tmp/stderr <==
[ 5.120231] init: networking main process (354) terminated with status 1
cat: cat: /proc/sys/kernel/version/proc/sys/kernel/version: No such file or directory: No such file or directory
cat: cat: /proc/sys/kernel/osrelease/proc/sys/kernel/osrelease: No such file or directory: No such file or directory
LKP: HOSTNAME vm-vp-quantal-i386-14, MAC , kernel , serial console /dev/ttyS0
==> /tmp/stdout <==
Kernel tests: Boot OK!
==> /tmp/stdout <==
Kernel tests: Boot OK!
==> /tmp/stderr <==
ipconfig: no devices to configure
==> /tmp/stderr <==
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
ipconfig: no devices to configure
/usr/share/initramfs-tools/scripts/functions: line 491: /run/net-eth0.conf: No such file or directory
/usr/share/initramfs-tools/scripts/functions: line 491: /run/net-eth0.conf: No such file or directory
!!! IP-Config: Auto-configuration of network failed !!!
!!! IP-Config: Auto-configuration of network failed !!!
!!! IP-Config: Auto-configuration of network failed !!!
error: 'lkp-bootstrap' exited outside the expected code flow.
[ 5.250673] init: rc main process (329) killed by TERM signal
[ 5.251696] init: tty4 main process (330) killed by TERM signal
[ 5.255905] init: tty5 main process (331) killed by TERM signal
[ 5.258240] init: tty2 main process (332) killed by TERM signal
unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[ 5.260644] init: tty3 main process (333) killed by TERM signal
[ 5.261973] init: tty6 main process (335) killed by TERM signal
[ 5.263487] init: hwclock-save main process (404) terminated with status 70
[ 5.264850] init: plymouth-upstart-bridge main process (405) terminated with status 1
[ 5.357309] Unregister pv shared memory for cpu 0
[ 5.357866] spin_lock-torture: Unscheduled system shutdown detected
[ 5.359124] reboot: Restarting system
[ 5.359446] reboot: machine restart
Elapsed time: 10
qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -kernel /pkg/linux/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/2d0f6efd311165fe06cecb29475e89e550b92d8c/vmlinuz-4.2.0-rc1-00077-g2d0f6ef -append 'root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-vp-quantal-i386-14/rand_boot-1-quantal-core-i386.cgz-i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED-2d0f6efd311165fe06cecb29475e89e550b92d8c-20150910-115223-4s69ck-1.yaml ARCH=i386 kconfig=i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED branch=linux-devel/devel-spot-201509091835 commit=2d0f6efd311165fe06cecb29475e89e550b92d8c BOOT_IMAGE=/pkg/linux/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/2d0f6efd311165fe06cecb29475e89e550b92d8c/vmlinuz-4.2.0-rc1-00077-g2d0f6ef max_uptime=600 RESULT_ROOT=/result/boot/1/vm-vp-quantal-i386/quantal-core-i386.cgz/i386-randconfig-h1-09092111+CONFIG_DEBUG_INFO_REDUCED/gcc-4.9/2d0f6efd311165fe06cecb29475e89e550b92d8c/1 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw ip=::::vm-vp-quantal-i386-14::dhcp drbd.minor_count=8' -initrd /fs/sdc1/initrd-vm-vp-quantal-i386-14 -m 360 -smp 1 -device e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -rtc base=localtime -pidfile /dev/shm/kboot/pid-vm-vp-quantal-i386-14 -serial file:/dev/shm/kboot/serial-vm-vp-quantal-i386-14 -daemonize -display none -monitor null
[-- Attachment #4: config-4.2.0-rc1-00078-gd0a795e --]
[-- Type: text/plain, Size: 72608 bytes --]
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.2.0-rc1 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_SCHED is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
# CONFIG_PCSPKR_PLATFORM is not set
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_PCI_QUIRKS=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_JUMP_LABEL=y
# CONFIG_UPROBES is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_CC_STACKPROTECTOR_NONE=y
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_COPY_THREAD_TLS=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=1
# CONFIG_MODULES is not set
CONFIG_MODULES_TREE_LOOKUP=y
# CONFIG_BLOCK is not set
CONFIG_ASN1=y
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
# CONFIG_FREEZER is not set
#
# Processor type and features
#
CONFIG_ZONE_DMA=y
# CONFIG_SMP is not set
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_GOLDFISH is not set
# CONFIG_X86_INTEL_LPSS is not set
# CONFIG_X86_AMD_PLATFORM_DEVICE is not set
# CONFIG_IOSF_MBI is not set
CONFIG_X86_RDC321X=y
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_X86_32_IRIS is not set
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
CONFIG_HYPERVISOR_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_KVM_GUEST=y
# CONFIG_KVM_DEBUG_FS is not set
# CONFIG_LGUEST_GUEST is not set
# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
CONFIG_PARAVIRT_CLOCK=y
CONFIG_NO_BOOTMEM=y
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MELAN is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_INTERNODE_CACHE_SHIFT=5
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_PROCESSOR_SELECT=y
# CONFIG_CPU_SUP_INTEL is not set
# CONFIG_CPU_SUP_CYRIX_32 is not set
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
CONFIG_HPET_TIMER=y
CONFIG_DMI=y
CONFIG_NR_CPUS=1
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_MCE=y
# CONFIG_X86_ANCIENT_MCE is not set
CONFIG_X86_MCE_INJECT=y
CONFIG_VM86=y
CONFIG_X86_16BIT=y
CONFIG_X86_ESPFIX32=y
CONFIG_TOSHIBA=y
CONFIG_I8K=y
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD_EARLY=y
CONFIG_MICROCODE_EARLY=y
CONFIG_X86_MSR=y
# CONFIG_X86_CPUID is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
# CONFIG_VMSPLIT_3G is not set
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
CONFIG_VMSPLIT_2G_OPT=y
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0x78000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_VIRT_TO_BUS=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_MEMORY_FAILURE=y
# CONFIG_HWPOISON_INJECT is not set
CONFIG_TRANSPARENT_HUGEPAGE=y
# CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
CONFIG_NEED_PER_CPU_KM=y
CONFIG_CLEANCACHE=y
CONFIG_CMA=y
CONFIG_CMA_DEBUG=y
CONFIG_CMA_DEBUGFS=y
CONFIG_CMA_AREAS=7
CONFIG_ZPOOL=y
# CONFIG_ZBUD is not set
CONFIG_ZSMALLOC=y
# CONFIG_PGTABLE_MAPPING is not set
# CONFIG_ZSMALLOC_STAT is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT=y
# CONFIG_HIGHPTE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MATH_EMULATION=y
# CONFIG_MTRR is not set
# CONFIG_ARCH_RANDOM is not set
CONFIG_X86_SMAP=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_RANDOMIZE_BASE=y
CONFIG_RANDOMIZE_BASE_MAX_OFFSET=0x20000000
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x200000
CONFIG_COMPAT_VDSO=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management and ACPI options
#
# CONFIG_SUSPEND is not set
# CONFIG_PM is not set
CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
# CONFIG_ACPI_VIDEO is not set
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
# CONFIG_ACPI_IPMI is not set
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_CUSTOM_METHOD is not set
# CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set
CONFIG_HAVE_ACPI_APEI=y
CONFIG_HAVE_ACPI_APEI_NMI=y
# CONFIG_ACPI_APEI is not set
# CONFIG_PMIC_OPREGION is not set
# CONFIG_SFI is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# CPU Idle
#
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
# CONFIG_PCI_GOOLPC is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_OLPC=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
# CONFIG_PCI_IOV is not set
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
CONFIG_PCI_LABEL=y
#
# PCI host controller drivers
#
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
CONFIG_SCx200=y
CONFIG_SCx200HR_TIMER=y
CONFIG_OLPC=y
# CONFIG_OLPC_XO15_SCI is not set
# CONFIG_ALIX is not set
# CONFIG_NET5501 is not set
# CONFIG_GEOS is not set
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA is not set
CONFIG_CARDBUS=y
#
# PC-card bridges
#
# CONFIG_YENTA is not set
# CONFIG_HOTPLUG_PCI is not set
# CONFIG_RAPIDIO is not set
# CONFIG_X86_SYSFB is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
# CONFIG_COREDUMP is not set
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_PMC_ATOM=y
CONFIG_NET=y
#
# Networking options
#
# CONFIG_PACKET is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
# CONFIG_NET_KEY is not set
# CONFIG_INET is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NET_PTP_CLASSIFY is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_DNS_RESOLVER is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_MPLS is not set
# CONFIG_HSR is not set
# CONFIG_CGROUP_NET_PRIO is not set
# CONFIG_CGROUP_NET_CLASSID is not set
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
#
# Network testing
#
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set
#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_MAC80211_STA_HASH_MAX_SIZE=0
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_NFC is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
# CONFIG_UEVENT_HELPER is not set
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
# CONFIG_ALLOW_DEV_COREDUMP is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_REGMAP_MMIO=y
CONFIG_REGMAP_IRQ=y
CONFIG_DMA_SHARED_BUFFER=y
# CONFIG_FENCE_TRACE is not set
CONFIG_DMA_CMA=y
#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=0
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
#
# Bus devices
#
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
CONFIG_MTD_REDBOOT_PARTS=y
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
CONFIG_MTD_REDBOOT_PARTS_READONLY=y
# CONFIG_MTD_CMDLINE_PARTS is not set
CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_AR7_PARTS=y
#
# User Modules And Translation Layers
#
CONFIG_MTD_OOPS=y
# CONFIG_MTD_PARTITIONED_MASTER is not set
#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
# CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_MAP_BANK_WIDTH_8=y
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
CONFIG_MTD_MAP_BANK_WIDTH_32=y
# CONFIG_MTD_CFI_I1 is not set
# CONFIG_MTD_CFI_I2 is not set
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_OTP=y
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
# CONFIG_MTD_PHYSMAP_COMPAT is not set
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_AMD76XROM=y
CONFIG_MTD_ICHXROM=y
# CONFIG_MTD_ESB2ROM is not set
# CONFIG_MTD_CK804XROM is not set
# CONFIG_MTD_SCB2_FLASH is not set
# CONFIG_MTD_NETtel is not set
CONFIG_MTD_L440GX=y
# CONFIG_MTD_INTEL_VR_NOR is not set
CONFIG_MTD_PLATRAM=y
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_SST25L is not set
CONFIG_MTD_SLRAM=y
CONFIG_MTD_PHRAM=y
CONFIG_MTD_MTDRAM=y
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTDRAM_ABS_POS=0
#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOCG3=y
CONFIG_BCH_CONST_M=14
CONFIG_BCH_CONST_T=4
# CONFIG_MTD_NAND is not set
CONFIG_MTD_ONENAND=y
# CONFIG_MTD_ONENAND_VERIFY_WRITE is not set
CONFIG_MTD_ONENAND_GENERIC=y
# CONFIG_MTD_ONENAND_OTP is not set
# CONFIG_MTD_ONENAND_2X_PROGRAM is not set
#
# LPDDR & LPDDR2 PCM memory drivers
#
CONFIG_MTD_LPDDR=y
CONFIG_MTD_QINFO_PROBE=y
# CONFIG_MTD_SPI_NOR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_GLUEBI=y
CONFIG_DTC=y
CONFIG_OF=y
CONFIG_OF_UNITTEST=y
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_PROMTREE=y
CONFIG_OF_DYNAMIC=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_ADDRESS_PCI=y
CONFIG_OF_IRQ=y
CONFIG_OF_PCI=y
CONFIG_OF_PCI_IRQ=y
CONFIG_OF_MTD=y
CONFIG_OF_RESOLVE=y
CONFIG_OF_OVERLAY=y
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
CONFIG_PARPORT=y
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y
#
# Protocols
#
CONFIG_PNPACPI=y
#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_AD525X_DPOT=y
CONFIG_AD525X_DPOT_I2C=y
CONFIG_AD525X_DPOT_SPI=y
CONFIG_DUMMY_IRQ=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
CONFIG_ENCLOSURE_SERVICES=y
# CONFIG_HP_ILO is not set
CONFIG_APDS9802ALS=y
CONFIG_ISL29003=y
CONFIG_ISL29020=y
CONFIG_SENSORS_TSL2550=y
# CONFIG_SENSORS_BH1780 is not set
CONFIG_SENSORS_BH1770=y
CONFIG_SENSORS_APDS990X=y
CONFIG_HMC6352=y
CONFIG_DS1682=y
CONFIG_TI_DAC7512=y
CONFIG_VMWARE_BALLOON=y
CONFIG_BMP085=y
CONFIG_BMP085_I2C=y
# CONFIG_BMP085_SPI is not set
# CONFIG_PCH_PHUB is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
CONFIG_LATTICE_ECP3_CONFIG=y
CONFIG_SRAM=y
# CONFIG_C2PORT is not set
#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
CONFIG_EEPROM_AT25=y
CONFIG_EEPROM_LEGACY=y
CONFIG_EEPROM_MAX6875=y
CONFIG_EEPROM_93CX6=y
CONFIG_EEPROM_93XX46=y
# CONFIG_CB710_CORE is not set
#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_I2C is not set
#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
# CONFIG_VMWARE_VMCI is not set
#
# Intel MIC Bus Driver
#
#
# SCIF Bus Driver
#
#
# Intel MIC Host Driver
#
#
# Intel MIC Card Driver
#
#
# SCIF Driver
#
CONFIG_ECHO=y
# CONFIG_CXL_BASE is not set
# CONFIG_CXL_KERNEL_API is not set
CONFIG_HAVE_IDE=y
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=y
# CONFIG_FIREWIRE_OHCI is not set
# CONFIG_FIREWIRE_NOSY is not set
CONFIG_MACINTOSH_DRIVERS=y
# CONFIG_NETDEVICES is not set
# CONFIG_VHOST_NET is not set
CONFIG_VHOST_CROSS_ENDIAN_LEGACY=y
#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_LEDS=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MATRIXKMAP=y
#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ADP5588=y
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
CONFIG_KEYBOARD_TCA6416=y
CONFIG_KEYBOARD_TCA8418=y
CONFIG_KEYBOARD_MATRIX=y
CONFIG_KEYBOARD_LM8323=y
CONFIG_KEYBOARD_LM8333=y
# CONFIG_KEYBOARD_MAX7359 is not set
CONFIG_KEYBOARD_MCS=y
CONFIG_KEYBOARD_MPR121=y
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_KEYBOARD_OPENCORES=y
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_KEYBOARD_SUNKBD=y
# CONFIG_KEYBOARD_STMPE is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_KEYBOARD_TC3589X is not set
CONFIG_KEYBOARD_TWL4030=y
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_KEYBOARD_CROS_EC=y
CONFIG_KEYBOARD_CAP11XX=y
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=y
# CONFIG_JOYSTICK_A3D is not set
CONFIG_JOYSTICK_ADI=y
CONFIG_JOYSTICK_COBRA=y
CONFIG_JOYSTICK_GF2K=y
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
CONFIG_JOYSTICK_GUILLEMOT=y
CONFIG_JOYSTICK_INTERACT=y
CONFIG_JOYSTICK_SIDEWINDER=y
CONFIG_JOYSTICK_TMDC=y
CONFIG_JOYSTICK_IFORCE=y
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=y
CONFIG_JOYSTICK_MAGELLAN=y
CONFIG_JOYSTICK_SPACEORB=y
CONFIG_JOYSTICK_SPACEBALL=y
# CONFIG_JOYSTICK_STINGER is not set
CONFIG_JOYSTICK_TWIDJOY=y
CONFIG_JOYSTICK_ZHENHUA=y
CONFIG_JOYSTICK_DB9=y
# CONFIG_JOYSTICK_GAMECON is not set
CONFIG_JOYSTICK_TURBOGRAFX=y
CONFIG_JOYSTICK_AS5011=y
CONFIG_JOYSTICK_JOYDUMP=y
# CONFIG_JOYSTICK_XPAD is not set
CONFIG_JOYSTICK_WALKERA0701=y
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
# CONFIG_TABLET_USB_AIPTEK is not set
# CONFIG_TABLET_USB_HANWANG is not set
# CONFIG_TABLET_USB_KBTAB is not set
CONFIG_TABLET_SERIAL_WACOM4=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_OF_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=y
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_AR1021_I2C is not set
CONFIG_TOUCHSCREEN_ATMEL_MXT=y
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
CONFIG_TOUCHSCREEN_CHIPONE_ICN8318=y
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set
CONFIG_TOUCHSCREEN_DA9034=y
CONFIG_TOUCHSCREEN_DA9052=y
CONFIG_TOUCHSCREEN_DYNAPRO=y
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
CONFIG_TOUCHSCREEN_EETI=y
CONFIG_TOUCHSCREEN_EGALAX=y
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GOODIX is not set
CONFIG_TOUCHSCREEN_ILI210X=y
CONFIG_TOUCHSCREEN_GUNZE=y
# CONFIG_TOUCHSCREEN_ELAN is not set
CONFIG_TOUCHSCREEN_ELO=y
CONFIG_TOUCHSCREEN_WACOM_W8001=y
CONFIG_TOUCHSCREEN_WACOM_I2C=y
# CONFIG_TOUCHSCREEN_MAX11801 is not set
CONFIG_TOUCHSCREEN_MCS5000=y
# CONFIG_TOUCHSCREEN_MMS114 is not set
CONFIG_TOUCHSCREEN_MTOUCH=y
# CONFIG_TOUCHSCREEN_INEXIO is not set
CONFIG_TOUCHSCREEN_MK712=y
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
CONFIG_TOUCHSCREEN_EDT_FT5X06=y
CONFIG_TOUCHSCREEN_TOUCHRIGHT=y
CONFIG_TOUCHSCREEN_TOUCHWIN=y
CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y
CONFIG_TOUCHSCREEN_PIXCIR=y
CONFIG_TOUCHSCREEN_WDT87XX_I2C=y
# CONFIG_TOUCHSCREEN_WM831X is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_MC13783 is not set
CONFIG_TOUCHSCREEN_TOUCHIT213=y
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
CONFIG_TOUCHSCREEN_TSC2007=y
CONFIG_TOUCHSCREEN_PCAP=y
CONFIG_TOUCHSCREEN_ST1232=y
CONFIG_TOUCHSCREEN_STMPE=y
# CONFIG_TOUCHSCREEN_SX8654 is not set
CONFIG_TOUCHSCREEN_TPS6507X=y
CONFIG_TOUCHSCREEN_ZFORCE=y
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_CT82C710=y
CONFIG_SERIO_PARKBD=y
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
CONFIG_SERIO_PS2MULT=y
CONFIG_SERIO_ARC_PS2=y
CONFIG_SERIO_APBPS2=y
# CONFIG_SERIO_OLPC_APSP is not set
CONFIG_GAMEPORT=y
CONFIG_GAMEPORT_NS558=y
CONFIG_GAMEPORT_L4=y
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_FM801 is not set
#
# Character devices
#
CONFIG_TTY=y
# CONFIG_VT is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
# CONFIG_DEVKMEM is not set
#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_FINTEK is not set
# CONFIG_SERIAL_8250_INGENIC is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_OF_PLATFORM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_CONEXANT_DIGICOLOR is not set
# CONFIG_SERIAL_MEN_Z135 is not set
# CONFIG_TTY_PRINTK is not set
CONFIG_PRINTER=y
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=y
# CONFIG_VIRTIO_CONSOLE is not set
CONFIG_IPMI_HANDLER=y
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
CONFIG_IPMI_SI=y
CONFIG_IPMI_SI_PROBE_DEFAULTS=y
# CONFIG_IPMI_SSIF is not set
CONFIG_IPMI_WATCHDOG=y
# CONFIG_IPMI_POWEROFF is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
CONFIG_SCx200_GPIO=y
# CONFIG_PC8736x_GPIO is not set
CONFIG_NSC_GPIO=y
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=y
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
CONFIG_TCG_TIS_I2C_ATMEL=y
CONFIG_TCG_TIS_I2C_INFINEON=y
CONFIG_TCG_TIS_I2C_NUVOTON=y
CONFIG_TCG_NSC=y
# CONFIG_TCG_ATMEL is not set
# CONFIG_TCG_INFINEON is not set
# CONFIG_TCG_CRB is not set
CONFIG_TCG_TIS_ST33ZP24=y
CONFIG_TCG_TIS_ST33ZP24_I2C=y
CONFIG_TCG_TIS_ST33ZP24_SPI=y
CONFIG_TELCLOCK=y
CONFIG_DEVPORT=y
CONFIG_XILLYBUS=y
CONFIG_XILLYBUS_OF=y
#
# I2C support
#
CONFIG_I2C=y
CONFIG_ACPI_I2C_OPREGION=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MUX=y
#
# Multiplexer I2C Chip support
#
CONFIG_I2C_ARB_GPIO_CHALLENGE=y
CONFIG_I2C_MUX_GPIO=y
CONFIG_I2C_MUX_PCA9541=y
CONFIG_I2C_MUX_PCA954x=y
# CONFIG_I2C_HELPER_AUTO is not set
CONFIG_I2C_SMBUS=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
CONFIG_I2C_ALGOPCA=y
#
# I2C Hardware Bus support
#
#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_ISMT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
CONFIG_I2C_CBUS_GPIO=y
# CONFIG_I2C_DESIGNWARE_PCI is not set
# CONFIG_I2C_EG20T is not set
CONFIG_I2C_GPIO=y
# CONFIG_I2C_KEMPLD is not set
CONFIG_I2C_OCORES=y
CONFIG_I2C_PCA_PLATFORM=y
# CONFIG_I2C_PXA is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_CROS_EC_TUNNEL=y
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SLAVE is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
CONFIG_SPI_ALTERA=y
CONFIG_SPI_BITBANG=y
# CONFIG_SPI_BUTTERFLY is not set
CONFIG_SPI_CADENCE=y
# CONFIG_SPI_GPIO is not set
CONFIG_SPI_LM70_LLP=y
# CONFIG_SPI_FSL_SPI is not set
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PXA2XX is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_TOPCLIFF_PCH is not set
# CONFIG_SPI_XCOMM is not set
CONFIG_SPI_XILINX=y
CONFIG_SPI_ZYNQMP_GQSPI=y
CONFIG_SPI_DESIGNWARE=y
# CONFIG_SPI_DW_PCI is not set
CONFIG_SPI_DW_MMIO=y
#
# SPI Protocol Masters
#
CONFIG_SPI_SPIDEV=y
# CONFIG_SPI_TLE62X0 is not set
CONFIG_SPMI=y
CONFIG_HSI=y
CONFIG_HSI_BOARDINFO=y
#
# HSI controllers
#
#
# HSI clients
#
CONFIG_HSI_CHAR=y
#
# PPS support
#
# CONFIG_PPS is not set
#
# PPS generators support
#
#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_OF_GPIO=y
CONFIG_GPIO_ACPI=y
CONFIG_GPIOLIB_IRQCHIP=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_GENERIC=y
CONFIG_GPIO_MAX730X=y
#
# Memory mapped GPIO drivers
#
# CONFIG_GPIO_74XX_MMIO is not set
# CONFIG_GPIO_ALTERA is not set
CONFIG_GPIO_DWAPB=y
CONFIG_GPIO_F7188X=y
# CONFIG_GPIO_GENERIC_PLATFORM is not set
CONFIG_GPIO_GRGPIO=y
# CONFIG_GPIO_ICH is not set
# CONFIG_GPIO_IT8761E is not set
# CONFIG_GPIO_LYNXPOINT is not set
# CONFIG_GPIO_SCH is not set
CONFIG_GPIO_SCH311X=y
# CONFIG_GPIO_VX855 is not set
CONFIG_GPIO_XILINX=y
#
# I2C GPIO expanders
#
CONFIG_GPIO_ADP5588=y
# CONFIG_GPIO_ADP5588_IRQ is not set
# CONFIG_GPIO_ADNP is not set
CONFIG_GPIO_MAX7300=y
CONFIG_GPIO_MAX732X=y
CONFIG_GPIO_MAX732X_IRQ=y
# CONFIG_GPIO_PCA953X is not set
CONFIG_GPIO_PCF857X=y
CONFIG_GPIO_SX150X=y
#
# MFD GPIO expanders
#
CONFIG_GPIO_ARIZONA=y
CONFIG_GPIO_CRYSTAL_COVE=y
# CONFIG_GPIO_DA9052 is not set
CONFIG_GPIO_DA9055=y
# CONFIG_GPIO_KEMPLD is not set
CONFIG_GPIO_LP3943=y
CONFIG_GPIO_PALMAS=y
# CONFIG_GPIO_RC5T583 is not set
# CONFIG_GPIO_STMPE is not set
CONFIG_GPIO_TC3589X=y
CONFIG_GPIO_TPS65910=y
CONFIG_GPIO_TPS65912=y
# CONFIG_GPIO_TWL4030 is not set
CONFIG_GPIO_TWL6040=y
CONFIG_GPIO_WM831X=y
# CONFIG_GPIO_WM8350 is not set
CONFIG_GPIO_WM8994=y
#
# PCI GPIO expanders
#
# CONFIG_GPIO_AMD8111 is not set
# CONFIG_GPIO_BT8XX is not set
# CONFIG_GPIO_INTEL_MID is not set
# CONFIG_GPIO_ML_IOH is not set
# CONFIG_GPIO_PCH is not set
# CONFIG_GPIO_RDC321X is not set
# CONFIG_GPIO_SODAVILLE is not set
#
# SPI GPIO expanders
#
# CONFIG_GPIO_74X164 is not set
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
CONFIG_GPIO_MC33880=y
CONFIG_W1=y
#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
# CONFIG_W1_MASTER_DS2482 is not set
CONFIG_W1_MASTER_DS1WM=y
CONFIG_W1_MASTER_GPIO=y
#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=y
CONFIG_W1_SLAVE_SMEM=y
CONFIG_W1_SLAVE_DS2408=y
CONFIG_W1_SLAVE_DS2408_READBACK=y
# CONFIG_W1_SLAVE_DS2413 is not set
# CONFIG_W1_SLAVE_DS2406 is not set
# CONFIG_W1_SLAVE_DS2423 is not set
CONFIG_W1_SLAVE_DS2431=y
CONFIG_W1_SLAVE_DS2433=y
# CONFIG_W1_SLAVE_DS2433_CRC is not set
CONFIG_W1_SLAVE_DS2760=y
# CONFIG_W1_SLAVE_DS2780 is not set
CONFIG_W1_SLAVE_DS2781=y
CONFIG_W1_SLAVE_DS28E04=y
CONFIG_W1_SLAVE_BQ27000=y
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_MAX8925_POWER is not set
# CONFIG_WM831X_BACKUP is not set
CONFIG_WM831X_POWER=y
# CONFIG_WM8350_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
CONFIG_BATTERY_OLPC=y
# CONFIG_BATTERY_SBS is not set
CONFIG_BATTERY_BQ27x00=y
CONFIG_BATTERY_BQ27X00_I2C=y
CONFIG_BATTERY_BQ27X00_PLATFORM=y
CONFIG_BATTERY_DA9030=y
CONFIG_BATTERY_DA9052=y
CONFIG_BATTERY_MAX17040=y
CONFIG_BATTERY_MAX17042=y
CONFIG_CHARGER_PCF50633=y
CONFIG_CHARGER_MAX8903=y
# CONFIG_CHARGER_TWL4030 is not set
CONFIG_CHARGER_LP8727=y
CONFIG_CHARGER_GPIO=y
CONFIG_CHARGER_MANAGER=y
CONFIG_CHARGER_MAX77693=y
CONFIG_CHARGER_MAX8997=y
# CONFIG_CHARGER_BQ2415X is not set
CONFIG_CHARGER_BQ24190=y
CONFIG_CHARGER_BQ24257=y
CONFIG_CHARGER_BQ24735=y
CONFIG_CHARGER_BQ25890=y
CONFIG_CHARGER_SMB347=y
CONFIG_BATTERY_GAUGE_LTC2941=y
CONFIG_CHARGER_RT9455=y
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
CONFIG_HWMON_DEBUG_CHIP=y
#
# Native drivers
#
CONFIG_SENSORS_ABITUGURU=y
# CONFIG_SENSORS_ABITUGURU3 is not set
CONFIG_SENSORS_AD7314=y
CONFIG_SENSORS_AD7414=y
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
CONFIG_SENSORS_ADM1026=y
# CONFIG_SENSORS_ADM1029 is not set
CONFIG_SENSORS_ADM1031=y
CONFIG_SENSORS_ADM9240=y
CONFIG_SENSORS_ADT7X10=y
CONFIG_SENSORS_ADT7310=y
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
CONFIG_SENSORS_ADT7462=y
CONFIG_SENSORS_ADT7470=y
CONFIG_SENSORS_ADT7475=y
CONFIG_SENSORS_ASC7621=y
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_K10TEMP is not set
# CONFIG_SENSORS_FAM15H_POWER is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_SENSORS_ASB100 is not set
CONFIG_SENSORS_ATXP1=y
CONFIG_SENSORS_DS620=y
# CONFIG_SENSORS_DS1621 is not set
CONFIG_SENSORS_DELL_SMM=y
CONFIG_SENSORS_DA9052_ADC=y
# CONFIG_SENSORS_DA9055 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
CONFIG_SENSORS_F71882FG=y
CONFIG_SENSORS_F75375S=y
# CONFIG_SENSORS_MC13783_ADC is not set
CONFIG_SENSORS_FSCHMD=y
# CONFIG_SENSORS_GL518SM is not set
CONFIG_SENSORS_GL520SM=y
CONFIG_SENSORS_G760A=y
CONFIG_SENSORS_G762=y
CONFIG_SENSORS_GPIO_FAN=y
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_IBMAEM is not set
CONFIG_SENSORS_IBMPEX=y
# CONFIG_SENSORS_I5500 is not set
CONFIG_SENSORS_CORETEMP=y
# CONFIG_SENSORS_IT87 is not set
CONFIG_SENSORS_JC42=y
CONFIG_SENSORS_POWR1220=y
# CONFIG_SENSORS_LINEAGE is not set
CONFIG_SENSORS_LTC2945=y
CONFIG_SENSORS_LTC4151=y
# CONFIG_SENSORS_LTC4215 is not set
CONFIG_SENSORS_LTC4222=y
# CONFIG_SENSORS_LTC4245 is not set
CONFIG_SENSORS_LTC4260=y
CONFIG_SENSORS_LTC4261=y
# CONFIG_SENSORS_MAX1111 is not set
CONFIG_SENSORS_MAX16065=y
CONFIG_SENSORS_MAX1619=y
CONFIG_SENSORS_MAX1668=y
CONFIG_SENSORS_MAX197=y
CONFIG_SENSORS_MAX6639=y
CONFIG_SENSORS_MAX6642=y
CONFIG_SENSORS_MAX6650=y
# CONFIG_SENSORS_MAX6697 is not set
CONFIG_SENSORS_HTU21=y
CONFIG_SENSORS_MCP3021=y
CONFIG_SENSORS_ADCXX=y
CONFIG_SENSORS_LM63=y
CONFIG_SENSORS_LM70=y
CONFIG_SENSORS_LM73=y
CONFIG_SENSORS_LM75=y
# CONFIG_SENSORS_LM77 is not set
CONFIG_SENSORS_LM78=y
CONFIG_SENSORS_LM80=y
CONFIG_SENSORS_LM83=y
CONFIG_SENSORS_LM85=y
CONFIG_SENSORS_LM87=y
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_LM92=y
CONFIG_SENSORS_LM93=y
CONFIG_SENSORS_LM95234=y
CONFIG_SENSORS_LM95241=y
CONFIG_SENSORS_LM95245=y
CONFIG_SENSORS_PC87360=y
CONFIG_SENSORS_PC87427=y
CONFIG_SENSORS_NTC_THERMISTOR=y
CONFIG_SENSORS_NCT6683=y
# CONFIG_SENSORS_NCT6775 is not set
CONFIG_SENSORS_NCT7802=y
CONFIG_SENSORS_NCT7904=y
CONFIG_SENSORS_PCF8591=y
# CONFIG_PMBUS is not set
CONFIG_SENSORS_SHT15=y
CONFIG_SENSORS_SHT21=y
# CONFIG_SENSORS_SHTC1 is not set
# CONFIG_SENSORS_SIS5595 is not set
CONFIG_SENSORS_DME1737=y
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
CONFIG_SENSORS_EMC6W201=y
CONFIG_SENSORS_SMSC47M1=y
CONFIG_SENSORS_SMSC47M192=y
CONFIG_SENSORS_SMSC47B397=y
# CONFIG_SENSORS_SCH56XX_COMMON is not set
CONFIG_SENSORS_SMM665=y
CONFIG_SENSORS_ADC128D818=y
CONFIG_SENSORS_ADS1015=y
# CONFIG_SENSORS_ADS7828 is not set
CONFIG_SENSORS_ADS7871=y
# CONFIG_SENSORS_AMC6821 is not set
CONFIG_SENSORS_INA209=y
CONFIG_SENSORS_INA2XX=y
CONFIG_SENSORS_TC74=y
CONFIG_SENSORS_THMC50=y
# CONFIG_SENSORS_TMP102 is not set
CONFIG_SENSORS_TMP103=y
CONFIG_SENSORS_TMP401=y
# CONFIG_SENSORS_TMP421 is not set
CONFIG_SENSORS_VIA_CPUTEMP=y
# CONFIG_SENSORS_VIA686A is not set
CONFIG_SENSORS_VT1211=y
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
CONFIG_SENSORS_W83792D=y
CONFIG_SENSORS_W83793=y
CONFIG_SENSORS_W83795=y
# CONFIG_SENSORS_W83795_FANCTRL is not set
CONFIG_SENSORS_W83L785TS=y
CONFIG_SENSORS_W83L786NG=y
CONFIG_SENSORS_W83627HF=y
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_WM831X=y
# CONFIG_SENSORS_WM8350 is not set
#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_OF=y
# CONFIG_THERMAL_WRITABLE_TRIPS is not set
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR is not set
# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_GOV_STEP_WISE=y
# CONFIG_THERMAL_GOV_BANG_BANG is not set
# CONFIG_THERMAL_GOV_USER_SPACE is not set
# CONFIG_THERMAL_GOV_POWER_ALLOCATOR is not set
# CONFIG_THERMAL_EMULATION is not set
# CONFIG_INTEL_SOC_DTS_THERMAL is not set
# CONFIG_INT340X_THERMAL is not set
#
# Texas Instruments thermal drivers
#
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
CONFIG_SSB=y
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_B43_PCI_BRIDGE is not set
CONFIG_SSB_SDIOHOST_POSSIBLE=y
# CONFIG_SSB_SDIOHOST is not set
CONFIG_SSB_SILENT=y
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
# CONFIG_SSB_DRIVER_PCICORE is not set
# CONFIG_SSB_DRIVER_GPIO is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set
#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_CS5535 is not set
# CONFIG_MFD_AS3711 is not set
CONFIG_MFD_AS3722=y
# CONFIG_PMIC_ADP5520 is not set
CONFIG_MFD_AAT2870_CORE=y
CONFIG_MFD_ATMEL_HLCDC=y
CONFIG_MFD_BCM590XX=y
CONFIG_MFD_AXP20X=y
CONFIG_MFD_CROS_EC=y
CONFIG_MFD_CROS_EC_I2C=y
CONFIG_MFD_CROS_EC_SPI=y
CONFIG_PMIC_DA903X=y
CONFIG_PMIC_DA9052=y
# CONFIG_MFD_DA9052_SPI is not set
CONFIG_MFD_DA9052_I2C=y
CONFIG_MFD_DA9055=y
# CONFIG_MFD_DA9063 is not set
CONFIG_MFD_DA9150=y
CONFIG_MFD_MC13XXX=y
CONFIG_MFD_MC13XXX_SPI=y
CONFIG_MFD_MC13XXX_I2C=y
CONFIG_MFD_HI6421_PMIC=y
CONFIG_HTC_PASIC3=y
CONFIG_HTC_I2CPLD=y
# CONFIG_LPC_ICH is not set
# CONFIG_LPC_SCH is not set
CONFIG_INTEL_SOC_PMIC=y
# CONFIG_MFD_JANZ_CMODIO is not set
CONFIG_MFD_KEMPLD=y
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX14577 is not set
# CONFIG_MFD_MAX77686 is not set
CONFIG_MFD_MAX77693=y
# CONFIG_MFD_MAX77843 is not set
CONFIG_MFD_MAX8907=y
CONFIG_MFD_MAX8925=y
CONFIG_MFD_MAX8997=y
# CONFIG_MFD_MAX8998 is not set
CONFIG_MFD_MT6397=y
# CONFIG_MFD_MENF21BMC is not set
CONFIG_EZX_PCAP=y
CONFIG_MFD_RETU=y
CONFIG_MFD_PCF50633=y
CONFIG_PCF50633_ADC=y
CONFIG_PCF50633_GPIO=y
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_RT5033 is not set
CONFIG_MFD_RC5T583=y
CONFIG_MFD_RK808=y
CONFIG_MFD_RN5T618=y
# CONFIG_MFD_SEC_CORE is not set
CONFIG_MFD_SI476X_CORE=y
CONFIG_MFD_SM501=y
# CONFIG_MFD_SM501_GPIO is not set
CONFIG_MFD_SKY81452=y
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
CONFIG_MFD_STMPE=y
#
# STMicroelectronics STMPE Interface Drivers
#
CONFIG_STMPE_I2C=y
CONFIG_STMPE_SPI=y
# CONFIG_MFD_SYSCON is not set
CONFIG_MFD_TI_AM335X_TSCADC=y
CONFIG_MFD_LP3943=y
# CONFIG_MFD_LP8788 is not set
CONFIG_MFD_PALMAS=y
CONFIG_TPS6105X=y
# CONFIG_TPS65010 is not set
CONFIG_TPS6507X=y
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
CONFIG_MFD_TPS65218=y
# CONFIG_MFD_TPS6586X is not set
CONFIG_MFD_TPS65910=y
CONFIG_MFD_TPS65912=y
# CONFIG_MFD_TPS65912_I2C is not set
CONFIG_MFD_TPS65912_SPI=y
# CONFIG_MFD_TPS80031 is not set
CONFIG_TWL4030_CORE=y
CONFIG_MFD_TWL4030_AUDIO=y
CONFIG_TWL6040_CORE=y
CONFIG_MFD_WL1273_CORE=y
CONFIG_MFD_LM3533=y
# CONFIG_MFD_TIMBERDALE is not set
CONFIG_MFD_TC3589X=y
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_VX855 is not set
CONFIG_MFD_ARIZONA=y
CONFIG_MFD_ARIZONA_I2C=y
CONFIG_MFD_ARIZONA_SPI=y
CONFIG_MFD_WM5102=y
CONFIG_MFD_WM5110=y
# CONFIG_MFD_WM8997 is not set
# CONFIG_MFD_WM8400 is not set
CONFIG_MFD_WM831X=y
# CONFIG_MFD_WM831X_I2C is not set
CONFIG_MFD_WM831X_SPI=y
CONFIG_MFD_WM8350=y
CONFIG_MFD_WM8350_I2C=y
CONFIG_MFD_WM8994=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
CONFIG_REGULATOR_ACT8865=y
CONFIG_REGULATOR_AD5398=y
CONFIG_REGULATOR_AAT2870=y
CONFIG_REGULATOR_AS3722=y
CONFIG_REGULATOR_AXP20X=y
CONFIG_REGULATOR_BCM590XX=y
CONFIG_REGULATOR_DA903X=y
CONFIG_REGULATOR_DA9052=y
# CONFIG_REGULATOR_DA9055 is not set
CONFIG_REGULATOR_DA9210=y
# CONFIG_REGULATOR_DA9211 is not set
CONFIG_REGULATOR_FAN53555=y
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_HI6421=y
CONFIG_REGULATOR_ISL9305=y
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_LP3971 is not set
CONFIG_REGULATOR_LP3972=y
CONFIG_REGULATOR_LP872X=y
CONFIG_REGULATOR_LP8755=y
CONFIG_REGULATOR_LTC3589=y
CONFIG_REGULATOR_MAX1586=y
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8907 is not set
CONFIG_REGULATOR_MAX8925=y
CONFIG_REGULATOR_MAX8952=y
# CONFIG_REGULATOR_MAX8973 is not set
CONFIG_REGULATOR_MAX8997=y
# CONFIG_REGULATOR_MAX77693 is not set
CONFIG_REGULATOR_MC13XXX_CORE=y
# CONFIG_REGULATOR_MC13783 is not set
CONFIG_REGULATOR_MC13892=y
CONFIG_REGULATOR_MT6397=y
CONFIG_REGULATOR_PALMAS=y
CONFIG_REGULATOR_PCAP=y
CONFIG_REGULATOR_PCF50633=y
# CONFIG_REGULATOR_PFUZE100 is not set
CONFIG_REGULATOR_QCOM_SPMI=y
# CONFIG_REGULATOR_RC5T583 is not set
# CONFIG_REGULATOR_RK808 is not set
CONFIG_REGULATOR_RN5T618=y
CONFIG_REGULATOR_SKY81452=y
CONFIG_REGULATOR_TPS51632=y
CONFIG_REGULATOR_TPS6105X=y
CONFIG_REGULATOR_TPS62360=y
# CONFIG_REGULATOR_TPS65023 is not set
CONFIG_REGULATOR_TPS6507X=y
# CONFIG_REGULATOR_TPS65218 is not set
CONFIG_REGULATOR_TPS6524X=y
# CONFIG_REGULATOR_TPS65910 is not set
CONFIG_REGULATOR_TPS65912=y
# CONFIG_REGULATOR_TWL4030 is not set
# CONFIG_REGULATOR_WM831X is not set
CONFIG_REGULATOR_WM8350=y
CONFIG_REGULATOR_WM8994=y
CONFIG_MEDIA_SUPPORT=y
#
# Multimedia core support
#
CONFIG_MEDIA_CAMERA_SUPPORT=y
# CONFIG_MEDIA_ANALOG_TV_SUPPORT is not set
# CONFIG_MEDIA_DIGITAL_TV_SUPPORT is not set
CONFIG_MEDIA_RADIO_SUPPORT=y
# CONFIG_MEDIA_SDR_SUPPORT is not set
CONFIG_MEDIA_RC_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_ADV_DEBUG=y
CONFIG_VIDEO_FIXED_MINOR_RANGES=y
# CONFIG_TTPCI_EEPROM is not set
#
# Media drivers
#
CONFIG_RC_CORE=y
# CONFIG_RC_MAP is not set
# CONFIG_RC_DECODERS is not set
# CONFIG_RC_DEVICES is not set
# CONFIG_MEDIA_PCI_SUPPORT is not set
# CONFIG_V4L_PLATFORM_DRIVERS is not set
# CONFIG_V4L_MEM2MEM_DRIVERS is not set
# CONFIG_V4L_TEST_DRIVERS is not set
#
# Supported MMC/SDIO adapters
#
CONFIG_RADIO_ADAPTERS=y
CONFIG_RADIO_SI470X=y
CONFIG_I2C_SI470X=y
CONFIG_RADIO_SI4713=y
# CONFIG_PLATFORM_SI4713 is not set
CONFIG_I2C_SI4713=y
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_TEA5764 is not set
# CONFIG_RADIO_SAA7706H is not set
# CONFIG_RADIO_TEF6862 is not set
CONFIG_RADIO_WL1273=y
#
# Texas Instruments WL128x FM driver (ST based)
#
#
# Media ancillary drivers (tuners, sensors, i2c, frontends)
#
# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
CONFIG_VIDEO_IR_I2C=y
#
# Encoders, decoders, sensors and other helper chips
#
#
# Audio decoders, processors and mixers
#
CONFIG_VIDEO_TVAUDIO=y
CONFIG_VIDEO_TDA7432=y
CONFIG_VIDEO_TDA9840=y
CONFIG_VIDEO_TEA6415C=y
CONFIG_VIDEO_TEA6420=y
# CONFIG_VIDEO_MSP3400 is not set
CONFIG_VIDEO_CS5345=y
CONFIG_VIDEO_CS53L32A=y
# CONFIG_VIDEO_TLV320AIC23B is not set
# CONFIG_VIDEO_UDA1342 is not set
CONFIG_VIDEO_WM8775=y
CONFIG_VIDEO_WM8739=y
CONFIG_VIDEO_VP27SMPX=y
# CONFIG_VIDEO_SONY_BTF_MPX is not set
#
# RDS decoders
#
# CONFIG_VIDEO_SAA6588 is not set
#
# Video decoders
#
CONFIG_VIDEO_ADV7180=y
CONFIG_VIDEO_ADV7183=y
CONFIG_VIDEO_ADV7604=y
CONFIG_VIDEO_ADV7842=y
# CONFIG_VIDEO_BT819 is not set
# CONFIG_VIDEO_BT856 is not set
CONFIG_VIDEO_BT866=y
CONFIG_VIDEO_KS0127=y
CONFIG_VIDEO_ML86V7667=y
CONFIG_VIDEO_SAA7110=y
CONFIG_VIDEO_SAA711X=y
# CONFIG_VIDEO_TVP514X is not set
CONFIG_VIDEO_TVP5150=y
CONFIG_VIDEO_TVP7002=y
CONFIG_VIDEO_TW2804=y
CONFIG_VIDEO_TW9903=y
CONFIG_VIDEO_TW9906=y
CONFIG_VIDEO_VPX3220=y
#
# Video and audio decoders
#
CONFIG_VIDEO_SAA717X=y
CONFIG_VIDEO_CX25840=y
#
# Video encoders
#
CONFIG_VIDEO_SAA7127=y
# CONFIG_VIDEO_SAA7185 is not set
CONFIG_VIDEO_ADV7170=y
# CONFIG_VIDEO_ADV7175 is not set
# CONFIG_VIDEO_ADV7343 is not set
# CONFIG_VIDEO_ADV7393 is not set
CONFIG_VIDEO_ADV7511=y
CONFIG_VIDEO_AD9389B=y
CONFIG_VIDEO_AK881X=y
# CONFIG_VIDEO_THS8200 is not set
#
# Camera sensor devices
#
CONFIG_VIDEO_APTINA_PLL=y
# CONFIG_VIDEO_OV2659 is not set
CONFIG_VIDEO_OV7640=y
# CONFIG_VIDEO_OV7670 is not set
CONFIG_VIDEO_OV9650=y
# CONFIG_VIDEO_VS6624 is not set
CONFIG_VIDEO_MT9M032=y
CONFIG_VIDEO_MT9P031=y
CONFIG_VIDEO_MT9T001=y
CONFIG_VIDEO_MT9V011=y
CONFIG_VIDEO_MT9V032=y
CONFIG_VIDEO_SR030PC30=y
CONFIG_VIDEO_NOON010PC30=y
# CONFIG_VIDEO_M5MOLS is not set
CONFIG_VIDEO_S5K6AA=y
CONFIG_VIDEO_S5K6A3=y
# CONFIG_VIDEO_S5K4ECGX is not set
CONFIG_VIDEO_S5K5BAF=y
# CONFIG_VIDEO_S5C73M3 is not set
#
# Flash devices
#
# CONFIG_VIDEO_ADP1653 is not set
# CONFIG_VIDEO_AS3645A is not set
CONFIG_VIDEO_LM3560=y
# CONFIG_VIDEO_LM3646 is not set
#
# Video improvement chips
#
CONFIG_VIDEO_UPD64031A=y
CONFIG_VIDEO_UPD64083=y
#
# Audio/Video compression chips
#
CONFIG_VIDEO_SAA6752HS=y
#
# Miscellaneous helper chips
#
# CONFIG_VIDEO_THS7303 is not set
CONFIG_VIDEO_M52790=y
#
# Sensors used on soc_camera driver
#
CONFIG_MEDIA_TUNER=y
#
# Customize TV tuners
#
# CONFIG_MEDIA_TUNER_SIMPLE is not set
CONFIG_MEDIA_TUNER_TDA8290=y
CONFIG_MEDIA_TUNER_TDA827X=y
CONFIG_MEDIA_TUNER_TDA18271=y
CONFIG_MEDIA_TUNER_TDA9887=y
CONFIG_MEDIA_TUNER_TEA5761=y
CONFIG_MEDIA_TUNER_TEA5767=y
# CONFIG_MEDIA_TUNER_MSI001 is not set
# CONFIG_MEDIA_TUNER_MT20XX is not set
CONFIG_MEDIA_TUNER_MT2060=y
CONFIG_MEDIA_TUNER_MT2063=y
CONFIG_MEDIA_TUNER_MT2266=y
CONFIG_MEDIA_TUNER_MT2131=y
# CONFIG_MEDIA_TUNER_QT1010 is not set
CONFIG_MEDIA_TUNER_XC2028=y
CONFIG_MEDIA_TUNER_XC5000=y
CONFIG_MEDIA_TUNER_XC4000=y
# CONFIG_MEDIA_TUNER_MXL5005S is not set
CONFIG_MEDIA_TUNER_MXL5007T=y
CONFIG_MEDIA_TUNER_MC44S803=y
CONFIG_MEDIA_TUNER_MAX2165=y
CONFIG_MEDIA_TUNER_TDA18218=y
# CONFIG_MEDIA_TUNER_FC0011 is not set
CONFIG_MEDIA_TUNER_FC0012=y
CONFIG_MEDIA_TUNER_FC0013=y
CONFIG_MEDIA_TUNER_TDA18212=y
CONFIG_MEDIA_TUNER_E4000=y
CONFIG_MEDIA_TUNER_FC2580=y
# CONFIG_MEDIA_TUNER_M88RS6000T is not set
# CONFIG_MEDIA_TUNER_TUA9001 is not set
# CONFIG_MEDIA_TUNER_SI2157 is not set
CONFIG_MEDIA_TUNER_IT913X=y
# CONFIG_MEDIA_TUNER_R820T is not set
CONFIG_MEDIA_TUNER_MXL301RF=y
CONFIG_MEDIA_TUNER_QM1D1C0042=y
#
# Customise DVB Frontends
#
CONFIG_DVB_AU8522=y
CONFIG_DVB_AU8522_V4L=y
CONFIG_DVB_TUNER_DIB0070=y
CONFIG_DVB_TUNER_DIB0090=y
#
# Tools to develop new frontends
#
CONFIG_DVB_DUMMY_FE=y
#
# Graphics support
#
# CONFIG_AGP is not set
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_VGA_SWITCHEROO is not set
#
# Direct Rendering Manager
#
CONFIG_DRM=y
CONFIG_DRM_MIPI_DSI=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
#
# I2C encoder or helper chips
#
CONFIG_DRM_I2C_ADV7511=y
CONFIG_DRM_I2C_CH7006=y
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_I2C_NXP_TDA998X is not set
# CONFIG_DRM_PTN3460 is not set
CONFIG_DRM_PS8622=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_AMDGPU is not set
# CONFIG_DRM_NOUVEAU is not set
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
CONFIG_DRM_VGEM=y
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_AST is not set
# CONFIG_DRM_MGAG200 is not set
# CONFIG_DRM_CIRRUS_QEMU is not set
# CONFIG_DRM_QXL is not set
# CONFIG_DRM_BOCHS is not set
# CONFIG_DRM_VIRTIO_GPU is not set
CONFIG_DRM_PANEL=y
#
# Display Panels
#
CONFIG_DRM_PANEL_SIMPLE=y
# CONFIG_DRM_PANEL_LD9040 is not set
CONFIG_DRM_PANEL_S6E8AA0=y
# CONFIG_DRM_PANEL_SHARP_LQ101R1SX01 is not set
#
# Frame buffer Devices
#
# CONFIG_FB is not set
CONFIG_FB_CMDLINE=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
# CONFIG_LCD_L4F00242T03 is not set
CONFIG_LCD_LMS283GF05=y
CONFIG_LCD_LTV350QV=y
CONFIG_LCD_ILI922X=y
CONFIG_LCD_ILI9320=y
CONFIG_LCD_TDO24M=y
CONFIG_LCD_VGG2432A4=y
CONFIG_LCD_PLATFORM=y
CONFIG_LCD_S6E63M0=y
# CONFIG_LCD_LD9040 is not set
CONFIG_LCD_AMS369FG06=y
CONFIG_LCD_LMS501KF03=y
# CONFIG_LCD_HX8357 is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_LM3533 is not set
CONFIG_BACKLIGHT_DA903X=y
CONFIG_BACKLIGHT_DA9052=y
# CONFIG_BACKLIGHT_MAX8925 is not set
# CONFIG_BACKLIGHT_APPLE is not set
CONFIG_BACKLIGHT_SAHARA=y
CONFIG_BACKLIGHT_WM831X=y
# CONFIG_BACKLIGHT_ADP8860 is not set
CONFIG_BACKLIGHT_ADP8870=y
CONFIG_BACKLIGHT_PCF50633=y
CONFIG_BACKLIGHT_AAT2870=y
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_PANDORA is not set
CONFIG_BACKLIGHT_SKY81452=y
# CONFIG_BACKLIGHT_GPIO is not set
CONFIG_BACKLIGHT_LV5207LP=y
# CONFIG_BACKLIGHT_BD6107 is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEOMODE_HELPERS=y
CONFIG_HDMI=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
# CONFIG_SND is not set
CONFIG_SOUND_PRIME=y
CONFIG_SOUND_OSS=y
CONFIG_SOUND_TRACEINIT=y
# CONFIG_SOUND_DMAP is not set
CONFIG_SOUND_VMIDI=y
CONFIG_SOUND_TRIX=y
# CONFIG_SOUND_MSS is not set
CONFIG_SOUND_MPU401=y
# CONFIG_SOUND_PAS is not set
CONFIG_SOUND_PSS=y
# CONFIG_PSS_MIXER is not set
# CONFIG_SOUND_SB is not set
CONFIG_SOUND_YM3812=y
CONFIG_SOUND_UART6850=y
# CONFIG_SOUND_AEDSP16 is not set
#
# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
# CONFIG_HIDRAW is not set
CONFIG_UHID=y
# CONFIG_HID_GENERIC is not set
#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
# CONFIG_HID_ACRUX is not set
CONFIG_HID_APPLE=y
CONFIG_HID_AUREAL=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
# CONFIG_HID_CYPRESS is not set
CONFIG_HID_DRAGONRISE=y
CONFIG_DRAGONRISE_FF=y
CONFIG_HID_EMS_FF=y
# CONFIG_HID_ELECOM is not set
CONFIG_HID_EZKEY=y
CONFIG_HID_KEYTOUCH=y
CONFIG_HID_KYE=y
CONFIG_HID_WALTOP=y
CONFIG_HID_GYRATION=y
CONFIG_HID_ICADE=y
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
CONFIG_HID_LENOVO=y
CONFIG_HID_LOGITECH=y
# CONFIG_HID_LOGITECH_HIDPP is not set
# CONFIG_LOGITECH_FF is not set
CONFIG_LOGIRUMBLEPAD2_FF=y
# CONFIG_LOGIG940_FF is not set
# CONFIG_LOGIWHEELS_FF is not set
CONFIG_HID_MAGICMOUSE=y
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
# CONFIG_HID_MULTITOUCH is not set
CONFIG_HID_ORTEK=y
# CONFIG_HID_PANTHERLORD is not set
CONFIG_HID_PETALYNX=y
CONFIG_HID_PICOLCD=y
# CONFIG_HID_PICOLCD_BACKLIGHT is not set
CONFIG_HID_PICOLCD_LCD=y
# CONFIG_HID_PICOLCD_LEDS is not set
CONFIG_HID_PICOLCD_CIR=y
# CONFIG_HID_PLANTRONICS is not set
CONFIG_HID_PRIMAX=y
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SPEEDLINK is not set
CONFIG_HID_STEELSERIES=y
CONFIG_HID_SUNPLUS=y
CONFIG_HID_RMI=y
# CONFIG_HID_GREENASIA is not set
CONFIG_HID_SMARTJOYPLUS=y
# CONFIG_SMARTJOYPLUS_FF is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
CONFIG_HID_THINGM=y
CONFIG_HID_THRUSTMASTER=y
# CONFIG_THRUSTMASTER_FF is not set
CONFIG_HID_WACOM=y
CONFIG_HID_WIIMOTE=y
# CONFIG_HID_XINMO is not set
CONFIG_HID_ZEROPLUS=y
CONFIG_ZEROPLUS_FF=y
CONFIG_HID_ZYDACRON=y
CONFIG_HID_SENSOR_HUB=y
# CONFIG_HID_SENSOR_CUSTOM_SENSOR is not set
#
# I2C HID support
#
CONFIG_I2C_HID=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
# CONFIG_USB is not set
#
# USB port drivers
#
#
# USB Physical Layer drivers
#
# CONFIG_USB_PHY is not set
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_TAHVO_USB is not set
# CONFIG_USB_GADGET is not set
# CONFIG_UWB is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_CLKGATE is not set
#
# MMC/SD/SDIO Card Drivers
#
# CONFIG_SDIO_UART is not set
CONFIG_MMC_TEST=y
#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_WBSD is not set
# CONFIG_MMC_TIFM_SD is not set
# CONFIG_MMC_CB710 is not set
# CONFIG_MMC_VIA_SDMMC is not set
CONFIG_MMC_USDHI6ROL0=y
# CONFIG_MMC_TOSHIBA_PCI is not set
CONFIG_MMC_MTK=y
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
# CONFIG_LEDS_CLASS_FLASH is not set
#
# LED drivers
#
CONFIG_LEDS_BCM6328=y
# CONFIG_LEDS_BCM6358 is not set
CONFIG_LEDS_LM3530=y
CONFIG_LEDS_LM3533=y
CONFIG_LEDS_LM3642=y
# CONFIG_LEDS_NET48XX is not set
# CONFIG_LEDS_WRAP is not set
CONFIG_LEDS_PCA9532=y
CONFIG_LEDS_PCA9532_GPIO=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_LP3944=y
CONFIG_LEDS_LP55XX_COMMON=y
# CONFIG_LEDS_LP5521 is not set
CONFIG_LEDS_LP5523=y
# CONFIG_LEDS_LP5562 is not set
CONFIG_LEDS_LP8501=y
CONFIG_LEDS_LP8860=y
CONFIG_LEDS_CLEVO_MAIL=y
CONFIG_LEDS_PCA955X=y
# CONFIG_LEDS_PCA963X is not set
CONFIG_LEDS_WM831X_STATUS=y
# CONFIG_LEDS_WM8350 is not set
CONFIG_LEDS_DA903X=y
CONFIG_LEDS_DA9052=y
CONFIG_LEDS_DAC124S085=y
CONFIG_LEDS_REGULATOR=y
CONFIG_LEDS_BD2802=y
# CONFIG_LEDS_INTEL_SS4200 is not set
CONFIG_LEDS_LT3593=y
CONFIG_LEDS_MC13783=y
CONFIG_LEDS_TCA6507=y
# CONFIG_LEDS_TLC591XX is not set
CONFIG_LEDS_MAX8997=y
CONFIG_LEDS_LM355x=y
CONFIG_LEDS_OT200=y
#
# LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM)
#
# CONFIG_LEDS_BLINKM is not set
CONFIG_LEDS_PM8941_WLED=y
#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
CONFIG_ACCESSIBILITY=y
CONFIG_EDAC_ATOMIC_SCRUB=y
CONFIG_EDAC_SUPPORT=y
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
CONFIG_DMADEVICES=y
CONFIG_DMADEVICES_DEBUG=y
# CONFIG_DMADEVICES_VDEBUG is not set
#
# DMA Devices
#
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_DW_DMAC is not set
# CONFIG_DW_DMAC_PCI is not set
# CONFIG_HSU_DMA_PCI is not set
# CONFIG_PCH_DMA is not set
CONFIG_FSL_EDMA=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_ACPI=y
CONFIG_DMA_OF=y
#
# DMA Clients
#
# CONFIG_ASYNC_TX_DMA is not set
CONFIG_DMATEST=y
CONFIG_AUXDISPLAY=y
CONFIG_UIO=y
# CONFIG_UIO_CIF is not set
CONFIG_UIO_PDRV_GENIRQ=y
CONFIG_UIO_DMEM_GENIRQ=y
# CONFIG_UIO_AEC is not set
# CONFIG_UIO_SERCOS3 is not set
# CONFIG_UIO_PCI_GENERIC is not set
# CONFIG_UIO_NETX is not set
CONFIG_UIO_PRUSS=y
# CONFIG_UIO_MF624 is not set
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y
#
# Virtio drivers
#
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_VIRTIO_INPUT=y
CONFIG_VIRTIO_MMIO=y
CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
# CONFIG_X86_PLATFORM_DEVICES is not set
CONFIG_CHROME_PLATFORMS=y
CONFIG_CHROMEOS_LAPTOP=y
# CONFIG_CHROMEOS_PSTORE is not set
CONFIG_CROS_EC_CHARDEV=y
CONFIG_CROS_EC_LPC=y
CONFIG_CROS_EC_PROTO=y
#
# Hardware Spinlock drivers
#
#
# Clock Source drivers
#
CONFIG_CLKSRC_I8253=y
CONFIG_CLKEVT_I8253=y
CONFIG_CLKBLD_I8253=y
# CONFIG_ATMEL_PIT is not set
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_SH_TIMER_MTU2 is not set
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_EM_TIMER_STI is not set
# CONFIG_MAILBOX is not set
# CONFIG_IOMMU_SUPPORT is not set
#
# Remoteproc drivers
#
CONFIG_REMOTEPROC=y
CONFIG_STE_MODEM_RPROC=y
#
# Rpmsg drivers
#
#
# SOC (System On Chip) specific Drivers
#
# CONFIG_SUNXI_SRAM is not set
CONFIG_SOC_TI=y
# CONFIG_PM_DEVFREQ is not set
CONFIG_EXTCON=y
#
# Extcon Device Drivers
#
CONFIG_EXTCON_GPIO=y
# CONFIG_EXTCON_MAX77693 is not set
CONFIG_EXTCON_MAX8997=y
CONFIG_EXTCON_PALMAS=y
CONFIG_EXTCON_RT8973A=y
CONFIG_EXTCON_SM5502=y
CONFIG_EXTCON_USB_GPIO=y
CONFIG_MEMORY=y
# CONFIG_IIO is not set
# CONFIG_NTB is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_IPACK_BUS=y
# CONFIG_BOARD_TPCI200 is not set
# CONFIG_SERIAL_IPOCTAL is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set
#
# PHY Subsystem
#
CONFIG_GENERIC_PHY=y
# CONFIG_PHY_PXA_28NM_HSIC is not set
CONFIG_PHY_PXA_28NM_USB2=y
CONFIG_BCM_KONA_USB2_PHY=y
# CONFIG_POWERCAP is not set
CONFIG_MCB=y
# CONFIG_MCB_PCI is not set
CONFIG_RAS=y
# CONFIG_THUNDERBOLT is not set
#
# Android
#
# CONFIG_ANDROID is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_FIRMWARE_MEMMAP is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
# CONFIG_DMI_SYSFS is not set
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
# CONFIG_ISCSI_IBFT_FIND is not set
# CONFIG_GOOGLE_FIRMWARE is not set
#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QFMT_V1=y
# CONFIG_QFMT_V2 is not set
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=y
CONFIG_CUSE=y
CONFIG_OVERLAY_FS=y
#
# Caches
#
CONFIG_FSCACHE=y
CONFIG_FSCACHE_STATS=y
CONFIG_FSCACHE_HISTOGRAM=y
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
# CONFIG_PROC_SYSCTL is not set
# CONFIG_PROC_PAGE_MONITOR is not set
CONFIG_PROC_CHILDREN=y
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_ECRYPT_FS=y
CONFIG_ECRYPT_FS_MESSAGING=y
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
# CONFIG_JFFS2_FS_WRITEBUFFER is not set
# CONFIG_JFFS2_SUMMARY is not set
CONFIG_JFFS2_FS_XATTR=y
CONFIG_JFFS2_FS_POSIX_ACL=y
CONFIG_JFFS2_FS_SECURITY=y
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_LZO=y
CONFIG_JFFS2_RTIME=y
CONFIG_JFFS2_RUBIN=y
# CONFIG_JFFS2_CMODE_NONE is not set
# CONFIG_JFFS2_CMODE_PRIORITY is not set
CONFIG_JFFS2_CMODE_SIZE=y
# CONFIG_JFFS2_CMODE_FAVOURLZO is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_LOGFS is not set
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_BACKED_BY_MTD=y
CONFIG_ROMFS_ON_MTD=y
# CONFIG_PSTORE is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=y
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
CONFIG_NLS_CODEPAGE_855=y
CONFIG_NLS_CODEPAGE_857=y
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
CONFIG_NLS_CODEPAGE_862=y
CONFIG_NLS_CODEPAGE_863=y
# CONFIG_NLS_CODEPAGE_864 is not set
CONFIG_NLS_CODEPAGE_865=y
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_CODEPAGE_869=y
CONFIG_NLS_CODEPAGE_936=y
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
CONFIG_NLS_ISO8859_8=y
CONFIG_NLS_CODEPAGE_1250=y
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
CONFIG_NLS_ISO8859_3=y
# CONFIG_NLS_ISO8859_4 is not set
CONFIG_NLS_ISO8859_5=y
# CONFIG_NLS_ISO8859_6 is not set
CONFIG_NLS_ISO8859_7=y
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
CONFIG_NLS_ISO8859_14=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
CONFIG_NLS_KOI8_U=y
CONFIG_NLS_MAC_ROMAN=y
# CONFIG_NLS_MAC_CELTIC is not set
CONFIG_NLS_MAC_CENTEURO=y
CONFIG_NLS_MAC_CROATIAN=y
CONFIG_NLS_MAC_CYRILLIC=y
# CONFIG_NLS_MAC_GAELIC is not set
CONFIG_NLS_MAC_GREEK=y
CONFIG_NLS_MAC_ICELAND=y
CONFIG_NLS_MAC_INUIT=y
CONFIG_NLS_MAC_ROMANIAN=y
CONFIG_NLS_MAC_TURKISH=y
CONFIG_NLS_UTF8=y
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DYNAMIC_DEBUG is not set
#
# Compile-time checks and compiler options
#
# CONFIG_DEBUG_INFO is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
CONFIG_STRIP_ASM_SYMS=y
CONFIG_READABLE_ASM=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_PAGE_OWNER=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_DEBUG_KERNEL=y
#
# Memory Debugging
#
CONFIG_PAGE_EXTENSION=y
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_SELFTEST=y
CONFIG_DEBUG_OBJECTS_FREE=y
# CONFIG_DEBUG_OBJECTS_TIMERS is not set
# CONFIG_DEBUG_OBJECTS_WORK is not set
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
# CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER is not set
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VM_VMACACHE is not set
CONFIG_DEBUG_VM_RB=y
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_DEBUG_SHIRQ is not set
#
# Debug Lockups and Hangs
#
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_PANIC_ON_OOPS=y
CONFIG_PANIC_ON_OOPS_VALUE=1
CONFIG_PANIC_TIMEOUT=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHED_INFO=y
CONFIG_SCHEDSTATS=y
CONFIG_SCHED_STACK_END_CHECK=y
# CONFIG_DEBUG_TIMEKEEPING is not set
# CONFIG_TIMER_STATS is not set
#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_LOCK_TORTURE_TEST=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_PI_LIST=y
CONFIG_DEBUG_SG=y
CONFIG_DEBUG_NOTIFIERS=y
# CONFIG_DEBUG_CREDENTIALS is not set
#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_PROVE_RCU_REPEATEDLY is not set
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_TORTURE_TEST=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
CONFIG_RCU_EQS_DEBUG=y
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
CONFIG_IRQSOFF_TRACER=y
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_TRACER_SNAPSHOT=y
CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
CONFIG_TRACE_BRANCH_PROFILING=y
# CONFIG_BRANCH_PROFILE_NONE is not set
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
CONFIG_PROFILE_ALL_BRANCHES=y
CONFIG_TRACING_BRANCHES=y
CONFIG_BRANCH_TRACER=y
# CONFIG_STACK_TRACER is not set
# CONFIG_UPROBE_EVENT is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
CONFIG_TRACEPOINT_BENCHMARK=y
CONFIG_RING_BUFFER_BENCHMARK=y
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
CONFIG_TRACE_ENUM_MAP_FILE=y
#
# Runtime Testing
#
CONFIG_TEST_LIST_SORT=y
# CONFIG_BACKTRACE_SELF_TEST is not set
CONFIG_RBTREE_TEST=y
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_TEST_HEXDUMP=y
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_TEST_RHASHTABLE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_BUILD_DOCSRC=y
# CONFIG_DMA_API_DEBUG is not set
CONFIG_TEST_FIRMWARE=y
# CONFIG_TEST_UDELAY is not set
# CONFIG_MEMTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_STRICT_DEVMEM=y
CONFIG_X86_VERBOSE_BOOTUP=y
# CONFIG_EARLY_PRINTK is not set
CONFIG_X86_PTDUMP=y
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DOUBLEFAULT is not set
CONFIG_DEBUG_TLBFLUSH=y
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_X86_DEBUG_STATIC_CPU_HAS is not set
CONFIG_X86_DEBUG_FPU=y
# CONFIG_PUNIT_ATOM_DEBUG is not set
#
# Security options
#
CONFIG_KEYS=y
CONFIG_PERSISTENT_KEYRINGS=y
# CONFIG_BIG_KEYS is not set
# CONFIG_TRUSTED_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
CONFIG_SECURITY_DMESG_RESTRICT=y
# CONFIG_SECURITY is not set
CONFIG_SECURITYFS=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_RSA=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
# CONFIG_CRYPTO_MCRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_ABLK_HELPER=y
CONFIG_CRYPTO_GLUE_HELPER_X86=y
#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=y
CONFIG_CRYPTO_GCM=y
CONFIG_CRYPTO_CHACHA20POLY1305=y
CONFIG_CRYPTO_SEQIV=y
# CONFIG_CRYPTO_ECHAINIV is not set
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_PCBC=y
CONFIG_CRYPTO_XTS=y
#
# Hash modes
#
CONFIG_CRYPTO_CMAC=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
CONFIG_CRYPTO_VMAC=y
#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
CONFIG_CRYPTO_CRC32=y
CONFIG_CRYPTO_CRC32_PCLMUL=y
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_GHASH=y
CONFIG_CRYPTO_POLY1305=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_RMD128=y
CONFIG_CRYPTO_RMD160=y
# CONFIG_CRYPTO_RMD256 is not set
CONFIG_CRYPTO_RMD320=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_WP512=y
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_AES_NI_INTEL=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAST_COMMON=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_SALSA20=y
# CONFIG_CRYPTO_SALSA20_586 is not set
CONFIG_CRYPTO_CHACHA20=y
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_SERPENT_SSE2_586=y
CONFIG_CRYPTO_TEA=y
# CONFIG_CRYPTO_TWOFISH is not set
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_586=y
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_ZLIB=y
CONFIG_CRYPTO_LZO=y
CONFIG_CRYPTO_842=y
CONFIG_CRYPTO_LZ4=y
# CONFIG_CRYPTO_LZ4HC is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_DRBG_MENU=y
CONFIG_CRYPTO_DRBG_HMAC=y
CONFIG_CRYPTO_DRBG_HASH=y
CONFIG_CRYPTO_DRBG_CTR=y
CONFIG_CRYPTO_DRBG=y
CONFIG_CRYPTO_JITTERENTROPY=y
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_ASYMMETRIC_KEY_TYPE=y
# CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE is not set
CONFIG_PUBLIC_KEY_ALGO_RSA=y
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
# CONFIG_LGUEST is not set
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_HAVE_ARCH_BITREVERSE is not set
CONFIG_RATIONAL=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_PERCPU_RWSEM=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_CRC8=y
# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_842_COMPRESS=y
CONFIG_842_DECOMPRESS=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_COMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
# CONFIG_XZ_DEC_POWERPC is not set
CONFIG_XZ_DEC_IA64=y
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_BCH=y
CONFIG_BCH_CONST_PARAMS=y
CONFIG_ASSOCIATIVE_ARRAY=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
CONFIG_CLZ_TAB=y
CONFIG_CORDIC=y
CONFIG_DDR=y
CONFIG_MPILIB=y
CONFIG_LIBFDT=y
CONFIG_ARCH_HAS_SG_CHAIN=y
CONFIG_ARCH_HAS_PMEM_API=y
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [rcu] kernel BUG at include/linux/pagemap.h:149!
2015-09-10 0:57 [rcu] kernel BUG at include/linux/pagemap.h:149! Fengguang Wu
@ 2015-09-10 10:25 ` Boqun Feng
2015-09-10 17:16 ` Paul E. McKenney
0 siblings, 1 reply; 62+ messages in thread
From: Boqun Feng @ 2015-09-10 10:25 UTC (permalink / raw)
To: Fengguang Wu; +Cc: Paul E. McKenney, LKP, LKML, Frederic Weisbecker
Hi Fengguang,
On Thu, Sep 10, 2015 at 08:57:08AM +0800, Fengguang Wu wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2015.09.01a
>
> commit d0a795e7964cca98fbefefef5e0c330b24d04f50
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> AuthorDate: Thu Jul 30 16:55:38 2015 -0700
> Commit: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> CommitDate: Mon Aug 31 14:38:03 2015 -0700
>
> rcu: Don't disable preemption for Tiny and Tree RCU readers
>
> Because preempt_disable() maps to barrier() for non-debug builds,
> it forces the compiler to spill and reload registers. Because Tree
> RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
> barrier() instances generate needless extra code for each instance of
> rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
> RCU and bloats Tiny RCU.
>
> This commit therefore removes the preempt_disable() and preempt_enable()
> from the non-preemptible implementations of __rcu_read_lock() and
> __rcu_read_unlock(), respectively.
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> +------------------------------------------------+------------+------------+------------+
> | | 2d0f6efd31 | d0a795e796 | d0a795e796 |
> +------------------------------------------------+------------+------------+------------+
> | boot_successes | 63 | 0 | 0 |
> | boot_failures | 2 | 42 | 42 |
> | IP-Config:Auto-configuration_of_network_failed | 2 | | |
> | kernel_BUG_at_include/linux/pagemap.h | 0 | 42 | 42 |
> | invalid_opcode | 0 | 42 | 42 |
> | EIP_is_at_page_cache_get_speculative | 0 | 42 | 42 |
> | Kernel_panic-not_syncing:Fatal_exception | 0 | 42 | 42 |
> | backtrace:vfs_write | 0 | 42 | 42 |
> | backtrace:SyS_write | 0 | 42 | 42 |
> | backtrace:populate_rootfs | 0 | 42 | 42 |
> | backtrace:kernel_init_freeable | 0 | 42 | 42 |
> +------------------------------------------------+------------+------------+------------+
>
> dmesg for d0a795e796 and 2d0f6efd31 are both attached.
>
> [ 0.205937] PCI: CLS 0 bytes, default 32
> [ 0.206554] Unpacking initramfs...
> [ 0.208263] ------------[ cut here ]------------
> [ 0.209011] kernel BUG at include/linux/pagemap.h:149!
Code here is:
#ifdef CONFIG_TINY_RCU
# ifdef CONFIG_PREEMPT_COUNT
VM_BUG_ON(!in_atomic()); <-- BUG triggered here.
# endif
...
#endif
This indicates that CONFIG_TINY_RCU and CONFIG_PREEMPT_COUNT are both y.
Normally, IIUC, this is not possible or meaningless, because TINY_RCU is
for !PREEMPT kernel. However, according to commmit e8f7c70f4 ("sched:
Make sleeping inside spinlock detection working in !CONFIG_PREEMPT"),
maintaining preempt counts in !PREEMPT kernel makes sense for finding
preempt-related bugs.
So a possible fix would be still counting preempt_count in
rcu_read_lock and rcu_read_unlock if PREEMPT_COUNT is y for debug
purpose:
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 07f9b95..887bf5f 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -297,10 +297,16 @@ void synchronize_rcu(void);
static inline void __rcu_read_lock(void)
{
+#ifdef CONFIG_PREEMPT_COUNT
+ preempt_disable();
+#endif
}
static inline void __rcu_read_unlock(void)
{
+#ifdef CONFIG_PREEMPT_COUNT
+ preempt_enable();
+#endif
}
I did a simple booting test with the some configuration on a guest on
x86, didn't see this error again.
(Also add Frederic Weisbecker to CCed)
Regards,
Boqun
> [ 0.209033] invalid opcode: 0000 [#1] DEBUG_PAGEALLOC
> [ 0.209033] CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-rc1-00078-gd0a795e #1
> [ 0.209033] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> [ 0.209033] task: 8b1aa040 ti: 8b1ac000 task.ti: 8b1ac000
> [ 0.209033] EIP: 0060:[<7dccf506>] EFLAGS: 00010202 CPU: 0
> [ 0.209033] EIP is at page_cache_get_speculative+0x6c/0x149
> [ 0.209033] EAX: 00000001 EBX: 8ac00101 ECX: 00000000 EDX: 00000001
> [ 0.209033] ESI: 8bb946e0 EDI: 00000001 EBP: 8b1adc7c ESP: 8b1adc70
> [ 0.209033] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
> [ 0.209033] CR0: 8005003b CR2: ffffffff CR3: 069fb000 CR4: 00000690
> [ 0.209033] Stack:
> [ 0.209033] 8ac0012c 8bb946e0 00000000 8b1adc9c 7dcd1219 8ad5ac7c 00000007 00000002
> [ 0.209033] 000200d2 00000000 00000000 8b1adcc0 7dcd136c 00000007 00000000 8ad5ac78
> [ 0.209033] 0000000f 000200d2 00000000 00000000 8b1adcd4 7dcd3609 000200d2 000009e8
> [ 0.209033] Call Trace:
> [ 0.209033] [<7dcd1219>] find_get_entry+0xce/0x133
> [ 0.209033] [<7dcd136c>] pagecache_get_page+0x1d/0x39d
> [ 0.209033] [<7dcd3609>] grab_cache_page_write_begin+0x3a/0x68
> [ 0.209033] [<7dd58353>] simple_write_begin+0x2d/0xbf
> [ 0.209033] [<7dcd3703>] generic_perform_write+0xcc/0x26f
> [ 0.209033] [<7dd4c3e5>] ? file_update_time+0x12b/0x135
> [ 0.209033] [<7dcd3a79>] __generic_file_write_iter+0x1d3/0x233
> [ 0.209033] [<7dcd3b2f>] generic_file_write_iter+0x56/0x128
> [ 0.209033] [<7dd2d866>] __vfs_write+0x99/0x106
> [ 0.209033] [<7dd2da75>] vfs_write+0xf7/0x136
> [ 0.209033] [<7dd2dbbc>] SyS_write+0x61/0xa7
> [ 0.209033] [<7e967bdd>] xwrite+0x23/0xa1
> [ 0.209033] [<7e967d10>] do_copy+0xb5/0xf9
> [ 0.209033] [<7e96781a>] write_buffer+0x1d/0x2c
> [ 0.209033] [<7e9679c1>] flush_buffer+0x3c/0xb0
> [ 0.209033] [<7e98e1dc>] gunzip+0x3a0/0x4b0
> [ 0.209033] [<7e98de34>] ? bunzip2+0x60c/0x60c
> [ 0.209033] [<7e98de3c>] ? nofill+0x8/0x8
> [ 0.209033] [<7e96838a>] unpack_to_rootfs+0x1b0/0x2ee
> [ 0.209033] [<7e967985>] ? error+0x2c/0x2c
> [ 0.209033] [<7e967959>] ? do_start+0x1b/0x1b
> [ 0.209033] [<7e968546>] populate_rootfs+0x7e/0x199
> [ 0.209033] [<7e966f01>] do_one_initcall+0x130/0x216
> [ 0.209033] [<7e966506>] ? repair_env_string+0x29/0x96
> [ 0.209033] [<7e9684c8>] ? unpack_to_rootfs+0x2ee/0x2ee
> [ 0.209033] [<7dc59bec>] ? parse_args+0x343/0x40a
> [ 0.209033] [<7e9670be>] ? kernel_init_freeable+0xd7/0x1b4
> [ 0.209033] [<7e9670de>] kernel_init_freeable+0xf7/0x1b4
> [ 0.209033] [<7e2736cf>] kernel_init+0x9/0x139
> [ 0.209033] [<7e281f00>] ret_from_kernel_thread+0x20/0x30
> [ 0.209033] [<7e2736c6>] ? rest_init+0x11e/0x11e
> [ 0.209033] Code: ff ff ff 7f b8 dc 98 77 7e 0f 94 c3 31 c9 0f b6 fb 89 fa e8 c7 50 fe ff 8b 04 bd dc 8a 7d 7e 40 84 db 89 04 bd dc 8a 7d 7e 74 02 <0f> 0b 8b 1e 31 c9 b8 a0 98 77 7e c1 eb 0f 83 e3 01 89 da e8 9c
> [ 0.209033] EIP: [<7dccf506>] page_cache_get_speculative+0x6c/0x149 SS:ESP 0068:8b1adc70
> [ 0.240927] ---[ end trace b15ce49b08a81922 ]---
> [ 0.241403] Kernel panic - not syncing: Fatal exception
>
> git bisect start d0a795e7964cca98fbefefef5e0c330b24d04f50 d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754 --
> git bisect good 8ff4fbfd69a6c7b9598f8c1f2df34f89bac02c1a # 06:49 22+ 0 Merge branches 'fixes.2015.07.22a' and 'initexp.2015.08.04a' into HEAD
> git bisect good 8611bc8cfdb809852e15c8c8786fe0fbd72e7da7 # 06:54 22+ 0 rcu_sync: Introduce rcu_sync_dtor()
> git bisect good d74251b8bae07a4957c9f3ccecbdb7f84d790f38 # 07:03 22+ 0 locking/percpu-rwsem: Clean up the lockdep annotations in percpu_down_read()
> git bisect good 51899e3fb9b8de48dff0ab1a9cc5250c6d4020ac # 07:09 22+ 0 rcu: Use rcu_callback_t in call_rcu*() and friends
> git bisect good e8ee682bcce44c81d8363009b08f115e964dbd0b # 07:14 21+ 2 rcu: Use call_rcu_func_to to replace explicit type equivalents
> git bisect good 2d0f6efd311165fe06cecb29475e89e550b92d8c # 07:22 22+ 0 rcu: Use rsp->expedited_wq instead of sync_rcu_preempt_exp_wq
> # first bad commit: [d0a795e7964cca98fbefefef5e0c330b24d04f50] rcu: Don't disable preemption for Tiny and Tree RCU readers
> git bisect good 2d0f6efd311165fe06cecb29475e89e550b92d8c # 07:26 63+ 2 rcu: Use rsp->expedited_wq instead of sync_rcu_preempt_exp_wq
> # extra tests on HEAD of linux-devel/devel-spot-201509091835
> git bisect bad 325c0efb5f89af4e5e3d0575ea1b042375dedf6b # 07:31 0- 2 0day head guard for 'devel-spot-201509091835'
> # extra tests on tree/branch rcu/dev.2015.09.01a
> git bisect bad caa7dd68d68438b256ee830f4aa6b2ddd04b4575 # 07:36 0- 11 locktorture: Fix module unwind when bad torture_type specified
> # extra tests with first bad commit reverted
> git bisect good 9ff21ff24e5557ad2c1bd72b63f969609e0d28f8 # 07:42 66+ 2 Revert "rcu: Don't disable preemption for Tiny and Tree RCU readers"
> # extra tests on tree/branch linus/master
> git bisect good b8889c4fc6ba03e289cec6a4d692f6f080a55e53 # 07:50 66+ 0 Merge tag 'tty-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
> # extra tests on tree/branch linux-next/master
> git bisect good 72c9d8043fdc87832802de0b7a7129d6fc4c4c70 # 07:58 63+ 0 Add linux-next specific files for 20150909
>
>
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [rcu] kernel BUG at include/linux/pagemap.h:149!
2015-09-10 10:25 ` Boqun Feng
@ 2015-09-10 17:16 ` Paul E. McKenney
2015-09-11 2:19 ` Boqun Feng
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2015-09-10 17:16 UTC (permalink / raw)
To: Boqun Feng; +Cc: Fengguang Wu, LKP, LKML, Frederic Weisbecker
On Thu, Sep 10, 2015 at 06:25:13PM +0800, Boqun Feng wrote:
> Hi Fengguang,
>
> On Thu, Sep 10, 2015 at 08:57:08AM +0800, Fengguang Wu wrote:
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2015.09.01a
> >
> > commit d0a795e7964cca98fbefefef5e0c330b24d04f50
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > AuthorDate: Thu Jul 30 16:55:38 2015 -0700
> > Commit: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > CommitDate: Mon Aug 31 14:38:03 2015 -0700
> >
> > rcu: Don't disable preemption for Tiny and Tree RCU readers
> >
> > Because preempt_disable() maps to barrier() for non-debug builds,
> > it forces the compiler to spill and reload registers. Because Tree
> > RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
> > barrier() instances generate needless extra code for each instance of
> > rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
> > RCU and bloats Tiny RCU.
> >
> > This commit therefore removes the preempt_disable() and preempt_enable()
> > from the non-preemptible implementations of __rcu_read_lock() and
> > __rcu_read_unlock(), respectively.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >
> > +------------------------------------------------+------------+------------+------------+
> > | | 2d0f6efd31 | d0a795e796 | d0a795e796 |
> > +------------------------------------------------+------------+------------+------------+
> > | boot_successes | 63 | 0 | 0 |
> > | boot_failures | 2 | 42 | 42 |
> > | IP-Config:Auto-configuration_of_network_failed | 2 | | |
> > | kernel_BUG_at_include/linux/pagemap.h | 0 | 42 | 42 |
> > | invalid_opcode | 0 | 42 | 42 |
> > | EIP_is_at_page_cache_get_speculative | 0 | 42 | 42 |
> > | Kernel_panic-not_syncing:Fatal_exception | 0 | 42 | 42 |
> > | backtrace:vfs_write | 0 | 42 | 42 |
> > | backtrace:SyS_write | 0 | 42 | 42 |
> > | backtrace:populate_rootfs | 0 | 42 | 42 |
> > | backtrace:kernel_init_freeable | 0 | 42 | 42 |
> > +------------------------------------------------+------------+------------+------------+
> >
> > dmesg for d0a795e796 and 2d0f6efd31 are both attached.
> >
> > [ 0.205937] PCI: CLS 0 bytes, default 32
> > [ 0.206554] Unpacking initramfs...
> > [ 0.208263] ------------[ cut here ]------------
> > [ 0.209011] kernel BUG at include/linux/pagemap.h:149!
>
> Code here is:
>
> #ifdef CONFIG_TINY_RCU
> # ifdef CONFIG_PREEMPT_COUNT
> VM_BUG_ON(!in_atomic()); <-- BUG triggered here.
> # endif
> ...
> #endif
>
> This indicates that CONFIG_TINY_RCU and CONFIG_PREEMPT_COUNT are both y.
> Normally, IIUC, this is not possible or meaningless, because TINY_RCU is
> for !PREEMPT kernel. However, according to commmit e8f7c70f4 ("sched:
> Make sleeping inside spinlock detection working in !CONFIG_PREEMPT"),
> maintaining preempt counts in !PREEMPT kernel makes sense for finding
> preempt-related bugs.
Good analysis, thank you!
> So a possible fix would be still counting preempt_count in
> rcu_read_lock and rcu_read_unlock if PREEMPT_COUNT is y for debug
> purpose:
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 07f9b95..887bf5f 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -297,10 +297,16 @@ void synchronize_rcu(void);
>
> static inline void __rcu_read_lock(void)
> {
> +#ifdef CONFIG_PREEMPT_COUNT
> + preempt_disable();
> +#endif
We can save a line as follows:
if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
preempt_disable();
This approach also has the advantage of letting the compiler look at
more of the code, so that compiler errors in strange combinations of
configurations are less likely to be missed.
> }
>
> static inline void __rcu_read_unlock(void)
> {
> +#ifdef CONFIG_PREEMPT_COUNT
> + preempt_enable();
> +#endif
> }
>
> I did a simple booting test with the some configuration on a guest on
> x86, didn't see this error again.
>
> (Also add Frederic Weisbecker to CCed)
Would you like to send me a replacement patch?
Thanx, Paul
> Regards,
> Boqun
>
> > [ 0.209033] invalid opcode: 0000 [#1] DEBUG_PAGEALLOC
> > [ 0.209033] CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-rc1-00078-gd0a795e #1
> > [ 0.209033] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> > [ 0.209033] task: 8b1aa040 ti: 8b1ac000 task.ti: 8b1ac000
> > [ 0.209033] EIP: 0060:[<7dccf506>] EFLAGS: 00010202 CPU: 0
> > [ 0.209033] EIP is at page_cache_get_speculative+0x6c/0x149
> > [ 0.209033] EAX: 00000001 EBX: 8ac00101 ECX: 00000000 EDX: 00000001
> > [ 0.209033] ESI: 8bb946e0 EDI: 00000001 EBP: 8b1adc7c ESP: 8b1adc70
> > [ 0.209033] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
> > [ 0.209033] CR0: 8005003b CR2: ffffffff CR3: 069fb000 CR4: 00000690
> > [ 0.209033] Stack:
> > [ 0.209033] 8ac0012c 8bb946e0 00000000 8b1adc9c 7dcd1219 8ad5ac7c 00000007 00000002
> > [ 0.209033] 000200d2 00000000 00000000 8b1adcc0 7dcd136c 00000007 00000000 8ad5ac78
> > [ 0.209033] 0000000f 000200d2 00000000 00000000 8b1adcd4 7dcd3609 000200d2 000009e8
> > [ 0.209033] Call Trace:
> > [ 0.209033] [<7dcd1219>] find_get_entry+0xce/0x133
> > [ 0.209033] [<7dcd136c>] pagecache_get_page+0x1d/0x39d
> > [ 0.209033] [<7dcd3609>] grab_cache_page_write_begin+0x3a/0x68
> > [ 0.209033] [<7dd58353>] simple_write_begin+0x2d/0xbf
> > [ 0.209033] [<7dcd3703>] generic_perform_write+0xcc/0x26f
> > [ 0.209033] [<7dd4c3e5>] ? file_update_time+0x12b/0x135
> > [ 0.209033] [<7dcd3a79>] __generic_file_write_iter+0x1d3/0x233
> > [ 0.209033] [<7dcd3b2f>] generic_file_write_iter+0x56/0x128
> > [ 0.209033] [<7dd2d866>] __vfs_write+0x99/0x106
> > [ 0.209033] [<7dd2da75>] vfs_write+0xf7/0x136
> > [ 0.209033] [<7dd2dbbc>] SyS_write+0x61/0xa7
> > [ 0.209033] [<7e967bdd>] xwrite+0x23/0xa1
> > [ 0.209033] [<7e967d10>] do_copy+0xb5/0xf9
> > [ 0.209033] [<7e96781a>] write_buffer+0x1d/0x2c
> > [ 0.209033] [<7e9679c1>] flush_buffer+0x3c/0xb0
> > [ 0.209033] [<7e98e1dc>] gunzip+0x3a0/0x4b0
> > [ 0.209033] [<7e98de34>] ? bunzip2+0x60c/0x60c
> > [ 0.209033] [<7e98de3c>] ? nofill+0x8/0x8
> > [ 0.209033] [<7e96838a>] unpack_to_rootfs+0x1b0/0x2ee
> > [ 0.209033] [<7e967985>] ? error+0x2c/0x2c
> > [ 0.209033] [<7e967959>] ? do_start+0x1b/0x1b
> > [ 0.209033] [<7e968546>] populate_rootfs+0x7e/0x199
> > [ 0.209033] [<7e966f01>] do_one_initcall+0x130/0x216
> > [ 0.209033] [<7e966506>] ? repair_env_string+0x29/0x96
> > [ 0.209033] [<7e9684c8>] ? unpack_to_rootfs+0x2ee/0x2ee
> > [ 0.209033] [<7dc59bec>] ? parse_args+0x343/0x40a
> > [ 0.209033] [<7e9670be>] ? kernel_init_freeable+0xd7/0x1b4
> > [ 0.209033] [<7e9670de>] kernel_init_freeable+0xf7/0x1b4
> > [ 0.209033] [<7e2736cf>] kernel_init+0x9/0x139
> > [ 0.209033] [<7e281f00>] ret_from_kernel_thread+0x20/0x30
> > [ 0.209033] [<7e2736c6>] ? rest_init+0x11e/0x11e
> > [ 0.209033] Code: ff ff ff 7f b8 dc 98 77 7e 0f 94 c3 31 c9 0f b6 fb 89 fa e8 c7 50 fe ff 8b 04 bd dc 8a 7d 7e 40 84 db 89 04 bd dc 8a 7d 7e 74 02 <0f> 0b 8b 1e 31 c9 b8 a0 98 77 7e c1 eb 0f 83 e3 01 89 da e8 9c
> > [ 0.209033] EIP: [<7dccf506>] page_cache_get_speculative+0x6c/0x149 SS:ESP 0068:8b1adc70
> > [ 0.240927] ---[ end trace b15ce49b08a81922 ]---
> > [ 0.241403] Kernel panic - not syncing: Fatal exception
> >
> > git bisect start d0a795e7964cca98fbefefef5e0c330b24d04f50 d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754 --
> > git bisect good 8ff4fbfd69a6c7b9598f8c1f2df34f89bac02c1a # 06:49 22+ 0 Merge branches 'fixes.2015.07.22a' and 'initexp.2015.08.04a' into HEAD
> > git bisect good 8611bc8cfdb809852e15c8c8786fe0fbd72e7da7 # 06:54 22+ 0 rcu_sync: Introduce rcu_sync_dtor()
> > git bisect good d74251b8bae07a4957c9f3ccecbdb7f84d790f38 # 07:03 22+ 0 locking/percpu-rwsem: Clean up the lockdep annotations in percpu_down_read()
> > git bisect good 51899e3fb9b8de48dff0ab1a9cc5250c6d4020ac # 07:09 22+ 0 rcu: Use rcu_callback_t in call_rcu*() and friends
> > git bisect good e8ee682bcce44c81d8363009b08f115e964dbd0b # 07:14 21+ 2 rcu: Use call_rcu_func_to to replace explicit type equivalents
> > git bisect good 2d0f6efd311165fe06cecb29475e89e550b92d8c # 07:22 22+ 0 rcu: Use rsp->expedited_wq instead of sync_rcu_preempt_exp_wq
> > # first bad commit: [d0a795e7964cca98fbefefef5e0c330b24d04f50] rcu: Don't disable preemption for Tiny and Tree RCU readers
> > git bisect good 2d0f6efd311165fe06cecb29475e89e550b92d8c # 07:26 63+ 2 rcu: Use rsp->expedited_wq instead of sync_rcu_preempt_exp_wq
> > # extra tests on HEAD of linux-devel/devel-spot-201509091835
> > git bisect bad 325c0efb5f89af4e5e3d0575ea1b042375dedf6b # 07:31 0- 2 0day head guard for 'devel-spot-201509091835'
> > # extra tests on tree/branch rcu/dev.2015.09.01a
> > git bisect bad caa7dd68d68438b256ee830f4aa6b2ddd04b4575 # 07:36 0- 11 locktorture: Fix module unwind when bad torture_type specified
> > # extra tests with first bad commit reverted
> > git bisect good 9ff21ff24e5557ad2c1bd72b63f969609e0d28f8 # 07:42 66+ 2 Revert "rcu: Don't disable preemption for Tiny and Tree RCU readers"
> > # extra tests on tree/branch linus/master
> > git bisect good b8889c4fc6ba03e289cec6a4d692f6f080a55e53 # 07:50 66+ 0 Merge tag 'tty-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
> > # extra tests on tree/branch linux-next/master
> > git bisect good 72c9d8043fdc87832802de0b7a7129d6fc4c4c70 # 07:58 63+ 0 Add linux-next specific files for 20150909
> >
> >
>
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [rcu] kernel BUG at include/linux/pagemap.h:149!
2015-09-10 17:16 ` Paul E. McKenney
@ 2015-09-11 2:19 ` Boqun Feng
[not found] ` <CAJzB8QG=1iZW3dQEie6ZSTLv8GZ3YSut0aL1VU7LLmiHQ1B1DQ@mail.gmail.com>
2015-09-21 19:30 ` Frederic Weisbecker
0 siblings, 2 replies; 62+ messages in thread
From: Boqun Feng @ 2015-09-11 2:19 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: Fengguang Wu, LKP, LKML, Frederic Weisbecker
Hi Paul
On Thu, Sep 10, 2015 at 10:16:49AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 10, 2015 at 06:25:13PM +0800, Boqun Feng wrote:
[snip]
> >
> > Code here is:
> >
> > #ifdef CONFIG_TINY_RCU
> > # ifdef CONFIG_PREEMPT_COUNT
> > VM_BUG_ON(!in_atomic()); <-- BUG triggered here.
> > # endif
> > ...
> > #endif
> >
> > This indicates that CONFIG_TINY_RCU and CONFIG_PREEMPT_COUNT are both y.
> > Normally, IIUC, this is not possible or meaningless, because TINY_RCU is
> > for !PREEMPT kernel. However, according to commmit e8f7c70f4 ("sched:
> > Make sleeping inside spinlock detection working in !CONFIG_PREEMPT"),
> > maintaining preempt counts in !PREEMPT kernel makes sense for finding
> > preempt-related bugs.
>
> Good analysis, thank you!
>
> > So a possible fix would be still counting preempt_count in
> > rcu_read_lock and rcu_read_unlock if PREEMPT_COUNT is y for debug
> > purpose:
> >
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 07f9b95..887bf5f 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -297,10 +297,16 @@ void synchronize_rcu(void);
> >
> > static inline void __rcu_read_lock(void)
> > {
> > +#ifdef CONFIG_PREEMPT_COUNT
> > + preempt_disable();
> > +#endif
>
> We can save a line as follows:
>
> if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> preempt_disable();
>
> This approach also has the advantage of letting the compiler look at
> more of the code, so that compiler errors in strange combinations of
> configurations are less likely to be missed.
>
Good idea, plus better readability IMO.
> > }
> >
> > static inline void __rcu_read_unlock(void)
> > {
> > +#ifdef CONFIG_PREEMPT_COUNT
> > + preempt_enable();
> > +#endif
> > }
> >
> > I did a simple booting test with the some configuration on a guest on
> > x86, didn't see this error again.
> >
> > (Also add Frederic Weisbecker to CCed)
>
> Would you like to send me a replacement patch?
>
Not sure I'm handling the Signed-off-by right.., but here it is:
(The rest on dev.2015.09.01a branch can be applied on this cleanly, and
I did a simple booting test with the same configuration on a guest on
x86, didn't see the reported error again)
--------------->8
Subject: [PATCH 01/27] rcu: Don't disable preemption for Tiny and Tree RCU
readers
Because preempt_disable() maps to barrier() for non-debug builds,
it forces the compiler to spill and reload registers. Because Tree
RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
barrier() instances generate needless extra code for each instance of
rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
RCU and bloats Tiny RCU.
This commit therefore removes the preempt_disable() and preempt_enable()
from the non-preemptible implementations of __rcu_read_lock() and
__rcu_read_unlock(), respectively.
For debug purposes, preempt_disable() and preempt_enable() are still
kept if CONFIG_PREEMPT_COUNT=y, which makes the detection of sleeping
inside atomic sections still work in non-preemptible kernels.
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
include/linux/rcupdate.h | 6 ++++--
include/linux/rcutiny.h | 1 +
kernel/rcu/tree.c | 9 +++++++++
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index d63bb77..6c3cece 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -297,12 +297,14 @@ void synchronize_rcu(void);
static inline void __rcu_read_lock(void)
{
- preempt_disable();
+ if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
+ preempt_disable();
}
static inline void __rcu_read_unlock(void)
{
- preempt_enable();
+ if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
+ preempt_enable();
}
static inline void synchronize_rcu(void)
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index c8a0722..4c1aaf9 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -216,6 +216,7 @@ static inline bool rcu_is_watching(void)
static inline void rcu_all_qs(void)
{
+ barrier(); /* Avoid RCU read-side critical sections leaking across. */
}
#endif /* __LINUX_RCUTINY_H */
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index ce43fac..b4882f8 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -337,12 +337,14 @@ static void rcu_momentary_dyntick_idle(void)
*/
void rcu_note_context_switch(void)
{
+ barrier(); /* Avoid RCU read-side critical sections leaking down. */
trace_rcu_utilization(TPS("Start context switch"));
rcu_sched_qs();
rcu_preempt_note_context_switch();
if (unlikely(raw_cpu_read(rcu_sched_qs_mask)))
rcu_momentary_dyntick_idle();
trace_rcu_utilization(TPS("End context switch"));
+ barrier(); /* Avoid RCU read-side critical sections leaking up. */
}
EXPORT_SYMBOL_GPL(rcu_note_context_switch);
@@ -353,12 +355,19 @@ EXPORT_SYMBOL_GPL(rcu_note_context_switch);
* RCU flavors in desperate need of a quiescent state, which will normally
* be none of them). Either way, do a lightweight quiescent state for
* all RCU flavors.
+ *
+ * The barrier() calls are redundant in the common case when this is
+ * called externally, but just in case this is called from within this
+ * file.
+ *
*/
void rcu_all_qs(void)
{
+ barrier(); /* Avoid RCU read-side critical sections leaking down. */
if (unlikely(raw_cpu_read(rcu_sched_qs_mask)))
rcu_momentary_dyntick_idle();
this_cpu_inc(rcu_qs_ctr);
+ barrier(); /* Avoid RCU read-side critical sections leaking up. */
}
EXPORT_SYMBOL_GPL(rcu_all_qs);
^ permalink raw reply related [flat|nested] 62+ messages in thread[parent not found: <CAJzB8QG=1iZW3dQEie6ZSTLv8GZ3YSut0aL1VU7LLmiHQ1B1DQ@mail.gmail.com>]
* Re: [rcu] kernel BUG at include/linux/pagemap.h:149!
[not found] ` <CAJzB8QG=1iZW3dQEie6ZSTLv8GZ3YSut0aL1VU7LLmiHQ1B1DQ@mail.gmail.com>
@ 2015-09-11 21:59 ` Paul E. McKenney
2015-09-12 5:46 ` Boqun Feng
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2015-09-11 21:59 UTC (permalink / raw)
To: Boqun Feng; +Cc: Fengguang Wu, LKP, LKML, Frederic Weisbecker
> Hi Paul
>
> On Thu, Sep 10, 2015 at 10:16:49AM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 10, 2015 at 06:25:13PM +0800, Boqun Feng wrote:
> [snip]
> > >
> > > Code here is:
> > >
> > > #ifdef CONFIG_TINY_RCU
> > > # ifdef CONFIG_PREEMPT_COUNT
> > > VM_BUG_ON(!in_atomic()); <-- BUG triggered here.
> > > # endif
> > > ...
> > > #endif
> > >
> > > This indicates that CONFIG_TINY_RCU and CONFIG_PREEMPT_COUNT are both y.
> > > Normally, IIUC, this is not possible or meaningless, because TINY_RCU is
> > > for !PREEMPT kernel. However, according to commmit e8f7c70f4 ("sched:
> > > Make sleeping inside spinlock detection working in !CONFIG_PREEMPT"),
> > > maintaining preempt counts in !PREEMPT kernel makes sense for finding
> > > preempt-related bugs.
> >
> > Good analysis, thank you!
> >
> > > So a possible fix would be still counting preempt_count in
> > > rcu_read_lock and rcu_read_unlock if PREEMPT_COUNT is y for debug
> > > purpose:
> > >
> > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > index 07f9b95..887bf5f 100644
> > > --- a/include/linux/rcupdate.h
> > > +++ b/include/linux/rcupdate.h
> > > @@ -297,10 +297,16 @@ void synchronize_rcu(void);
> > >
> > > static inline void __rcu_read_lock(void)
> > > {
> > > +#ifdef CONFIG_PREEMPT_COUNT
> > > + preempt_disable();
> > > +#endif
> >
> > We can save a line as follows:
> >
> > if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> > preempt_disable();
> >
> > This approach also has the advantage of letting the compiler look at
> > more of the code, so that compiler errors in strange combinations of
> > configurations are less likely to be missed.
> >
>
> Good idea, plus better readability IMO.
>
>
> > > }
> > >
> > > static inline void __rcu_read_unlock(void)
> > > {
> > > +#ifdef CONFIG_PREEMPT_COUNT
> > > + preempt_enable();
> > > +#endif
> > > }
> > >
> > > I did a simple booting test with the some configuration on a guest on
> > > x86, didn't see this error again.
> > >
> > > (Also add Frederic Weisbecker to CCed)
> >
> > Would you like to send me a replacement patch?
> >
>
> Not sure I'm handling the Signed-off-by right.., but here it is:
>
> (The rest on dev.2015.09.01a branch can be applied on this cleanly, and
> I did a simple booting test with the same configuration on a guest on
> x86, didn't see the reported error again)
Queued for v4.4, thank you! Please see below for updated commit log,
and please let me know if there are any problems with it.
Thanx, Paul
> --------------->8
> Subject: [PATCH 01/27] rcu: Don't disable preemption for Tiny and Tree RCU
> readers
>
> Because preempt_disable() maps to barrier() for non-debug builds,
> it forces the compiler to spill and reload registers. Because Tree
> RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
> barrier() instances generate needless extra code for each instance of
> rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
> RCU and bloats Tiny RCU.
>
> This commit therefore removes the preempt_disable() and preempt_enable()
> from the non-preemptible implementations of __rcu_read_lock() and
> __rcu_read_unlock(), respectively.
>
> For debug purposes, preempt_disable() and preempt_enable() are still
> kept if CONFIG_PREEMPT_COUNT=y, which makes the detection of sleeping
> inside atomic sections still work in non-preemptible kernels.
>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> include/linux/rcupdate.h | 6 ++++--
> include/linux/rcutiny.h | 1 +
> kernel/rcu/tree.c | 9 +++++++++
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index d63bb77..6c3cece 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -297,12 +297,14 @@ void synchronize_rcu(void);
>
> static inline void __rcu_read_lock(void)
> {
> - preempt_disable();
> + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> + preempt_disable();
> }
>
> static inline void __rcu_read_unlock(void)
> {
> - preempt_enable();
> + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> + preempt_enable();
> }
>
> static inline void synchronize_rcu(void)
> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> index c8a0722..4c1aaf9 100644
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -216,6 +216,7 @@ static inline bool rcu_is_watching(void)
>
> static inline void rcu_all_qs(void)
> {
> + barrier(); /* Avoid RCU read-side critical sections leaking across.
> */
> }
>
> #endif /* __LINUX_RCUTINY_H */
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index ce43fac..b4882f8 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -337,12 +337,14 @@ static void rcu_momentary_dyntick_idle(void)
> */
> void rcu_note_context_switch(void)
> {
> + barrier(); /* Avoid RCU read-side critical sections leaking down. */
> trace_rcu_utilization(TPS("Start context switch"));
> rcu_sched_qs();
> rcu_preempt_note_context_switch();
> if (unlikely(raw_cpu_read(rcu_sched_qs_mask)))
> rcu_momentary_dyntick_idle();
> trace_rcu_utilization(TPS("End context switch"));
> + barrier(); /* Avoid RCU read-side critical sections leaking up. */
> }
> EXPORT_SYMBOL_GPL(rcu_note_context_switch);
>
> @@ -353,12 +355,19 @@ EXPORT_SYMBOL_GPL(rcu_note_context_switch);
> * RCU flavors in desperate need of a quiescent state, which will normally
> * be none of them). Either way, do a lightweight quiescent state for
> * all RCU flavors.
> + *
> + * The barrier() calls are redundant in the common case when this is
> + * called externally, but just in case this is called from within this
> + * file.
> + *
> */
> void rcu_all_qs(void)
> {
> + barrier(); /* Avoid RCU read-side critical sections leaking down. */
> if (unlikely(raw_cpu_read(rcu_sched_qs_mask)))
> rcu_momentary_dyntick_idle();
> this_cpu_inc(rcu_qs_ctr);
> + barrier(); /* Avoid RCU read-side critical sections leaking up. */
> }
> EXPORT_SYMBOL_GPL(rcu_all_qs);
------------------------------------------------------------------------
rcu: Don't disable preemption for Tiny and Tree RCU readers
Because preempt_disable() maps to barrier() for non-debug builds,
it forces the compiler to spill and reload registers. Because Tree
RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
barrier() instances generate needless extra code for each instance of
rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
RCU and bloats Tiny RCU.
This commit therefore removes the preempt_disable() and preempt_enable()
from the non-preemptible implementations of __rcu_read_lock() and
__rcu_read_unlock(), respectively. However, for debug purposes,
preempt_disable() and preempt_enable() are still invoked if
CONFIG_PREEMPT_COUNT=y, because this allows detection of sleeping inside
atomic sections in non-preemptible kernels.
This is based on an earlier patch by Paul E. McKenney, fixing
a bug encountered in kernels built with CONFIG_PREEMPT=n and
CONFIG_PREEMPT_COUNT=y.
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index d63bb77dab35..6c3ceceb6148 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -297,12 +297,14 @@ void synchronize_rcu(void);
static inline void __rcu_read_lock(void)
{
- preempt_disable();
+ if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
+ preempt_disable();
}
static inline void __rcu_read_unlock(void)
{
- preempt_enable();
+ if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
+ preempt_enable();
}
static inline void synchronize_rcu(void)
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index c8a0722f77ea..4c1aaf9cce7b 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -216,6 +216,7 @@ static inline bool rcu_is_watching(void)
static inline void rcu_all_qs(void)
{
+ barrier(); /* Avoid RCU read-side critical sections leaking across. */
}
#endif /* __LINUX_RCUTINY_H */
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index ce43fac5ff91..b4882f8b8a9e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -337,12 +337,14 @@ static void rcu_momentary_dyntick_idle(void)
*/
void rcu_note_context_switch(void)
{
+ barrier(); /* Avoid RCU read-side critical sections leaking down. */
trace_rcu_utilization(TPS("Start context switch"));
rcu_sched_qs();
rcu_preempt_note_context_switch();
if (unlikely(raw_cpu_read(rcu_sched_qs_mask)))
rcu_momentary_dyntick_idle();
trace_rcu_utilization(TPS("End context switch"));
+ barrier(); /* Avoid RCU read-side critical sections leaking up. */
}
EXPORT_SYMBOL_GPL(rcu_note_context_switch);
@@ -353,12 +355,19 @@ EXPORT_SYMBOL_GPL(rcu_note_context_switch);
* RCU flavors in desperate need of a quiescent state, which will normally
* be none of them). Either way, do a lightweight quiescent state for
* all RCU flavors.
+ *
+ * The barrier() calls are redundant in the common case when this is
+ * called externally, but just in case this is called from within this
+ * file.
+ *
*/
void rcu_all_qs(void)
{
+ barrier(); /* Avoid RCU read-side critical sections leaking down. */
if (unlikely(raw_cpu_read(rcu_sched_qs_mask)))
rcu_momentary_dyntick_idle();
this_cpu_inc(rcu_qs_ctr);
+ barrier(); /* Avoid RCU read-side critical sections leaking up. */
}
EXPORT_SYMBOL_GPL(rcu_all_qs);
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [rcu] kernel BUG at include/linux/pagemap.h:149!
2015-09-11 21:59 ` Paul E. McKenney
@ 2015-09-12 5:46 ` Boqun Feng
0 siblings, 0 replies; 62+ messages in thread
From: Boqun Feng @ 2015-09-12 5:46 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: Fengguang Wu, LKP, LKML, Frederic Weisbecker
[-- Attachment #1: Type: text/plain, Size: 4093 bytes --]
On Fri, Sep 11, 2015 at 02:59:37PM -0700, Paul E. McKenney wrote:
>
> Queued for v4.4, thank you! Please see below for updated commit log,
> and please let me know if there are any problems with it.
>
Looks great to me! Thank you ;-)
Regards,
Boqun
> ------------------------------------------------------------------------
>
> rcu: Don't disable preemption for Tiny and Tree RCU readers
>
> Because preempt_disable() maps to barrier() for non-debug builds,
> it forces the compiler to spill and reload registers. Because Tree
> RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
> barrier() instances generate needless extra code for each instance of
> rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
> RCU and bloats Tiny RCU.
>
> This commit therefore removes the preempt_disable() and preempt_enable()
> from the non-preemptible implementations of __rcu_read_lock() and
> __rcu_read_unlock(), respectively. However, for debug purposes,
> preempt_disable() and preempt_enable() are still invoked if
> CONFIG_PREEMPT_COUNT=y, because this allows detection of sleeping inside
> atomic sections in non-preemptible kernels.
>
> This is based on an earlier patch by Paul E. McKenney, fixing
> a bug encountered in kernels built with CONFIG_PREEMPT=n and
> CONFIG_PREEMPT_COUNT=y.
>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index d63bb77dab35..6c3ceceb6148 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -297,12 +297,14 @@ void synchronize_rcu(void);
>
> static inline void __rcu_read_lock(void)
> {
> - preempt_disable();
> + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> + preempt_disable();
> }
>
> static inline void __rcu_read_unlock(void)
> {
> - preempt_enable();
> + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> + preempt_enable();
> }
>
> static inline void synchronize_rcu(void)
> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> index c8a0722f77ea..4c1aaf9cce7b 100644
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -216,6 +216,7 @@ static inline bool rcu_is_watching(void)
>
> static inline void rcu_all_qs(void)
> {
> + barrier(); /* Avoid RCU read-side critical sections leaking across. */
> }
>
> #endif /* __LINUX_RCUTINY_H */
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index ce43fac5ff91..b4882f8b8a9e 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -337,12 +337,14 @@ static void rcu_momentary_dyntick_idle(void)
> */
> void rcu_note_context_switch(void)
> {
> + barrier(); /* Avoid RCU read-side critical sections leaking down. */
> trace_rcu_utilization(TPS("Start context switch"));
> rcu_sched_qs();
> rcu_preempt_note_context_switch();
> if (unlikely(raw_cpu_read(rcu_sched_qs_mask)))
> rcu_momentary_dyntick_idle();
> trace_rcu_utilization(TPS("End context switch"));
> + barrier(); /* Avoid RCU read-side critical sections leaking up. */
> }
> EXPORT_SYMBOL_GPL(rcu_note_context_switch);
>
> @@ -353,12 +355,19 @@ EXPORT_SYMBOL_GPL(rcu_note_context_switch);
> * RCU flavors in desperate need of a quiescent state, which will normally
> * be none of them). Either way, do a lightweight quiescent state for
> * all RCU flavors.
> + *
> + * The barrier() calls are redundant in the common case when this is
> + * called externally, but just in case this is called from within this
> + * file.
> + *
> */
> void rcu_all_qs(void)
> {
> + barrier(); /* Avoid RCU read-side critical sections leaking down. */
> if (unlikely(raw_cpu_read(rcu_sched_qs_mask)))
> rcu_momentary_dyntick_idle();
> this_cpu_inc(rcu_qs_ctr);
> + barrier(); /* Avoid RCU read-side critical sections leaking up. */
> }
> EXPORT_SYMBOL_GPL(rcu_all_qs);
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [rcu] kernel BUG at include/linux/pagemap.h:149!
2015-09-11 2:19 ` Boqun Feng
[not found] ` <CAJzB8QG=1iZW3dQEie6ZSTLv8GZ3YSut0aL1VU7LLmiHQ1B1DQ@mail.gmail.com>
@ 2015-09-21 19:30 ` Frederic Weisbecker
2015-09-21 20:43 ` Paul E. McKenney
1 sibling, 1 reply; 62+ messages in thread
From: Frederic Weisbecker @ 2015-09-21 19:30 UTC (permalink / raw)
To: Boqun Feng; +Cc: Paul E. McKenney, Fengguang Wu, LKP, LKML
On Fri, Sep 11, 2015 at 10:19:47AM +0800, Boqun Feng wrote:
> Subject: [PATCH 01/27] rcu: Don't disable preemption for Tiny and Tree RCU
> readers
>
> Because preempt_disable() maps to barrier() for non-debug builds,
> it forces the compiler to spill and reload registers. Because Tree
> RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
> barrier() instances generate needless extra code for each instance of
> rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
> RCU and bloats Tiny RCU.
>
> This commit therefore removes the preempt_disable() and preempt_enable()
> from the non-preemptible implementations of __rcu_read_lock() and
> __rcu_read_unlock(), respectively.
>
> For debug purposes, preempt_disable() and preempt_enable() are still
> kept if CONFIG_PREEMPT_COUNT=y, which makes the detection of sleeping
> inside atomic sections still work in non-preemptible kernels.
>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> include/linux/rcupdate.h | 6 ++++--
> include/linux/rcutiny.h | 1 +
> kernel/rcu/tree.c | 9 +++++++++
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index d63bb77..6c3cece 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -297,12 +297,14 @@ void synchronize_rcu(void);
>
> static inline void __rcu_read_lock(void)
> {
> - preempt_disable();
> + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> + preempt_disable();
preempt_disable() is a no-op when !CONFIG_PREEMPT_COUNT, right?
Or rather it's a barrier(), which is anyway implied by rcu_read_lock().
So perhaps we can get rid of the IS_ENABLED() check?
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [rcu] kernel BUG at include/linux/pagemap.h:149!
2015-09-21 19:30 ` Frederic Weisbecker
@ 2015-09-21 20:43 ` Paul E. McKenney
2019-06-02 5:56 ` rcu_read_lock lost its compiler barrier Herbert Xu
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2015-09-21 20:43 UTC (permalink / raw)
To: Frederic Weisbecker; +Cc: Boqun Feng, Fengguang Wu, LKP, LKML
On Mon, Sep 21, 2015 at 09:30:49PM +0200, Frederic Weisbecker wrote:
> On Fri, Sep 11, 2015 at 10:19:47AM +0800, Boqun Feng wrote:
> > Subject: [PATCH 01/27] rcu: Don't disable preemption for Tiny and Tree RCU
> > readers
> >
> > Because preempt_disable() maps to barrier() for non-debug builds,
> > it forces the compiler to spill and reload registers. Because Tree
> > RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
> > barrier() instances generate needless extra code for each instance of
> > rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
> > RCU and bloats Tiny RCU.
> >
> > This commit therefore removes the preempt_disable() and preempt_enable()
> > from the non-preemptible implementations of __rcu_read_lock() and
> > __rcu_read_unlock(), respectively.
> >
> > For debug purposes, preempt_disable() and preempt_enable() are still
> > kept if CONFIG_PREEMPT_COUNT=y, which makes the detection of sleeping
> > inside atomic sections still work in non-preemptible kernels.
> >
> > Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> > include/linux/rcupdate.h | 6 ++++--
> > include/linux/rcutiny.h | 1 +
> > kernel/rcu/tree.c | 9 +++++++++
> > 3 files changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index d63bb77..6c3cece 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -297,12 +297,14 @@ void synchronize_rcu(void);
> >
> > static inline void __rcu_read_lock(void)
> > {
> > - preempt_disable();
> > + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> > + preempt_disable();
>
> preempt_disable() is a no-op when !CONFIG_PREEMPT_COUNT, right?
> Or rather it's a barrier(), which is anyway implied by rcu_read_lock().
>
> So perhaps we can get rid of the IS_ENABLED() check?
Actually, barrier() is not intended to be implied by rcu_read_lock().
In a non-preemptible RCU implementation, it doesn't help anything
to have the compiler flush its temporaries upon rcu_read_lock()
and rcu_read_unlock().
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread* rcu_read_lock lost its compiler barrier
2015-09-21 20:43 ` Paul E. McKenney
@ 2019-06-02 5:56 ` Herbert Xu
2019-06-02 20:54 ` Linus Torvalds
2019-06-03 0:06 ` Paul E. McKenney
0 siblings, 2 replies; 62+ messages in thread
From: Herbert Xu @ 2019-06-02 5:56 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Frederic Weisbecker, Boqun Feng, Fengguang Wu, LKP, LKML, netdev,
David S. Miller, Linus Torvalds
Digging up an old email because I was not aware of this previously
but Paul pointed me to it during another discussion.
On Mon, Sep 21, 2015 at 01:43:27PM -0700, Paul E. McKenney wrote:
> On Mon, Sep 21, 2015 at 09:30:49PM +0200, Frederic Weisbecker wrote:
>
> > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > index d63bb77..6c3cece 100644
> > > --- a/include/linux/rcupdate.h
> > > +++ b/include/linux/rcupdate.h
> > > @@ -297,12 +297,14 @@ void synchronize_rcu(void);
> > >
> > > static inline void __rcu_read_lock(void)
> > > {
> > > - preempt_disable();
> > > + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> > > + preempt_disable();
> >
> > preempt_disable() is a no-op when !CONFIG_PREEMPT_COUNT, right?
> > Or rather it's a barrier(), which is anyway implied by rcu_read_lock().
> >
> > So perhaps we can get rid of the IS_ENABLED() check?
>
> Actually, barrier() is not intended to be implied by rcu_read_lock().
> In a non-preemptible RCU implementation, it doesn't help anything
> to have the compiler flush its temporaries upon rcu_read_lock()
> and rcu_read_unlock().
This is seriously broken. RCU has been around for years and is
used throughout the kernel while the compiler barrier existed.
You can't then go and decide to remove the compiler barrier! To do
that you'd need to audit every single use of rcu_read_lock in the
kernel to ensure that they're not depending on the compiler barrier.
This is also contrary to the definition of almost every other
*_lock primitive in the kernel where the compiler barrier is
included.
So please revert this patch.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-02 5:56 ` rcu_read_lock lost its compiler barrier Herbert Xu
@ 2019-06-02 20:54 ` Linus Torvalds
2019-06-03 2:46 ` Herbert Xu
2019-06-03 0:06 ` Paul E. McKenney
1 sibling, 1 reply; 62+ messages in thread
From: Linus Torvalds @ 2019-06-02 20:54 UTC (permalink / raw)
To: Herbert Xu
Cc: Paul E. McKenney, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Sat, Jun 1, 2019 at 10:56 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> You can't then go and decide to remove the compiler barrier! To do
> that you'd need to audit every single use of rcu_read_lock in the
> kernel to ensure that they're not depending on the compiler barrier.
What's the possible case where it would matter when there is no preemption?
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-02 20:54 ` Linus Torvalds
@ 2019-06-03 2:46 ` Herbert Xu
2019-06-03 3:47 ` Paul E. McKenney
2019-06-06 8:38 ` Andrea Parri
0 siblings, 2 replies; 62+ messages in thread
From: Herbert Xu @ 2019-06-03 2:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paul E. McKenney, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Sun, Jun 02, 2019 at 01:54:12PM -0700, Linus Torvalds wrote:
> On Sat, Jun 1, 2019 at 10:56 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> > You can't then go and decide to remove the compiler barrier! To do
> > that you'd need to audit every single use of rcu_read_lock in the
> > kernel to ensure that they're not depending on the compiler barrier.
>
> What's the possible case where it would matter when there is no preemption?
The case we were discussing is from net/ipv4/inet_fragment.c from
the net-next tree:
void fqdir_exit(struct fqdir *fqdir)
{
...
fqdir->dead = true;
/* call_rcu is supposed to provide memory barrier semantics,
* separating the setting of fqdir->dead with the destruction
* work. This implicit barrier is paired with inet_frag_kill().
*/
INIT_RCU_WORK(&fqdir->destroy_rwork, fqdir_rwork_fn);
queue_rcu_work(system_wq, &fqdir->destroy_rwork);
}
and
void inet_frag_kill(struct inet_frag_queue *fq)
{
...
rcu_read_lock();
/* The RCU read lock provides a memory barrier
* guaranteeing that if fqdir->dead is false then
* the hash table destruction will not start until
* after we unlock. Paired with inet_frags_exit_net().
*/
if (!fqdir->dead) {
rhashtable_remove_fast(&fqdir->rhashtable, &fq->node,
fqdir->f->rhash_params);
...
}
...
rcu_read_unlock();
...
}
I simplified this to
Initial values:
a = 0
b = 0
CPU1 CPU2
---- ----
a = 1 rcu_read_lock
synchronize_rcu if (a == 0)
b = 2 b = 1
rcu_read_unlock
On exit we want this to be true:
b == 2
Now what Paul was telling me is that unless every memory operation
is done with READ_ONCE/WRITE_ONCE then his memory model shows that
the exit constraint won't hold. IOW, we need
CPU1 CPU2
---- ----
WRITE_ONCE(a, 1) rcu_read_lock
synchronize_rcu if (READ_ONCE(a) == 0)
WRITE_ONCE(b, 2) WRITE_ONCE(b, 1)
rcu_read_unlock
Now I think this bullshit because if we really needed these compiler
barriers then we surely would need real memory barriers to go with
them.
In fact, the sole purpose of the RCU mechanism is to provide those
memory barriers. Quoting from
Documentation/RCU/Design/Requirements/Requirements.html:
<li> Each CPU that has an RCU read-side critical section that
begins before <tt>synchronize_rcu()</tt> starts is
guaranteed to execute a full memory barrier between the time
that the RCU read-side critical section ends and the time that
<tt>synchronize_rcu()</tt> returns.
Without this guarantee, a pre-existing RCU read-side critical section
might hold a reference to the newly removed <tt>struct foo</tt>
after the <tt>kfree()</tt> on line 14 of
<tt>remove_gp_synchronous()</tt>.
<li> Each CPU that has an RCU read-side critical section that ends
after <tt>synchronize_rcu()</tt> returns is guaranteed
to execute a full memory barrier between the time that
<tt>synchronize_rcu()</tt> begins and the time that the RCU
read-side critical section begins.
Without this guarantee, a later RCU read-side critical section
running after the <tt>kfree()</tt> on line 14 of
<tt>remove_gp_synchronous()</tt> might
later run <tt>do_something_gp()</tt> and find the
newly deleted <tt>struct foo</tt>.
My review of the RCU code shows that these memory barriers are
indeed present (at least when we're not in tiny mode where all
this discussion would be moot anyway). For example, in call_rcu
we eventually get down to rcu_segcblist_enqueue which has an smp_mb.
On the reader side (correct me if I'm wrong Paul) the memory
barrier is implicitly coming from the scheduler.
My point is that within our kernel whenever we have a CPU memory
barrier we always have a compiler barrier too. Therefore my code
example above does not need any extra compiler barriers such as
the ones provided by READ_ONCE/WRITE_ONCE.
I think perhaps Paul was perhaps thinking that I'm expecting
rcu_read_lock/rcu_read_unlock themselves to provide the memory
or compiler barriers. That would indeed be wrong but this is
not what I need. All I need is the RCU semantics as documented
for there to be memory and compiler barriers around the whole
grace period.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 2:46 ` Herbert Xu
@ 2019-06-03 3:47 ` Paul E. McKenney
2019-06-03 4:01 ` Herbert Xu
2019-06-03 5:26 ` Herbert Xu
2019-06-06 8:38 ` Andrea Parri
1 sibling, 2 replies; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-03 3:47 UTC (permalink / raw)
To: Herbert Xu
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Mon, Jun 03, 2019 at 10:46:40AM +0800, Herbert Xu wrote:
> On Sun, Jun 02, 2019 at 01:54:12PM -0700, Linus Torvalds wrote:
> > On Sat, Jun 1, 2019 at 10:56 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > >
> > > You can't then go and decide to remove the compiler barrier! To do
> > > that you'd need to audit every single use of rcu_read_lock in the
> > > kernel to ensure that they're not depending on the compiler barrier.
> >
> > What's the possible case where it would matter when there is no preemption?
>
> The case we were discussing is from net/ipv4/inet_fragment.c from
> the net-next tree:
>
> void fqdir_exit(struct fqdir *fqdir)
> {
> ...
> fqdir->dead = true;
>
> /* call_rcu is supposed to provide memory barrier semantics,
> * separating the setting of fqdir->dead with the destruction
> * work. This implicit barrier is paired with inet_frag_kill().
> */
>
> INIT_RCU_WORK(&fqdir->destroy_rwork, fqdir_rwork_fn);
> queue_rcu_work(system_wq, &fqdir->destroy_rwork);
> }
>
> and
>
> void inet_frag_kill(struct inet_frag_queue *fq)
> {
> ...
> rcu_read_lock();
> /* The RCU read lock provides a memory barrier
> * guaranteeing that if fqdir->dead is false then
> * the hash table destruction will not start until
> * after we unlock. Paired with inet_frags_exit_net().
> */
> if (!fqdir->dead) {
> rhashtable_remove_fast(&fqdir->rhashtable, &fq->node,
> fqdir->f->rhash_params);
> ...
> }
> ...
> rcu_read_unlock();
> ...
> }
>
> I simplified this to
>
> Initial values:
>
> a = 0
> b = 0
>
> CPU1 CPU2
> ---- ----
> a = 1 rcu_read_lock
> synchronize_rcu if (a == 0)
> b = 2 b = 1
> rcu_read_unlock
>
> On exit we want this to be true:
> b == 2
>
> Now what Paul was telling me is that unless every memory operation
> is done with READ_ONCE/WRITE_ONCE then his memory model shows that
> the exit constraint won't hold.
But please note that the plain-variable portion of the memory model is
very new and likely still has a bug or two. In fact, see below.
> IOW, we need
>
> CPU1 CPU2
> ---- ----
> WRITE_ONCE(a, 1) rcu_read_lock
> synchronize_rcu if (READ_ONCE(a) == 0)
> WRITE_ONCE(b, 2) WRITE_ONCE(b, 1)
> rcu_read_unlock
>
> Now I think this bullshit because if we really needed these compiler
> barriers then we surely would need real memory barriers to go with
> them.
On the one hand, you have no code before your rcu_read_lock() and also
1no code after your rcu_read_unlock(). So in this particular example,
adding compiler barriers to these guys won't help you.
On the other hand, on CPU 1's write to "b", I agree with you and disagree
with the model, though perhaps my partners in LKMM crime will show me the
error of my ways on this point. On CPU 2's write to "b", I can see the
memory model's point, but getting there requires some gymnastics on the
part of both the compiler and the CPU. The WRITE_ONCE() and READ_ONCE()
for "a" is the normal requirement for variables that are concurrently
loaded and stored.
Please note that garden-variety uses of RCU have similar requirements,
namely the rcu_assign_pointer() on the one side and the rcu_dereference()
on the other. Your use case allows rcu_assign_pointer() to be weakened
to WRITE_ONCE() and rcu_dereference() to be weakened to READ_ONCE()
(not that this last is all that much of a weakening these days).
> In fact, the sole purpose of the RCU mechanism is to provide those
> memory barriers. Quoting from
> Documentation/RCU/Design/Requirements/Requirements.html:
>
> <li> Each CPU that has an RCU read-side critical section that
> begins before <tt>synchronize_rcu()</tt> starts is
> guaranteed to execute a full memory barrier between the time
> that the RCU read-side critical section ends and the time that
> <tt>synchronize_rcu()</tt> returns.
> Without this guarantee, a pre-existing RCU read-side critical section
> might hold a reference to the newly removed <tt>struct foo</tt>
> after the <tt>kfree()</tt> on line 14 of
> <tt>remove_gp_synchronous()</tt>.
> <li> Each CPU that has an RCU read-side critical section that ends
> after <tt>synchronize_rcu()</tt> returns is guaranteed
> to execute a full memory barrier between the time that
> <tt>synchronize_rcu()</tt> begins and the time that the RCU
> read-side critical section begins.
> Without this guarantee, a later RCU read-side critical section
> running after the <tt>kfree()</tt> on line 14 of
> <tt>remove_gp_synchronous()</tt> might
> later run <tt>do_something_gp()</tt> and find the
> newly deleted <tt>struct foo</tt>.
Ahem.
1. These guarantees are of full memory barriers, -not- compiler
barriers.
2. These rules don't say exactly where these full memory barriers
go. SRCU is at one extreme, placing those full barriers in
srcu_read_lock() and srcu_read_unlock(), and !PREEMPT Tree RCU
at the other, placing these barriers entirely within the callback
queueing/invocation, grace-period computation, and the scheduler.
Preemptible Tree RCU is in the middle, with rcu_read_unlock()
sometimes including a full memory barrier, but other times with
the full memory barrier being confined as it is with !PREEMPT
Tree RCU.
So let's place those memory barriers in your example, interleaving:
CPU2: rcu_read_lock();
CPU1: WRITE_ONCE(a, 1) | CPU2: if (READ_ONCE(a) == 0)
CPU2: WRITE_ONCE(b, 1)
CPU2: rcu_read_unlock
/* Could put a full memory barrier here, but it wouldn't help. */
CPU1: synchronize_rcu
CPU1: b = 2;
Here the accesses to "a" are concurrent, and there are legal placements
for the required full memory barrier that don't change that. In fact,
I cannot see how any memory-barrier placement can help here. So the
WRITE_ONCE() and READ_ONCE() should be used for "a". And again, in
garden-variety RCU use cases, these would be rcu_assign_pointer() and
rcu_dereference(), respectively. So again, I advise using READ_ONCE()
and WRITE_ONCE() for the accesses to "a", for documentation purposes,
even ignoring the future proofing.
Now let's do the (admittedly quite crazy, at least here in 2019)
profiling-directed transformation of the "b = 1" on a weakly ordered
system:
CPU1: WRITE_ONCE(a, 1)
CPU1: synchronize_rcu
CPU1: b = 2;
CPU2: rcu_read_lock();
CPU2: if (READ_ONCE(a) == 0)
CPU2: if (b != 1)
CPU2: b = 1;
CPU2: rcu_read_unlock
Interleaving and inserting full memory barriers as per the rules above:
CPU1: WRITE_ONCE(a, 1)
CPU1: synchronize_rcu
/* Could put a full memory barrier here, but it wouldn't help. */
CPU2: rcu_read_lock();
CPU1: b = 2;
CPU2: if (READ_ONCE(a) == 0)
CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
CPU2: b = 1;
CPU2: rcu_read_unlock
In fact, CPU2's load from b might be moved up to race with CPU1's store,
which (I believe) is why the model complains in this case.
I still cannot imagine why CPU1's "b = 2" needs to be WRITE_ONCE(),
perhaps due to a failure of imagination on my part.
> My review of the RCU code shows that these memory barriers are
> indeed present (at least when we're not in tiny mode where all
> this discussion would be moot anyway). For example, in call_rcu
> we eventually get down to rcu_segcblist_enqueue which has an smp_mb.
> On the reader side (correct me if I'm wrong Paul) the memory
> barrier is implicitly coming from the scheduler.
>
> My point is that within our kernel whenever we have a CPU memory
> barrier we always have a compiler barrier too. Therefore my code
> example above does not need any extra compiler barriers such as
> the ones provided by READ_ONCE/WRITE_ONCE.
For the garden-variety RCU use cases, this is true. Instead, they
require things that are as strong or stronger than READ_ONCE/WRITE_ONCE.
For example:
CPU 0:
p = kzalloc(sizeof(*p), GFP_KERNEL);
BUG_ON(!p);
p->a = 42;
r1 = p->b;
rcu_assign_pointer(gp, p);
CPU 1:
rcu_read_lock()
q = rcu_dereference(gp);
r2 = p->a;
p->b = 202;
rcu_read_unlock()
In this case, the plain C-language loads and stores cannot possibly
execute concurrently, and the model agrees with this. Again, we didn't
use WRITE_ONCE() and READ_ONCE() -- we instead used rcu_assign_pointer()
and rcu_dereference().
Similar examples involving (say) list_del_rcu() and synchronize_rcu()
are also safe for plain C-language loads and stores. Plain C-language
accesses by readers to the item being deleted cannot race with plain
C-language accesses after the synchronize_rcu() returns. But here we
are using list_del_rcu() in the update-side code along with the
synchronize_rcu() and the readers are again using rcu_dereference().
> I think perhaps Paul was perhaps thinking that I'm expecting
> rcu_read_lock/rcu_read_unlock themselves to provide the memory
> or compiler barriers. That would indeed be wrong but this is
> not what I need. All I need is the RCU semantics as documented
> for there to be memory and compiler barriers around the whole
> grace period.
Whew!!! That was -exactly- what I was thinking, and I am glad that
you are not advocating rcu_read_lock() and rcu_read_unlock() supplying
those barriers. ;-)
And again, it is early days for plain accesses for the Linux-kernel
memory model. I am confident that READ_ONCE() and WRITE_ONCE for
"a" is a very good thing to do, but less confident for "b", most
especially for CPU1's store to "b".
Either way, your example is an excellent test case for the plain
C-language access capability of the Linux-kernel memory model, so thank
you for that!
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 3:47 ` Paul E. McKenney
@ 2019-06-03 4:01 ` Herbert Xu
2019-06-03 4:17 ` Herbert Xu
2019-06-03 7:23 ` Paul E. McKenney
2019-06-03 5:26 ` Herbert Xu
1 sibling, 2 replies; 62+ messages in thread
From: Herbert Xu @ 2019-06-03 4:01 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
>
> CPU2: if (b != 1)
> CPU2: b = 1;
Stop right there. The kernel is full of code that assumes that
assignment to an int/long is atomic. If your compiler breaks this
assumption that we can kiss the kernel good-bye.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-03 4:01 ` Herbert Xu
@ 2019-06-03 4:17 ` Herbert Xu
2019-06-03 7:23 ` Paul E. McKenney
1 sibling, 0 replies; 62+ messages in thread
From: Herbert Xu @ 2019-06-03 4:17 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Mon, Jun 03, 2019 at 12:01:14PM +0800, Herbert Xu wrote:
> On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
> >
> > CPU2: if (b != 1)
> > CPU2: b = 1;
>
> Stop right there. The kernel is full of code that assumes that
> assignment to an int/long is atomic. If your compiler breaks this
> assumption that we can kiss the kernel good-bye.
The slippery slope apparently started here:
: commit ea435467500612636f8f4fb639ff6e76b2496e4b
: Author: Matthew Wilcox <matthew@wil.cx>
: Date: Tue Jan 6 14:40:39 2009 -0800
:
: atomic_t: unify all arch definitions
:
: diff --git a/arch/x86/include/asm/atomic_32.h b/arch/x86/include/asm/atomic_32.h
: index ad5b9f6ecddf..85b46fba4229 100644
: --- a/arch/x86/include/asm/atomic_32.h
: +++ b/arch/x86/include/asm/atomic_32.h
: ...
: @@ -10,15 +11,6 @@
: * resource counting etc..
: */
:
: -/*
: - * Make sure gcc doesn't try to be clever and move things around
: - * on us. We need to use _exactly_ the address the user gave us,
: - * not some alias that contains the same information.
: - */
: -typedef struct {
: - int counter;
: -} atomic_t;
:
: diff --git a/include/linux/types.h b/include/linux/types.h
: index 121f349cb7ec..3b864f2d9560 100644
: --- a/include/linux/types.h
: +++ b/include/linux/types.h
: @@ -195,6 +195,16 @@ typedef u32 phys_addr_t;
:
: typedef phys_addr_t resource_size_t;
:
: +typedef struct {
: + volatile int counter;
: +} atomic_t;
: +
Before evolving into the READ_ONCE/WRITE_ONCE that we have now.
Linus, are we now really supporting a compiler where an assignment
(or a read) from an int/long/pointer can be non-atomic without the
volatile marker? Because if that's the case then we have a lot of
code to audit.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 4:01 ` Herbert Xu
2019-06-03 4:17 ` Herbert Xu
@ 2019-06-03 7:23 ` Paul E. McKenney
2019-06-03 8:42 ` Paul E. McKenney
1 sibling, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-03 7:23 UTC (permalink / raw)
To: Herbert Xu
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Mon, Jun 03, 2019 at 12:01:14PM +0800, Herbert Xu wrote:
> On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
> >
> > CPU2: if (b != 1)
> > CPU2: b = 1;
>
> Stop right there. The kernel is full of code that assumes that
> assignment to an int/long is atomic. If your compiler breaks this
> assumption that we can kiss the kernel good-bye.
Here you go:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
TL;DR: On x86, of you are doing a plain store of a 32-bit constant
that has bits set only in the lower few bits of each 16-bit half of
that constant, the compiler is plenty happy to use a pair of 16-bit
store-immediate instructions to carry out that store. This is also
known as "store tearing".
The two bugs were filed (and after some back and forth, fixed) because
someone forgot to exclude C11 atomics and volatile accesses from this
store tearing.
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-03 7:23 ` Paul E. McKenney
@ 2019-06-03 8:42 ` Paul E. McKenney
2019-06-03 15:26 ` David Laight
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-03 8:42 UTC (permalink / raw)
To: Herbert Xu
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Mon, Jun 03, 2019 at 12:23:39AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 03, 2019 at 12:01:14PM +0800, Herbert Xu wrote:
> > On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
> > >
> > > CPU2: if (b != 1)
> > > CPU2: b = 1;
> >
> > Stop right there. The kernel is full of code that assumes that
> > assignment to an int/long is atomic. If your compiler breaks this
> > assumption that we can kiss the kernel good-bye.
>
> Here you go:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
>
> TL;DR: On x86, of you are doing a plain store of a 32-bit constant
> that has bits set only in the lower few bits of each 16-bit half of
> that constant, the compiler is plenty happy to use a pair of 16-bit
> store-immediate instructions to carry out that store. This is also
> known as "store tearing".
>
> The two bugs were filed (and after some back and forth, fixed) because
> someone forgot to exclude C11 atomics and volatile accesses from this
> store tearing.
I should hasten to add that I have not seen load tearing, nor have I seen
store tearing when storing a value unknown to the compiler. However,
plain C-language loads and stores can be invented, fused, and a few other
"interesting" optimization can be applied.
On kissing the kernel goodbye, a reasonable strategy might be to
identify the transformations that are actually occuring (like the
stores of certain constants called out above) and fix those. We do
occasionally use READ_ONCE() to prevent load-fusing optimizations that
would otherwise cause the compiler to turn while-loops into if-statements
guarding infinite loops. There is also the possibility of having the
compiler guys give us more command-line arguments.
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread
* RE: rcu_read_lock lost its compiler barrier
2019-06-03 8:42 ` Paul E. McKenney
@ 2019-06-03 15:26 ` David Laight
2019-06-03 15:40 ` Linus Torvalds
0 siblings, 1 reply; 62+ messages in thread
From: David Laight @ 2019-06-03 15:26 UTC (permalink / raw)
To: 'paulmck@linux.ibm.com', Herbert Xu
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
From: Paul E. McKenney
> Sent: 03 June 2019 09:42
...
> On kissing the kernel goodbye, a reasonable strategy might be to
> identify the transformations that are actually occuring (like the
> stores of certain constants called out above) and fix those.
> We do
> occasionally use READ_ONCE() to prevent load-fusing optimizations that
> would otherwise cause the compiler to turn while-loops into if-statements
> guarding infinite loops.
In that case the variable ought to be volatile...
> There is also the possibility of having the
> compiler guys give us more command-line arguments.
I wonder how much the code size (of anything) would increase
if the compiler:
1) Never read a value into a local more than once.
2) Never write a value that wasn't requested by the code.
3) Never used multiple memory accesses for 'machine word' (and
smaller) items.
(1) makes all reads READ_ONCE() except that the actual read
can be delayed until further down the code.
If I have a naive #define bswap32() I'd expect:
v = bswap32(foo->bar)
to possibly read foo->bar multiple times, but not:
int foo_bar = foo->bar;
v = bswap32(foo_bar);
(2) makes all writes WRITE_ONCE() except that if there are
multiple writes to the same location, only the last need
be done.
In particular it stops speculative writes and the use of
locations that are going to be written to as temporaries.
It also stop foo->bar = ~0; being implemented as a clear
then decrement.
(3) I'd never imagined the compiler would write the two halves
of a word separately!
If the compiler behaved like that (as one might expect it would)
then READ_ONCE() would be a READ_NOW() for when the sequencing
mattered.
I was also recently surprised by the code I got from this loop:
for (i = 0; i < limit; i++)
sum64 += array32[i];
(as in the IP checksum sum without add carry support).
The compiler unrolled it to used horrid sequences of sse3/avx
instructions.
This might be a gain for large enough buffers and 'hot cache'
but for small buffer and likely cold cache it is horrid.
I guess such optimisations are valid, but I wonder how often
they are an actual win for real programs.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 15:26 ` David Laight
@ 2019-06-03 15:40 ` Linus Torvalds
0 siblings, 0 replies; 62+ messages in thread
From: Linus Torvalds @ 2019-06-03 15:40 UTC (permalink / raw)
To: David Laight
Cc: paulmck, Herbert Xu, Frederic Weisbecker, Boqun Feng,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller
On Mon, Jun 3, 2019 at 8:26 AM David Laight <David.Laight@aculab.com> wrote:
>
> From: Paul E. McKenney
>
> > We do
> > occasionally use READ_ONCE() to prevent load-fusing optimizations that
> > would otherwise cause the compiler to turn while-loops into if-statements
> > guarding infinite loops.
>
> In that case the variable ought to be volatile...
No.
We do not use volatile on variables.
The C people got the semantics wrong, probably because 'volatile' was
historically for IO, not for access atomicity without locking.
It's not the memory location that is volatile, it is really the
_access_ that is volatile.
The same memory location might be completely stable in other access
situations (ie when done under a lock).
In other words, we should *never* use volatile in the kernel. It's
fundamentally mis-designed for modern use.
(Of course, we then can use volatile in a cast in code, which drives
some compiler people crazy, but that's because said compiler people
don't care about reality, they care about some paperwork).
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-03 3:47 ` Paul E. McKenney
2019-06-03 4:01 ` Herbert Xu
@ 2019-06-03 5:26 ` Herbert Xu
2019-06-03 6:42 ` Boqun Feng
2019-06-03 9:35 ` Paul E. McKenney
1 sibling, 2 replies; 62+ messages in thread
From: Herbert Xu @ 2019-06-03 5:26 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
>
> 1. These guarantees are of full memory barriers, -not- compiler
> barriers.
What I'm saying is that wherever they are, they must come with
compiler barriers. I'm not aware of any synchronisation mechanism
in the kernel that gives a memory barrier without a compiler barrier.
> 2. These rules don't say exactly where these full memory barriers
> go. SRCU is at one extreme, placing those full barriers in
> srcu_read_lock() and srcu_read_unlock(), and !PREEMPT Tree RCU
> at the other, placing these barriers entirely within the callback
> queueing/invocation, grace-period computation, and the scheduler.
> Preemptible Tree RCU is in the middle, with rcu_read_unlock()
> sometimes including a full memory barrier, but other times with
> the full memory barrier being confined as it is with !PREEMPT
> Tree RCU.
The rules do say that the (full) memory barrier must precede any
RCU read-side that occur after the synchronize_rcu and after the
end of any RCU read-side that occur before the synchronize_rcu.
All I'm arguing is that wherever that full mb is, as long as it
also carries with it a barrier() (which it must do if it's done
using an existing kernel mb/locking primitive), then we're fine.
> Interleaving and inserting full memory barriers as per the rules above:
>
> CPU1: WRITE_ONCE(a, 1)
> CPU1: synchronize_rcu
> /* Could put a full memory barrier here, but it wouldn't help. */
CPU1: smp_mb();
CPU2: smp_mb();
Let's put them in because I think they are critical. smp_mb() also
carries with it a barrier().
> CPU2: rcu_read_lock();
> CPU1: b = 2;
> CPU2: if (READ_ONCE(a) == 0)
> CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
> CPU2: b = 1;
> CPU2: rcu_read_unlock
>
> In fact, CPU2's load from b might be moved up to race with CPU1's store,
> which (I believe) is why the model complains in this case.
Let's put aside my doubt over how we're even allowing a compiler
to turn
b = 1
into
if (b != 1)
b = 1
Since you seem to be assuming that (a == 0) is true in this case
(as the assignment b = 1 is carried out), then because of the
presence of the full memory barrier, the RCU read-side section
must have started prior to the synchronize_rcu. This means that
synchronize_rcu is not allowed to return until at least the end
of the grace period, or at least until the end of rcu_read_unlock.
So it actually should be:
CPU1: WRITE_ONCE(a, 1)
CPU1: synchronize_rcu called
/* Could put a full memory barrier here, but it wouldn't help. */
CPU1: smp_mb();
CPU2: smp_mb();
CPU2: grace period starts
...time passes...
CPU2: rcu_read_lock();
CPU2: if (READ_ONCE(a) == 0)
CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
CPU2: b = 1;
CPU2: rcu_read_unlock
...time passes...
CPU2: grace period ends
/* This full memory barrier is also guaranteed by RCU. */
CPU2: smp_mb();
CPU1 synchronize_rcu returns
CPU1: b = 2;
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-03 5:26 ` Herbert Xu
@ 2019-06-03 6:42 ` Boqun Feng
2019-06-03 20:03 ` Paul E. McKenney
2019-06-03 9:35 ` Paul E. McKenney
1 sibling, 1 reply; 62+ messages in thread
From: Boqun Feng @ 2019-06-03 6:42 UTC (permalink / raw)
To: Herbert Xu
Cc: Paul E. McKenney, Linus Torvalds, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 4707 bytes --]
On Mon, Jun 03, 2019 at 01:26:26PM +0800, Herbert Xu wrote:
> On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
> >
> > 1. These guarantees are of full memory barriers, -not- compiler
> > barriers.
>
> What I'm saying is that wherever they are, they must come with
> compiler barriers. I'm not aware of any synchronisation mechanism
> in the kernel that gives a memory barrier without a compiler barrier.
>
> > 2. These rules don't say exactly where these full memory barriers
> > go. SRCU is at one extreme, placing those full barriers in
> > srcu_read_lock() and srcu_read_unlock(), and !PREEMPT Tree RCU
> > at the other, placing these barriers entirely within the callback
> > queueing/invocation, grace-period computation, and the scheduler.
> > Preemptible Tree RCU is in the middle, with rcu_read_unlock()
> > sometimes including a full memory barrier, but other times with
> > the full memory barrier being confined as it is with !PREEMPT
> > Tree RCU.
>
> The rules do say that the (full) memory barrier must precede any
> RCU read-side that occur after the synchronize_rcu and after the
> end of any RCU read-side that occur before the synchronize_rcu.
>
> All I'm arguing is that wherever that full mb is, as long as it
> also carries with it a barrier() (which it must do if it's done
> using an existing kernel mb/locking primitive), then we're fine.
>
> > Interleaving and inserting full memory barriers as per the rules above:
> >
> > CPU1: WRITE_ONCE(a, 1)
> > CPU1: synchronize_rcu
> > /* Could put a full memory barrier here, but it wouldn't help. */
>
> CPU1: smp_mb();
> CPU2: smp_mb();
>
> Let's put them in because I think they are critical. smp_mb() also
> carries with it a barrier().
>
> > CPU2: rcu_read_lock();
> > CPU1: b = 2;
> > CPU2: if (READ_ONCE(a) == 0)
> > CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
> > CPU2: b = 1;
> > CPU2: rcu_read_unlock
> >
> > In fact, CPU2's load from b might be moved up to race with CPU1's store,
> > which (I believe) is why the model complains in this case.
>
> Let's put aside my doubt over how we're even allowing a compiler
> to turn
>
> b = 1
>
> into
>
> if (b != 1)
> b = 1
>
> Since you seem to be assuming that (a == 0) is true in this case
I think Paul's example assuming (a == 0) is false, and maybe
speculative writes (by compilers) needs to added into consideration?
Please consider the following case (I add a few smp_mb()s), the case may
be a little bit crasy, you have been warned ;-)
CPU1: WRITE_ONCE(a, 1)
CPU1: synchronize_rcu called
CPU1: smp_mb(); /* let assume there is one here */
CPU2: rcu_read_lock();
CPU2: smp_mb(); /* let assume there is one here */
/* "if (b != 1) b = 1" reordered */
CPU2: r0 = b; /* if (b != 1) reordered here, r0 == 0 */
CPU2: if (r0 != 1) /* true */
CPU2: b = 1; /* b == 1 now, this is a speculative write
by compiler
*/
CPU1: b = 2; /* b == 2 */
CPU2: if (READ_ONCE(a) == 0) /* false */
CPU2: ...
CPU2 else /* undo the speculative write */
CPU2: b = r0; /* b == 0 */
CPU2: smp_mb();
CPU2: read_read_unlock();
I know this is too crasy for us to think a compiler like this, but this
might be the reason why the model complain about this.
Paul, did I get this right? Or you mean something else?
Regards,
Boqun
> (as the assignment b = 1 is carried out), then because of the
> presence of the full memory barrier, the RCU read-side section
> must have started prior to the synchronize_rcu. This means that
> synchronize_rcu is not allowed to return until at least the end
> of the grace period, or at least until the end of rcu_read_unlock.
>
> So it actually should be:
>
> CPU1: WRITE_ONCE(a, 1)
> CPU1: synchronize_rcu called
> /* Could put a full memory barrier here, but it wouldn't help. */
>
> CPU1: smp_mb();
> CPU2: smp_mb();
>
> CPU2: grace period starts
> ...time passes...
> CPU2: rcu_read_lock();
> CPU2: if (READ_ONCE(a) == 0)
> CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
> CPU2: b = 1;
> CPU2: rcu_read_unlock
> ...time passes...
> CPU2: grace period ends
>
> /* This full memory barrier is also guaranteed by RCU. */
> CPU2: smp_mb();
>
> CPU1 synchronize_rcu returns
> CPU1: b = 2;
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-03 6:42 ` Boqun Feng
@ 2019-06-03 20:03 ` Paul E. McKenney
2019-06-04 14:44 ` Alan Stern
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-03 20:03 UTC (permalink / raw)
To: Boqun Feng
Cc: Herbert Xu, Linus Torvalds, Frederic Weisbecker, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller, stern
On Mon, Jun 03, 2019 at 02:42:00PM +0800, Boqun Feng wrote:
> On Mon, Jun 03, 2019 at 01:26:26PM +0800, Herbert Xu wrote:
> > On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
> > >
> > > 1. These guarantees are of full memory barriers, -not- compiler
> > > barriers.
> >
> > What I'm saying is that wherever they are, they must come with
> > compiler barriers. I'm not aware of any synchronisation mechanism
> > in the kernel that gives a memory barrier without a compiler barrier.
> >
> > > 2. These rules don't say exactly where these full memory barriers
> > > go. SRCU is at one extreme, placing those full barriers in
> > > srcu_read_lock() and srcu_read_unlock(), and !PREEMPT Tree RCU
> > > at the other, placing these barriers entirely within the callback
> > > queueing/invocation, grace-period computation, and the scheduler.
> > > Preemptible Tree RCU is in the middle, with rcu_read_unlock()
> > > sometimes including a full memory barrier, but other times with
> > > the full memory barrier being confined as it is with !PREEMPT
> > > Tree RCU.
> >
> > The rules do say that the (full) memory barrier must precede any
> > RCU read-side that occur after the synchronize_rcu and after the
> > end of any RCU read-side that occur before the synchronize_rcu.
> >
> > All I'm arguing is that wherever that full mb is, as long as it
> > also carries with it a barrier() (which it must do if it's done
> > using an existing kernel mb/locking primitive), then we're fine.
> >
> > > Interleaving and inserting full memory barriers as per the rules above:
> > >
> > > CPU1: WRITE_ONCE(a, 1)
> > > CPU1: synchronize_rcu
> > > /* Could put a full memory barrier here, but it wouldn't help. */
> >
> > CPU1: smp_mb();
> > CPU2: smp_mb();
> >
> > Let's put them in because I think they are critical. smp_mb() also
> > carries with it a barrier().
> >
> > > CPU2: rcu_read_lock();
> > > CPU1: b = 2;
> > > CPU2: if (READ_ONCE(a) == 0)
> > > CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
> > > CPU2: b = 1;
> > > CPU2: rcu_read_unlock
> > >
> > > In fact, CPU2's load from b might be moved up to race with CPU1's store,
> > > which (I believe) is why the model complains in this case.
> >
> > Let's put aside my doubt over how we're even allowing a compiler
> > to turn
> >
> > b = 1
> >
> > into
> >
> > if (b != 1)
> > b = 1
> >
> > Since you seem to be assuming that (a == 0) is true in this case
>
> I think Paul's example assuming (a == 0) is false, and maybe
Yes, otherwise, P0()'s write to "b" cannot have happened.
> speculative writes (by compilers) needs to added into consideration?
I would instead call it the compiler eliminating needless writes
by inventing reads -- if the variable already has the correct value,
no write happens. So no compiler speculation.
However, it is difficult to create a solid defensible example. Yes,
from LKMM's viewpoint, the weakly reordered invented read from "b"
can be concurrent with P0()'s write to "b", but in that case the value
loaded would have to manage to be equal to 1 for anything bad to happen.
This does feel wrong to me, but again, it is difficult to create a solid
defensible example.
> Please consider the following case (I add a few smp_mb()s), the case may
> be a little bit crasy, you have been warned ;-)
>
> CPU1: WRITE_ONCE(a, 1)
> CPU1: synchronize_rcu called
>
> CPU1: smp_mb(); /* let assume there is one here */
>
> CPU2: rcu_read_lock();
> CPU2: smp_mb(); /* let assume there is one here */
>
> /* "if (b != 1) b = 1" reordered */
> CPU2: r0 = b; /* if (b != 1) reordered here, r0 == 0 */
> CPU2: if (r0 != 1) /* true */
> CPU2: b = 1; /* b == 1 now, this is a speculative write
> by compiler
> */
>
> CPU1: b = 2; /* b == 2 */
>
> CPU2: if (READ_ONCE(a) == 0) /* false */
> CPU2: ...
> CPU2 else /* undo the speculative write */
> CPU2: b = r0; /* b == 0 */
>
> CPU2: smp_mb();
> CPU2: read_read_unlock();
>
> I know this is too crasy for us to think a compiler like this, but this
> might be the reason why the model complain about this.
>
> Paul, did I get this right? Or you mean something else?
Mostly there, except that I am not yet desperate enough to appeal to
compilers speculating stores. ;-)
Thanx, Paul
> Regards,
> Boqun
>
>
>
> > (as the assignment b = 1 is carried out), then because of the
> > presence of the full memory barrier, the RCU read-side section
> > must have started prior to the synchronize_rcu. This means that
> > synchronize_rcu is not allowed to return until at least the end
> > of the grace period, or at least until the end of rcu_read_unlock.
> >
> > So it actually should be:
> >
> > CPU1: WRITE_ONCE(a, 1)
> > CPU1: synchronize_rcu called
> > /* Could put a full memory barrier here, but it wouldn't help. */
> >
> > CPU1: smp_mb();
> > CPU2: smp_mb();
> >
> > CPU2: grace period starts
> > ...time passes...
> > CPU2: rcu_read_lock();
> > CPU2: if (READ_ONCE(a) == 0)
> > CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
> > CPU2: b = 1;
> > CPU2: rcu_read_unlock
> > ...time passes...
> > CPU2: grace period ends
> >
> > /* This full memory barrier is also guaranteed by RCU. */
> > CPU2: smp_mb();
> >
> > CPU1 synchronize_rcu returns
> > CPU1: b = 2;
> >
> > Cheers,
> > --
> > Email: Herbert Xu <herbert@gondor.apana.org.au>
> > Home Page: http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-03 20:03 ` Paul E. McKenney
@ 2019-06-04 14:44 ` Alan Stern
2019-06-04 16:04 ` Linus Torvalds
` (2 more replies)
0 siblings, 3 replies; 62+ messages in thread
From: Alan Stern @ 2019-06-04 14:44 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Boqun Feng, Herbert Xu, Linus Torvalds, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Mon, 3 Jun 2019, Paul E. McKenney wrote:
> On Mon, Jun 03, 2019 at 02:42:00PM +0800, Boqun Feng wrote:
> > On Mon, Jun 03, 2019 at 01:26:26PM +0800, Herbert Xu wrote:
> > > On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
> > > >
> > > > 1. These guarantees are of full memory barriers, -not- compiler
> > > > barriers.
> > >
> > > What I'm saying is that wherever they are, they must come with
> > > compiler barriers. I'm not aware of any synchronisation mechanism
> > > in the kernel that gives a memory barrier without a compiler barrier.
> > >
> > > > 2. These rules don't say exactly where these full memory barriers
> > > > go. SRCU is at one extreme, placing those full barriers in
> > > > srcu_read_lock() and srcu_read_unlock(), and !PREEMPT Tree RCU
> > > > at the other, placing these barriers entirely within the callback
> > > > queueing/invocation, grace-period computation, and the scheduler.
> > > > Preemptible Tree RCU is in the middle, with rcu_read_unlock()
> > > > sometimes including a full memory barrier, but other times with
> > > > the full memory barrier being confined as it is with !PREEMPT
> > > > Tree RCU.
> > >
> > > The rules do say that the (full) memory barrier must precede any
> > > RCU read-side that occur after the synchronize_rcu and after the
> > > end of any RCU read-side that occur before the synchronize_rcu.
> > >
> > > All I'm arguing is that wherever that full mb is, as long as it
> > > also carries with it a barrier() (which it must do if it's done
> > > using an existing kernel mb/locking primitive), then we're fine.
> > >
> > > > Interleaving and inserting full memory barriers as per the rules above:
> > > >
> > > > CPU1: WRITE_ONCE(a, 1)
> > > > CPU1: synchronize_rcu
> > > > /* Could put a full memory barrier here, but it wouldn't help. */
> > >
> > > CPU1: smp_mb();
> > > CPU2: smp_mb();
> > >
> > > Let's put them in because I think they are critical. smp_mb() also
> > > carries with it a barrier().
> > >
> > > > CPU2: rcu_read_lock();
> > > > CPU1: b = 2;
> > > > CPU2: if (READ_ONCE(a) == 0)
> > > > CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
> > > > CPU2: b = 1;
> > > > CPU2: rcu_read_unlock
> > > >
> > > > In fact, CPU2's load from b might be moved up to race with CPU1's store,
> > > > which (I believe) is why the model complains in this case.
> > >
> > > Let's put aside my doubt over how we're even allowing a compiler
> > > to turn
> > >
> > > b = 1
> > >
> > > into
> > >
> > > if (b != 1)
> > > b = 1
Even if you don't think the compiler will ever do this, the C standard
gives compilers the right to invent read accesses if a plain (i.e.,
non-atomic and non-volatile) write is present. The Linux Kernel Memory
Model has to assume that compilers will sometimes do this, even if it
doesn't take the exact form of checking a variable's value before
writing to it.
(Incidentally, regardless of whether the compiler will ever do this, I
have seen examples in the kernel where people did exactly this
manually, in order to avoid dirtying a cache line unnecessarily.)
> > > Since you seem to be assuming that (a == 0) is true in this case
> >
> > I think Paul's example assuming (a == 0) is false, and maybe
>
> Yes, otherwise, P0()'s write to "b" cannot have happened.
>
> > speculative writes (by compilers) needs to added into consideration?
On the other hand, the C standard does not allow compilers to add
speculative writes. The LKMM assumes they will never occur.
> I would instead call it the compiler eliminating needless writes
> by inventing reads -- if the variable already has the correct value,
> no write happens. So no compiler speculation.
>
> However, it is difficult to create a solid defensible example. Yes,
> from LKMM's viewpoint, the weakly reordered invented read from "b"
> can be concurrent with P0()'s write to "b", but in that case the value
> loaded would have to manage to be equal to 1 for anything bad to happen.
> This does feel wrong to me, but again, it is difficult to create a solid
> defensible example.
>
> > Please consider the following case (I add a few smp_mb()s), the case may
> > be a little bit crasy, you have been warned ;-)
> >
> > CPU1: WRITE_ONCE(a, 1)
> > CPU1: synchronize_rcu called
> >
> > CPU1: smp_mb(); /* let assume there is one here */
> >
> > CPU2: rcu_read_lock();
> > CPU2: smp_mb(); /* let assume there is one here */
> >
> > /* "if (b != 1) b = 1" reordered */
> > CPU2: r0 = b; /* if (b != 1) reordered here, r0 == 0 */
> > CPU2: if (r0 != 1) /* true */
> > CPU2: b = 1; /* b == 1 now, this is a speculative write
> > by compiler
> > */
> >
> > CPU1: b = 2; /* b == 2 */
> >
> > CPU2: if (READ_ONCE(a) == 0) /* false */
> > CPU2: ...
> > CPU2 else /* undo the speculative write */
> > CPU2: b = r0; /* b == 0 */
> >
> > CPU2: smp_mb();
> > CPU2: read_read_unlock();
> >
> > I know this is too crasy for us to think a compiler like this, but this
> > might be the reason why the model complain about this.
> >
> > Paul, did I get this right? Or you mean something else?
>
> Mostly there, except that I am not yet desperate enough to appeal to
> compilers speculating stores. ;-)
This example really does point out a weakness in the LKMM's handling of
data races. Herbert's litmus test is a great starting point:
C xu
{}
P0(int *a, int *b)
{
WRITE_ONCE(*a, 1);
synchronize_rcu();
*b = 2;
}
P1(int *a, int *b)
{
rcu_read_lock();
if (READ_ONCE(*a) == 0)
*b = 1;
rcu_read_unlock();
}
exists (~b=2)
Currently the LKMM says the test is allowed and there is a data race,
but this answer clearly is wrong since it would violate the RCU
guarantee.
The problem is that the LKMM currently requires all ordering/visibility
of plain accesses to be mediated by marked accesses. But in this case,
the visibility is mediated by RCU. Technically, we need to add a
relation like
([M] ; po ; rcu-fence ; po ; [M])
into the definitions of ww-vis, wr-vis, and rw-xbstar. Doing so
changes the litmus test's result to "not allowed" and no data race.
However, I'm not certain that this single change is the entire fix;
more thought is needed.
Alan
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-04 14:44 ` Alan Stern
@ 2019-06-04 16:04 ` Linus Torvalds
2019-06-04 17:00 ` Alan Stern
2019-06-07 14:09 ` inet: frags: Turn fqdir->dead into an int for old Alphas Herbert Xu
2019-06-06 4:51 ` rcu_read_lock lost its compiler barrier Herbert Xu
2019-06-06 8:16 ` Andrea Parri
2 siblings, 2 replies; 62+ messages in thread
From: Linus Torvalds @ 2019-06-04 16:04 UTC (permalink / raw)
To: Alan Stern
Cc: Paul E. McKenney, Boqun Feng, Herbert Xu, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Tue, Jun 4, 2019 at 7:44 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> Even if you don't think the compiler will ever do this, the C standard
> gives compilers the right to invent read accesses if a plain (i.e.,
> non-atomic and non-volatile) write is present.
Note that for the kernel, it's not like we go strictly by what the
standard says anyway.
The reason for the "read for write" thing is that obviously you
sometimes have broken architectures (*cough*alpha*cough*) that need to
do some common writes are read-maskmodify-write accesses, and for
bitfields you obviously *always* have that issue.
In general, a sane compiler (as opposed to "we just read the
standard") had better not add random reads, because people might have
some mappings be write-only when the hardware supports it.
And we do generally expect sanity from our compilers, and will add
compiler flags to disable bad behavior if required - even if said
behavior would be "technically allowed by the standard".
> (Incidentally, regardless of whether the compiler will ever do this, I
> have seen examples in the kernel where people did exactly this
> manually, in order to avoid dirtying a cache line unnecessarily.)
I really hope and expect that this is not something that the compiler ever does.
If a compiler turns "x = y" into if (x != y) x = y" (like we do
manually at times, as you say), that compiler is garbage that we
cannot use for the kernel. It would break things like "smp_wmb()"
ordering guarantees, I'm pretty sure.
And as always, if we're doing actively stupid things, and the compiler
then turns our stupid code into something we don't expect, the
corollary is that then it's on _us_. IOW, if we do
if (x != 1) {
...
}
x = 1;
and the compiler goes "oh, we already checked that 'x == 1'" and moves
that "unconditional" 'x = 1' into the conditional section like
if (x != 1) {
..
x = 1;
}
then that's not something we can then complain about.
So our expectation is that the compiler is _sane_, not that it's some
"C as assembler". Adding spurious reads is not ok. But if we already
had reads in the code and the compiler combines them with other ops,
that's on us.
End result: in general, we do expect that the compiler turns a regular
assignment into a single plain write when that's what the code does,
and does not add extra logic over and beyond that.
In fact, the alpha port was always subtly buggy exactly because of the
"byte write turns into a read-and-masked-write", even if I don't think
anybody ever noticed (we did fix cases where people _did_ notice,
though, and we might still have some cases where we use 'int' for
booleans because of alpha issues.).
So I don't technically disagree with anything you say, I just wanted
to point out that as far as the kernel is concerned, we do have higher
quality expectations from the compiler than just "technically valid
according to the C standard".
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-04 16:04 ` Linus Torvalds
@ 2019-06-04 17:00 ` Alan Stern
2019-06-04 17:29 ` Linus Torvalds
2019-06-07 14:09 ` inet: frags: Turn fqdir->dead into an int for old Alphas Herbert Xu
1 sibling, 1 reply; 62+ messages in thread
From: Alan Stern @ 2019-06-04 17:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paul E. McKenney, Boqun Feng, Herbert Xu, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Tue, 4 Jun 2019, Linus Torvalds wrote:
> So I don't technically disagree with anything you say,
That's good to know!
> I just wanted
> to point out that as far as the kernel is concerned, we do have higher
> quality expectations from the compiler than just "technically valid
> according to the C standard".
Which suggests asking whether these higher expectations should be
reflected in the Linux Kernel Memory Model. So far we have largely
avoided doing that sort of thing, although there are a few exceptions.
(For example, we assume the compiler does not destroy address
dependencies from volatile reads -- but we also warn that this
assumption may fail if the programmer does not follow some rules
described in one of Paul's documentation files.)
Alan
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-04 17:00 ` Alan Stern
@ 2019-06-04 17:29 ` Linus Torvalds
0 siblings, 0 replies; 62+ messages in thread
From: Linus Torvalds @ 2019-06-04 17:29 UTC (permalink / raw)
To: Alan Stern
Cc: Paul E. McKenney, Boqun Feng, Herbert Xu, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Tue, Jun 4, 2019 at 10:00 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> Which suggests asking whether these higher expectations should be
> reflected in the Linux Kernel Memory Model. So far we have largely
> avoided doing that sort of thing, although there are a few exceptions.
I think they might be hard to describe - which in turn may be why the
standard leaves it open and only describes the simple cases.
Exactly that "we expect an assignment to be done as a single write" is
probably a good example. Yes, we do have that expectation for the
simple cases. But it's not an absolute rule, obviously, because it's
clearly violated by bitfield writes, and similarly it's obviously
violated for data that is bigger than the word size (ie a "u64"
assignment is obviously not a single write when you're on a 32-bit
target).
And while those cases are static and could be described separately,
the "oh, and we have _other_ accesses to the same variable nearby, and
we expect that the compiler might take those into account unless we
explicitly use WRITE_ONCE()" things make for much more hard to
describe issues.
Doing writes with speculative values is clearly bogus and garbage
(although compiler writers _have_ tried to do that too: "we then
overwrite it with the right value later, so it's ok"), and thankfully
even user space people complain about that due to threading and
signals. But eliding writes entirely by combining them with a later
one is clearly ok - and eliding them when there was an explcit earlier
read and value comparison (like in my example) sounds reasonable to me
too. Yet silently adding the elision that wasn't visible in the source
due to other accesses would be bad.
How do you say "sane and reasonable compiler" in a spec? You usually
don't - or you make the rules so odd and complex than nobody really
understands them any more, and make it all moot ;)
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread
* inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-04 16:04 ` Linus Torvalds
2019-06-04 17:00 ` Alan Stern
@ 2019-06-07 14:09 ` Herbert Xu
2019-06-07 15:26 ` Eric Dumazet
1 sibling, 1 reply; 62+ messages in thread
From: Herbert Xu @ 2019-06-07 14:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alan Stern, Paul E. McKenney, Boqun Feng, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Tue, Jun 04, 2019 at 09:04:55AM -0700, Linus Torvalds wrote:
>
> In fact, the alpha port was always subtly buggy exactly because of the
> "byte write turns into a read-and-masked-write", even if I don't think
> anybody ever noticed (we did fix cases where people _did_ notice,
> though, and we might still have some cases where we use 'int' for
> booleans because of alpha issues.).
This is in fact a real bug in the code in question that no amount
of READ_ONCE/WRITE_ONCE would have caught. The field fqdir->dead is
declared as boolean so writing to it is not atomic (on old Alphas).
I don't think it currently matters because padding would ensure
that it is in fact 64 bits long. However, should someone add another
char/bool/bitfield in this struct in future it could become an issue.
So let's fix it.
---8<--
The field fqdir->dead is meant to be written (and read) atomically.
As old Alpha CPUs can't write a single byte atomically, we need at
least an int for it to work.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index e91b79ad4e4a..8c458fba74ad 100644
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -14,7 +14,9 @@ struct fqdir {
int max_dist;
struct inet_frags *f;
struct net *net;
- bool dead;
+
+ /* We can't use boolean because this needs atomic writes. */
+ int dead;
struct rhashtable rhashtable ____cacheline_aligned_in_smp;
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index 35e9784fab4e..05aa7c145817 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -193,7 +193,7 @@ void fqdir_exit(struct fqdir *fqdir)
{
fqdir->high_thresh = 0; /* prevent creation of new frags */
- fqdir->dead = true;
+ fqdir->dead = 1;
/* call_rcu is supposed to provide memory barrier semantics,
* separating the setting of fqdir->dead with the destruction
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-07 14:09 ` inet: frags: Turn fqdir->dead into an int for old Alphas Herbert Xu
@ 2019-06-07 15:26 ` Eric Dumazet
2019-06-07 15:32 ` Herbert Xu
2019-06-07 16:19 ` Linus Torvalds
0 siblings, 2 replies; 62+ messages in thread
From: Eric Dumazet @ 2019-06-07 15:26 UTC (permalink / raw)
To: Herbert Xu, Linus Torvalds
Cc: Alan Stern, Paul E. McKenney, Boqun Feng, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On 6/7/19 7:09 AM, Herbert Xu wrote:
> On Tue, Jun 04, 2019 at 09:04:55AM -0700, Linus Torvalds wrote:
>>
>> In fact, the alpha port was always subtly buggy exactly because of the
>> "byte write turns into a read-and-masked-write", even if I don't think
>> anybody ever noticed (we did fix cases where people _did_ notice,
>> though, and we might still have some cases where we use 'int' for
>> booleans because of alpha issues.).
>
> This is in fact a real bug in the code in question that no amount
> of READ_ONCE/WRITE_ONCE would have caught. The field fqdir->dead is
> declared as boolean so writing to it is not atomic (on old Alphas).
>
> I don't think it currently matters because padding would ensure
> that it is in fact 64 bits long. However, should someone add another
> char/bool/bitfield in this struct in future it could become an issue.
>
> So let's fix it.
There is common knowledge among us programmers that bit fields
(or bool) sharing a common 'word' need to be protected
with a common lock.
Converting all bit fields to plain int/long would be quite a waste of memory.
In this case, fqdir_exit() is called right before the whole
struct fqdir is dismantled, and the only cpu that could possibly
change the thing is ourself, and we are going to start an RCU grace period.
Note that first cache line in 'struct fqdir' is read-only.
Only ->dead field is flipped to one at exit time.
Your patch would send a strong signal to programmers to not even try using
bit fields.
Do we really want that ?
>
> ---8<--
> The field fqdir->dead is meant to be written (and read) atomically.
> As old Alpha CPUs can't write a single byte atomically, we need at
> least an int for it to work.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
> index e91b79ad4e4a..8c458fba74ad 100644
> --- a/include/net/inet_frag.h
> +++ b/include/net/inet_frag.h
> @@ -14,7 +14,9 @@ struct fqdir {
> int max_dist;
> struct inet_frags *f;
> struct net *net;
> - bool dead;
> +
> + /* We can't use boolean because this needs atomic writes. */
> + int dead;
>
> struct rhashtable rhashtable ____cacheline_aligned_in_smp;
>
> diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> index 35e9784fab4e..05aa7c145817 100644
> --- a/net/ipv4/inet_fragment.c
> +++ b/net/ipv4/inet_fragment.c
> @@ -193,7 +193,7 @@ void fqdir_exit(struct fqdir *fqdir)
> {
> fqdir->high_thresh = 0; /* prevent creation of new frags */
>
> - fqdir->dead = true;
> + fqdir->dead = 1;
>
> /* call_rcu is supposed to provide memory barrier semantics,
> * separating the setting of fqdir->dead with the destruction
>
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-07 15:26 ` Eric Dumazet
@ 2019-06-07 15:32 ` Herbert Xu
2019-06-07 16:13 ` Eric Dumazet
2019-06-07 16:19 ` Linus Torvalds
1 sibling, 1 reply; 62+ messages in thread
From: Herbert Xu @ 2019-06-07 15:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Linus Torvalds, Alan Stern, Paul E. McKenney, Boqun Feng,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Andrea Parri, Luc Maranget, Jade Alglave
On Fri, Jun 07, 2019 at 08:26:12AM -0700, Eric Dumazet wrote:
>
> There is common knowledge among us programmers that bit fields
> (or bool) sharing a common 'word' need to be protected
> with a common lock.
>
> Converting all bit fields to plain int/long would be quite a waste of memory.
>
> In this case, fqdir_exit() is called right before the whole
> struct fqdir is dismantled, and the only cpu that could possibly
> change the thing is ourself, and we are going to start an RCU grace period.
>
> Note that first cache line in 'struct fqdir' is read-only.
> Only ->dead field is flipped to one at exit time.
>
> Your patch would send a strong signal to programmers to not even try using
> bit fields.
>
> Do we really want that ?
If this were a bitfield then I'd think it would be safer because
anybody adding a new bitfield is unlikely to try modifying both
fields without locking or atomic ops.
However, because this is a boolean, I can certainly see someone
else coming along and adding another bool right next to it and
expecting writes them to still be atomic.
As it stands, my patch has zero impact on memory usage because
it's simply using existing padding. Should this become an issue
in future, we can always revisit this and use a more appropriate
method of addressing it.
But the point is to alert future developers that this field is
not an ordinary boolean.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-07 15:32 ` Herbert Xu
@ 2019-06-07 16:13 ` Eric Dumazet
0 siblings, 0 replies; 62+ messages in thread
From: Eric Dumazet @ 2019-06-07 16:13 UTC (permalink / raw)
To: Herbert Xu, Eric Dumazet
Cc: Linus Torvalds, Alan Stern, Paul E. McKenney, Boqun Feng,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Andrea Parri, Luc Maranget, Jade Alglave
On 6/7/19 8:32 AM, Herbert Xu wrote:
> On Fri, Jun 07, 2019 at 08:26:12AM -0700, Eric Dumazet wrote:
>>
>> There is common knowledge among us programmers that bit fields
>> (or bool) sharing a common 'word' need to be protected
>> with a common lock.
>>
>> Converting all bit fields to plain int/long would be quite a waste of memory.
>>
>> In this case, fqdir_exit() is called right before the whole
>> struct fqdir is dismantled, and the only cpu that could possibly
>> change the thing is ourself, and we are going to start an RCU grace period.
>>
>> Note that first cache line in 'struct fqdir' is read-only.
>> Only ->dead field is flipped to one at exit time.
>>
>> Your patch would send a strong signal to programmers to not even try using
>> bit fields.
>>
>> Do we really want that ?
>
> If this were a bitfield then I'd think it would be safer because
> anybody adding a new bitfield is unlikely to try modifying both
> fields without locking or atomic ops.
>
> However, because this is a boolean, I can certainly see someone
> else coming along and adding another bool right next to it and
> expecting writes them to still be atomic.
>
> As it stands, my patch has zero impact on memory usage because
> it's simply using existing padding. Should this become an issue
> in future, we can always revisit this and use a more appropriate
> method of addressing it.
>
> But the point is to alert future developers that this field is
> not an ordinary boolean.
Okay, but you added a quite redundant comment.
/* We can't use boolean because this needs atomic writes. */
Should we add a similar comment in front of all bit-fields,
or could we factorize this in a proper Documentation perhaps ?
Can we just add a proper bit-field and not the comment ?
unsigned int dead:1;
This way, next programmer can just apply normal rules to add a new bit.
Thanks !
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-07 15:26 ` Eric Dumazet
2019-06-07 15:32 ` Herbert Xu
@ 2019-06-07 16:19 ` Linus Torvalds
2019-06-08 15:27 ` Paul E. McKenney
1 sibling, 1 reply; 62+ messages in thread
From: Linus Torvalds @ 2019-06-07 16:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: Herbert Xu, Alan Stern, Paul E. McKenney, Boqun Feng,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Andrea Parri, Luc Maranget, Jade Alglave
On Fri, Jun 7, 2019 at 8:26 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> There is common knowledge among us programmers that bit fields
> (or bool) sharing a common 'word' need to be protected
> with a common lock.
>
> Converting all bit fields to plain int/long would be quite a waste of memory.
Yeah, and we really don't care about alpha. So 'char' should be safe.
No compiler actually turns a 'bool' in a struct into a bitfield,
afaik, because you're still supposed to be able to take the address of
a boolean.
But on the whole, I do not believe that we should ever use 'bool' in
structures anyway, because it's such a badly defined type. I think
it's 'char' in practice on just about all architectures, but there
really were traditional use cases where 'bool' was int.
But:
- we shouldn't turn them into 'int' anyway - alpha is dead, and no
sane architecture will make the same mistake anyway. People learnt.
- we might want to make sure 'bool' really is 'char' in practice, to
double-check that fthe compiler doesn't do anything stupid.
- bitfields obviously do need locks. 'char' does not.
If there's somebody who really notices the alpha issue in PRACTICE, we
can then bother to fix it. But there is approximately one user, and
it's not a heavy-duty one.
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-07 16:19 ` Linus Torvalds
@ 2019-06-08 15:27 ` Paul E. McKenney
2019-06-08 17:42 ` Linus Torvalds
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-08 15:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric Dumazet, Herbert Xu, Alan Stern, Boqun Feng,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Andrea Parri, Luc Maranget, Jade Alglave
On Fri, Jun 07, 2019 at 09:19:42AM -0700, Linus Torvalds wrote:
> On Fri, Jun 7, 2019 at 8:26 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > There is common knowledge among us programmers that bit fields
> > (or bool) sharing a common 'word' need to be protected
> > with a common lock.
> >
> > Converting all bit fields to plain int/long would be quite a waste of memory.
>
> Yeah, and we really don't care about alpha. So 'char' should be safe.
>
> No compiler actually turns a 'bool' in a struct into a bitfield,
> afaik, because you're still supposed to be able to take the address of
> a boolean.
>
> But on the whole, I do not believe that we should ever use 'bool' in
> structures anyway, because it's such a badly defined type. I think
> it's 'char' in practice on just about all architectures, but there
> really were traditional use cases where 'bool' was int.
>
> But:
>
> - we shouldn't turn them into 'int' anyway - alpha is dead, and no
> sane architecture will make the same mistake anyway. People learnt.
>
> - we might want to make sure 'bool' really is 'char' in practice, to
> double-check that fthe compiler doesn't do anything stupid.
>
> - bitfields obviously do need locks. 'char' does not.
>
> If there's somebody who really notices the alpha issue in PRACTICE, we
> can then bother to fix it. But there is approximately one user, and
> it's not a heavy-duty one.
C11 and later compilers are supposed to use read-modify-write atomic
operations in this sort of situation anyway because they are not supposed
to introduce data races. So if this problem comes up, the fix should
be in GCC rather than the Linux kernel, right?
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-08 15:27 ` Paul E. McKenney
@ 2019-06-08 17:42 ` Linus Torvalds
2019-06-08 17:50 ` Linus Torvalds
2019-06-08 18:14 ` Paul E. McKenney
0 siblings, 2 replies; 62+ messages in thread
From: Linus Torvalds @ 2019-06-08 17:42 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Eric Dumazet, Herbert Xu, Alan Stern, Boqun Feng,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Andrea Parri, Luc Maranget, Jade Alglave
On Sat, Jun 8, 2019 at 8:32 AM Paul E. McKenney <paulmck@linux.ibm.com> wrote:
>
> On Fri, Jun 07, 2019 at 09:19:42AM -0700, Linus Torvalds wrote:
> >
> > - bitfields obviously do need locks. 'char' does not.
> >
> > If there's somebody who really notices the alpha issue in PRACTICE, we
> > can then bother to fix it. But there is approximately one user, and
> > it's not a heavy-duty one.
>
> C11 and later compilers are supposed to use read-modify-write atomic
> operations in this sort of situation anyway because they are not supposed
> to introduce data races.
I don't think that's possible on any common architecture. The
bitfields themselves will need locking, to serialize writes of
different fields against each other.
There are no atomic rmw sequences that have reasonable performance for
the bitfield updates themselves.
The fields *around* the bitfields had better be safe, but that's
something we already depend on, and which falls under the heading of
"we don't accept garbage compilers".
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-08 17:42 ` Linus Torvalds
@ 2019-06-08 17:50 ` Linus Torvalds
2019-06-08 18:50 ` Paul E. McKenney
2019-06-08 18:14 ` Paul E. McKenney
1 sibling, 1 reply; 62+ messages in thread
From: Linus Torvalds @ 2019-06-08 17:50 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Eric Dumazet, Herbert Xu, Alan Stern, Boqun Feng,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Andrea Parri, Luc Maranget, Jade Alglave
On Sat, Jun 8, 2019 at 10:42 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> There are no atomic rmw sequences that have reasonable performance for
> the bitfield updates themselves.
Note that this is purely about the writing side. Reads of bitfield
values can be (and generally _should_ be) atomic, and hopefully C11
means that you wouldn't see intermediate values.
But I'm not convinced about that either: one natural way to update a
bitfield is to first do the masking, and then do the insertion of new
bits, so a bitfield assignment very easily exposes non-real values to
a concurrent read on another CPU.
What I think C11 is supposed to protect is from compilers doing
horribly bad things, and accessing bitfields with bigger types than
the field itself, ie when you have
struct {
char c;
int field1:5;
};
then a write to "field1" had better not touch "char c" as part of the
rmw operation, because that would indeed introduce a data-race with a
completely independent field that might have completely independent
locking rules.
But
struct {
int c:8;
int field1:5;
};
would not sanely have the same guarantees, even if the layout in
memory might be identical. Once you have bitfields next to each other,
and use a base type that means they can be combined together, they
can't be sanely modified without locking.
(And I don't know if C11 took up the "base type of the bitfield"
thing. Maybe you still need to use the ":0" thing to force alignment,
and maybe the C standards people still haven't made the underlying
type be meaningful other than for sign handling).
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-08 17:50 ` Linus Torvalds
@ 2019-06-08 18:50 ` Paul E. McKenney
0 siblings, 0 replies; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-08 18:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric Dumazet, Herbert Xu, Alan Stern, Boqun Feng,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Andrea Parri, Luc Maranget, Jade Alglave
On Sat, Jun 08, 2019 at 10:50:51AM -0700, Linus Torvalds wrote:
> On Sat, Jun 8, 2019 at 10:42 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > There are no atomic rmw sequences that have reasonable performance for
> > the bitfield updates themselves.
>
> Note that this is purely about the writing side. Reads of bitfield
> values can be (and generally _should_ be) atomic, and hopefully C11
> means that you wouldn't see intermediate values.
>
> But I'm not convinced about that either: one natural way to update a
> bitfield is to first do the masking, and then do the insertion of new
> bits, so a bitfield assignment very easily exposes non-real values to
> a concurrent read on another CPU.
Agreed on the "not convinced" part (though perhaps most implementations
would handle concurrent reads and writes involving different fields of
the same bitfield). And the C standard does not guarantee this, because
data races are defined in terms of memory locations. So as far as the
C standard is concerned, if there are two concurrent accesses to fields
within a bitfield that are not separated by ":0", there is a data race
and so the compiler can do whatever it wants.
But do we really care about this case?
> What I think C11 is supposed to protect is from compilers doing
> horribly bad things, and accessing bitfields with bigger types than
> the field itself, ie when you have
>
> struct {
> char c;
> int field1:5;
> };
>
> then a write to "field1" had better not touch "char c" as part of the
> rmw operation, because that would indeed introduce a data-race with a
> completely independent field that might have completely independent
> locking rules.
>
> But
>
> struct {
> int c:8;
> int field1:5;
> };
>
> would not sanely have the same guarantees, even if the layout in
> memory might be identical. Once you have bitfields next to each other,
> and use a base type that means they can be combined together, they
> can't be sanely modified without locking.
>
> (And I don't know if C11 took up the "base type of the bitfield"
> thing. Maybe you still need to use the ":0" thing to force alignment,
> and maybe the C standards people still haven't made the underlying
> type be meaningful other than for sign handling).
The C standard draft (n2310) gives similar examples:
EXAMPLE A structure declared as
struct {
char a;
int b:5, c:11,:0, d:8;
struct { int ee:8; } e;
}
contains four separate memory locations: The member a, and
bit-fields d and e.ee are each separate memory locations,
and can be modified concurrently without interfering with each
other. The bit-fields b and c together constitute the fourth
memory location. The bit-fields b and c cannot be concurrently
modified, but b and a, for example, can be.
So yes, ":0" still forces alignment to the next storage unit. And it
can be used to allow concurrent accesses to fields within a bitfield,
but only when those two fields are separated by ":0".
On the underlying type, according to J.3.9 of the current C working draft,
the following are implementation-specified behavior:
- Whether a "plain" int bit-field is treated as a signed int
bit-field or as an unsigned int bit-field (6.7.2, 6.7.2.1).
- Whether atomic types are permitted for bit-fields (6.7.2.1).
This last is strange because you are not allowed to take the address of
a bit field, and the various operations on atomic types take addresses.
Search me!
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: inet: frags: Turn fqdir->dead into an int for old Alphas
2019-06-08 17:42 ` Linus Torvalds
2019-06-08 17:50 ` Linus Torvalds
@ 2019-06-08 18:14 ` Paul E. McKenney
1 sibling, 0 replies; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-08 18:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric Dumazet, Herbert Xu, Alan Stern, Boqun Feng,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Andrea Parri, Luc Maranget, Jade Alglave
On Sat, Jun 08, 2019 at 10:42:41AM -0700, Linus Torvalds wrote:
> On Sat, Jun 8, 2019 at 8:32 AM Paul E. McKenney <paulmck@linux.ibm.com> wrote:
> >
> > On Fri, Jun 07, 2019 at 09:19:42AM -0700, Linus Torvalds wrote:
> > >
> > > - bitfields obviously do need locks. 'char' does not.
> > >
> > > If there's somebody who really notices the alpha issue in PRACTICE, we
> > > can then bother to fix it. But there is approximately one user, and
> > > it's not a heavy-duty one.
> >
> > C11 and later compilers are supposed to use read-modify-write atomic
> > operations in this sort of situation anyway because they are not supposed
> > to introduce data races.
Apologies, I should have explicitly stated that I was talking about char
stores, not bitfield stores. And last I checked, the C11 standard's
prohibition against data races did not extend to individual fields within
a bitfield. So, yes, for bitfields, the programmer must use a lock or
similar if it is necessary for updates to fields within a bitfield to
be atomic.
> I don't think that's possible on any common architecture. The
> bitfields themselves will need locking, to serialize writes of
> different fields against each other.
Yes, and again the C standard doesn't make any atomicity guarantees
regarding storing to different fields within a bitfield. The compiler is
free to assume that nothing else is happening anywhere in the bitfield
when storing to a field within that bitfield. Which gets back to your
"bitfields obviously do need locks", and it is of course the developer
(not the compiler) who must supply those locks. Plus a given lock must
cover the entire bitfield -- having one lock for half the fields within
a given bitfield and another lock for the other half will break.
Switching from bitfields to char, the C standard -does- require that
storing to one char must avoid even momentary corruption of adjacent
char, so given an old Alpha the compiler would need to use something
like an LL/SC loop. If it fails to do so, that compiler is failing to
comply with the standard.
> There are no atomic rmw sequences that have reasonable performance for
> the bitfield updates themselves.
Agreed, in the general case. In a few specific special cases, we do
sometimes hand-craft bitfields using shifts and masks, and sometimes
we use atomic RMW operations to update them. I suppose we could use
unions as an alternative, but it is not clear to me that this would
help anything.
> The fields *around* the bitfields had better be safe, but that's
> something we already depend on, and which falls under the heading of
> "we don't accept garbage compilers".
And the C standard does require the compiler to make that guarantee, so
for once the standard is even on our side. ;-)
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-04 14:44 ` Alan Stern
2019-06-04 16:04 ` Linus Torvalds
@ 2019-06-06 4:51 ` Herbert Xu
2019-06-06 6:05 ` Paul E. McKenney
2019-06-06 8:16 ` Andrea Parri
2 siblings, 1 reply; 62+ messages in thread
From: Herbert Xu @ 2019-06-06 4:51 UTC (permalink / raw)
To: Alan Stern
Cc: Paul E. McKenney, Boqun Feng, Linus Torvalds,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Andrea Parri, Luc Maranget, Jade Alglave
On Tue, Jun 04, 2019 at 10:44:18AM -0400, Alan Stern wrote:
>
> Currently the LKMM says the test is allowed and there is a data race,
> but this answer clearly is wrong since it would violate the RCU
> guarantee.
Thank you! This is what I tried to say all along in this thread
but you expressed it in a much better way :)
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-06 4:51 ` rcu_read_lock lost its compiler barrier Herbert Xu
@ 2019-06-06 6:05 ` Paul E. McKenney
2019-06-06 6:14 ` Herbert Xu
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-06 6:05 UTC (permalink / raw)
To: Herbert Xu
Cc: Alan Stern, Boqun Feng, Linus Torvalds, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Thu, Jun 06, 2019 at 12:51:09PM +0800, Herbert Xu wrote:
> On Tue, Jun 04, 2019 at 10:44:18AM -0400, Alan Stern wrote:
> >
> > Currently the LKMM says the test is allowed and there is a data race,
> > but this answer clearly is wrong since it would violate the RCU
> > guarantee.
>
> Thank you! This is what I tried to say all along in this thread
> but you expressed it in a much better way :)
In case you were wondering, the reason that I was giving you such
a hard time was that from what I could see, you were pushing for no
{READ,WRITE}_ONCE() at all. ;-)
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-06 6:05 ` Paul E. McKenney
@ 2019-06-06 6:14 ` Herbert Xu
2019-06-06 9:06 ` Paul E. McKenney
0 siblings, 1 reply; 62+ messages in thread
From: Herbert Xu @ 2019-06-06 6:14 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Alan Stern, Boqun Feng, Linus Torvalds, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Wed, Jun 05, 2019 at 11:05:11PM -0700, Paul E. McKenney wrote:
>
> In case you were wondering, the reason that I was giving you such
> a hard time was that from what I could see, you were pushing for no
> {READ,WRITE}_ONCE() at all. ;-)
Hmm, that's exactly what it should be in net/ipv4/inet_fragment.c.
We don't need the READ_ONCE/WRITE_ONCE (or volatile marking) at
all. Even if the compiler dices and slices the reads/writes of
"a" into a thousand pieces, it should still work if the RCU
primitives are worth their salt.
But I do concede that in the general RCU case you must have the
READ_ONCE/WRITE_ONCE calls for rcu_dereference/rcu_assign_pointer.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-06 6:14 ` Herbert Xu
@ 2019-06-06 9:06 ` Paul E. McKenney
2019-06-06 9:28 ` Herbert Xu
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-06 9:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Alan Stern, Boqun Feng, Linus Torvalds, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Thu, Jun 06, 2019 at 02:14:38PM +0800, Herbert Xu wrote:
> On Wed, Jun 05, 2019 at 11:05:11PM -0700, Paul E. McKenney wrote:
> >
> > In case you were wondering, the reason that I was giving you such
> > a hard time was that from what I could see, you were pushing for no
> > {READ,WRITE}_ONCE() at all. ;-)
>
> Hmm, that's exactly what it should be in net/ipv4/inet_fragment.c.
> We don't need the READ_ONCE/WRITE_ONCE (or volatile marking) at
> all. Even if the compiler dices and slices the reads/writes of
> "a" into a thousand pieces, it should still work if the RCU
> primitives are worth their salt.
OK, so I take it that there is additional synchronization in there
somewhere that is not captured in your simplified example code?
Or is your point instead that given the initial value of "a" being
zero and the value stored to "a" being one, there is no way that
any possible load and store tearing (your slicing and dicing) could
possibly mess up the test of the value loaded from "a"?
> But I do concede that in the general RCU case you must have the
> READ_ONCE/WRITE_ONCE calls for rcu_dereference/rcu_assign_pointer.
OK, good that we are in agreement on this part, at least! ;-)
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-06 9:06 ` Paul E. McKenney
@ 2019-06-06 9:28 ` Herbert Xu
2019-06-06 10:58 ` Paul E. McKenney
0 siblings, 1 reply; 62+ messages in thread
From: Herbert Xu @ 2019-06-06 9:28 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Alan Stern, Boqun Feng, Linus Torvalds, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Thu, Jun 06, 2019 at 02:06:19AM -0700, Paul E. McKenney wrote:
>
> Or is your point instead that given the initial value of "a" being
> zero and the value stored to "a" being one, there is no way that
> any possible load and store tearing (your slicing and dicing) could
> possibly mess up the test of the value loaded from "a"?
Exactly. If you can dream up of a scenario where the compiler can
get this wrong I'm all ears.
> > But I do concede that in the general RCU case you must have the
> > READ_ONCE/WRITE_ONCE calls for rcu_dereference/rcu_assign_pointer.
>
> OK, good that we are in agreement on this part, at least! ;-)
Well only because we're allowing crazy compilers that can turn
a simple word-aligned word assignment (a = b) into two stores.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-06 9:28 ` Herbert Xu
@ 2019-06-06 10:58 ` Paul E. McKenney
2019-06-06 13:38 ` Herbert Xu
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-06 10:58 UTC (permalink / raw)
To: Herbert Xu
Cc: Alan Stern, Boqun Feng, Linus Torvalds, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Thu, Jun 06, 2019 at 05:28:55PM +0800, Herbert Xu wrote:
> On Thu, Jun 06, 2019 at 02:06:19AM -0700, Paul E. McKenney wrote:
> >
> > Or is your point instead that given the initial value of "a" being
> > zero and the value stored to "a" being one, there is no way that
> > any possible load and store tearing (your slicing and dicing) could
> > possibly mess up the test of the value loaded from "a"?
>
> Exactly. If you can dream up of a scenario where the compiler can
> get this wrong I'm all ears.
I believe that this is safe in practice, as long as you exercise
constant vigilance. (OK, OK, I might be overdramatizing...)
I cannot immediately think of a way that the compiler could get this
wrong even in theory, but similar code sequences can be messed up.
The reason for this is that in theory, the compiler could use the
stored-to location as temporary storage, like this:
a = whatever; // Compiler uses "a" as a temporary
do_something();
whatever = a;
a = 1; // Intended store
The compiler is allowed to do this (again, in theory and according to a
strict interpretation of the standard) because you haven't told it that
anything else is paying attention to variable "a". As a result, the
compiler is within its rights to use "a" as temporary storage immediately
prior to any plain C-language store to "a".
In practice, I don't know of any compilers that actually do this, nor
have I heard anyone suggesting that they might soon actually do this.
And even if they could, your example would still work because your example
doesn't care about anything other than zero and non-zero, so wouldn't
get confused by the compiler storing a temporary value of 42 or whatever.
> > > But I do concede that in the general RCU case you must have the
> > > READ_ONCE/WRITE_ONCE calls for rcu_dereference/rcu_assign_pointer.
> >
> > OK, good that we are in agreement on this part, at least! ;-)
>
> Well only because we're allowing crazy compilers that can turn
> a simple word-aligned word assignment (a = b) into two stores.
In my experience, the insanity of compilers increases with time,
but yes.
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-06 10:58 ` Paul E. McKenney
@ 2019-06-06 13:38 ` Herbert Xu
2019-06-06 13:48 ` Paul E. McKenney
0 siblings, 1 reply; 62+ messages in thread
From: Herbert Xu @ 2019-06-06 13:38 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Alan Stern, Boqun Feng, Linus Torvalds, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Thu, Jun 06, 2019 at 03:58:17AM -0700, Paul E. McKenney wrote:
>
> I cannot immediately think of a way that the compiler could get this
> wrong even in theory, but similar code sequences can be messed up.
> The reason for this is that in theory, the compiler could use the
> stored-to location as temporary storage, like this:
>
> a = whatever; // Compiler uses "a" as a temporary
> do_something();
> whatever = a;
> a = 1; // Intended store
Well if the compiler is going to do this then surely it would
continue to do this even if you used WRITE_ONCE. Remember a is
not volatile, only the access of a through WRITE_ONCE is volatile.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-06 13:38 ` Herbert Xu
@ 2019-06-06 13:48 ` Paul E. McKenney
0 siblings, 0 replies; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-06 13:48 UTC (permalink / raw)
To: Herbert Xu
Cc: Alan Stern, Boqun Feng, Linus Torvalds, Frederic Weisbecker,
Fengguang Wu, LKP, LKML, Netdev, David S. Miller, Andrea Parri,
Luc Maranget, Jade Alglave
On Thu, Jun 06, 2019 at 09:38:24PM +0800, Herbert Xu wrote:
> On Thu, Jun 06, 2019 at 03:58:17AM -0700, Paul E. McKenney wrote:
> >
> > I cannot immediately think of a way that the compiler could get this
> > wrong even in theory, but similar code sequences can be messed up.
> > The reason for this is that in theory, the compiler could use the
> > stored-to location as temporary storage, like this:
> >
> > a = whatever; // Compiler uses "a" as a temporary
> > do_something();
> > whatever = a;
> > a = 1; // Intended store
>
> Well if the compiler is going to do this then surely it would
> continue to do this even if you used WRITE_ONCE. Remember a is
> not volatile, only the access of a through WRITE_ONCE is volatile.
I disagree. Given a volatile store, the compiler cannot assume that the
stored-to location is normal memory at that point in time, and therefore
cannot assume that it is safe to invent a store to that location (as
shown above). Thus far, the C++ standards committee seems on-board with
this, though time will tell.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1382r1.pdf
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-04 14:44 ` Alan Stern
2019-06-04 16:04 ` Linus Torvalds
2019-06-06 4:51 ` rcu_read_lock lost its compiler barrier Herbert Xu
@ 2019-06-06 8:16 ` Andrea Parri
2019-06-06 14:19 ` Alan Stern
2 siblings, 1 reply; 62+ messages in thread
From: Andrea Parri @ 2019-06-06 8:16 UTC (permalink / raw)
To: Alan Stern
Cc: Paul E. McKenney, Boqun Feng, Herbert Xu, Linus Torvalds,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Luc Maranget, Jade Alglave
> This example really does point out a weakness in the LKMM's handling of
> data races. Herbert's litmus test is a great starting point:
>
>
> C xu
>
> {}
>
> P0(int *a, int *b)
> {
> WRITE_ONCE(*a, 1);
> synchronize_rcu();
> *b = 2;
> }
>
> P1(int *a, int *b)
> {
> rcu_read_lock();
> if (READ_ONCE(*a) == 0)
> *b = 1;
> rcu_read_unlock();
> }
>
> exists (~b=2)
>
>
> Currently the LKMM says the test is allowed and there is a data race,
> but this answer clearly is wrong since it would violate the RCU
> guarantee.
>
> The problem is that the LKMM currently requires all ordering/visibility
> of plain accesses to be mediated by marked accesses. But in this case,
> the visibility is mediated by RCU. Technically, we need to add a
> relation like
>
> ([M] ; po ; rcu-fence ; po ; [M])
>
> into the definitions of ww-vis, wr-vis, and rw-xbstar. Doing so
> changes the litmus test's result to "not allowed" and no data race.
> However, I'm not certain that this single change is the entire fix;
> more thought is needed.
This seems a sensible change to me: looking forward to seeing a patch,
on top of -rcu/dev, for further review and testing!
We could also add (to LKMM) the barrier() for rcu_read_{lock,unlock}()
discussed in this thread (maybe once the RCU code and the informal doc
will have settled in such direction).
It seems worth stressing the fact that _neither_ of these changes will
prevent the test below from being racy, considered the two accesses to
"a" happen concurrently / without synchronization.
Thanks,
Andrea
C xu-2
{}
P0(int *a, int *b)
{
*a = 1;
synchronize_rcu();
WRITE_ONCE(*b, 2);
}
P1(int *a, int *b)
{
rcu_read_lock();
if (*a == 0)
WRITE_ONCE(*b, 1);
rcu_read_unlock();
}
exists (~b=2)
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-06 8:16 ` Andrea Parri
@ 2019-06-06 14:19 ` Alan Stern
2019-06-08 15:19 ` Paul E. McKenney
0 siblings, 1 reply; 62+ messages in thread
From: Alan Stern @ 2019-06-06 14:19 UTC (permalink / raw)
To: Andrea Parri
Cc: Paul E. McKenney, Boqun Feng, Herbert Xu, Linus Torvalds,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Luc Maranget, Jade Alglave
On Thu, 6 Jun 2019, Andrea Parri wrote:
> This seems a sensible change to me: looking forward to seeing a patch,
> on top of -rcu/dev, for further review and testing!
>
> We could also add (to LKMM) the barrier() for rcu_read_{lock,unlock}()
> discussed in this thread (maybe once the RCU code and the informal doc
> will have settled in such direction).
Yes. Also for SRCU. That point had not escaped me.
Alan
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-06 14:19 ` Alan Stern
@ 2019-06-08 15:19 ` Paul E. McKenney
2019-06-08 15:56 ` Alan Stern
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-08 15:19 UTC (permalink / raw)
To: Alan Stern
Cc: Andrea Parri, Boqun Feng, Herbert Xu, Linus Torvalds,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Luc Maranget, Jade Alglave
On Thu, Jun 06, 2019 at 10:19:43AM -0400, Alan Stern wrote:
> On Thu, 6 Jun 2019, Andrea Parri wrote:
>
> > This seems a sensible change to me: looking forward to seeing a patch,
> > on top of -rcu/dev, for further review and testing!
> >
> > We could also add (to LKMM) the barrier() for rcu_read_{lock,unlock}()
> > discussed in this thread (maybe once the RCU code and the informal doc
> > will have settled in such direction).
>
> Yes. Also for SRCU. That point had not escaped me.
And it does seem pretty settled. There are quite a few examples where
there are normal accesses at either end of the RCU read-side critical
sections, for example, the one in the requirements diffs below.
For SRCU, srcu_read_lock() and srcu_read_unlock() have implied compiler
barriers since 2006. ;-)
Thanx, Paul
------------------------------------------------------------------------
diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
index 5a9238a2883c..080b39cc1dbb 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -2129,6 +2129,8 @@ Some of the relevant points of interest are as follows:
<li> <a href="#Hotplug CPU">Hotplug CPU</a>.
<li> <a href="#Scheduler and RCU">Scheduler and RCU</a>.
<li> <a href="#Tracing and RCU">Tracing and RCU</a>.
+<li> <a href="#Accesses to User Mamory and RCU">
+Accesses to User Mamory and RCU</a>.
<li> <a href="#Energy Efficiency">Energy Efficiency</a>.
<li> <a href="#Scheduling-Clock Interrupts and RCU">
Scheduling-Clock Interrupts and RCU</a>.
@@ -2521,6 +2523,75 @@ cannot be used.
The tracing folks both located the requirement and provided the
needed fix, so this surprise requirement was relatively painless.
+<h3><a name="Accesses to User Mamory and RCU">
+Accesses to User Mamory and RCU</a></h3>
+
+<p>
+The kernel needs to access user-space memory, for example, to access
+data referenced by system-call parameters.
+The <tt>get_user()</tt> macro does this job.
+
+<p>
+However, user-space memory might well be paged out, which means
+that <tt>get_user()</tt> might well page-fault and thus block while
+waiting for the resulting I/O to complete.
+It would be a very bad thing for the compiler to reorder
+a <tt>get_user()</tt> invocation into an RCU read-side critical
+section.
+For example, suppose that the source code looked like this:
+
+<blockquote>
+<pre>
+ 1 rcu_read_lock();
+ 2 p = rcu_dereference(gp);
+ 3 v = p->value;
+ 4 rcu_read_unlock();
+ 5 get_user(user_v, user_p);
+ 6 do_something_with(v, user_v);
+</pre>
+</blockquote>
+
+<p>
+The compiler must not be permitted to transform this source code into
+the following:
+
+<blockquote>
+<pre>
+ 1 rcu_read_lock();
+ 2 p = rcu_dereference(gp);
+ 3 get_user(user_v, user_p); // BUG: POSSIBLE PAGE FAULT!!!
+ 4 v = p->value;
+ 5 rcu_read_unlock();
+ 6 do_something_with(v, user_v);
+</pre>
+</blockquote>
+
+<p>
+If the compiler did make this transformation in a
+<tt>CONFIG_PREEMPT=n</tt> kernel build, and if <tt>get_user()</tt> did
+page fault, the result would be a quiescent state in the middle
+of an RCU read-side critical section.
+This misplaced quiescent state could result in line 4 being
+a use-after-free access, which could be bad for your kernel's
+actuarial statistics.
+Similar examples can be constructed with the call to <tt>get_user()</tt>
+preceding the <tt>rcu_read_lock()</tt>.
+
+<p>
+Unfortunately, <tt>get_user()</tt> doesn't have any particular
+ordering properties, and in some architectures the underlying <tt>asm</tt>
+isn't even marked <tt>volatile</tt>.
+And even if it was marked <tt>volatile</tt>, the above access to
+<tt>p->value</tt> is not volatile, so the compiler would not have any
+reason to keep those two accesses in order.
+
+<p>
+Therefore, the Linux-kernel definitions of <tt>rcu_read_lock()</tt>
+and <tt>rcu_read_unlock()</tt> must act as compiler barriers,
+at least for outermost instances of <tt>rcu_read_lock()</tt> and
+<tt>rcu_read_unlock()</tt> within a nested set of RCU read-side critical
+sections.
+
<h3><a name="Energy Efficiency">Energy Efficiency</a></h3>
<p>
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-08 15:19 ` Paul E. McKenney
@ 2019-06-08 15:56 ` Alan Stern
2019-06-08 16:31 ` Paul E. McKenney
0 siblings, 1 reply; 62+ messages in thread
From: Alan Stern @ 2019-06-08 15:56 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Andrea Parri, Boqun Feng, Herbert Xu, Linus Torvalds,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Luc Maranget, Jade Alglave
On Sat, 8 Jun 2019, Paul E. McKenney wrote:
> On Thu, Jun 06, 2019 at 10:19:43AM -0400, Alan Stern wrote:
> > On Thu, 6 Jun 2019, Andrea Parri wrote:
> >
> > > This seems a sensible change to me: looking forward to seeing a patch,
> > > on top of -rcu/dev, for further review and testing!
> > >
> > > We could also add (to LKMM) the barrier() for rcu_read_{lock,unlock}()
> > > discussed in this thread (maybe once the RCU code and the informal doc
> > > will have settled in such direction).
> >
> > Yes. Also for SRCU. That point had not escaped me.
>
> And it does seem pretty settled. There are quite a few examples where
> there are normal accesses at either end of the RCU read-side critical
> sections, for example, the one in the requirements diffs below.
>
> For SRCU, srcu_read_lock() and srcu_read_unlock() have implied compiler
> barriers since 2006. ;-)
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
> index 5a9238a2883c..080b39cc1dbb 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.html
> +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> @@ -2129,6 +2129,8 @@ Some of the relevant points of interest are as follows:
> <li> <a href="#Hotplug CPU">Hotplug CPU</a>.
> <li> <a href="#Scheduler and RCU">Scheduler and RCU</a>.
> <li> <a href="#Tracing and RCU">Tracing and RCU</a>.
> +<li> <a href="#Accesses to User Mamory and RCU">
------------------------------------^
> +Accesses to User Mamory and RCU</a>.
---------------------^
> <li> <a href="#Energy Efficiency">Energy Efficiency</a>.
> <li> <a href="#Scheduling-Clock Interrupts and RCU">
> Scheduling-Clock Interrupts and RCU</a>.
> @@ -2521,6 +2523,75 @@ cannot be used.
> The tracing folks both located the requirement and provided the
> needed fix, so this surprise requirement was relatively painless.
>
> +<h3><a name="Accesses to User Mamory and RCU">
----------------------------------^
> +Accesses to User Mamory and RCU</a></h3>
---------------------^
Are these issues especially notable for female programmers? :-)
Alan
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-08 15:56 ` Alan Stern
@ 2019-06-08 16:31 ` Paul E. McKenney
0 siblings, 0 replies; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-08 16:31 UTC (permalink / raw)
To: Alan Stern
Cc: Andrea Parri, Boqun Feng, Herbert Xu, Linus Torvalds,
Frederic Weisbecker, Fengguang Wu, LKP, LKML, Netdev,
David S. Miller, Luc Maranget, Jade Alglave
On Sat, Jun 08, 2019 at 11:56:04AM -0400, Alan Stern wrote:
> On Sat, 8 Jun 2019, Paul E. McKenney wrote:
>
> > On Thu, Jun 06, 2019 at 10:19:43AM -0400, Alan Stern wrote:
> > > On Thu, 6 Jun 2019, Andrea Parri wrote:
> > >
> > > > This seems a sensible change to me: looking forward to seeing a patch,
> > > > on top of -rcu/dev, for further review and testing!
> > > >
> > > > We could also add (to LKMM) the barrier() for rcu_read_{lock,unlock}()
> > > > discussed in this thread (maybe once the RCU code and the informal doc
> > > > will have settled in such direction).
> > >
> > > Yes. Also for SRCU. That point had not escaped me.
> >
> > And it does seem pretty settled. There are quite a few examples where
> > there are normal accesses at either end of the RCU read-side critical
> > sections, for example, the one in the requirements diffs below.
> >
> > For SRCU, srcu_read_lock() and srcu_read_unlock() have implied compiler
> > barriers since 2006. ;-)
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
> > index 5a9238a2883c..080b39cc1dbb 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.html
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> > @@ -2129,6 +2129,8 @@ Some of the relevant points of interest are as follows:
> > <li> <a href="#Hotplug CPU">Hotplug CPU</a>.
> > <li> <a href="#Scheduler and RCU">Scheduler and RCU</a>.
> > <li> <a href="#Tracing and RCU">Tracing and RCU</a>.
> > +<li> <a href="#Accesses to User Mamory and RCU">
> ------------------------------------^
> > +Accesses to User Mamory and RCU</a>.
> ---------------------^
> > <li> <a href="#Energy Efficiency">Energy Efficiency</a>.
> > <li> <a href="#Scheduling-Clock Interrupts and RCU">
> > Scheduling-Clock Interrupts and RCU</a>.
> > @@ -2521,6 +2523,75 @@ cannot be used.
> > The tracing folks both located the requirement and provided the
> > needed fix, so this surprise requirement was relatively painless.
> >
> > +<h3><a name="Accesses to User Mamory and RCU">
> ----------------------------------^
> > +Accesses to User Mamory and RCU</a></h3>
> ---------------------^
>
> Are these issues especially notable for female programmers? :-)
*Red face* Some days it just doesn't pay to get up in the morning...
Well, those issues certainly seem a bit inconsiderate to non-mammalian
programmers. :-/
How about the updated version shown below?
Thanx, Paul
------------------------------------------------------------------------
diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
index 5a9238a2883c..f04c467e55c5 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -2129,6 +2129,8 @@ Some of the relevant points of interest are as follows:
<li> <a href="#Hotplug CPU">Hotplug CPU</a>.
<li> <a href="#Scheduler and RCU">Scheduler and RCU</a>.
<li> <a href="#Tracing and RCU">Tracing and RCU</a>.
+<li> <a href="#Accesses to User Memory and RCU">
+Accesses to User Memory and RCU</a>.
<li> <a href="#Energy Efficiency">Energy Efficiency</a>.
<li> <a href="#Scheduling-Clock Interrupts and RCU">
Scheduling-Clock Interrupts and RCU</a>.
@@ -2521,6 +2523,75 @@ cannot be used.
The tracing folks both located the requirement and provided the
needed fix, so this surprise requirement was relatively painless.
+<h3><a name="Accesses to User Memory and RCU">
+Accesses to User Memory and RCU</a></h3>
+
+<p>
+The kernel needs to access user-space memory, for example, to access
+data referenced by system-call parameters.
+The <tt>get_user()</tt> macro does this job.
+
+<p>
+However, user-space memory might well be paged out, which means
+that <tt>get_user()</tt> might well page-fault and thus block while
+waiting for the resulting I/O to complete.
+It would be a very bad thing for the compiler to reorder
+a <tt>get_user()</tt> invocation into an RCU read-side critical
+section.
+For example, suppose that the source code looked like this:
+
+<blockquote>
+<pre>
+ 1 rcu_read_lock();
+ 2 p = rcu_dereference(gp);
+ 3 v = p->value;
+ 4 rcu_read_unlock();
+ 5 get_user(user_v, user_p);
+ 6 do_something_with(v, user_v);
+</pre>
+</blockquote>
+
+<p>
+The compiler must not be permitted to transform this source code into
+the following:
+
+<blockquote>
+<pre>
+ 1 rcu_read_lock();
+ 2 p = rcu_dereference(gp);
+ 3 get_user(user_v, user_p); // BUG: POSSIBLE PAGE FAULT!!!
+ 4 v = p->value;
+ 5 rcu_read_unlock();
+ 6 do_something_with(v, user_v);
+</pre>
+</blockquote>
+
+<p>
+If the compiler did make this transformation in a
+<tt>CONFIG_PREEMPT=n</tt> kernel build, and if <tt>get_user()</tt> did
+page fault, the result would be a quiescent state in the middle
+of an RCU read-side critical section.
+This misplaced quiescent state could result in line 4 being
+a use-after-free access, which could be bad for your kernel's
+actuarial statistics.
+Similar examples can be constructed with the call to <tt>get_user()</tt>
+preceding the <tt>rcu_read_lock()</tt>.
+
+<p>
+Unfortunately, <tt>get_user()</tt> doesn't have any particular
+ordering properties, and in some architectures the underlying <tt>asm</tt>
+isn't even marked <tt>volatile</tt>.
+And even if it was marked <tt>volatile</tt>, the above access to
+<tt>p->value</tt> is not volatile, so the compiler would not have any
+reason to keep those two accesses in order.
+
+<p>
+Therefore, the Linux-kernel definitions of <tt>rcu_read_lock()</tt>
+and <tt>rcu_read_unlock()</tt> must act as compiler barriers,
+at least for outermost instances of <tt>rcu_read_lock()</tt> and
+<tt>rcu_read_unlock()</tt> within a nested set of RCU read-side critical
+sections.
+
<h3><a name="Energy Efficiency">Energy Efficiency</a></h3>
<p>
^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-03 5:26 ` Herbert Xu
2019-06-03 6:42 ` Boqun Feng
@ 2019-06-03 9:35 ` Paul E. McKenney
1 sibling, 0 replies; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-03 9:35 UTC (permalink / raw)
To: Herbert Xu
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Mon, Jun 03, 2019 at 01:26:26PM +0800, Herbert Xu wrote:
> On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
> >
> > 1. These guarantees are of full memory barriers, -not- compiler
> > barriers.
>
> What I'm saying is that wherever they are, they must come with
> compiler barriers. I'm not aware of any synchronisation mechanism
> in the kernel that gives a memory barrier without a compiler barrier.
Yes, if a given synchronization mechanism requires that memory references
need to be ordered, both the compiler and the CPU must maintain that
ordering.
> > 2. These rules don't say exactly where these full memory barriers
> > go. SRCU is at one extreme, placing those full barriers in
> > srcu_read_lock() and srcu_read_unlock(), and !PREEMPT Tree RCU
> > at the other, placing these barriers entirely within the callback
> > queueing/invocation, grace-period computation, and the scheduler.
> > Preemptible Tree RCU is in the middle, with rcu_read_unlock()
> > sometimes including a full memory barrier, but other times with
> > the full memory barrier being confined as it is with !PREEMPT
> > Tree RCU.
>
> The rules do say that the (full) memory barrier must precede any
> RCU read-side that occur after the synchronize_rcu and after the
> end of any RCU read-side that occur before the synchronize_rcu.
>
> All I'm arguing is that wherever that full mb is, as long as it
> also carries with it a barrier() (which it must do if it's done
> using an existing kernel mb/locking primitive), then we're fine.
Fair enough, and smp_mb() does provide what is needed.
> > Interleaving and inserting full memory barriers as per the rules above:
> >
> > CPU1: WRITE_ONCE(a, 1)
> > CPU1: synchronize_rcu
> > /* Could put a full memory barrier here, but it wouldn't help. */
>
> CPU1: smp_mb();
> CPU2: smp_mb();
What is CPU2's smp_mb() ordering? In other words, what comment would
you put on each of the above smp_mb() calls?
> Let's put them in because I think they are critical. smp_mb() also
> carries with it a barrier().
Again, agreed, smp_mb() implies barrier().
> > CPU2: rcu_read_lock();
> > CPU1: b = 2;
> > CPU2: if (READ_ONCE(a) == 0)
> > CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
> > CPU2: b = 1;
> > CPU2: rcu_read_unlock
> >
> > In fact, CPU2's load from b might be moved up to race with CPU1's store,
> > which (I believe) is why the model complains in this case.
>
> Let's put aside my doubt over how we're even allowing a compiler
> to turn
>
> b = 1
>
> into
>
> if (b != 1)
> b = 1
>
> Since you seem to be assuming that (a == 0) is true in this case
> (as the assignment b = 1 is carried out), then because of the
> presence of the full memory barrier, the RCU read-side section
> must have started prior to the synchronize_rcu. This means that
> synchronize_rcu is not allowed to return until at least the end
> of the grace period, or at least until the end of rcu_read_unlock.
>
> So it actually should be:
>
> CPU1: WRITE_ONCE(a, 1)
> CPU1: synchronize_rcu called
> /* Could put a full memory barrier here, but it wouldn't help. */
>
> CPU1: smp_mb();
> CPU2: smp_mb();
>
> CPU2: grace period starts
> ...time passes...
> CPU2: rcu_read_lock();
> CPU2: if (READ_ONCE(a) == 0)
> CPU2: if (b != 1) /* Weakly ordered CPU moved this up! */
> CPU2: b = 1;
> CPU2: rcu_read_unlock
> ...time passes...
> CPU2: grace period ends
>
> /* This full memory barrier is also guaranteed by RCU. */
> CPU2: smp_mb();
But in this case, given that there are no more statements for CPU2,
what is this smp_mb() ordering?
Thanx, Paul
> CPU1 synchronize_rcu returns
> CPU1: b = 2;
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-03 2:46 ` Herbert Xu
2019-06-03 3:47 ` Paul E. McKenney
@ 2019-06-06 8:38 ` Andrea Parri
2019-06-06 9:32 ` Herbert Xu
1 sibling, 1 reply; 62+ messages in thread
From: Andrea Parri @ 2019-06-06 8:38 UTC (permalink / raw)
To: Herbert Xu
Cc: Linus Torvalds, Paul E. McKenney, Frederic Weisbecker,
Boqun Feng, Fengguang Wu, LKP, LKML, Netdev, David S. Miller,
Dmitry Vyukov, Alan Stern, Eric Dumazet
On Mon, Jun 03, 2019 at 10:46:40AM +0800, Herbert Xu wrote:
> The case we were discussing is from net/ipv4/inet_fragment.c from
> the net-next tree:
BTW, thank you for keeping me and other people who intervened in that
discussion in Cc:...
Andrea
>
> void fqdir_exit(struct fqdir *fqdir)
> {
> ...
> fqdir->dead = true;
>
> /* call_rcu is supposed to provide memory barrier semantics,
> * separating the setting of fqdir->dead with the destruction
> * work. This implicit barrier is paired with inet_frag_kill().
> */
>
> INIT_RCU_WORK(&fqdir->destroy_rwork, fqdir_rwork_fn);
> queue_rcu_work(system_wq, &fqdir->destroy_rwork);
> }
>
> and
>
> void inet_frag_kill(struct inet_frag_queue *fq)
> {
> ...
> rcu_read_lock();
> /* The RCU read lock provides a memory barrier
> * guaranteeing that if fqdir->dead is false then
> * the hash table destruction will not start until
> * after we unlock. Paired with inet_frags_exit_net().
> */
> if (!fqdir->dead) {
> rhashtable_remove_fast(&fqdir->rhashtable, &fq->node,
> fqdir->f->rhash_params);
> ...
> }
> ...
> rcu_read_unlock();
> ...
> }
>
> I simplified this to
>
> Initial values:
>
> a = 0
> b = 0
>
> CPU1 CPU2
> ---- ----
> a = 1 rcu_read_lock
> synchronize_rcu if (a == 0)
> b = 2 b = 1
> rcu_read_unlock
>
> On exit we want this to be true:
> b == 2
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-06 8:38 ` Andrea Parri
@ 2019-06-06 9:32 ` Herbert Xu
0 siblings, 0 replies; 62+ messages in thread
From: Herbert Xu @ 2019-06-06 9:32 UTC (permalink / raw)
To: Andrea Parri
Cc: Linus Torvalds, Paul E. McKenney, Frederic Weisbecker,
Boqun Feng, Fengguang Wu, LKP, LKML, Netdev, David S. Miller,
Dmitry Vyukov, Alan Stern, Eric Dumazet
On Thu, Jun 06, 2019 at 10:38:56AM +0200, Andrea Parri wrote:
> On Mon, Jun 03, 2019 at 10:46:40AM +0800, Herbert Xu wrote:
>
> > The case we were discussing is from net/ipv4/inet_fragment.c from
> > the net-next tree:
>
> BTW, thank you for keeping me and other people who intervened in that
> discussion in Cc:...
FWIW I didn't drop you from the Cc list. The email discussion was
taken off-list by someone else and I simply kept that Cc list when
I brought it back onto lkml. On a second look I did end up dropping
Eric but I think he's had enough of this discussion :)
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-02 5:56 ` rcu_read_lock lost its compiler barrier Herbert Xu
2019-06-02 20:54 ` Linus Torvalds
@ 2019-06-03 0:06 ` Paul E. McKenney
2019-06-03 3:03 ` Herbert Xu
1 sibling, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-03 0:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Frederic Weisbecker, Boqun Feng, Fengguang Wu, LKP, LKML, netdev,
David S. Miller, Linus Torvalds
On Sun, Jun 02, 2019 at 01:56:07PM +0800, Herbert Xu wrote:
> Digging up an old email because I was not aware of this previously
> but Paul pointed me to it during another discussion.
>
> On Mon, Sep 21, 2015 at 01:43:27PM -0700, Paul E. McKenney wrote:
> > On Mon, Sep 21, 2015 at 09:30:49PM +0200, Frederic Weisbecker wrote:
> >
> > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > > index d63bb77..6c3cece 100644
> > > > --- a/include/linux/rcupdate.h
> > > > +++ b/include/linux/rcupdate.h
> > > > @@ -297,12 +297,14 @@ void synchronize_rcu(void);
> > > >
> > > > static inline void __rcu_read_lock(void)
> > > > {
> > > > - preempt_disable();
> > > > + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> > > > + preempt_disable();
> > >
> > > preempt_disable() is a no-op when !CONFIG_PREEMPT_COUNT, right?
> > > Or rather it's a barrier(), which is anyway implied by rcu_read_lock().
> > >
> > > So perhaps we can get rid of the IS_ENABLED() check?
> >
> > Actually, barrier() is not intended to be implied by rcu_read_lock().
> > In a non-preemptible RCU implementation, it doesn't help anything
> > to have the compiler flush its temporaries upon rcu_read_lock()
> > and rcu_read_unlock().
>
> This is seriously broken. RCU has been around for years and is
> used throughout the kernel while the compiler barrier existed.
Please note that preemptible Tree RCU has lacked the compiler barrier on
all but the outermost rcu_read_unlock() for years before Boqun's patch.
So exactly where in the code that we are currently discussing
are you relying on compiler barriers in either rcu_read_lock() or
rcu_read_unlock()?
The grace-period guarantee allows the compiler ordering to be either in
the readers (SMP&&PREEMPT), in the grace-period mechanism (SMP&&!PREEMPT),
or both (SRCU).
> You can't then go and decide to remove the compiler barrier! To do
> that you'd need to audit every single use of rcu_read_lock in the
> kernel to ensure that they're not depending on the compiler barrier.
>
> This is also contrary to the definition of almost every other
> *_lock primitive in the kernel where the compiler barrier is
> included.
>
> So please revert this patch.
I do not believe that reverting that patch will help you at all.
But who knows? So please point me at the full code body that was being
debated earlier on this thread. It will no doubt take me quite a while to
dig through it, given my being on the road for the next couple of weeks,
but so it goes.
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 0:06 ` Paul E. McKenney
@ 2019-06-03 3:03 ` Herbert Xu
2019-06-03 9:27 ` Paul E. McKenney
2019-06-03 15:55 ` Linus Torvalds
0 siblings, 2 replies; 62+ messages in thread
From: Herbert Xu @ 2019-06-03 3:03 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Frederic Weisbecker, Boqun Feng, Fengguang Wu, LKP, LKML, netdev,
David S. Miller, Linus Torvalds
On Sun, Jun 02, 2019 at 05:06:17PM -0700, Paul E. McKenney wrote:
>
> Please note that preemptible Tree RCU has lacked the compiler barrier on
> all but the outermost rcu_read_unlock() for years before Boqun's patch.
Actually this is not true. Boqun's patch (commit bb73c52bad36) does
not add a barrier() to __rcu_read_lock. In fact I dug into the git
history and this compiler barrier() has existed in preemptible tree
RCU since the very start in 2009:
: commit f41d911f8c49a5d65c86504c19e8204bb605c4fd
: Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
: Date: Sat Aug 22 13:56:52 2009 -0700
:
: rcu: Merge preemptable-RCU functionality into hierarchical RCU
:
: +/*
: + * Tree-preemptable RCU implementation for rcu_read_lock().
: + * Just increment ->rcu_read_lock_nesting, shared state will be updated
: + * if we block.
: + */
: +void __rcu_read_lock(void)
: +{
: + ACCESS_ONCE(current->rcu_read_lock_nesting)++;
: + barrier(); /* needed if we ever invoke rcu_read_lock in rcutree.c */
: +}
: +EXPORT_SYMBOL_GPL(__rcu_read_lock);
However, you are correct that in the non-preempt tree RCU case,
the compiler barrier in __rcu_read_lock was not always present.
In fact it was added by:
: commit 386afc91144b36b42117b0092893f15bc8798a80
: Author: Linus Torvalds <torvalds@linux-foundation.org>
: Date: Tue Apr 9 10:48:33 2013 -0700
:
: spinlocks and preemption points need to be at least compiler barriers
I suspect this is what prompted you to remove it in 2015.
> I do not believe that reverting that patch will help you at all.
>
> But who knows? So please point me at the full code body that was being
> debated earlier on this thread. It will no doubt take me quite a while to
> dig through it, given my being on the road for the next couple of weeks,
> but so it goes.
Please refer to my response to Linus for the code in question.
In any case, I am now even more certain that compiler barriers are
not needed in the code in question. The reasoning is quite simple.
If you need those compiler barriers then you surely need real memory
barriers.
Vice versa, if real memory barriers are already present thanks to
RCU, then you don't need those compiler barriers.
In fact this calls into question the use of READ_ONCE/WRITE_ONCE in
RCU primitives such as rcu_dereference and rcu_assign_pointer. IIRC
when RCU was first added to the Linux kernel we did not have compiler
barriers in rcu_dereference and rcu_assign_pointer. They were added
later on.
As compiler barriers per se are useless, these are surely meant to
be coupled with the memory barriers provided by RCU grace periods
and synchronize_rcu. But then those real memory barriers would have
compiler barriers too. So why do we need the compiler barriers in
rcu_dereference and rcu_assign_pointer?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 3:03 ` Herbert Xu
@ 2019-06-03 9:27 ` Paul E. McKenney
2019-06-03 15:55 ` Linus Torvalds
1 sibling, 0 replies; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-03 9:27 UTC (permalink / raw)
To: Herbert Xu
Cc: Frederic Weisbecker, Boqun Feng, Fengguang Wu, LKP, LKML, netdev,
David S. Miller, Linus Torvalds
On Mon, Jun 03, 2019 at 11:03:24AM +0800, Herbert Xu wrote:
> On Sun, Jun 02, 2019 at 05:06:17PM -0700, Paul E. McKenney wrote:
> >
> > Please note that preemptible Tree RCU has lacked the compiler barrier on
> > all but the outermost rcu_read_unlock() for years before Boqun's patch.
>
> Actually this is not true. Boqun's patch (commit bb73c52bad36) does
> not add a barrier() to __rcu_read_lock. In fact I dug into the git
> history and this compiler barrier() has existed in preemptible tree
> RCU since the very start in 2009:
I said rcu_read_unlock() and you said __rcu_read_lock().
> : commit f41d911f8c49a5d65c86504c19e8204bb605c4fd
> : Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> : Date: Sat Aug 22 13:56:52 2009 -0700
> :
> : rcu: Merge preemptable-RCU functionality into hierarchical RCU
> :
> : +/*
> : + * Tree-preemptable RCU implementation for rcu_read_lock().
> : + * Just increment ->rcu_read_lock_nesting, shared state will be updated
> : + * if we block.
> : + */
> : +void __rcu_read_lock(void)
> : +{
> : + ACCESS_ONCE(current->rcu_read_lock_nesting)++;
> : + barrier(); /* needed if we ever invoke rcu_read_lock in rcutree.c */
> : +}
> : +EXPORT_SYMBOL_GPL(__rcu_read_lock);
Thank you for finding this! This particular version does have an
unconditional barrier() in __rcu_read_unlock(), for whatever that
is worth:
+void __rcu_read_unlock(void)
+{
+ struct task_struct *t = current;
+
+ barrier(); /* needed if we ever invoke rcu_read_unlock in rcutree.c */
+ if (--ACCESS_ONCE(t->rcu_read_lock_nesting) == 0 &&
+ unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
+ rcu_read_unlock_special(t);
+}
I would not have seen the point of a compiler barrier in the non-outermost
__rcu_read_unlock(), since the completion of an inner __rcu_read_unlock()
does not permit the grace period to complete.
> However, you are correct that in the non-preempt tree RCU case,
> the compiler barrier in __rcu_read_lock was not always present.
> In fact it was added by:
>
> : commit 386afc91144b36b42117b0092893f15bc8798a80
> : Author: Linus Torvalds <torvalds@linux-foundation.org>
> : Date: Tue Apr 9 10:48:33 2013 -0700
> :
> : spinlocks and preemption points need to be at least compiler barriers
>
> I suspect this is what prompted you to remove it in 2015.
If I remember correctly, it was pointed out to me that in !PREEMPT kernels,
the compiler barrier in the preempt_disable() invoked in rcu_read_lock()
(and similar on the rcu_read_unlock() side) wasn't helping anything,
> > I do not believe that reverting that patch will help you at all.
> >
> > But who knows? So please point me at the full code body that was being
> > debated earlier on this thread. It will no doubt take me quite a while to
> > dig through it, given my being on the road for the next couple of weeks,
> > but so it goes.
>
> Please refer to my response to Linus for the code in question.
>
> In any case, I am now even more certain that compiler barriers are
> not needed in the code in question. The reasoning is quite simple.
> If you need those compiler barriers then you surely need real memory
> barriers.
OK, we are in agreement on that point, then!
> Vice versa, if real memory barriers are already present thanks to
> RCU, then you don't need those compiler barriers.
For users of RCU, this seems reasonable.
On the other hand, the compiler barriers in PREEMPT Tree RCU's outermost
__rcu_read_lock() and __rcu_read_unlock() invocations really are needed
by RCU internals. This is because RCU uses of interrupt handlers that
access per-task and per-CPU variables, and these need to be able to
sense the edges of the nested set of RCU read-side critical sections.
It is OK for these interrupt handlers to think that the critical section
is larger than it really is, but fatal for them to think that the critical
sections are smaller than they really are.
> In fact this calls into question the use of READ_ONCE/WRITE_ONCE in
> RCU primitives such as rcu_dereference and rcu_assign_pointer.
No, these are -not- called into question, or if they are, the question
gets quickly answered it a way that supports current Linux-kernel code.
As mentioned in earlier emails, the traditional uses of RCU that involve
rcu_dereference(), rcu_assign_pointer(), and synchronize_rcu() all work
just fine.
In fact, from what I can see, the issue stems from having developed
intuitions from working with the traditional rcu_dereference(),
rcu_assign_pointer(), and synchronize_rcu() linked-structure use cases,
and then attempting to apply these intuition to use cases that have
neither rcu_dereference() nor rcu_assign_pointer(). Don't get me wrong,
it is only natural to try to extend your intuitions to something that
admittedly looks pretty similar to the traditional use cases. But this
is one of those cases where "pretty similar" might not be good enough.
> IIRC
> when RCU was first added to the Linux kernel we did not have compiler
> barriers in rcu_dereference and rcu_assign_pointer. They were added
> later on.
From what I can see, rcu_dereference() still does not have a compiler
barrier. Please note that the pair of barrier() calls in READ_ONCE()
only apply when READ_ONCE()ing something larger than the machine can load.
And if your platform cannot load and store pointers with a single access,
the Linux kernel isn't going to do very well regardless. Ditto for
WRITE_ONCE().
> As compiler barriers per se are useless, these are surely meant to
> be coupled with the memory barriers provided by RCU grace periods
> and synchronize_rcu. But then those real memory barriers would have
> compiler barriers too. So why do we need the compiler barriers in
> rcu_dereference and rcu_assign_pointer?
In rcu_dereference(), RCU does not need them. They are instead
inherited from READ_ONCE() for when it is used on a data structure too
big for any single load instruction available on the system in question.
These barrier() calls are in a case that rcu_dereference() had better
not be using -- after all, using them would mean that the hardware didn't
have a load instruction big enough to handle a pointer.
In rcu_assign_pointer(), RCU just needs this to act like a release
store, that is, the store itself must not be reordered with any earlier
memory accesses. The Linux kernel's smp_store_release() currently
over-approximates this using a barrier() or equivalent inline-assembly
directive, which enforces compiler ordering for not only the release
store, but also far all memory accesses following the release store.
Obviously, barrier is not enough for weakly ordered systems, which
must also emit an appropriate memory-barrier instruction (or a special
load instruction for architectures like ARMv8 providing such a thing).
The compiler barriers in __rcu_read_lock() and __rcu_read_unlock() are
there so that preemptible Tree RCU can use its various tricks to make
readers perform and scale well. Read-side state is confined to the CPU
and/or task in the common case, thus avoiding heavy synchronization
overhead in the common case (or, in the case of !PREEMPT RCU, thus
avoiding -any- synchronization overhead in the common case). For example,
the compiler barriers ensure that RCU's scheduler-clock code and softirq
code can trust per-CPU/task state indicating whether or not there is an
RCU read-side critical section in effect.
Does that help? Or am I missing your point?
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 3:03 ` Herbert Xu
2019-06-03 9:27 ` Paul E. McKenney
@ 2019-06-03 15:55 ` Linus Torvalds
2019-06-03 16:07 ` Linus Torvalds
1 sibling, 1 reply; 62+ messages in thread
From: Linus Torvalds @ 2019-06-03 15:55 UTC (permalink / raw)
To: Herbert Xu
Cc: Paul E. McKenney, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Sun, Jun 2, 2019 at 8:03 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> In any case, I am now even more certain that compiler barriers are
> not needed in the code in question. The reasoning is quite simple.
> If you need those compiler barriers then you surely need real memory
> barriers.
So the above statement is not necessarily correct.
Compiler barriers very much can have real effects even in the absense
of "real" memory barriers.
But those effects are obviously not about multiple CPU's - they are
about code generation and can be about ordering on _one_ CPU. Those
effects definitely happen, though.
So a compiler barrier without a memory barrier may make a difference if you
(a) compile for UP (when a compiler barrier basically _is_ a memory barrier)
(b) have deadlock or ordering avoidance with only the local CPU
taking interrupts.
(c) need to re-load a value in a loop, but ordering isn't a concern
and possibly other situations.
In the above, (a) may be pointless and trivial, but (b) and (c) are
issues even on SMP. Some things only matter for the local CPU - an
interrupt or a code sequence that happens on another CPU can just
block, but if an interrupt comes in on the same CPU may dead-lock and
depend on particular access ordering. And (c) is for things like
cpu_relax() in loops that read stuff (although honestly, READ_ONCE()
is generally a much better pattern).
But it sounds like in this case at least, Herbert's and Paul's
disagreements aren't really all that fundamentally about the memory
barriers and locking, as just the fact that in general the only thing
that RCU protects against is single accesses, and thus any RCU region
technically should use something that guarantees that the compiler
might not do stupid things.
We do require a _minimum_ of compiler sanity, but the compiler turning
a non-marked read into two reads has definitely happened, and can be
very subtle. Even if on a C level it looks like a single access, and
correctness doesn't care about _what_ the value we read is, it might
be turned by the compiler into two separate accesses that get two
different values, and then the end result may be insane and
unreliable.
So on the whole, I do think that it's usually a good idea to show
_which_ access is protected by RCU. Perhaps with a
READ_ONCE/WRITE_ONCE pattern, although it can be other things.
I don't believe that it would necessarily help to turn a
rcu_read_lock() into a compiler barrier, because for the non-preempt
case rcu_read_lock() doesn't need to actually _do_ anything, and
anything that matters for the RCU read lock will already be a compiler
barrier for other reasons (ie a function call that can schedule).
Anyway, I suspect the code is correct in practice, but I do have some
sympathy for the "RCU protected accesses should be marked".
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 15:55 ` Linus Torvalds
@ 2019-06-03 16:07 ` Linus Torvalds
2019-06-03 19:53 ` Paul E. McKenney
0 siblings, 1 reply; 62+ messages in thread
From: Linus Torvalds @ 2019-06-03 16:07 UTC (permalink / raw)
To: Herbert Xu
Cc: Paul E. McKenney, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Mon, Jun 3, 2019 at 8:55 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I don't believe that it would necessarily help to turn a
> rcu_read_lock() into a compiler barrier, because for the non-preempt
> case rcu_read_lock() doesn't need to actually _do_ anything, and
> anything that matters for the RCU read lock will already be a compiler
> barrier for other reasons (ie a function call that can schedule).
Actually, thinking a bit more about this, and trying to come up with
special cases, I'm not at all convinced.
Even if we don't have preemption enabled, it turns out that we *do*
have things that can cause scheduling without being compiler barriers.
In particular, user accesses are not necessarily full compiler
barriers. One common pattern (x86) is
asm volatile("call __get_user_%P4"
which explicitly has a "asm volaile" so that it doesn't re-order wrt
other asms (and thus other user accesses), but it does *not* have a
"memory" clobber, because the user access doesn't actually change
kernel memory. Not even if it's a "put_user()".
So we've made those fairly relaxed on purpose. And they might be
relaxed enough that they'd allow re-ordering wrt something that does a
rcu read lock, unless the rcu read lock has some compiler barrier in
it.
IOW, imagine completely made up code like
get_user(val, ptr)
rcu_read_lock();
WRITE_ONCE(state, 1);
and unless the rcu lock has a barrier in it, I actually think that
write to 'state' could migrate to *before* the get_user().
I'm not convinced we have anything that remotely looks like the above,
but I'm actually starting to think that yes, all RCU barriers had
better be compiler barriers.
Because this is very much an example of something where you don't
necessarily need a memory barrier, but there's a code generation
barrier needed because of local ordering requirements. The possible
faulting behavior of "get_user()" must not migrate into the RCU
critical region.
Paul?
So I think the rule really should be: every single form of locking
that has any semantic meaning at all, absolutely needs to be at least
a compiler barrier.
(That "any semantic meaning" weaselwording is because I suspect that
we have locking that truly and intentionally becomes no-ops because
it's based on things that aren't relevant in some configurations. But
generally compiler barriers are really pretty damn cheap, even from a
code generation standpoint, and can help make the resulting code more
legible, so I think we should not try to aggressively remove them
without _very_ good reasons)
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 16:07 ` Linus Torvalds
@ 2019-06-03 19:53 ` Paul E. McKenney
2019-06-03 20:24 ` Linus Torvalds
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-03 19:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Herbert Xu, Frederic Weisbecker, Boqun Feng, Fengguang Wu, LKP,
LKML, Netdev, David S. Miller
On Mon, Jun 03, 2019 at 09:07:29AM -0700, Linus Torvalds wrote:
> On Mon, Jun 3, 2019 at 8:55 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > I don't believe that it would necessarily help to turn a
> > rcu_read_lock() into a compiler barrier, because for the non-preempt
> > case rcu_read_lock() doesn't need to actually _do_ anything, and
> > anything that matters for the RCU read lock will already be a compiler
> > barrier for other reasons (ie a function call that can schedule).
>
> Actually, thinking a bit more about this, and trying to come up with
> special cases, I'm not at all convinced.
>
> Even if we don't have preemption enabled, it turns out that we *do*
> have things that can cause scheduling without being compiler barriers.
>
> In particular, user accesses are not necessarily full compiler
> barriers. One common pattern (x86) is
>
> asm volatile("call __get_user_%P4"
>
> which explicitly has a "asm volaile" so that it doesn't re-order wrt
> other asms (and thus other user accesses), but it does *not* have a
> "memory" clobber, because the user access doesn't actually change
> kernel memory. Not even if it's a "put_user()".
>
> So we've made those fairly relaxed on purpose. And they might be
> relaxed enough that they'd allow re-ordering wrt something that does a
> rcu read lock, unless the rcu read lock has some compiler barrier in
> it.
>
> IOW, imagine completely made up code like
>
> get_user(val, ptr)
> rcu_read_lock();
> WRITE_ONCE(state, 1);
>
> and unless the rcu lock has a barrier in it, I actually think that
> write to 'state' could migrate to *before* the get_user().
>
> I'm not convinced we have anything that remotely looks like the above,
> but I'm actually starting to think that yes, all RCU barriers had
> better be compiler barriers.
>
> Because this is very much an example of something where you don't
> necessarily need a memory barrier, but there's a code generation
> barrier needed because of local ordering requirements. The possible
> faulting behavior of "get_user()" must not migrate into the RCU
> critical region.
>
> Paul?
I agree that !PREEMPT rcu_read_lock() would not affect compiler code
generation, but given that get_user() is a volatile asm, isn't the
compiler already forbidden from reordering it with the volatile-casted
WRITE_ONCE() access, even if there was nothing at all between them?
Or are asms an exception to the rule that volatile executions cannot
be reordered?
> So I think the rule really should be: every single form of locking
> that has any semantic meaning at all, absolutely needs to be at least
> a compiler barrier.
>
> (That "any semantic meaning" weaselwording is because I suspect that
> we have locking that truly and intentionally becomes no-ops because
> it's based on things that aren't relevant in some configurations. But
> generally compiler barriers are really pretty damn cheap, even from a
> code generation standpoint, and can help make the resulting code more
> legible, so I think we should not try to aggressively remove them
> without _very_ good reasons)
We can of course put them back in, but this won't help in the typical
rcu_assign_pointer(), rcu_dereference(), and synchronize_rcu() situation
(nor do I see how it helps in Hubert's example). And in other RCU
use cases, the accesses analogous to the rcu_assign_pointer() and
rcu_dereference() (in Hubert's example, the accesses to variable "a")
really need to be READ_ONCE()/WRITE_ONCE() or stronger, correct?
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 19:53 ` Paul E. McKenney
@ 2019-06-03 20:24 ` Linus Torvalds
2019-06-04 21:14 ` Paul E. McKenney
0 siblings, 1 reply; 62+ messages in thread
From: Linus Torvalds @ 2019-06-03 20:24 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Herbert Xu, Frederic Weisbecker, Boqun Feng, Fengguang Wu, LKP,
LKML, Netdev, David S. Miller
On Mon, Jun 3, 2019 at 12:53 PM Paul E. McKenney <paulmck@linux.ibm.com> wrote:
>
> I agree that !PREEMPT rcu_read_lock() would not affect compiler code
> generation, but given that get_user() is a volatile asm, isn't the
> compiler already forbidden from reordering it with the volatile-casted
> WRITE_ONCE() access, even if there was nothing at all between them?
> Or are asms an exception to the rule that volatile executions cannot
> be reordered?
Paul, you MAKE NO SENSE.
What is wrong with you?
I just showed you an example of where rcu_read_lock() needs to be a
compiler barrier, and then you make incoherent noises about
WRITE_ONCE() that do not even exist in that example.
Forget about your READ_ONCE/WRITE_ONCE theories. Herbert already
showed code that doesn't have those accessors, so reality doesn't
match your fevered imagination.
And sometimes it's not even possible, since you can't do a bitfield
access, for exmaple, with READ_ONCE().
> We can of course put them back in,
Stop the craziness. It's not "we can". It is a "we will".
So I will add that barrier, and you need to stop arguing against it
based on specious theoretical arguments that do not match reality. And
we will not ever remove that barrier again. Herbert already pointed to
me having to do this once before in commit 386afc91144b ("spinlocks
and preemption points need to be at least compiler barriers"), and
rcu_read_lock() clearly has at a minimum that same preemption point
issue.
Linus
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-03 20:24 ` Linus Torvalds
@ 2019-06-04 21:14 ` Paul E. McKenney
2019-06-05 2:21 ` Herbert Xu
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-04 21:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: Herbert Xu, Frederic Weisbecker, Boqun Feng, Fengguang Wu, LKP,
LKML, Netdev, David S. Miller
On Mon, Jun 03, 2019 at 01:24:32PM -0700, Linus Torvalds wrote:
> On Mon, Jun 3, 2019 at 12:53 PM Paul E. McKenney <paulmck@linux.ibm.com> wrote:
> >
> > I agree that !PREEMPT rcu_read_lock() would not affect compiler code
> > generation, but given that get_user() is a volatile asm, isn't the
> > compiler already forbidden from reordering it with the volatile-casted
> > WRITE_ONCE() access, even if there was nothing at all between them?
> > Or are asms an exception to the rule that volatile executions cannot
> > be reordered?
>
> Paul, you MAKE NO SENSE.
>
> What is wrong with you?
Mostly that I didn't check all architectures' definitions of get_user().
Had I done so, I would have seen that not all of the corresponding asms
have the "volatile" keyword. And of course, without that keyword, there
is absolutely nothing preventing the compiler from reordering the asm
with pretty much anything. The only things that would be absolutely
guaranteed to prevent reordering would be things like memory clobbers
(barrier()) or accesses that overlap the asm's input/output list.
Yeah, I know, even with the "volatile" keyword, it is not entirely clear
how much reordering the compiler is allowed to do. I was relying on
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html, which says:
Qualifiers
volatile
The typical use of extended asm statements is to
manipulate input values to produce output values. However,
your asm statements may also produce side effects. If so,
you may need to use the volatile qualifier to disable
certain optimizations. See Volatile.
But the linked-to "Volatile" section later in that same web page mostly
talks about the compiler's ability to hoist asms out of loops.
> I just showed you an example of where rcu_read_lock() needs to be a
> compiler barrier, and then you make incoherent noises about
> WRITE_ONCE() that do not even exist in that example.
I thought we were discussing this example, but it doesn't matter because
I was missing your point about get_user() and page faults:
get_user(val, ptr)
rcu_read_lock();
WRITE_ONCE(state, 1);
But regardless, given that some architectures omit volatile from their
asms implementing get_user(), even an optimistic interpretation of that
part of the GCC documentation would still permit reordering the above.
And again, I was missing your point about get_user() causing page faults
and thus context switches.
> Forget about your READ_ONCE/WRITE_ONCE theories. Herbert already
> showed code that doesn't have those accessors, so reality doesn't
> match your fevered imagination.
I get the feeling that you believe that I want LKMM to be some sort of
final judge and absolute arbiter of what code is legal and not from
a memory-ordering perspective. This is absolutely -not- the case.
The current state of the art, despite the recent impressive progress,
simply cannot reasonably do this. So all I can claim is that LKMM
dispenses advice, hopefully good advice. (It is early days for LKMM's
handling of plain accesses, so some work might be required to deliver
on the "good advice" promise, but we have to start somewhere. Plus it
is progressing nicely.)
The places where long-standing RCU patterns require rcu_dereference()
and rcu_assign_pointer() do require some attention to avoid compiler
optimizations, and {READ,WRITE}_ONCE() is one way of addressing this.
But not the only way, nor always the best way. For example, some
fastpaths might need the optimizations that {READ,WRITE}_ONCE()
suppresses. Therefore, Linux kernel hackers have a number of other
ways of paying attention. For example, accesses might be constrained
via barrier() and friends. For another example, some developers might
check assembly output (hopefully scripted somehow).
Again, the Linux-kernel memory model dispenses advice, not absolutes.
Furthermore, the way it dispenses advice is currently a bit limited.
It can currently say that it is nervous about lack of {READ,WRITE}_ONCE(),
as in "Flag data-race", but it would be difficult to make it recommend
the other options in an intelligent way. So we should interpret "Flag
data-race" as LKMM saying "I am nervous about your unmarked accesses"
rather than "You absolutely must call {READ,WRITE}_ONCE() more often!!!"
Again, advice, not absolutes.
So the idea is that you add and remove {READ,WRITE}_ONCE() to/from the
-litmus- -tests- to determine which accesses LKMM is nervous about.
But that doesn't necessarily mean that {READ,WRITE}_ONCE() goes into
the corresponding places in the Linux kernel.
Does that help, or am I still confused?
> And sometimes it's not even possible, since you can't do a bitfield
> access, for example, with READ_ONCE().
Ah, good point. So the Linux kernel uses bitfields to communicate
between mainline and interrupt handlers. New one on me. :-/
> > We can of course put them back in,
>
> Stop the craziness. It's not "we can". It is a "we will".
>
> So I will add that barrier, and you need to stop arguing against it
> based on specious theoretical arguments that do not match reality. And
> we will not ever remove that barrier again. Herbert already pointed to
> me having to do this once before in commit 386afc91144b ("spinlocks
> and preemption points need to be at least compiler barriers"), and
> rcu_read_lock() clearly has at a minimum that same preemption point
> issue.
And the lack of "volatile" allows get_user() to migrate page faults
(and thus context switches) into RCU read-side critical sections
in CONFIG_PREEMPT=n. Yes, this would be very bad.
OK, I finally got it, so please accept my apologies for my earlier
confusion.
I don't yet see a commit from you, so I queued the one below locally
and started testing.
Thanx, Paul
------------------------------------------------------------------------
commit 9b4766c5523efb8d3d52b2ba2a29fd69cdfc65bb
Author: Paul E. McKenney <paulmck@linux.ibm.com>
Date: Tue Jun 4 14:05:52 2019 -0700
rcu: Restore barrier() to rcu_read_lock() and rcu_read_unlock()
Commit bb73c52bad36 ("rcu: Don't disable preemption for Tiny and Tree
RCU readers") removed the barrier() calls from rcu_read_lock() and
rcu_write_lock() in CONFIG_PREEMPT=n&&CONFIG_PREEMPT_COUNT=n kernels.
Within RCU, this commit was OK, but it failed to account for things like
get_user() that can pagefault and that can be reordered by the compiler.
Lack of the barrier() calls in rcu_read_lock() and rcu_read_unlock()
can cause these page faults to migrate into RCU read-side critical
sections, which in CONFIG_PREEMPT=n kernels could result in too-short
grace periods and arbitrary misbehavior. Please see commit 386afc91144b
("spinlocks and preemption points need to be at least compiler barriers")
for more details.
This commit therefore restores the barrier() call to both rcu_read_lock()
and rcu_read_unlock(). It also removes them from places in the RCU update
machinery that used to need compensatory barrier() calls, effectively
reverting commit bb73c52bad36 ("rcu: Don't disable preemption for Tiny
and Tree RCU readers").
Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 0c9b92799abc..8f7167478c1d 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -56,14 +56,12 @@ void __rcu_read_unlock(void);
static inline void __rcu_read_lock(void)
{
- if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
- preempt_disable();
+ preempt_disable();
}
static inline void __rcu_read_unlock(void)
{
- if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
- preempt_enable();
+ preempt_enable();
}
static inline int rcu_preempt_depth(void)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 3f52d8438e0f..841060fce33c 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -288,7 +288,6 @@ void rcu_note_context_switch(bool preempt)
struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
struct rcu_node *rnp;
- barrier(); /* Avoid RCU read-side critical sections leaking down. */
trace_rcu_utilization(TPS("Start context switch"));
lockdep_assert_irqs_disabled();
WARN_ON_ONCE(!preempt && t->rcu_read_lock_nesting > 0);
@@ -340,7 +339,6 @@ void rcu_note_context_switch(bool preempt)
if (rdp->exp_deferred_qs)
rcu_report_exp_rdp(rdp);
trace_rcu_utilization(TPS("End context switch"));
- barrier(); /* Avoid RCU read-side critical sections leaking up. */
}
EXPORT_SYMBOL_GPL(rcu_note_context_switch);
@@ -828,11 +826,6 @@ static void rcu_qs(void)
* dyntick-idle quiescent state visible to other CPUs, which will in
* some cases serve for expedited as well as normal grace periods.
* Either way, register a lightweight quiescent state.
- *
- * The barrier() calls are redundant in the common case when this is
- * called externally, but just in case this is called from within this
- * file.
- *
*/
void rcu_all_qs(void)
{
@@ -847,14 +840,12 @@ void rcu_all_qs(void)
return;
}
this_cpu_write(rcu_data.rcu_urgent_qs, false);
- barrier(); /* Avoid RCU read-side critical sections leaking down. */
if (unlikely(raw_cpu_read(rcu_data.rcu_need_heavy_qs))) {
local_irq_save(flags);
rcu_momentary_dyntick_idle();
local_irq_restore(flags);
}
rcu_qs();
- barrier(); /* Avoid RCU read-side critical sections leaking up. */
preempt_enable();
}
EXPORT_SYMBOL_GPL(rcu_all_qs);
@@ -864,7 +855,6 @@ EXPORT_SYMBOL_GPL(rcu_all_qs);
*/
void rcu_note_context_switch(bool preempt)
{
- barrier(); /* Avoid RCU read-side critical sections leaking down. */
trace_rcu_utilization(TPS("Start context switch"));
rcu_qs();
/* Load rcu_urgent_qs before other flags. */
@@ -877,7 +867,6 @@ void rcu_note_context_switch(bool preempt)
rcu_tasks_qs(current);
out:
trace_rcu_utilization(TPS("End context switch"));
- barrier(); /* Avoid RCU read-side critical sections leaking up. */
}
EXPORT_SYMBOL_GPL(rcu_note_context_switch);
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: rcu_read_lock lost its compiler barrier
2019-06-04 21:14 ` Paul E. McKenney
@ 2019-06-05 2:21 ` Herbert Xu
2019-06-05 3:30 ` Paul E. McKenney
0 siblings, 1 reply; 62+ messages in thread
From: Herbert Xu @ 2019-06-05 2:21 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Tue, Jun 04, 2019 at 02:14:49PM -0700, Paul E. McKenney wrote:
>
> Yeah, I know, even with the "volatile" keyword, it is not entirely clear
> how much reordering the compiler is allowed to do. I was relying on
> https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html, which says:
The volatile keyword doesn't give any guarantees of this kind.
The key to ensuring ordering between unrelated variable/register
reads/writes is the memory clobber:
6.47.2.6 Clobbers and Scratch Registers
...
"memory" The "memory" clobber tells the compiler that the assembly
code performs memory reads or writes to items other than those
listed in the input and output operands (for example, accessing
the memory pointed to by one of the input parameters). To ensure
memory contains correct values, GCC may need to flush specific
register values to memory before executing the asm. Further,
the compiler does not assume that any values read from memory
before an asm remain unchanged after that asm; it reloads them as
needed. Using the "memory" clobber effectively forms a read/write
memory barrier for the compiler.
Note that this clobber does not prevent the processor from
doing speculative reads past the asm statement. To prevent that,
you need processor-specific fence instructions.
IOW you need a barrier().
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-05 2:21 ` Herbert Xu
@ 2019-06-05 3:30 ` Paul E. McKenney
2019-06-06 4:37 ` Herbert Xu
0 siblings, 1 reply; 62+ messages in thread
From: Paul E. McKenney @ 2019-06-05 3:30 UTC (permalink / raw)
To: Herbert Xu
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Wed, Jun 05, 2019 at 10:21:17AM +0800, Herbert Xu wrote:
> On Tue, Jun 04, 2019 at 02:14:49PM -0700, Paul E. McKenney wrote:
> >
> > Yeah, I know, even with the "volatile" keyword, it is not entirely clear
> > how much reordering the compiler is allowed to do. I was relying on
> > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html, which says:
>
> The volatile keyword doesn't give any guarantees of this kind.
> The key to ensuring ordering between unrelated variable/register
> reads/writes is the memory clobber:
>
> 6.47.2.6 Clobbers and Scratch Registers
>
> ...
>
> "memory" The "memory" clobber tells the compiler that the assembly
> code performs memory reads or writes to items other than those
> listed in the input and output operands (for example, accessing
> the memory pointed to by one of the input parameters). To ensure
> memory contains correct values, GCC may need to flush specific
> register values to memory before executing the asm. Further,
> the compiler does not assume that any values read from memory
> before an asm remain unchanged after that asm; it reloads them as
> needed. Using the "memory" clobber effectively forms a read/write
> memory barrier for the compiler.
>
> Note that this clobber does not prevent the processor from
> doing speculative reads past the asm statement. To prevent that,
> you need processor-specific fence instructions.
>
> IOW you need a barrier().
Understood. Does the patch I sent out a few hours ago cover it? Or is
something else needed?
Other than updates to the RCU requirements documentation, which is
forthcoming.
Thanx, Paul
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: rcu_read_lock lost its compiler barrier
2019-06-05 3:30 ` Paul E. McKenney
@ 2019-06-06 4:37 ` Herbert Xu
0 siblings, 0 replies; 62+ messages in thread
From: Herbert Xu @ 2019-06-06 4:37 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Linus Torvalds, Frederic Weisbecker, Boqun Feng, Fengguang Wu,
LKP, LKML, Netdev, David S. Miller
On Tue, Jun 04, 2019 at 08:30:39PM -0700, Paul E. McKenney wrote:
>
> Understood. Does the patch I sent out a few hours ago cover it? Or is
> something else needed?
It looks good to me.
> Other than updates to the RCU requirements documentation, which is
> forthcoming.
Thanks Paul.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 62+ messages in thread
end of thread, other threads:[~2019-06-08 18:51 UTC | newest]
Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-10 0:57 [rcu] kernel BUG at include/linux/pagemap.h:149! Fengguang Wu
2015-09-10 10:25 ` Boqun Feng
2015-09-10 17:16 ` Paul E. McKenney
2015-09-11 2:19 ` Boqun Feng
[not found] ` <CAJzB8QG=1iZW3dQEie6ZSTLv8GZ3YSut0aL1VU7LLmiHQ1B1DQ@mail.gmail.com>
2015-09-11 21:59 ` Paul E. McKenney
2015-09-12 5:46 ` Boqun Feng
2015-09-21 19:30 ` Frederic Weisbecker
2015-09-21 20:43 ` Paul E. McKenney
2019-06-02 5:56 ` rcu_read_lock lost its compiler barrier Herbert Xu
2019-06-02 20:54 ` Linus Torvalds
2019-06-03 2:46 ` Herbert Xu
2019-06-03 3:47 ` Paul E. McKenney
2019-06-03 4:01 ` Herbert Xu
2019-06-03 4:17 ` Herbert Xu
2019-06-03 7:23 ` Paul E. McKenney
2019-06-03 8:42 ` Paul E. McKenney
2019-06-03 15:26 ` David Laight
2019-06-03 15:40 ` Linus Torvalds
2019-06-03 5:26 ` Herbert Xu
2019-06-03 6:42 ` Boqun Feng
2019-06-03 20:03 ` Paul E. McKenney
2019-06-04 14:44 ` Alan Stern
2019-06-04 16:04 ` Linus Torvalds
2019-06-04 17:00 ` Alan Stern
2019-06-04 17:29 ` Linus Torvalds
2019-06-07 14:09 ` inet: frags: Turn fqdir->dead into an int for old Alphas Herbert Xu
2019-06-07 15:26 ` Eric Dumazet
2019-06-07 15:32 ` Herbert Xu
2019-06-07 16:13 ` Eric Dumazet
2019-06-07 16:19 ` Linus Torvalds
2019-06-08 15:27 ` Paul E. McKenney
2019-06-08 17:42 ` Linus Torvalds
2019-06-08 17:50 ` Linus Torvalds
2019-06-08 18:50 ` Paul E. McKenney
2019-06-08 18:14 ` Paul E. McKenney
2019-06-06 4:51 ` rcu_read_lock lost its compiler barrier Herbert Xu
2019-06-06 6:05 ` Paul E. McKenney
2019-06-06 6:14 ` Herbert Xu
2019-06-06 9:06 ` Paul E. McKenney
2019-06-06 9:28 ` Herbert Xu
2019-06-06 10:58 ` Paul E. McKenney
2019-06-06 13:38 ` Herbert Xu
2019-06-06 13:48 ` Paul E. McKenney
2019-06-06 8:16 ` Andrea Parri
2019-06-06 14:19 ` Alan Stern
2019-06-08 15:19 ` Paul E. McKenney
2019-06-08 15:56 ` Alan Stern
2019-06-08 16:31 ` Paul E. McKenney
2019-06-03 9:35 ` Paul E. McKenney
2019-06-06 8:38 ` Andrea Parri
2019-06-06 9:32 ` Herbert Xu
2019-06-03 0:06 ` Paul E. McKenney
2019-06-03 3:03 ` Herbert Xu
2019-06-03 9:27 ` Paul E. McKenney
2019-06-03 15:55 ` Linus Torvalds
2019-06-03 16:07 ` Linus Torvalds
2019-06-03 19:53 ` Paul E. McKenney
2019-06-03 20:24 ` Linus Torvalds
2019-06-04 21:14 ` Paul E. McKenney
2019-06-05 2:21 ` Herbert Xu
2019-06-05 3:30 ` Paul E. McKenney
2019-06-06 4:37 ` Herbert Xu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).