Improve signal perception on noisy cams #1

andrey-utkin · 2016-04-09T10:43:27Z

On customer's installation (Mr. Luna) some cameras which are said to provide good picture previously, have noisy picture. No idea how to improve that. Maybe we could analyze decoding errors if there are any.

Retriving the horizontal timings from the port registers as part of get_config(). This fixes a division by zero: [ 56.916557] divide error: 0000 [#1] PREEMPT SMP [ 56.921741] Modules linked in: i915(+) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart cf g80211 rfkill binfmt_misc ax88179_178a kvm_intel kvm irqbypass crc32c_intel efivars tpm_tis tpm fuse [ 56.944106] CPU: 3 PID: 1097 Comm: modprobe Not tainted 4.6.0-rc4+ torvalds#433 [ 56.951501] Hardware name: Intel Corp. Broxton M/RVP, BIOS BXT1RVPA.X64.0131.B30.1604142217 04/14/2016 [ 56.961908] task: ffff88007a854d00 ti: ffff88007aea0000 task.ti: ffff88007aea0000 [ 56.970273] RIP: 0010:[<ffffffffa01235b2>] [<ffffffffa01235b2>] drm_mode_hsync+0x22/0x40 [drm] [ 56.980043] RSP: 0018:ffff88007aea3788 EFLAGS: 00010206 [ 56.985982] RAX: 000000000788b600 RBX: ffff880073c22108 RCX: 0000000000000000 [ 56.993957] RDX: 0000000000000000 RSI: ffff88007ab06800 RDI: ffff880073c22108 [ 57.001935] RBP: ffff88007aea3788 R08: 0000000000000001 R09: ffff880073c221e8 [ 57.009903] R10: ffff880073c22108 R11: 0000000000000001 R12: ffff88007a300000 [ 57.017872] R13: ffff880073c22000 R14: ffff880175f78000 R15: ffff880175f78798 [ 57.025849] FS: 00007f105d3e6700(0000) GS:ffff88017fd80000(0000) knlGS:0000000000000000 [ 57.034894] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 57.041317] CR2: 00007f4d485101d0 CR3: 000000007a820000 CR4: 00000000003406e0 [ 57.049292] Stack: [ 57.051539] ffff88007aea37a0 ffffffffa043b632 ffff880175f787c8 ffff88007aea3810 [ 57.059825] ffffffffa043d59e ffff880175f787b0 ffff88007ab68c00 ffff88007aea37f0 [ 57.068128] ffff880073c221e8 ffff880073c22108 ffff880175f78780 ffff880100000000 [ 57.076430] Call Trace: [ 57.079254] [<ffffffffa043b632>] intel_mode_from_pipe_config+0x82/0xb0 [i915] [ 57.087405] [<ffffffffa043d59e>] intel_modeset_setup_hw_state+0x55e/0xd60 [i915] [ 57.095847] [<ffffffffa043ff94>] intel_modeset_init+0x8e4/0x1630 [i915] [ 57.103415] [<ffffffffa047bcf0>] i915_driver_load+0xbe0/0x1980 [i915] [ 57.110745] [<ffffffffa0116c19>] drm_dev_register+0xa9/0xc0 [drm] [ 57.117681] [<ffffffffa011921d>] drm_get_pci_dev+0x8d/0x1e0 [drm] [ 57.124600] [<ffffffff8195f942>] ? _raw_spin_unlock_irqrestore+0x42/0x70 [ 57.132253] [<ffffffffa03b0384>] i915_pci_probe+0x34/0x50 [i915] [ 57.139070] [<ffffffff8149c375>] local_pci_probe+0x45/0xa0 [ 57.145303] [<ffffffff8149d300>] ? pci_match_device+0xe0/0x110 [ 57.151924] [<ffffffff8149d6cb>] pci_device_probe+0xdb/0x130 [ 57.158355] [<ffffffff81579b93>] driver_probe_device+0x223/0x440 [ 57.165169] [<ffffffff81579e85>] __driver_attach+0xd5/0x100 [ 57.171500] [<ffffffff81579db0>] ? driver_probe_device+0x440/0x440 [ 57.178510] [<ffffffff81577736>] bus_for_each_dev+0x66/0xa0 [ 57.184841] [<ffffffff815793de>] driver_attach+0x1e/0x20 [ 57.190881] [<ffffffff81578d6e>] bus_add_driver+0x1ee/0x280 [ 57.197212] [<ffffffff8157abc0>] driver_register+0x60/0xe0 [ 57.203447] [<ffffffff8149bc50>] __pci_register_driver+0x60/0x70 [ 57.210285] [<ffffffffa0119450>] drm_pci_init+0xe0/0x110 [drm] [ 57.216911] [<ffffffff810dcd8d>] ? trace_hardirqs_on+0xd/0x10 [ 57.223434] [<ffffffffa023a000>] ? 0xffffffffa023a000 [ 57.229237] [<ffffffffa023a092>] i915_init+0x92/0x99 [i915] [ 57.235570] [<ffffffff810003db>] do_one_initcall+0xab/0x1d0 [ 57.241900] [<ffffffff810f9eef>] ? rcu_read_lock_sched_held+0x7f/0x90 [ 57.249205] [<ffffffff81204f18>] ? kmem_cache_alloc_trace+0x248/0x2b0 [ 57.256509] [<ffffffff811a5eee>] ? do_init_module+0x27/0x1d9 [ 57.262934] [<ffffffff811a5f26>] do_init_module+0x5f/0x1d9 [ 57.269167] [<ffffffff8112392f>] load_module+0x20ef/0x27b0 [ 57.275401] [<ffffffff8111f8e0>] ? store_uevent+0x40/0x40 [ 57.281541] [<ffffffff81124243>] SYSC_finit_module+0xc3/0xf0 [ 57.287969] [<ffffffff8112428e>] SyS_finit_module+0xe/0x10 [ 57.294203] [<ffffffff81960069>] entry_SYSCALL_64_fastpath+0x1c/0xac [ 57.301406] Code: ff 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 8b 87 d8 00 00 00 55 48 89 e5 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 5d c3 [ 57.322964] RIP [<ffffffffa01235b2>] drm_mode_hsync+0x22/0x40 [drm] [ 57.330103] RSP <ffff88007aea3788> [ 57.334276] ---[ end trace d414224cb2e2a4cf ]--- [ 57.339861] modprobe (1097) used greatest stack depth: 12048 bytes left Fixes: 6f0e753 ("drm/i915/BXT: Get pipe conf from the port registers") Signed-off-by: Ramalingam C <[email protected]> Acked-by: Imre Deak <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

In commit f9476a6 ("drm/i915: Refactor platform specifics out of intel_get_shared_dpll()"), the ibx_get_dpll() function lacked an error check, that can lead to a NULL pointer dereference when trying to enable three pipes. BUG: unable to handle kernel NULL pointer dereference at 0000000000000068 IP: [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915] PGD cec87067 PUD d30ce067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: snd_hda_intel i915 drm_kms_helper drm intel_gtt sch_fq_codel cfg80211 binfmt_misc i2c_algo_bit cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp agpgart kvm_intel snd_hda_codec_hdmi kvm iTCO_wdt snd_hda_codec_realtek snd_hda_codec_generic irqbypass aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse pcspkr snd_hda_codec i2c_i801 snd_hwdep snd_hda_core snd_pcm snd_timer lpc_ich mfd_core snd soundcore wmi evdev tpm_tis tpm [last unloaded: drm] CPU: 3 PID: 5810 Comm: kms_flip Tainted: G U W 4.6.0-test+ #3 Hardware name: /DZ77BH-55K, BIOS BHZ7710H.86A.0100.2013.0517.0942 05/17/2013 task: ffff8800d3908040 ti: ffff8801166c8000 task.ti: ffff8801166c8000 RIP: 0010:[<ffffffffa0482275>] [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915] RSP: 0018:ffff8801166cba60 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000002 RDX: 0000000000000001 RSI: ffff8800d07f1bf8 RDI: 0000000000000000 RBP: ffff8801166cba88 R08: 0000000000000002 R09: ffff8800d32e5698 R10: 0000000000000001 R11: ffff8800cc89ac88 R12: ffff8800d07f1bf8 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f4c3fc8d8c0(0000) GS:ffff88011bcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000068 CR3: 00000000d3b4c000 CR4: 00000000001406e0 Stack: 0000000000000000 ffff8800d07f1bf8 0000000000000000 ffff8800d04c0000 0000000000000000 ffff8801166cbaa8 ffffffffa04823a7 ffff8800d07f1bf8 ffff8800d32e5698 ffff8801166cbab8 ffffffffa04840cf ffff8801166cbaf0 Call Trace: [<ffffffffa04823a7>] ibx_get_dpll+0x47/0xa0 [i915] [<ffffffffa04840cf>] intel_get_shared_dpll+0x1f/0x50 [i915] [<ffffffffa046d080>] ironlake_crtc_compute_clock+0x280/0x430 [i915] [<ffffffffa0472ac0>] intel_crtc_atomic_check+0x240/0x320 [i915] [<ffffffffa03da18e>] drm_atomic_helper_check_planes+0x14e/0x1d0 [drm_kms_helper] [<ffffffffa0474a0c>] intel_atomic_check+0x5dc/0x1110 [i915] [<ffffffffa029d3aa>] drm_atomic_check_only+0x14a/0x660 [drm] [<ffffffffa029d086>] ? drm_atomic_set_crtc_for_connector+0x96/0x100 [drm] [<ffffffffa029d8d7>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa03dc3b7>] restore_fbdev_mode+0x237/0x260 [drm_kms_helper] [<ffffffffa029c65a>] ? drm_modeset_lock_all_ctx+0x9a/0xb0 [drm] [<ffffffffa03de9b3>] drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper] [<ffffffffa03dea2d>] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] [<ffffffffa03de93a>] drm_fb_helper_hotplug_event+0xaa/0xf0 [drm_kms_helper] [<ffffffffa03de9d6>] drm_fb_helper_restore_fbdev_mode_unlocked+0x56/0x80 [drm_kms_helper] [<ffffffffa0490f72>] intel_fbdev_restore_mode+0x22/0x80 [i915] [<ffffffffa04ba45e>] i915_driver_lastclose+0xe/0x20 [i915] [<ffffffffa02810de>] drm_lastclose+0x2e/0x130 [drm] [<ffffffffa028148c>] drm_release+0x2ac/0x4b0 [drm] [<ffffffff811a6b2d>] __fput+0xed/0x1f0 [<ffffffff811a6c6e>] ____fput+0xe/0x10 [<ffffffff81079156>] task_work_run+0x76/0xb0 [<ffffffff8105aaab>] do_exit+0x3ab/0xc60 [<ffffffff810a145f>] ? trace_hardirqs_on_caller+0x12f/0x1c0 [<ffffffff8105c67e>] do_group_exit+0x4e/0xc0 [<ffffffff8105c704>] SyS_exit_group+0x14/0x20 [<ffffffff8158bb25>] entry_SYSCALL_64_fastpath+0x18/0xa8 Code: 14 80 48 8d 34 90 b8 01 00 00 00 d3 e0 09 04 b3 5b 41 5c 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 55 41 54 53 <44> 8b 67 68 48 89 f3 48 8b be 08 02 00 00 4c 8b 2e e8 15 9d fd RIP [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915] RSP <ffff8801166cba60> CR2: 0000000000000068 Cc: Ville Syrjälä <[email protected]> Cc: [email protected] Reported-by: Ville Syrjälä <[email protected]> Fixes: f9476a6 ("drm/i915: Refactor platform specifics out of intel_get_shared_dpll()") Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Tested-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1463748426-5956-1-git-send-email-ander.conselvan.de.oliveira@intel.com

…offline_kmem() memcg_offline_kmem() may be called from memcg_free_kmem() after a css init failure. memcg_free_kmem() is a ->css_free callback which is called without cgroup_mutex and memcg_offline_kmem() ends up using css_for_each_descendant_pre() without any locking. Fix it by adding rcu read locking around it. mkdir: cannot create directory `65530': No space left on device [ 527.241361] =============================== [ 527.241845] [ INFO: suspicious RCU usage. ] [ 527.242367] 4.6.0-work+ torvalds#321 Not tainted [ 527.242730] ------------------------------- [ 527.243220] kernel/cgroup.c:4008 cgroup_mutex or RCU read lock required! [ 527.243970] [ 527.243970] other info that might help us debug this: [ 527.243970] [ 527.244715] [ 527.244715] rcu_scheduler_active = 1, debug_locks = 0 [ 527.245463] 2 locks held by kworker/0:5/1664: [ 527.245939] #0: ("cgroup_destroy"){.+.+..}, at: [<ffffffff81060ab5>] process_one_work+0x165/0x4a0 [ 527.246958] #1: ((&css->destroy_work)#3){+.+...}, at: [<ffffffff81060ab5>] process_one_work+0x165/0x4a0 [ 527.248098] [ 527.248098] stack backtrace: [ 527.249565] CPU: 0 PID: 1664 Comm: kworker/0:5 Not tainted 4.6.0-work+ torvalds#321 [ 527.250429] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014 [ 527.250555] Workqueue: cgroup_destroy css_free_work_fn [ 527.250555] 0000000000000000 ffff880178747c68 ffffffff8128bfc7 ffff880178b8ac40 [ 527.250555] 0000000000000001 ffff880178747c98 ffffffff8108c297 0000000000000000 [ 527.250555] ffff88010de54138 000000000000fffb ffff88010de537e8 ffff880178747cc0 [ 527.250555] Call Trace: [ 527.250555] [<ffffffff8128bfc7>] dump_stack+0x68/0xa1 [ 527.250555] [<ffffffff8108c297>] lockdep_rcu_suspicious+0xd7/0x110 [ 527.250555] [<ffffffff810ca03d>] css_next_descendant_pre+0x7d/0xb0 [ 527.250555] [<ffffffff8114d14a>] memcg_offline_kmem.part.44+0x4a/0xc0 [ 527.250555] [<ffffffff8114d3ac>] mem_cgroup_css_free+0x1ec/0x200 [ 527.250555] [<ffffffff810ccdc9>] css_free_work_fn+0x49/0x5e0 [ 527.250555] [<ffffffff81060b15>] process_one_work+0x1c5/0x4a0 [ 527.250555] [<ffffffff81060ab5>] ? process_one_work+0x165/0x4a0 [ 527.250555] [<ffffffff81060e39>] worker_thread+0x49/0x490 [ 527.250555] [<ffffffff81060df0>] ? process_one_work+0x4a0/0x4a0 [ 527.250555] [<ffffffff81060df0>] ? process_one_work+0x4a0/0x4a0 [ 527.250555] [<ffffffff810672ba>] kthread+0xea/0x100 [ 527.250555] [<ffffffff814cbcff>] ret_from_fork+0x1f/0x40 [ 527.250555] [<ffffffff810671d0>] ? kthread_create_on_node+0x200/0x200 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Tejun Heo <[email protected]> Acked-by: Vladimir Davydov <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <[email protected]> Cc: Ebru Akagunduz <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

khugepaged does swap in during collapse under anon_vma lock. It causes complain from lockdep. The trace below shows following scenario: - khugepaged tries to swap in a page under mmap_sem and anon_vma lock; - do_swap_page() calls swapin_readahead() with GFP_HIGHUSER_MOVABLE; - __read_swap_cache_async() tries to allocate the page for swap in; - lockdep_trace_alloc() in __alloc_pages_nodemask() notices that with given gfp_mask we could end up in direct relaim. - Lockdep already knows that reclaim sometimes (e.g. in case of split_huge_page()) wants to take anon_vma lock on its own. Therefore deadlock is possible. The fix is to take anon_vma lock after swap in. [18344.236625] ================================= [18344.236628] [ INFO: inconsistent lock state ] [18344.236633] 4.3.0-rc1-next-20150918-dbg-00014-ge5128d0-dirty torvalds#361 Not tainted [18344.236636] --------------------------------- [18344.236640] inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage. [18344.236645] khugepaged/32 [HC0[0]:SC0[0]:HE1:SE1] takes: [18344.236648] (&anon_vma->rwsem){++++?.}, at: [<ffffffff81134403>] khugepaged+0x8b0/0x1987 [18344.236662] {IN-RECLAIM_FS-W} state was registered at: [18344.236666] [<ffffffff8107d747>] __lock_acquire+0x8e2/0x1183 [18344.236673] [<ffffffff8107e7ac>] lock_acquire+0x10b/0x1a6 [18344.236678] [<ffffffff8150a367>] down_write+0x3b/0x6a [18344.236686] [<ffffffff811360d8>] split_huge_page_to_list+0x5b/0x61f [18344.236689] [<ffffffff811224b3>] add_to_swap+0x37/0x78 [18344.236691] [<ffffffff810fd650>] shrink_page_list+0x4c2/0xb9a [18344.236694] [<ffffffff810fe47c>] shrink_inactive_list+0x371/0x5d9 [18344.236696] [<ffffffff810fee2f>] shrink_lruvec+0x410/0x5ae [18344.236698] [<ffffffff810ff024>] shrink_zone+0x57/0x140 [18344.236700] [<ffffffff810ffc79>] kswapd+0x6a5/0x91b [18344.236702] [<ffffffff81059588>] kthread+0x107/0x10f [18344.236706] [<ffffffff8150c7bf>] ret_from_fork+0x3f/0x70 [18344.236708] irq event stamp: 6517947 [18344.236709] hardirqs last enabled at (6517947): [<ffffffff810f2d0c>] get_page_from_freelist+0x362/0x59e [18344.236713] hardirqs last disabled at (6517946): [<ffffffff8150ba41>] _raw_spin_lock_irqsave+0x18/0x51 [18344.236715] softirqs last enabled at (6507072): [<ffffffff81041cb0>] __do_softirq+0x2df/0x3f5 [18344.236719] softirqs last disabled at (6507055): [<ffffffff81041fb5>] irq_exit+0x40/0x94 [18344.236722] other info that might help us debug this: [18344.236723] Possible unsafe locking scenario: [18344.236724] CPU0 [18344.236725] ---- [18344.236726] lock(&anon_vma->rwsem); [18344.236728] <Interrupt> [18344.236729] lock(&anon_vma->rwsem); [18344.236731] *** DEADLOCK *** [18344.236733] 2 locks held by khugepaged/32: [18344.236733] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff81134122>] khugepaged+0x5cf/0x1987 [18344.236738] #1: (&anon_vma->rwsem){++++?.}, at: [<ffffffff81134403>] khugepaged+0x8b0/0x1987 [18344.236741] stack backtrace: [18344.236744] CPU: 3 PID: 32 Comm: khugepaged Not tainted 4.3.0-rc1-next-20150918-dbg-00014-ge5128d0-dirty torvalds#361 [18344.236747] 0000000000000000 ffff880132827a00 ffffffff81230867 ffffffff8237ba90 [18344.236750] ffff880132827a38 ffffffff810ea9b9 000000000000000a ffff8801333b52e0 [18344.236753] ffff8801333b4c00 ffffffff8107b3ce 000000000000000a ffff880132827a78 [18344.236755] Call Trace: [18344.236758] [<ffffffff81230867>] dump_stack+0x4e/0x79 [18344.236761] [<ffffffff810ea9b9>] print_usage_bug.part.24+0x259/0x268 [18344.236763] [<ffffffff8107b3ce>] ? print_shortest_lock_dependencies+0x180/0x180 [18344.236765] [<ffffffff8107c7fc>] mark_lock+0x381/0x567 [18344.236766] [<ffffffff8107ca40>] mark_held_locks+0x5e/0x74 [18344.236768] [<ffffffff8107ee9f>] lockdep_trace_alloc+0xb0/0xb3 [18344.236771] [<ffffffff810f30cc>] __alloc_pages_nodemask+0x99/0x856 [18344.236772] [<ffffffff810ebaf9>] ? find_get_entry+0x14b/0x17a [18344.236774] [<ffffffff810ebb16>] ? find_get_entry+0x168/0x17a [18344.236777] [<ffffffff811226d9>] __read_swap_cache_async+0x7b/0x1aa [18344.236778] [<ffffffff8112281d>] read_swap_cache_async+0x15/0x2d [18344.236780] [<ffffffff8112294f>] swapin_readahead+0x11a/0x16a [18344.236783] [<ffffffff81112791>] do_swap_page+0xa7/0x36b [18344.236784] [<ffffffff81112791>] ? do_swap_page+0xa7/0x36b [18344.236787] [<ffffffff8113444c>] khugepaged+0x8f9/0x1987 [18344.236790] [<ffffffff810772f3>] ? wait_woken+0x88/0x88 [18344.236792] [<ffffffff81133b53>] ? maybe_pmd_mkwrite+0x1a/0x1a [18344.236794] [<ffffffff81059588>] kthread+0x107/0x10f [18344.236797] [<ffffffff81059481>] ? kthread_create_on_node+0x1ea/0x1ea [18344.236799] [<ffffffff8150c7bf>] ret_from_fork+0x3f/0x70 [18344.236801] [<ffffffff81059481>] ? kthread_create_on_node+0x1ea/0x1ea Signed-off-by: Kirill A. Shutemov <[email protected]> Reported-by: Sergey Senozhatsky <[email protected]> Tested-by: Sergey Senozhatsky <[email protected]> Cc: Ebru Akagunduz <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Andrea Arcangeli <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

…ent() Nested circular locking dependency detected by kernel robot (udevadm). udevadm/221 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [<ffffffff81262543>] __might_fault+0x83/0x150 but task is already holding lock: (s_active#12){++++.+}, at: [<ffffffff813315ee>] kernfs_fop_write+0x8e/0x250 which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(s_active); lock(cpu_hotplug.lock); lock(s_active); lock(&mm->mmap_sem); the existing dependency chain (in reverse order) is: -> #2 (s_active#12){++++.+}: [<ffffffff8117da2c>] lock_acquire+0xac/0x180 [<ffffffff8132f50a>] __kernfs_remove+0x2da/0x410 [<ffffffff81330630>] kernfs_remove_by_name_ns+0x40/0x90 [<ffffffff813339fb>] sysfs_remove_file_ns+0x2b/0x70 [<ffffffff81ba8a16>] device_del+0x166/0x320 [<ffffffff81ba943c>] device_destroy+0x3c/0x50 [<ffffffff8105aa61>] cpuid_class_cpu_callback+0x51/0x70 [<ffffffff81131ce9>] notifier_call_chain+0x59/0x190 [<ffffffff81132749>] __raw_notifier_call_chain+0x9/0x10 [<ffffffff810fe6b0>] __cpu_notify+0x40/0x90 [<ffffffff810fe890>] cpu_notify_nofail+0x10/0x30 [<ffffffff810fe8d7>] notify_dead+0x27/0x1e0 [<ffffffff810fe273>] cpuhp_down_callbacks+0x93/0x190 [<ffffffff82096062>] _cpu_down+0xc2/0x1e0 [<ffffffff810ff727>] do_cpu_down+0x37/0x50 [<ffffffff8110003b>] cpu_down+0xb/0x10 [<ffffffff81038e4d>] _debug_hotplug_cpu+0x7d/0xd0 [<ffffffff8435d6bb>] debug_hotplug_cpu+0xd/0x11 [<ffffffff84352426>] do_one_initcall+0x138/0x1cf [<ffffffff8435270a>] kernel_init_freeable+0x24d/0x2de [<ffffffff8209533a>] kernel_init+0xa/0x120 [<ffffffff820a7972>] ret_from_fork+0x22/0x50 -> #1 (cpu_hotplug.lock#2){+.+.+.}: [<ffffffff8117da2c>] lock_acquire+0xac/0x180 [<ffffffff820a20d1>] mutex_lock_nested+0x71/0x4c0 [<ffffffff810ff526>] get_online_cpus+0x66/0x80 [<ffffffff81246fb3>] sum_vm_event+0x23/0x1b0 [<ffffffff81293768>] collapse_huge_page+0x118/0x10b0 [<ffffffff81294c5d>] khugepaged+0x55d/0xe80 [<ffffffff81130304>] kthread+0x134/0x1a0 [<ffffffff820a7972>] ret_from_fork+0x22/0x50 -> #0 (&mm->mmap_sem){++++++}: [<ffffffff8117bf61>] __lock_acquire+0x2861/0x31f0 [<ffffffff8117da2c>] lock_acquire+0xac/0x180 [<ffffffff8126257e>] __might_fault+0xbe/0x150 [<ffffffff8133160f>] kernfs_fop_write+0xaf/0x250 [<ffffffff812a8933>] __vfs_write+0x43/0x1a0 [<ffffffff812a8d3a>] vfs_write+0xda/0x240 [<ffffffff812a8f84>] SyS_write+0x44/0xa0 [<ffffffff820a773c>] entry_SYSCALL_64_fastpath+0x1f/0xbd This patch moves sum_vm_event() before taking down_write(&mm->mmap_sem) to solve dependency lock. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ebru Akagunduz <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Rik van Riel <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Cyrill Gorcunov <[email protected]> Cc: Mel Gorman <[email protected]> Cc: David Rientjes <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

We must handle data access exception as well as memory address unaligned exceptions from return from trap window fill faults, not just normal TLB misses. Otherwise we can get an OOPS that looks like this: ld-linux.so.2(36808): Kernel bad sw trap 5 [#1] CPU: 1 PID: 36808 Comm: ld-linux.so.2 Not tainted 4.6.0 torvalds#34 task: fff8000303be5c60 ti: fff8000301344000 task.ti: fff8000301344000 TSTATE: 0000004410001601 TPC: 0000000000a1a784 TNPC: 0000000000a1a788 Y: 00000002 Not tainted TPC: <do_sparc64_fault+0x5c4/0x700> g0: fff8000024fc8248 g1: 0000000000db04dc g2: 0000000000000000 g3: 0000000000000001 g4: fff8000303be5c60 g5: fff800030e672000 g6: fff8000301344000 g7: 0000000000000001 o0: 0000000000b95ee8 o1: 000000000000012b o2: 0000000000000000 o3: 0000000200b9b358 o4: 0000000000000000 o5: fff8000301344040 sp: fff80003013475c1 ret_pc: 0000000000a1a77c RPC: <do_sparc64_fault+0x5bc/0x700> l0: 00000000000007ff l1: 0000000000000000 l2: 000000000000005f l3: 0000000000000000 l4: fff8000301347e98 l5: fff8000024ff3060 l6: 0000000000000000 l7: 0000000000000000 i0: fff8000301347f60 i1: 0000000000102400 i2: 0000000000000000 i3: 0000000000000000 i4: 0000000000000000 i5: 0000000000000000 i6: fff80003013476a1 i7: 0000000000404d4c I7: <user_rtt_fill_fixup+0x6c/0x7c> Call Trace: [0000000000404d4c] user_rtt_fill_fixup+0x6c/0x7c The window trap handlers are slightly clever, the trap table entries for them are composed of two pieces of code. First comes the code that actually performs the window fill or spill trap handling, and then there are three instructions at the end which are for exception processing. The userland register window fill handler is: add %sp, STACK_BIAS + 0x00, %g1; \ ldxa [%g1 + %g0] ASI, %l0; \ mov 0x08, %g2; \ mov 0x10, %g3; \ ldxa [%g1 + %g2] ASI, %l1; \ mov 0x18, %g5; \ ldxa [%g1 + %g3] ASI, %l2; \ ldxa [%g1 + %g5] ASI, %l3; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %l4; \ ldxa [%g1 + %g2] ASI, %l5; \ ldxa [%g1 + %g3] ASI, %l6; \ ldxa [%g1 + %g5] ASI, %l7; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %i0; \ ldxa [%g1 + %g2] ASI, %i1; \ ldxa [%g1 + %g3] ASI, %i2; \ ldxa [%g1 + %g5] ASI, %i3; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %i4; \ ldxa [%g1 + %g2] ASI, %i5; \ ldxa [%g1 + %g3] ASI, %i6; \ ldxa [%g1 + %g5] ASI, %i7; \ restored; \ retry; nop; nop; nop; nop; \ b,a,pt %xcc, fill_fixup_dax; \ b,a,pt %xcc, fill_fixup_mna; \ b,a,pt %xcc, fill_fixup; And the way this works is that if any of those memory accesses generate an exception, the exception handler can revector to one of those final three branch instructions depending upon which kind of exception the memory access took. In this way, the fault handler doesn't have to know if it was a spill or a fill that it's handling the fault for. It just always branches to the last instruction in the parent trap's handler. For example, for a regular fault, the code goes: winfix_trampoline: rdpr %tpc, %g3 or %g3, 0x7c, %g3 wrpr %g3, %tnpc done All window trap handlers are 0x80 aligned, so if we "or" 0x7c into the trap time program counter, we'll get that final instruction in the trap handler. On return from trap, we have to pull the register window in but we do this by hand instead of just executing a "restore" instruction for several reasons. The largest being that from Niagara and onward we simply don't have enough levels in the trap stack to fully resolve all possible exception cases of a window fault when we are already at trap level 1 (which we enter to get ready to return from the original trap). This is executed inline via the FILL_*_RTRAP handlers. rtrap_64.S's code branches directly to these to do the window fill by hand if necessary. Now if you look at them, we'll see at the end: ba,a,pt %xcc, user_rtt_fill_fixup; ba,a,pt %xcc, user_rtt_fill_fixup; ba,a,pt %xcc, user_rtt_fill_fixup; And oops, all three cases are handled like a fault. This doesn't work because each of these trap types (data access exception, memory address unaligned, and faults) store their auxiliary info in different registers to pass on to the C handler which does the real work. So in the case where the stack was unaligned, the unaligned trap handler sets up the arg registers one way, and then we branched to the fault handler which expects them setup another way. So the FAULT_TYPE_* value ends up basically being garbage, and randomly would generate the backtrace seen above. Reported-by: Nick Alcock <[email protected]> Signed-off-by: David S. Miller <[email protected]>

…os5420 The MFC IP is also inter-connected by an Async-Bridge so the CLK_ACLK333 has to be ungated during a power domain switch. Trying to do it when the clock is gated will fail and lead to an imprecise external abort error when the driver tries to access the MFC registers with the PD disabled. For example, if the s5p-mfc module is removed and the MFC PD turned off: [ 186.835606] Power domain power-domain@10044060 disable failed [ 186.835671] s5p-mfc 11000000.codec: Removing 11000000.codec [ 186.837670] Power domain power-domain@10044060 disable failed And when the module is inserted again: [ 2395.176956] s5p_mfc_wait_for_done_dev:34: Interrupt (dev->int_type:0, command:12) timed out [ 2395.177031] s5p_mfc_init_hw:272: Failed to load firmware [ 2395.177384] Unhandled fault: imprecise external abort (0x1406) at 0x00000000 [ 2395.177441] pgd = ec3b4000 [ 2395.177467] [00000000] *pgd=00000000 [ 2395.177507] Internal error: : 1406 [#1] PREEMPT SMP ARM [ 2395.177550] Modules linked in: s5p_mfc mwifiex_sdio mwifiex uvcvideo s5p_jpeg v4l2_mem2mem videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media [last unloaded: s5p_mfc] [ 2395.177774] CPU: 1 PID: 2382 Comm: v4l_id Tainted: G W 4.6.0-rc6-next-20160502-00010-g7730dc64d2c1-dirty torvalds#179 [ 2395.177857] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 2395.177906] task: ed275500 ti: e6c8c000 task.ti: e6c8c000 [ 2395.177996] PC is at s5p_mfc_reset+0x1c4/0x284 [s5p_mfc] [ 2395.178057] LR is at s5p_mfc_reset+0x1a4/0x284 [s5p_mfc] This patch fixes this issue by adding the CLK_ACLK333 as an Async-Bridge clock for the MFC power domain, so the PD configuration works properly. Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]>

Although unbinding a pinctrl driver requires root privileges but it still might be used theoretically in certain attacks (by triggering NULL pointer exception or memory corruption). Samsung pincontrol drivers are essential for system operation so their removal is not expected. They do not implement remove() driver callback and they are not buildable as modules. Suppression of the unbinding will prevent triggering NULL pointer exception like this (Odroid XU3): $ echo 13400000.pinctrl > /sys/bus/platform/drivers/samsung-pinctrl/unbind $ cat /sys/kernel/debug/gpio Unable to handle kernel NULL pointer dereference at virtual address 00000c44 pgd = ec41c000 [00000c44] *pgd=6d448835, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM (samsung_gpio_get) from [<c034f9a0>] (gpiolib_seq_show+0x1b0/0x26c) (gpiolib_seq_show) from [<c01fb8c0>] (seq_read+0x304/0x4b8) (seq_read) from [<c02dbc78>] (full_proxy_read+0x4c/0x64) (full_proxy_read) from [<c01d9fb0>] (__vfs_read+0x2c/0x110) (__vfs_read) from [<c01db400>] (vfs_read+0x8c/0x110) (vfs_read) from [<c01db4c4>] (SyS_read+0x40/0x8c) (SyS_read) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c) Suggested-by: Marek Szyprowski <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Linus Walleij <[email protected]>

Lets provide the basic machine information for dump_stack on s390. This enables the "Hardware name:" line and results in output like [...] Oops: 0004 ilc:2 [#1] SMP Modules linked in: CPU: 1 PID: 74 Comm: sh Not tainted 4.5.0+ torvalds#205 Hardware name: IBM 2964 NC9 704 (KVM) [...] Signed-off-by: Christian Borntraeger <[email protected]> Acked-by: Heiko Carstens <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>

In many cases in the RCU tree code, we iterate over the set of cpus for a leaf node described by rcu_node::grplo and rcu_node::grphi, checking per-cpu data for each cpu in this range. However, if the set of possible cpus is sparse, some cpus described in this range are not possible, and thus no per-cpu region will have been allocated (or initialised) for them by the generic percpu code. Erroneous accesses to a per-cpu area for these !possible cpus may fault or may hit other data depending on the addressed generated when the erroneous per cpu offset is applied. In practice, both cases have been observed on arm64 hardware (the former being silent, but detectable with additional patches). To avoid issues resulting from this, we must iterate over the set of *possible* cpus for a given leaf node. This patch add a new helper, for_each_leaf_node_possible_cpu, to enable this. As iteration is often intertwined with rcu_node local bitmask manipulation, a new leaf_node_cpu_bit helper is added to make this simpler and more consistent. The RCU tree code is made to use both of these where appropriate. Without this patch, running reboot at a shell can result in an oops like: [ 3369.075979] Unable to handle kernel paging request at virtual address ffffff8008b21b4c [ 3369.083881] pgd = ffffffc3ecdda000 [ 3369.087270] [ffffff8008b21b4c] *pgd=00000083eca48003, *pud=00000083eca48003, *pmd=0000000000000000 [ 3369.096222] Internal error: Oops: 96000007 [#1] PREEMPT SMP [ 3369.101781] Modules linked in: [ 3369.104825] CPU: 2 PID: 1817 Comm: NetworkManager Tainted: G W 4.6.0+ #3 [ 3369.121239] task: ffffffc0fa13e000 ti: ffffffc3eb940000 task.ti: ffffffc3eb940000 [ 3369.128708] PC is at sync_rcu_exp_select_cpus+0x188/0x510 [ 3369.134094] LR is at sync_rcu_exp_select_cpus+0x104/0x510 [ 3369.139479] pc : [<ffffff80081109a8>] lr : [<ffffff8008110924>] pstate: 200001c5 [ 3369.146860] sp : ffffffc3eb9435a0 [ 3369.150162] x29: ffffffc3eb9435a0 x28: ffffff8008be4f88 [ 3369.155465] x27: ffffff8008b66c80 x26: ffffffc3eceb2600 [ 3369.160767] x25: 0000000000000001 x24: ffffff8008be4f88 [ 3369.166070] x23: ffffff8008b51c3c x22: ffffff8008b66c80 [ 3369.171371] x21: 0000000000000001 x20: ffffff8008b21b40 [ 3369.176673] x19: ffffff8008b66c80 x18: 0000000000000000 [ 3369.181975] x17: 0000007fa951a010 x16: ffffff80086a30f0 [ 3369.187278] x15: 0000007fa9505590 x14: 0000000000000000 [ 3369.192580] x13: ffffff8008b51000 x12: ffffffc3eb940000 [ 3369.197882] x11: 0000000000000006 x10: ffffff8008b51b78 [ 3369.203184] x9 : 0000000000000001 x8 : ffffff8008be4000 [ 3369.208486] x7 : ffffff8008b21b40 x6 : 0000000000001003 [ 3369.213788] x5 : 0000000000000000 x4 : ffffff8008b27280 [ 3369.219090] x3 : ffffff8008b21b4c x2 : 0000000000000001 [ 3369.224406] x1 : 0000000000000001 x0 : 0000000000000140 ... [ 3369.972257] [<ffffff80081109a8>] sync_rcu_exp_select_cpus+0x188/0x510 [ 3369.978685] [<ffffff80081128b4>] synchronize_rcu_expedited+0x64/0xa8 [ 3369.985026] [<ffffff80086b987c>] synchronize_net+0x24/0x30 [ 3369.990499] [<ffffff80086ddb54>] dev_deactivate_many+0x28c/0x298 [ 3369.996493] [<ffffff80086b6bb8>] __dev_close_many+0x60/0xd0 [ 3370.002052] [<ffffff80086b6d48>] __dev_close+0x28/0x40 [ 3370.007178] [<ffffff80086bf62c>] __dev_change_flags+0x8c/0x158 [ 3370.012999] [<ffffff80086bf718>] dev_change_flags+0x20/0x60 [ 3370.018558] [<ffffff80086cf7f0>] do_setlink+0x288/0x918 [ 3370.023771] [<ffffff80086d0798>] rtnl_newlink+0x398/0x6a8 [ 3370.029158] [<ffffff80086cee84>] rtnetlink_rcv_msg+0xe4/0x220 [ 3370.034891] [<ffffff80086e274c>] netlink_rcv_skb+0xc4/0xf8 [ 3370.040364] [<ffffff80086ced8c>] rtnetlink_rcv+0x2c/0x40 [ 3370.045663] [<ffffff80086e1fe8>] netlink_unicast+0x160/0x238 [ 3370.051309] [<ffffff80086e24b8>] netlink_sendmsg+0x2f0/0x358 [ 3370.056956] [<ffffff80086a0070>] sock_sendmsg+0x18/0x30 [ 3370.062168] [<ffffff80086a21cc>] ___sys_sendmsg+0x26c/0x280 [ 3370.067728] [<ffffff80086a30ac>] __sys_sendmsg+0x44/0x88 [ 3370.073027] [<ffffff80086a3100>] SyS_sendmsg+0x10/0x20 [ 3370.078153] [<ffffff8008085e70>] el0_svc_naked+0x24/0x28 Signed-off-by: Mark Rutland <[email protected]> Reported-by: Dennis Chen <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Lai Jiangshan <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Steve Capper <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Signed-off-by: Paul E. McKenney <[email protected]>

This patch fixes a typo in khugepaged_scan_pmd(): instead of setting "result" to SCAN_EXCEED_SWAP_PTE we set "ret". Setting "ret" results in an attempt to collapse a huge page although we meant aborting the scan. As a result, we can call khugepaged_find_target_node() with all entries in the khugepaged_node_load array being zeros. The latter is not ready for that and might return an offline node on such input. This leads to a warning followed by kernel panic: WARNING: CPU: 1 PID: 40 at include/linux/gfp.h:314 khugepaged_alloc_page+0xd4/0xf0() CPU: 1 PID: 40 Comm: khugepaged Not tainted 4.3.0-rc1-mm1+ torvalds#102 000000000000013a ffff88010ae77b58 ffffffff813270d4 ffffffff818cda31 0000000000000000 ffff88010ae77b98 ffffffff8107c9f5 dead000000000100 ffff88010ae77e70 0000000000c752da 0000000000000001 0000000000000000 Call Trace: [<ffffffff813270d4>] dump_stack+0x48/0x64 [<ffffffff8107c9f5>] warn_slowpath_common+0x95/0xe0 [<ffffffff8107ca5a>] warn_slowpath_null+0x1a/0x20 [<ffffffff811ec124>] khugepaged_alloc_page+0xd4/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 BUG: unable to handle kernel paging request at 0000000000014028 IP: [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 PGD aaac7067 PUD aaac606 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 40 Comm: khugepaged Tainted: G W 4.3.0-rc1-mm1+ torvalds#102 task: ffff88010ae16400 ti: ffff88010ae74000 task.ti: ffff88010ae74000 RIP: 0010:[<ffffffff81185eb2>] [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP: 0018:ffff88010ae77ad8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000014020 RCX: 0000000000000014 RDX: 0000000000000000 RSI: 0000000000000009 RDI: 0000000000c752da RBP: ffff88010ae77ba8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000c752da FS: 0000000000000000(0000) GS:ffff88010be40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000014028 CR3: 00000000aaac4000 CR4: 00000000000006e0 Stack: ffff88010ae77ae8 ffffffff810d0b3b ffff88010ae77b48 ffffffff81179e73 0000000000000010 ffff88010ae77b58 ffff88010ae77b18 ffffffff811ec124 ffff88010ae77b38 00000009a6e3aff4 0000000000000000 0000000000000000 Call Trace: [<ffffffff810d0b3b>] ? vprintk_default+0x2b/0x40 [<ffffffff81179e73>] ? printk+0x46/0x48 [<ffffffff811ec124>] ? khugepaged_alloc_page+0xd4/0xf0 [<ffffffff8107ca04>] ? warn_slowpath_common+0xa4/0xe0 [<ffffffff811ec0cd>] khugepaged_alloc_page+0x7d/0xf0 [<ffffffff811f15c8>] collapse_huge_page+0x58/0x550 [<ffffffff810b38e6>] ? account_entity_dequeue+0xb6/0xd0 [<ffffffff810b5289>] ? idle_balance+0x79/0x2b0 [<ffffffff811f1f5e>] khugepaged_scan_pmd+0x49e/0x710 [<ffffffff810e1f3a>] ? lock_timer_base+0x5a/0x80 [<ffffffff810e1fbb>] ? try_to_del_timer_sync+0x5b/0x70 [<ffffffff810e214c>] ? del_timer_sync+0x4c/0x60 [<ffffffff8168242f>] ? schedule_timeout+0x11f/0x200 [<ffffffff811f2330>] khugepaged_scan_mm_slot+0x160/0x2a0 [<ffffffff811f255f>] khugepaged_do_scan+0xef/0x160 [<ffffffff810bcdb0>] ? wait_woken+0x80/0x80 [<ffffffff811f25d0>] ? khugepaged_do_scan+0x160/0x160 [<ffffffff811f25f8>] khugepaged+0x28/0x80 [<ffffffff8109ab1c>] kthread+0xcc/0xf0 [<ffffffff810a667e>] ? schedule_tail+0x1e/0xc0 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168371f>] ret_from_fork+0x3f/0x70 [<ffffffff8109aa50>] ? kthread_freezable_should_stop+0x70/0x70 RIP [<ffffffff81185eb2>] __alloc_pages_nodemask+0xc2/0x2c0 RSP <ffff88010ae77ad8> CR2: 0000000000014028 Fixes: acc067d ("mm: make optimistic check for swapin readahead") Signed-off-by: Vladimir Davydov <[email protected]> Cc: Ebru Akagunduz <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

khugepaged does swap in during collapse under anon_vma lock. It causes complain from lockdep. The trace below shows following scenario: - khugepaged tries to swap in a page under mmap_sem and anon_vma lock; - do_swap_page() calls swapin_readahead() with GFP_HIGHUSER_MOVABLE; - __read_swap_cache_async() tries to allocate the page for swap in; - lockdep_trace_alloc() in __alloc_pages_nodemask() notices that with given gfp_mask we could end up in direct relaim. - Lockdep already knows that reclaim sometimes (e.g. in case of split_huge_page()) wants to take anon_vma lock on its own. Therefore deadlock is possible. The fix is to take anon_vma lock after swap in. [18344.236625] ================================= [18344.236628] [ INFO: inconsistent lock state ] [18344.236633] 4.3.0-rc1-next-20150918-dbg-00014-ge5128d0-dirty torvalds#361 Not tainted [18344.236636] --------------------------------- [18344.236640] inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage. [18344.236645] khugepaged/32 [HC0[0]:SC0[0]:HE1:SE1] takes: [18344.236648] (&anon_vma->rwsem){++++?.}, at: [<ffffffff81134403>] khugepaged+0x8b0/0x1987 [18344.236662] {IN-RECLAIM_FS-W} state was registered at: [18344.236666] [<ffffffff8107d747>] __lock_acquire+0x8e2/0x1183 [18344.236673] [<ffffffff8107e7ac>] lock_acquire+0x10b/0x1a6 [18344.236678] [<ffffffff8150a367>] down_write+0x3b/0x6a [18344.236686] [<ffffffff811360d8>] split_huge_page_to_list+0x5b/0x61f [18344.236689] [<ffffffff811224b3>] add_to_swap+0x37/0x78 [18344.236691] [<ffffffff810fd650>] shrink_page_list+0x4c2/0xb9a [18344.236694] [<ffffffff810fe47c>] shrink_inactive_list+0x371/0x5d9 [18344.236696] [<ffffffff810fee2f>] shrink_lruvec+0x410/0x5ae [18344.236698] [<ffffffff810ff024>] shrink_zone+0x57/0x140 [18344.236700] [<ffffffff810ffc79>] kswapd+0x6a5/0x91b [18344.236702] [<ffffffff81059588>] kthread+0x107/0x10f [18344.236706] [<ffffffff8150c7bf>] ret_from_fork+0x3f/0x70 [18344.236708] irq event stamp: 6517947 [18344.236709] hardirqs last enabled at (6517947): [<ffffffff810f2d0c>] get_page_from_freelist+0x362/0x59e [18344.236713] hardirqs last disabled at (6517946): [<ffffffff8150ba41>] _raw_spin_lock_irqsave+0x18/0x51 [18344.236715] softirqs last enabled at (6507072): [<ffffffff81041cb0>] __do_softirq+0x2df/0x3f5 [18344.236719] softirqs last disabled at (6507055): [<ffffffff81041fb5>] irq_exit+0x40/0x94 [18344.236722] other info that might help us debug this: [18344.236723] Possible unsafe locking scenario: [18344.236724] CPU0 [18344.236725] ---- [18344.236726] lock(&anon_vma->rwsem); [18344.236728] <Interrupt> [18344.236729] lock(&anon_vma->rwsem); [18344.236731] *** DEADLOCK *** [18344.236733] 2 locks held by khugepaged/32: [18344.236733] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff81134122>] khugepaged+0x5cf/0x1987 [18344.236738] #1: (&anon_vma->rwsem){++++?.}, at: [<ffffffff81134403>] khugepaged+0x8b0/0x1987 [18344.236741] stack backtrace: [18344.236744] CPU: 3 PID: 32 Comm: khugepaged Not tainted 4.3.0-rc1-next-20150918-dbg-00014-ge5128d0-dirty torvalds#361 [18344.236747] 0000000000000000 ffff880132827a00 ffffffff81230867 ffffffff8237ba90 [18344.236750] ffff880132827a38 ffffffff810ea9b9 000000000000000a ffff8801333b52e0 [18344.236753] ffff8801333b4c00 ffffffff8107b3ce 000000000000000a ffff880132827a78 [18344.236755] Call Trace: [18344.236758] [<ffffffff81230867>] dump_stack+0x4e/0x79 [18344.236761] [<ffffffff810ea9b9>] print_usage_bug.part.24+0x259/0x268 [18344.236763] [<ffffffff8107b3ce>] ? print_shortest_lock_dependencies+0x180/0x180 [18344.236765] [<ffffffff8107c7fc>] mark_lock+0x381/0x567 [18344.236766] [<ffffffff8107ca40>] mark_held_locks+0x5e/0x74 [18344.236768] [<ffffffff8107ee9f>] lockdep_trace_alloc+0xb0/0xb3 [18344.236771] [<ffffffff810f30cc>] __alloc_pages_nodemask+0x99/0x856 [18344.236772] [<ffffffff810ebaf9>] ? find_get_entry+0x14b/0x17a [18344.236774] [<ffffffff810ebb16>] ? find_get_entry+0x168/0x17a [18344.236777] [<ffffffff811226d9>] __read_swap_cache_async+0x7b/0x1aa [18344.236778] [<ffffffff8112281d>] read_swap_cache_async+0x15/0x2d [18344.236780] [<ffffffff8112294f>] swapin_readahead+0x11a/0x16a [18344.236783] [<ffffffff81112791>] do_swap_page+0xa7/0x36b [18344.236784] [<ffffffff81112791>] ? do_swap_page+0xa7/0x36b [18344.236787] [<ffffffff8113444c>] khugepaged+0x8f9/0x1987 [18344.236790] [<ffffffff810772f3>] ? wait_woken+0x88/0x88 [18344.236792] [<ffffffff81133b53>] ? maybe_pmd_mkwrite+0x1a/0x1a [18344.236794] [<ffffffff81059588>] kthread+0x107/0x10f [18344.236797] [<ffffffff81059481>] ? kthread_create_on_node+0x1ea/0x1ea [18344.236799] [<ffffffff8150c7bf>] ret_from_fork+0x3f/0x70 [18344.236801] [<ffffffff81059481>] ? kthread_create_on_node+0x1ea/0x1ea Signed-off-by: Kirill A. Shutemov <[email protected]> Reported-by: Sergey Senozhatsky <[email protected]> Tested-by: Sergey Senozhatsky <[email protected]> Cc: Ebru Akagunduz <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Andrea Arcangeli <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

…ent() Nested circular locking dependency detected by kernel robot (udevadm). udevadm/221 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [<ffffffff81262543>] __might_fault+0x83/0x150 but task is already holding lock: (s_active#12){++++.+}, at: [<ffffffff813315ee>] kernfs_fop_write+0x8e/0x250 which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(s_active); lock(cpu_hotplug.lock); lock(s_active); lock(&mm->mmap_sem); the existing dependency chain (in reverse order) is: -> #2 (s_active#12){++++.+}: [<ffffffff8117da2c>] lock_acquire+0xac/0x180 [<ffffffff8132f50a>] __kernfs_remove+0x2da/0x410 [<ffffffff81330630>] kernfs_remove_by_name_ns+0x40/0x90 [<ffffffff813339fb>] sysfs_remove_file_ns+0x2b/0x70 [<ffffffff81ba8a16>] device_del+0x166/0x320 [<ffffffff81ba943c>] device_destroy+0x3c/0x50 [<ffffffff8105aa61>] cpuid_class_cpu_callback+0x51/0x70 [<ffffffff81131ce9>] notifier_call_chain+0x59/0x190 [<ffffffff81132749>] __raw_notifier_call_chain+0x9/0x10 [<ffffffff810fe6b0>] __cpu_notify+0x40/0x90 [<ffffffff810fe890>] cpu_notify_nofail+0x10/0x30 [<ffffffff810fe8d7>] notify_dead+0x27/0x1e0 [<ffffffff810fe273>] cpuhp_down_callbacks+0x93/0x190 [<ffffffff82096062>] _cpu_down+0xc2/0x1e0 [<ffffffff810ff727>] do_cpu_down+0x37/0x50 [<ffffffff8110003b>] cpu_down+0xb/0x10 [<ffffffff81038e4d>] _debug_hotplug_cpu+0x7d/0xd0 [<ffffffff8435d6bb>] debug_hotplug_cpu+0xd/0x11 [<ffffffff84352426>] do_one_initcall+0x138/0x1cf [<ffffffff8435270a>] kernel_init_freeable+0x24d/0x2de [<ffffffff8209533a>] kernel_init+0xa/0x120 [<ffffffff820a7972>] ret_from_fork+0x22/0x50 -> #1 (cpu_hotplug.lock#2){+.+.+.}: [<ffffffff8117da2c>] lock_acquire+0xac/0x180 [<ffffffff820a20d1>] mutex_lock_nested+0x71/0x4c0 [<ffffffff810ff526>] get_online_cpus+0x66/0x80 [<ffffffff81246fb3>] sum_vm_event+0x23/0x1b0 [<ffffffff81293768>] collapse_huge_page+0x118/0x10b0 [<ffffffff81294c5d>] khugepaged+0x55d/0xe80 [<ffffffff81130304>] kthread+0x134/0x1a0 [<ffffffff820a7972>] ret_from_fork+0x22/0x50 -> #0 (&mm->mmap_sem){++++++}: [<ffffffff8117bf61>] __lock_acquire+0x2861/0x31f0 [<ffffffff8117da2c>] lock_acquire+0xac/0x180 [<ffffffff8126257e>] __might_fault+0xbe/0x150 [<ffffffff8133160f>] kernfs_fop_write+0xaf/0x250 [<ffffffff812a8933>] __vfs_write+0x43/0x1a0 [<ffffffff812a8d3a>] vfs_write+0xda/0x240 [<ffffffff812a8f84>] SyS_write+0x44/0xa0 [<ffffffff820a773c>] entry_SYSCALL_64_fastpath+0x1f/0xbd This patch moves sum_vm_event() before taking down_write(&mm->mmap_sem) to solve dependency lock. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ebru Akagunduz <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Rik van Riel <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Cyrill Gorcunov <[email protected]> Cc: Mel Gorman <[email protected]> Cc: David Rientjes <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

We must not attempt to send WMI packets while holding the data-lock, as it may deadlock: BUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath10k/wmi.c:1824 in_atomic(): 1, irqs_disabled(): 0, pid: 2878, name: wpa_supplicant ============================================= [ INFO: possible recursive locking detected ] 4.4.6+ torvalds#21 Tainted: G W O --------------------------------------------- wpa_supplicant/2878 is trying to acquire lock: (&(&ar->data_lock)->rlock){+.-...}, at: [<ffffffffa0721511>] ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core] but task is already holding lock: (&(&ar->data_lock)->rlock){+.-...}, at: [<ffffffffa070251b>] ath10k_peer_create+0x122/0x1ae [ath10k_core] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&ar->data_lock)->rlock); lock(&(&ar->data_lock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by wpa_supplicant/2878: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff816493ca>] rtnl_lock+0x12/0x14 #1: (&ar->conf_mutex){+.+.+.}, at: [<ffffffffa0706932>] ath10k_add_interface+0x3b/0xbda [ath10k_core] #2: (&(&ar->data_lock)->rlock){+.-...}, at: [<ffffffffa070251b>] ath10k_peer_create+0x122/0x1ae [ath10k_core] #3: (rcu_read_lock){......}, at: [<ffffffffa062f304>] rcu_read_lock+0x0/0x66 [mac80211] stack backtrace: CPU: 3 PID: 2878 Comm: wpa_supplicant Tainted: G W O 4.4.6+ torvalds#21 Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013 0000000000000000 ffff8801fcadf8f0 ffffffff8137086d ffffffff82681720 ffffffff82681720 ffff8801fcadf9b0 ffffffff8112e3be ffff8801fcadf920 0000000100000000 ffffffff82681720 ffffffffa0721500 ffff8801fcb8d348 Call Trace: [<ffffffff8137086d>] dump_stack+0x81/0xb6 [<ffffffff8112e3be>] __lock_acquire+0xc5b/0xde7 [<ffffffffa0721500>] ? ath10k_wmi_tx_beacons_iter+0x15/0x11a [ath10k_core] [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201 [<ffffffff8112e908>] lock_acquire+0x132/0x1cb [<ffffffff8112e908>] ? lock_acquire+0x132/0x1cb [<ffffffffa0721511>] ? ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core] [<ffffffffa07214eb>] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core] [<ffffffff816f9e2b>] _raw_spin_lock_bh+0x31/0x40 [<ffffffffa0721511>] ? ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core] [<ffffffffa0721511>] ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core] [<ffffffffa07214eb>] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core] [<ffffffffa062eb18>] __iterate_interfaces+0x9d/0x13d [mac80211] [<ffffffffa062f609>] ieee80211_iterate_active_interfaces_atomic+0x32/0x3e [mac80211] [<ffffffffa07214eb>] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core] [<ffffffffa071fa9f>] ath10k_wmi_tx_beacons_nowait.isra.13+0x14/0x16 [ath10k_core] [<ffffffffa0721676>] ath10k_wmi_cmd_send+0x71/0x242 [ath10k_core] [<ffffffffa07023f6>] ath10k_wmi_peer_delete+0x3f/0x42 [ath10k_core] [<ffffffffa0702557>] ath10k_peer_create+0x15e/0x1ae [ath10k_core] [<ffffffffa0707004>] ath10k_add_interface+0x70d/0xbda [ath10k_core] [<ffffffffa05fffcc>] drv_add_interface+0x123/0x1a5 [mac80211] [<ffffffffa061554b>] ieee80211_do_open+0x351/0x667 [mac80211] [<ffffffffa06158aa>] ieee80211_open+0x49/0x4c [mac80211] [<ffffffff8163ecf9>] __dev_open+0x88/0xde [<ffffffff8163ef6e>] __dev_change_flags+0xa4/0x13a [<ffffffff8163f023>] dev_change_flags+0x1f/0x54 [<ffffffff816a5532>] devinet_ioctl+0x2b9/0x5c9 [<ffffffff816514dd>] ? copy_to_user+0x32/0x38 [<ffffffff816a6115>] inet_ioctl+0x81/0x9d [<ffffffff816a6115>] ? inet_ioctl+0x81/0x9d [<ffffffff81621cf8>] sock_do_ioctl+0x20/0x3d [<ffffffff816223c4>] sock_ioctl+0x222/0x22e [<ffffffff8121cf95>] do_vfs_ioctl+0x453/0x4d7 [<ffffffff81625603>] ? __sys_recvmsg+0x4c/0x5b [<ffffffff81225af1>] ? __fget_light+0x48/0x6c [<ffffffff8121d06b>] SyS_ioctl+0x52/0x74 [<ffffffff816fa736>] entry_SYSCALL_64_fastpath+0x16/0x7a Signed-off-by: Ben Greear <[email protected]> Signed-off-by: Kalle Valo <[email protected]>

In commit f9476a6 ("drm/i915: Refactor platform specifics out of intel_get_shared_dpll()"), the ibx_get_dpll() function lacked an error check, that can lead to a NULL pointer dereference when trying to enable three pipes. BUG: unable to handle kernel NULL pointer dereference at 0000000000000068 IP: [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915] PGD cec87067 PUD d30ce067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: snd_hda_intel i915 drm_kms_helper drm intel_gtt sch_fq_codel cfg80211 binfmt_misc i2c_algo_bit cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp agpgart kvm_intel snd_hda_codec_hdmi kvm iTCO_wdt snd_hda_codec_realtek snd_hda_codec_generic irqbypass aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse pcspkr snd_hda_codec i2c_i801 snd_hwdep snd_hda_core snd_pcm snd_timer lpc_ich mfd_core snd soundcore wmi evdev tpm_tis tpm [last unloaded: drm] CPU: 3 PID: 5810 Comm: kms_flip Tainted: G U W 4.6.0-test+ #3 Hardware name: /DZ77BH-55K, BIOS BHZ7710H.86A.0100.2013.0517.0942 05/17/2013 task: ffff8800d3908040 ti: ffff8801166c8000 task.ti: ffff8801166c8000 RIP: 0010:[<ffffffffa0482275>] [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915] RSP: 0018:ffff8801166cba60 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000002 RDX: 0000000000000001 RSI: ffff8800d07f1bf8 RDI: 0000000000000000 RBP: ffff8801166cba88 R08: 0000000000000002 R09: ffff8800d32e5698 R10: 0000000000000001 R11: ffff8800cc89ac88 R12: ffff8800d07f1bf8 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f4c3fc8d8c0(0000) GS:ffff88011bcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000068 CR3: 00000000d3b4c000 CR4: 00000000001406e0 Stack: 0000000000000000 ffff8800d07f1bf8 0000000000000000 ffff8800d04c0000 0000000000000000 ffff8801166cbaa8 ffffffffa04823a7 ffff8800d07f1bf8 ffff8800d32e5698 ffff8801166cbab8 ffffffffa04840cf ffff8801166cbaf0 Call Trace: [<ffffffffa04823a7>] ibx_get_dpll+0x47/0xa0 [i915] [<ffffffffa04840cf>] intel_get_shared_dpll+0x1f/0x50 [i915] [<ffffffffa046d080>] ironlake_crtc_compute_clock+0x280/0x430 [i915] [<ffffffffa0472ac0>] intel_crtc_atomic_check+0x240/0x320 [i915] [<ffffffffa03da18e>] drm_atomic_helper_check_planes+0x14e/0x1d0 [drm_kms_helper] [<ffffffffa0474a0c>] intel_atomic_check+0x5dc/0x1110 [i915] [<ffffffffa029d3aa>] drm_atomic_check_only+0x14a/0x660 [drm] [<ffffffffa029d086>] ? drm_atomic_set_crtc_for_connector+0x96/0x100 [drm] [<ffffffffa029d8d7>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa03dc3b7>] restore_fbdev_mode+0x237/0x260 [drm_kms_helper] [<ffffffffa029c65a>] ? drm_modeset_lock_all_ctx+0x9a/0xb0 [drm] [<ffffffffa03de9b3>] drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper] [<ffffffffa03dea2d>] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] [<ffffffffa03de93a>] drm_fb_helper_hotplug_event+0xaa/0xf0 [drm_kms_helper] [<ffffffffa03de9d6>] drm_fb_helper_restore_fbdev_mode_unlocked+0x56/0x80 [drm_kms_helper] [<ffffffffa0490f72>] intel_fbdev_restore_mode+0x22/0x80 [i915] [<ffffffffa04ba45e>] i915_driver_lastclose+0xe/0x20 [i915] [<ffffffffa02810de>] drm_lastclose+0x2e/0x130 [drm] [<ffffffffa028148c>] drm_release+0x2ac/0x4b0 [drm] [<ffffffff811a6b2d>] __fput+0xed/0x1f0 [<ffffffff811a6c6e>] ____fput+0xe/0x10 [<ffffffff81079156>] task_work_run+0x76/0xb0 [<ffffffff8105aaab>] do_exit+0x3ab/0xc60 [<ffffffff810a145f>] ? trace_hardirqs_on_caller+0x12f/0x1c0 [<ffffffff8105c67e>] do_group_exit+0x4e/0xc0 [<ffffffff8105c704>] SyS_exit_group+0x14/0x20 [<ffffffff8158bb25>] entry_SYSCALL_64_fastpath+0x18/0xa8 Code: 14 80 48 8d 34 90 b8 01 00 00 00 d3 e0 09 04 b3 5b 41 5c 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 55 41 54 53 <44> 8b 67 68 48 89 f3 48 8b be 08 02 00 00 4c 8b 2e e8 15 9d fd RIP [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915] RSP <ffff8801166cba60> CR2: 0000000000000068 Cc: Ville Syrjälä <[email protected]> Cc: [email protected] Reported-by: Ville Syrjälä <[email protected]> Fixes: f9476a6 ("drm/i915: Refactor platform specifics out of intel_get_shared_dpll()") Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Tested-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1463748426-5956-1-git-send-email-ander.conselvan.de.oliveira@intel.com (cherry picked from commit bb14316) Signed-off-by: Jani Nikula <[email protected]>

I see a hang when enabling sched events: echo 1 > /sys/kernel/debug/tracing/events/sched/enable The printk buffer shows: BUG: spinlock recursion on CPU#1, swapper/1/0 lock: 0xffff88007d5d8c00, .magic: dead4ead, .owner: swapper/1/0, .owner_cpu: 1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.7.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 ... Call Trace: <IRQ> [<ffffffff8143d663>] dump_stack+0x85/0xc2 [<ffffffff81115948>] spin_dump+0x78/0xc0 [<ffffffff81115aea>] do_raw_spin_lock+0x11a/0x150 [<ffffffff81891471>] _raw_spin_lock+0x61/0x80 [<ffffffff810e5466>] ? try_to_wake_up+0x256/0x4e0 [<ffffffff810e5466>] try_to_wake_up+0x256/0x4e0 [<ffffffff81891a0a>] ? _raw_spin_unlock_irqrestore+0x4a/0x80 [<ffffffff810e5705>] wake_up_process+0x15/0x20 [<ffffffff810cebb4>] insert_work+0x84/0xc0 [<ffffffff810ced7f>] __queue_work+0x18f/0x660 [<ffffffff810cf9a6>] queue_work_on+0x46/0x90 [<ffffffffa00cd95b>] drm_fb_helper_dirty.isra.11+0xcb/0xe0 [drm_kms_helper] [<ffffffffa00cdac0>] drm_fb_helper_sys_imageblit+0x30/0x40 [drm_kms_helper] [<ffffffff814babcd>] soft_cursor+0x1ad/0x230 [<ffffffff814ba379>] bit_cursor+0x649/0x680 [<ffffffff814b9d30>] ? update_attr.isra.2+0x90/0x90 [<ffffffff814b5e6a>] fbcon_cursor+0x14a/0x1c0 [<ffffffff81555ef8>] hide_cursor+0x28/0x90 [<ffffffff81558b6f>] vt_console_print+0x3bf/0x3f0 [<ffffffff81122c63>] call_console_drivers.constprop.24+0x183/0x200 [<ffffffff811241f4>] console_unlock+0x3d4/0x610 [<ffffffff811247f5>] vprintk_emit+0x3c5/0x610 [<ffffffff81124bc9>] vprintk_default+0x29/0x40 [<ffffffff811e965b>] printk+0x57/0x73 [<ffffffff810f7a9e>] enqueue_entity+0xc2e/0xc70 [<ffffffff810f7b39>] enqueue_task_fair+0x59/0xab0 [<ffffffff8106dcd9>] ? kvm_sched_clock_read+0x9/0x20 [<ffffffff8103fb39>] ? sched_clock+0x9/0x10 [<ffffffff810e3fcc>] activate_task+0x5c/0xa0 [<ffffffff810e4514>] ttwu_do_activate+0x54/0xb0 [<ffffffff810e5cea>] sched_ttwu_pending+0x7a/0xb0 [<ffffffff810e5e51>] scheduler_ipi+0x61/0x170 [<ffffffff81059e7f>] smp_trace_reschedule_interrupt+0x4f/0x2a0 [<ffffffff81893ba6>] trace_reschedule_interrupt+0x96/0xa0 <EOI> [<ffffffff8106e0d6>] ? native_safe_halt+0x6/0x10 [<ffffffff8110fb1d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81040ac0>] default_idle+0x20/0x1a0 [<ffffffff8104147f>] arch_cpu_idle+0xf/0x20 [<ffffffff81102f8f>] default_idle_call+0x2f/0x50 [<ffffffff8110332e>] cpu_startup_entry+0x37e/0x450 [<ffffffff8105af70>] start_secondary+0x160/0x1a0 Note the hang only occurs when echoing the above from a physical serial console, not from an ssh session. The bug is caused by a deadlock where the task is trying to grab the rq lock twice because printk()'s aren't safe in sched code. Signed-off-by: Josh Poimboeuf <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Mike Galbraith <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Srikar Dronamraju <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Fixes: cb25176 ("sched/debug: Make schedstats a runtime tunable that is disabled by default") Link: http://lkml.kernel.org/r/20160613073209.gdvdybiruljbkn3p@treble Signed-off-by: Ingo Molnar <[email protected]>

…r_set_config Since commit 0955c12 ("drm/crtc: take references to connectors used in a modeset. (v2)"), the reference counts of all connectors in the drm_mode_set given to drm_crtc_helper_set_config are incremented, and then the reference counts of all connectors are decremented on success, but in a temporary copy of the connector structure. This leads to the following error after the first modeset on imx-drm: Unable to handle kernel NULL pointer dereference at virtual address 00000004 pgd = ad8c4000 [00000004] *pgd=3d9c5831, *pte=00000000, *ppte=00000000 Internal error: Oops: 817 [#1] PREEMPT SMP ARM Modules linked in: CPU: 1 PID: 190 Comm: kmsfb-manage Not tainted 4.7.0-rc1+ torvalds#657 Hardware name: Freescale i.MX6 Quad/DualLit: [<80506098>] lr : [<80252e94>] psr: 200c0013 sp : adca7ca8 ip : adca7b90 fp : adca7cd4 r10: 00000000 r9 : 00000100 r8 : 00000200 r7 : af3c9800 r6 : aded7848 r5 : aded7800 r4 : 00000000 r3 : af3ca058 r2 : 00000200 r1 : af3ca058 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 3d8c404a DAC: 00000051 Process kmsfb-manage (pid: 190, stack limit = 0xadca6210) Stack: (0xadca7ca8 to 0xadca8000) 7ca0: 805190e0 aded7800 aded7820 80501a88 8155a290 af3c9c6c 7cc0: adca7ddc 0000000f adca7cec adca7cd8 80519104 80506044 805190e0 aded7800 7ce0: adca7d04 adca7cf0 80501ac0 805190ec aded7820 aded7814 adca7d24 adca7d08 7d00: 804fdb80 80501a94 aded7800 af3ca010 aded7afc af3c9c60 adca7d94 adca7d28 7d20: 804e3518 804fdb20 00000000 af3c9b1c adca7d50 81506f44 00000000 8093c500 7d40: af3c9c6c ae4f2ca8 ae4f2c18 00000000 00000000 ae637f00 00000000 aded7800 7d60: 00000001 af3c9800 af23c300 ae77fcc0 ae4f2c18 00000001 af3c9800 8155a290 7d80: af1af700 adca6000 adca7db4 adca7d98 804fea6c 804e2de4 adca7e50 adb3d940 7da0: 00000001 af3c9800 adca7e24 adca7db8 8050440c 804fea0c ae77fcc0 00000003 7dc0: adca7e24 adb3d940 af1af700 ae77fcc0 ae77fccc ae4f2c18 8083d44c ae77fcc0 7de0: ae4002 80d03040 adca7e64 adca7e40 adca7e50 80503f08 7e40: 7ebd5630 adca7e50 00000068 c06864a2 7ebd5be8 00000000 00000001 00000018 7e60: 00000026 00000000 00000000 00000000 00000001 000115bc 05010500 05a0059f 7e80: 03200000 03360321 00000337 0000003c 00000000 00000040 30383231 30303878 7ea0: 00000000 00000000 00000000 00000000 00000000 00000000 80173058 80172e30 7ec0: 80d77d32 00004000 adf7d900 00000003 00000000 7ebd5630 af342bb0 adfe3b80 7ee0: 80272f50 00000003 adca6000 00000000 adca7f7c adca7f00 802725ec 804f52cc 7f00: 802809cc 80178450 00000000 00000000 80280880 80145904 adb3d8c0 adf7d990 7f20: ffffffff 00000003 00004000 01614c10 c06864a2 00000003 adca6000 00000000 7f40: adca7f6c adca7f50 80280b04 8028088c 000115bc adfe3b81 7ebd5630 adfe3b80 7f60: c06864a2 00000003 adca6000 00000000 adca7fa4 adca7f80 80272f50 80272548 7f80: 000115bc 00017050 00000001 01614c10 00000036 801089e4 00000000 adca7fa8 7fa0: 80108840 80272f18 00017050 00000001 00000003 c06864a2 7ebd5630 000115bc 7fc0: 00017050 00000001 01614c10 00000036 00000003 00000000 00000026 00000018 7fe0: 00016f38 7ebd562c 0000b5e9 76ef31e6 400c0030 00000003 ff5f37db bfe7dd4d Backtrace: [<80506038>] (drm_connector_cleanup) from [<80519104>] (dw_hdmi_connector_destroy+0x24/0x28) r10:0000000f r9:adca7ddc r8:af3c9c6c r7:8155a290 r6:80501a88 r5:aded7820 r4:aded7800 r3:805190e0 [<805190e0>] (dw_hdmi_connector_destroy) from [<80501ac0>] (drm_connector_free+0x38/0x3c) r4:aded7800 nreference) from [<804e3518>] (drm_crtc_helper_set_config+0x740/0xbf4) r6:af3c9c60 r5:aded7afc r4:af3ca010 r3:aded7800 [<804e2dd8>] (drm_crtc_helper_set_config) from [<804fea6c>] (drm_mode_set_config_internal+0x6c/0xf4) r10:adca6000 r9:af1af700 r8:8155a290 r7:af3c9800 r6:00000001 r5:ae4f2c18 r4:ae77fcc0 [<804fea00>] (drm_mode_set_config_internal) from [<8050440c>] (drm_mode_setcrtc+0x504/0x57c) r7:af3c9800 r6:00000001 r5:adb3d940 r4:adca7e50 [<80503f08>] (drm_mode_setcrtc) from [<804f5404>] (drm_ioctl+0x144/0x4dc) r10:ada2e000 r9:000000a2 r8:af3c9800 r7:8155a290 r6:809320b4 r5:00000051 r4:adca7e50 [<804f52c0>] (drm_ioctl) from [<802725ec>] (do_vfs_ioctl+0xb0/0x9d0) r10:00000000 r9:adca6000 r8:00000003 r7:80272f50 r6:adfe3b80 r5:af342bb0 r4:7ebd5630 [<8027253c>] (do_vfs_ioctl) from [<80272f50>] (SyS_ioctl+0x44/0x6c) r10:00000000 r9:adca6000 r8:00000003 r7:c06864a2 r6:adfe3b80 r5:7ebd5630 r4:adfe3b81 [<80272f0c>] (SyS_ioctl) from [<80108840>] (ret_fast_syscall+0x0/0x1c) r8:801089e4 r7:00000036 r6:01614c10 r5:00000001 r4:00017050 r3:000115bc Code: 0a00000c e5932004 e1a01003 e1a0a004 (e5842004) ---[ end trace 9a7257572ccacb16 ]--- Only the reference count of connectors that weren't previously bound to an encoder should be incremented after a call to drm_crtc_helper_set_config. And only the reference count of connectors that were previously bound to an encoder and are unbound afterwards should ever be decremented. The reference counts of the temporary copies in the save_connectors should not be touched at all. This patch fixes the above error by only incrementing the reference count of those connectors in the set that are initially not bound to any encoder, and also by restoring the reference count of only those connectors in the set in the failure case. "Note that this can only be hit when fbdev emulation is disabled, since then the refcount drops from 1 to 0 and we call the connector destroy functions on the backup copy, which eventually results in tears. With fbdev emulation the refcount only goes down from 2 to 1 ever. And since we unconditionally increment the refcount on the real object, the refcount of that will slowly increase. The backup connector's refcount doesn't matter, since we kfree() that either way in the end of drm_crtc_helper_set_config()." Fixes: 0955c12 ("drm/crtc: take references to connectors used in a modeset. (v2)") Signed-off-by: Philipp Zabel <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>

Nicolas Dichtel says: ==================== ovs: fix rtnl notifications on interface deletion There was no rtnl notifications for interfaces (gre, vxlan, geneve) created by ovs. This problem is fixed by adjusting the creation path. v1 -> v2: - add patch #1 and #4 - rework error handling in patch #2 ==================== Acked-by: Pravin B Shelar <[email protected]> Signed-off-by: David S. Miller <[email protected]>

…n ARM64" This reverts commit 1733a2a. There is apparently something amiss with the way the TTM code handles DMA buffers, which the above commit was attempting to work around for arm64 systems with non-coherent PCI. Unfortunately, this completely breaks systems *with* coherent PCI (which appear to be the majority). Booting a plain arm64 defconfig + CONFIG_DRM + CONFIG_DRM_NOUVEAU on a machine with a PCI GPU having coherent dma_map_ops (in this case a 7600GT card plugged into an ARM Juno board) results in a fatal crash: [ 2.803438] nouveau 0000:06:00.0: DRM: allocated 1024x768 fb: 0x9000, bo ffffffc976141c00 [ 2.897662] Unable to handle kernel NULL pointer dereference at virtual address 000001ac [ 2.897666] pgd = ffffff8008e00000 [ 2.897675] [000001ac] *pgd=00000009ffffe003, *pud=00000009ffffe003, *pmd=0000000000000000 [ 2.897680] Internal error: Oops: 96000045 [#1] PREEMPT SMP [ 2.897685] Modules linked in: [ 2.897692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5+ torvalds#543 [ 2.897694] Hardware name: ARM Juno development board (r1) (DT) [ 2.897699] task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000 [ 2.897711] PC is at __memcpy+0x7c/0x180 [ 2.897719] LR is at OUT_RINGp+0x34/0x70 [ 2.897724] pc : [<ffffff80083465fc>] lr : [<ffffff800854248c>] pstate: 80000045 [ 2.897726] sp : ffffffc9768ab360 [ 2.897732] x29: ffffffc9768ab360 x28: 0000000000000001 [ 2.897738] x27: ffffffc97624c000 x26: 0000000000000000 [ 2.897744] x25: 0000000000000080 x24: 0000000000006c00 [ 2.897749] x23: 0000000000000005 x22: ffffffc97624c010 [ 2.897755] x21: 0000000000000004 x20: 0000000000000004 [ 2.897761] x19: ffffffc9763da000 x18: ffffffc976b2491c [ 2.897766] x17: 0000000000000007 x16: 0000000000000006 [ 2.897771] x15: 0000000000000001 x14: 0000000000000001 [ 2.897777] x13: 0000000000e31b70 x12: ffffffc9768a0080 [ 2.897783] x11: 0000000000000000 x10: fffffffffffffb00 [ 2.897788] x9 : 0000000000000000 x8 : 0000000000000000 [ 2.897793] x7 : 0000000000000000 x6 : 00000000000001ac [ 2.897799] x5 : 00000000ffffffff x4 : 0000000000000000 [ 2.897804] x3 : 0000000000000010 x2 : 0000000000000010 [ 2.897810] x1 : ffffffc97624c010 x0 : 00000000000001ac ... [ 2.898494] Call trace: [ 2.898499] Exception stack(0xffffffc9768ab1a0 to 0xffffffc9768ab2c0) [ 2.898506] b1a0: ffffffc9763da000 0000000000000004 ffffffc9768ab360 ffffff80083465fc [ 2.898513] b1c0: ffffffc976801e00 ffffffc9762b8000 ffffffc9768ab1f0 ffffff80080ec158 [ 2.898520] b1e0: ffffffc9768ab230 ffffff8008496d04 ffffffc975ce6d80 ffffffc9768ab36e [ 2.898527] b200: ffffffc9768ab36f ffffffc9768ab29d ffffffc9768ab29e ffffffc9768a0000 [ 2.898533] b220: ffffffc9768ab250 ffffff80080e70c0 ffffffc9768ab270 ffffff8008496e44 [ 2.898540] b240: 00000000000001ac ffffffc97624c010 0000000000000010 0000000000000010 [ 2.898546] b260: 0000000000000000 00000000ffffffff 00000000000001ac 0000000000000000 [ 2.898552] b280: 0000000000000000 0000000000000000 fffffffffffffb00 0000000000000000 [ 2.898558] b2a0: ffffffc9768a0080 0000000000e31b70 0000000000000001 0000000000000001 [ 2.898566] [<ffffff80083465fc>] __memcpy+0x7c/0x180 [ 2.898574] [<ffffff800853e164>] nv04_fbcon_imageblit+0x1d4/0x2e8 [ 2.898582] [<ffffff800853d6d0>] nouveau_fbcon_imageblit+0xd8/0xe0 [ 2.898591] [<ffffff80083c4db4>] soft_cursor+0x154/0x1d8 [ 2.898598] [<ffffff80083c47b4>] bit_cursor+0x4fc/0x538 [ 2.898605] [<ffffff80083c0cfc>] fbcon_cursor+0x134/0x1a8 [ 2.898613] [<ffffff800841c280>] hide_cursor+0x38/0xa0 [ 2.898620] [<ffffff800841d420>] redraw_screen+0x120/0x228 [ 2.898628] [<ffffff80083bf268>] fbcon_prepare_logo+0x370/0x3f8 [ 2.898635] [<ffffff80083bf640>] fbcon_init+0x350/0x560 [ 2.898641] [<ffffff800841c634>] visual_init+0xac/0x108 [ 2.898648] [<ffffff800841df14>] do_bind_con_driver+0x1c4/0x3a8 [ 2.898655] [<ffffff800841e4f4>] do_take_over_console+0x174/0x1e8 [ 2.898662] [<ffffff80083bf8c4>] do_fbcon_takeover+0x74/0x100 [ 2.898669] [<ffffff80083c3e44>] fbcon_event_notify+0x8cc/0x920 [ 2.898680] [<ffffff80080d7e38>] notifier_call_chain+0x50/0x90 [ 2.898685] [<ffffff80080d8214>] __blocking_notifier_call_chain+0x4c/0x90 [ 2.898691] [<ffffff80080d826c>] blocking_notifier_call_chain+0x14/0x20 [ 2.898696] [<ffffff80083c5e1c>] fb_notifier_call_chain+0x1c/0x28 [ 2.898703] [<ffffff80083c81ac>] register_framebuffer+0x1cc/0x2e0 [ 2.898712] [<ffffff800845da80>] drm_fb_helper_initial_config+0x288/0x3e8 [ 2.898719] [<ffffff800853da20>] nouveau_fbcon_init+0xe0/0x118 [ 2.898727] [<ffffff800852d2f8>] nouveau_drm_load+0x268/0x890 [ 2.898734] [<ffffff8008466e24>] drm_dev_register+0xbc/0xc8 [ 2.898740] [<ffffff8008468a88>] drm_get_pci_dev+0xa0/0x180 [ 2.898747] [<ffffff800852cb28>] nouveau_drm_probe+0x1a0/0x1e0 [ 2.898755] [<ffffff80083a32e0>] pci_device_probe+0x98/0x110 [ 2.898763] [<ffffff800858e434>] driver_probe_device+0x204/0x2b0 [ 2.898770] [<ffffff800858e58c>] __driver_attach+0xac/0xb0 [ 2.898777] [<ffffff800858c3e0>] bus_for_each_dev+0x60/0xa0 [ 2.898783] [<ffffff800858dbc0>] driver_attach+0x20/0x28 [ 2.898789] [<ffffff800858d7b0>] bus_add_driver+0x1d0/0x238 [ 2.898796] [<ffffff800858ed50>] driver_register+0x60/0xf8 [ 2.898802] [<ffffff80083a20dc>] __pci_register_driver+0x3c/0x48 [ 2.898809] [<ffffff8008468eb4>] drm_pci_init+0xf4/0x120 [ 2.898818] [<ffffff8008c56fc0>] nouveau_drm_init+0x21c/0x230 [ 2.898825] [<ffffff80080829d4>] do_one_initcall+0x8c/0x190 [ 2.898832] [<ffffff8008c31af4>] kernel_init_freeable+0x14c/0x1f0 [ 2.898839] [<ffffff80088a0c20>] kernel_init+0x10/0x100 [ 2.898845] [<ffffff8008085e10>] ret_from_fork+0x10/0x40 [ 2.898853] Code: a88120c7 a8c12027 a88120c7 a8c12027 (a88120c7) [ 2.898871] ---[ end trace d5713dcad023ee04 ]--- [ 2.898888] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b In a toss-up between the GPU seeing stale data artefacts on some systems vs. catastrophic kernel crashes on other systems, the latter would seem to take precedence, so revert this change until the real underlying problem can be fixed. Signed-off-by: Robin Murphy <[email protected]> Acked-by: Alexandre Courbot <[email protected]> [[email protected]: port to Nouveau tree, remove bits in lib/] Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]> Cc: [email protected]

Rather than wait until we observe the lock being free (which might never happen), we can also return from spin_unlock_wait if we observe that the lock is now held by somebody else, which implies that it was unlocked but we just missed seeing it in that state. Furthermore, in such a scenario there is no longer a need to write back the value that we loaded, since we know that there has been a lock hand-off, which is sufficient to publish any stores prior to the unlock_wait because the ARm architecture ensures that a Store-Release instruction is multi-copy atomic when observed by a Load-Acquire instruction. The litmus test is something like: AArch64 { 0:X1=x; 0:X3=y; 1:X1=y; 2:X1=y; 2:X3=x; } P0 | P1 | P2 ; MOV W0,#1 | MOV W0,#1 | LDAR W0,[X1] ; STR W0,[X1] | STLR W0,[X1] | LDR W2,[X3] ; DMB SY | | ; LDR W2,[X3] | | ; exists (0:X2=0 /\ 2:X0=1 /\ 2:X2=0) where P0 is doing spin_unlock_wait, P1 is doing spin_unlock and P2 is doing spin_lock. Signed-off-by: Will Deacon <[email protected]>

saw a debug splat: net/include/net/sch_generic.h:287 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by kworker/2:1/710: #0: ("events"){.+.+.+}, at: [<ffffffff8106ca1d>] #1: ((&q->work)){+.+...}, at: [<ffffffff8106ca1d>] process_one_work+0x14d/0x690 Workqueue: events htb_work_func Call Trace: [<ffffffff812dc763>] dump_stack+0x85/0xc2 [<ffffffff8109fee7>] lockdep_rcu_suspicious+0xe7/0x120 [<ffffffff814ced47>] htb_work_func+0x67/0x70 Signed-off-by: Florian Westphal <[email protected]> Acked-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>

When run tipcTS&tipcTC test suite, the following complaint appears: [ 56.926168] =============================== [ 56.926169] [ INFO: suspicious RCU usage. ] [ 56.926171] 4.7.0-rc1+ torvalds#160 Not tainted [ 56.926173] ------------------------------- [ 56.926174] net/tipc/bearer.c:408 suspicious rcu_dereference_protected() usage! [ 56.926175] [ 56.926175] other info that might help us debug this: [ 56.926175] [ 56.926177] [ 56.926177] rcu_scheduler_active = 1, debug_locks = 1 [ 56.926179] 3 locks held by swapper/4/0: [ 56.926180] #0: (((&req->timer))){+.-...}, at: [<ffffffff810e79b5>] call_timer_fn+0x5/0x340 [ 56.926203] #1: (&(&req->lock)->rlock){+.-...}, at: [<ffffffffa000c29b>] disc_timeout+0x1b/0xd0 [tipc] [ 56.926212] #2: (rcu_read_lock){......}, at: [<ffffffffa00055e0>] tipc_bearer_xmit_skb+0xb0/0x2e0 [tipc] [ 56.926218] [ 56.926218] stack backtrace: [ 56.926221] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.7.0-rc1+ torvalds#160 [ 56.926222] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 56.926224] 0000000000000000 ffff880016803d28 ffffffff813c4423 ffff8800154252c0 [ 56.926227] 0000000000000001 ffff880016803d58 ffffffff810b7512 ffff8800124d8120 [ 56.926230] ffff880013f8a160 ffff8800132b5ccc ffff8800124d8120 ffff880016803d88 [ 56.926234] Call Trace: [ 56.926235] <IRQ> [<ffffffff813c4423>] dump_stack+0x67/0x94 [ 56.926250] [<ffffffff810b7512>] lockdep_rcu_suspicious+0xe2/0x120 [ 56.926256] [<ffffffffa00051f1>] tipc_l2_send_msg+0x131/0x1c0 [tipc] [ 56.926261] [<ffffffffa000567c>] tipc_bearer_xmit_skb+0x14c/0x2e0 [tipc] [ 56.926266] [<ffffffffa00055e0>] ? tipc_bearer_xmit_skb+0xb0/0x2e0 [tipc] [ 56.926273] [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc] [ 56.926278] [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc] [ 56.926283] [<ffffffffa000c2d6>] disc_timeout+0x56/0xd0 [tipc] [ 56.926288] [<ffffffff810e7a68>] call_timer_fn+0xb8/0x340 [ 56.926291] [<ffffffff810e79b5>] ? call_timer_fn+0x5/0x340 [ 56.926296] [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc] [ 56.926300] [<ffffffff810e8f4a>] run_timer_softirq+0x23a/0x390 [ 56.926306] [<ffffffff810f89ff>] ? clockevents_program_event+0x7f/0x130 [ 56.926316] [<ffffffff819727c3>] __do_softirq+0xc3/0x4a2 [ 56.926323] [<ffffffff8106ba5a>] irq_exit+0x8a/0xb0 [ 56.926327] [<ffffffff81972456>] smp_apic_timer_interrupt+0x46/0x60 [ 56.926331] [<ffffffff81970a49>] apic_timer_interrupt+0x89/0x90 [ 56.926333] <EOI> [<ffffffff81027fda>] ? default_idle+0x2a/0x1a0 [ 56.926340] [<ffffffff81027fd8>] ? default_idle+0x28/0x1a0 [ 56.926342] [<ffffffff810289cf>] arch_cpu_idle+0xf/0x20 [ 56.926345] [<ffffffff810adf0f>] default_idle_call+0x2f/0x50 [ 56.926347] [<ffffffff810ae145>] cpu_startup_entry+0x215/0x3e0 [ 56.926353] [<ffffffff81040ad9>] start_secondary+0xf9/0x100 The warning appears as rtnl_dereference() is wrongly used in tipc_l2_send_msg() under RCU read lock protection. Instead the proper usage should be that rcu_dereference_rtnl() is called here. Fixes: 5b7066c ("tipc: stricter filtering of packets in bearer layer") Acked-by: Jon Maloy <[email protected]> Signed-off-by: Ying Xue <[email protected]> Signed-off-by: David S. Miller <[email protected]>

_coresight_build_path assumes that all the connections of a csdev has the child_dev initialised. This may not be true if the particular component is not supported by the kernel config(e.g TPIU) but is present in the DT. In which case, building a path can cause a crash like this : Unable to handle kernel NULL pointer dereference at virtual address 00000010 pgd = ffffffc9750dd000 [00000010] *pgd=00000009f5e90003, *pud=00000009f5e90003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 4 PID: 1348 Comm: bash Not tainted 4.6.0-next-20160517 #1646 Hardware name: ARM Juno development board (r0) (DT) task: ffffffc97517a280 ti: ffffffc9762c4000 task.ti: ffffffc9762c4000 PC is at _coresight_build_path+0x18/0xe4 LR is at _coresight_build_path+0xc0/0xe4 pc : [<ffffff80083d5130>] lr : [<ffffff80083d51d8>] pstate: 20000145 sp : ffffffc9762c7ba0 [<ffffff80083d5130>] _coresight_build_path+0x18/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d5cdc>] coresight_build_path+0x40/0x68 [<ffffff80083d5e14>] coresight_enable+0x74/0x1bc [<ffffff80083d60a0>] enable_source_store+0x3c/0x6c [<ffffff800830b17c>] dev_attr_store+0x18/0x28 [<ffffff80081ca9c4>] sysfs_kf_write+0x40/0x50 [<ffffff80081c9e38>] kernfs_fop_write+0x140/0x1cc [<ffffff8008163ec8>] __vfs_write+0x28/0x110 [<ffffff8008164bf0>] vfs_write+0xa0/0x174 [<ffffff8008165d18>] SyS_write+0x44/0xa0 [<ffffff8008084e70>] el0_svc_naked+0x24/0x28 Cc: Mathieu Poirier <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

At the end of the trace capture, we free the allocated memory, resetting the drvdata->buf to NULL, to indicate that trace data was collected and the next trace session should allocate the memory in tmc_enable_etr_sink_sysfs. The tmc_enable_etr_sink_sysfs, we only allocate memory if drvdata->vaddr is not NULL (which is not performed at the end of previous session). This can cause, drvdata->vaddr getting assigned NULL and later we do memset() which causes a crash as below : Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc9747f0000 [00000000] *pgd=00000009f402e003, *pud=00000009f402e003, *pmd=0000000000000000 Internal error: Oops: 96000046 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1592 Comm: bash Not tainted 4.7.0-rc1+ #1712 Hardware name: ARM Juno development board (r0) (DT) task: ffffffc078fe0080 ti: ffffffc974178000 task.ti: ffffffc974178000 PC is at __memset+0x1ac/0x200 LR is at tmc_enable_etr_sink+0xf8/0x304 pc : [<ffffff80083a002c>] lr : [<ffffff800859be44>] pstate: 400001c5 sp : ffffffc97417bc00 x29: ffffffc97417bc00 x28: ffffffc974178000 Call trace: Exception stack(0xffffffc97417ba40 to 0xffffffc97417bb60) ba40: 0000000000000001 ffffffc974a5d098 ffffffc97417bc00 ffffff80083a002c ba60: ffffffc974a5d118 0000000000000000 0000000000000000 0000000000000000 ba80: 0000000000000001 0000000000000000 ffffff800859bdec 0000000000000040 baa0: ffffff8008b45b58 00000000000001c0 ffffffc97417baf0 ffffff80080eddb4 bac0: 0000000000000003 ffffffc078fe0080 ffffffc078fe0960 ffffffc078fe0940 bae0: 0000000000000000 0000000000000000 00000000007fffc0 0000000000000004 bb00: 0000000000000000 0000000000000040 000000000000003f 0000000000000000 bb20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001 bb40: ffffffc078fe0960 0000000000000018 ffffffffffffffff 0008669628000000 [<ffffff80083a002c>] __memset+0x1ac/0x200 [<ffffff8008599814>] coresight_enable_path+0xa8/0x1dc [<ffffff8008599b10>] coresight_enable+0x88/0x1b8 [<ffffff8008599d88>] enable_source_store+0x3c/0x6c [<ffffff800845eaf4>] dev_attr_store+0x18/0x28 [<ffffff80082829e8>] sysfs_kf_write+0x54/0x64 [<ffffff8008281c30>] kernfs_fop_write+0x148/0x1d8 [<ffffff8008200128>] __vfs_write+0x28/0x110 [<ffffff8008200e88>] vfs_write+0xa0/0x198 [<ffffff80082021b0>] SyS_write+0x44/0xa0 [<ffffff8008084e70>] el0_svc_naked+0x24/0x28 Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428) This patch fixes the issue by clearing the drvdata->vaddr while we free the allocated buffer at the end of a session, so that we allocate the memory again. Cc: [email protected] Signed-off-by: Suzuki K Poulose <[email protected]> Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

This bug leads to: [ 1.906411] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 1.914878] pgd = c0004000 [ 1.917786] [0000000c] *pgd=00000000 [ 1.921536] Internal error: Oops: 5 [#1] SMP ARM [ 1.926357] Modules linked in: [ 1.929556] CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 4.4.5 torvalds#18 [ 1.936006] Hardware name: Generic AM33XX (Flattened Device Tree) [ 1.942383] Workqueue: events power_supply_changed_work [ 1.947842] task: de2c41c0 ti: de2c8000 task.ti: de2c8000 [ 1.953483] PC is at tps65217_ac_get_property+0x14/0x28 [ 1.958937] LR is at tps65217_ac_get_property+0x10/0x28 Driver was trying to use drv_data in property get handler. However drv_data was not set, so it caused NULL pointer dereference. This patch properly sets drv_data during probe by power_supply_config parameter, so the property get handler works as desired. Signed-off-by: Marcin Niestroj <[email protected]> Fixes: 3636859 ("power_supply: Add support for tps65217-charger") Signed-off-by: Sebastian Reichel <[email protected]>

The memory needed for the send and receive queues associated with a QP is proportional to the max_sge parameter. The current value of that parameter is such that with an mlx4 HCA the QP buffer size is 8 MB. Since DMA is used for communication between HCA and CPU that buffer either has to be allocated coherently or map_single() must succeed for that buffer. Since large contiguous allocations are fragile and since the maximum segment size for e.g. swiotlb is 256 KB, reduce the max_sge parameter. This patch avoids that the following text appears on the console after SRP logout and relogin on a system equipped with multiple IB HCAs: mlx4_core 0000:05:00.0: swiotlb buffer is full (sz: 8388608 bytes) swiotlb: coherent allocation failed for device 0000:05:00.0 size=8388608 CPU: 11 PID: 148 Comm: kworker/11:1 Not tainted 4.7.0-rc4-dbg+ #1 Call Trace: [<ffffffff812c6d35>] dump_stack+0x67/0x92 [<ffffffff812efe71>] swiotlb_alloc_coherent+0x141/0x150 [<ffffffff810458be>] x86_swiotlb_alloc_coherent+0x3e/0x50 [<ffffffffa03861fa>] mlx4_buf_direct_alloc.isra.5+0x9a/0x120 [mlx4_core] [<ffffffffa0386545>] mlx4_buf_alloc+0x165/0x1a0 [mlx4_core] [<ffffffffa035053d>] create_qp_common.isra.29+0x57d/0xff0 [mlx4_ib] [<ffffffffa03510da>] mlx4_ib_create_qp+0x12a/0x3f0 [mlx4_ib] [<ffffffffa031154a>] ib_create_qp+0x3a/0x250 [ib_core] [<ffffffffa055dd4b>] srpt_cm_handler+0x4bb/0xcad [ib_srpt] [<ffffffffa02c1ab0>] cm_process_work+0x20/0xf0 [ib_cm] [<ffffffffa02c3640>] cm_work_handler+0x1ac0/0x2059 [ib_cm] [<ffffffff810737ed>] process_one_work+0x19d/0x490 [<ffffffff81073b29>] worker_thread+0x49/0x490 [<ffffffff8107a0ea>] kthread+0xea/0x100 [<ffffffff815b25af>] ret_from_fork+0x1f/0x40 Fixes: b99f8e4 ("IB/srpt: convert to the generic RDMA READ/WRITE API") Signed-off-by: Bart Van Assche <[email protected]> Cc: Laurence Oberman <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Sagi Grimberg <[email protected]> Signed-off-by: Doug Ledford <[email protected]>

Commit e8d975e ("fixing infinite OPEN loop in 4.0 stateid recovery") introduced access to state after it was just potentially freed by nfs4_put_open_state leading to a random data corruption somewhere. BUG: unable to handle kernel paging request at ffff88004941ee40 IP: [<ffffffff813baf01>] nfs4_do_reclaim+0x461/0x740 PGD 3501067 PUD 3504067 PMD 6ff37067 PTE 800000004941e060 Oops: 0002 [#1] SMP DEBUG_PAGEALLOC Modules linked in: loop rpcsec_gss_krb5 acpi_cpufreq tpm_tis joydev i2c_piix4 pcspkr tpm virtio_console nfsd ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops floppy serio_raw virtio_blk drm CPU: 6 PID: 2161 Comm: 192.168.10.253- Not tainted 4.7.0-rc1-vm-nfs+ torvalds#112 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff8800463dcd00 ti: ffff88003ff48000 task.ti: ffff88003ff48000 RIP: 0010:[<ffffffff813baf01>] [<ffffffff813baf01>] nfs4_do_reclaim+0x461/0x740 RSP: 0018:ffff88003ff4bd68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffff81a49900 RCX: 00000000000000e8 RDX: 00000000000000e8 RSI: ffff8800418b9930 RDI: ffff880040c96c88 RBP: ffff88003ff4bdf8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff880040c96c98 R13: ffff88004941ee20 R14: ffff88004941ee40 R15: ffff88004941ee00 FS: 0000000000000000(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff88004941ee40 CR3: 0000000060b0b000 CR4: 00000000000006e0 Stack: ffffffff813baad5 ffff8800463dcd00 ffff880000000001 ffffffff810e6b68 ffff880043ddbc88 ffff8800418b9800 ffff8800418b98c8 ffff88004941ee48 ffff880040c96c90 ffff880040c96c00 ffff880040c96c20 ffff880040c96c40 Call Trace: [<ffffffff813baad5>] ? nfs4_do_reclaim+0x35/0x740 [<ffffffff810e6b68>] ? trace_hardirqs_on_caller+0x128/0x1b0 [<ffffffff813bb7cd>] nfs4_run_state_manager+0x5ed/0xa40 [<ffffffff813bb1e0>] ? nfs4_do_reclaim+0x740/0x740 [<ffffffff813bb1e0>] ? nfs4_do_reclaim+0x740/0x740 [<ffffffff810af0d1>] kthread+0x101/0x120 [<ffffffff810e6b68>] ? trace_hardirqs_on_caller+0x128/0x1b0 [<ffffffff818843af>] ret_from_fork+0x1f/0x40 [<ffffffff810aefd0>] ? kthread_create_on_node+0x250/0x250 Code: 65 80 4c 8b b5 78 ff ff ff e8 fc 88 4c 00 48 8b 7d 88 e8 13 67 d2 ff 49 8b 47 40 a8 02 0f 84 d3 01 00 00 4c 89 ff e8 7f f9 ff ff <f0> 41 80 26 7f 48 8b 7d c8 e8 b1 84 4c 00 e9 39 fd ff ff 3d e6 RIP [<ffffffff813baf01>] nfs4_do_reclaim+0x461/0x740 RSP <ffff88003ff4bd68> CR2: ffff88004941ee40 Signed-off-by: Oleg Drokin <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>

mem_cgroup_migrate() uses local_irq_disable/enable() but can be called with irq disabled from migrate_page_copy(). This ends up enabling irq while holding a irq context lock triggering the following lockdep warning. Fix it by using irq_save/restore instead. ================================= [ INFO: inconsistent lock state ] 4.7.0-rc1+ #52 Tainted: G W --------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. kcompactd0/151 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&ctx->completion_lock)->rlock){+.?.-.}, at: [<000000000038fd96>] aio_migratepage+0x156/0x1e8 {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x5b6/0x1930 lock_acquire+0xee/0x270 _raw_spin_lock_irqsave+0x66/0xb0 aio_complete+0x98/0x328 dio_complete+0xe4/0x1e0 blk_update_request+0xd4/0x450 scsi_end_request+0x48/0x1c8 scsi_io_completion+0x272/0x698 blk_done_softirq+0xca/0xe8 __do_softirq+0xc8/0x518 irq_exit+0xee/0x110 do_IRQ+0x6a/0x88 io_int_handler+0x11a/0x25c __mutex_unlock_slowpath+0x144/0x1d8 __mutex_unlock_slowpath+0x140/0x1d8 kernfs_iop_permission+0x64/0x80 __inode_permission+0x9e/0xf0 link_path_walk+0x6e/0x510 path_lookupat+0xc4/0x1a8 filename_lookup+0x9c/0x160 user_path_at_empty+0x5c/0x70 SyS_readlinkat+0x68/0x140 system_call+0xd6/0x270 irq event stamp: 971410 hardirqs last enabled at (971409): migrate_page_move_mapping+0x3ea/0x588 hardirqs last disabled at (971410): _raw_spin_lock_irqsave+0x3c/0xb0 softirqs last enabled at (970526): __do_softirq+0x460/0x518 softirqs last disabled at (970519): irq_exit+0xee/0x110 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&ctx->completion_lock)->rlock); <Interrupt> lock(&(&ctx->completion_lock)->rlock); *** DEADLOCK *** 3 locks held by kcompactd0/151: #0: (&(&mapping->private_lock)->rlock){+.+.-.}, at: aio_migratepage+0x42/0x1e8 #1: (&ctx->ring_lock){+.+.+.}, at: aio_migratepage+0x5a/0x1e8 #2: (&(&ctx->completion_lock)->rlock){+.?.-.}, at: aio_migratepage+0x156/0x1e8 stack backtrace: CPU: 20 PID: 151 Comm: kcompactd0 Tainted: G W 4.7.0-rc1+ #52 Call Trace: show_trace+0xea/0xf0 show_stack+0x72/0xf0 dump_stack+0x9a/0xd8 print_usage_bug.part.27+0x2d4/0x2e8 mark_lock+0x17e/0x758 mark_held_locks+0xa2/0xd0 trace_hardirqs_on_caller+0x140/0x1c0 mem_cgroup_migrate+0x266/0x370 aio_migratepage+0x16a/0x1e8 move_to_new_page+0xb0/0x260 migrate_pages+0x8f4/0x9f0 compact_zone+0x4dc/0xdc8 kcompactd_do_work+0x1aa/0x358 kcompactd+0xba/0x2c8 kthread+0x10a/0x110 kernel_thread_starter+0x6/0xc kernel_thread_starter+0x0/0xc INFO: lockdep is turned off. Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/g/[email protected] Fixes: 74485cf ("mm: migrate: consolidate mem_cgroup_migrate() calls") Signed-off-by: Tejun Heo <[email protected]> Reported-by: Christian Borntraeger <[email protected]> Acked-by: Johannes Weiner <[email protected]> Acked-by: Michal Hocko <[email protected]> Reviewed-by: Vladimir Davydov <[email protected]> Cc: <[email protected]> [4.5+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>

mem_cgroup_css_alloc() was returning NULL on failure while cgroup core expected it to return an ERR_PTR value leading to the following NULL deref after a css allocation failure. Fix it by return ERR_PTR(-ENOMEM) instead. I'll also update cgroup core so that it can handle NULL returns. mkdir: page allocation failure: order:6, mode:0x240c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO) CPU: 0 PID: 8738 Comm: mkdir Not tainted 4.7.0-rc3+ torvalds#123 ... Call Trace: dump_stack+0x68/0xa1 warn_alloc_failed+0xd6/0x130 __alloc_pages_nodemask+0x4c6/0xf20 alloc_pages_current+0x66/0xe0 alloc_kmem_pages+0x14/0x80 kmalloc_order_trace+0x2a/0x1a0 __kmalloc+0x291/0x310 memcg_update_all_caches+0x6c/0x130 mem_cgroup_css_alloc+0x590/0x610 cgroup_apply_control_enable+0x18b/0x370 cgroup_mkdir+0x1de/0x2e0 kernfs_iop_mkdir+0x55/0x80 vfs_mkdir+0xb9/0x150 SyS_mkdir+0x66/0xd0 do_syscall_64+0x53/0x120 entry_SYSCALL64_slow_path+0x25/0x25 ... BUG: unable to handle kernel NULL pointer dereference at 00000000000000d0 IP: init_and_link_css+0x37/0x220 PGD 34b1e067 PUD 3a109067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: CPU: 0 PID: 8738 Comm: mkdir Not tainted 4.7.0-rc3+ torvalds#123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.2-20160422_131301-anatol 04/01/2014 task: ffff88007cbc5200 ti: ffff8800666d4000 task.ti: ffff8800666d4000 RIP: 0010:[<ffffffff810f2ca7>] [<ffffffff810f2ca7>] init_and_link_css+0x37/0x220 RSP: 0018:ffff8800666d7d90 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffffffff810f2499 RSI: 0000000000000000 RDI: 0000000000000008 RBP: ffff8800666d7db8 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: ffff88005a5fb400 R13: ffffffff81f0f8a0 R14: ffff88005a5fb400 R15: 0000000000000010 FS: 00007fc944689700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3aed0d2b80 CR3: 000000003a1e8000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: cgroup_apply_control_enable+0x1ac/0x370 cgroup_mkdir+0x1de/0x2e0 kernfs_iop_mkdir+0x55/0x80 vfs_mkdir+0xb9/0x150 SyS_mkdir+0x66/0xd0 do_syscall_64+0x53/0x120 entry_SYSCALL64_slow_path+0x25/0x25 Code: 89 f5 48 89 fb 49 89 d4 48 83 ec 08 8b 05 72 3b d8 00 85 c0 0f 85 60 01 00 00 4c 89 e7 e8 72 f7 ff ff 48 8d 7b 08 48 89 d9 31 c0 <48> c7 83 d0 00 00 00 00 00 00 00 48 83 e7 f8 48 29 f9 81 c1 d8 RIP init_and_link_css+0x37/0x220 RSP <ffff8800666d7d90> CR2: 00000000000000d0 ---[ end trace a2d8836ae1e852d1 ]--- Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Tejun Heo <[email protected]> Reported-by: Johannes Weiner <[email protected]> Reviewed-by: Vladimir Davydov <[email protected]> Acked-by: Johannes Weiner <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>

An ENOMEM when creating a pair tty in tty_ldisc_setup causes a null pointer dereference in devpts_kill_index because tty->link->driver_data is NULL. The oops was triggered with the pty stressor in stress-ng when in a low memory condition. tty_init_dev tries to clean up a tty_ldisc_setup ENOMEM error by calling release_tty, however, this ultimately tries to clean up the NULL pair'd tty in pty_unix98_remove, triggering the Oops. Add check to pty_unix98_remove to only clean up fsi if it is not NULL. Ooops: [ 23.020961] Oops: 0000 [#1] SMP [ 23.020976] Modules linked in: ppdev snd_hda_codec_generic snd_hda_intel snd_hda_codec parport_pc snd_hda_core snd_hwdep parport snd_pcm input_leds joydev snd_timer serio_raw snd soundcore i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel qxl aes_x86_64 ttm lrw gf128mul glue_helper ablk_helper drm_kms_helper cryptd syscopyarea sysfillrect psmouse sysimgblt floppy fb_sys_fops drm pata_acpi jitterentropy_rng drbg ansi_cprng [ 23.020978] CPU: 0 PID: 1452 Comm: stress-ng-pty Not tainted 4.7.0-rc4+ #2 [ 23.020978] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [ 23.020979] task: ffff88007ba30000 ti: ffff880078ea8000 task.ti: ffff880078ea8000 [ 23.020981] RIP: 0010:[<ffffffff813f11ff>] [<ffffffff813f11ff>] ida_remove+0x1f/0x120 [ 23.020981] RSP: 0018:ffff880078eabb60 EFLAGS: 00010a03 [ 23.020982] RAX: 4444444444444567 RBX: 0000000000000000 RCX: 000000000000001f [ 23.020982] RDX: 000000000000014c RSI: 000000000000026f RDI: 0000000000000000 [ 23.020982] RBP: ffff880078eabb70 R08: 0000000000000004 R09: 0000000000000036 [ 23.020983] R10: 000000000000026f R11: 0000000000000000 R12: 000000000000026f [ 23.020983] R13: 000000000000026f R14: ffff88007c944b40 R15: 000000000000026f [ 23.020984] FS: 00007f9a2f3cc700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 23.020984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.020985] CR2: 0000000000000010 CR3: 000000006c81b000 CR4: 00000000001406f0 [ 23.020988] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 23.020988] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 23.020988] Stack: [ 23.020989] 0000000000000000 000000000000026f ffff880078eabb90 ffffffff812a5a99 [ 23.020990] 0000000000000000 00000000fffffff4 ffff880078eabba8 ffffffff814f9cbe [ 23.020991] ffff88007965c800 ffff880078eabbc8 ffffffff814eef43 fffffffffffffff4 [ 23.020991] Call Trace: [ 23.021000] [<ffffffff812a5a99>] devpts_kill_index+0x29/0x50 [ 23.021002] [<ffffffff814f9cbe>] pty_unix98_remove+0x2e/0x50 [ 23.021006] [<ffffffff814eef43>] release_tty+0xb3/0x1b0 [ 23.021007] [<ffffffff814f18d4>] tty_init_dev+0xd4/0x1c0 [ 23.021011] [<ffffffff814f9fae>] ptmx_open+0xae/0x190 [ 23.021013] [<ffffffff812254ef>] chrdev_open+0xbf/0x1b0 [ 23.021015] [<ffffffff8121d973>] do_dentry_open+0x203/0x310 [ 23.021016] [<ffffffff81225430>] ? cdev_put+0x30/0x30 [ 23.021017] [<ffffffff8121ee44>] vfs_open+0x54/0x80 [ 23.021018] [<ffffffff8122b8fc>] ? may_open+0x8c/0x100 [ 23.021019] [<ffffffff8122f26b>] path_openat+0x2eb/0x1440 [ 23.021020] [<ffffffff81230534>] ? putname+0x54/0x60 [ 23.021022] [<ffffffff814f6f97>] ? n_tty_ioctl_helper+0x27/0x100 [ 23.021023] [<ffffffff81231651>] do_filp_open+0x91/0x100 [ 23.021024] [<ffffffff81230596>] ? getname_flags+0x56/0x1f0 [ 23.021026] [<ffffffff8123fc66>] ? __alloc_fd+0x46/0x190 [ 23.021027] [<ffffffff8121f1e4>] do_sys_open+0x124/0x210 [ 23.021028] [<ffffffff8121f2ee>] SyS_open+0x1e/0x20 [ 23.021035] [<ffffffff81845576>] entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 23.021044] Code: 63 28 45 31 e4 eb dd 0f 1f 44 00 00 55 4c 63 d6 48 ba 89 88 88 88 88 88 88 88 4c 89 d0 b9 1f 00 00 00 48 f7 e2 48 89 e5 41 54 53 <8b> 47 10 48 89 fb 8d 3c c5 00 00 00 00 48 c1 ea 09 b8 01 00 00 [ 23.021045] RIP [<ffffffff813f11ff>] ida_remove+0x1f/0x120 [ 23.021045] RSP <ffff880078eabb60> [ 23.021046] CR2: 0000000000000010 Signed-off-by: Colin Ian King <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Userspace can quite legitimately perform an exec() syscall with a suspended transaction. exec() does not return to the old process, rather it load a new one and starts that, the expectation therefore is that the new process starts not in a transaction. Currently exec() is not treated any differently to any other syscall which creates problems. Firstly it could allow a new process to start with a suspended transaction for a binary that no longer exists. This means that the checkpointed state won't be valid and if the suspended transaction were ever to be resumed and subsequently aborted (a possibility which is exceedingly likely as exec()ing will likely doom the transaction) the new process will jump to invalid state. Secondly the incorrect attempt to keep the transactional state while still zeroing state for the new process creates at least two TM Bad Things. The first triggers on the rfid to return to userspace as start_thread() has given the new process a 'clean' MSR but the suspend will still be set in the hardware MSR. The second TM Bad Thing triggers in __switch_to() as the processor is still transactionally suspended but __switch_to() wants to zero the TM sprs for the new process. This is an example of the outcome of calling exec() with a suspended transaction. Note the first 700 is likely the first TM bad thing decsribed earlier only the kernel can't report it as we've loaded userspace registers. c000000000009980 is the rfid in fast_exception_return() Bad kernel stack pointer 3fffcfa1a370 at c000000000009980 Oops: Bad kernel stack pointer, sig: 6 [#1] CPU: 0 PID: 2006 Comm: tm-execed Not tainted NIP: c000000000009980 LR: 0000000000000000 CTR: 0000000000000000 REGS: c00000003ffefd40 TRAP: 0700 Not tainted MSR: 8000000300201031 <SF,ME,IR,DR,LE,TM[SE]> CR: 00000000 XER: 00000000 CFAR: c0000000000098b4 SOFTE: 0 PACATMSCRATCH: b00000010000d033 GPR00: 0000000000000000 00003fffcfa1a370 0000000000000000 0000000000000000 GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 00003fff966611c0 0000000000000000 0000000000000000 0000000000000000 NIP [c000000000009980] fast_exception_return+0xb0/0xb8 LR [0000000000000000] (null) Call Trace: Instruction dump: f84d0278 e9a100d8 7c7b03a6 e84101a0 7c4ff120 e8410170 7c5a03a6 e8010070 e8410080 e8610088 e8810090 e8210078 <4c000024> 48000000 e8610178 88ed023b Kernel BUG at c000000000043e80 [verbose debug info unavailable] Unexpected TM Bad Thing exception at c000000000043e80 (msr 0x201033) Oops: Unrecoverable exception, sig: 6 [#2] CPU: 0 PID: 2006 Comm: tm-execed Tainted: G D task: c0000000fbea6d80 ti: c00000003ffec000 task.ti: c0000000fb7ec000 NIP: c000000000043e80 LR: c000000000015a24 CTR: 0000000000000000 REGS: c00000003ffef7e0 TRAP: 0700 Tainted: G D MSR: 8000000300201033 <SF,ME,IR,DR,RI,LE,TM[SE]> CR: 28002828 XER: 00000000 CFAR: c000000000015a20 SOFTE: 0 PACATMSCRATCH: b00000010000d033 GPR00: 0000000000000000 c00000003ffefa60 c000000000db5500 c0000000fbead000 GPR04: 8000000300001033 2222222222222222 2222222222222222 00000000ff160000 GPR08: 0000000000000000 800000010000d033 c0000000fb7e3ea0 c00000000fe00004 GPR12: 0000000000002200 c00000000fe00000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 c0000000fbea7410 00000000ff160000 GPR24: c0000000ffe1f600 c0000000fbea8700 c0000000fbea8700 c0000000fbead000 GPR28: c000000000e20198 c0000000fbea6d80 c0000000fbeab680 c0000000fbea6d80 NIP [c000000000043e80] tm_restore_sprs+0xc/0x1c LR [c000000000015a24] __switch_to+0x1f4/0x420 Call Trace: Instruction dump: 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020 This fixes CVE-2016-5828. Fixes: bc2a940 ("powerpc: Hook in new transactional memory code") Cc: [email protected] # v3.9+ Signed-off-by: Cyril Bur <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>

Between acquiring the this_cpu_ptr() and using it, ideally we don't want to be preempted and work on another CPU's private data. this_cpu_ptr() checks whether or not preemption is disable, and get_cpu_ptr() provides a convenient wrapper for operating on the cpu ptr inside a preemption disabled critical section (which currently is provided by the spinlock). [ 167.997877] BUG: using smp_processor_id() in preemptible [00000000] code: usb-storage/216 [ 167.997940] caller is debug_smp_processor_id+0x17/0x20 [ 167.997945] CPU: 7 PID: 216 Comm: usb-storage Tainted: G U 4.7.0-rc1-gfxbench-RO_Patchwork_1057+ #1 [ 167.997948] Hardware name: Hewlett-Packard HP Pro 3500 Series/2ABF, BIOS 8.11 10/24/2012 [ 167.997951] 0000000000000000 ffff880118b7f9c8 ffffffff8140dca5 0000000000000007 [ 167.997958] ffffffff81a3a7e9 ffff880118b7f9f8 ffffffff8142a927 0000000000000000 [ 167.997965] ffff8800d499ed58 0000000000000001 00000000000fffff ffff880118b7fa08 [ 167.997971] Call Trace: [ 167.997977] [<ffffffff8140dca5>] dump_stack+0x67/0x92 [ 167.997981] [<ffffffff8142a927>] check_preemption_disabled+0xd7/0xe0 [ 167.997985] [<ffffffff8142a947>] debug_smp_processor_id+0x17/0x20 [ 167.997990] [<ffffffff81507e17>] alloc_iova_fast+0xb7/0x210 [ 167.997994] [<ffffffff8150c55f>] intel_alloc_iova+0x7f/0xd0 [ 167.997998] [<ffffffff8151021d>] intel_map_sg+0xbd/0x240 [ 167.998002] [<ffffffff810e5efd>] ? debug_lockdep_rcu_enabled+0x1d/0x20 [ 167.998009] [<ffffffff81596059>] usb_hcd_map_urb_for_dma+0x4b9/0x5a0 [ 167.998013] [<ffffffff81596d19>] usb_hcd_submit_urb+0xe9/0xaa0 [ 167.998017] [<ffffffff810cff2f>] ? mark_held_locks+0x6f/0xa0 [ 167.998022] [<ffffffff810d525c>] ? __raw_spin_lock_init+0x1c/0x50 [ 167.998025] [<ffffffff810e5efd>] ? debug_lockdep_rcu_enabled+0x1d/0x20 [ 167.998028] [<ffffffff815988f3>] usb_submit_urb+0x3f3/0x5a0 [ 167.998032] [<ffffffff810d0082>] ? trace_hardirqs_on_caller+0x122/0x1b0 [ 167.998035] [<ffffffff81599ae7>] usb_sg_wait+0x67/0x150 [ 167.998039] [<ffffffff815dc202>] usb_stor_bulk_transfer_sglist.part.3+0x82/0xd0 [ 167.998042] [<ffffffff815dc29c>] usb_stor_bulk_srb+0x4c/0x60 [ 167.998045] [<ffffffff815dc42e>] usb_stor_Bulk_transport+0x17e/0x420 [ 167.998049] [<ffffffff815dcf32>] usb_stor_invoke_transport+0x242/0x540 [ 167.998052] [<ffffffff810e5efd>] ? debug_lockdep_rcu_enabled+0x1d/0x20 [ 167.998058] [<ffffffff815dba19>] usb_stor_transparent_scsi_command+0x9/0x10 [ 167.998061] [<ffffffff815de518>] usb_stor_control_thread+0x158/0x260 [ 167.998064] [<ffffffff815de3c0>] ? fill_inquiry_response+0x20/0x20 [ 167.998067] [<ffffffff815de3c0>] ? fill_inquiry_response+0x20/0x20 [ 167.998071] [<ffffffff8109ddfa>] kthread+0xea/0x100 [ 167.998078] [<ffffffff817ac6af>] ret_from_fork+0x1f/0x40 [ 167.998081] [<ffffffff8109dd10>] ? kthread_create_on_node+0x1f0/0x1f0 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96293 Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 9257b4a ('iommu/iova: introduce per-cpu caching to iova allocation') Signed-off-by: Joerg Roedel <[email protected]>

The USB core contains a bug that can show up when a USB-3 host controller is removed. If the primary (USB-2) hcd structure is released before the shared (USB-3) hcd, the core will try to do a double-free of the common bandwidth_mutex. The problem was described in graphical form by Chung-Geol Kim, who first reported it: ================================================= At *remove USB(3.0) Storage sequence <1> --> <5> ((Problem Case)) ================================================= VOLD ------------------------------------|------------ (uevent) ________|_________ |<1> | |dwc3_otg_sm_work | |usb_put_hcd | |peer_hcd(kref=2)| |__________________| ________|_________ |<2> | |New USB BUS #2 | | | |peer_hcd(kref=1) | | | --(Link)-bandXX_mutex| | |__________________| | ___________________ | |<3> | | |dwc3_otg_sm_work | | |usb_put_hcd | | |primary_hcd(kref=1)| | |___________________| | _________|_________ | |<4> | | |New USB BUS #1 | | |hcd_release | | |primary_hcd(kref=0)| | | | | |bandXX_mutex(free) |<- |___________________| (( VOLD )) ______|___________ |<5> | | SCSI | |usb_put_hcd | |peer_hcd(kref=0) | |*hcd_release | |bandXX_mutex(free*)|<- double free |__________________| ================================================= This happens because hcd_release() frees the bandwidth_mutex whenever it sees a primary hcd being released (which is not a very good idea in any case), but in the course of releasing the primary hcd, it changes the pointers in the shared hcd in such a way that the shared hcd will appear to be primary when it gets released. This patch fixes the problem by changing hcd_release() so that it deallocates the bandwidth_mutex only when the _last_ hcd structure referencing it is released. The patch also removes an unnecessary test, so that when an hcd is released, both the shared_hcd and primary_hcd pointers in the hcd's peer will be cleared. Signed-off-by: Alan Stern <[email protected]> Reported-by: Chung-Geol Kim <[email protected]> Tested-by: Chung-Geol Kim <[email protected]> CC: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Currently we have 2 segments that are bolted for the kernel linear mapping (ie 0xc000... addresses). This is 0 to 1TB and also the kernel stacks. Anything accessed outside of these regions may need to be faulted in. (In practice machines with TM always have 1T segments) If a machine has < 2TB of memory we never fault on the kernel linear mapping as these two segments cover all physical memory. If a machine has > 2TB of memory, there may be structures outside of these two segments that need to be faulted in. This faulting can occur when running as a guest as the hypervisor may remove any SLB that's not bolted. When we treclaim and trecheckpoint we have a window where we need to run with the userspace GPRs. This means that we no longer have a valid stack pointer in r1. For this window we therefore clear MSR RI to indicate that any exceptions taken at this point won't be able to be handled. This means that we can't take segment misses in this RI=0 window. In this RI=0 region, we currently access the thread_struct for the process being context switched to or from. This thread_struct access may cause a segment fault since it's not guaranteed to be covered by the two bolted segment entries described above. We've seen this with a crash when running as a guest with > 2TB of memory on PowerVM: Unrecoverable exception 4100 at c00000000004f138 Oops: Unrecoverable exception, sig: 6 [#1] SMP NR_CPUS=2048 NUMA pSeries CPU: 1280 PID: 7755 Comm: kworker/1280:1 Tainted: G X 4.4.13-46-default #1 task: c000189001df4210 ti: c000189001d5c000 task.ti: c000189001d5c000 NIP: c00000000004f138 LR: 0000000010003a24 CTR: 0000000010001b20 REGS: c000189001d5f730 TRAP: 4100 Tainted: G X (4.4.13-46-default) MSR: 8000000100001031 <SF,ME,IR,DR,LE> CR: 24000048 XER: 00000000 CFAR: c00000000004ed18 SOFTE: 0 GPR00: ffffffffc58d7b60 c000189001d5f9b0 00000000100d7d00 000000003a738288 GPR04: 0000000000002781 0000000000000006 0000000000000000 c0000d1f4d889620 GPR08: 000000000000c350 00000000000008ab 00000000000008ab 00000000100d7af0 GPR12: 00000000100d7ae8 00003ffe787e67a0 0000000000000000 0000000000000211 GPR16: 0000000010001b20 0000000000000000 0000000000800000 00003ffe787df110 GPR20: 0000000000000001 00000000100d1e10 0000000000000000 00003ffe787df050 GPR24: 0000000000000003 0000000000010000 0000000000000000 00003fffe79e2e30 GPR28: 00003fffe79e2e68 00000000003d0f00 00003ffe787e67a0 00003ffe787de680 NIP [c00000000004f138] restore_gprs+0xd0/0x16c LR [0000000010003a24] 0x10003a24 Call Trace: [c000189001d5f9b0] [c000189001d5f9f0] 0xc000189001d5f9f0 (unreliable) [c000189001d5fb90] [c00000000001583c] tm_recheckpoint+0x6c/0xa0 [c000189001d5fbd0] [c000000000015c40] __switch_to+0x2c0/0x350 [c000189001d5fc30] [c0000000007e647c] __schedule+0x32c/0x9c0 [c000189001d5fcb0] [c0000000007e6b58] schedule+0x48/0xc0 [c000189001d5fce0] [c0000000000deabc] worker_thread+0x22c/0x5b0 [c000189001d5fd80] [c0000000000e7000] kthread+0x110/0x130 [c000189001d5fe30] [c000000000009538] ret_from_kernel_thread+0x5c/0xa4 Instruction dump: 7cb103a6 7cc0e3a6 7ca222a6 78a58402 38c00800 7cc62838 08860000 7cc000a6 38a00006 78c60022 7cc62838 0b060000 <e8c701a0> 7ccff120 e8270078 e8a70098 ---[ end trace 602126d0a1dedd54 ]--- This fixes this by copying the required data from the thread_struct to the stack before we clear MSR RI. Then once we clear RI, we only access the stack, guaranteeing there's no segment miss. We also tighten the region over which we set RI=0 on the treclaim() path. This may have a slight performance impact since we're adding an mtmsr instruction. Fixes: 090b928 ("powerpc/tm: Clear MSR RI in non-recoverable TM code") Signed-off-by: Michael Neuling <[email protected]> Reviewed-by: Cyril Bur <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>

Fix null pointer deference in clk_core_enable() when driver unbind is run when there is an application has an active pipeline playing. s5p_mfc_release() gets called after s5p_mfc_final_pm() disables and does clk_put() and s5p_mfc_release() attempts to enable clock and runs into null pointer deference accessing invalid pointer. [ 4869.434709] Unable to handle kernel NULL pointer dereference at virtual addr0 [ 4869.441312] pgd = e91ac000 [ 4869.443996] [00000010] *pgd=ba4f7835 [ 4869.447552] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 4869.452921] Modules linked in: cpufreq_userspace cpufreq_powersave cpufreq_ca [ 4869.471728] CPU: 4 PID: 2965 Comm: lt-gst-launch-1 Not tainted 4.7.0-rc2-nex0 [ 4869.481778] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 4869.487844] task: e91f1e00 ti: ed650000 task.ti: ed650000 [ 4869.493227] PC is at clk_core_enable+0x4c/0x98 [ 4869.497637] LR is at clk_core_enable+0x40/0x98 [ 4869.502056] pc : [<c0559714>] lr : [<c0559708>] psr: 60060093 [ 4869.502056] sp : ed651f18 ip : 00000000 fp : 002641b4 [ 4869.513493] r10: e9088c08 r9 : 00000008 r8 : ed676d68 [ 4869.518692] r7 : ee3ac000 r6 : bf16b3c0 r5 : a0060013 r4 : ee37a8c0 [ 4869.525191] r3 : 00000000 r2 : 00000001 r1 : 00000004 r0 : 00000000 [ 4869.531692] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment noe [ 4869.538883] Control: 10c5387d Table: 691ac06 DAC: 00000051 [ 4869.544603] Process lt-gst-launch-1 (pid: 2965, stack limit = 0xed650210) [ 4869.551361] Stack: (0xed651f18 to 0xed652000) [ 4869.555694] 1f00: ee373 [ 4869.563841] 1f20: bf16b3c0 c055a0e0 ee3ac004 ed676c10 bf16b3c0 bf1558e0 e9080 [ 4869.571986] 1f40: 00000000 ee98a510 ee502e40 bf047344 e9088c00 ee986938 00004 [ 4869.580132] 1f60: 00000000 00000000 e91f2204 00000000 c0b4658c e91f1e00 c0100 [ 4869.588277] 1f80: 00000000 c0135c58 ed650000 c0107904 ed651fb0 00000006 c0104 [ 4869.596423] 1fa0: 00229500 b6581000 b6f7b544 c0107794 00000000 00000002 b6f90 [ 4869.604568] 1fc0: 00229500 b6581000 b6f7b544 00000006 0017b600 0002c038 00264 [ 4869.612714] 1fe0: 00000000 bee56ef0 00000000 b6d49612 00060030 00000006 00000 [ 4869.620865] [<c0559714>] (clk_core_enable) from [<c055a0e0>] (clk_enable+0x2) [ 4869.628509] [<c055a0e0>] (clk_enable) from [<bf1558e0>] (s5p_mfc_release+0x3) [ 4869.637111] [<bf1558e0>] (s5p_mfc_release [s5p_mfc]) from [<bf047344>] (v4l2) [ 4869.646706] [<bf047344>] (v4l2_release [videodev]) from [<c01e4274>] (__fput) [ 4869.654745] [<c01e4274>] (__fput) from [<c0135c58>] (task_work_run+0x94/0xc8) [ 4869.661852] [<c0135c58>] (task_work_run) from [<c010a9d4>] (do_work_pending+) [ 4869.669735] [<c010a9d4>] (do_work_pending) from [<c0107794>] (slow_work_pend) [ 4869.677878] Code: ebffffef e3500000 18bd8070 e5943004 (e5933010) Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Kamil Debski <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>

commit b49b927 upstream. We shouldn't be calling clk_prepare_enable()/clk_prepare_disable() in an atomic context. Fixes the following issue: [ 5.830970] ehci-omap: OMAP-EHCI Host Controller driver [ 5.830974] driver_register 'ehci-omap' [ 5.895849] driver_register 'wl1271_sdio' [ 5.896870] BUG: scheduling while atomic: udevd/994/0x00000002 [ 5.896876] 4 locks held by udevd/994: [ 5.896904] #0: (&dev->mutex){......}, at: [<c049597c>] __driver_attach+0x60/0xac [ 5.896923] #1: (&dev->mutex){......}, at: [<c049598c>] __driver_attach+0x70/0xac [ 5.896946] #2: (tll_lock){+.+...}, at: [<c04c2630>] omap_tll_enable+0x2c/0xd0 [ 5.896966] #3: (prepare_lock){+.+...}, at: [<c05ce9c8>] clk_prepare_lock+0x48/0xe0 [ 5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine [ 5.897048] Preemption disabled at:[< (null)>] (null) [ 5.897051] [ 5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ torvalds#233 [ 5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.897076] [<c010e714>] (unwind_backtrace) from [<c010af34>] (show_stack+0x10/0x14) [ 5.897087] [<c010af34>] (show_stack) from [<c040aa7c>] (dump_stack+0x88/0xc0) [ 5.897099] [<c040aa7c>] (dump_stack) from [<c020c558>] (__schedule_bug+0xac/0xd0) [ 5.897111] [<c020c558>] (__schedule_bug) from [<c06f3d44>] (__schedule+0x88/0x7e4) [ 5.897120] [<c06f3d44>] (__schedule) from [<c06f46d8>] (schedule+0x9c/0xc0) [ 5.897129] [<c06f46d8>] (schedule) from [<c06f4904>] (schedule_preempt_disabled+0x14/0x20) [ 5.897140] [<c06f4904>] (schedule_preempt_disabled) from [<c06f64e4>] (mutex_lock_nested+0x258/0x43c) [ 5.897150] [<c06f64e4>] (mutex_lock_nested) from [<c05ce9c8>] (clk_prepare_lock+0x48/0xe0) [ 5.897160] [<c05ce9c8>] (clk_prepare_lock) from [<c05d0e7c>] (clk_prepare+0x10/0x28) [ 5.897169] [<c05d0e7c>] (clk_prepare) from [<c04c2668>] (omap_tll_enable+0x64/0xd0) [ 5.897180] [<c04c2668>] (omap_tll_enable) from [<c04c1728>] (usbhs_runtime_resume+0x18/0x17c) [ 5.897192] [<c04c1728>] (usbhs_runtime_resume) from [<c049d404>] (pm_generic_runtime_resume+0x2c/0x40) [ 5.897202] [<c049d404>] (pm_generic_runtime_resume) from [<c049f180>] (__rpm_callback+0x38/0x68) [ 5.897210] [<c049f180>] (__rpm_callback) from [<c049f220>] (rpm_callback+0x70/0x88) [ 5.897218] [<c049f220>] (rpm_callback) from [<c04a0a00>] (rpm_resume+0x4ec/0x7ec) [ 5.897227] [<c04a0a00>] (rpm_resume) from [<c04a0f48>] (__pm_runtime_resume+0x4c/0x64) [ 5.897236] [<c04a0f48>] (__pm_runtime_resume) from [<c04958dc>] (driver_probe_device+0x30/0x70) [ 5.897246] [<c04958dc>] (driver_probe_device) from [<c04959a4>] (__driver_attach+0x88/0xac) [ 5.897256] [<c04959a4>] (__driver_attach) from [<c04940f8>] (bus_for_each_dev+0x50/0x84) [ 5.897267] [<c04940f8>] (bus_for_each_dev) from [<c0494e40>] (bus_add_driver+0xcc/0x1e4) [ 5.897276] [<c0494e40>] (bus_add_driver) from [<c0496914>] (driver_register+0xac/0xf4) [ 5.897286] [<c0496914>] (driver_register) from [<c01018e0>] (do_one_initcall+0x100/0x1b8) [ 5.897296] [<c01018e0>] (do_one_initcall) from [<c01c7a54>] (do_init_module+0x58/0x1c0) [ 5.897304] [<c01c7a54>] (do_init_module) from [<c01c8a3c>] (SyS_finit_module+0x88/0x90) [ 5.897313] [<c01c8a3c>] (SyS_finit_module) from [<c0107120>] (ret_fast_syscall+0x0/0x1c) [ 5.912697] ------------[ cut here ]------------ [ 5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 _raw_spin_unlock+0x28/0x58 [ 5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count()) Reported-by: H. Nikolaus Schaller <[email protected]> Tested-by: H. Nikolaus Schaller <[email protected]> Signed-off-by: Roger Quadros <[email protected]> Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

@offset

commit 373a32c upstream. Both vhci_get_user and vhci_release race with open_timeout work. They both contain cancel_delayed_work_sync, but do not test whether the work actually created hdev or not. Since the work can be in progress and _sync will wait for finishing it, we can have data->hdev allocated when cancel_delayed_work_sync returns. But the call sites do 'if (data->hdev)' *before* cancel_delayed_work_sync. As a result: * vhci_get_user allocates a second hdev and puts it into data->hdev. The former is leaked. * vhci_release does not release data->hdev properly as it thinks there is none. Fix both cases by moving the actual test *after* the call to cancel_delayed_work_sync. This can be hit by this program: #include <err.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #include <unistd.h> #include <sys/stat.h> #include <sys/types.h> int main(int argc, char **argv) { int fd; srand(time(NULL)); while (1) { const int delta = (rand() % 200 - 100) * 100; fd = open("/dev/vhci", O_RDWR); if (fd < 0) err(1, "open"); usleep(1000000 + delta); close(fd); } return 0; } And the result is: BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228 Read of size 8 by task kworker/u13:1/32068 ============================================================================= BUG kmalloc-192 (Tainted: G E ): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040 ... kmem_cache_alloc_trace+0x150/0x190 vhci_open+0x50/0x330 [hci_vhci] misc_open+0x35b/0x4e0 chrdev_open+0x23b/0x510 ... INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040 ... __slab_free+0x204/0x310 vhci_release+0xa4/0xd0 [hci_vhci] ... INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080 INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600 Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00 ...k............ Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff ...k.......k.... Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff .F.k.....F.k.... Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00 ................ Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff @[email protected].... Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de P.n............. Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00 .........b...... Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff ........8..k.... Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00 .. ............. Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff ...........=.... Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . .............. Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb ........ Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00 ........ CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G B E 4.4.6-0-default #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014 Workqueue: hci0 hci_cmd_work [bluetooth] 00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180 ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320 ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80 Call Trace: ... [<ffffffff81ec8ebe>] ? skb_queue_tail+0x13e/0x150 [<ffffffffa06e027c>] ? vhci_send_frame+0xac/0x100 [hci_vhci] [<ffffffffa0c61268>] ? hci_send_frame+0x188/0x320 [bluetooth] [<ffffffffa0c61515>] ? hci_cmd_work+0x115/0x310 [bluetooth] [<ffffffff811a1375>] ? process_one_work+0x815/0x1340 [<ffffffff811a1f85>] ? worker_thread+0xe5/0x11f0 [<ffffffff811a1ea0>] ? process_one_work+0x1340/0x1340 [<ffffffff811b3c68>] ? kthread+0x1c8/0x230 ... Memory state around the buggy address: ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Fixes: 23424c0 (Bluetooth: Add support creating virtual AMP controllers) Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Cc: Dmitry Vyukov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e1f3028 upstream. lockdep reports the following circular locking dependency. ====================================================== INFO: possible circular locking dependency detected ] 4.6.0-rc3-00191-gfabf418 torvalds#162 Not tainted ------------------------------------------------------- systemd/1 is trying to acquire lock: ((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280 but task is already holding lock: (&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&wd_data->lock){+.+...}: [<80662310>] mutex_lock_nested+0x64/0x4a8 [<804aca4c>] watchdog_ping_work+0x18/0x4c [<80143128>] process_one_work+0x1ac/0x500 [<801434b4>] worker_thread+0x38/0x554 [<80149510>] kthread+0xf4/0x108 [<80107c10>] ret_from_fork+0x14/0x24 -> #0 ((&(&wd_data->work)->work)){+.+...}: [<8017c4e8>] lock_acquire+0x70/0x90 [<8014169c>] flush_work+0x4c/0x280 [<801440f8>] __cancel_work_timer+0x9c/0x1e0 [<804acfcc>] watchdog_release+0x3c/0x190 [<8022c5e8>] __fput+0x80/0x1c8 [<80147b28>] task_work_run+0x94/0xc8 [<8010b998>] do_work_pending+0x8c/0xb4 [<80107ba8>] slow_work_pending+0xc/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&wd_data->lock); lock((&(&wd_data->work)->work)); lock(&wd_data->lock); lock((&(&wd_data->work)->work));

commit c2985d0 upstream. Commit 80f9642 ("NFSv4.x: Enforce the ca_maxreponsesize_cached on the back channel") causes an oops when it receives a callback with cachethis=yes. [ 109.667378] BUG: unable to handle kernel NULL pointer dereference at 00000000000002c8 [ 109.669476] IP: [<ffffffffa08a3e68>] nfs4_callback_compound+0x4f8/0x690 [nfsv4] [ 109.671216] PGD 0 [ 109.671736] Oops: 0000 [#1] SMP [ 109.705427] CPU: 1 PID: 3579 Comm: nfsv4.1-svc Not tainted 4.5.0-rc1+ #1 [ 109.706987] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014 [ 109.709468] task: ffff8800b4408000 ti: ffff88008448c000 task.ti: ffff88008448c000 [ 109.711207] RIP: 0010:[<ffffffffa08a3e68>] [<ffffffffa08a3e68>] nfs4_callback_compound+0x4f8/0x690 [nfsv4] [ 109.713521] RSP: 0018:ffff88008448fca0 EFLAGS: 00010286 [ 109.714762] RAX: ffff880081ee202c RBX: ffff8800b7b5b600 RCX: 0000000000000001 [ 109.716427] RDX: 0000000000000008 RSI: 0000000000000008 RDI: 0000000000000000 [ 109.718091] RBP: ffff88008448fda8 R08: 0000000000000000 R09: 000000000b000000 [ 109.719757] R10: ffff880137786000 R11: ffff8800b7b5b600 R12: 0000000001000000 [ 109.721415] R13: 0000000000000002 R14: 0000000053270000 R15: 000000000000000b [ 109.723061] FS: 0000000000000000(0000) GS:ffff880139640000(0000) knlGS:0000000000000000 [ 109.724931] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 109.726278] CR2: 00000000000002c8 CR3: 0000000034d50000 CR4: 00000000001406e0 [ 109.727972] Stack: [ 109.728465] ffff880081ee202c ffff880081ee201c 000000008448fcc0 ffff8800baccb800 [ 109.730349] ffff8800baccc800 ffffffffa08d0380 0000000000000000 0000000000000000 [ 109.732211] ffff8800b7b5b600 0000000000000001 ffffffff81d073c0 ffff880081ee3090 [ 109.734056] Call Trace: [ 109.734657] [<ffffffffa03795d4>] svc_process_common+0x5c4/0x6c0 [sunrpc] [ 109.736267] [<ffffffffa0379a4c>] bc_svc_process+0x1fc/0x360 [sunrpc] [ 109.737775] [<ffffffffa08a2c2c>] nfs41_callback_svc+0x10c/0x1d0 [nfsv4] [ 109.739335] [<ffffffff810cb380>] ? prepare_to_wait_event+0xf0/0xf0 [ 109.740799] [<ffffffffa08a2b20>] ? nfs4_callback_svc+0x50/0x50 [nfsv4] [ 109.742349] [<ffffffff810a6998>] kthread+0xd8/0xf0 [ 109.743495] [<ffffffff810a68c0>] ? kthread_park+0x60/0x60 [ 109.744776] [<ffffffff816abc4f>] ret_from_fork+0x3f/0x70 [ 109.746037] [<ffffffff810a68c0>] ? kthread_park+0x60/0x60 [ 109.747324] Code: cc 45 31 f6 48 8b 85 00 ff ff ff 44 89 30 48 8b 85 f8 fe ff ff 44 89 20 48 8b 9d 38 ff ff ff 48 8b bd 30 ff ff ff 48 85 db 74 4c <4c> 8b af c8 02 00 00 4d 8d a5 08 02 00 00 49 81 c5 98 02 00 00 [ 109.754361] RIP [<ffffffffa08a3e68>] nfs4_callback_compound+0x4f8/0x690 [nfsv4] [ 109.756123] RSP <ffff88008448fca0> [ 109.756951] CR2: 00000000000002c8 [ 109.757738] ---[ end trace 2b8555511ab5dfb4 ]--- [ 109.758819] Kernel panic - not syncing: Fatal exception [ 109.760126] Kernel Offset: disabled [ 118.938934] ---[ end Kernel panic - not syncing: Fatal exception It doesn't unlock the table nor does it set the cps->clp pointer which is later needed by nfs4_cb_free_slot(). Fixes: 80f9642 ("NFSv4.x: Enforce the ca_maxresponsesize_cached ...") Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f0f3938 upstream. Commit ff1e22e ("xen/events: Mask a moving irq") open-coded irq_move_irq() but left out checking if the IRQ is disabled. This broke resuming from suspend since it tries to move a (disabled) irq without holding the IRQ's desc->lock. Fix it by adding in a check for disabled IRQs. The resulting stacktrace was: kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31! invalid opcode: 0000 [#1] SMP Modules linked in: xenfs xen_privcmd ... CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic torvalds#39-Ubuntu Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016 task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000 RIP: 0010:[<ffffffff810e26e2>] [<ffffffff810e26e2>] irq_move_masked_irq+0xd2/0xe0 RSP: 0018:ffff88003d7bfc50 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8 RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000 R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0 R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff FS: 0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66 Call Trace: [<ffffffff814c8d92>] eoi_pirq+0xb2/0xf0 [<ffffffff814c8f66>] __startup_pirq+0xe6/0x150 [<ffffffff814ca659>] xen_irq_resume+0x319/0x360 [<ffffffff814c7e75>] xen_suspend+0xb5/0x180 [<ffffffff81120155>] multi_cpu_stop+0xb5/0xe0 [<ffffffff811200a0>] ? cpu_stop_queue_work+0x80/0x80 [<ffffffff811203d0>] cpu_stopper_thread+0xb0/0x140 [<ffffffff810a94e6>] ? finish_task_switch+0x76/0x220 [<ffffffff810ca731>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [<ffffffff810a3935>] smpboot_thread_fn+0x105/0x160 [<ffffffff810a3830>] ? sort_range+0x30/0x30 [<ffffffff810a0588>] kthread+0xd8/0xf0 [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0 [<ffffffff8182568f>] ret_from_fork+0x3f/0x70 [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0 Signed-off-by: Ross Lagerwall <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ade8feb upstream. Since the patch "NFS: Allow multiple commit requests in flight per file" we can run multiple simultaneous commits on the same inode. This introduced a race over collecting pages to commit that made it possible to call nfs_init_commit() with an empty list - which causes crashes like the one below. The fix is to catch this race and avoid calling nfs_init_commit and initiate_commit when there is no work to do. Here is the crash: [600522.076832] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 [600522.078475] IP: [<ffffffffa0479e72>] nfs_init_commit+0x22/0x130 [nfs] [600522.078745] PGD 4272b1067 PUD 4272cb067 PMD 0 [600522.078972] Oops: 0000 [#1] SMP [600522.079204] Modules linked in: nfsv3 nfs_layout_flexfiles rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache dcdbas ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw vmw_vsock_vmci_transport vsock bonding ipmi_devintf ipmi_msghandler coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ppdev vmw_balloon parport_pc parport acpi_cpufreq vmw_vmci i2c_piix4 shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c vmwgfx drm_kms_helper ttm drm crc32c_intel serio_raw vmxnet3 [600522.081380] vmw_pvscsi ata_generic pata_acpi [600522.081809] CPU: 3 PID: 15667 Comm: /usr/bin/python Not tainted 4.1.9-100.pd.88.el7.x86_64 #1 [600522.082281] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 [600522.082814] task: ffff8800bbbfa780 ti: ffff88042ae84000 task.ti: ffff88042ae84000 [600522.083378] RIP: 0010:[<ffffffffa0479e72>] [<ffffffffa0479e72>] nfs_init_commit+0x22/0x130 [nfs] [600522.083973] RSP: 0018:ffff88042ae87438 EFLAGS: 00010246 [600522.084571] RAX: 0000000000000000 RBX: ffff880003485e40 RCX: ffff88042ae87588 [600522.085188] RDX: 0000000000000000 RSI: ffff88042ae874b0 RDI: ffff880003485e40 [600522.085756] RBP: ffff88042ae87448 R08: ffff880003486010 R09: ffff88042ae874b0 [600522.086332] R10: 0000000000000000 R11: 0000000000000005 R12: ffff88042ae872d0 [600522.086905] R13: ffff88042ae874b0 R14: ffff880003485e40 R15: ffff88042704c840 [600522.087484] FS: 00007f4728ff2740(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000 [600522.088070] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [600522.088663] CR2: 0000000000000040 CR3: 000000042b6aa000 CR4: 00000000001406e0 [600522.089327] Stack: [600522.089926] 0000000000000001 ffff88042ae87588 ffff88042ae874f8 ffffffffa04f09fa [600522.090549] 0000000000017840 0000000000017840 ffff88042ae87588 ffff8803258d9930 [600522.091169] ffff88042ae87578 ffffffffa0563d80 0000000000000000 ffff88042704c840 [600522.091789] Call Trace: [600522.092420] [<ffffffffa04f09fa>] pnfs_generic_commit_pagelist+0x1da/0x320 [nfsv4] [600522.093052] [<ffffffffa0563d80>] ? ff_layout_commit_prepare_v3+0x30/0x30 [nfs_layout_flexfiles] [600522.093696] [<ffffffffa0562645>] ff_layout_commit_pagelist+0x15/0x20 [nfs_layout_flexfiles] [600522.094359] [<ffffffffa047bc78>] nfs_generic_commit_list+0xe8/0x120 [nfs] [600522.095032] [<ffffffffa047bd6a>] nfs_commit_inode+0xba/0x110 [nfs] [600522.095719] [<ffffffffa046ac54>] nfs_release_page+0x44/0xd0 [nfs] [600522.096410] [<ffffffff811a8122>] try_to_release_page+0x32/0x50 [600522.097109] [<ffffffff811bd4f1>] shrink_page_list+0x961/0xb30 [600522.097812] [<ffffffff811bdced>] shrink_inactive_list+0x1cd/0x550 [600522.098530] [<ffffffff811bea65>] shrink_lruvec+0x635/0x840 [600522.099250] [<ffffffff811bed60>] shrink_zone+0xf0/0x2f0 [600522.099974] [<ffffffff811bf312>] do_try_to_free_pages+0x192/0x470 [600522.100709] [<ffffffff811bf6ca>] try_to_free_pages+0xda/0x170 [600522.101464] [<ffffffff811b2198>] __alloc_pages_nodemask+0x588/0x970 [600522.102235] [<ffffffff811fbbd5>] alloc_pages_vma+0xb5/0x230 [600522.103000] [<ffffffff813a1589>] ? cpumask_any_but+0x39/0x50 [600522.103774] [<ffffffff811d6115>] wp_page_copy.isra.55+0x95/0x490 [600522.104558] [<ffffffff810e3438>] ? __wake_up+0x48/0x60 [600522.105357] [<ffffffff811d7d3b>] do_wp_page+0xab/0x4f0 [600522.106137] [<ffffffff810a1bbb>] ? release_task+0x36b/0x470 [600522.106902] [<ffffffff8126dbd7>] ? eventfd_ctx_read+0x67/0x1c0 [600522.107659] [<ffffffff811da2a8>] handle_mm_fault+0xc78/0x1900 [600522.108431] [<ffffffff81067ef1>] __do_page_fault+0x181/0x420 [600522.109173] [<ffffffff811446a6>] ? __audit_syscall_exit+0x1e6/0x280 [600522.109893] [<ffffffff810681c0>] do_page_fault+0x30/0x80 [600522.110594] [<ffffffff81024f36>] ? syscall_trace_leave+0xc6/0x120 [600522.111288] [<ffffffff81790a58>] page_fault+0x28/0x30 [600522.111947] Code: 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 4c 8d 87 d0 01 00 00 48 89 e5 53 48 89 fb 48 83 ec 08 4c 8b 0e 49 8b 41 18 4c 39 ce <48> 8b 40 40 4c 8b 50 30 74 24 48 8b 87 d0 01 00 00 48 8b 7e 08 [600522.113343] RIP [<ffffffffa0479e72>] nfs_init_commit+0x22/0x130 [nfs] [600522.114003] RSP <ffff88042ae87438> [600522.114636] CR2: 0000000000000040 Fixes: af7cf05 (NFS: Allow multiple commit requests in flight per file) Signed-off-by: Weston Andros Adamson <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

If s5p_mfc_release() runs after s5p_mfc_remove(), the former will access invalid s5p_mfc_dev pointer saved in the s5p_mfc_ctx and runs into kernel paging request errors. Clear ctx dev pointer in s5p_mfc_remove() and change s5p_mfc_release() to avoid work that requires ctx->dev. odroid kernel: Unable to handle kernel paging request at virtual address f17c1104 odroid kernel: pgd = ebca4000 odroid kernel: [f17c1104] *pgd=6e23d811, *pte=00000000, *ppte=00000000 odroid kernel: Internal error: Oops: 807 [#1] PREEMPT SMP ARM odroid kernel: Modules linked in: cpufreq_userspace cpufreq_powersave cpufreq_conservative s5p_mfc s5p_jpeg v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media odroid kernel: Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) odroid kernel: task: c2241400 ti: e7018000 task.ti: e7018000 odroid kernel: PC is at s5p_mfc_reset+0x40/0x28c [s5p_mfc] odroid kernel: LR is at s5p_mfc_reset+0x34/0x28c [s5p_mfc] odroid kernel: pc : [<bf15bfbc>] lr : [<bf15bfb0>] psr: 60010013 odroid kernel: [<bf15bfbc>] (s5p_mfc_reset [s5p_mfc]) from [<bf15c62c>] (s5p_mfc_deinit_hw+0x14/0x3c [s5p_mfc]) odroid kernel: [<bf15c62c>] (s5p_mfc_deinit_hw [s5p_mfc]) from [<bf155958>] (s5p_mfc_release+0xac/0x1c4 [s5p_mfc]) odroid kernel: [<bf155958>] (s5p_mfc_release [s5p_mfc]) from [<bf021344>] (v4l2_release+0x38/0x74 [videodev]) odroid kernel: [<bf021344>] (v4l2_release [videodev]) from [<c01e4274>] (__fput+0x80/0x1c8) odroid kernel: [<c01e4274>] (__fput) from [<c0135c58>] (task_work_run+0x94/0xc8) odroid kernel: [<c0135c58>] (task_work_run) from [<c010a9d4>] (do_work_pending+0x7c/0xa4) odroid kernel: [<c010a9d4>] (do_work_pending) from [<c0107794>] (slow_work_pending+0xc/0x20) odroid kernel: Code: eb3edacc e5953078 e3a06000 e2833c11 (e5836004) Signed-off-by: Shuah Khan <[email protected]> Tested-by: Luis de Bethencourt <[email protected]> Signed-off-by: Sylwester Nawrocki <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>

Without this patch, a bug is issued when the module is removed: [ 1417.425863] cx231xx 1-3.1.4:1.1: Cx231xx dvb Extension removed [ 1417.571923] BUG: unable to handle kernel paging request at ffffffffc081a024 [ 1417.571962] IP: [<ffffffff813da854>] string+0x24/0x80 [ 1417.571987] PGD 1c09067 PUD 1c0b067 PMD 88e653067 PTE 0 [ 1417.572013] Oops: 0000 [#1] SMP [ 1417.572026] Modules linked in: mb86a20s dvb_core cx231xx_alsa ir_kbd_i2c(-) tda18271 tea5767 tuner cx25840 cx231xx i2c_mux videobuf_vmalloc tveeprom cx2341x videobuf_core rc_core v4l2_common videodev media bnep usblp fuse xt_CHECKSUM iptable_mangle tun ebtable_filter ebtables ip6table_filter ip6_tables xt_physdev br_netfilter bridge nf_log_ipv4 nf_log_common xt_LOG xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack cpufreq_stats vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_intel snd_hda_codec kvm snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm irqbypass crct10dif_pclmul iTCO_wdt crc32_pclmul nfsd hci_uart iTCO_vendor_support [ 1417.572317] snd_timer ghash_clmulni_intel btbcm intel_cstate btqca snd intel_uncore btintel intel_rapl_perf mei_me bluetooth mei shpchp soundcore pcspkr i2c_i801 auth_rpcgss wmi acpi_als kfifo_buf nfs_acl industrialio rfkill lockd pinctrl_sunrisepoint pinctrl_intel tpm_tis tpm intel_lpss_acpi intel_lpss acpi_pad grace sunrpc binfmt_misc hid_logitech_hidpp hid_logitech_dj 8021q garp stp llc mrp i915 i2c_algo_bit drm_kms_helper drm e1000e sdhci_pci sdhci mmc_core crc32c_intel ptp pps_core video i2c_hid fjes analog gameport joydev [last unloaded: rc_pixelview_002t] [ 1417.572487] CPU: 4 PID: 24493 Comm: rmmod Tainted: G W 4.7.0+ #2 [ 1417.572504] Hardware name: /NUC6i7KYB, BIOS KYSKLi70.86A.0041.2016.0817.1130 08/17/2016 [ 1417.572526] task: ffff880894b81e80 ti: ffff880896bdc000 task.ti: ffff880896bdc000 [ 1417.572544] RIP: 0010:[<ffffffff813da854>] [<ffffffff813da854>] string+0x24/0x80 [ 1417.572564] RSP: 0018:ffff880896bdfbe8 EFLAGS: 00010286 [ 1417.572577] RAX: ffffffffc081a025 RBX: ffff8808935aa15c RCX: ffff0a00ffffff04 [ 1417.572594] RDX: ffffffffc081a024 RSI: ffffffffffffffff RDI: ffff8808935aa15c [ 1417.572610] RBP: ffff880896bdfbe8 R08: fffffffffffffffe R09: ffff8808935aa91c [ 1417.572628] R10: ffffffffc07b85d6 R11: 0000000000000000 R12: ffff8808935aa91c [ 1417.572644] R13: 00000000000007c5 R14: ffffffffc07b85dd R15: ffffffffc07b85dd [ 1417.572662] FS: 00007f5a5392d700(0000) GS:ffff8808bed00000(0000) knlGS:0000000000000000 [ 1417.572681] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1417.572705] CR2: ffffffffc081a024 CR3: 0000000897188000 CR4: 00000000003406e0 [ 1417.572735] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1417.572761] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1417.572778] Stack: [ 1417.572785] ffff880896bdfc48 ffffffff813dcf77 0000000000000005 ffff8808935aa157 [ 1417.572806] ffff880896bdfc58 ffff0a00ffffff04 000000009d27375e ffff8808935aa000 [ 1417.572829] 0000000000000800 ffff880896182800 0000000000000000 ffff88089e898ae0 [ 1417.572850] Call Trace: [ 1417.572860] [<ffffffff813dcf77>] vsnprintf+0x2d7/0x500 [ 1417.572873] [<ffffffff813d3e12>] add_uevent_var+0x82/0x120 [ 1417.572890] [<ffffffffc07b534d>] rc_dev_uevent+0x2d/0x60 [rc_core] [ 1417.572907] [<ffffffff81515969>] dev_uevent+0xd9/0x2d0 [ 1417.572921] [<ffffffff813d4309>] kobject_uevent_env+0x2d9/0x4f0 [ 1417.572938] [<ffffffff813d452b>] kobject_uevent+0xb/0x10 [ 1417.572954] [<ffffffff81513a3f>] device_del+0x18f/0x260 [ 1417.572974] [<ffffffff813d2db7>] ? kobject_put+0x27/0x50 [ 1417.572998] [<ffffffffc07b5e25>] rc_unregister_device+0x75/0xb0 [rc_core] [ 1417.573028] [<ffffffffc07e6023>] ir_remove+0x23/0x30 [ir_kbd_i2c] [ 1417.573055] [<ffffffff8162bf88>] i2c_device_remove+0x58/0xb0 [ 1417.573078] [<ffffffff81518191>] __device_release_driver+0xa1/0x160 [ 1417.573102] [<ffffffff81518de6>] driver_detach+0xa6/0xb0 [ 1417.573122] [<ffffffff81517b25>] bus_remove_driver+0x55/0xd0 [ 1417.573146] [<ffffffff815195bc>] driver_unregister+0x2c/0x50 [ 1417.573168] [<ffffffff8162cf62>] i2c_del_driver+0x22/0x50 [ 1417.573194] [<ffffffffc07e6ba4>] ir_kbd_driver_exit+0x10/0x46c [ir_kbd_i2c] [ 1417.573227] [<ffffffff81126348>] SyS_delete_module+0x1b8/0x220 [ 1417.573254] [<ffffffff817debf2>] entry_SYSCALL_64_fastpath+0x1a/0xa4 [ 1417.573279] Code: eb e9 76 ff ff ff 90 55 49 89 f1 48 89 ce 48 c1 fe 30 48 81 fa ff 0f 00 00 48 89 e5 4c 8d 46 ff 76 40 48 85 f6 74 4e 48 8d 42 01 <0f> b6 12 84 d2 74 43 49 01 c0 31 f6 eb 0c 48 83 c0 01 0f b6 50 [ 1417.573437] RIP [<ffffffff813da854>] string+0x24/0x80 [ 1417.573455] RSP <ffff880896bdfbe8> [ 1417.573465] CR2: ffffffffc081a024 [ 1417.580053] ---[ end trace 4ca9e2eced326a62 ]--- Signed-off-by: Mauro Carvalho Chehab <[email protected]>

andrey-utkin changed the title ~~Improve signal perception on noicy cams~~ Improve signal perception on noisy cams Apr 9, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve signal perception on noisy cams #1

Improve signal perception on noisy cams #1

andrey-utkin commented Apr 9, 2016

Improve signal perception on noisy cams #1

Improve signal perception on noisy cams #1

Comments

andrey-utkin commented Apr 9, 2016