commit 1d074db69c46d62ce82b331c2080e2fcb710bf4a Author: Greg Kroah-Hartman Date: Thu Sep 15 08:29:29 2016 +0200 Linux 4.4.21 commit 11c27e850d90372d79c1337be299923b5fb353e8 Author: Nicolai Stange Date: Tue Mar 22 13:12:35 2016 +0100 lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs commit f2d1362ff7d266b3d2b1c764d6c2ef4a3b457f23 upstream. Currently, if the number of leading zeros is greater than fits into a complete limb, mpi_write_sgl() skips them by iterating over them limb-wise. However, it fails to adjust its internal leading zeros tracking variable, lzeros, accordingly: it does a p -= sizeof(alimb); continue; which should really have been a lzeros -= sizeof(alimb); continue; Since lzeros never decreases if its initial value >= sizeof(alimb), nothing gets copied by mpi_write_sgl() in that case. Instead of skipping the high order zero limbs within the loop as shown above, fix the issue by adjusting the copying loop's bounds. Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") Signed-off-by: Nicolai Stange Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3838b04f6d5868f5ec5ee52ce1391b6253c6ce16 Author: Mika Båtsman Date: Fri Jun 17 13:31:37 2016 +0300 regulator: anatop: allow regulator to be in bypass mode commit 8a092e682f20f193f2070dba2ea1904e95814126 upstream. Bypass support was added in commit d38018f2019c ("regulator: anatop: Add bypass support to digital LDOs"). A check for valid voltage selectors was added in commit da0607c8df5c ("regulator: anatop: Fail on invalid voltage selector") but it also discards all regulators that are in bypass mode. Add check for the bypass setting. Errors below were seen on a Variscite mx6 board. anatop_regulator 20c8000.anatop:regulator-vddcore@140: Failed to read a valid default voltage selector. anatop_regulator: probe of 20c8000.anatop:regulator-vddcore@140 failed with error -22 anatop_regulator 20c8000.anatop:regulator-vddsoc@140: Failed to read a valid default voltage selector. anatop_regulator: probe of 20c8000.anatop:regulator-vddsoc@140 failed with error -22 Fixes: da0607c8df5c ("regulator: anatop: Fail on invalid voltage selector") Signed-off-by: Mika Båtsman Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 390bddc4a36d2ce015a9d78d8624e575cbac9cd3 Author: Krzysztof Kozlowski Date: Mon Mar 14 09:07:14 2016 +0900 hwrng: exynos - Disable runtime PM on probe failure commit 48a61e1e2af8020f11a2b8f8dc878144477623c6 upstream. Add proper error path (for disabling runtime PM) when registering of hwrng fails. Fixes: b329669ea0b5 ("hwrng: exynos - Add support for Exynos random number generator") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit aaac8cab2f92aa235f6f79e8cff52bf11c0fbf1d Author: Sai Gurrappadi Date: Fri Apr 29 14:44:37 2016 -0700 cpufreq: Fix GOV_LIMITS handling for the userspace governor commit e43e94c1eda76dabd686ddf6f7825f54d747b310 upstream. Currently, the userspace governor only updates frequency on GOV_LIMITS if policy->cur falls outside policy->{min/max}. However, it is also necessary to update current frequency on GOV_LIMITS to match the user requested value if it can be achieved within the new policy->{max/min}. This was previously the behaviour in the governor until commit d1922f0 ("cpufreq: Simplify userspace governor") which incorrectly assumed that policy->cur == user requested frequency via scaling_setspeed. This won't be true if the user requested frequency falls outside policy->{min/max}. Ex: a temporary thermal cap throttled the user requested frequency. Fix this by storing the user requested frequency in a seperate variable. The governor will then try to achieve this request on every GOV_LIMITS change. Fixes: d1922f02562f (cpufreq: Simplify userspace governor) Signed-off-by: Sai Gurrappadi Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 73e6305cf0f89ee66abe522a75eb614212b1c8a2 Author: James Hogan Date: Tue May 3 09:11:21 2016 +0100 metag: Fix atomic_*_return inline asm constraints commit 096a8b6d5e7ab9f8ca3d2474b3ca6a1fe79e0371 upstream. The argument i of atomic_*_return() operations is given to inline asm with the "bd" constraint, which means "An Op2 register where Op1 is a data unit register and the instruction supports O2R", however Op1 is constrained by "da" which allows an address unit register to be used. Fix the constraint to use "br", meaning "An Op2 register and the instruction supports O2R", i.e. not requiring Op1 to be a data unit register. Fixes: d6dfe2509da9 ("locking,arch,metag: Fold atomic_ops") Signed-off-by: James Hogan Cc: Peter Zijlstra Cc: linux-metag@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6f0caecda50f411841d9791e1fe54c30d33969b7 Author: Tyrel Datwyler Date: Fri Aug 12 17:20:07 2016 -0500 scsi: fix upper bounds check of sense key in scsi_sense_key_string() commit a87eeb900dbb9f8202f96604d56e47e67c936b9d upstream. Commit 655ee63cf371 ("scsi constants: command, sense key + additional sense string") added a "Completed" sense string with key 0xF to snstext[], but failed to updated the upper bounds check of the sense key in scsi_sense_key_string(). Fixes: 655ee63cf371 ("[SCSI] scsi constants: command, sense key + additional sense strings") Signed-off-by: Tyrel Datwyler Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit f5b004e4edb87ea4c0a72a72191f33d372d08251 Author: Vegard Nossum Date: Mon Aug 29 00:33:51 2016 +0200 ALSA: timer: fix NULL pointer dereference on memory allocation failure commit 8ddc05638ee42b18ba4fe99b5fb647fa3ad20456 upstream. I hit this with syzkaller: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 task: ffff88011278d600 task.stack: ffff8801120c0000 RIP: 0010:[] [] snd_hrtimer_start+0x77/0x100 RSP: 0018:ffff8801120c7a60 EFLAGS: 00010006 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007 RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048 RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790 R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980 R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286 FS: 00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0 Stack: ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0 ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000 ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0 Call Trace: [] snd_timer_start1+0x331/0x670 [] snd_timer_start+0x5d/0xa0 [] snd_timer_user_ioctl+0x88e/0x2830 [] ? __follow_pte.isra.49+0x430/0x430 [] ? snd_timer_pause+0x80/0x80 [] ? do_wp_page+0x3aa/0x1c90 [] ? put_prev_entity+0x108f/0x21a0 [] ? snd_timer_pause+0x80/0x80 [] do_vfs_ioctl+0x193/0x1050 [] ? cpuacct_account_field+0x12f/0x1a0 [] ? ioctl_preallocate+0x200/0x200 [] ? syscall_trace_enter+0x3cf/0xdb0 [] ? __context_tracking_exit.part.4+0x9a/0x1e0 [] ? exit_to_usermode_loop+0x190/0x190 [] ? check_preemption_disabled+0x37/0x1e0 [] ? security_file_ioctl+0x89/0xb0 [] SyS_ioctl+0x8f/0xc0 [] ? do_vfs_ioctl+0x1050/0x1050 [] do_syscall_64+0x1c4/0x4e0 [] entry_SYSCALL64_slow_path+0x25/0x25 Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46 RIP [] snd_hrtimer_start+0x77/0x100 RSP ---[ end trace 5955b08db7f2b029 ]--- This can happen if snd_hrtimer_open() fails to allocate memory and returns an error, which is currently not checked by snd_timer_open(): ioctl(SNDRV_TIMER_IOCTL_SELECT) - snd_timer_user_tselect() - snd_timer_close() - snd_hrtimer_close() - (struct snd_timer *) t->private_data = NULL - snd_timer_open() - snd_hrtimer_open() - kzalloc() fails; t->private_data is still NULL ioctl(SNDRV_TIMER_IOCTL_START) - snd_timer_user_start() - snd_timer_start() - snd_timer_start1() - snd_hrtimer_start() - t->private_data == NULL // boom Signed-off-by: Vegard Nossum Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6fd91313bfcfd44cebcb2a55dbeeb606ee3cd710 Author: Vegard Nossum Date: Mon Aug 29 00:33:50 2016 +0200 ALSA: timer: fix division by zero after SNDRV_TIMER_IOCTL_CONTINUE commit 6b760bb2c63a9e322c0e4a0b5daf335ad93d5a33 upstream. I got this: divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 task: ffff8801120a9580 task.stack: ffff8801120b0000 RIP: 0010:[] [] snd_hrtimer_callback+0x1da/0x3f0 RSP: 0018:ffff88011aa87da8 EFLAGS: 00010006 RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001 RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048 R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00 R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000 FS: 00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0 Stack: 0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76 ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0 00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0 Call Trace: [] __hrtimer_run_queues+0x347/0xa00 [] ? snd_hrtimer_close+0x130/0x130 [] ? retrigger_next_event+0x1b0/0x1b0 [] ? hrtimer_interrupt+0x136/0x4b0 [] hrtimer_interrupt+0x1b0/0x4b0 [] local_apic_timer_interrupt+0x6e/0xf0 [] ? kvm_guest_apic_eoi_write+0x13/0xc0 [] smp_apic_timer_interrupt+0x76/0xa0 [] apic_timer_interrupt+0x8c/0xa0 [] ? _raw_spin_unlock_irqrestore+0x2c/0x60 [] snd_timer_start1+0xdd/0x670 [] snd_timer_continue+0x45/0x80 [] snd_timer_user_ioctl+0x1030/0x2830 [] ? __follow_pte.isra.49+0x430/0x430 [] ? snd_timer_pause+0x80/0x80 [] ? do_wp_page+0x3aa/0x1c90 [] ? handle_mm_fault+0xbc8/0x27f0 [] ? __pmd_alloc+0x370/0x370 [] ? snd_timer_pause+0x80/0x80 [] do_vfs_ioctl+0x193/0x1050 [] ? ioctl_preallocate+0x200/0x200 [] ? syscall_trace_enter+0x3cf/0xdb0 [] ? __context_tracking_exit.part.4+0x9a/0x1e0 [] ? exit_to_usermode_loop+0x190/0x190 [] ? check_preemption_disabled+0x37/0x1e0 [] ? security_file_ioctl+0x89/0xb0 [] SyS_ioctl+0x8f/0xc0 [] ? do_vfs_ioctl+0x1050/0x1050 [] do_syscall_64+0x1c4/0x4e0 [] entry_SYSCALL64_slow_path+0x25/0x25 Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 <48> f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00 RIP [] snd_hrtimer_callback+0x1da/0x3f0 RSP ---[ end trace 6aa380f756a21074 ]--- The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a completely new/unused timer -- it will have ->sticks == 0, which causes a divide by 0 in snd_hrtimer_callback(). Signed-off-by: Vegard Nossum Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6664ad65f31ecb35f4f7d8208036b5dbc7640740 Author: Vegard Nossum Date: Sun Aug 28 10:13:07 2016 +0200 ALSA: timer: fix NULL pointer dereference in read()/ioctl() race commit 11749e086b2766cccf6217a527ef5c5604ba069c upstream. I got this with syzkaller: ================================================================== BUG: KASAN: null-ptr-deref on address 0000000000000020 Read of size 32 by task syz-executor/22519 CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2 014 0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90 ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80 ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68 Call Trace: [] dump_stack+0x83/0xb2 [] kasan_report_error+0x41f/0x4c0 [] kasan_report+0x34/0x40 [] ? snd_timer_user_read+0x554/0x790 [] check_memory_region+0x13e/0x1a0 [] kasan_check_read+0x11/0x20 [] snd_timer_user_read+0x554/0x790 [] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0 [] ? proc_fault_inject_write+0x1c1/0x250 [] ? next_tgid+0x2a0/0x2a0 [] ? do_group_exit+0x108/0x330 [] ? fsnotify+0x72a/0xca0 [] __vfs_read+0x10e/0x550 [] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0 [] ? do_sendfile+0xc50/0xc50 [] ? __fsnotify_update_child_dentry_flags+0x60/0x60 [] ? kcov_ioctl+0x56/0x190 [] ? common_file_perm+0x2e2/0x380 [] ? __fsnotify_parent+0x5e/0x2b0 [] ? security_file_permission+0x86/0x1e0 [] ? rw_verify_area+0xe5/0x2b0 [] vfs_read+0x115/0x330 [] SyS_read+0xd1/0x1a0 [] ? vfs_write+0x4b0/0x4b0 [] ? __this_cpu_preempt_check+0x1c/0x20 [] ? __context_tracking_exit.part.4+0x3a/0x1e0 [] ? vfs_write+0x4b0/0x4b0 [] do_syscall_64+0x1c4/0x4e0 [] ? syscall_return_slowpath+0x16c/0x1d0 [] entry_SYSCALL64_slow_path+0x25/0x25 ================================================================== There are a couple of problems that I can see: - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets tu->queue/tu->tqueue to NULL on memory allocation failure, so read() would get a NULL pointer dereference like the above splat - the same ioctl() can free tu->queue/to->tqueue which means read() could potentially see (and dereference) the freed pointer We can fix both by taking the ioctl_lock mutex when dereferencing ->queue/->tqueue, since that's always held over all the ioctl() code. Just looking at the code I find it likely that there are more problems here such as tu->qhead pointing outside the buffer if the size is changed concurrently using SNDRV_TIMER_IOCTL_PARAMS. Signed-off-by: Vegard Nossum Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 857fbd7a74d2cb1a396f4733536e10e74c4908a6 Author: Kai-Heng Feng Date: Tue Aug 30 15:36:34 2016 +0800 ALSA: hda - Enable subwoofer on Dell Inspiron 7559 commit fd06c77eb9200b53d421da5fffe0dcd894b5d72a upstream. The subwoofer on Inspiron 7559 was disabled originally. Applying a pin fixup to node 0x1b can enable it and make it work. Old pin: 0x411111f0 New pin: 0x90170151 Signed-off-by: Kai-Heng Feng Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit eea36eb2c42be7e1eba65bb17cfa1018270184b1 Author: Shrirang Bagul Date: Mon Aug 29 15:19:27 2016 +0800 ALSA: hda - Add headset mic quirk for Dell Inspiron 5468 commit 311042d1b67d9a1856a8e1294e7729fb86f64014 upstream. This patch enables headset microphone on some variants of Dell Inspiron 5468. (Dell SSID 0x07ad) BugLink: https://bugs.launchpad.net/bugs/1617900 Signed-off-by: Shrirang Bagul Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 42c51d003bfd58b3d1bc966ad25f69c5b4974f9b Author: Takashi Iwai Date: Tue Aug 30 14:45:46 2016 +0200 ALSA: rawmidi: Fix possible deadlock with virmidi registration commit 816f318b2364262a51024096da7ca3b84e78e3b5 upstream. When a seq-virmidi driver is initialized, it registers a rawmidi instance with its callback to create an associated seq kernel client. Currently it's done throughly in rawmidi's register_mutex context. Recently it was found that this may lead to a deadlock another rawmidi device that is being attached with the sequencer is accessed, as both open with the same register_mutex. This was actually triggered by syzkaller, as Dmitry Vyukov reported: ====================================================== [ INFO: possible circular locking dependency detected ] 4.8.0-rc1+ #11 Not tainted ------------------------------------------------------- syz-executor/7154 is trying to acquire lock: (register_mutex#5){+.+.+.}, at: [] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341 but task is already holding lock: (&grp->list_mutex){++++.+}, at: [] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&grp->list_mutex){++++.+}: [] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746 [] down_read+0x49/0xc0 kernel/locking/rwsem.c:22 [< inline >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681 [] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822 [] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418 [] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101 [] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297 [< inline >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383 [] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450 [] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645 [] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164 [< inline >] __snd_device_register sound/core/device.c:162 [] snd_device_register_all+0xad/0x110 sound/core/device.c:212 [] snd_card_register+0xef/0x6c0 sound/core/init.c:749 [] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123 [] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564 ...... -> #0 (register_mutex#5){+.+.+.}: [< inline >] check_prev_add kernel/locking/lockdep.c:1829 [< inline >] check_prevs_add kernel/locking/lockdep.c:1939 [< inline >] validate_chain kernel/locking/lockdep.c:2266 [] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335 [] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746 [< inline >] __mutex_lock_common kernel/locking/mutex.c:521 [] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621 [] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341 [] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188 [< inline >] subscribe_port sound/core/seq/seq_ports.c:427 [] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510 [] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579 [] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480 [] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225 [] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440 [] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375 [] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281 [] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274 [] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138 [] soundcore_open+0x30f/0x640 sound/sound_core.c:639 ...... other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&grp->list_mutex); lock(register_mutex#5); lock(&grp->list_mutex); lock(register_mutex#5); *** DEADLOCK *** ====================================================== The fix is to simply move the registration parts in snd_rawmidi_dev_register() to the outside of the register_mutex lock. The lock is needed only to manage the linked list, and it's not necessarily to cover the whole initialization process. Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e6c4138bc1e6021be12eba70bb90a2ea2a3dc96a Author: Takashi Sakamoto Date: Wed Aug 31 22:58:42 2016 +0900 ALSA: fireworks: accessing to user space outside spinlock commit 6b1ca4bcadf9ef077cc5f03c6822ba276ed14902 upstream. In hwdep interface of fireworks driver, accessing to user space is in a critical section with disabled local interrupt. Depending on architecture, accessing to user space can cause page fault exception. Then local processor stores machine status and handles the synchronous event. A handler corresponding to the event can call task scheduler to wait for preparing pages. In a case of usage of single core processor, the state to disable local interrupt is worse because it don't handle usual interrupts from hardware. This commit fixes this bug, performing the accessing outside spinlock. This commit also gives up counting the number of queued response messages to simplify ring-buffer management. Reported-by: Vaishali Thakkar Fixes: 555e8a8f7f14('ALSA: fireworks: Add command/response functionality into hwdep interface') Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ad3bccfd7d6c0d9b263977492f2f712f1859b5b2 Author: Takashi Sakamoto Date: Wed Aug 31 20:15:32 2016 +0900 ALSA: firewire-tascam: accessing to user space outside spinlock commit 04b2d9c9c319277ad4fbbb71855c256a9f4d5f98 upstream. In hwdep interface of firewire-tascam driver, accessing to user space is in a critical section with disabled local interrupt. Depending on architecture, accessing to user space can cause page fault exception. Then local processor stores machine status and handle the synchronous event. A handler corresponding to the event can call task scheduler to wait for preparing pages. In a case of usage of single core processor, the state to disable local interrupt is worse because it doesn't handle usual interrupts from hardware. This commit fixes this bug, by performing the accessing outside spinlock. Reported-by: Vaishali Thakkar Fixes: e5e0c3dd257b('ALSA: firewire-tascam: add hwdep interface') Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9947ec2c04d30412a06e45a4af03f28c2d76d1f6 Author: Ken Lin Date: Fri Aug 12 14:08:47 2016 -0400 ALSA: usb-audio: Add sample rate inquiry quirk for B850V3 CP2114 commit 83d9956b7e6b310c1062df7894257251c625b22e upstream. Avoid getting sample rate on B850V3 CP2114 as it is unsupported and causes noisy "current rate is different from the runtime rate" messages when playback starts. Signed-off-by: Ken Lin Signed-off-by: Akshay Bhat Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f973851a595969f2a57f81e3c915cc116ae5a74f Author: Horia Geantă Date: Mon Aug 29 14:52:14 2016 +0300 crypto: caam - fix IV loading for authenc (giv)decryption commit 8b18e2359aff2ab810aba84cebffc9da07fef78f upstream. For algorithms that implement IV generators before the crypto ops, the IV needed for decryption is initially located in req->src scatterlist, not in req->iv. Avoid copying the IV into req->iv by modifying the (givdecrypt) descriptors to load it directly from req->src. aead_givdecrypt() is no longer needed and goes away. Fixes: 479bcc7c5b9e ("crypto: caam - Convert authenc to new AEAD interface") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f964b3b368b59cc03e26d3f5b5226432b22d9a0d Author: Oleg Nesterov Date: Wed Aug 17 17:36:29 2016 +0200 uprobes: Fix the memcg accounting commit 6c4687cc17a788a6dd8de3e27dbeabb7cbd3e066 upstream. __replace_page() wronlgy calls mem_cgroup_cancel_charge() in "success" path, it should only do this if page_check_address() fails. This means that every enable/disable leads to unbalanced mem_cgroup_uncharge() from put_page(old_page), it is trivial to underflow the page_counter->count and trigger OOM. Reported-and-tested-by: Brenden Blanco Signed-off-by: Oleg Nesterov Reviewed-by: Johannes Weiner Acked-by: Michal Hocko Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vladimir Davydov Fixes: 00501b531c47 ("mm: memcontrol: rewrite charge API") Link: http://lkml.kernel.org/r/20160817153629.GB29724@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2e133f2d2cf40736ebc028ffa11dd907dc0753eb Author: Wanpeng Li Date: Tue Aug 23 20:07:19 2016 +0800 x86/apic: Do not init irq remapping if ioapic is disabled commit 2e63ad4bd5dd583871e6602f9d398b9322d358d9 upstream. native_smp_prepare_cpus -> default_setup_apic_routing -> enable_IR_x2apic -> irq_remapping_prepare -> intel_prepare_irq_remapping -> intel_setup_irq_remapping So IR table is setup even if "noapic" boot parameter is added. As a result we crash later when the interrupt affinity is set due to a half initialized remapping infrastructure. Prevent remap initialization when IOAPIC is disabled. Signed-off-by: Wanpeng Li Cc: Peter Zijlstra Cc: Joerg Roedel Link: http://lkml.kernel.org/r/1471954039-3942-1-git-send-email-wanpeng.li@hotmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 9cb2e06aa5ce916bd77cb1c4ec75cbb2a3d0b736 Author: Benjamin Coddington Date: Mon Jun 6 18:07:59 2016 -0400 vhost/scsi: fix reuse of &vq->iov[out] in response commit a77ec83a57890240c546df00ca5df1cdeedb1cc3 upstream. The address of the iovec &vq->iov[out] is not guaranteed to contain the scsi command's response iovec throughout the lifetime of the command. Rather, it is more likely to contain an iovec from an immediately following command after looping back around to vhost_get_vq_desc(). Pass along the iovec entirely instead. Fixes: 79c14141a487 ("vhost/scsi: Convert completion path to use copy_to_iter") Signed-off-by: Benjamin Coddington Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 2d64cbc819b13ebd503780f39552827516f4ce4a Author: Kent Overstreet Date: Wed Aug 17 18:21:24 2016 -0700 bcache: RESERVE_PRIO is too small by one when prio_buckets() is a power of two. commit acc9cf8c66c66b2cbbdb4a375537edee72be64df upstream. This patch fixes a cachedev registration-time allocation deadlock. This can deadlock on boot if your initrd auto-registeres bcache devices: Allocator thread: [ 720.727614] INFO: task bcache_allocato:3833 blocked for more than 120 seconds. [ 720.732361] [] schedule+0x37/0x90 [ 720.732963] [] bch_bucket_alloc+0x188/0x360 [bcache] [ 720.733538] [] ? prepare_to_wait_event+0xf0/0xf0 [ 720.734137] [] bch_prio_write+0x19d/0x340 [bcache] [ 720.734715] [] bch_allocator_thread+0x3ff/0x470 [bcache] [ 720.735311] [] ? __schedule+0x2dc/0x950 [ 720.735884] [] ? invalidate_buckets+0x980/0x980 [bcache] Registration thread: [ 720.710403] INFO: task bash:3531 blocked for more than 120 seconds. [ 720.715226] [] schedule+0x37/0x90 [ 720.715805] [] __bch_btree_map_nodes+0x12d/0x150 [bcache] [ 720.716409] [] ? bch_btree_insert_check_key+0x1c0/0x1c0 [bcache] [ 720.717008] [] bch_btree_insert+0xf4/0x170 [bcache] [ 720.717586] [] ? prepare_to_wait_event+0xf0/0xf0 [ 720.718191] [] bch_journal_replay+0x14a/0x290 [bcache] [ 720.718766] [] ? ttwu_do_activate.constprop.94+0x5d/0x70 [ 720.719369] [] ? try_to_wake_up+0x1d4/0x350 [ 720.719968] [] run_cache_set+0x580/0x8e0 [bcache] [ 720.720553] [] register_bcache+0xe2e/0x13b0 [bcache] [ 720.721153] [] kobj_attr_store+0xf/0x20 [ 720.721730] [] sysfs_kf_write+0x3d/0x50 [ 720.722327] [] kernfs_fop_write+0x12a/0x180 [ 720.722904] [] __vfs_write+0x37/0x110 [ 720.723503] [] ? __sb_start_write+0x58/0x110 [ 720.724100] [] ? security_file_permission+0x23/0xa0 [ 720.724675] [] vfs_write+0xa9/0x1b0 [ 720.725275] [] ? do_audit_syscall_entry+0x6c/0x70 [ 720.725849] [] SyS_write+0x55/0xd0 [ 720.726451] [] ? do_page_fault+0x30/0x80 [ 720.727045] [] system_call_fastpath+0x12/0x71 The fifo code in upstream bcache can't use the last element in the buffer, which was the cause of the bug: if you asked for a power of two size, it'd give you a fifo that could hold one less than what you asked for rather than allocating a buffer twice as big. Signed-off-by: Kent Overstreet Tested-by: Eric Wheeler Signed-off-by: Greg Kroah-Hartman commit 4c10981673bb8aa798dac491bef41389646d02b1 Author: Vincent Stehlé Date: Fri Aug 12 15:26:30 2016 +0200 ubifs: Fix assertion in layout_in_gaps() commit c0082e985fdf77b02fc9e0dac3b58504dcf11b7a upstream. An assertion in layout_in_gaps() verifies that the gap_lebs pointer is below the maximum bound. When computing this maximum bound the idx_lebs count is multiplied by sizeof(int), while C pointers arithmetic does take into account the size of the pointed elements implicitly already. Remove the multiplication to fix the assertion. Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system") Signed-off-by: Vincent Stehlé Cc: Artem Bityutskiy Signed-off-by: Artem Bityutskiy Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 2f949da9c0203bb8b309daddcf532593d019fc2b Author: Miklos Szeredi Date: Mon Sep 5 13:55:20 2016 +0200 ovl: fix workdir creation commit e1ff3dd1ae52cef5b5373c8cc4ad949c2c25a71c upstream. Workdir creation fails in latest kernel. Fix by allowing EOPNOTSUPP as a valid return value from vfs_removexattr(XATTR_NAME_POSIX_ACL_*). Upper filesystem may not support ACL and still be perfectly able to support overlayfs. Reported-by: Martin Ziegler Signed-off-by: Miklos Szeredi Fixes: c11b9fdd6a61 ("ovl: remove posix_acl_default from workdir") Signed-off-by: Greg Kroah-Hartman commit 708cb42fcaef0874a81100b461833096564db6cf Author: Miklos Szeredi Date: Thu Sep 1 11:12:00 2016 +0200 ovl: listxattr: use strnlen() commit 7cb35119d067191ce9ebc380a599db0b03cbd9d9 upstream. Be defensive about what underlying fs provides us in the returned xattr list buffer. If it's not properly null terminated, bail out with a warning insead of BUG. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit d57a6c748059eb1f90cde4b40091f57617b72609 Author: Miklos Szeredi Date: Thu Sep 1 11:11:59 2016 +0200 ovl: remove posix_acl_default from workdir commit c11b9fdd6a612f376a5e886505f1c54c16d8c380 upstream. Clear out posix acl xattrs on workdir and also reset the mode after creation so that an inherited sgid bit is cleared. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 48fd20d7237bfefd18750b1b38f426c7e210462d Author: Miklos Szeredi Date: Mon Aug 8 15:08:49 2016 +0200 ovl: don't copy up opaqueness commit 0956254a2d5b9e2141385514553aeef694dfe3b5 upstream. When a copy up of a directory occurs which has the opaque xattr set, the xattr remains in the upper directory. The immediate behavior with overlayfs is that the upper directory is not treated as opaque, however after a remount the opaque flag is used and upper directory is treated as opaque. This causes files created in the lower layer to be hidden when using multiple lower directories. Fix by not copying up the opaque flag. To reproduce: ----8<---------8<---------8<---------8<---------8<---------8<---- mkdir -p l/d/s u v w mnt mount -t overlay overlay -olowerdir=l,upperdir=u,workdir=w mnt rm -rf mnt/d/ mkdir -p mnt/d/n umount mnt mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt touch mnt/d/foo umount mnt mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt ls mnt/d ----8<---------8<---------8<---------8<---------8<---------8<---- output should be: "foo n" Reported-by: Derek McGowan Link: https://bugzilla.kernel.org/show_bug.cgi?id=151291 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit d72e9b2566e79f0ca6fe128d8bb6972209a816fc Author: Al Viro Date: Fri Jan 22 15:40:57 2016 -0500 wrappers for ->i_mutex access commit 5955102c9984fa081b2d570cfac75c97eecf8f3b upstream parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested}, inode_foo(inode) being mutex_foo(&inode->i_mutex). Please, use those for access to ->i_mutex; over the coming cycle ->i_mutex will become rwsem, with ->lookup() done with it held only shared. Signed-off-by: Al Viro [only the fs.h change included to make backports easier - gregkh] Signed-off-by: Greg Kroah-Hartman commit 09ca40a6afc93c21ec2ecc2ff9ba5b7c7360a0b7 Author: Al Viro Date: Fri Jan 22 15:34:16 2016 -0500 lustre: remove unused declaration commit 57b8f112cfe6622ddddb8c2641206bb5fa8a112d upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 4eca11dbd272076f05c934dfd3005afc4b77c521 Author: John Stultz Date: Tue Aug 23 16:08:21 2016 -0700 timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING commit 27727df240c7cc84f2ba6047c6f18d5addfd25ef upstream. When I added some extra sanity checking in timekeeping_get_ns() under CONFIG_DEBUG_TIMEKEEPING, I missed that the NMI safe __ktime_get_fast_ns() method was using timekeeping_get_ns(). Thus the locking added to the debug checks broke the NMI-safety of __ktime_get_fast_ns(). This patch open-codes the timekeeping_get_ns() logic for __ktime_get_fast_ns(), so can avoid any deadlocks in NMI. Fixes: 4ca22c2648f9 "timekeeping: Add warnings when overflows or underflows are observed" Reported-by: Steven Rostedt Reported-by: Peter Zijlstra Signed-off-by: John Stultz Link: http://lkml.kernel.org/r/1471993702-29148-2-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 42ef9015e0adec4b5cf8142846a596a7adb8cadc Author: John Stultz Date: Tue Aug 23 16:08:22 2016 -0700 timekeeping: Cap array access in timekeeping_debug commit a4f8f6667f099036c88f231dcad4cf233652c824 upstream. It was reported that hibernation could fail on the 2nd attempt, where the system hangs at hibernate() -> syscore_resume() -> i8237A_resume() -> claim_dma_lock(), because the lock has already been taken. However there is actually no other process would like to grab this lock on that problematic platform. Further investigation showed that the problem is triggered by setting /sys/power/pm_trace to 1 before the 1st hibernation. Since once pm_trace is enabled, the rtc becomes unmeaningful after suspend, and meanwhile some BIOSes would like to adjust the 'invalid' RTC (e.g, smaller than 1970) to the release date of that motherboard during POST stage, thus after resumed, it may seem that the system had a significant long sleep time which is a completely meaningless value. Then in timekeeping_resume -> tk_debug_account_sleep_time, if the bit31 of the sleep time happened to be set to 1, fls() returns 32 and we add 1 to sleep_time_bin[32], which causes an out of bounds array access and therefor memory being overwritten. As depicted by System.map: 0xffffffff81c9d080 b sleep_time_bin 0xffffffff81c9d100 B dma_spin_lock the dma_spin_lock.val is set to 1, which caused this problem. This patch adds a sanity check in tk_debug_account_sleep_time() to ensure we don't index past the sleep_time_bin array. [jstultz: Problem diagnosed and original patch by Chen Yu, I've solved the issue slightly differently, but borrowed his excelent explanation of the issue here.] Fixes: 5c83545f24ab "power: Add option to log time spent in suspend" Reported-by: Janek Kozicki Reported-by: Chen Yu Signed-off-by: John Stultz Cc: linux-pm@vger.kernel.org Cc: Peter Zijlstra Cc: Xunlei Pang Cc: "Rafael J. Wysocki" Cc: Zhang Rui Link: http://lkml.kernel.org/r/1471993702-29148-3-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit f5edb04b45076f498a96e5a6f5b1c37e943b501e Author: Dave Chinner Date: Fri Aug 26 16:01:30 2016 +1000 xfs: fix superblock inprogress check commit f3d7ebdeb2c297bd26272384e955033493ca291c upstream. From inspection, the superblock sb_inprogress check is done in the verifier and triggered only for the primary superblock via a "bp->b_bn == XFS_SB_DADDR" check. Unfortunately, the primary superblock is an uncached buffer, and hence it is configured by xfs_buf_read_uncached() with: bp->b_bn = XFS_BUF_DADDR_NULL; /* always null for uncached buffers */ And so this check never triggers. Fix it. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 4757f7ed8e9473d03074e3a315158492856a9f56 Author: Christoph Huber Date: Mon Aug 15 18:59:25 2016 +0200 ASoC: atmel_ssc_dai: Don't unconditionally reset SSC on stream startup commit 3e103a65514c2947e53f3171b21255fbde8b60c6 upstream. commit cbaadf0f90d6 ("ASoC: atmel_ssc_dai: refactor the startup and shutdown") refactored code such that the SSC is reset on every startup; this breaks duplex audio (e.g. first start audio playback, then start record, causing the playback to stop/hang) Fixes: cbaadf0f90d6 (ASoC: atmel_ssc_dai: refactor the startup and shutdown) Signed-off-by: Christoph Huber Signed-off-by: Peter Meerwald-Stadler Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 103898dd7701bf65ba35c5337ae82f82834bb0c5 Author: Rob Clark Date: Mon Aug 22 15:15:23 2016 -0400 drm/msm: fix use of copy_from_user() while holding spinlock commit 89f82cbb0d5c0ab768c8d02914188aa2211cd2e3 upstream. Use instead __copy_from_user_inatomic() and fallback to slow-path where we drop and re-aquire the lock in case of fault. Reported-by: Vaishali Thakkar Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit b7e99f782e6bd2606adbbce0c90804fb8aa4f5c8 Author: Daniel Vetter Date: Sat Aug 20 12:22:11 2016 +0200 drm: Reject page_flip for !DRIVER_MODESET commit 6f00975c619064a18c23fd3aced325ae165a73b9 upstream. Somehow this one slipped through, which means drivers without modeset support can be oopsed (since those also don't call drm_mode_config_init, which means the crtc lookup will chase an uninitalized idr). Reported-by: Alexander Potapenko Cc: Alexander Potapenko Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 314c7e8a09e8f23715e0fcd08e8659a67447c0d4 Author: Christian König Date: Wed Aug 17 09:46:42 2016 +0200 drm/radeon: fix radeon_move_blit on 32bit systems commit 13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 upstream. This bug seems to be present for a very long time. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2d29d6cec3bc5473efdad3b143404d9e32817c86 Author: Martin Schwidefsky Date: Mon Apr 25 17:54:28 2016 +0200 s390/sclp_ctl: fix potential information leak with /dev/sclp commit 532c34b5fbf1687df63b3fcd5b2846312ac943c6 upstream. The sclp_ctl_ioctl_sccb function uses two copy_from_user calls to retrieve the sclp request from user space. The first copy_from_user fetches the length of the request which is stored in the first two bytes of the request. The second copy_from_user gets the complete sclp request, but this copies the length field a second time. A malicious user may have changed the length in the meantime. Reported-by: Pengfei Wang Reviewed-by: Michael Holzheu Signed-off-by: Martin Schwidefsky Signed-off-by: Juerg Haefliger Signed-off-by: Greg Kroah-Hartman commit ffd5ce2ad5fd140ddd492ab2064e29e86aaa64ea Author: Kangjie Lu Date: Thu Jun 2 04:11:20 2016 -0400 rds: fix an infoleak in rds_inc_info_copy commit 4116def2337991b39919f3b448326e21c40e0dbb upstream. The last field "flags" of object "minfo" is not initialized. Copying this object out may leak kernel stack data. Assign 0 to it to avoid leak. Signed-off-by: Kangjie Lu Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Juerg Haefliger Signed-off-by: Greg Kroah-Hartman commit 0e324f6d66549b6a98122f2bd8da5ae56b018956 Author: Michael Neuling Date: Tue Jun 28 13:01:04 2016 +1000 powerpc/tm: Avoid SLB faults in treclaim/trecheckpoint when RI=0 commit 190ce8693c23eae09ba5f303a83bf2fbeb6478b1 upstream. 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 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 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: 090b9284d725 ("powerpc/tm: Clear MSR RI in non-recoverable TM code") Signed-off-by: Michael Neuling Reviewed-by: Cyril Bur Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 81e9a969c441d43b1a82b7d27848c0c7e1a5d90d Author: Gabriel Krisman Bertazi Date: Thu Sep 8 18:10:23 2016 -0300 nvme: Call pci_disable_device on the error path. Commit 5706aca74fe4 ("NVMe: Don't unmap controller registers on reset"), which backported b00a726a9fd8 to the 4.4.y kernel introduced a regression in which it didn't call pci_disable_device in the error path of nvme_pci_enable. Reported-by: Jiri Slaby Embarassed-developer: Gabriel Krisman Bertazi Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Greg Kroah-Hartman commit db8c7fff99ef64e0f2702b5477104b6c3a6c6fee Author: Balbir Singh Date: Wed Aug 10 15:43:06 2016 -0400 cgroup: reduce read locked section of cgroup_threadgroup_rwsem during fork commit 568ac888215c7fb2fabe8ea739b00ec3c1f5d440 upstream. cgroup_threadgroup_rwsem is acquired in read mode during process exit and fork. It is also grabbed in write mode during __cgroups_proc_write(). I've recently run into a scenario with lots of memory pressure and OOM and I am beginning to see systemd __switch_to+0x1f8/0x350 __schedule+0x30c/0x990 schedule+0x48/0xc0 percpu_down_write+0x114/0x170 __cgroup_procs_write.isra.12+0xb8/0x3c0 cgroup_file_write+0x74/0x1a0 kernfs_fop_write+0x188/0x200 __vfs_write+0x6c/0xe0 vfs_write+0xc0/0x230 SyS_write+0x6c/0x110 system_call+0x38/0xb4 This thread is waiting on the reader of cgroup_threadgroup_rwsem to exit. The reader itself is under memory pressure and has gone into reclaim after fork. There are times the reader also ends up waiting on oom_lock as well. __switch_to+0x1f8/0x350 __schedule+0x30c/0x990 schedule+0x48/0xc0 jbd2_log_wait_commit+0xd4/0x180 ext4_evict_inode+0x88/0x5c0 evict+0xf8/0x2a0 dispose_list+0x50/0x80 prune_icache_sb+0x6c/0x90 super_cache_scan+0x190/0x210 shrink_slab.part.15+0x22c/0x4c0 shrink_zone+0x288/0x3c0 do_try_to_free_pages+0x1dc/0x590 try_to_free_pages+0xdc/0x260 __alloc_pages_nodemask+0x72c/0xc90 alloc_pages_current+0xb4/0x1a0 page_table_alloc+0xc0/0x170 __pte_alloc+0x58/0x1f0 copy_page_range+0x4ec/0x950 copy_process.isra.5+0x15a0/0x1870 _do_fork+0xa8/0x4b0 ppc_clone+0x8/0xc In the meanwhile, all processes exiting/forking are blocked almost stalling the system. This patch moves the threadgroup_change_begin from before cgroup_fork() to just before cgroup_canfork(). There is no nee to worry about threadgroup changes till the task is actually added to the threadgroup. This avoids having to call reclaim with cgroup_threadgroup_rwsem held. tj: Subject and description edits. Signed-off-by: Balbir Singh Acked-by: Zefan Li Cc: Oleg Nesterov Cc: Andrew Morton Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 02989f49787e23855d989647d2e37826f841d844 Author: Ming Lei Date: Tue Aug 23 21:49:45 2016 +0800 block: make sure a big bio is split into at most 256 bvecs commit 4d70dca4eadf2f95abe389116ac02b8439c2d16c upstream. After arbitrary bio size was introduced, the incoming bio may be very big. We have to split the bio into small bios so that each holds at most BIO_MAX_PAGES bvecs for safety reason, such as bio_clone(). This patch fixes the following kernel crash: > [ 172.660142] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 > [ 172.660229] IP: [] bio_trim+0xf/0x2a > [ 172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0 > [ 172.660399] Oops: 0000 [#1] SMP > [...] > [ 172.664780] Call Trace: > [ 172.664813] [] ? raid1_make_request+0x2e8/0xad7 [raid1] > [ 172.664846] [] ? blk_queue_split+0x377/0x3d4 > [ 172.664880] [] ? md_make_request+0xf6/0x1e9 [md_mod] > [ 172.664912] [] ? generic_make_request+0xb5/0x155 > [ 172.664947] [] ? prio_io+0x85/0x95 [bcache] > [ 172.664981] [] ? register_cache_set+0x355/0x8d0 [bcache] > [ 172.665016] [] ? register_bcache+0x1006/0x1174 [bcache] The issue can be reproduced by the following steps: - create one raid1 over two virtio-blk - build bcache device over the above raid1 and another cache device and bucket size is set as 2Mbytes - set cache mode as writeback - run random write over ext4 on the bcache device Fixes: 54efd50(block: make generic_make_request handle arbitrarily sized bios) Reported-by: Sebastian Roesner Reported-by: Eric Wheeler Cc: Shaohua Li Acked-by: Kent Overstreet Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d3a6bd7b77ce9c9c19b37226ab0640a8918c4663 Author: Bart Van Assche Date: Tue Aug 16 16:48:36 2016 -0700 block: Fix race triggered by blk_set_queue_dying() commit 1b856086813be9371929b6cc62045f9fd470f5a0 upstream. blk_set_queue_dying() can be called while another thread is submitting I/O or changing queue flags, e.g. through dm_stop_queue(). Hence protect the QUEUE_FLAG_DYING flag change with locking. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1d12bad745acfc02d452a13f32b4087865964c9a Author: Daeho Jeong Date: Sun Jul 3 17:51:39 2016 -0400 ext4: avoid modifying checksum fields directly during checksum verification commit b47820edd1634dc1208f9212b7ecfb4230610a23 upstream. We temporally change checksum fields in buffers of some types of metadata into '0' for verifying the checksum values. By doing this without locking the buffer, some metadata's checksums, which are being committed or written back to the storage, could be damaged. In our test, several metadata blocks were found with damaged metadata checksum value during recovery process. When we only verify the checksum value, we have to avoid modifying checksum fields directly. Signed-off-by: Daeho Jeong Signed-off-by: Youngjin Gil Signed-off-by: Theodore Ts'o Reviewed-by: Darrick J. Wong Cc: Török Edwin Signed-off-by: Greg Kroah-Hartman commit 77ae14d00650e7f7b2144019b855acbc6e27003f Author: Jan Kara Date: Thu Aug 11 12:38:55 2016 -0400 ext4: avoid deadlock when expanding inode size commit 2e81a4eeedcaa66e35f58b81e0755b87057ce392 upstream. When we need to move xattrs into external xattr block, we call ext4_xattr_block_set() from ext4_expand_extra_isize_ea(). That may end up calling ext4_mark_inode_dirty() again which will recurse back into the inode expansion code leading to deadlocks. Protect from recursion using EXT4_STATE_NO_EXPAND inode flag and move its management into ext4_expand_extra_isize_ea() since its manipulation is safe there (due to xattr_sem) from possible races with ext4_xattr_set_handle() which plays with it as well. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit a79f1f7fcbe478e22cb4ff5f524847ec584177fe Author: Jan Kara Date: Thu Aug 11 12:00:01 2016 -0400 ext4: properly align shifted xattrs when expanding inodes commit 443a8c41cd49de66a3fda45b32b9860ea0292b84 upstream. We did not count with the padding of xattr value when computing desired shift of xattrs in the inode when expanding i_extra_isize. As a result we could create unaligned start of inline xattrs. Account for alignment properly. Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit e6abdbf8ac4adc14b6e91fdeb81492c112e9cc1e Author: Jan Kara Date: Thu Aug 11 11:58:32 2016 -0400 ext4: fix xattr shifting when expanding inodes part 2 commit 418c12d08dc64a45107c467ec1ba29b5e69b0715 upstream. When multiple xattrs need to be moved out of inode, we did not properly recompute total size of xattr headers in the inode and the new header position. Thus when moving the second and further xattr we asked ext4_xattr_shift_entries() to move too much and from the wrong place, resulting in possible xattr value corruption or general memory corruption. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit f2c06c7321aa080b18f36090cc1c3b2fa03a5cc8 Author: Jan Kara Date: Thu Aug 11 11:50:30 2016 -0400 ext4: fix xattr shifting when expanding inodes commit d0141191a20289f8955c1e03dad08e42e6f71ca9 upstream. The code in ext4_expand_extra_isize_ea() treated new_extra_isize argument sometimes as the desired target i_extra_isize and sometimes as the amount by which we need to grow current i_extra_isize. These happen to coincide when i_extra_isize is 0 which used to be the common case and so nobody noticed this until recently when we added i_projid to the inode and so i_extra_isize now needs to grow from 28 to 32 bytes. The result of these bugs was that we sometimes unnecessarily decided to move xattrs out of inode even if there was enough space and we often ended up corrupting in-inode xattrs because arguments to ext4_xattr_shift_entries() were just wrong. This could demonstrate itself as BUG_ON in ext4_xattr_shift_entries() triggering. Fix the problem by introducing new isize_diff variable and use it where appropriate. Reported-by: Dave Chinner Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit dfa0a22733804636fb8ac7963bd24e7ce6dbaa45 Author: Theodore Ts'o Date: Mon Aug 1 00:51:02 2016 -0400 ext4: validate that metadata blocks do not overlap superblock commit 829fa70dddadf9dd041d62b82cd7cea63943899d upstream. A number of fuzzing failures seem to be caused by allocation bitmaps or other metadata blocks being pointed at the superblock. This can cause kernel BUG or WARNings once the superblock is overwritten, so validate the group descriptor blocks to make sure this doesn't happen. Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6af4737361aa55ac90ecb9b41915cd8fd5cade77 Author: Tyler Hicks Date: Thu Jun 2 23:43:22 2016 -0500 net: Use ns_capable_noaudit() when determining net sysctl permissions commit d6e0d306449bcb5fa3c80e7a3edf11d45abf9ae9 upstream. The capability check should not be audited since it is only being used to determine the inode permissions. A failed check does not indicate a violation of security policy but, when an LSM is enabled, a denial audit message was being generated. The denial audit message caused confusion for some application authors because root-running Go applications always triggered the denial. To prevent this confusion, the capability check in net_ctl_permissions() is switched to the noaudit variant. BugLink: https://launchpad.net/bugs/1465724 Signed-off-by: Tyler Hicks Acked-by: Serge E. Hallyn Signed-off-by: James Morris Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ad7c1399b7d0c6788b8f5fdb5c274110f3ce6017 Author: Tyler Hicks Date: Thu Jun 2 23:43:21 2016 -0500 kernel: Add noaudit variant of ns_capable() commit 98f368e9e2630a3ce3e80fb10fb2e02038cf9578 upstream. When checking the current cred for a capability in a specific user namespace, it isn't always desirable to have the LSMs audit the check. This patch adds a noaudit variant of ns_capable() for when those situations arise. The common logic between ns_capable() and the new ns_capable_noaudit() is moved into a single, shared function to keep duplicated code to a minimum and ease maintainability. Signed-off-by: Tyler Hicks Acked-by: Serge E. Hallyn Signed-off-by: James Morris Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5afbd223e60a130f66bddf7598165ebe2b51f8db Author: David Howells Date: Tue Aug 30 00:35:07 2016 -0400 KEYS: Fix ASN.1 indefinite length object parsing [ Upstream commit 23c8a812dc3c621009e4f0e5342aa4e2ede1ceaa ] This fixes CVE-2016-0758. In the ASN.1 decoder, when the length field of an ASN.1 value is extracted, it isn't validated against the remaining amount of data before being added to the cursor. With a sufficiently large size indicated, the check: datalen - dp < 2 may then fail due to integer overflow. Fix this by checking the length indicated against the amount of remaining data in both places a definite length is determined. Whilst we're at it, make the following changes: (1) Check the maximum size of extended length does not exceed the capacity of the variable it's being stored in (len) rather than the type that variable is assumed to be (size_t). (2) Compare the EOC tag to the symbolic constant ASN1_EOC rather than the integer 0. (3) To reduce confusion, move the initialisation of len outside of: for (len = 0; n > 0; n--) { since it doesn't have anything to do with the loop counter n. Signed-off-by: David Howells Reviewed-by: Mimi Zohar Acked-by: David Woodhouse Acked-by: Peter Jones Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 45a063156fc5822f3f72bee0bc986de63e7ed73b Author: Jake Oshins Date: Tue Aug 30 00:35:06 2016 -0400 drivers:hv: Lock access to hyperv_mmio resource tree [ Upstream commit e16dad6bfe1437aaee565f875a6713ca7ce81bdf ] In existing code, this tree of resources is created in single-threaded code and never modified after it is created, and thus needs no locking. This patch introduces a semaphore for tree access, as other patches in this series introduce run-time modifications of this resource tree which can happen on multiple threads. Signed-off-by: Jake Oshins Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d4009e4b6e309e222c5245056f4d6e1a4da88026 Author: Manoj N. Kumar Date: Tue Aug 30 00:35:05 2016 -0400 cxlflash: Move to exponential back-off when cmd_room is not available [ Upstream commit ea76543127da32dec28af0a13ea1b06625fc085e ] While profiling the cxlflash_queuecommand() path under a heavy load it was found that number of retries to find cmd_room was fairly high. There are two problems with the current back-off: a) It starts with a udelay of 0 b) It backs-off linearly Tried several approaches (a higher multiple 10*n, 100*n, as well as n^2, 2^n) and found that the exponential back-off(2^n) approach had the least overall cost. Cost as being defined as overall time spent waiting. The fix is to change the linear back-off to an exponential back-off. This solution also takes care of the problem with the initial delay (starts with 1 usec). Signed-off-by: Manoj N. Kumar Acked-by: Matthew R. Ochs Reviewed-by: Johannes Thumshirn Signed-off-by: Uma Krishnan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 61610c63fa1025468c82be975e7d574e847d00de Author: Florian Westphal Date: Tue Aug 30 00:35:04 2016 -0400 netfilter: x_tables: check for size overflow [ Upstream commit d157bd761585605b7882935ffb86286919f62ea1 ] Ben Hawkes says: integer overflow in xt_alloc_table_info, which on 32-bit systems can lead to small structure allocation and a copy_from_user based heap corruption. Reported-by: Ben Hawkes Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b54698f045e805b577e14285d047ecfae1e706be Author: Alex Deucher Date: Tue Aug 30 00:35:03 2016 -0400 drm/amdgpu/cz: enable/disable vce dpm even if vce pg is disabled [ Upstream commit b3dae7828399ef316e3fabf7e82c6415cb03a02e ] I missed this when cleaning up the vce pg handling. Reviewed-by: Christian König Reviewed-by: Rex Zhu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4666aa74a3797d23a2344033df41b2aa0cfe5023 Author: Seth Forshee Date: Tue Aug 30 00:35:01 2016 -0400 cred: Reject inodes with invalid ids in set_create_file_as() [ Upstream commit 5f65e5ca286126a60f62c8421b77c2018a482b8a ] Using INVALID_[UG]ID for the LSM file creation context doesn't make sense, so return an error if the inode passed to set_create_file_as() has an invalid id. Signed-off-by: Seth Forshee Acked-by: Serge Hallyn Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6a90aa44065afb34ad4f37676b734c0e3eeafe6a Author: Seth Forshee Date: Tue Aug 30 00:35:00 2016 -0400 fs: Check for invalid i_uid in may_follow_link() [ Upstream commit 2d7f9e2ad35e4e7a3086231f19bfab33c6a8a64a ] Filesystem uids which don't map into a user namespace may result in inode->i_uid being INVALID_UID. A symlink and its parent could have different owners in the filesystem can both get mapped to INVALID_UID, which may result in following a symlink when this would not have otherwise been permitted when protected symlinks are enabled. Signed-off-by: Seth Forshee Acked-by: Serge Hallyn Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 917f84b8df10b6959f0fb8e5019cdffb670c0362 Author: Carol L Soto Date: Tue Aug 30 00:34:59 2016 -0400 IB/IPoIB: Do not set skb truesize since using one linearskb [ Upstream commit bb6a777369449d15a4a890306d2f925cae720e1c ] We are seeing this warning: at net/core/skbuff.c:4174 and before commit a44878d10063 ("IB/ipoib: Use one linear skb in RX flow") skb truesize was not being set when ipoib was using just one skb. Removing this line avoids the warning when running tcp tests like iperf. Fixes: a44878d10063 ("IB/ipoib: Use one linear skb in RX flow") Signed-off-by: Carol L Soto Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dfe2042d96065f044a794f684e9f7976a4ca6e24 Author: Eric Dumazet Date: Tue Aug 30 00:34:58 2016 -0400 udp: properly support MSG_PEEK with truncated buffers [ Upstream commit 197c949e7798fbf28cfadc69d9ca0c2abbf93191 ] Backport of this upstream commit into stable kernels : 89c22d8c3b27 ("net: Fix skb csum races when peeking") exposed a bug in udp stack vs MSG_PEEK support, when user provides a buffer smaller than skb payload. In this case, skb_copy_and_csum_datagram_iovec(skb, sizeof(struct udphdr), msg->msg_iov); returns -EFAULT. This bug does not happen in upstream kernels since Al Viro did a great job to replace this into : skb_copy_and_csum_datagram_msg(skb, sizeof(struct udphdr), msg); This variant is safe vs short buffers. For the time being, instead reverting Herbert Xu patch and add back skb->ip_summed invalid changes, simply store the result of udp_lib_checksum_complete() so that we avoid computing the checksum a second time, and avoid the problematic skb_copy_and_csum_datagram_iovec() call. This patch can be applied on recent kernels as it avoids a double checksumming, then backported to stable kernels as a bug fix. Signed-off-by: Eric Dumazet Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4259821921698f26e4a2c67c72f00db4e48833b0 Author: Haren Myneni Date: Tue Aug 30 00:34:57 2016 -0400 crypto: nx-842 - Mask XERS0 bit in return value [ Upstream commit 6333ed8f26cf77311088d2e2b7cf16d8480bcbb2 ] NX842 coprocessor sets 3rd bit in CR register with XER[S0] which is nothing to do with NX request. Since this bit can be set with other valuable return status, mast this bit. One of other bits (INITIATED, BUSY or REJECTED) will be returned for any given NX request. Signed-off-by: Haren Myneni Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f88503578d823dfe503c9c6b80baf3864915f6a5 Author: Matthew R. Ochs Date: Tue Aug 30 00:34:55 2016 -0400 cxlflash: Fix to avoid virtual LUN failover failure [ Upstream commit d5e26bb1d812ba74f29b6bcbc88c3dbfb3eed824 ] Applications which use virtual LUN's that are backed by a physical LUN over both adapter ports may experience an I/O failure in the event of a link loss (e.g. cable pull). Virtual LUNs may be accessed through one or both ports of the adapter. This access is encoded in the translation entries that comprise the virtual LUN and used by the AFU for load-balancing I/O and handling failover scenarios. In a link loss scenario, even though the AFU is able to maintain connectivity to the LUN, it is up to the application to retry the failed I/O. When applications are unaware of the virtual LUN's underlying topology, they are unable to make a sound decision of when to retry an I/O and therefore are forced to make their reaction to a failed I/O absolute. The result is either a failure to retry I/O or increased latency for scenarios where a retry is pointless. To remedy this scenario, provide feedback back to the application on virtual LUN creation as to which ports the LUN may be accessed. LUN's spanning both ports are candidates for a retry in a presence of an I/O failure. Signed-off-by: Matthew R. Ochs Acked-by: Manoj Kumar Reviewed-by: Uma Krishnan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 610f1a8d3700e81d534adb3db07267fa8b20411c Author: Manoj Kumar Date: Tue Aug 30 00:34:54 2016 -0400 cxlflash: Fix to escalate LINK_RESET also on port 1 [ Upstream commit a9be294ecb3b9dc82b15625631b153f871181d16 ] The original fix to escalate a 'login timed out' error to a LINK_RESET was only made for one of the two ports on the card. This fix resolves the same issue for the second port (port 1). Signed-off-by: Manoj N. Kumar Acked-by: Matthew R. Ochs Reviewed-by: Uma Krishnan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b2e345ed50bc140e2334e6b8fa9108ee66683cb Author: Richard Alpe Date: Thu Jul 14 15:02:07 2016 +0100 tipc: fix nl compat regression for link statistics [ Upstream commit 55e77a3e8297581c919b45adcc4d0815b69afa84 ] Fix incorrect use of nla_strlcpy() where the first NLA_HDRLEN bytes of the link name where left out. Making the output of tipc-config -ls look something like: Link statistics: dcast-link 1:data0-1.1.2:data0 1:data0-1.1.3:data0 Also, for the record, the patch that introduce this regression claims "Sending the whole object out can cause a leak". Which isn't very likely as this is a compat layer, where the data we are parsing is generated by us and we know the string to be NULL terminated. But you can of course never be to secure. Fixes: 5d2be1422e02 (tipc: fix an infoleak in tipc_nl_compat_link_dump) Signed-off-by: Richard Alpe Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5fb71611925f734f7fe03a45527e14b296fd5167 Author: Kangjie Lu Date: Thu Jul 14 15:02:06 2016 +0100 tipc: fix an infoleak in tipc_nl_compat_link_dump [ Upstream commit 5d2be1422e02ccd697ccfcd45c85b4a26e6178e2 ] link_info.str is a char array of size 60. Memory after the NULL byte is not initialized. Sending the whole object out can cause a leak. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cfd6e7fe434a378127e4964fc0b7ccf32ae2baed Author: Florian Westphal Date: Wed Jul 13 11:44:54 2016 +0100 netfilter: x_tables: check for size overflow [ Upstream commit d157bd761585605b7882935ffb86286919f62ea1 ] Ben Hawkes says: integer overflow in xt_alloc_table_info, which on 32-bit systems can lead to small structure allocation and a copy_from_user based heap corruption. Reported-by: Ben Hawkes Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c6d7c62c0092fd5d0fca299eeb9d4eb0a46a8a9d Author: Tedd Ho-Jeong An Date: Wed Jul 13 16:13:23 2016 +0800 Bluetooth: Add support for Intel Bluetooth device 8265 [8087:0a2b] [ Upstream commit a0af53b511423cca93900066512379e21586d7dd ] This patch adds support for Intel Bluetooth device 8265 also known as Windstorm Peak (WsP). T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0a2b Rev= 0.10 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Tedd Ho-Jeong An Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e153f52df99a88614384dcc6568014ece08802ff Author: Ville Syrjälä Date: Thu Jul 7 16:24:29 2016 +0800 drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV [ Upstream commit 22f35042593c2b369861f0b9740efb8065a42db0 ] Apparently some CHV boards failed to hook up the port presence straps for HDMI ports as well (earlier we assumed this problem only affected eDP ports). So let's check the VBT in addition to the strap, and if either one claims that the port is present go ahead and register the relevant connector. While at it, change port D to register DP before HDMI as we do for ports B and C since commit 457c52d87e5d ("drm/i915: Only ignore eDP ports that are connected") Also print a debug message when we register a HDMI connector to aid in diagnosing missing/incorrect ports. We already had such a print for DP/eDP. v2: Improve the comment in the code a bit, note the port D change in the commit message Cc: Radoslav Duda Tested-by: Radoslav Duda Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96321 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1464945463-14364-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af115b1a3adff2d01ff2e55a184adf3775bf2b1c Author: Chris Wilson Date: Thu Jul 7 16:24:28 2016 +0800 drm/i915: Only ignore eDP ports that are connected [ Upstream commit 457c52d87e5dac9a4cf1a6a287e60ea7645067d4 ] If the VBT says that a certain port should be eDP (and hence fused off from HDMI), but in reality it isn't, we need to try and acquire the HDMI connection instead. So only trust the VBT edp setting if we can connect to an eDP device on that port. Fixes: d2182a6608 (drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHV) References: https://bugs.freedesktop.org/show_bug.cgi?id=96288 Signed-off-by: Chris Wilson Tested-by: Phidias Chiang Cc: Ville Syrjälä Cc: Jani Nikula Cc: Daniel Vetter Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1464766070-31623-1-git-send-email-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 822480f8f45473c41307e2abe81de681ca2ca349 Author: Pavel Rojtberg Date: Fri Jul 1 17:32:09 2016 -0400 Input: xpad - move pending clear to the correct location [ Upstream commit 4efc6939a83c54fb3417541be48991afd0290ba3 ] otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27 Signed-off-by: Pavel Rojtberg Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit be9755f99926603ded05d50b8adef1e73234b3fd Author: Sunil Goutham Date: Mon Jun 27 15:30:02 2016 +0530 net: thunderx: Fix link status reporting [ Upstream commit 3f4c68cfde30caa1f6d8368fd19590671411ade2 ] Check for SMU RX local/remote faults along with SPU LINK status. Otherwise at times link is UP at our end but DOWN at link partner's side. Also due to an issue in BGX it's rarely seen that initialization doesn't happen properly and SMU RX reports faults with everything fine at SPU. This patch tries to reinitialize LMAC to fix it. Also fixed LMAC disable sequence to properly bring down link. Signed-off-by: Sunil Goutham Signed-off-by: Tao Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5852a85ed87d963ea5bcfead4f61fc9a276882c Author: Vitaly Kuznetsov Date: Fri Apr 15 15:50:32 2016 +0200 x86/hyperv: Avoid reporting bogus NMI status for Gen2 instances [ Upstream commit 1e2ae9ec072f3b7887f456426bc2cf23b80f661a ] Generation2 instances don't support reporting the NMI status on port 0x61, read from there returns 'ff' and we end up reporting nonsensical PCI error (as there is no PCI bus in these instances) on all NMIs: NMI: PCI system error (SERR) for reason ff on CPU 0. Dazed and confused, but trying to continue Fix the issue by overriding x86_platform.get_nmi_reason. Use 'booted on EFI' flag to detect Gen2 instances. Signed-off-by: Vitaly Kuznetsov Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Cathy Avery Cc: Haiyang Zhang Cc: Jiri Olsa Cc: K. Y. Srinivasan Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: devel@linuxdriverproject.org Link: http://lkml.kernel.org/r/1460728232-31433-1-git-send-email-vkuznets@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3d390b83a990e688edc5682bee55c52ee46c6880 Author: Leonidas Da Silva Barbosa Date: Mon Jun 27 09:12:02 2016 -0600 crypto: vmx - IV size failing on skcipher API [ Upstream commit 0d3d054b43719ef33232677ba27ba6097afdafbc ] IV size was zero on CBC and CTR modes, causing a bug triggered by skcipher. Fixing this adding a correct size. Signed-off-by: Leonidas Da Silva Barbosa Signed-off-by: Paulo Smorigo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1062520ea49aa89b42119e868d44a67699e3a552 Author: Matthias Schwarzott Date: Mon Jun 20 06:22:12 2016 -0600 tda10071: Fix dependency to REGMAP_I2C [ Upstream commit b046d3ad38d90276379c862f15ddd99fa8739906 ] Without I get this error for by dvb-card: tda10071: Unknown symbol devm_regmap_init_i2c (err 0) cx23885_dvb_register() dvb_register failed err = -22 cx23885_dev_setup() Failed to register dvb adapters on VID_B Signed-off-by: Matthias Schwarzott Reviewed-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4be6661ccec8a1dfe8c5242126b8efe316d894c6 Author: Anton Blanchard Date: Fri Jun 10 16:47:02 2016 +1000 crypto: vmx - Fix ABI detection [ Upstream commit 975f57fdff1d0eb9816806cabd27162a8a1a4038 ] When calling ppc-xlate.pl, we pass it either linux-ppc64 or linux-ppc64le. The script however was expecting linux64le, a result of its OpenSSL origins. This means we aren't obeying the ppc64le ABIv2 rules. Fix this by checking for linux-ppc64le. Fixes: 5ca55738201c ("crypto: vmx - comply with ABIs that specify vrsave as reserved.") Cc: stable@vger.kernel.org Signed-off-by: Anton Blanchard Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e29e85ac08345e9276bff3ca39debc88a46d79a4 Author: Paulo Flabiano Smorigo Date: Thu May 5 11:09:27 2016 -0300 crypto: vmx - comply with ABIs that specify vrsave as reserved. [ Upstream commit 5ca55738201c7ae1b556ad87bbb22c139ecc01dd ] It gives significant improvements ( ~+15%) on some modes. These code has been adopted from OpenSSL project in collaboration with the original author (Andy Polyakov ). Signed-off-by: Paulo Flabiano Smorigo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5349cdd3b49cea2d57dc05bbf3f313979751fed3 Author: Benjamin Tissoires Date: Tue Jun 14 10:55:22 2016 -0700 HID: core: prevent out-of-bound readings [ Upstream commit 50220dead1650609206efe91f0cc116132d59b3f ] Plugging a Logitech DJ receiver with KASAN activated raises a bunch of out-of-bound readings. The fields are allocated up to MAX_USAGE, meaning that potentially, we do not have enough fields to fit the incoming values. Add checks and silence KASAN. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9f4a5a1c0cac1e655234984b3f877ae0b7585f00 Author: James Smart Date: Fri Jun 3 07:14:08 2016 -0600 lpfc: Fix DMA faults observed upon plugging loopback connector [ Upstream commit ae09c765109293b600ba9169aa3d632e1ac1a843 ] Driver didn't program the REG_VFI mailbox correctly, giving the adapter bad addresses. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7cd8506b35cf5b357c25a6f052de61ff88a724e Author: Christoph Hellwig Date: Fri Jun 3 07:42:17 2016 -0600 block: fix blk_rq_get_max_sectors for driver private requests [ Upstream commit f21018427cb007a0894c36ad702990ab639cbbb4 ] Driver private request types should not get the artifical cap for the FS requests. This is important to use the full device capabilities for internal command or NVMe pass through commands. Signed-off-by: Christoph Hellwig Reported-by: Jeff Lien Tested-by: Jeff Lien Reviewed-by: Keith Busch Updated by me to use an explicit check for the one command type that does support extended checking, instead of relying on the ordering of the enum command values - as suggested by Keith. Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 80cce3cde88e274943085c21241f445935cdfaa3 Author: Ganapatrao Kulkarni Date: Wed May 25 15:29:20 2016 +0200 irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144 [ Upstream commit fbf8f40e1658cb2f17452dbd3c708e329c5d27e0 ] The erratum fixes the hang of ITS SYNC command by avoiding inter node io and collections/cpu mapping on thunderx dual-socket platform. This fix is only applicable for Cavium's ThunderX dual-socket platform. Reviewed-by: Robert Richter Signed-off-by: Ganapatrao Kulkarni Signed-off-by: Robert Richter Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a2350f3d827a4669cf41b976b8cd083e6269c0fa Author: Vitaly Kuznetsov Date: Fri Jun 3 20:38:35 2016 -0600 clocksource: Allow unregistering the watchdog [ Upstream commit bbf66d897adf2bb0c310db96c97e8db6369f39e1 ] Hyper-V vmbus module registers TSC page clocksource when loaded. This is the clocksource with the highest rating and thus it becomes the watchdog making unloading of the vmbus module impossible. Separate clocksource_select_watchdog() from clocksource_enqueue_watchdog() and use it on clocksource register/rating change/unregister. After all, lobotomized monkeys may need some love too. Signed-off-by: Vitaly Kuznetsov Cc: John Stultz Cc: Dexuan Cui Cc: K. Y. Srinivasan Link: http://lkml.kernel.org/r/1453483913-25672-1-git-send-email-vkuznets@redhat.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b5282220fdd4a1e39b59a28fd499d03f2cb0c056 Author: Zhao Lei Date: Fri May 27 14:59:00 2016 -0400 btrfs: Continue write in case of can_not_nocow [ Upstream commit 4da2e26a2a32b174878744bd0f07db180c875f26 ] btrfs failed in xfstests btrfs/080 with -o nodatacow. Can be reproduced by following script: DEV=/dev/vdg MNT=/mnt/tmp umount $DEV &>/dev/null mkfs.btrfs -f $DEV mount -o nodatacow $DEV $MNT dd if=/dev/zero of=$MNT/test bs=1 count=2048 & btrfs subvolume snapshot -r $MNT $MNT/test_snap & wait -- We can see dd failed on NO_SPACE. Reason: __btrfs_buffered_write should run cow write when no_cow impossible, and current code is designed with above logic. But check_can_nocow() have 2 type of return value(0 and <0) on can_not_no_cow, and current code only continue write on first case, the second case happened in doing subvolume. Fix: Continue write when check_can_nocow() return 0 and <0. Reviewed-by: Filipe Manana Signed-off-by: Zhao Lei Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4af03e19226cebe72d45c669ddc3b33666adf18e Author: Keith Busch Date: Thu May 26 10:25:51 2016 -0600 blk-mq: End unstarted requests on dying queue [ Upstream commit a59e0f5795fe52dad42a99c00287e3766153b312 ] Go directly to ending a request if it wasn't started. Previously, completing a request may invoke a driver callback for a request it didn't initialize. Signed-off-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Johannes Thumshirn Acked-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d774bfcec0980b1be5c02405c5ac2e6c4ede56b7 Author: Manoj N. Kumar Date: Mon May 23 14:30:42 2016 -0600 cxlflash: Fix to resolve dead-lock during EEH recovery [ Upstream commit 635f6b0893cff193a1774881ebb1e4a4b9a7fead ] When a cxlflash adapter goes into EEH recovery and multiple processes (each having established its own context) are active, the EEH recovery can hang if the processes attempt to recover in parallel. The symptom logged after a couple of minutes is: INFO: task eehd:48 blocked for more than 120 seconds. Not tainted 4.5.0-491-26f710d+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. eehd 0 48 2 Call Trace: __switch_to+0x2f0/0x410 __schedule+0x300/0x980 schedule+0x48/0xc0 rwsem_down_write_failed+0x294/0x410 down_write+0x88/0xb0 cxlflash_pci_error_detected+0x100/0x1c0 [cxlflash] cxl_vphb_error_detected+0x88/0x110 [cxl] cxl_pci_error_detected+0xb0/0x1d0 [cxl] eeh_report_error+0xbc/0x130 eeh_pe_dev_traverse+0x94/0x160 eeh_handle_normal_event+0x17c/0x450 eeh_handle_event+0x184/0x370 eeh_event_handler+0x1c8/0x1d0 kthread+0x110/0x130 ret_from_kernel_thread+0x5c/0xa4 INFO: task blockio:33215 blocked for more than 120 seconds. Not tainted 4.5.0-491-26f710d+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. blockio 0 33215 33213 Call Trace: 0x1 (unreliable) __switch_to+0x2f0/0x410 __schedule+0x300/0x980 schedule+0x48/0xc0 rwsem_down_read_failed+0x124/0x1d0 down_read+0x68/0x80 cxlflash_ioctl+0x70/0x6f0 [cxlflash] scsi_ioctl+0x3b0/0x4c0 sg_ioctl+0x960/0x1010 do_vfs_ioctl+0xd8/0x8c0 SyS_ioctl+0xd4/0xf0 system_call+0x38/0xb4 INFO: task eehd:48 blocked for more than 120 seconds. The hang is because of a 3 way dead-lock: Process A holds the recovery mutex, and waits for eehd to complete. Process B holds the semaphore and waits for the recovery mutex. eehd waits for semaphore. The fix is to have Process B above release the semaphore before attempting to acquire the recovery mutex. This will allow eehd to proceed to completion. Signed-off-by: Manoj N. Kumar Reviewed-by: Matthew R. Ochs Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4b3a13ece27435f509b40235af7bec052b4dddb Author: Dave Airlie Date: Tue Mar 22 09:38:18 2016 +1000 drm/radeon/mst: fix regression in lane/link handling. [ Upstream commit b36f7d26a7fdc0b07b1217368ee09bb8560269f8 ] The function this used changed in 092c96a8ab9d1bd60ada2ed385cc364ce084180e drm/radeon: fix dp link rate selection (v2) However for MST we should just always train to the max link/rate. Though we probably need to limit this for future hw, in theory radeon won't support it. This fixes my 30" monitor with MST enabled. Cc: stable@vger.kernel.org # v4.4 Signed-off-by: Dave Airlie Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 25dcddef047a2720d8cce5d8a46a9c69d7cbd142 Author: Al Viro Date: Wed Jun 8 19:20:33 2016 +0100 ecryptfs: fix handling of directory opening [ Upstream commit 6a480a7842545ec520a91730209ec0bae41694c1 ] First of all, trying to open them r/w is idiocy; it's guaranteed to fail. Moreover, assigning ->f_pos and assuming that everything will work is blatantly broken - try that with e.g. tmpfs as underlying layer and watch the fireworks. There may be a non-trivial amount of state associated with current IO position, well beyond the numeric offset. Using the single struct file associated with underlying inode is really not a good idea; we ought to open one for each ecryptfs directory struct file. Additionally, file_operations both for directories and non-directories are full of pointless methods; non-directories should *not* have ->iterate(), directories should not have ->flush(), ->fasync() and ->splice_read(). Signed-off-by: Al Viro Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c00414f20096c279d317b7763e5b90eb15d58e21 Author: Maruthi Srinivas Bayyavarapu Date: Wed May 11 08:16:36 2016 -0400 ALSA: hda: add AMD Polaris-10/11 AZ PCI IDs with proper driver caps [ Upstream commit 8eb22214b7cb0c0a28be6caf3b81201629d8ea7c ] This commit fixes garbled audio on Polaris-10/11 variants Signed-off-by: Maruthi Bayyavarapu Reviewed-by: Alex Deucher Acked-by: Christian König Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e0df9595ca96607755a04929a7e9df665de01181 Author: Chris Wilson Date: Mon May 9 12:01:27 2016 -0600 drm: Balance error path for GEM handle allocation [ Upstream commit 6984128d01cf935820a0563f3a00c6623ba58109 ] The current error path for failure when establishing a handle for a GEM object is unbalance, e.g. we call object_close() without calling first object_open(). Use the typical onion structure to only undo what has been set up prior to the error. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1db396648ca33eb92dd0ed5cc2ea2f58816eeb9a Author: John Stultz Date: Thu Apr 14 10:25:14 2016 -0600 ntp: Fix ADJ_SETOFFSET being used w/ ADJ_NANO [ Upstream commit dd4e17ab704269bce71402285f5e8b9ac24b1eff ] Recently, in commit 37cf4dc3370f I forgot to check if the timeval being passed was actually a timespec (as is signaled with ADJ_NANO). This resulted in that patch breaking ADJ_SETOFFSET users who set ADJ_NANO, by rejecting valid timespecs that were compared with valid timeval ranges. This patch addresses this by checking for the ADJ_NANO flag and using the timepsec check instead in that case. Reported-by: Harald Hoyer Reported-by: Kay Sievers Fixes: 37cf4dc3370f "time: Verify time values in adjtimex ADJ_SETOFFSET to avoid overflow" Signed-off-by: John Stultz Cc: Sasha Levin Cc: Richard Cochran Cc: Prarit Bhargava Cc: David Herrmann Link: http://lkml.kernel.org/r/1453417415-19110-2-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e79e7333c3a3d94a2b4f10f4977b45162ef160cf Author: John Stultz Date: Thu Dec 3 22:09:31 2015 -0500 time: Verify time values in adjtimex ADJ_SETOFFSET to avoid overflow [ Upstream commit 37cf4dc3370fbca0344e23bb96446eb2c3548ba7 ] For adjtimex()'s ADJ_SETOFFSET, make sure the tv_usec value is sane. We might multiply them later which can cause an overflow and undefined behavior. This patch introduces new helper functions to simplify the checking code and adds comments to clarify Orginally this patch was by Sasha Levin, but I've basically rewritten it, so he should get credit for finding the issue and I should get the blame for any mistakes made since. Also, credit to Richard Cochran for the phrasing used in the comment for what is considered valid here. Cc: Sasha Levin Cc: Richard Cochran Cc: Thomas Gleixner Reported-by: Sasha Levin Signed-off-by: John Stultz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit efdd094f63fd62357988695de6d5152cbd58d26c Author: Pavel Rojtberg Date: Wed Dec 9 11:57:01 2015 -0800 Input: xpad - correctly handle concurrent LED and FF requests [ Upstream commit 7fc595f4c02636eadaeeecfe7bbc45b57c173004 ] Track the status of the irq_out URB to prevent submission iof new requests while current one is active. Failure to do so results in the "URB submitted while active" warning/stack trace. Store pending brightness and FF effect in the driver structure and replace it with the latest requests until the device is ready to process next request. Alternate serving LED vs FF requests to make sure one does not starve another. See [1] for discussion. Inspired by patch of Sarah Bessmer [2]. [1]: http://www.spinics.net/lists/linux-input/msg40708.html [2]: http://www.spinics.net/lists/linux-input/msg31450.html Signed-off-by: Pavel Rojtberg Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4c79345330edabd74f5d2e12067a8c1e762abe53 Author: Sunil Goutham Date: Tue Feb 16 16:29:51 2016 +0530 net: thunderx: Fix receive packet stats [ Upstream commit ad2ecebd67d8a80fe5412d11df375a5ed2db7cd1 ] Counting rx packets for every CQE_RX in CQ irq handler is incorrect. Synchronization is missing when multiple queues are receiving packets simultaneously. Like transmit packet stats use HW stats here. Also removed unused 'cqe_type' parameter in nicvf_rcv_pkt_handler(). Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 61c188313c6c0808339c3dc034adfc255d84bf32 Author: Sunil Goutham Date: Tue Feb 16 16:29:49 2016 +0530 net: thunderx: Fix for multiqset not configured upon interface toggle [ Upstream commit 6a9bab79bb79bd9b2eda16f0aba1b4c43f677be9 ] When a interface is assigned morethan 8 queues and the logical interface is toggled i.e down & up, additional queues or qsets are not initialized as secondary qset count is being set to zero while tearing down. Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 12850f3616f89b750630ae757cd8eb15d15027f1 Author: Vikas Shivappa Date: Thu Mar 10 15:32:08 2016 -0800 perf/x86/cqm: Fix CQM memory leak and notifier leak [ Upstream commit ada2f634cd50d050269b67b4e2966582387e7c27 ] Fixes the hotcpu notifier leak and other global variable memory leaks during CQM (cache quality of service monitoring) initialization. Signed-off-by: Vikas Shivappa Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Tony Luck Acked-by: Thomas Gleixner Cc: Alexander Shishkin Cc: Andy Lutomirski Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Brian Gerst Cc: David Ahern Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jiri Olsa Cc: Linus Torvalds Cc: Matt Fleming Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Vince Weaver Cc: fenghua.yu@intel.com Cc: h.peter.anvin@intel.com Cc: ravi.v.shankar@intel.com Cc: vikas.shivappa@intel.com Link: http://lkml.kernel.org/r/1457652732-4499-3-git-send-email-vikas.shivappa@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0b152db0426acee35ae4798f682ce512fc7f6a35 Author: Vikas Shivappa Date: Thu Mar 10 15:32:07 2016 -0800 perf/x86/cqm: Fix CQM handling of grouping events into a cache_group [ Upstream commit a223c1c7ab4cc64537dc4b911f760d851683768a ] Currently CQM (cache quality of service monitoring) is grouping all events belonging to same PID to use one RMID. However its not counting all of these different events. Hence we end up with a count of zero for all events other than the group leader. The patch tries to address the issue by keeping a flag in the perf_event.hw which has other CQM related fields. The field is updated at event creation and during grouping. Signed-off-by: Vikas Shivappa [peterz: Changed hw_perf_event::is_group_event to an int] Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Tony Luck Acked-by: Thomas Gleixner Cc: Alexander Shishkin Cc: Andy Lutomirski Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Brian Gerst Cc: David Ahern Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jiri Olsa Cc: Linus Torvalds Cc: Matt Fleming Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Vince Weaver Cc: fenghua.yu@intel.com Cc: h.peter.anvin@intel.com Cc: ravi.v.shankar@intel.com Cc: vikas.shivappa@intel.com Link: http://lkml.kernel.org/r/1457652732-4499-2-git-send-email-vikas.shivappa@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 72f4972b8812e0a1749d3be19d8017de25a9d15d Author: Harald Freudenberger Date: Thu Mar 17 14:52:17 2016 +0100 s390/crypto: provide correct file mode at device register. [ Upstream commit 74b2375e6767935e6d9220bdbc6ed0db57f71a59 ] When the prng device driver calls misc_register() there is the possibility to also provide the recommented file permissions. This fix now gives useful values (0644) where previously just the default was used (resulting in 0600 for the device file). Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f3de8fbe2a2a3ec4c612e2e0ddeee68f9c5bd972 Author: Johannes Weiner Date: Tue Feb 2 16:57:29 2016 -0800 proc: revert /proc//maps [stack:TID] annotation [ Upstream commit 65376df582174ffcec9e6471bf5b0dd79ba05e4a ] Commit b76437579d13 ("procfs: mark thread stack correctly in proc//maps") added [stack:TID] annotation to /proc//maps. Finding the task of a stack VMA requires walking the entire thread list, turning this into quadratic behavior: a thousand threads means a thousand stacks, so the rendering of /proc//maps needs to look at a million combinations. The cost is not in proportion to the usefulness as described in the patch. Drop the [stack:TID] annotation to make /proc//maps (and /proc//numa_maps) usable again for higher thread counts. The [stack] annotation inside /proc//task//maps is retained, as identifying the stack VMA there is an O(1) operation. Siddesh said: "The end users needed a way to identify thread stacks programmatically and there wasn't a way to do that. I'm afraid I no longer remember (or have access to the resources that would aid my memory since I changed employers) the details of their requirement. However, I did do this on my own time because I thought it was an interesting project for me and nobody really gave any feedback then as to its utility, so as far as I am concerned you could roll back the main thread maps information since the information is available in the thread-specific files" Signed-off-by: Johannes Weiner Cc: "Kirill A. Shutemov" Cc: Siddhesh Poyarekar Cc: Shaohua Li Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 25db8d1cb34a0e6eb61152529be268265c91a015 Author: Dasaratharaman Chandramouli Date: Thu Sep 4 17:22:54 2014 -0700 intel_idle: Support for Intel Xeon Phi Processor x200 Product Family [ Upstream commit 281baf7a702693deaa45c98ef0c5161006b48257 ] Enables "Intel(R) Xeon Phi(TM) Processor x200 Product Family" support, formerly code-named KNL. It is based on modified Intel Atom Silvermont microarchitecture. Signed-off-by: Dasaratharaman Chandramouli [micah.barany@intel.com: adjusted values of residency and latency] Signed-off-by: Micah Barany [hubert.chrzaniuk@intel.com: removed deprecated CPUIDLE_FLAG_TIME_VALID flag] Signed-off-by: Hubert Chrzaniuk Signed-off-by: Pawel Karczewski Signed-off-by: Len Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 321aeea695a2a9343c20d03f33a475978b55c719 Author: Manoj N. Kumar Date: Fri Mar 4 15:55:19 2016 -0600 cxlflash: Fix to avoid unnecessary scan with internal LUNs [ Upstream commit 603ecce95f4817074a724a889cd88c3c8210f933 ] When switching to the internal LUN defined on the IBM CXL flash adapter, there is an unnecessary scan occurring on the second port. This scan leads to the following extra lines in the log: Dec 17 10:09:00 tul83p1 kernel: [ 3708.561134] cxlflash 0008:00:00.0: cxlflash_queuecommand: (scp=c0000000fc1f0f00) 11/1/0/0 cdb=(A0000000-00000000-10000000-00000000) Dec 17 10:09:00 tul83p1 kernel: [ 3708.561147] process_cmd_err: cmd failed afu_rc=32 scsi_rc=0 fc_rc=0 afu_extra=0xE, scsi_extra=0x0, fc_extra=0x0 By definition, both of the internal LUNs are on the first port/channel. When the lun_mode is switched to internal LUN the same value for host->max_channel is retained. This causes an unnecessary scan over the second port/channel. This fix alters the host->max_channel to 0 (1 port), if internal LUNs are configured and switches it back to 1 (2 ports) while going back to external LUNs. Signed-off-by: Manoj N. Kumar Acked-by: Matthew R. Ochs Reviewed-by: Uma Krishnan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bee629f1b07375d467a679797acbf8d8ab3db61f Author: Vitaly Kuznetsov Date: Wed Jan 27 22:29:36 2016 -0800 Drivers: hv: vmbus: don't manipulate with clocksources on crash [ Upstream commit 3ccb4fd8f492f99aece21acc1bd6142275f26236 ] clocksource_change_rating() involves mutex usage and can't be called in interrupt context. It also makes sense to avoid doing redundant work on crash. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d6d72d7cbe464e3776370b65f518866953cb4e12 Author: Vitaly Kuznetsov Date: Wed Jan 27 22:29:35 2016 -0800 Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload() [ Upstream commit 415719160de3fae3bb9cbc617664649919cd00d0 ] We have to call vmbus_initiate_unload() on crash to make kdump work but the crash can also be happening in interrupt (e.g. Sysrq + c results in such) where we can't schedule or the following will happen: [ 314.905786] bad: scheduling from the idle thread! Just skipping the wait (and even adding some random wait here) won't help: to make host-side magic working we're supposed to receive CHANNELMSG_UNLOAD (and actually confirm the fact that we received it) but we can't use interrupt-base path (vmbus_isr()-> vmbus_on_msg_dpc()). Implement a simple busy wait ignoring all the other messages and use it if we're in an interrupt context. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d0d84ae99d3c11775896420ff2e4bd2a084e1f90 Author: Vitaly Kuznetsov Date: Wed Jan 27 22:29:34 2016 -0800 Drivers: hv: vmbus: avoid infinite loop in init_vp_index() [ Upstream commit 79fd8e706637a5c7c41f9498fe0fbfb437abfdc8 ] When we pick a CPU to use for a new subchannel we try find a non-used one on the appropriate NUMA node, we keep track of them with the primary->alloced_cpus_in_node mask. Under normal circumstances we don't run out of available CPUs but it is possible when we we don't initialize some cpus in Linux, e.g. when we boot with 'nr_cpus=' limitation. Avoid the infinite loop in init_vp_index() by checking that we still have non-used CPUs in the alloced_cpus_in_node mask and resetting it in case we don't. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit def391c897a2a99da371b74bd70f32f0f80dfed3 Author: Ching Huang Date: Wed Nov 25 19:41:23 2015 +0800 arcmsr: fixes not release allocated resource [ Upstream commit 98f90debc2b64a40a416dd9794ac2d8de6b43af2 ] Releasing allocated resource if get configuration data failed. Signed-off-by: Ching Huang Reviewed-by: Johannes Thumshirn Reviewed-by: Hannes Reinicke Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c77d6c3c88f359fb760664a2cf054785b69a4f71 Author: Ching Huang Date: Wed Nov 25 19:36:02 2015 +0800 arcmsr: fixed getting wrong configuration data [ Upstream commit 251e2d25bfb72b69edd414abfa42a41191d9657a ] Fixed getting wrong configuration data of adapter type B and type D. Signed-off-by: Ching Huang Reviewed-by: Hannes Reinicke Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1e455f2fdb4bdd372b89b7c1c1cd80f70977010b Author: Gerald Schaefer Date: Mon Nov 16 14:35:48 2015 +0100 s390/pci_dma: fix DMA table corruption with > 4 TB main memory [ Upstream commit 69eea95c48857c9dfcac120d6acea43027627b28 ] DMA addresses returned from map_page() are calculated by using an iommu bitmap plus a start_dma offset. The size of this bitmap is based on the main memory size. If we have more than (4 TB - start_dma) main memory, the DMA address calculation will also produce addresses > 4 TB. Such addresses cannot be inserted in the 3-level DMA page table, instead the entries modulo 4 TB will be overwritten. Fix this by restricting the iommu bitmap size to (4 TB - start_dma). Also set zdev->end_dma to the actual end address of the usable range, instead of the theoretical maximum as reported by the hardware, which fixes a sanity check in dma_map() and also the IOMMU API domain geometry aperture calculation. Signed-off-by: Gerald Schaefer Reviewed-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 160790a044c27bbd8b54bed71a7725f7ef6c1964 Author: Gal Pressman Date: Wed Mar 2 00:13:38 2016 +0200 net/mlx5e: Don't modify CQ before it was created [ Upstream commit 2fcb92fbd04eef26dfe7e67839da6262d83d6b65 ] Calling mlx5e_set_coalesce while the interface is down will result in modifying CQs that don't exist. Fixes: f62b8bb8f2d3 ('net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality') Signed-off-by: Gal Pressman Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3b763fc8f05e755a0c1baa1ba6c2daaf87fa5ac5 Author: Gal Pressman Date: Wed Mar 2 00:13:37 2016 +0200 net/mlx5e: Don't try to modify CQ moderation if it is not supported [ Upstream commit 7524a5d88b94afef8397a79f1e664af5b7052c22 ] If CQ moderation is not supported by the device, print a warning on netdevice load, and return error when trying to modify/query cq moderation via ethtool. Fixes: f62b8bb8f2d3 ('net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality') Signed-off-by: Gal Pressman Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4ab4d8c00baf7f8fd0859599e3e72bb68d7daf42 Author: Adrian Hunter Date: Thu Nov 26 14:00:46 2015 +0200 mmc: sdhci: Do not BUG on invalid vdd [ Upstream commit 9d5de93f6d543b356e39e225988ef443a7bce34c ] The driver may not be able to set the power correctly but that is not a reason to BUG(). Signed-off-by: Adrian Hunter Reviewed-by: Venu Byravarasu Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 840a59324e631a167c0aab4136024e58374ddd2c Author: Aviv Greenberg Date: Fri Oct 16 08:48:51 2015 -0300 UVC: Add support for R200 depth camera [ Upstream commit 5d8d8db851ef81337e7026b32a9d5a9cfb2271d5 ] Add support for Intel R200 depth camera in uvc driver. This includes adding new uvc GUIDs for the new pixel formats, adding new V4L pixel format definition to user api headers, and updating the uvc driver GUID-to-4cc tables with the new formats. Tested-by: Greenberg, Aviv D Signed-off-by: Aviv Greenberg Signed-off-by: Sakari Ailus Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f2b8424f35f5d457c2d35b3823ee0fb272e77728 Author: Gavin Guo Date: Wed Jan 20 12:36:58 2016 +0800 sched/numa: Fix use-after-free bug in the task_numa_compare [ Upstream commit 1dff76b92f69051e579bdc131e01500da9fa2a91 ] The following message can be observed on the Ubuntu v3.13.0-65 with KASan backported: ================================================================== BUG: KASan: use after free in task_numa_find_cpu+0x64c/0x890 at addr ffff880dd393ecd8 Read of size 8 by task qemu-system-x86/3998900 ============================================================================= BUG kmalloc-128 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in task_numa_fault+0xc1b/0xed0 age=41980 cpu=18 pid=3998890 __slab_alloc+0x4f8/0x560 __kmalloc+0x1eb/0x280 task_numa_fault+0xc1b/0xed0 do_numa_page+0x192/0x200 handle_mm_fault+0x808/0x1160 __do_page_fault+0x218/0x750 do_page_fault+0x1a/0x70 page_fault+0x28/0x30 SyS_poll+0x66/0x1a0 system_call_fastpath+0x1a/0x1f INFO: Freed in task_numa_free+0x1d2/0x200 age=62 cpu=18 pid=0 __slab_free+0x2ab/0x3f0 kfree+0x161/0x170 task_numa_free+0x1d2/0x200 finish_task_switch+0x1d2/0x210 __schedule+0x5d4/0xc60 schedule_preempt_disabled+0x40/0xc0 cpu_startup_entry+0x2da/0x340 start_secondary+0x28f/0x360 Call Trace: [] dump_stack+0x45/0x56 [] print_trailer+0xfd/0x170 [] object_err+0x36/0x40 [] kasan_report_error+0x1e9/0x3a0 [] kasan_report+0x40/0x50 [] ? task_numa_find_cpu+0x64c/0x890 [] __asan_load8+0x69/0xa0 [] ? find_next_bit+0xd8/0x120 [] task_numa_find_cpu+0x64c/0x890 [] task_numa_migrate+0x4ac/0x7b0 [] numa_migrate_preferred+0xb3/0xc0 [] task_numa_fault+0xb88/0xed0 [] do_numa_page+0x192/0x200 [] handle_mm_fault+0x808/0x1160 [] ? sched_clock_cpu+0x10d/0x160 [] ? native_load_tls+0x82/0xa0 [] __do_page_fault+0x218/0x750 [] ? hrtimer_try_to_cancel+0x76/0x160 [] ? schedule_hrtimeout_range_clock.part.24+0xf7/0x1c0 [] do_page_fault+0x1a/0x70 [] page_fault+0x28/0x30 [] ? do_sys_poll+0x1c4/0x6d0 [] ? enqueue_task_fair+0x4b6/0xaa0 [] ? sched_clock+0x9/0x10 [] ? resched_task+0x7a/0xc0 [] ? check_preempt_curr+0xb3/0x130 [] ? poll_select_copy_remaining+0x170/0x170 [] ? wake_up_state+0x10/0x20 [] ? drop_futex_key_refs.isra.14+0x1f/0x90 [] ? futex_requeue+0x3de/0xba0 [] ? do_futex+0xbe/0x8f0 [] ? read_tsc+0x9/0x20 [] ? ktime_get_ts+0x12d/0x170 [] ? timespec_add_safe+0x59/0xe0 [] SyS_poll+0x66/0x1a0 [] system_call_fastpath+0x1a/0x1f As commit 1effd9f19324 ("sched/numa: Fix unsafe get_task_struct() in task_numa_assign()") points out, the rcu_read_lock() cannot protect the task_struct from being freed in the finish_task_switch(). And the bug happens in the process of calculation of imp which requires the access of p->numa_faults being freed in the following path: do_exit() current->flags |= PF_EXITING; release_task() ~~delayed_put_task_struct()~~ schedule() ... ... rq->curr = next; context_switch() finish_task_switch() put_task_struct() __put_task_struct() task_numa_free() The fix here to get_task_struct() early before end of dst_rq->lock to protect the calculation process and also put_task_struct() in the corresponding point if finally the dst_rq->curr somehow cannot be assigned. Additional credit to Liang Chen who helped fix the error logic and add the put_task_struct() to the place it missed. Signed-off-by: Gavin Guo Signed-off-by: Peter Zijlstra (Intel) Cc: Andrea Arcangeli Cc: Andrew Morton Cc: Hugh Dickins Cc: Linus Torvalds Cc: Mel Gorman Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: jay.vosburgh@canonical.com Cc: liang.chen@canonical.com Link: http://lkml.kernel.org/r/1453264618-17645-1-git-send-email-gavin.guo@canonical.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5fb01ac92f6138d1f81f54766c80a23bc63e896d Author: Libin Yang Date: Thu Jan 14 14:09:00 2016 +0800 ALSA: hda - add codec support for Kabylake display audio codec [ Upstream commit 91815d8aa7e2f45d30e51caa297061ad893628d9 ] This patch adds codec ID (0x8086280b) for Kabylake display codec and apply the hsw fix-ups to Kabylake. Signed-off-by: Libin Yang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a554bd7ccf3be8be0ecb430dae27fb97c4915564 Author: Ville Syrjälä Date: Wed Feb 10 19:59:05 2016 +0200 drm/i915: Fix hpd live status bits for g4x [ Upstream commit 0780cd36c7af70c55981ee624084f0f48cae9b95 ] Looks like g4x hpd live status bits actually agree with the spec. At least they do on the machine I have, and apparently on Nick Bowler's g4x as well. So gm45 may be the only platform where they don't agree. At least that seems to be the case based on the (somewhat incomplete) logs/dumps in [1], and Daniel has also tested this on his gm45 sometime in the past. So let's change the bits to match the spec on g4x. That actually makes the g4x bits identical to vlv/chv so we can just share the code between those platforms, leaving gm45 as the special case. [1] https://bugzilla.kernel.org/show_bug.cgi?id=52361 Cc: Shashank Sharma Cc: Sonika Jindal Cc: Daniel Vetter Cc: Jani Nikula Cc: Nick Bowler References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.html Reported-by: Nick Bowler Cc: stable@vger.kernel.org Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1455127145-20087-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1b82da380dcfd030bd1ee32853b132659bb0ab4c Author: Parthasarathy Bhuvaragan Date: Thu Mar 3 17:54:54 2016 +0100 tipc: fix nullptr crash during subscription cancel [ Upstream commit 4de13d7ed6ffdcbb34317acaa9236f121176f5f8 ] commit 4d5cfcba2f6e ('tipc: fix connection abort during subscription cancel'), removes the check for a valid subscription before calling tipc_nametbl_subscribe(). This will lead to a nullptr exception when we process a subscription cancel request. For a cancel request, a null subscription is passed to tipc_nametbl_subscribe() resulting in exception. In this commit, we call tipc_nametbl_subscribe() only for a valid subscription. Fixes: 4d5cfcba2f6e ('tipc: fix connection abort during subscription cancel') Reported-by: Anders Widell Signed-off-by: Parthasarathy Bhuvaragan Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 950464b230e007f5206b4a4ac86aeba70524b2f6 Author: Andrew Pinski Date: Wed Feb 24 17:44:57 2016 -0800 arm64: Add workaround for Cavium erratum 27456 [ Upstream commit 104a0c02e8b1936c049e18a6d4e4ab040fb61213 ] On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI instructions may cause the icache to become corrupted if it contains data for a non-current ASID. This patch implements the workaround (which invalidates the local icache when switching the mm) by using code patching. Signed-off-by: Andrew Pinski Signed-off-by: David Daney Reviewed-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7c3692b809bfbcf03cbb70104dc365658b3bfb6 Author: Sunil Goutham Date: Wed Feb 24 16:40:50 2016 +0530 net: thunderx: Fix for Qset error due to CQ full [ Upstream commit 4c0b6eaf373a5323f03a3a20c42fc435715b073d ] On Thunderx pass 1.x and pass2 due to a HW errata default CQ DROP_LEVEL of 0x80 is not sufficient to avoid CQ_WR_FULL Qset error when packets are being received at >20Mpps resulting in complete stall of packet reception. This patch will configure it to 0x100 which is what is expected by HW on Thunderx. On future passes of thunderx and other chips HW default/reset value will be 0x100 or higher hence not overwritten. Signed-off-by: Jerin Jacob Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 724457fa1c0ca2992bec5a3db85ac3b130409cfa Author: Alex Deucher Date: Thu Dec 17 10:23:34 2015 -0500 drm/radeon: fix dp link rate selection (v2) [ Upstream commit 092c96a8ab9d1bd60ada2ed385cc364ce084180e ] Need to properly handle the max link rate in the dpcd. This prevents some cases where 5.4 Ghz is selected when it shouldn't be. v2: simplify logic, add array bounds check Reviewed-by: Tom St Denis Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8844e74f8e0f1758ad9931b480ec88dd37c8528c Author: Alex Deucher Date: Thu Dec 17 09:57:49 2015 -0500 drm/amdgpu: fix dp link rate selection (v2) [ Upstream commit 41869c1c7fe583dec932eb3d87de2e010b30a737 ] Need to properly handle the max link rate in the dpcd. This prevents some cases where 5.4 Ghz is selected when it shouldn't be. v2: simplify logic, add array bounds check Reviewed-by: Tom St Denis Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 07235140a4c3ed8e0d8fcb58fc51d1cbb5406ff4 Author: Swapnil Nagle Date: Thu Feb 4 11:45:17 2016 -0500 qla2xxx: Use ATIO type to send correct tmr response [ Upstream commit d7236ac368212bd6fc8b45f050136ee53e6a6f2d ] The function value inside se_cmd can change if the TMR is cancelled. Use original ATIO Type to correctly determine CTIO response. Signed-off-by: Swapnil Nagle Signed-off-by: Himanshu Madhani Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b07ef1af4d0e7130ac1917f662b1e410e9b09555 Author: Adrian Hunter Date: Thu Nov 26 14:00:49 2015 +0200 mmc: sdhci: 64-bit DMA actually has 4-byte alignment [ Upstream commit 04a5ae6fdd018af29675eb8b6c2550c87f471570 ] The version 3.00 SDHCI spec. was a bit unclear about the required data alignment for 64-bit DMA, whereas the version 4.10 spec. uses different language and indicates that only 4-byte alignment is required rather than the 8-byte alignment currently implemented. That make no difference to SD and EMMC which invariably transfer data in sector-aligned blocks. However with SDIO, it results in using more DMA descriptors than necessary. Theoretically that slows DMA slightly although DMA is not the limiting factor for throughput, so there is no discernable impact on performance. Nevertheless, the driver should follw the spec unless there is good reason not to, so this patch corrects the alignment criterion. There is a more complicated criterion for the DMA descriptor table itself. However the table is allocated by dma_alloc_coherent() which allocates pages (i.e. aligned to a page boundary). For simplicity just check it is 8-byte aligned, but add a comment that some Intel controllers actually require 8-byte alignment even when using 32-bit DMA. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 934e6279f9cee184f34d1247132bcd43ff74656b Author: Maarten Lankhorst Date: Thu Jan 7 10:59:21 2016 +0100 drm/atomic: Do not unset crtc when an encoder is stolen [ Upstream commit 97a8df90875f72ba3b4c3320759fd93cea743261 ] While we steal the encoder away from the connector the connector may be updated to use a different encoder. Without this change if 2 connectors swap encoders one of them will end up without a crtc. Signed-off-by: Maarten Lankhorst Reviewed-by: Gustavo Padovan Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1452160762-30487-5-git-send-email-maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bea3a6d7c54c81e470e63e1bcca16e638c4ab07f Author: Michał Winiarski Date: Fri Feb 5 13:21:42 2016 +0100 drm/i915/skl: Add missing SKL ids [ Upstream commit 7157bb27e79875db5603aa1e30f56e873a8300f9 ] Used by production devices: Intel(R) Iris Graphics 540 (Skylake GT3e) Intel(R) Iris Graphics 550 (Skylake GT3e) v2: More ids v3: Less ids (GT1 got duplicated) Cc: Mika Kuoppala Signed-off-by: Michał Winiarski Reviewed-by: Mika Kuoppala Signed-off-by: Mika Kuoppala Link: http://patchwork.freedesktop.org/patch/msgid/1454674902-26207-1-git-send-email-michal.winiarski@intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c459dadb94b704e440ab8d3ed9e3df634416088f Author: Imre Deak Date: Thu Jan 28 16:04:12 2016 +0200 drm/i915/bxt: update list of PCIIDs [ Upstream commit 985dd4360fdf2533fe48a33a4a2094f2e4718dc0 ] Add PCIIDs for new versions of the SOC, based on BSpec. Also add the name of the versions as code comment where this is available. The new versions don't have any changes visible to the kernel driver. Signed-off-by: Imre Deak Reviewed-by: Mika Kuoppala Link: http://patchwork.freedesktop.org/patch/msgid/1453989852-13569-1-git-send-email-imre.deak@intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fc2942b6e2de2efc8a9d3784d4b0d3543149613 Author: Marc Zyngier Date: Fri Jan 15 17:41:09 2016 +0000 hrtimer: Catch illegal clockids [ Upstream commit 9006a01829a50cfd6bbd4980910ed46e895e93d7 ] It is way too easy to take any random clockid and feed it to the hrtimer subsystem. At best, it gets mapped to a monotonic base, but it would be better to just catch illegal values as early as possible. This patch does exactly that, mapping illegal clockids to an illegal base index, and panicing when we detect the illegal condition. Signed-off-by: Marc Zyngier Cc: Tomasz Nowicki Cc: Christoffer Dall Link: http://lkml.kernel.org/r/1452879670-16133-3-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8a840b7f37551fd072147968eafe447e2572e180 Author: Anjali Singhai Jain Date: Wed Dec 9 15:50:24 2015 -0800 i40e/i40evf: Fix RSS rx-flow-hash configuration through ethtool [ Upstream commit 6e35c04cf633e55648acb9ccabff42aa37bd4044 ] This patch fixes the Hash PCTYPE enable for X722 since it supports a broader selection of PCTYPES for TCP and UDP. This patch also fixes a bug in XL710, X710, X722 support for RSS, as of now we cannot reduce the (4)tuple for RSS for TCP/IPv4/IPV6 or UDP/IPv4/IPv6 packets since this requires a product feature change that comes in a later release. A VF should never be allowed to change the tuples for RSS for any PCTYPE since that's a global setting for the device in case of i40e devices. Change-ID: I0ee7203c9b24813260f58f3220798bc9d9ac4a12 Signed-off-by: Anjali Singhai Jain Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 116a7584cbf95324d2ac66bbce0f2682e71a81f0 Author: Suganath prabu Subramani Date: Thu Jan 28 12:07:06 2016 +0530 mpt3sas: Fix for Asynchronous completion of timedout IO and task abort of timedout IO. [ Upstream commit 03d1fb3a65783979f23bd58b5a0387e6992d9e26 ] Track msix of each IO and use the same msix for issuing abort to timed out IO. With this driver will process IO's reply first followed by TM. Signed-off-by: Suganath prabu Subramani Signed-off-by: Chaitra P B Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b208a5d0a3b37a68cb1694a125c8deee56be45c Author: Tomas Henzl Date: Wed Dec 23 14:21:47 2015 +0100 mpt3sas: A correction in unmap_resources [ Upstream commit 5f985d88bac34e7f3b4403118eab072902a0b392 ] It might happen that we try to free an already freed pointer. Reported-by: Maurizio Lombardi Signed-off-by: Tomas Henzl Acked-by: Chaitra P B Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6d0e49cf1b432a11bf60b9fc2ee41c3e4e0347fe Author: Colin Ian King Date: Fri Feb 5 16:30:39 2016 +0000 net: cavium: liquidio: fix check for in progress flag [ Upstream commit 19a6d156a7bd080f3a855a40a4a08ab475e34b4a ] smatch detected a suspicious looking bitop condition: drivers/net/ethernet/cavium/liquidio/lio_main.c:2529 handle_timestamp() warn: suspicious bitop condition (skb_shinfo(skb)->tx_flags | SKBTX_IN_PROGRESS is always non-zero, so the logic is definitely not correct. Use & to mask the correct bit. Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 849e28efb04c4c46f6189f75e30d3f541eb6dfb4 Author: Tirumalesh Chalamarla Date: Wed Feb 10 10:46:53 2016 -0800 arm64: KVM: Configure TCR_EL2.PS at runtime [ Upstream commit 3c5b1d92b3b02be07873d611a27950addff544d3 ] Setting TCR_EL2.PS to 40 bits is wrong on systems with less that less than 40 bits of physical addresses. and breaks KVM on systems where the RAM is above 40 bits. This patch uses ID_AA64MMFR0_EL1.PARange to set TCR_EL2.PS dynamically, just like we already do for VTCR_EL2.PS. [Marc: rewrote commit message, patch tidy up] Reviewed-by: Marc Zyngier Signed-off-by: Tirumalesh Chalamarla Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d5251a1952bff1148ceeea5283e34d07a502da62 Author: Tirumalesh Chalamarla Date: Thu Feb 4 10:45:25 2016 -0800 irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor [ Upstream commit 1a1ebd5fb1e203ee8cc73508cc7a38ac4b804596 ] The ARM GICv3 specification mentions the need for dsb after a read from the ICC_IAR1_EL1 register: 4.1.1 Physical CPU Interface: The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1 on the state of a returned INTID are not guaranteed to be visible until after the execution of a DSB. Not having this could result in missed interrupts, so let's add the required barrier. [Marc: fixed commit message] Acked-by: Marc Zyngier Signed-off-by: Tirumalesh Chalamarla Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e941af922e512e4b4b2653a33c8372e5e4d57579 Author: Vladimir Zapolskiy Date: Sun Dec 6 13:32:01 2015 +0200 pwm: lpc32xx: fix and simplify duty cycle and period calculations [ Upstream commit 5a9fc9c666d5d759699cf5495bda85f1da0d747e ] The change fixes a problem, if duty_ns is too small in comparison to period_ns (as a valid corner case duty_ns is 0 ns), then due to PWM_DUTY() macro applied on a value the result is overflowed over 8 bits, and instead of the highest bitfield duty cycle value 0xff the invalid duty cycle bitfield value 0x00 is written. For reference the LPC32xx spec defines PWMx_DUTY bitfield description is this way and it seems to be correct: [Low]/[High] = [PWM_DUTY]/[256-PWM_DUTY], where 0 < PWM_DUTY <= 255. In addition according to my oscilloscope measurements LPC32xx PWM is "tristate" in sense that it produces a wave with floating min/max voltage levels for different duty cycle values, for corner cases: PWM_DUTY == 0x01 => signal is in range from -1.05v to 0v .... PWM_DUTY == 0x80 => signal is in range from -0.75v to +0.75v .... PWM_DUTY == 0xff => signal is in range from 0v to +1.05v PWM_DUTY == 0x00 => signal is around 0v, PWM is off Due to this peculiarity on very long period ranges (less than 1KHz) and odd pre-divider values PWM generated wave does not remind a clock shape signal, but rather a heartbit shape signal with positive and negative peaks, so I would recommend to use high-speed HCLK clock as a PWM parent clock and avoid using RTC clock as a parent. The change corrects PWM output in corner cases and prevents any possible overflows in calculation of values for PWM_DUTY and PWM_RELOADV bitfields, thus helper macro definitions may be removed. Signed-off-by: Vladimir Zapolskiy Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a5880180d33e982962322de3f46f731f82a9b9ff Author: Vladimir Zapolskiy Date: Sun Dec 6 13:31:59 2015 +0200 pwm: lpc32xx: correct number of PWM channels from 2 to 1 [ Upstream commit ebe1fca35038df28b5c183e8486863e765364ec1 ] LPC32xx SoC has two independent PWM controllers, they have different clock parents, clock gates and even slightly different controls, and each of these two PWM controllers has one output channel. Due to almost similar controls arranged in a row it is incorrectly set that there is one PWM controller with two channels, fix this problem, which at the moment prevents separate configuration of different clock parents and gates for both PWM controllers. The change makes previous PWM device node description incompatible with this update. Signed-off-by: Vladimir Zapolskiy Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 67a915d817eb2929008e1bd05ef7875fcce09a16 Author: Stefan Agner Date: Mon Nov 23 14:45:07 2015 -0800 pwm: fsl-ftm: Fix clock enable/disable when using PM [ Upstream commit 816aec2325e620b6454474372a21f90a8740cb28 ] A FTM PWM instance enables/disables three clocks: The bus clock, the counter clock and the PWM clock. The bus clock gets enabled on pwm_request, whereas the counter and PWM clocks will be enabled upon pwm_enable. The driver has three closesly related issues when enabling/disabling clocks during suspend/resume: - The three clocks are not treated differently in regards to the individual PWM state enabled/requested. This can lead to clocks getting disabled which have not been enabled in the first place (a PWM channel which only has been requested going through suspend/resume). - When entering suspend, the current behavior relies on the FTM_OUTMASK register: If a PWM output is unmasked, the driver assumes the clocks are enabled. However, some PWM instances have only 2 channels connected (e.g. Vybrid's FTM1). In that case, the FTM_OUTMASK reads 0x3 if all channels are disabled, even if the code wrote 0xff to it before. For those PWM instances, the current approach to detect enabled PWM signals does not work. - A third issue applies to the bus clock only, which can get enabled multiple times (once for each PWM channel of a PWM chip). This is fine, however when entering suspend mode, the clock only gets disabled once. This change introduces a different approach by relying on the enable and prepared counters of the clock framework and using the frameworks PWM signal states to address all three issues. Clocks get disabled during suspend and back enabled on resume regarding to the PWM channels individual state (requested/enabled). Since we do not count the clock enables in the driver, this change no longer clears the Status and Control registers Clock Source Selection (FTM_SC[CLKS]). However, since we disable the selected clock anyway, and we explicitly select the clock source on reenabling a PWM channel this approach should not make a difference in practice. Signed-off-by: Stefan Agner Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e77b14a6f3cee18cb03f124fd283a122b6516900 Author: Tomas Henzl Date: Mon Feb 1 15:12:04 2016 +0100 megaraid_sas: Add an i/o barrier [ Upstream commit b99dbe56d511eb07de33bfa1b99ac5a6ff76ae08 ] A barrier should be added to ensure proper ordering of memory mapped writes. Signed-off-by: Tomas Henzl Reviewed-by: Kashyap Desai Acked-by: Kashyap Desai Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 948cb1ca1fc3b88443051c17c58ee94608465552 Author: Sumit Saxena Date: Thu Jan 28 21:14:26 2016 +0530 megaraid_sas: Fix SMAP issue [ Upstream commit ea1c928bb6051ec4ccf24826898aa2361eaa71e5 ] Inside compat IOCTL hook of driver, driver was using wrong address of ioc->frame.raw which leads sense_ioc_ptr to be calculated wrongly and failing IOCTL. Signed-off-by: Sumit Saxena Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7aeba6bd2bf61cc397d5e7dcc9eed2020a14661 Author: Sumit Saxena Date: Thu Jan 28 21:04:22 2016 +0530 megaraid_sas: Do not allow PCI access during OCR [ Upstream commit 11c71cb4ab7cd901b9d6f0ff267c102778c1c8ef ] This patch will do synhronization between OCR function and AEN function using "reset_mutex" lock. reset_mutex will be acquired only in the first half of the AEN function which issues a DCMD. Second half of the function which calls SCSI API (scsi_add_device/scsi_remove_device) should be out of reset_mutex to avoid deadlock between scsi_eh thread and driver. During chip reset (inside OCR function), there should not be any PCI access and AEN function (which is called in delayed context) may be firing DCMDs (doing PCI writes) when chip reset is happening in parallel which will cause FW fault. This patch will solve the problem by making AEN thread and OCR thread mutually exclusive. Signed-off-by: Sumit Saxena Signed-off-by: Kashyap Desai Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9eccfa31f0024f0407a122b1afdc91bba52cf511 Author: Sebastian Ott Date: Mon Jan 25 10:32:51 2016 +0100 s390/cio: update measurement characteristics [ Upstream commit 9f3d6d7a40a178b8a5b5274f4e55fec8c30147c9 ] Per channel path measurement characteristics are obtained during channel path registration. However if some properties of a channel path change we don't update the measurement characteristics. Make sure to update the characteristics when we change the properties of a channel path or receive a notification from FW about such a change. Signed-off-by: Sebastian Ott Reviewed-by: Peter Oberparleiter Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit eb9f26c99639de3b04c89085855196f56b3f69ea Author: Sebastian Ott Date: Mon Jan 25 10:31:33 2016 +0100 s390/cio: ensure consistent measurement state [ Upstream commit 61f0bfcf8020f02eb09adaef96745d1c1d1b3623 ] Make sure that in all cases where we could not obtain measurement characteristics the associated fields are set to invalid values. Note: without this change the "shared" capability of a channel path for which we could not obtain the measurement characteristics was incorrectly displayed as 0 (not shared). We will now correctly report "unknown" in this case. Signed-off-by: Sebastian Ott Reviewed-by: Peter Oberparleiter Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10de05f6c3cd24bed1832d205e94da2c3cee324e Author: Sebastian Ott Date: Mon Jan 25 10:30:27 2016 +0100 s390/cio: fix measurement characteristics memleak [ Upstream commit 0d9bfe9123cfde59bf5c2e375b59d2a7d5061c4c ] Measurement characteristics are allocated during channel path registration but not freed during deregistration. Fix this by embedding these characteristics inside struct channel_path. Signed-off-by: Sebastian Ott Reviewed-by: Peter Oberparleiter Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2b2c611c802b1c73ee346f3f213f4356bd6510dd Author: Ursula Braun Date: Fri Dec 11 12:27:55 2015 +0100 qeth: initialize net_device with carrier off [ Upstream commit e5ebe63214d44d4dcf43df02edf3613e04d671b9 ] /sys/class/net//operstate for an active qeth network interface offen shows "unknown", which translates to "state UNKNOWN in output of "ip link show". It is caused by a missing initialization of the __LINK_STATE_NOCARRIER bit in the net_device state field. This patch adds a netif_carrier_off() invocation when creating the net_device for a qeth device. Signed-off-by: Ursula Braun Acked-by: Hendrik Brueckner Reference-ID: Bugzilla 133209 Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2dfdfa34392530885c09f50caccf8fa4053f6cde Author: James Smart Date: Wed Dec 16 18:12:04 2015 -0500 lpfc: Fix external loopback failure. [ Upstream commit 4360ca9c24388e44cb0e14861a62fff43cf225c0 ] Fix external loopback failure. Rx sequence reassembly was incorrect. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10103c5228e85f2878ff77cce36afe3c05468984 Author: James Smart Date: Wed Dec 16 18:12:03 2015 -0500 lpfc: Fix mbox reuse in PLOGI completion [ Upstream commit 01c73bbcd7cc4f31f45a1b0caeacdba46acd9c9c ] Fix mbox reuse in PLOGI completion. Moved allocations so that buffer properly init'd. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 13c61f04687d95b650e2ac7091b7a221d0caf1f0 Author: James Smart Date: Wed Dec 16 18:11:59 2015 -0500 lpfc: Fix RDP Speed reporting. [ Upstream commit 81e7517723fc17396ba91f59312b3177266ddbda ] Fix RDP Speed reporting. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6b9bd78515c42966540c1edf11253d76fd57eb14 Author: James Smart Date: Wed Dec 16 18:11:57 2015 -0500 lpfc: Fix crash in fcp command completion path. [ Upstream commit c90261dcd86e4eb5c9c1627fde037e902db8aefa ] Fix crash in fcp command completion path. Missed null check. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7cf5c223ccf949e6d5ef6b87c33edcad67a8ebbe Author: James Smart Date: Wed Dec 16 18:11:56 2015 -0500 lpfc: Fix driver crash when module parameter lpfc_fcp_io_channel set to 16 [ Upstream commit 6690e0d4fc5cccf74534abe0c9f9a69032bc02f0 ] Fix driver crash when module parameter lpfc_fcp_io_channel set to 16 Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0217efc5b83a7443c2234e5426493b2d06b7067c Author: James Smart Date: Wed Dec 16 18:11:55 2015 -0500 lpfc: Fix RegLogin failed error seen on Lancer FC during port bounce [ Upstream commit 4b7789b71c916f79a3366da080101014473234c3 ] Fix RegLogin failed error seen on Lancer FC during port bounce Fix the statemachine and ref counting. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1a1455583df0a4f9fbbbaec3f7aad2ef09934c66 Author: James Smart Date: Wed Dec 16 18:11:53 2015 -0500 lpfc: Fix the FLOGI discovery logic to comply with T11 standards [ Upstream commit d6de08cc46269899988b4f40acc7337279693d4b ] Fix the FLOGI discovery logic to comply with T11 standards We weren't properly setting fabric parameters, such as R_A_TOV and E_D_TOV, when we registered the vfi object in default configs and pt2pt configs. Revise to now pass service params with the values to the firmware and ensure they are reset on link bounce. Required reworking the call sequence in the discovery threads. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f499a426420ab8b6f5c5a8a728cd6f713b5f398 Author: James Smart Date: Wed Dec 16 18:11:52 2015 -0500 lpfc: Fix FCF Infinite loop in lpfc_sli4_fcf_rr_next_index_get. [ Upstream commit f5cb5304eb26d307c9b30269fb0e007e0b262b7d ] Fix FCF Infinite loop in lpfc_sli4_fcf_rr_next_index_get. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bcc975680df41bddcff13c3477087c7f51280b00 Author: Uma Krishnan Date: Mon Dec 7 16:03:32 2015 -0600 cxl: Enable PCI device ID for future IBM CXL adapter [ Upstream commit 68adb7bfd66504e97364651fb7dac3f9c8aa8561 ] Add support for future IBM Coherent Accelerator (CXL) device with ID of 0x0601. Signed-off-by: Uma Krishnan Reviewed-by: Matthew R. Ochs Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0f874d9433bd6b2acd668ef0a0359e30af38f8b0 Author: Brian Norris Date: Fri Jan 8 10:30:09 2016 -0800 cxl: fix build for GCC 4.6.x [ Upstream commit aa09545589ceeff884421d8eb38d04963190afbe ] GCC 4.6.3 does not support -Wno-unused-const-variable. Instead, use the kbuild infrastructure that checks if this options exists. Fixes: 2cd55c68c0a4 ("cxl: Fix build failure due to -Wunused-variable behaviour change") Suggested-by: Michal Marek Suggested-by: Arnd Bergmann Signed-off-by: Brian Norris Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8c67424e2a37005364d0aecd6541d221517a1c4f Author: Manoj Kumar Date: Mon Dec 14 15:07:43 2015 -0600 cxlflash: Enable device id for future IBM CXL adapter [ Upstream commit a2746fb16e41b7c8f02aa4d2605ecce97abbebbd ] This drop enables a future card with a device id of 0x0600 to be recognized by the cxlflash driver. As per the design, the Accelerator Function Unit (AFU) for this new IBM CXL Flash Adapter retains the same host interface as the previous generation. For the early prototypes of the new card, the driver with this change behaves exactly as the driver prior to this behaved with the earlier generation card. Therefore, no card specific programming has been added. These card specific changes can be staged in later if needed. Signed-off-by: Manoj N. Kumar Acked-by: Matthew R. Ochs Reviewed-by: Andrew Donnellan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 20ab6948f1c09ad84ec8f5b8fdf02ea86e33fa63 Author: Manoj Kumar Date: Mon Dec 14 15:07:23 2015 -0600 cxlflash: Resolve oops in wait_port_offline [ Upstream commit b45cdbaf9f7f0486847c52f60747fb108724652a ] If an async error interrupt is generated, and the error requires the FC link to be reset, it cannot be performed in the interrupt context. So a work element is scheduled to complete the link reset in a process context. If either an EEH event or an escalation occurs in between when the interrupt is generated and the scheduled work is started, the MMIO space may no longer be available. This will cause an oops in the worker thread. [ 606.806583] NIP kthread_data+0x28/0x40 [ 606.806633] LR wq_worker_sleeping+0x30/0x100 [ 606.806694] Call Trace: [ 606.806721] 0x50 (unreliable) [ 606.806796] wq_worker_sleeping+0x30/0x100 [ 606.806884] __schedule+0x69c/0x8a0 [ 606.806959] schedule+0x44/0xc0 [ 606.807034] do_exit+0x770/0xb90 [ 606.807109] die+0x300/0x460 [ 606.807185] bad_page_fault+0xd8/0x150 [ 606.807259] handle_page_fault+0x2c/0x30 [ 606.807338] wait_port_offline.constprop.12+0x60/0x130 [cxlflash] To prevent the problem space area from being unmapped, when there is pending work, a mapcount (using the kref mechanism) is held. The mapcount is released only when the work is completed. The last reference release is tied to the unmapping service. Signed-off-by: Manoj N. Kumar Acked-by: Matthew R. Ochs Reviewed-by: Uma Krishnan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 284555fc7f5d2d4aab34dbf2b5766c6f8da84873 Author: Manoj Kumar Date: Mon Dec 14 15:07:02 2015 -0600 cxlflash: Fix to resolve cmd leak after host reset [ Upstream commit ee91e332a6e6e9b939f60f6e1bd72fb2def5290d ] After a few iterations of resetting the card, either during EEH recovery, or a host_reset the following is seen in the logs. cxlflash 0008:00: cxlflash_queuecommand: could not get a free command At every reset of the card, the commands that are outstanding are being leaked. No effort is being made to reap these commands. A few more resets later, the above error message floods the logs and the card is rendered totally unusable as no free commands are available. Iterated through the 'cmd' queue and printed out the 'free' counter and found that on each reset certain commands were in-use and stayed in-use through subsequent resets. To resolve this issue, when the card is reset, reap all the commands that are active/outstanding. Signed-off-by: Manoj N. Kumar Acked-by: Matthew R. Ochs Reviewed-by: Andrew Donnellan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e66e0a249d9dacb9fda4135d0e38ba8ae9af9cac Author: Vaibhav Jain Date: Tue Nov 24 16:26:18 2015 +0530 cxl: Fix DSI misses when the context owning task exits [ Upstream commit 7b8ad495d59280b634a7b546f4cdf58cf4d65f61 ] Presently when a user-space process issues CXL_IOCTL_START_WORK ioctl we store the pid of the current task_struct and use it to get pointer to the mm_struct of the process, while processing page or segment faults from the capi card. However this causes issues when the thread that had originally issued the start-work ioctl exits in which case the stored pid is no more valid and the cxl driver is unable to handle faults as the mm_struct corresponding to process is no more accessible. This patch fixes this issue by using the mm_struct of the next alive task in the thread group. This is done by iterating over all the tasks in the thread group starting from thread group leader and calling get_task_mm on each one of them. When a valid mm_struct is obtained the pid of the associated task is stored in the context replacing the exiting one for handling future faults. The patch introduces a new function named get_mem_context that checks if the current task pointed to by ctx->pid is dead? If yes it performs the steps described above. Also a new variable cxl_context.glpid is introduced which stores the pid of the thread group leader associated with the context owning task. Reported-by: Matthew R. Ochs Reported-by: Frank Haverkamp Suggested-by: Ian Munsie Signed-off-by: Vaibhav Jain Acked-by: Ian Munsie Reviewed-by: Frederic Barrat Reviewed-by: Matthew R. Ochs Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c0b72ca1ae92147e0714e7a780ba7ccc4e282370 Author: Vaibhav Jain Date: Mon Nov 16 09:33:45 2015 +0530 cxl: Fix possible idr warning when contexts are released [ Upstream commit 1b5df59e50874b9034c0fa389cd52b65f1f93292 ] An idr warning is reported when a context is release after the capi card is unbound from the cxl driver via sysfs. Below are the steps to reproduce: 1. Create multiple afu contexts in an user-space application using libcxl. 2. Unbind capi card from cxl using command of form echo > /sys/bus/pci/drivers/cxl-pci/unbind 3. Exit/kill the application owning afu contexts. After above steps a warning message is usually seen in the kernel logs of the form "idr_remove called for id= which is not allocated." This is caused by the function cxl_release_afu which destroys the contexts_idr table. So when a context is release no entry for context pe is found in the contexts_idr table and idr code prints this warning. This patch fixes this issue by increasing & decreasing the ref-count on the afu device when a context is initialized or when its freed respectively. This prevents the afu from being released until all the afu contexts have been released. The patch introduces two new functions namely cxl_afu_get/put that manage the ref-count on the afu device. Also the patch removes code inside cxl_dev_context_init that increases ref on the afu device as its guaranteed to be alive during this function. Reported-by: Ian Munsie Signed-off-by: Vaibhav Jain Acked-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 64bdc685ccc1d207632a6cf17cd5771e10623c85 Author: Dexuan Cui Date: Mon Dec 14 16:01:49 2015 -0800 Drivers: hv: vmbus: fix rescind-offer handling for device without a driver [ Upstream commit 34c6801e3310ad286c7bb42bc88d42926b8f99bf ] In the path vmbus_onoffer_rescind() -> vmbus_device_unregister() -> device_unregister() -> ... -> __device_release_driver(), we can see for a device without a driver loaded: dev->driver is NULL, so dev->bus->remove(dev), namely vmbus_remove(), isn't invoked. As a result, vmbus_remove() -> hv_process_channel_removal() isn't invoked and some cleanups(like sending a CHANNELMSG_RELID_RELEASED message to the host) aren't done. We can demo the issue this way: 1. rmmod hv_utils; 2. disable the Heartbeat Integration Service in Hyper-V Manager and lsvmbus shows the device disappears. 3. re-enable the Heartbeat in Hyper-V Manager and modprobe hv_utils, but lsvmbus shows the device can't appear again. This is because, the host thinks the VM hasn't released the relid, so can't re-offer the device to the VM. We can fix the issue by moving hv_process_channel_removal() from vmbus_close_internal() to vmbus_device_release(), since the latter is always invoked on device_unregister(), whether or not the dev has a driver loaded. Signed-off-by: Dexuan Cui Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ff83d7914b749f8c654c0e08d21667035901ab75 Author: Dexuan Cui Date: Mon Dec 14 16:01:47 2015 -0800 Drivers: hv: vmbus: serialize process_chn_event() and vmbus_close_internal() [ Upstream commit 63d55b2aeb5e4faa170316fee73c3c47ea9268c7 ] process_chn_event(), running in the tasklet, can race with vmbus_close_internal() in the case of SMP guest, e.g., when the former is accessing channel->inbound.ring_buffer, the latter could be freeing the ring_buffer pages. To resolve the race, we can serialize them by disabling the tasklet when the latter is running here. Signed-off-by: Dexuan Cui Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bf59c816fb104b2e92d29f8c13f1118f4c5333c4 Author: Olaf Hering Date: Mon Dec 14 16:01:42 2015 -0800 Drivers: hv: vss: run only on supported host versions [ Upstream commit ed9ba608e4851144af8c7061cbb19f751c73e998 ] The Backup integration service on WS2012 has appearently trouble to negotiate with a guest which does not support the provided util version. Currently the VSS driver supports only version 5/0. A WS2012 offers only version 1/x and 3/x, and vmbus_prep_negotiate_resp correctly returns an empty icframe_vercnt/icmsg_vercnt. But the host ignores that and continues to send ICMSGTYPE_NEGOTIATE messages. The result are weird errors during boot and general misbehaviour. Check the Windows version to work around the host bug, skip hv_vss_init on WS2012 and older. Signed-off-by: Olaf Hering Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c1d32939e9e1951eaf7af573b15d54d8495aafff Author: Andrey Smetanin Date: Mon Dec 14 16:01:38 2015 -0800 drivers/hv: cleanup synic msrs if vmbus connect failed [ Upstream commit 17efbee8ba02ef00d3b270998978f8a1a90f1d92 ] Before vmbus_connect() synic is setup per vcpu - this means hypervisor receives writes at synic msr's and probably allocate hypervisor resources per synic setup. If vmbus_connect() failed for some reason it's neccessary to cleanup synic setup by call hv_synic_cleanup() at each vcpu to get a chance to free allocated resources by hypervisor per synic. This patch does appropriate cleanup in case of vmbus_connect() failure. Signed-off-by: Andrey Smetanin Signed-off-by: Denis V. Lunev Reviewed-by: Vitaly Kuznetsov CC: "K. Y. Srinivasan" CC: Haiyang Zhang CC: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e35b50490e2612b42edbd08b602a4ea597fce7f2 Author: Olaf Hering Date: Mon Dec 14 16:01:36 2015 -0800 Drivers: hv: util: catch allocation errors [ Upstream commit cdc0c0c94e4e6dfa371d497a3130f83349b6ead6 ] Catch allocation errors in hvutil_transport_send. Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport abstraction') Signed-off-by: Olaf Hering Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10b8e4ebc4b3b3f4f2ff3e5651429ff4427d3397 Author: Olaf Hering Date: Mon Dec 14 16:01:34 2015 -0800 tools: hv: report ENOSPC errors in hv_fcopy_daemon [ Upstream commit b4ed5d1682c6613988c2eb1de55df5ac9988afcc ] Currently some "Unspecified error 0x80004005" is reported on the Windows side if something fails. Handle the ENOSPC case and return ERROR_DISK_FULL, which allows at least Copy-VMFile to report a meaning full error. Signed-off-by: Olaf Hering Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b125fabf22d44f7c57e6df2a21d27add8385df0d Author: Olaf Hering Date: Mon Dec 14 16:01:33 2015 -0800 Drivers: hv: utils: run polling callback always in interrupt context [ Upstream commit 3cace4a616108539e2730f8dc21a636474395e0f ] All channel interrupts are bound to specific VCPUs in the guest at the point channel is created. While currently, we invoke the polling function on the correct CPU (the CPU to which the channel is bound to) in some cases we may run the polling function in a non-interrupt context. This potentially can cause an issue as the polling function can be interrupted by the channel callback function. Fix the issue by running the polling function on the appropriate CPU at interrupt level. Additional details of the issue being addressed by this patch are given below: Currently hv_fcopy_onchannelcallback is called from interrupts and also via the ->write function of hv_utils. Since the used global variables to maintain state are not thread safe the state can get out of sync. This affects the variable state as well as the channel inbound buffer. As suggested by KY adjust hv_poll_channel to always run the given callback on the cpu which the channel is bound to. This avoids the need for locking because all the util services are single threaded and only one transaction is active at any given point in time. Additionally, remove the context variable, they will always be the same as recv_channel. Signed-off-by: Olaf Hering Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e31409cd1ae44450964fc29e2bb0519cc50f5923 Author: K. Y. Srinivasan Date: Mon Dec 14 16:01:32 2015 -0800 Drivers: hv: util: Increase the timeout for util services [ Upstream commit c0b200cfb0403740171c7527b3ac71d03f82947a ] Util services such as KVP and FCOPY need assistance from daemon's running in user space. Increase the timeout so we don't prematurely terminate the transaction in the kernel. Host sets up a 60 second timeout for all util driver transactions. The host will retry the transaction if it times out. Set the guest timeout at 30 seconds. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 12e2d36594f98bef28aebe5ebf4c8c48be70ba3f Author: Matias Bjørling Date: Tue Jan 12 07:49:32 2016 +0100 lightnvm: fix missing grown bad block type [ Upstream commit b5d4acd4cbf5029a2616084d9e9f392046d53a37 ] The get/set bad block interface defines good block, factory bad block, grown bad block, device reserved block, and host reserved block. Unfortunately the grown bad block was missing, leaving the offsets wrong for device and host side reserved blocks. This patch adds the missing type and corrects the offsets. Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 651b328d97d2bdf62518093628f765824cb638fd Author: Wenwei Tao Date: Tue Jan 12 07:49:25 2016 +0100 lightnvm: fix locking and mempool in rrpc_lun_gc [ Upstream commit b262924be03d5d2ae735bc9a4b37eb2c613f61f8 ] This patch fix two issues in rrpc_lun_gc 1. prio_list is protected by rrpc_lun's lock not nvm_lun's, so acquire rlun's lock instead of lun's before operate on the list. 2. we delete block from prio_list before allocating gcb, but gcb allocation may fail, we end without putting it back to the list, this makes the block won't get reclaimed in the future. To solve this issue, delete block after gcb allocation. Signed-off-by: Wenwei Tao Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d239b53a14bb9bbe6fa45405af6fa0d86f68a874 Author: Wenwei Tao Date: Tue Jan 12 07:49:18 2016 +0100 lightnvm: unlock rq and free ppa_list on submission fail [ Upstream commit c27278bddd75a3ee755c8e83c6bcc3fdd7271ef6 ] When rrpc_write_ppalist_rq and rrpc_read_ppalist_rq succeed, we setup rq correctly, but nvm_submit_io may afterward fail since it cannot allocate request or nvme_nvm_command, we return error but forget to cleanup the previous work. Signed-off-by: Wenwei Tao Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d3f89f3a91dfa4758fdd6e98b780095d2de66943 Author: Javier Gonzalez Date: Tue Jan 12 07:49:17 2016 +0100 lightnvm: add check after mempool allocation [ Upstream commit 3bfbc6adbc5031e8a5907baa5beb27b41637742a ] The mempool allocation might fail. Make sure to return error when it does, instead of causing a kernel panic. Signed-off-by: Javier Gonzalez Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 15de5f8f3c5d1ea982a4aa270fc10cd78c6682a0 Author: Chao Yu Date: Tue Jan 12 07:49:16 2016 +0100 lightnvm: fix incorrect nr_free_blocks stat [ Upstream commit bdded1552085b12d23c9be76147d2e96647a098f ] When initing bad block list in gennvm_block_bb, once we move bad block from free_list to bb_list, we should maintain both stat info nr_free_blocks and nr_bad_blocks. So this patch fixes to add missing operation related to nr_free_blocks. Signed-off-by: Chao Yu Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cf48dc15f10a8524c37dd0a7f2821b3123d54744 Author: Wenwei Tao Date: Tue Jan 12 07:49:15 2016 +0100 lightnvm: fix bio submission issue [ Upstream commit 3cd485b1f8e25a6534eb4c542e7eba1b944fbaaf ] Put bio when submission fails, since we get it before submission. And return error when backend device driver doesn't provide a submit_io method, thus we can end IO properly. Signed-off-by: Wenwei Tao Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit edf9459008c299d90abc5c7a045d167e5f46f68c Author: Dan Carpenter Date: Wed Dec 2 17:26:28 2015 -0600 cxlflash: a couple off by one bugs [ Upstream commit e37390bee6fe7dfbe507a9d50cdc11344b53fa08 ] The "> MAX_CONTEXT" should be ">= MAX_CONTEXT". Otherwise we go one step beyond the end of the cfg->ctx_tbl[] array. Signed-off-by: Dan Carpenter Reviewed-by: Manoj Kumar Reviewed-by: Johannes Thumshirn Acked-by: Matthew R. Ochs Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit acafdb31f521b6728f865646612e6fb5e605fe97 Author: Alexander Duyck Date: Tue Oct 27 16:59:18 2015 -0700 fm10k: Cleanup exception handling for mailbox interrupt [ Upstream commit e00e23bceba48a8f0c94fefe26948404cbd43d0a ] This patch addresses two issues. First is the fact that the fm10k_mbx_free_irq was assuming msix_entries was valid and that will not always be the case. As such we need to add a check for if it is NULL. Second is the fact that we weren't freeing the IRQ if the mailbox API returned an error on trying to connect. Signed-off-by: Alexander Duyck Reviewed-by: Bruce Allan Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e0ee2ce51824680b687a73857ef64182bbfd3a14 Author: Alexander Duyck Date: Tue Oct 27 16:59:12 2015 -0700 fm10k: Cleanup MSI-X interrupts in case of failure [ Upstream commit 587731e684dcf3522215194a02357d26b9bc7277 ] If the q_vector allocation fails we should free the resources associated with the MSI-X vector table. Signed-off-by: Alexander Duyck Reviewed-by: Bruce Allan Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6628b26348d9338571b9f024b2bd266a60298442 Author: Jacob Keller Date: Fri Oct 16 10:56:59 2015 -0700 fm10k: reinitialize queuing scheme after calling init_hw [ Upstream commit 875328e4bce696e85edcda3c4b0ec80fd525e3a3 ] The init_hw function may fail, and in the case of VFs, it might change the number of maximum queues available. Thus, for every flow which checks init_hw, we need to ensure that we clear the queue scheme before, and initialize it after. The fm10k_io_slot_reset path will end up triggering a reset so fm10k_reinit needs this change. The fm10k_io_error_detected and fm10k_io_resume also need to properly clear and reinitialize the queue scheme. Signed-off-by: Jacob Keller Reviewed-by: Bruce Allan Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 134d78e9d4625aa237d9e6a516965e753bb02e67 Author: Jacob Keller Date: Fri Oct 16 10:56:58 2015 -0700 fm10k: always check init_hw for errors [ Upstream commit 1343c65f70ee1b1f968a08b30e1836a4e37116cd ] A recent change modified init_hw in some flows the function may fail on VF devices. For example, if a VF doesn't yet own its own queues. However, many callers of init_hw didn't bother to check the error code. Other callers checked but only displayed diagnostic messages without actually handling the consequences. Fix this by (a) always returning and preventing the netdevice from going up, and (b) printing the diagnostic in every flow for consistency. This should resolve an issue where VF drivers would attempt to come up before the PF has finished assigning queues. In addition, change the dmesg output to explicitly show the actual function that failed, instead of combining reset_hw and init_hw into a single check, to help for future debugging. Fixes: 1d568b0f6424 ("fm10k: do not assume VF always has 1 queue") Signed-off-by: Jacob Keller Reviewed-by: Bruce Allan Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 587e0cfdad34aa76d6bafa9151e4afabadbdbfbd Author: Jacob Keller Date: Fri Oct 16 10:56:57 2015 -0700 fm10k: reset max_queues on init_hw_vf failure [ Upstream commit 0e8d5b5975401c83641efd5d4595e6cdbe9e9e2f ] VF drivers must detect how many queues are available. Previously, the driver assumed that each VF has at minimum 1 queue. This assumption is incorrect, since it is possible that the PF has not yet assigned the queues to the VF by the time the VF checks. To resolve this, we added a check first to ensure that the first queue is infact owned by the VF at init_hw_vf time. However, the code flow did not reset hw->mac.max_queues to 0. In some cases, such as during reinit flows, we call init_hw_vf without clearing the previous value of hw->mac.max_queues. Due to this, when init_hw_vf errors out, if its error code is not properly handled the VF driver may still believe it has queues which no longer belong to it. Fix this by clearing the hw->mac.max_queues on exit due to errors. Signed-off-by: Jacob Keller Reviewed-by: Bruce Allan Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 031d16e75c5dbc96cdbfcb1ebd5c60d95d33786d Author: Alexander Duyck Date: Tue Sep 22 14:35:35 2015 -0700 fm10k: Fix handling of NAPI budget when multiple queues are enabled per vector [ Upstream commit 9f872986479b6e0543eb5c615e5f9491bb04e5c1 ] This patch corrects an issue in which the polling routine would increase the budget for Rx to at least 1 per queue if multiple queues were present. This would result in Rx packets being processed when the budget was 0 which is meant to indicate that no Rx can be handled. Signed-off-by: Alexander Duyck Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 199ffa62bf2e6c599f07badf90f996a3f773af77 Author: Jacob Keller Date: Tue Aug 25 13:49:11 2015 -0700 fm10k: Correct MTU for jumbo frames [ Upstream commit 8c7ee6d2cacc7794a91875ef5fd8284b4a900d8c ] Based on hardware testing, the host interface supports up to 15368 bytes as the maximum frame size. To determine the correct MTU, we subtract 8 for the internal switch tag, 14 for the L2 header, and 4 for the appended FCS header, resulting in 15342 bytes of payload for our maximum MTU on jumbo frames. Signed-off-by: Matthew Vick Signed-off-by: Jacob Keller Acked-by: Bruce Allan Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 87a7bea68d32ef961f0d6883feb7a83f45c2a74e Author: Jacob Keller Date: Mon Aug 24 17:27:24 2015 -0700 fm10k: do not assume VF always has 1 queue [ Upstream commit 1340181fe435ccb8ca2f996b8680bd9566860619 ] It is possible that the PF has not yet assigned resources to the VF. Although rare, this could result in the VF attempting to read queues it does not own and result in FUM or THI faults in the PF. To prevent this, check queue 0 before we continue in init_hw_vf. Signed-off-by: Jacob Keller Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4aa1324340dabca412d39ba98de7eabd495af7f0 Author: Loc Ho Date: Thu Nov 19 12:20:30 2015 -0700 clk: xgene: Fix divider with non-zero shift value [ Upstream commit 1382ea631ddddb634850a3795527db0feeff5aaf ] The X-Gene clock driver missed the divider shift operation when set the divider value. Signed-off-by: Loc Ho Fixes: 308964caeebc ("clk: Add APM X-Gene SoC clock driver") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c6210760f2428690255e1fd91cf084b12e827a0a Author: Dmitry Fleytman Date: Tue Oct 13 12:48:18 2015 +0300 e1000e: fix division by zero on jumbo MTUs [ Upstream commit b77ac46bbae862dcb3f51296825c940404c69b0f ] This patch fixes possible division by zero in receive interrupt handler when working without adaptive interrupt moderation. The adaptive interrupt moderation mechanism is typically disabled on jumbo MTUs. Signed-off-by: Dmitry Fleytman Signed-off-by: Leonid Bloch Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit abe2792fab39c606f21a6b4a4dab2d5090723a01 Author: Dmitriy Vyukov Date: Tue Sep 8 10:52:44 2015 +0200 e1000: fix data race between tx_ring->next_to_clean [ Upstream commit 9eab46b7cb8d0b0dcf014bf7b25e0e72b9e4d929 ] e1000_clean_tx_irq cleans buffers and sets tx_ring->next_to_clean, then e1000_xmit_frame reuses the cleaned buffers. But there are no memory barriers when buffers gets recycled, so the recycled buffers can be corrupted. Use smp_store_release to update tx_ring->next_to_clean and smp_load_acquire to read tx_ring->next_to_clean to properly hand off buffers from e1000_clean_tx_irq to e1000_xmit_frame. The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by: Dmitry Vyukov Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5c5989e0dde275bae778d6b4706cf606aca749cc Author: Alexander Duyck Date: Tue Sep 22 14:35:41 2015 -0700 ixgbe: Fix handling of NAPI budget when multiple queues are enabled per vector [ Upstream commit 5d6002b7b822c7423e75d4651e6790bfb5642b1b ] This patch corrects an issue in which the polling routine would increase the budget for Rx to at least 1 per queue if multiple queues were present. This would result in Rx packets being processed when the budget was 0 which is meant to indicate that no Rx can be handled. Signed-off-by: Alexander Duyck Tested-by: Darin Miller Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fe52e1255397ac4a1233db10e8f651847f992a4b Author: Jan Beulich Date: Mon Oct 19 04:23:29 2015 -0600 igb: fix NULL derefs due to skipped SR-IOV enabling [ Upstream commit be06998f96ecb93938ad2cce46c4289bf7cf45bc ] The combined effect of commits 6423fc3416 ("igb: do not re-init SR-IOV during probe") and ceee3450b3 ("igb: make sure SR-IOV init uses the right number of queues") causes VFs no longer getting set up, leading to NULL pointer dereferences due to the adapter's ->vf_data being NULL while ->vfs_allocated_count is non-zero. The first commit not only neglected the side effect of igb_sriov_reinit() that the second commit tried to account for, but also that of setting IGB_FLAG_HAS_MSIX, without which igb_enable_sriov() is effectively a no-op. Calling igb_{,re}set_interrupt_capability() as done here seems to address this, but I'm not sure whether this is better than sinply reverting the other two commits. Signed-off-by: Jan Beulich Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1231f5a2e59477f896c69d3ed66d9efde20603ba Author: Todd Fujinaka Date: Fri Sep 18 15:43:51 2015 -0700 igb: use the correct i210 register for EEMNGCTL [ Upstream commit 08c991297582114a6e1220f913eec91789c4eac6 ] The i210 has two EEPROM access registers that are located in non-standard offsets: EEARBC and EEMNGCTL. EEARBC was fixed previously and EEMNGCTL should also be corrected. Reported-by: Roman Hodek Signed-off-by: Todd Fujinaka Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d5463792a1c1bd788aca2024f96e3136c875c01d Author: Jarod Wilson Date: Thu Sep 10 15:37:50 2015 -0400 igb: don't unmap NULL hw_addr [ Upstream commit 73bf8048d7c86a20a59d427e55deb1a778e94df7 ] I've got a startech thunderbolt dock someone loaned me, which among other things, has the following device in it: 08:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) This hotplugs just fine (kernel 4.2.0 plus a patch or two here): [ 863.020315] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.18-k [ 863.020316] igb: Copyright (c) 2007-2014 Intel Corporation. [ 863.028657] igb 0000:08:00.0: enabling device (0000 -> 0002) [ 863.062089] igb 0000:08:00.0: added PHC on eth0 [ 863.062090] igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network Connection [ 863.062091] igb 0000:08:00.0: eth0: (PCIe:2.5Gb/s:Width x1) e8:ea:6a:00:1b:2a [ 863.062194] igb 0000:08:00.0: eth0: PBA No: 000200-000 [ 863.062196] igb 0000:08:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s) [ 863.064889] igb 0000:08:00.0 enp8s0: renamed from eth0 But disconnecting it is another story: [ 1002.807932] igb 0000:08:00.0: removed PHC on enp8s0 [ 1002.807944] igb 0000:08:00.0 enp8s0: PCIe link lost, device now detached [ 1003.341141] ------------[ cut here ]------------ [ 1003.341148] WARNING: CPU: 0 PID: 199 at lib/iomap.c:43 bad_io_access+0x38/0x40() [ 1003.341149] Bad IO access at port 0x0 () [ 1003.342767] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi igb dca firewire_ohci firewire_core crc_itu_t rfcomm ctr ccm arc4 iwlmvm mac80211 fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 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 iptable_filter bnep dm_mirror dm_region_hash dm_log dm_mod coretemp x86_pkg_temp_thermal intel_powerclamp kvm_intel snd_hda_codec_hdmi kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg [ 1003.342793] ansi_cprng aesni_intel hp_wmi aes_x86_64 iTCO_wdt lrw iTCO_vendor_support ppdev gf128mul sparse_keymap glue_helper ablk_helper cryptd snd_hda_codec_realtek snd_hda_codec_generic microcode snd_hda_intel uvcvideo iwlwifi snd_hda_codec videobuf2_vmalloc videobuf2_memops snd_hda_core videobuf2_core snd_hwdep btusb v4l2_common btrtl snd_seq btbcm btintel videodev cfg80211 snd_seq_device rtsx_pci_ms bluetooth pcspkr input_leds i2c_i801 media parport_pc memstick rfkill sg lpc_ich snd_pcm 8250_fintek parport joydev snd_timer snd soundcore hp_accel ie31200_edac mei_me lis3lv02d edac_core input_polldev mei hp_wireless shpchp tpm_infineon sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables autofs4 xfs libcrc32c sd_mod sr_mod cdrom rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci [ 1003.342822] nouveau ahci libahci mxm_wmi e1000e xhci_pci hwmon ptp drm_kms_helper pps_core xhci_hcd ttm wmi video ipv6 [ 1003.342839] CPU: 0 PID: 199 Comm: kworker/0:2 Not tainted 4.2.0-2.el7_UNSUPPORTED.x86_64 #1 [ 1003.342840] Hardware name: Hewlett-Packard HP ZBook 15 G2/2253, BIOS M70 Ver. 01.07 02/26/2015 [ 1003.342843] Workqueue: pciehp-3 pciehp_power_thread [ 1003.342844] ffffffff81a90655 ffff8804866d3b48 ffffffff8164763a 0000000000000000 [ 1003.342846] ffff8804866d3b98 ffff8804866d3b88 ffffffff8107134a ffff8804866d3b88 [ 1003.342847] ffff880486f46000 ffff88046c8a8000 ffff880486f46840 ffff88046c8a8098 [ 1003.342848] Call Trace: [ 1003.342852] [] dump_stack+0x45/0x57 [ 1003.342855] [] warn_slowpath_common+0x8a/0xc0 [ 1003.342857] [] warn_slowpath_fmt+0x46/0x50 [ 1003.342859] [] ? pci_disable_msix+0x3e/0x50 [ 1003.342860] [] bad_io_access+0x38/0x40 [ 1003.342861] [] pci_iounmap+0x27/0x40 [ 1003.342865] [] igb_remove+0xc7/0x160 [igb] [ 1003.342867] [] pci_device_remove+0x3f/0xc0 [ 1003.342869] [] __device_release_driver+0x96/0x130 [ 1003.342870] [] device_release_driver+0x23/0x30 [ 1003.342871] [] pci_stop_bus_device+0x94/0xa0 [ 1003.342872] [] pci_stop_bus_device+0x3d/0xa0 [ 1003.342873] [] pci_stop_bus_device+0x3d/0xa0 [ 1003.342874] [] pci_stop_and_remove_bus_device+0x16/0x30 [ 1003.342876] [] pciehp_unconfigure_device+0x9b/0x180 [ 1003.342877] [] pciehp_disable_slot+0x43/0xb0 [ 1003.342878] [] pciehp_power_thread+0x8d/0xb0 [ 1003.342885] [] process_one_work+0x152/0x3d0 [ 1003.342886] [] worker_thread+0x11a/0x460 [ 1003.342887] [] ? process_one_work+0x3d0/0x3d0 [ 1003.342890] [] kthread+0xc9/0xe0 [ 1003.342891] [] ? kthread_create_on_node+0x180/0x180 [ 1003.342893] [] ret_from_fork+0x3f/0x70 [ 1003.342894] [] ? kthread_create_on_node+0x180/0x180 [ 1003.342895] ---[ end trace 65a77e06d5aa9358 ]--- Upon looking at the igb driver, I see that igb_rd32() attempted to read from hw_addr and failed, so it set hw->hw_addr to NULL and spit out the message in the log output above, "PCIe link lost, device now detached". Well, now that hw_addr is NULL, the attempt to call pci_iounmap is obviously not going to go well. As suggested by Mark Rustad, do something similar to what ixgbe does, and save a copy of hw_addr as adapter->io_addr, so we can still call pci_iounmap on it on teardown. Additionally, for consistency, make the pci_iomap call assignment directly to io_addr, so map and unmap match. Signed-off-by: Jarod Wilson Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b909cfc8722a7ed3eb3c881a9ed96ba0f0c42fbe Author: Anjali Singhai Jain Date: Wed Dec 9 15:50:21 2015 -0800 i40e: Fix Rx hash reported to the stack by our driver [ Upstream commit 857942fd1aa15edf7356a4a4bad5369c8e70a633 ] If the driver calls skb_set_hash even with a zero hash, that indicates to the stack that the hash calculation is offloaded in hardware. So the Stack doesn't do a SW hash which is required for load balancing if the user decides to turn of rx-hashing on our device. This patch fixes the path so that we do not call skb_set_hash if the feature is disabled. Change-ID: Ic4debfa4ff91b5a72e447348a75768ed7a2d3e1b Signed-off-by: Anjali Singhai Jain Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 42622b1b7a5211f046ab6d56f67e156d05019c10 Author: Shannon Nelson Date: Thu Nov 19 11:34:23 2015 -0800 i40e: clean whole mac filter list [ Upstream commit f11999987bc0b5559ab56dedc6f4ca32fab5438a ] Clean the whole mac filter list when resetting after an intermediate add or delete push to the firmware. The code had evolved from using a list from the stack to a heap allocation, but the memset() didn't follow the change correctly. This now cleans the whole list rather that just part of the first element. Change-ID: I4cd03d5a103b7407dd8556a3a231e800f2d6f2d5 Reported-by: Rasmus Villemoes Signed-off-by: Shannon Nelson Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0af31973b5fd298a52e9429751be5e4bade42a83 Author: Mitch Williams Date: Thu Nov 19 11:34:18 2015 -0800 i40evf: check rings before freeing resources [ Upstream commit fdb47ae87af537b24977a03bc69cfe1c5c55ca62 ] If the driver gets unloaded during reset recovery, it's possible that it will attempt to free resources when they're already free. Add a check to make sure that the Tx and Rx rings actually exist before dereferencing them to free resources. Change-ID: I4d2b7e9ede49f634d421a4c5deaa5446bc755eee Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 796adc8527c3ce901bd813816ac0ec9ab212ee81 Author: Mitch Williams Date: Thu Nov 19 11:34:17 2015 -0800 i40e: don't add zero MAC filter [ Upstream commit b7b713a8eaf325607d37229f024ad0b9f3e7f320 ] When VFs are created, the MAC address defaults to all zeros, indicating to the VF driver that it should use a random MAC address. However, the PF driver was incorrectly adding this zero MAC to the filter table, along with the VF's randomly generated MAC address. Check for a good address before adding the default filter. While we're at it, make the error message a bit more useful. Change-ID: Ia100947d68140e0f73a19ba755cbffc3e79a8fcf Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b085e4dd706156b5fe7322b9dc6cf80dedc53a78 Author: Mitch Williams Date: Thu Nov 19 11:34:16 2015 -0800 i40e: properly delete VF MAC filters [ Upstream commit b36e9ab59b7e3a5b14bf88dc0536e6579db7b54d ] The virtual channel interface was using incorrect semantics to remove MAC addresses, which would leave incorrect filters active when using VLANs. To correct this, add a new function that unconditionally removes MAC addresses from all VLANs, and call this function when the VF requests a MAC filter removal. Change-ID: I69826908ae4f6c847f5bf9b32f11faa760189c74 Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3a87d06fb95e9d8ec3f87edc9383cc3538cd598a Author: Kiran Patil Date: Fri Nov 6 15:26:03 2015 -0800 i40e: Fix memory leaks, sideband filter programming [ Upstream commit a42e7a369ea2b73a554a85dea7d6243af51cd4f0 ] This patch fixes the memory leak which would be seen otherwise when user programs flow-director filter using ethtool (sideband filter programming). When ethtool is used to program flow directory filter, 'raw_buf' gets allocated and it is supposed to be freed as part of queue cleanup. But check of 'tx_buffer->skb' was preventing it from being freed. Change-ID: Ief4f0a1a32a653180498bf6e987c1b4342ab8923 Signed-off-by: Kiran Patil Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit be98bdf8c42915677fc8460fbb376b0bfee1de28 Author: Jesse Brandeburg Date: Thu Nov 5 17:01:01 2015 -0800 i40e: fix: do not sleep in netdev_ops [ Upstream commit 0e4425ed641f3eef67c892bc541949cd745a9ba9 ] The driver was being called by VLAN, bonding, teaming operations that expected to be able to hold locks like rcu_read_lock(). This causes the driver to be held to the requirement to not sleep, and was found by the kernel debug options for checking sleep inside critical section, and the locking validator. Change-ID: Ibc68c835f5ffa8ffe0638ffe910a66fc5649a7f7 Signed-off-by: Jesse Brandeburg Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f36bb42d19d9914afb71a422a29fdbc44f22a037 Author: Anjali Singhai Jain Date: Mon Oct 26 19:44:29 2015 -0400 i40e/i40evf: Fix RS bit update in Tx path and disable force WB workaround [ Upstream commit 6a7fded776a778f728b13d83a2c9fc893580c080 ] This patch fixes the issue of forcing WB too often causing us to not benefit from NAPI. Without this patch we were forcing WB/arming interrupt too often taking away the benefits of NAPI and causing a performance impact. With this patch we disable force WB in the clean routine for X710 and XL710 adapters. X722 adapters do not enable interrupt to force a WB and benefit from WB_ON_ITR and hence force WB is left enabled for those adapters. For XL710 and X710 adapters if we have less than 4 packets pending a software Interrupt triggered from service task will force a WB. This patch also changes the conditions for setting RS bit as described in code comments. This optimizes when the HW does a tail bump amd when it does a WB. It also optimizes when we do a wmb. Change-ID: Id831e1ae7d3e2ec3f52cd0917b41ce1d22d75d9d Signed-off-by: Anjali Singhai Jain Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 355528ece5de4764f61221732b49d53cd51f72f6 Author: Mitch Williams Date: Wed Oct 21 19:47:12 2015 -0400 i40evf: handle many MAC filters correctly [ Upstream commit 1418c3458118c6969d08e23aa377da7e2a7be36c ] When a lot (many hundreds) of MAC or VLAN filters are added at one time, we can overflow the Admin Queue buffer size with all the requests. Unfortunately, the driver would then calculate the message size incorrectly, causing it to be rejected by the PF. Furthermore, there was no mechanism to trigger another request to allow for configuring the rest of the filters that didn't fit into the first request. To fix this, recalculate the correct buffer size when we detect the overflow condition instead of just assuming the max buffer size. Also, don't clear the request bit in adapter->aq_required when we have an overflow, so that the rest of the filters can be processed later. Change-ID: Idd7cbbc5af31315e0dcb1b10e6a02ad9817ce65c Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 410d31b9ffca731afcf2b62872fed27bbdc892d4 Author: Anjali Singhai Jain Date: Wed Oct 21 19:47:07 2015 -0400 i40e: Workaround fix for mss < 256 issue [ Upstream commit 4f2f017c6101ab2ba202d6059c238c15577ad38b ] HW/NVM sets a limit of no less than 256 bytes for MSS. Stack can send as low as 76 bytes MSS. This patch lowers the HW limit to 64 bytes to avoid MDDs from firing and causing a reset when the MSS is lower than 256. Change-ID: I36b500a6bb227d283c3e321a7718e0672b11fab0 Signed-off-by: Anjali Singhai Jain Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman