[lkp-robot] de8a3b1249 [ 109.999929] WARNING: CPU: 0 PID: 10066 at kernel/rcu/tree_plugin.h:508 rcu_read_unlock_special
by kernel test robot
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 rcu/dev
commit de8a3b1249d6d6eb910e271dc0d18bafd032172d
Author: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
AuthorDate: Tue Jul 11 21:52:31 2017 -0700
Commit: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
CommitDate: Tue Jul 11 21:52:31 2017 -0700
rcu: Add assertions verifying blocked-tasks list
This commit adds assertions verifying the consistency of the rcu_node
structure's ->blkd_tasks list and its ->gp_tasks, ->exp_tasks, and
->boost_tasks pointers. In particular, the ->blkd_tasks lists must be
empty except for leaf rcu_node structures.
Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
a3755ad263 doc: No longer allowed to use rcu_dereference on non-pointers
de8a3b1249 rcu: Add assertions verifying blocked-tasks list
50e2757ccb fixup! rcu: Add assertions verifying blocked-tasks list
+--------------------------------------------------------------+------------+------------+------------+
| | a3755ad263 | de8a3b1249 | 50e2757ccb |
+--------------------------------------------------------------+------------+------------+------------+
| boot_successes | 6 | 6 | 1 |
| boot_failures | 44 | 10 | 10 |
| is_trying_to_release_lock(rcu_preempt_state)at | 44 | 10 | 10 |
| WARNING:at_kernel/rcu/tree_plugin.h:#rcu_read_unlock_special | 0 | 10 | 10 |
| EIP:rcu_read_unlock_special | 0 | 10 | 10 |
+--------------------------------------------------------------+------------+------------+------------+
[ 62.433128] rcu-torture: Reader Pipe: 2 0 0 0 0 0 0 0 0 0 0
[ 62.433503] rcu-torture: Reader Batch: 0 2 0 0 0 0 0 0 0 0 0
[ 62.433863] rcu-torture: Free-Block Circulation: 0 0 0 0 0 0 0 0 0 0 0
procd: - shutdown -
[ 109.999490] ------------[ cut here ]------------
[ 109.999929] WARNING: CPU: 0 PID: 10066 at kernel/rcu/tree_plugin.h:508 rcu_read_unlock_special+0x240/0x2f0
[ 110.000909] Modules linked in:
[ 110.001180] CPU: 0 PID: 10066 Comm: ubus Not tainted 4.12.0-02191-gde8a3b1 #1
[ 110.001788] task: cea64440 task.stack: ce88a000
[ 110.002177] EIP: rcu_read_unlock_special+0x240/0x2f0
[ 110.002608] EFLAGS: 00010086 CPU: 0
[ 110.002910] EAX: 00000000 EBX: cea64440 ECX: cea64440 EDX: 00000000
[ 110.003453] ESI: c1920e40 EDI: cea645fc EBP: ce88bd70 ESP: ce88bd54
[ 110.003973] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 110.004419] CR0: 80050033 CR2: 093402e0 CR3: 001f9000 CR4: 001406d0
[ 110.004941] DR0: 00000000 DR1: c0100220 DR2: 00000000 DR3: 00000000
[ 110.005474] DR6: fffe0ff0 DR7: 00000600
[ 110.005807] Call Trace:
[ 110.006029] __rcu_read_unlock+0x4f/0x60
[ 110.006372] sock_def_readable+0x9e/0xe0
[ 110.006719] unix_stream_sendmsg+0x1ba/0x350
[ 110.007094] ___sys_sendmsg+0x245/0x260
[ 110.007434] ? kvm_clock_read+0x21/0x40
[ 110.007772] ? kvm_sched_clock_read+0x9/0x20
[ 110.008143] ? kvm_clock_read+0x21/0x40
[ 110.008482] ? kvm_sched_clock_read+0x9/0x20
[ 110.008852] ? sched_clock+0x9/0x10
[ 110.009157] ? sched_clock_cpu+0x13/0x130
[ 110.009516] ? find_held_lock+0x2a/0x90
[ 110.009853] __sys_sendmsg+0x2d/0x60
[ 110.010168] SyS_socketcall+0x14c/0x610
[ 110.010509] do_int80_syscall_32+0x44/0xb0
[ 110.010863] entry_INT80_32+0x27/0x27
[ 110.011180] EIP: 0xb76fc595
[ 110.011423] EFLAGS: 00000292 CPU: 0
[ 110.011729] EAX: ffffffda EBX: 00000010 ECX: bfa0a838 EDX: b7741ff4
[ 110.012259] ESI: bfa0a838 EDI: bfa0a884 EBP: bfa0a8c8 ESP: bfa0a828
[ 110.012796] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 110.013260] Code: 84 5f fe ff ff e9 79 fe ff ff 90 0f ff eb c2 8b 46 3c 85 c0 0f 94 c0 89 c7 e9 5c ff ff ff 89 56 6c e9 4a ff ff ff 3b 7e 6c 74 f3 <0f> ff e9 3e ff ff ff 89 56 68 89 d0 e9 17 ff ff ff 89 56 64 e9
[ 110.014954] ---[ end trace 3e8b76b2bc990087 ]---
[ 110.015411]
# HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start 813d0f7c74d6dd0a3e65cc5bb347b50e58e3d597 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c --
git bisect bad dac7b62a1c7cd9c64df6872e8765f34b9550fd2b # 10:54 B 0 3 16 0 Merge 'linux-review/Arvind-Yadav/input-synaptics-rmi4-Constify-attribute_group-structures/20170706-111655' into devel-hourly-2017071222
git bisect good 04612072a0745b61ac767638ef1d90ac7c8d5d8a # 11:08 G 12 0 11 11 Merge 'linux-review/Arvind-Yadav/edac-i7core-constify-attribute_group-structures/20170704-170846' into devel-hourly-2017071222
git bisect bad b7f9844f0a1efcf60f3c5d0b07e26f4d526d0a0b # 11:20 B 2 10 0 0 Merge 'linux-review/sleepingzucchini-gmail-com/staging-ccree-fix-checkpatch-errors/20170710-064113' into devel-hourly-2017071222
git bisect good 1924fb78bd62b7b3d951c98ae9935aec409e332a # 11:32 G 12 0 7 8 Merge 'linux-review/Lee-Chun-Yi/acpi-handle-the-acpi-hotplug-schedule-error/20170703-010230' into devel-hourly-2017071222
git bisect good e26da16e0a77d9134723f2de44037c81f505eaee # 11:47 G 12 0 9 9 Merge 'linux-review/Lorenzo-Pieralisi/ARM-PCI-bios32-Fix-pcibios_init_resource-error-return-path/20170711-023118' into devel-hourly-2017071222
git bisect bad 65183fe884d687a732c03ea61bf28533d769d402 # 12:00 B 2 10 1 1 Merge 'linux-review/Michal-Suchanek/powerpc-mm-hash-Remove-stale-comment/20170712-010349' into devel-hourly-2017071222
git bisect good 16456a468855a6573aa334518f9e37d1e0f51866 # 12:13 G 12 0 11 11 Merge 'linux-review/Pierre-Kuo/printk-Modify-operators-of-printed_len/20170709-022019' into devel-hourly-2017071222
git bisect good 2d235721ab339895b9687be2491f7cb0d3f99314 # 12:27 G 12 0 11 11 Merge 'linux-review/Lynn-Lei/staging-sm750fb-refactor-method-and-fix-potential-type-inconsistence/20170705-041135' into devel-hourly-2017071222
git bisect good da880bfcfcadd73b7ba9b1f2b1860cd00cf0e83c # 12:37 G 11 0 10 11 Merge 'linux-review/Arnd-Bergmann/PM-Domains-provide-pm_genpd_poweroff_noirq-stub/20170703-085344' into devel-hourly-2017071222
git bisect bad 7ec11f7dab05234d22b172ff25aa1c0086c16269 # 12:56 B 0 1 15 0 Merge 'rcu/rcu/dev' into devel-hourly-2017071222
git bisect good 11125b193be42e50b63321f64a136274620c28a4 # 13:06 G 12 0 11 11 srcu: Make process_srcu() be static
git bisect good 14e9b77655876ec8345734be6583e1670453c06a # 13:15 G 12 0 10 10 rcu: Eliminate rcu_state ->orphan_lock
git bisect good 40d747c2be778c3274578d9338c594526ecb4e96 # 13:24 G 12 0 9 9 rcu/tracing: Set disable_rcu_irq_enter on rcu_eqs_exit()
git bisect good 6908be10136f496bef67b8495e618388c8a2d9a2 # 13:34 G 12 0 12 12 srcu: Provide ordering for CPU not involved in grace period
git bisect bad de8a3b1249d6d6eb910e271dc0d18bafd032172d # 13:44 B 2 3 0 0 rcu: Add assertions verifying blocked-tasks list
git bisect good a3755ad263641d66458ff645741ba5fc8554163c # 13:55 G 12 0 11 11 doc: No longer allowed to use rcu_dereference on non-pointers
# first bad commit: [de8a3b1249d6d6eb910e271dc0d18bafd032172d] rcu: Add assertions verifying blocked-tasks list
git bisect good a3755ad263641d66458ff645741ba5fc8554163c # 13:59 G 36 0 34 45 doc: No longer allowed to use rcu_dereference on non-pointers
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect bad de8a3b1249d6d6eb910e271dc0d18bafd032172d # 14:08 B 1 11 0 0 rcu: Add assertions verifying blocked-tasks list
# extra tests on HEAD of linux-devel/devel-hourly-2017071222
git bisect bad 813d0f7c74d6dd0a3e65cc5bb347b50e58e3d597 # 14:08 B 2 12 0 1 0day head guard for 'devel-hourly-2017071222'
# extra tests on tree/branch rcu/rcu/dev
git bisect bad 50e2757ccb19023b4837b190f837478ebf57785c # 14:21 B 2 10 1 1 fixup! rcu: Add assertions verifying blocked-tasks list
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
4 years, 2 months
[USB] f16443a034: EIP:arch_local_irq_restore
by kernel test robot
FYI, we noticed the following commit:
commit: f16443a034c7aa359ddf6f0f9bc40d01ca31faea ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -m 420M
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+-----------------------------------------+------------+------------+
| | d2f48f05cd | f16443a034 |
+-----------------------------------------+------------+------------+
| boot_successes | 53 | 0 |
| boot_failures | 1 | 58 |
| INFO:task_blocked_for_more_than#seconds | 1 | |
| calltrace:rtnl_lock | 1 | |
| calltrace:debug_show_all_locks | 1 | |
| BUG:kernel_hang_in_test_stage | 1 | |
| EIP:arch_local_irq_restore | 0 | 34 |
| EIP:ftrace_likely_update | 0 | 5 |
| EIP:__rb_reserve_next | 0 | 3 |
| EIP:native_safe_halt | 0 | 5 |
| EIP:arch_local_irq_enable | 0 | 1 |
| EIP:ring_buffer_unlock_commit | 0 | 1 |
| EIP:ring_buffer_lock_reserve | 0 | 3 |
| EIP:rb_calculate_event_length | 0 | 2 |
| EIP:rb_commit | 0 | 2 |
| EIP:paravirt_sched_clock | 0 | 1 |
| EIP:ring_buffer_producer | 0 | 1 |
+-----------------------------------------+------------+------------+
[ 2.748828] kernel_init+0x8/0x150
[ 2.748828] kernel_init+0x8/0x150
[ 2.748830] ret_from_fork+0x19/0x24
[ 2.748830] ret_from_fork+0x19/0x24
[ 2.748830]
[ 2.748830] other info that might help us debug this:
[ 2.748830]
[ 2.748830]
[ 2.748830] other info that might help us debug this:
[ 2.748830]
[ 2.748837] Possible unsafe locking scenario:
[ 2.748837]
[ 2.748837] Possible unsafe locking scenario:
[ 2.748837]
[ 2.748839] CPU0 CPU1
[ 2.748839] CPU0 CPU1
[ 2.748840] ---- ----
[ 2.748840] ---- ----
[ 2.748840] lock(&(&cdev->lock)->rlock);
[ 2.748840] lock(&(&cdev->lock)->rlock);
[ 2.748843] lock(&(&dum_hcd->dum->lock)->rlock);
[ 2.748843] lock(&(&dum_hcd->dum->lock)->rlock);
[ 2.748845] lock(&(&cdev->lock)->rlock);
[ 2.748845] lock(&(&cdev->lock)->rlock);
[ 2.748848] lock(&(&dum_hcd->dum->lock)->rlock);
[ 2.748848] lock(&(&dum_hcd->dum->lock)->rlock);
[ 2.748850]
[ 2.748850] *** DEADLOCK ***
[ 2.748850]
[ 2.748850]
[ 2.748850] *** DEADLOCK ***
[ 2.748850]
[ 2.748852] 3 locks held by swapper/1:
[ 2.748852] 3 locks held by swapper/1:
[ 2.748853] #0: (console_lock){+.+...}, at: [<790d2ca8>] vprintk_emit+0x363/0x38e
[ 2.748853] #0: (console_lock){+.+...}, at: [<790d2ca8>] vprintk_emit+0x363/0x38e
[ 2.748859] #1: ((&dum_hcd->timer)){+.-...}, at: [<790ec25b>] call_timer_fn+0x0/0x38c
[ 2.748859] #1: ((&dum_hcd->timer)){+.-...}, at: [<790ec25b>] call_timer_fn+0x0/0x38c
[ 2.748865] #2: (&(&cdev->lock)->rlock){..-...}, at: [<799eab67>] composite_setup+0xaa9/0x1a55
[ 2.748865] #2: (&(&cdev->lock)->rlock){..-...}, at: [<799eab67>] composite_setup+0xaa9/0x1a55
[ 2.748871]
[ 2.748871] stack backtrace:
[ 2.748871]
[ 2.748871] stack backtrace:
[ 2.748874] CPU: 0 PID: 1 Comm: swapper Not tainted 4.12.0-rc5-00006-gf16443a #1
[ 2.748874] CPU: 0 PID: 1 Comm: swapper Not tainted 4.12.0-rc5-00006-gf16443a #1
[ 2.748876] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 2.748876] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 2.748878] Call Trace:
[ 2.748878] Call Trace:
[ 2.748879] <SOFTIRQ>
[ 2.748879] <SOFTIRQ>
[ 2.748882] ? show_stack+0x56/0x5e
[ 2.748882] ? show_stack+0x56/0x5e
[ 2.748886] dump_stack+0x16/0x18
[ 2.748886] dump_stack+0x16/0x18
[ 2.748889] print_circular_bug+0x18b/0x198
[ 2.748889] print_circular_bug+0x18b/0x198
[ 2.748892] validate_chain+0x668/0x829
[ 2.748892] validate_chain+0x668/0x829
[ 2.748895] ? ret_from_fork+0x19/0x24
[ 2.748895] ? ret_from_fork+0x19/0x24
[ 2.748897] ? mark_lock+0x1e/0x1cc
[ 2.748897] ? mark_lock+0x1e/0x1cc
[ 2.748900] __lock_acquire+0x543/0x5eb
[ 2.748900] __lock_acquire+0x543/0x5eb
[ 2.748902] lock_acquire+0xe1/0x157
[ 2.748902] lock_acquire+0xe1/0x157
[ 2.748905] ? dummy_queue+0xd6/0x1fb
[ 2.748905] ? dummy_queue+0xd6/0x1fb
[ 2.748907] _raw_spin_lock_irqsave+0x37/0x47
[ 2.748907] _raw_spin_lock_irqsave+0x37/0x47
[ 2.748910] ? dummy_queue+0xd6/0x1fb
[ 2.748910] ? dummy_queue+0xd6/0x1fb
[ 2.748911] dummy_queue+0xd6/0x1fb
[ 2.748911] dummy_queue+0xd6/0x1fb
[ 2.748913] usb_ep_queue+0x80/0x1b5
[ 2.748913] usb_ep_queue+0x80/0x1b5
[ 2.748915] ncm_do_notify+0x155/0x187
[ 2.748915] ncm_do_notify+0x155/0x187
[ 2.748917] ncm_set_alt+0x267/0x276
[ 2.748917] ncm_set_alt+0x267/0x276
[ 2.748919] composite_setup+0xc75/0x1a55
[ 2.748919] composite_setup+0xc75/0x1a55
[ 2.748920] ? check_chain_key+0x8c/0xe1
[ 2.748920] ? check_chain_key+0x8c/0xe1
[ 2.748923] ? do_raw_spin_unlock+0xea/0x126
[ 2.748923] ? do_raw_spin_unlock+0xea/0x126
[ 2.748925] dummy_timer+0x8ba/0x1083
[ 2.748925] dummy_timer+0x8ba/0x1083
[ 2.748926] ? dummy_timer+0x8ba/0x1083
[ 2.748926] ? dummy_timer+0x8ba/0x1083
[ 2.748928] ? __lock_is_held+0x35/0x65
[ 2.748928] ? __lock_is_held+0x35/0x65
[ 2.748930] ? dummy_udc_probe+0x1b5/0x1b5
[ 2.748930] ? dummy_udc_probe+0x1b5/0x1b5
[ 2.748932] call_timer_fn+0x179/0x38c
[ 2.748932] call_timer_fn+0x179/0x38c
[ 2.748933] ? dummy_udc_probe+0x1b5/0x1b5
[ 2.748933] ? dummy_udc_probe+0x1b5/0x1b5
[ 2.748935] ? dummy_udc_probe+0x1b5/0x1b5
[ 2.748935] ? dummy_udc_probe+0x1b5/0x1b5
[ 2.748936] run_timer_softirq+0x1a1/0x1c9
[ 2.748936] run_timer_softirq+0x1a1/0x1c9
[ 2.748939] ? rcu_read_unlock_sched_notrace+0x21/0x41
[ 2.748939] ? rcu_read_unlock_sched_notrace+0x21/0x41
[ 2.748941] __do_softirq+0x1f6/0x4c7
[ 2.748941] __do_softirq+0x1f6/0x4c7
[ 2.748946] ? univ8250_console_setup+0x7a/0x7a
[ 2.748946] ? univ8250_console_setup+0x7a/0x7a
[ 2.748948] ? _local_bh_enable+0x5f/0x5f
[ 2.748948] ? _local_bh_enable+0x5f/0x5f
[ 2.748950] do_softirq_own_stack+0x1e/0x24
[ 2.748950] do_softirq_own_stack+0x1e/0x24
[ 2.748951] </SOFTIRQ>
[ 2.748951] </SOFTIRQ>
[ 2.748953] irq_exit+0x92/0xab
[ 2.748953] irq_exit+0x92/0xab
[ 2.748954] smp_apic_timer_interrupt+0x23/0x2c
[ 2.748954] smp_apic_timer_interrupt+0x23/0x2c
[ 2.748956] apic_timer_interrupt+0x34/0x3c
[ 2.748956] apic_timer_interrupt+0x34/0x3c
[ 2.748958] EIP: arch_local_irq_restore+0x5/0xb
[ 2.748958] EIP: arch_local_irq_restore+0x5/0xb
[ 2.748959] EFLAGS: 00200202 CPU: 0
[ 2.748959] EFLAGS: 00200202 CPU: 0
[ 2.748960] EAX: 00200202 EBX: 00000000 ECX: 00000006 EDX: 00000007
[ 2.748960] EAX: 00200202 EBX: 00000000 ECX: 00000006 EDX: 00000007
[ 2.748961] ESI: 796eb13b EDI: 00000000 EBP: 919efe00 ESP: 919efe00
[ 2.748961] ESI: 796eb13b EDI: 00000000 EBP: 919efe00 ESP: 919efe00
[ 2.748962] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 2.748962] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 2.748964] ? univ8250_console_setup+0x7a/0x7a
[ 2.748964] ? univ8250_console_setup+0x7a/0x7a
[ 2.748966] ? trace_raw_output_console+0x2d/0x59
[ 2.748966] ? trace_raw_output_console+0x2d/0x59
[ 2.748968] console_unlock+0x514/0x667
[ 2.748968] console_unlock+0x514/0x667
[ 2.748970] vprintk_emit+0x384/0x38e
[ 2.748970] vprintk_emit+0x384/0x38e
[ 2.748971] vprintk_default+0x12/0x14
[ 2.748971] vprintk_default+0x12/0x14
[ 2.748973] vprintk_func+0x63/0x67
[ 2.748973] vprintk_func+0x63/0x67
[ 2.748975] printk+0xe/0x10
[ 2.748975] printk+0xe/0x10
[ 2.748977] test+0x2c7/0x314
[ 2.748977] test+0x2c7/0x314
[ 2.748979] ? disk_type+0x4e/0x4e
[ 2.748979] ? disk_type+0x4e/0x4e
[ 2.748981] raid6_test+0xb8/0x116
[ 2.748981] raid6_test+0xb8/0x116
[ 2.748983] ? test+0x314/0x314
[ 2.748983] ? test+0x314/0x314
[ 2.748984] do_one_initcall+0x8f/0x18f
[ 2.748984] do_one_initcall+0x8f/0x18f
[ 2.748986] ? parse_args+0x19f/0x24d
[ 2.748986] ? parse_args+0x19f/0x24d
[ 2.748988] ? kernel_init_freeable+0xdb/0x1bc
[ 2.748988] ? kernel_init_freeable+0xdb/0x1bc
[ 2.748989] kernel_init_freeable+0xfe/0x1bc
[ 2.748989] kernel_init_freeable+0xfe/0x1bc
[ 2.748991] ? rest_init+0x12a/0x12a
[ 2.748991] ? rest_init+0x12a/0x12a
[ 2.748992] kernel_init+0x8/0x150
[ 2.748992] kernel_init+0x8/0x150
[ 2.748994] ret_from_fork+0x19/0x24
[ 2.748994] ret_from_fork+0x19/0x24
[ 2.821984] cdc_ncm 1-1:1.0: MAC-Address: 4e:8c:d2:7b:df:4e
[ 2.821984] cdc_ncm 1-1:1.0: MAC-Address: 4e:8c:d2:7b:df:4e
[ 2.822334] cdc_ncm 1-1:1.0 usb1: register 'cdc_ncm' at usb-dummy_hcd.0-1, CDC NCM, 4e:8c:d2:7b:df:4e
[ 2.822334] cdc_ncm 1-1:1.0 usb1: register 'cdc_ncm' at usb-dummy_hcd.0-1, CDC NCM, 4e:8c:d2:7b:df:4e
[ 2.827981] raid6test: test_disks(12, 15): faila= 12(D) failb= 15(D) OK
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Kernel Test Robot
4 years, 2 months
[lkp-robot] [rcu] de8a3b1249: WARNING:at_kernel/rcu/tree_plugin.h:#rcu_read_unlock_special
by kernel test robot
FYI, we noticed the following commit:
commit: de8a3b1249d6d6eb910e271dc0d18bafd032172d ("rcu: Add assertions verifying blocked-tasks list")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git rcu/dev
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu Westmere -m 512M
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+--------------------------------------------------------------+------------+------------+
| | a3755ad263 | de8a3b1249 |
+--------------------------------------------------------------+------------+------------+
| boot_successes | 6 | 3 |
| boot_failures | 45 | 13 |
| is_trying_to_release_lock(rcu_preempt_state)at | 45 | 13 |
| WARNING:at_kernel/rcu/tree_plugin.h:#rcu_read_unlock_special | 0 | 13 |
+--------------------------------------------------------------+------------+------------+
[ 3.957710] WARNING: CPU: 0 PID: 1 at kernel/rcu/tree_plugin.h:508 rcu_read_unlock_special+0x1ef/0x2a4
[ 3.959690] Modules linked in:
[ 3.960199] CPU: 0 PID: 1 Comm: swapper Not tainted 4.12.0-02191-gde8a3b1 #1
[ 3.960199] task: ffff88000002c000 task.stack: ffff880000030000
[ 3.960199] RIP: 0010:rcu_read_unlock_special+0x1ef/0x2a4
[ 3.960199] RSP: 0000:ffff880000033d10 EFLAGS: 00010017
[ 3.960199] RAX: ffff88000002c2d8 RBX: 0000000000000202 RCX: ffffffff81c060c8
[ 3.960199] RDX: 0000000000000000 RSI: ffffffff81c060c8 RDI: ffffffff81c06020
[ 3.960199] RBP: ffff880000033d40 R08: 00000001eff822d2 R09: 0000000000000000
[ 3.960199] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000002c000
[ 3.960199] R13: ffff88000002c000 R14: ffffffff81c06020 R15: 0000000000000000
[ 3.960199] FS: 0000000000000000(0000) GS:ffffffff81a2a000(0000) knlGS:0000000000000000
[ 3.960199] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.960199] CR2: 0000000000000000 CR3: 0000000001a17000 CR4: 00000000000006b0
[ 3.960199] Call Trace:
[ 3.960199] __rcu_read_unlock+0x3e/0x5f
[ 3.960199] insert_retry+0x1fa/0x4cb
[ 3.960199] test_rhashtable+0x75/0x7ed
[ 3.960199] ? lockdep_init_map+0xbb/0x1bd
[ 3.960199] test_rht_init+0xdd/0x3d4
[ 3.960199] ? test_rhashtable+0x7ed/0x7ed
[ 3.960199] ? set_debug_rodata+0x12/0x12
[ 3.960199] do_one_initcall+0x89/0x132
[ 3.960199] ? set_debug_rodata+0x12/0x12
[ 3.960199] kernel_init_freeable+0x107/0x185
[ 3.960199] ? rest_init+0x221/0x221
[ 3.960199] kernel_init+0x9/0xe6
[ 3.960199] ret_from_fork+0x2a/0x40
[ 3.960199] Code: 00 00 49 3b 86 c0 00 00 00 75 07 49 89 96 c0 00 00 00 4d 8b ae 28 01 00 00 49 83 e5 fe 4d 39 ec 75 0b 49 39 86 c8 00 00 00 74 02 <0f> ff 49 3b 86 c8 00 00 00 75 07 49 89 96 c8 00 00 00 4c 89 f7
[ 3.960199] ---[ end trace 88baba44f97303e0 ]---
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Xiaolong
4 years, 2 months
[lkp-robot] [md] 6497709b5d: mdadm-selftests.01raid6integ.fail
by kernel test robot
FYI, we noticed the following commit:
commit: 6497709b5d1bccce7de1df678d5f147d614551d1 ("md: factor out set_in_sync()")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: mdadm-selftests
with following parameters:
test_prefix: 01
on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 4G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
[ 529.654896] tests/01raid6integ... FAILED - see /var/tmp/log for details
[ 529.654900]
[ 529.663888] losetup: /dev/loop0: detach failed: No such device or address
[ 529.663890]
[ 529.685894] losetup: /dev/loop1: detach failed: No such device or address
[ 529.685897]
[ 529.710698] losetup: /dev/loop2: detach failed: No such device or address
[ 529.710701]
[ 529.723935] losetup: /dev/loop3: detach failed: No such device or address
[ 529.723938]
[ 529.742692] losetup: /dev/loop4: detach failed: No such device or address
[ 529.742694]
[ 529.759674] losetup: /dev/loop5: detach failed: No such device or address
[ 529.759677]
[ 529.782431] losetup: /dev/loop6: detach failed: No such device or address
[ 529.782434]
[ 529.804749] losetup: /dev/loop7: detach failed: No such device or address
[ 529.804752]
[ 529.823218] losetup: /dev/loop8: detach failed: No such device or address
[ 529.823220]
[ 529.840368] losetup: /dev/loop9: detach failed: No such device or address
[ 529.840371]
[ 529.862217] losetup: /dev/loop10: detach failed: No such device or address
[ 529.862220]
[ 529.879830] losetup: /dev/loop11: detach failed: No such device or address
[ 529.879833]
[ 529.898154] losetup: /dev/loop12: detach failed: No such device or address
[ 529.898156]
[ 529.921654] losetup: /dev/loop13: detach failed: No such device or address
[ 529.921657]
[ 529.948507] 01raid6integ TIMEOUT
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Xiaolong
4 years, 2 months
[lkp-robot] [libata] 6f7a1345d2: kmsg.ata#.#:failed_to_set_xfermode(err_mask=#)
by kernel test robot
FYI, we noticed the following commit:
commit: 6f7a1345d2304eeee7ab35116732049f8712b673 ("libata: implement SECURITY PROTOCOL IN/OUT")
git://git.infradead.org/users/hch/block.git libata-opal
in testcase: unixbench
with following parameters:
runtime: 300s
nr_task: 100%
test: fsbuffer
test-description: UnixBench is the original BYTE UNIX benchmark suite aims to test performance of Unix-like system.
test-url: https://github.com/kdlucas/byte-unixbench
on test machine: 8 threads Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz with 4G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
[ 8.838444] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 8.838797] ata1.01: SATA link down (SStatus 0 SControl 300)
[ 8.839251] ata2.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 8.839614] ata2.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 8.841700] ata1.00: ATA-8: Hitachi HDT721050SLA360, ST3OA38E, max UDMA/133
[ 8.842069] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 8.862760] ata1.00: ATA Identify Device Log not supported
[ 8.863071] ata1.00: Security Log not supported
[ 8.877950] ata2.00: ATA-9: INTEL SSDSC2CW240A3, 400i, max UDMA/133
[ 8.878287] ata2.00: 468862128 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 8.879074] ata2.00: READ LOG DMA EXT failed, trying unqueued
[ 8.879397] ata2.00: ATA Identify Device Log not supported
[ 8.879700] ata2.00: Security Log not supported
[ 8.879971] ata2.01: ATAPI: HL-DT-ST DVD+/-RW GH50N, B102, max UDMA/100
[ 8.880320] ata2.00: failed to set xfermode (err_mask=0x40)
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Xiaolong
4 years, 2 months
[lkp-robot] [perf callchain] d26144de70: perf-sanity-tests.DWARF_unwind.fail
by kernel test robot
FYI, we noticed the following commit:
commit: d26144de70f0f087915f8653d3741833dacf7a1d ("perf callchain: Maintain libunwind's address space in map_groups")
https://git.kernel.org/cgit/linux/kernel/git/jolsa/perf.git perf/data
in testcase: perf-sanity-tests
with following parameters:
on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 4 -m 5G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
52: perf hooks : Ok
53: builtin clang support : Skip (not compiled in)
54: unit_number__scnprintf : Ok
55: Test thread comm handling : Ok
56: Test thread lookup with time : Ok
57: Test thread map group handling with time : Ok
58: Test thread map lookup with time : Ok
59: x86 rdpmc : Ok
60: Convert perf time to TSC : Ok
61: DWARF unwind : FAILED!
62: x86 instruction decoder - new instructions : Ok
63: Intel cqm nmi context read : Skip
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Xiaolong
4 years, 2 months
[lkp-robot] [x86/dump_pagetables] c4b1439f71: kernel_BUG_at_arch/x86/mm/physaddr.c
by kernel test robot
FYI, we noticed the following commit:
commit: c4b1439f719b1689a1cfca9c0df17b9f8b8462b9 ("x86/dump_pagetables: Do not walk kasan_zero_* page tables")
https://git.kernel.org/cgit/linux/kernel/git/kas/linux.git la57/boot-switching/v2
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+--------------------------------------------+------------+------------+
| | fa49a83772 | c4b1439f71 |
+--------------------------------------------+------------+------------+
| boot_successes | 35 | 0 |
| boot_failures | 4 | 8 |
| BUG:using_smp_processor_id()in_preemptible | 4 | |
| kernel_BUG_at_arch/x86/mm/physaddr.c | 0 | 8 |
| invalid_opcode:#[##] | 0 | 8 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 8 |
+--------------------------------------------+------------+------------+
[ 18.428224] kernel BUG at arch/x86/mm/physaddr.c:26!
[ 18.428224] kernel BUG at arch/x86/mm/physaddr.c:26!
[ 18.430252] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 18.430252] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 18.432087] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-10988-gc4b1439 #1
[ 18.432087] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-10988-gc4b1439 #1
[ 18.434231] task: ffff88001d110040 task.stack: ffffc90000008000
[ 18.434231] task: ffff88001d110040 task.stack: ffffc90000008000
[ 18.436018] RIP: 0010:__phys_addr+0xdc/0xea
[ 18.436018] RIP: 0010:__phys_addr+0xdc/0xea
[ 18.437271] RSP: 0000:ffffc9000000be28 EFLAGS: 00010202
[ 18.437271] RSP: 0000:ffffc9000000be28 EFLAGS: 00010202
[ 18.438847] RAX: 0000780000000000 RBX: 0000780000000000 RCX: 0000000000000000
[ 18.438847] RAX: 0000780000000000 RBX: 0000780000000000 RCX: 0000000000000000
[ 18.440963] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff82a29d90
[ 18.440963] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff82a29d90
[ 18.443084] RBP: ffffc9000000be48 R08: ffff800000000000 R09: 0000000000000000
[ 18.443084] RBP: ffffc9000000be48 R08: ffff800000000000 R09: 0000000000000000
[ 18.445200] R10: ffffc9000000bdc0 R11: 0000000000000000 R12: 0000000000000003
[ 18.445200] R10: ffffc9000000bdc0 R11: 0000000000000000 R12: 0000000000000003
[ 18.447321] R13: 0000000000000001 R14: 0000000000000000 R15: ffffffff8260f000
[ 18.447321] R13: 0000000000000001 R14: 0000000000000000 R15: ffffffff8260f000
[ 18.449450] FS: 0000000000000000(0000) GS:ffff88001e300000(0000) knlGS:0000000000000000
[ 18.449450] FS: 0000000000000000(0000) GS:ffff88001e300000(0000) knlGS:0000000000000000
[ 18.451861] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 18.451861] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 18.453575] CR2: ffffc9000009c000 CR3: 000000000260f000 CR4: 00000000000006a0
[ 18.453575] CR2: ffffc9000009c000 CR3: 000000000260f000 CR4: 00000000000006a0
[ 18.455712] Call Trace:
[ 18.455712] Call Trace:
[ 18.456468] ptdump_walk_pgd_level_core+0x11e/0x59c
[ 18.456468] ptdump_walk_pgd_level_core+0x11e/0x59c
[ 18.457921] ? 0xffffffff81000000
[ 18.457921] ? 0xffffffff81000000
[ 18.458936] ptdump_walk_pgd_level_checkwx+0x12/0x14
[ 18.458936] ptdump_walk_pgd_level_checkwx+0x12/0x14
[ 18.460432] mark_rodata_ro+0xf6/0xfd
[ 18.460432] mark_rodata_ro+0xf6/0xfd
[ 18.461539] ? rest_init+0x144/0x144
[ 18.461539] ? rest_init+0x144/0x144
[ 18.462613] kernel_init+0x2b/0x160
[ 18.462613] kernel_init+0x2b/0x160
[ 18.463683] ret_from_fork+0x2a/0x40
[ 18.463683] ret_from_fork+0x2a/0x40
[ 18.464762] Code: 0f 95 c5 45 0f b6 e5 31 c9 31 d2 44 89 e6 48 c7 c7 90 9d a2 82 49 83 c4 02 e8 fd dd 16 00 4a ff 04 e5 30 cb b3 82 45 84 ed 74 02 <0f> 0b 48 89 d8 5b 41 5c 41 5d 41 5e 5d c3 55 48 89 e5 41 54 53
[ 18.464762] Code: 0f 95 c5 45 0f b6 e5 31 c9 31 d2 44 89 e6 48 c7 c7 90 9d a2 82 49 83 c4 02 e8 fd dd 16 00 4a ff 04 e5 30 cb b3 82 45 84 ed 74 02 <0f> 0b 48 89 d8 5b 41 5c 41 5d 41 5e 5d c3 55 48 89 e5 41 54 53
[ 18.470608] RIP: __phys_addr+0xdc/0xea RSP: ffffc9000000be28
[ 18.470608] RIP: __phys_addr+0xdc/0xea RSP: ffffc9000000be28
[ 18.472428] ---[ end trace 00099341c7800e18 ]---
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Xiaolong
4 years, 2 months
Re: [LKP] [PATCH v2] xattr: Enable security.capability in user namespaces
by Mimi Zohar
On Fri, 2017-07-14 at 19:02 -0500, Eric W. Biederman wrote:
> Mimi Zohar <zohar(a)linux.vnet.ibm.com> writes:
>
> > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> >> "Serge E. Hallyn" <serge(a)hallyn.com> writes:
> >>
> >> > Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> >> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> >> >> >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> >> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >> >> >>>Stefan Berger <stefanb(a)linux.vnet.ibm.com> writes:
> >> >> >>>
> >> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >> >> >>>>
> >> >> >>>>>My big question right now is can you implement Ted's suggested
> >> >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> >> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >> >> >>>>
> >> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> >> >> >>>>
> >> >> >>>The latter.
> >> >> >>That case would prevent a container user from overriding the xattr
> >> >> >>on the host. Is that what we want? For limiting the number of xattrs
> >> >> >Not really. If the file is owned by a uid mapped into the container,
> >> >> >then the container root can chown the file which will clear the file
> >> >> >capability, after which he can set a new one. If the file is not
> >> >> >owned by a uid mapped into the container, then container root could
> >> >> >not set a filecap anyway.
> >> >>
> >> >> Let's say I installed a container where all files are signed and
> >> >> thus have security.ima. Now for some reason I want to re-sign some
> >> >> or all files inside that container. How would I do that ? Would I
> >> >> need to get rid of security.ima first, possibly by copying each
> >> >> file, deleting the original file, and renaming the copied file to
> >> >> the original name, or should I just be able to write out a new
> >> >> signature, thus creating security.ima@uid=1000 besides the
> >> >> security.ima ?
> >> >>
> >> >> Stefan
> >> >
> >> > Hi Mimi,
> >> >
> >> > what do you think makes most sense for IMA?
> >>
> >> I am going to give my two cents since I have been thinking about this.
> >>
> >> First I think this entire scheme plays hobs with the security.evm
> >> attribute as security.evm needs to know the names of the xattrs to
> >> protect.
> >>
> >> I forget which attributes has a hash and what has a message
> >> athentication code.
> >
> > security.ima contains either a file hash or a signature. (file data)
> > security.evm contains either a signature or an hmac of the security
> > xattrs and other file metadata. (file meta-data)
> >
> > The same rules would apply to security.evm, as described in my
> > response. Based on it's view of the security xattrs, either the
> > native or namespace security.evm would be updated.
> >
> >> If there is an attribute with a simple file hash I think it only make
> >> sense for the kernel to touch it, and I don't see any sense in having
> >> multiples.
> >
> > Only files that are in the IMA-appraisal policy is the file hash
> > calculated and written out as security.ima. Depending this policy,
> > does the security.ima exist. So if the file is in policy for both the
> > native and namespace policies, agreed the same hash doesn't need to be
> > written as two different xattrs.
> >
> >> If there is an attribute with a message authentication code (roughly a
> >> signed hash) it makes sense to have that to be tied to the kernel key
> >> ring that controlls the keys. (Which probably means a per user
> >> namespace thing at some point). But again pretty untouchable otherwise.
> >
> > Right, the namespace would require it's own EVM key.
> >
> >> Which brings us to the semantic question of would it be nice to have
> >> stacked IMA/EVM on the same file.
> >>
> >> I really don't think we do. I think allowing multiple keys for
> >> different part of trusting files is easy enough that we should have no
> >> need to fight over which keys do which.
> >
> > We definitely want to support different policies on the native and in
> > the namespace with different keys and keyrings.
> >
> > Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
> > of IMA namespacing - kernsec.org/pipermail/linux-security-module-
> > archive/2017-July/002286.html.
> >
> >> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
> >> case I can think of for distributing a distribution image with ima/evm
> >> xattrs will need to use asymmetric keys aka public/private keypairs so
> >> that the originator of the content does not give away their private
> >> keys.
> >
> > Agreed.
> >
> >> Given that usefully we are talking about content that should be
> >> connected to keys in one way or another I don't believe it even makes
> >> sense at this point to attempt to use uids for dealing with ima and
> >> evm content.
> >
> > We need to resolve the xattr issue in order to namespace IMA-
> > appraisal.
>
>
> Mimi I have two questions:
>
> a) Is the keyid enough to distinguish the security.ima and security.evm
> xattrs of one container from another container and from native? Or
> do we have some important security xattrs that are associated with
> keys that don't have a keyid?
>
> b) Can we reasonably live with a limitation that the native and the
> namespace'd policies don't intersect? Or in the case of an
> interesection the native policy is the only one that is executed?
>
> I submit that if the answer is keyids are always present, and we can
> live with the native policy taking precedence over the container policy
> then we have a solution to the IMA xattrs.
IMA-measurement is hierachical, meaning that the measurement policy
determines whether the measurement exists in the native, the
container, or both measurement lists.
One of the main namespacing use cases for IMA-appraisal is the ability
to limit running an executable to a particular container. So unlike
IMA-measurement, which is hierarchical, the IMA-appraisal namespace
policy takes precedence over the native policy.
Mimi
4 years, 2 months
3b9e667663 ("x86/dump_pagetables: Do not walk kasan_zero_* .."): kernel BUG at arch/x86/mm/physaddr.c:26!
by kernel test robot
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git la57/boot-switching/v2
commit 3b9e6676636d5beee03ad534151dbc4a23680032
Author: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
AuthorDate: Wed Jul 12 13:34:19 2017 +0300
Commit: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
CommitDate: Fri Jul 14 13:22:37 2017 +0300
x86/dump_pagetables: Do not walk kasan_zero_* page tables
When KASAN is enabled, walking page tables takes unreasonable time for
5-level paging configuration. The reason is that have to look into all
shadow memory page tables.
But that's not necessary: it's useless to look into kasan_zero_* page
tables. The page walked wouldn't find any interesting there, so we just
waste time.
Let's cut page walking short on encounter any of kasan_zero_* page
tables.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
831cfb4bbe x86/dump_pagetables: Fix printout of p4d level
3b9e667663 x86/dump_pagetables: Do not walk kasan_zero_* page tables
ba30467b27 x86/mm: Allow to boot without la57 if CONFIG_X86_5LEVEL=y
+------------------------------------------+------------+------------+------------+
| | 831cfb4bbe | 3b9e667663 | ba30467b27 |
+------------------------------------------+------------+------------+------------+
| boot_successes | 33 | 0 | 0 |
| boot_failures | 0 | 15 | 11 |
| kernel_BUG_at_arch/x86/mm/physaddr.c | 0 | 15 | 11 |
| invalid_opcode:#[##] | 0 | 15 | 11 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 15 | 11 |
+------------------------------------------+------------+------------+------------+
[ 1.666149] Freeing unused kernel memory: 1348K
[ 1.667135] Freeing unused kernel memory: 52K
[ 1.667135] Freeing unused kernel memory: 52K
[ 1.667885] ------------[ cut here ]------------
[ 1.667885] ------------[ cut here ]------------
[ 1.668656] kernel BUG at arch/x86/mm/physaddr.c:26!
[ 1.668656] kernel BUG at arch/x86/mm/physaddr.c:26!
[ 1.669797] invalid opcode: 0000 [#1] PREEMPT SMP
[ 1.669797] invalid opcode: 0000 [#1] PREEMPT SMP
[ 1.670585] Modules linked in:
[ 1.670585] Modules linked in:
[ 1.671103] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-11621-g3b9e667 #2
[ 1.671103] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-11621-g3b9e667 #2
[ 1.672295] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 1.672295] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 1.673976] task: ffff88000017a640 task.stack: ffffc900000d0000
[ 1.673976] task: ffff88000017a640 task.stack: ffffc900000d0000
[ 1.674965] RIP: 0010:__phys_addr+0x37/0x50
[ 1.674965] RIP: 0010:__phys_addr+0x37/0x50
[ 1.675660] RSP: 0000:ffffc900000d3e28 EFLAGS: 00010287
[ 1.675660] RSP: 0000:ffffc900000d3e28 EFLAGS: 00010287
[ 1.676528] RAX: 0000780000000000 RBX: ffff8800024d6000 RCX: 0000000000000028
[ 1.676528] RAX: 0000780000000000 RBX: ffff8800024d6000 RCX: 0000000000000028
[ 1.677712] RDX: 0000000080000000 RSI: ffffc900000d3e88 RDI: 0000000000000000
[ 1.677712] RDX: 0000000080000000 RSI: ffffc900000d3e88 RDI: 0000000000000000
[ 1.678898] RBP: ffffc900000d3e28 R08: 000000000000021b R09: ffff800000000000
[ 1.678898] RBP: ffffc900000d3e28 R08: 000000000000021b R09: ffff800000000000
[ 1.680211] R10: 00000000fffffffe R11: 0000000000000001 R12: 0000880000000000
[ 1.680211] R10: 00000000fffffffe R11: 0000000000000001 R12: 0000880000000000
[ 1.681748] R13: ffffc900000d3e88 R14: 0000000000000000 R15: 00000000024d6000
[ 1.681748] R13: ffffc900000d3e88 R14: 0000000000000000 R15: 00000000024d6000
[ 1.683292] FS: 0000000000000000(0000) GS:ffff88001fa00000(0000) knlGS:0000000000000000
[ 1.683292] FS: 0000000000000000(0000) GS:ffff88001fa00000(0000) knlGS:0000000000000000
[ 1.685031] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.685031] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.686271] CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000001406b0
[ 1.686271] CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000001406b0
[ 1.687812] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1.687812] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1.689342] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1.689342] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1.690877] Call Trace:
[ 1.690877] Call Trace:
[ 1.691421] walk_pud_level+0x54/0x180
[ 1.691421] walk_pud_level+0x54/0x180
[ 1.692242] ptdump_walk_pgd_level_core+0xeb/0x150
[ 1.692242] ptdump_walk_pgd_level_core+0xeb/0x150
[ 1.693283] ptdump_walk_pgd_level_checkwx+0x12/0x20
[ 1.693283] ptdump_walk_pgd_level_checkwx+0x12/0x20
[ 1.694356] mark_rodata_ro+0xfc/0x110
[ 1.694356] mark_rodata_ro+0xfc/0x110
[ 1.695176] ? rest_init+0xd0/0xd0
[ 1.695176] ? rest_init+0xd0/0xd0
[ 1.695921] kernel_init+0x25/0x100
[ 1.695921] kernel_init+0x25/0x100
[ 1.696681] ret_from_fork+0x25/0x30
[ 1.696681] ret_from_fork+0x25/0x30
[ 1.697464] Code: 48 89 e5 72 28 48 b8 00 00 00 00 00 78 00 00 48 01 f8 48 39 c2 72 14 0f b6 0d df ff a3 00 48 89 c2 48 d3 ea 48 85 d2 75 02 5d c3 <0f> 0b 48 89 d0 48 03 05 0d db 9c 00 48 81 fa ff ff ff 1f 76 e9
[ 1.697464] Code: 48 89 e5 72 28 48 b8 00 00 00 00 00 78 00 00 48 01 f8 48 39 c2 72 14 0f b6 0d df ff a3 00 48 89 c2 48 d3 ea 48 85 d2 75 02 5d c3 <0f> 0b 48 89 d0 48 03 05 0d db 9c 00 48 81 fa ff ff ff 1f 76 e9
[ 1.701539] RIP: __phys_addr+0x37/0x50 RSP: ffffc900000d3e28
[ 1.701539] RIP: __phys_addr+0x37/0x50 RSP: ffffc900000d3e28
[ 1.702829] ---[ end trace a27a2c2ff0e1abd8 ]---
[ 1.702829] ---[ end trace a27a2c2ff0e1abd8 ]---
# HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start 8cac6677b2bdc830aa155fb37c5be094b71eeef6 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c --
git bisect bad 8aaef23d1683448655aecd2a895c2c36b983e847 # 11:02 B 0 11 24 0 Merge 'skn/v4.12/scmi' into devel-spot-201707160815
git bisect bad 9351b4c3738743d0147210f704937f9f8c3cd271 # 11:10 B 0 11 24 0 Merge 'kas/la57/boot-switching/v2' into devel-spot-201707160815
git bisect good f150502acd931e28d97dc184bbd52611ade9a7ac # 11:25 G 11 0 0 0 0day base guard for 'devel-spot-201707160815'
git bisect good 5518b69b76680a4f2df96b1deca260059db0c2de # 11:35 G 11 0 0 0 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good 2ceedf97aef41d071d897a6e6aec8c05fb707ec4 # 11:47 G 11 0 0 0 Merge tag 'dmaengine-4.13-rc1' of git://git.infradead.org/users/vkoul/slave-dma
git bisect good 6419ec78c6726aa54ff103aceffbf19d546d3d1b # 12:03 G 11 0 0 0 Merge branch 'drm-next-4.13' of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect good 6b1c776d3efbda31085b6a9f3bc7f774511fafd9 # 12:22 G 11 0 0 0 Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs
git bisect good 8c6f5e7359e5bd0616b686dd5e14b99a34103b32 # 12:34 G 11 0 0 0 Merge tag 'vfio-v4.13-rc1' of git://github.com/awilliam/linux-vfio
git bisect good 19c6e12c07ceab2ff5d5ec97354b893ab386c41c # 12:51 G 11 0 0 0 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
git bisect good 48ea2cedde3507941f4549b0d27ed46ed29e39ff # 13:13 G 11 0 0 0 Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
git bisect good ce85bd29210f2cd84dc1f762c3992d8e6db822c2 # 13:26 G 11 0 0 0 nfs: Fix fscache stat printing in nfs_show_stats()
git bisect good 15a8b93fd5690de017ce665382ea45e5d61811a4 # 13:35 G 11 0 0 0 sunrpc: use constant time memory comparison for mac
git bisect bad 0330baf2c2073b3628def539c24960ccb4ba6c7d # 13:45 B 0 11 26 2 x86/xen: Redefine XEN_ELFNOTE_INIT_P2M using PUD_SIZE * PTRS_PER_PUD
git bisect good b4f937cffa66b3d56eb8f586e620d0b223a281a3 # 13:57 G 11 0 0 0 NFS: Don't run wake_up_bit() when nobody is waiting...
git bisect good fa2181b827a2dce3b585e0a235636a5e7b509c02 # 14:12 G 11 0 0 0 x86/dump_pagetables: Generalize address normalization
git bisect bad 3b9e6676636d5beee03ad534151dbc4a23680032 # 14:19 B 0 11 24 0 x86/dump_pagetables: Do not walk kasan_zero_* page tables
git bisect good 831cfb4bbe69e371a87aff96a4d80f93d0453d1a # 14:28 G 11 0 0 0 x86/dump_pagetables: Fix printout of p4d level
# first bad commit: [3b9e6676636d5beee03ad534151dbc4a23680032] x86/dump_pagetables: Do not walk kasan_zero_* page tables
git bisect good 831cfb4bbe69e371a87aff96a4d80f93d0453d1a # 14:30 G 31 0 0 0 x86/dump_pagetables: Fix printout of p4d level
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect bad 3b9e6676636d5beee03ad534151dbc4a23680032 # 14:39 B 0 11 24 0 x86/dump_pagetables: Do not walk kasan_zero_* page tables
# extra tests on HEAD of linux-devel/devel-spot-201707160815
git bisect bad 8cac6677b2bdc830aa155fb37c5be094b71eeef6 # 14:39 B 0 23 39 0 0day head guard for 'devel-spot-201707160815'
# extra tests on tree/branch kas/la57/boot-switching/v2
git bisect bad ba30467b270ef2037f0c2b29513ecd089eee0bdf # 15:01 B 0 11 24 0 x86/mm: Allow to boot without la57 if CONFIG_X86_5LEVEL=y
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
4 years, 2 months
Re: [LKP] [PATCH v2] xattr: Enable security.capability in user namespaces
by Mimi Zohar
On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge(a)hallyn.com> writes:
>
> > Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> >> >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >> >>>Stefan Berger <stefanb(a)linux.vnet.ibm.com> writes:
> >> >>>
> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >> >>>>
> >> >>>>>My big question right now is can you implement Ted's suggested
> >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >> >>>>
> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> >> >>>>
> >> >>>The latter.
> >> >>That case would prevent a container user from overriding the xattr
> >> >>on the host. Is that what we want? For limiting the number of xattrs
> >> >Not really. If the file is owned by a uid mapped into the container,
> >> >then the container root can chown the file which will clear the file
> >> >capability, after which he can set a new one. If the file is not
> >> >owned by a uid mapped into the container, then container root could
> >> >not set a filecap anyway.
> >>
> >> Let's say I installed a container where all files are signed and
> >> thus have security.ima. Now for some reason I want to re-sign some
> >> or all files inside that container. How would I do that ? Would I
> >> need to get rid of security.ima first, possibly by copying each
> >> file, deleting the original file, and renaming the copied file to
> >> the original name, or should I just be able to write out a new
> >> signature, thus creating security.ima@uid=1000 besides the
> >> security.ima ?
> >>
> >> Stefan
> >
> > Hi Mimi,
> >
> > what do you think makes most sense for IMA?
>
> I am going to give my two cents since I have been thinking about this.
>
> First I think this entire scheme plays hobs with the security.evm
> attribute as security.evm needs to know the names of the xattrs to
> protect.
>
> I forget which attributes has a hash and what has a message
> athentication code.
security.ima contains either a file hash or a signature. (file data)
security.evm contains either a signature or an hmac of the security
xattrs and other file metadata. (file meta-data)
The same rules would apply to security.evm, as described in my
response. Based on it's view of the security xattrs, either the
native or namespace security.evm would be updated.
> If there is an attribute with a simple file hash I think it only make
> sense for the kernel to touch it, and I don't see any sense in having
> multiples.
Only files that are in the IMA-appraisal policy is the file hash
calculated and written out as security.ima. Depending this policy,
does the security.ima exist. So if the file is in policy for both the
native and namespace policies, agreed the same hash doesn't need to be
written as two different xattrs.
> If there is an attribute with a message authentication code (roughly a
> signed hash) it makes sense to have that to be tied to the kernel key
> ring that controlls the keys. (Which probably means a per user
> namespace thing at some point). But again pretty untouchable otherwise.
Right, the namespace would require it's own EVM key.
> Which brings us to the semantic question of would it be nice to have
> stacked IMA/EVM on the same file.
>
> I really don't think we do. I think allowing multiple keys for
> different part of trusting files is easy enough that we should have no
> need to fight over which keys do which.
We definitely want to support different policies on the native and in
the namespace with different keys and keyrings.
Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
of IMA namespacing - kernsec.org/pipermail/linux-security-module-
archive/2017-July/002286.html.
> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
> case I can think of for distributing a distribution image with ima/evm
> xattrs will need to use asymmetric keys aka public/private keypairs so
> that the originator of the content does not give away their private
> keys.
Agreed.
> Given that usefully we are talking about content that should be
> connected to keys in one way or another I don't believe it even makes
> sense at this point to attempt to use uids for dealing with ima and
> evm content.
We need to resolve the xattr issue in order to namespace IMA-
appraisal.
Mimi
> Further looking Serge's previous patch is 300 lines of code Setfan's
> patch that provides the possibility of code resuse is 500 lines of code.
>
> Increasingly it is looking to me that code reuse rather than concept
> reuse is a false economy. The code does not get smaller. The semantic
> differences make it problematic. Possibly to the problematic to the
> point where significant pieces may not be reused. The format breaks
> assumptions for other parts of the code like security.evm. The format
> by multiple names instead of a single attribute requires more disk
> access so is less efficient.
>
> In short I am seeing more code that runs slower and is harder to
> maintain. Please point out where I am wrong.
4 years, 2 months