commit f154a14e3efa547025d014d0a3f29396f03b1f74 Author: Sasha Levin Date: Fri Apr 3 22:46:37 2015 -0400 Linux 3.18.11 Signed-off-by: Sasha Levin commit 4c23efb4e6213c51c9343319a6c3803040b0af1f Author: Nicholas Bellinger Date: Fri Feb 27 03:54:13 2015 -0800 target/pscsi: Fix NULL pointer dereference in get_device_type [ Upstream commit 215a8fe4198f607f34ecdbc9969dae783d8b5a61 ] This patch fixes a NULL pointer dereference OOPs with pSCSI backends within target_core_stat.c code. The bug is caused by a configfs attr read if no pscsi_dev_virt->pdv_sd has been configured. Reported-by: Olaf Hering Cc: Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit af8524b010eb5fc2ce7df2533f4257d3d46d4d91 Author: Nicholas Bellinger Date: Mon Feb 23 00:57:51 2015 -0800 iscsi-target: Avoid early conn_logout_comp for iser connections [ Upstream commit f068fbc82e7696d67b1bb8189306865bedf368b6 ] This patch fixes a iser specific logout bug where early complete() of conn->conn_logout_comp in iscsit_close_connection() was causing isert_wait4logout() to complete too soon, triggering a use after free NULL pointer dereference of iscsi_conn memory. The complete() was originally added for traditional iscsi-target when a ISCSI_LOGOUT_OP failed in iscsi_target_rx_opcode(), but given iser-target does not wait in logout failure, this special case needs to be avoided. Reported-by: Sagi Grimberg Cc: Sagi Grimberg Cc: Slava Shwartsman Cc: # v3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit b54521a3bfe9970502be05efadda60b4ce6dab07 Author: Nicholas Bellinger Date: Thu Mar 5 03:28:24 2015 +0000 target: Fix virtual LUN=0 target_configure_device failure OOPs [ Upstream commit 5f7da044f8bc1cfb21c962edf34bd5699a76e7ae ] This patch fixes a NULL pointer dereference triggered by a late target_configure_device() -> alloc_workqueue() failure that results in target_free_device() being called with DF_CONFIGURED already set, which subsequently OOPses in destroy_workqueue() code. Currently this only happens at modprobe target_core_mod time when core_dev_setup_virtual_lun0() -> target_configure_device() fails, and the explicit target_free_device() gets called. To address this bug originally introduced by commit 0fd97ccf45, go ahead and move DF_CONFIGURED to end of target_configure_device() code to handle this special failure case. Reported-by: Claudio Fleiner Cc: Claudio Fleiner Cc: Christoph Hellwig Cc: # v3.7+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 6526d32f6b0b0bb8fd024580f91a32e2737fae57 Author: Bart Van Assche Date: Wed Feb 18 15:33:58 2015 +0100 target: Fix reference leak in target_get_sess_cmd() error path [ Upstream commit 7544e597343e2166daba3f32e4708533aa53c233 ] This patch fixes a se_cmd->cmd_kref leak buf when se_sess->sess_tearing_down is true within target_get_sess_cmd() submission path code. This se_cmd reference leak can occur during active session shutdown when ack_kref=1 is passed by target_submit_cmd_[map_sgls,tmr]() callers. Signed-off-by: Bart Van Assche Cc: # 3.6+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 5ef7008ba150150e591b27f78f0fca2d3d9ebae2 Author: Vignesh R Date: Tue Feb 10 11:05:42 2015 +0530 ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx [ Upstream commit 7d53d25578486d65bd7cd242bc7816b40e55e62b ] ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck. The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the functional clock of pwmss (l4ls_gclk). Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk. Fixes: 4da1c67719f61 ("add tbclk data for ehrpwm") Signed-off-by: Vignesh R Acked-by: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 25d96d6b6b564b38cff97571ef59fc8ab60b1e14 Author: Vignesh R Date: Tue Feb 10 11:05:41 2015 +0530 ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx [ Upstream commit 6e22616eba7e25fac5aa6cb6563471afa1815ec2 ] ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck. The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the functional clock of pwmss (l4ls_gclk). Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk. Fixes: 9e100ebafb91: ("Fix ehrpwm tbclk data") Signed-off-by: Vignesh R Acked-by: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 0755481749d00370f271026b346457f2c8055d51 Author: Ravikumar Kattekola Date: Sat Jan 31 22:36:44 2015 +0530 ARM: dts: DRA7x: Fix the bypass clock source for dpll_iva and others [ Upstream commit d2192ea09858a8535b056fcede1a41d824e0b3d8 ] Fixes: ee6c750761 (ARM: dts: dra7 clock data) On DRA7x, For DPLL_IVA, the ref clock(CLKINP) is connected to sys_clk1 and the bypass input(CLKINPULOW) is connected to iva_dpll_hs_clk_div clock. But the bypass input is not directly routed to bypass clkout instead both CLKINP and CLKINPULOW are connected to bypass clkout via a mux. This mux is controlled by the bit - CM_CLKSEL_DPLL_IVA[23]:DPLL_BYP_CLKSEL and it's POR value is zero which selects the CLKINP as bypass clkout. which means iva_dpll_hs_clk_div is not the bypass clock for dpll_iva_ck Fix this by adding another mux clock as parent in bypass mode. This design is common to most of the PLLs and the rest have only one bypass clock. Below is a list of the DPLLs that need this fix: DPLL_IVA, DPLL_DDR, DPLL_DSP, DPLL_EVE, DPLL_GMAC, DPLL_PER, DPLL_USB and DPLL_CORE Signed-off-by: Ravikumar Kattekola Acked-by: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit d409e2e69474187acf9e10e78f2baac00e84ef9a Author: Alexandre Belloni Date: Tue Mar 3 19:58:22 2015 +0100 ARM: at91: pm: fix at91rm9200 standby [ Upstream commit 84e871660bebfddb9a62ebd6f19d02536e782f0a ] at91rm9200 standby and suspend to ram has been broken since 00482a4078f4. It is wrongly using AT91_BASE_SYS which is a physical address and actually doesn't correspond to any register on at91rm9200. Use the correct at91_ramc_base[0] instead. Fixes: 00482a4078f4 (ARM: at91: implement the standby function for pm/cpuidle) Signed-off-by: Alexandre Belloni Signed-off-by: Nicolas Ferre Signed-off-by: Sasha Levin commit 1e29f16a9b6a09aebd57418bc289998ae3085e1b Author: Peter Chen Date: Fri Mar 6 16:04:20 2015 +0800 ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg [ Upstream commit 40f737791d4dab26bf23a6331609c604142228bd ] USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's parent reg, it fixed a bug that the voltage of vbus is incorrect due to swbst_reg is disabled after boots up. Cc: stable@vger.kernel.org Signed-off-by: Peter Chen Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit f8ac6343a34f407b237a7b7924f2182a1ddb7216 Author: Daniel J Blueman Date: Tue Nov 4 16:29:41 2014 +0800 x86: numachip: Fix 16-bit APIC ID truncation [ Upstream commit 00e7977dd1bbd46e336d7ef907d0fb6b6a4c294f ] Prevent 16-bit APIC IDs being truncated by using correct mask. This fixes booting large systems, where the wrong core would receive the startup and init IPIs, causing hanging. Signed-off-by: Daniel J Blueman Cc: Steffen Persvold Cc: Bjorn Helgaas Link: http://lkml.kernel.org/r/1415089784-28779-1-git-send-email-daniel@numascale.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit ad927769865b3e162266faf215918d4f83f7bb84 Author: Jiri Slaby Date: Thu Mar 5 09:13:31 2015 +0100 x86/vdso: Fix the build on GCC5 [ Upstream commit e893286918d2cde3a94850d8f7101cd1039e0c62 ] On gcc5 the kernel does not link: ld: .eh_frame_hdr table[4] FDE at 0000000000000648 overlaps table[5] FDE at 0000000000000670. Because prior GCC versions always emitted NOPs on ALIGN directives, but gcc5 started omitting them. .LSTARTFDEDLSI1 says: /* HACK: The dwarf2 unwind routines will subtract 1 from the return address to get an address in the middle of the presumed call instruction. Since we didn't get here via a call, we need to include the nop before the real start to make up for it. */ .long .LSTART_sigreturn-1-. /* PC-relative start address */ But commit 69d0627a7f6e ("x86 vDSO: reorder vdso32 code") from 2.6.25 replaced .org __kernel_vsyscall+32,0x90 by ALIGN right before __kernel_sigreturn. Of course, ALIGN need not generate any NOP in there. Esp. gcc5 collapses vclock_gettime.o and int80.o together with no generated NOPs as "ALIGN". So fix this by adding to that point at least a single NOP and make the function ALIGN possibly with more NOPs then. Kudos for reporting and diagnosing should go to Richard. Reported-by: Richard Biener Signed-off-by: Jiri Slaby Acked-by: Andy Lutomirski Cc: Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1425543211-12542-1-git-send-email-jslaby@suse.cz Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 9ab9ee7a87bbea7b4719e0445bcda2d7f0b7d197 Author: Paolo Bonzini Date: Thu Mar 5 11:54:46 2015 +0100 kvm: move advertising of KVM_CAP_IRQFD to common code [ Upstream commit dc9be0fac70a2ad86e31a81372bb0bdfb6945353 ] POWER supports irqfds but forgot to advertise them. Some userspace does not check for the capability, but others check it---thus they work on x86 and s390 but not POWER. To avoid that other architectures in the future make the same mistake, let common code handle KVM_CAP_IRQFD the same way as KVM_CAP_IRQFD_RESAMPLE. Reported-and-tested-by: Greg Kurz Cc: stable@vger.kernel.org Fixes: 297e21053a52f060944e9f0de4c64fad9bcd72fc Signed-off-by: Paolo Bonzini Signed-off-by: Marcelo Tosatti Signed-off-by: Sasha Levin commit 1b6bd91982a1f8b67684a1886dea0373c26e73c2 Author: Oleg Nesterov Date: Fri Mar 13 09:53:10 2015 +0100 x86/fpu: Drop_fpu() should not assume that tsk equals current [ Upstream commit f4c3686386393c120710dd34df2a74183ab805fd ] drop_fpu() does clear_used_math() and usually this is correct because tsk == current. However switch_fpu_finish()->restore_fpu_checking() is called before __switch_to() updates the "current_task" variable. If it fails, we will wrongly clear the PF_USED_MATH flag of the previous task. So use clear_stopped_child_used_math() instead. Signed-off-by: Oleg Nesterov Signed-off-by: Borislav Petkov Reviewed-by: Rik van Riel Cc: Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: Fenghua Yu Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Pekka Riikonen Cc: Quentin Casasnovas Cc: Suresh Siddha Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20150309171041.GB11388@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 1a29c27a0feda99289ddc41cb5dfbe010d37d374 Author: Oleg Nesterov Date: Fri Mar 13 09:53:09 2015 +0100 x86/fpu: Avoid math_state_restore() without used_math() in __restore_xstate_sig() [ Upstream commit a7c80ebcac3068b1c3cb27d538d29558c30010c8 ] math_state_restore() assumes it is called with irqs disabled, but this is not true if the caller is __restore_xstate_sig(). This means that if ia32_fxstate == T and __copy_from_user() fails, __restore_xstate_sig() returns with irqs disabled too. This triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41 dump_stack ___might_sleep ? _raw_spin_unlock_irqrestore __might_sleep down_read ? _raw_spin_unlock_irqrestore print_vma_addr signal_fault sys32_rt_sigreturn Change __restore_xstate_sig() to call set_used_math() unconditionally. This avoids enabling and disabling interrupts in math_state_restore(). If copy_from_user() fails, we can simply do fpu_finit() by hand. [ Note: this is only the first step. math_state_restore() should not check used_math(), it should set this flag. While init_fpu() should simply die. ] Signed-off-by: Oleg Nesterov Signed-off-by: Borislav Petkov Cc: Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: Fenghua Yu Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Pekka Riikonen Cc: Quentin Casasnovas Cc: Rik van Riel Cc: Suresh Siddha Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20150307153844.GB25954@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 3b389956156c23d7936f5a863cf7ac18a92dfee1 Author: Stephan Mueller Date: Thu Mar 12 09:17:51 2015 +0100 crypto: aesni - fix memory usage in GCM decryption [ Upstream commit ccfe8c3f7e52ae83155cb038753f4c75b774ca8a ] The kernel crypto API logic requires the caller to provide the length of (ciphertext || authentication tag) as cryptlen for the AEAD decryption operation. Thus, the cipher implementation must calculate the size of the plaintext output itself and cannot simply use cryptlen. The RFC4106 GCM decryption operation tries to overwrite cryptlen memory in req->dst. As the destination buffer for decryption only needs to hold the plaintext memory but cryptlen references the input buffer holding (ciphertext || authentication tag), the assumption of the destination buffer length in RFC4106 GCM operation leads to a too large size. This patch simply uses the already calculated plaintext size. In addition, this patch fixes the offset calculation of the AAD buffer pointer: as mentioned before, cryptlen already includes the size of the tag. Thus, the tag does not need to be added. With the addition, the AAD will be written beyond the already allocated buffer. Note, this fixes a kernel crash that can be triggered from user space via AF_ALG(aead) -- simply use the libkcapi test application from [1] and update it to use rfc4106-gcm-aes. Using [1], the changes were tested using CAVS vectors to demonstrate that the crypto operation still delivers the right results. [1] http://www.chronox.de/libkcapi.html CC: Tadeusz Struk Cc: stable@vger.kernel.org Signed-off-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 73a115c5406d04de7597a5d4a21a883e6596ee1b Author: Ard Biesheuvel Date: Thu Feb 26 07:22:05 2015 +0000 crypto: arm/aes update NEON AES module to latest OpenSSL version [ Upstream commit 001eabfd54c0cbf9d7d16264ddc8cc0bee67e3ed ] This updates the bit sliced AES module to the latest version in the upstream OpenSSL repository (e620e5ae37bc). This is needed to fix a bug in the XTS decryption path, where data chunked in a certain way could trigger the ciphertext stealing code, which is not supposed to be active in the kernel build (The kernel implementation of XTS only supports round multiples of the AES block size of 16 bytes, whereas the conformant OpenSSL implementation of XTS supports inputs of arbitrary size by applying ciphertext stealing). This is fixed in the upstream version by adding the missing #ifndef XTS_CHAIN_TWEAK around the offending instructions. The upstream code also contains the change applied by Russell to build the code unconditionally, i.e., even if __LINUX_ARM_ARCH__ < 7, but implemented slightly differently. Cc: stable@vger.kernel.org Fixes: e4e7f10bfc40 ("ARM: add support for bit sliced AES using NEON instructions") Reported-by: Adrian Kotelba Signed-off-by: Ard Biesheuvel Tested-by: Milan Broz Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1cd3d374b25ba7e9934be66781ff7fc4513a2b09 Author: Kirill A. Shutemov Date: Mon Mar 9 23:11:12 2015 +0200 pagemap: do not leak physical addresses to non-privileged userspace [ Upstream commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce ] As pointed by recent post[1] on exploiting DRAM physical imperfection, /proc/PID/pagemap exposes sensitive information which can be used to do attacks. This disallows anybody without CAP_SYS_ADMIN to read the pagemap. [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html [ Eventually we might want to do anything more finegrained, but for now this is the simple model. - Linus ] Signed-off-by: Kirill A. Shutemov Acked-by: Konstantin Khlebnikov Acked-by: Andy Lutomirski Cc: Pavel Emelyanov Cc: Andrew Morton Cc: Mark Seaborn Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 016958bf0577daa731bf0fc84aaa8a47d2dd705d Author: Maxime Ripard Date: Tue Mar 3 11:27:23 2015 +0100 irqchip: armada-370-xp: Fix chained per-cpu interrupts [ Upstream commit 5724be8464dceac047c1eaddaa3651cea0ec16ca ] On the Cortex-A9-based Armada SoCs, the MPIC is not the primary interrupt controller. Yet, it still has to handle some per-cpu interrupt. To do so, it is chained with the GIC using a per-cpu interrupt. However, the current code only call irq_set_chained_handler, which is called and enable that interrupt only on the boot CPU, which means that the parent per-CPU interrupt is never unmasked on the secondary CPUs, preventing the per-CPU interrupt to actually work as expected. This was not seen until now since the only MPIC PPI users were the Marvell timers that were not working, but not used either since the system use the ARM TWD by default, and the ethernet controllers, that are faking there interrupts as SPI, and don't really expect to have interrupts on the secondary cores anyway. Add a CPU notifier that will enable the PPI on the secondary cores when they are brought up. Cc: # 3.15+ Signed-off-by: Maxime Ripard Acked-by: Gregory CLEMENT Link: https://lkml.kernel.org/r/1425378443-28822-1-git-send-email-maxime.ripard@free-electrons.com Signed-off-by: Jason Cooper Signed-off-by: Sasha Levin commit a10f28903b99b7a5fbc08dccaf2578e43a9706d5 Author: Sasha Levin Date: Wed Feb 4 17:38:15 2015 -0500 PCI: Don't read past the end of sysfs "driver_override" buffer [ Upstream commit 4efe874aace57dba967624ce1c48322da2447b75 ] When printing the driver_override parameter when it is 4095 and 4094 bytes long, the printing code would access invalid memory because we need count+1 bytes for printing. Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override") Signed-off-by: Sasha Levin Signed-off-by: Bjorn Helgaas Acked-by: Alex Williamson CC: stable@vger.kernel.org # v3.16+ CC: Konrad Rzeszutek Wilk CC: Alexander Graf CC: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 89410138b43635c192850048df715c2862f02695 Author: James Bottomley Date: Wed Mar 4 16:18:33 2015 -0800 libsas: Fix Kernel Crash in smp_execute_task [ Upstream commit 6302ce4d80aa82b3fdb5c5cd68e7268037091b47 ] This crash was reported: [ 366.947370] sd 3:0:1:0: [sdb] Spinning up disk.... [ 368.804046] BUG: unable to handle kernel NULL pointer dereference at (null) [ 368.804072] IP: [] __mutex_lock_common.isra.7+0x9c/0x15b [ 368.804098] PGD 0 [ 368.804114] Oops: 0002 [#1] SMP [ 368.804143] CPU 1 [ 368.804151] Modules linked in: sg netconsole s3g(PO) uinput joydev hid_multitouch usbhid hid snd_hda_codec_via cpufreq_userspace cpufreq_powersave cpufreq_stats uhci_hcd cpufreq_conservative snd_hda_intel snd_hda_codec snd_hwdep snd_pcm sdhci_pci snd_page_alloc sdhci snd_timer snd psmouse evdev serio_raw pcspkr soundcore xhci_hcd shpchp s3g_drm(O) mvsas mmc_core ahci libahci drm i2c_core acpi_cpufreq mperf video processor button thermal_sys dm_dmirror exfat_fs exfat_core dm_zcache dm_mod padlock_aes aes_generic padlock_sha iscsi_target_mod target_core_mod configfs sswipe libsas libata scsi_transport_sas picdev via_cputemp hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif usb_storage scsi_mod ehci_hcd usbcore usb_common [ 368.804749] [ 368.804764] Pid: 392, comm: kworker/u:3 Tainted: P W O 3.4.87-logicube-ng.22 #1 To be filled by O.E.M. To be filled by O.E.M./EPIA-M920 [ 368.804802] RIP: 0010:[] [] __mutex_lock_common.isra.7+0x9c/0x15b [ 368.804827] RSP: 0018:ffff880117001cc0 EFLAGS: 00010246 [ 368.804842] RAX: 0000000000000000 RBX: ffff8801185030d0 RCX: ffff88008edcb420 [ 368.804857] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8801185030d4 [ 368.804873] RBP: ffff8801181531c0 R08: 0000000000000020 R09: 00000000fffffffe [ 368.804885] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801185030d4 [ 368.804899] R13: 0000000000000002 R14: ffff880117001fd8 R15: ffff8801185030d8 [ 368.804916] FS: 0000000000000000(0000) GS:ffff88011fc80000(0000) knlGS:0000000000000000 [ 368.804931] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 368.804946] CR2: 0000000000000000 CR3: 000000000160b000 CR4: 00000000000006e0 [ 368.804962] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 368.804978] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 368.804995] Process kworker/u:3 (pid: 392, threadinfo ffff880117000000, task ffff8801181531c0) [ 368.805009] Stack: [ 368.805017] ffff8801185030d8 0000000000000000 ffffffff8161ddf0 ffffffff81056f7c [ 368.805062] 000000000000b503 ffff8801185030d0 ffff880118503000 0000000000000000 [ 368.805100] ffff8801185030d0 ffff8801188b8000 ffff88008edcb420 ffffffff813583ac [ 368.805135] Call Trace: [ 368.805153] [] ? up+0xb/0x33 [ 368.805168] [] ? mutex_lock+0x16/0x25 [ 368.805194] [] ? smp_execute_task+0x4e/0x222 [libsas] [ 368.805217] [] ? sas_find_bcast_dev+0x3c/0x15d [libsas] [ 368.805240] [] ? sas_find_bcast_dev+0x6f/0x15d [libsas] [ 368.805264] [] ? sas_ex_revalidate_domain+0x37/0x2ec [libsas] [ 368.805280] [] ? printk+0x43/0x48 [ 368.805296] [] ? _raw_spin_unlock_irqrestore+0xc/0xd [ 368.805318] [] ? sas_revalidate_domain+0x85/0xb6 [libsas] [ 368.805336] [] ? process_one_work+0x151/0x27c [ 368.805351] [] ? worker_thread+0xbb/0x152 [ 368.805366] [] ? manage_workers.isra.29+0x163/0x163 [ 368.805382] [] ? kthread+0x79/0x81 [ 368.805399] [] ? kernel_thread_helper+0x4/0x10 [ 368.805416] [] ? kthread_flush_work_fn+0x9/0x9 [ 368.805431] [] ? gs_change+0x13/0x13 [ 368.805442] Code: 83 7d 30 63 7e 04 f3 90 eb ab 4c 8d 63 04 4c 8d 7b 08 4c 89 e7 e8 fa 15 00 00 48 8b 43 10 4c 89 3c 24 48 89 63 10 48 89 44 24 08 <48> 89 20 83 c8 ff 48 89 6c 24 10 87 03 ff c8 74 35 4d 89 ee 41 [ 368.805851] RIP [] __mutex_lock_common.isra.7+0x9c/0x15b [ 368.805877] RSP [ 368.805886] CR2: 0000000000000000 [ 368.805899] ---[ end trace b720682065d8f4cc ]--- It's directly caused by 89d3cf6 [SCSI] libsas: add mutex for SMP task execution, but shows a deeper cause: expander functions expect to be able to cast to and treat domain devices as expanders. The correct fix is to only do expander discover when we know we've got an expander device to avoid wrongly casting a non-expander device. Reported-by: Praveen Murali Tested-by: Praveen Murali Cc: stable@vger.kernel.org Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit c81fc59be42c6e0d5061d00ee910c59db08da90e Author: Al Viro Date: Fri Feb 6 02:07:45 2015 -0500 gadgetfs: use-after-free in ->aio_read() [ Upstream commit f01d35a15fa04162a58b95970fc01fa70ec9dacd ] AIO_PREAD requests call ->aio_read() with iovec on caller's stack, so if we are going to access it asynchronously, we'd better get ourselves a copy - the one on kernel stack of aio_run_iocb() won't be there anymore. function/f_fs.c take care of doing that, legacy/inode.c doesn't... Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit c7fd1867c7d0626bf00373cec0f64b0ce4f4ec84 Author: Jan Beulich Date: Wed Mar 11 13:51:17 2015 +0000 xen-pciback: limit guest control of command register [ Upstream commit af6fc858a35b90e89ea7a7ee58e66628c55c776b ] Otherwise the guest can abuse that control to cause e.g. PCIe Unsupported Request responses by disabling memory and/or I/O decoding and subsequently causing (CPU side) accesses to the respective address ranges, which (depending on system configuration) may be fatal to the host. Note that to alter any of the bits collected together as PCI_COMMAND_GUEST permissive mode is now required to be enabled globally or on the specific device. This is CVE-2015-2150 / XSA-120. Signed-off-by: Jan Beulich Reviewed-by: Konrad Rzeszutek Wilk Cc: Signed-off-by: David Vrabel Signed-off-by: Sasha Levin commit 72c7a8558c74d6162126547f1a89e54d94dcd86f Author: Juergen Gross Date: Thu Feb 26 06:52:05 2015 +0100 xen/events: avoid NULL pointer dereference in dom0 on large machines [ Upstream commit 85e40b0539b24518c8bdf63e2605c8522377d00f ] Using the pvops kernel a NULL pointer dereference was detected on a large machine (144 processors) when booting as dom0 in evtchn_fifo_unmask() during assignment of a pirq. The event channel in question was the first to need a new entry in event_array[] in events_fifo.c. Unfortunately xen_irq_info_pirq_setup() is called with evtchn being 0 for a new pirq and the real event channel number is assigned to the pirq only during __startup_pirq(). It is mandatory to call xen_evtchn_port_setup() after assigning the event channel number to the pirq to make sure all memory needed for the event channel is allocated. Signed-off-by: Juergen Gross Cc: # 3.14+ Signed-off-by: David Vrabel Signed-off-by: Sasha Levin commit 75391143ec736e21f6a77c1aa9b96cc67a98898f Author: Javier Martinez Canillas Date: Thu Mar 12 16:25:49 2015 -0700 drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data [ Upstream commit 8792f7772f4f40ffc68bad5f28311205584b734d ] Commit df9e26d093d3 ("rtc: s3c: add support for RTC of Exynos3250 SoC") added an "rtc_src" DT property to specify the clock used as a source to the S3C real-time clock. Not all SoCs needs this so commit eaf3a659086e ("drivers/rtc/rtc-s3c.c: fix initialization failure without rtc source clock") changed to check the struct s3c_rtc_data .needs_src_clk to conditionally grab the clock. But that commit didn't update the data for each IP version so the RTC broke on the boards that needs a source clock. This is the case of at least Exynos5250 and Exynos5440 which uses the s3c6410 RTC IP block. This commit fixes the S3C rtc on the Exynos5250 Snow and Exynos5420 Peach Pit and Pi Chromebooks. Signed-off-by: Javier Martinez Canillas Cc: Marek Szyprowski Cc: Chanwoo Choi Cc: Doug Anderson Cc: Olof Johansson Cc: Kevin Hilman Cc: Tyler Baker Cc: Alessandro Zummo Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit af6887e2100a5f053b2e07a0cc48f8dc6224653c Author: Chris Wilson Date: Wed Feb 25 13:45:26 2015 +0000 drm: Don't assign fbs for universal cursor support to files [ Upstream commit 9a6f5130143c17b91e0a3cbf5cc2d8c1e5a80a63 ] The internal framebuffers we create to remap legacy cursor ioctls to plane operations for the universal plane support shouldn't be linke to the file like normal userspace framebuffers. This bug goes back to the original universal cursor plane support introduced in commit 161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662 Author: Matt Roper Date: Tue Jun 10 08:28:10 2014 -0700 drm: Support legacy cursor ioctls via universal planes when possible (v4) The isn't too disastrous since fbs are small, we only create one when the cursor bo gets changed and ultimately they'll be reaped when the window server restarts. Conceptually we'd want to just pass NULL for file_priv when creating it, but the driver needs the file to lookup the underlying buffer object for cursor id. Instead let's move the file_priv linking out of add_framebuffer_internal() into the addfb ioctl implementation, which is the only place it is needed. And also rename the function for a more accurate since it only creates the fb, but doesn't add it anywhere. Signed-off-by: Daniel Vetter (fix & commit msg) Signed-off-by: Chris Wilson (provider of lipstick) Reviewed-by: Matt Roper Cc: Ville Syrjälä Cc: Matt Roper Cc: Rob Clark Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 2c7f0370166faf409e67c9bbcb098ed02c78d182 Author: Thomas Hellstrom Date: Mon Mar 9 01:56:21 2015 -0700 drm/vmwgfx: Fix a couple of lock dependency violations [ Upstream commit 5151adb37a5918957f4c33a8d8e7629c0fb00563 ] Experimental lockdep annotation added to the TTM lock has unveiled a couple of lock dependency violations in the vmwgfx driver. In both cases it turns out that the device_private::reservation_sem is not needed so the offending code is moved out of that lock. Cc: Acked-by: Sinclair Yeh Signed-off-by: Thomas Hellstrom Signed-off-by: Sasha Levin commit c95800d035abe0ad19aa8352e64c237e10724e67 Author: Thomas Hellstrom Date: Thu Mar 5 02:33:24 2015 -0800 drm/vmwgfx: Reorder device takedown somewhat [ Upstream commit 3458390b9f0ba784481d23134798faee27b5f16f ] To take down the MOB and GMR memory types, the driver may have to issue fence objects and thus make sure that the fence manager is taken down after those memory types. Reorder device init accordingly. Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh Signed-off-by: Sasha Levin commit 9297c326266dd08af2c7be30cbab32787eef9b9f Author: Jakub Kicinski Date: Wed Mar 11 18:35:36 2015 +0100 Revert "i2c: core: Dispose OF IRQ mapping at client removal time" [ Upstream commit a49445727014216703a3c28ccee4cef36d41571e ] This reverts commit e4df3a0b6228 ("i2c: core: Dispose OF IRQ mapping at client removal time") Calling irq_dispose_mapping() will destroy the mapping and disassociate the IRQ from the IRQ chip to which it belongs. Keeping it is OK, because existent mappings are reused properly. Also, this commit breaks drivers using devm* for IRQ management on OF-based systems because devm* cleanup happens in device code, after bus's remove() method returns. Signed-off-by: Jakub Kicinski Reported-by: Sébastien Szymanski Acked-by: Laurent Pinchart Acked-by: Dmitry Torokhov [wsa: updated the commit message with findings fromt the other bug report] Signed-off-by: Wolfram Sang Cc: stable@kernel.org Fixes: e4df3a0b6228 Signed-off-by: Sasha Levin commit 5e0c3d9ec8d84dcfc8a4f740bb632b0d61d8d3ed Author: Ryusuke Konishi Date: Thu Mar 12 16:26:00 2015 -0700 nilfs2: fix deadlock of segment constructor during recovery [ Upstream commit 283ee1482f349d6c0c09dfb725db5880afc56813 ] According to a report from Yuxuan Shui, nilfs2 in kernel 3.19 got stuck during recovery at mount time. The code path that caused the deadlock was as follows: nilfs_fill_super() load_nilfs() nilfs_salvage_orphan_logs() * Do roll-forwarding, attach segment constructor for recovery, and kick it. nilfs_segctor_thread() nilfs_segctor_thread_construct() * A lock is held with nilfs_transaction_lock() nilfs_segctor_do_construct() nilfs_segctor_drop_written_files() iput() iput_final() write_inode_now() writeback_single_inode() __writeback_single_inode() do_writepages() nilfs_writepage() nilfs_construct_dsync_segment() nilfs_transaction_lock() --> deadlock This can happen if commit 7ef3ff2fea8b ("nilfs2: fix deadlock of segment constructor over I_SYNC flag") is applied and roll-forward recovery was performed at mount time. The roll-forward recovery can happen if datasync write is done and the file system crashes immediately after that. For instance, we can reproduce the issue with the following steps: < nilfs2 is mounted on /nilfs (device: /dev/sdb1) > # dd if=/dev/zero of=/nilfs/test bs=4k count=1 && sync # dd if=/dev/zero of=/nilfs/test conv=notrunc oflag=dsync bs=4k count=1 && reboot -nfh < the system will immediately reboot > # mount -t nilfs2 /dev/sdb1 /nilfs The deadlock occurs because iput() can run segment constructor through writeback_single_inode() if MS_ACTIVE flag is not set on sb->s_flags. The above commit changed segment constructor so that it calls iput() asynchronously for inodes with i_nlink == 0, but that change was imperfect. This fixes the another deadlock by deferring iput() in segment constructor even for the case that mount is not finished, that is, for the case that MS_ACTIVE flag is not set. Signed-off-by: Ryusuke Konishi Reported-by: Yuxuan Shui Tested-by: Ryusuke Konishi Cc: Al Viro Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit bf90526a2d9c3c6049193b9790d25a4f8f8ae2cb Author: Doug Anderson Date: Tue Mar 3 15:20:47 2015 -0800 regulator: core: Fix enable GPIO reference counting [ Upstream commit 29d62ec5f87fbeec8413e2215ddad12e7f972e4c ] Normally _regulator_do_enable() isn't called on an already-enabled rdev. That's because the main caller, _regulator_enable() always calls _regulator_is_enabled() and only calls _regulator_do_enable() if the rdev was not already enabled. However, there is one caller of _regulator_do_enable() that doesn't check: regulator_suspend_finish(). While we might want to make regulator_suspend_finish() behave more like _regulator_enable(), it's probably also a good idea to make _regulator_do_enable() robust if it is called on an already enabled rdev. At the moment, _regulator_do_enable() is _not_ robust for already enabled rdevs if we're using an ena_pin. Each time _regulator_do_enable() is called for an rdev using an ena_pin the reference count of the ena_pin is incremented even if the rdev was already enabled. This is not as intended because the ena_pin is for something else: for keeping track of how many active rdevs there are sharing the same ena_pin. Here's how the reference counting works here: * Each time _regulator_enable() is called we increment rdev->use_count, so _regulator_enable() calls need to be balanced with _regulator_disable() calls. * There is no explicit reference counting in _regulator_do_enable() which is normally just a warapper around rdev->desc->ops->enable() with code for supporting delays. It's not expected that the "ops->enable()" call do reference counting. * Since regulator_ena_gpio_ctrl() does have reference counting (handling the sharing of the pin amongst multiple rdevs), we shouldn't call it if the current rdev is already enabled. Note that as part of this we cleanup (remove) the initting of ena_gpio_state in regulator_register(). In _regulator_do_enable(), _regulator_do_disable() and _regulator_is_enabled() is is clear that ena_gpio_state should be the state of whether this particular rdev has requested the GPIO be enabled. regulator_register() was initting it as the actual state of the pin. Fixes: 967cfb18c0e3 ("regulator: core: manage enable GPIO list") Signed-off-by: Doug Anderson Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4aeea72574f75e4727d1b7c78bdd970b415e8a0f Author: Javier Martinez Canillas Date: Mon Mar 2 21:40:39 2015 +0100 regulator: Only enable disabled regulators on resume [ Upstream commit 0548bf4f5ad6fc3bd93c4940fa48078b34609682 ] The _regulator_do_enable() call ought to be a no-op when called on an already-enabled regulator. However, as an optimization _regulator_enable() doesn't call _regulator_do_enable() on an already enabled regulator. That means we never test the case of calling _regulator_do_enable() during normal usage and there may be hidden bugs or warnings. We have seen warnings issued by the tps65090 driver and bugs when using the GPIO enable pin. Let's match the same optimization that _regulator_enable() in regulator_suspend_finish(). That may speed up suspend/resume and also avoids exposing hidden bugs. [Use much clearer commit message from Doug Anderson] Signed-off-by: Javier Martinez Canillas Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 084968adf59f1cd61a9451a0be1ba384eafe6d04 Author: Doug Anderson Date: Fri Feb 20 16:53:38 2015 -0800 regulator: rk808: Set the enable time for LDOs [ Upstream commit 28249b0c2fa361cdac450a6f40242ed45408a24f ] The LDOs are documented in the rk808 datasheet to have a soft start time of 400us. Add that to the driver. If this time takes longer on a certain board the device tree should be able to override with "regulator-enable-ramp-delay". This fixes some dw_mmc probing problems (together with other patches posted to the mmc maiing lists) on rk3288. Signed-off-by: Doug Anderson Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 45eacb50e531e3e4ac5d81612fb0ad95143a3ce6 Author: Brian King Date: Wed Mar 4 08:09:44 2015 -0600 bnx2x: Force fundamental reset for EEH recovery [ Upstream commit da293700568ed3d96fcf062ac15d7d7c41377f11 ] EEH recovery for bnx2x based adapters is not reliable on all Power systems using the default hot reset, which can result in an unrecoverable EEH error. Forcing the use of fundamental reset during EEH recovery fixes this. Cc: stable Signed-off-by: Brian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c07b3abce1d575c41c41df623486fed33703fd8 Author: Maxime Ripard Date: Wed Feb 18 11:32:07 2015 +0100 mtd: nand: pxa3xx: Fix PIO FIFO draining [ Upstream commit 8dad0386b97c4bd6edd56752ca7f2e735fe5beb4 ] The NDDB register holds the data that are needed by the read and write commands. However, during a read PIO access, the datasheet specifies that after each 32 bytes read in that register, when BCH is enabled, we have to make sure that the RDDREQ bit is set in the NDSR register. This fixes an issue that was seen on the Armada 385, and presumably other mvebu SoCs, when a read on a newly erased page would end up in the driver reporting a timeout from the NAND. Cc: # v3.14 Signed-off-by: Maxime Ripard Reviewed-by: Boris Brezillon Acked-by: Ezequiel Garcia Signed-off-by: Brian Norris Signed-off-by: Sasha Levin commit 79eb59a64b923ca914cefe05ad149957514c8c89 Author: Takashi Iwai Date: Mon Mar 16 10:18:08 2015 +0100 ALSA: hda - Treat stereo-to-mono mix properly [ Upstream commit cc261738add93947d138d2fabad9f4dbed4e5c00 ] The commit [ef403edb7558: ALSA: hda - Don't access stereo amps for mono channel widgets] fixed the handling of mono widgets in general, but it still misses an exceptional case: namely, a mono mixer widget taking a single stereo input. In this case, it has stereo volumes although it's a mono widget, and thus we have to take care of both left and right input channels, as stated in HD-audio spec ("7.1.3 Widget Interconnection Rules"). This patch covers this missing piece by adding proper checks of stereo amps in both the generic parser and the proc output codes. Reported-by: Raymond Yau Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6fdbb0ba74c5b4e4e7b54aee9078c6887d49709d Author: Takashi Iwai Date: Sun Mar 8 18:29:50 2015 +0100 ALSA: hda - Fix regression of HD-audio controller fallback modes [ Upstream commit a1f3f1ca66bd12c339b17a0c2ef93a093f90a277 ] The commit [63e51fd708f5: ALSA: hda - Don't take unresponsive D3 transition too serious] introduced a conditional fallback behavior to the HD-audio controller depending on the flag set. However, it introduced a silly bug, too, that the flag was evaluated in a reverse way. This resulted in a regression of HD-audio controller driver where it can't go to the fallback mode at communication errors. Unfortunately (or fortunately?) this didn't come up until recently because the affected code path is an error handling that happens only on an unstable hardware chip. Most of recent chips work stably, thus they didn't hit this problem. Now, we've got a regression report with a VIA chip, and this seems indeed requiring the fallback to the polling mode, and finally the bug was revealed. The fix is a oneliner to remove the wrong logical NOT in the check. (Lesson learned - be careful about double negation.) The bug should be backported to stable, but the patch won't be applicable to 3.13 or earlier because of the code splits. The stable fix patches for earlier kernels will be posted later manually. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021 Fixes: 63e51fd708f5 ('ALSA: hda - Don't take unresponsive D3 transition too serious') Cc: # v3.14+ Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 73de0edf4b541dcd758adbdc96380f0581c835c3 Author: Takashi Iwai Date: Thu Mar 12 20:47:15 2015 +0100 ALSA: hda - Add workaround for MacBook Air 5,2 built-in mic [ Upstream commit 2ddee91abe9cc34ddb6294ee14702b46ae07d460 ] MacBook Air 5,2 has the same problem as MacBook Pro 8,1 where the built-in mic records only the right channel. Apply the same workaround as MBP8,1 to spread the mono channel via a Cirrus codec vendor-specific COEF setup. Reported-and-tested-by: Vasil Zlatanov Cc: # 3.9+ Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b0501ca4a61e9735a8375bb155ef5cebe25b2f80 Author: Takashi Iwai Date: Thu Mar 12 20:28:04 2015 +0100 ALSA: hda - Set single_adc_amp flag for CS420x codecs [ Upstream commit bad994f5b4ab57eec8d56c180edca00505c3eeb2 ] CS420x codecs seem to deal only the single amps of ADC nodes even though the nodes receive multiple inputs. This leads to the inconsistent amp value after S3/S4 resume, for example. The fix is just to set codec->single_adc_amp flag. Then the driver handles these ADC amps as if single connections. Reported-and-tested-by: Vasil Zlatanov Cc: # 3.9+ Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e2b501a93a936b2b6b03f6237a161ce2ee1c26ff Author: Takashi Iwai Date: Thu Mar 12 08:30:11 2015 +0100 ALSA: hda - Don't access stereo amps for mono channel widgets [ Upstream commit ef403edb75580a3ec5d155f5de82155f0419c621 ] The current HDA generic parser initializes / modifies the amp values always in stereo, but this seems causing the problem on ALC3229 codec that has a few mono channel widgets: namely, these mono widgets react to actions for both channels equally. In the driver code, we do care the mono channel and create a control only for the left channel (as defined in HD-audio spec) for such a node. When the control is updated, only the left channel value is changed. However, in the resume, the right channel value is also restored from the initial value we took as stereo, and this overwrites the left channel value. This ends up being the silent output as the right channel has been never touched and remains muted. This patch covers the places where unconditional stereo amp accesses are done and converts to the conditional accesses. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94581 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 05e83bd5ada2cec47fad6957f8c0a78a2a182ecc Author: Takashi Iwai Date: Wed Mar 11 16:05:19 2015 +0100 ALSA: hda - Fix built-in mic on Compaq Presario CQ60 [ Upstream commit ddb6ca75b5671b8fbf1909bc588c449ee74b34f9 ] Compaq Presario CQ60 laptop with CX20561 gives a wrong pin for the built-in mic NID 0x17 instead of NID 0x1d, and it results in the non-working mic. This patch just remaps the pin correctly via fixup. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=920604 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c0527b93dce28eeb93ac97008511952bca7da762 Author: Takashi Iwai Date: Wed Mar 11 18:12:49 2015 +0100 ALSA: control: Add sanity checks for user ctl id name string [ Upstream commit be3bb8236db2d0fcd705062ae2e2a9d75131222f ] There was no check about the id string of user control elements, so we accepted even a control element with an empty string, which is obviously bogus. This patch adds more sanity checks of id strings. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 095ea4b422e73946922e511f209b22726013eb96 Author: Daniel Mack Date: Thu Mar 12 09:41:32 2015 +0100 ALSA: snd-usb: add quirks for Roland UA-22 [ Upstream commit fcdcd1dec6d2c7b718385ec743ae5a9a233edad4 ] The device complies to the UAC1 standard but hides that fact with proprietary descriptors. The autodetect quirk for Roland devices catches the audio interface but misses the MIDI part, so a specific quirk is needed. Signed-off-by: Daniel Mack Reported-by: Rafa Lafuente Tested-by: Raphaël Doursenaud Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 766afbabcbf94423ccd8c8ae1081a2bd38043d08 Author: Alexander Sverdlin Date: Fri Feb 27 16:30:21 2015 +0100 spi: pl022: Fix race in giveback() leading to driver lock-up [ Upstream commit cd6fa8d2ca53cac3226fdcffcf763be390abae32 ] Commit fd316941c ("spi/pl022: disable port when unused") introduced a race, which leads to possible driver lock up (easily reproducible on SMP). The problem happens in giveback() function where the completion of the transfer is signalled to SPI subsystem and then the HW SPI controller is disabled. Another transfer might be setup in between, which brings driver in locked-up state. Exact event sequence on SMP: core0 core1 => pump_transfers() /* message->state == STATE_DONE */ => giveback() => spi_finalize_current_message() => pl022_unprepare_transfer_hardware() => pl022_transfer_one_message => flush() => do_interrupt_dma_transfer() => set_up_next_transfer() /* Enable SSP, turn on interrupts */ writew((readw(SSP_CR1(pl022->virtbase)) | SSP_CR1_MASK_SSE), SSP_CR1(pl022->virtbase)); ... => pl022_interrupt_handler() => readwriter() /* disable the SPI/SSP operation */ => writew((readw(SSP_CR1(pl022->virtbase)) & (~SSP_CR1_MASK_SSE)), SSP_CR1(pl022->virtbase)); Lockup! SPI controller is disabled and the data will never be received. Whole SPI subsystem is waiting for transfer ACK and blocked. So, only signal transfer completion after disabling the controller. Fixes: fd316941c (spi/pl022: disable port when unused) Signed-off-by: Alexander Sverdlin Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit f3aa910546efe131b46ee2b7721a473b7b6938bc Author: Andy Shevchenko Date: Mon Mar 2 20:15:58 2015 +0200 spi: dw-mid: avoid potential NULL dereference [ Upstream commit c9dafb27c84412fe4b17c3b94cc4ffeef5df1833 ] When DMA descriptor allocation fails we should not try to assign any fields in the bad descriptor. The patch adds the necessary checks for that. Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support) Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit fbafcf8fb1f46e46e8f5882be2fdf6428f6f6801 Author: Torsten Fleischer Date: Tue Feb 24 16:32:57 2015 +0100 spi: atmel: Fix interrupt setup for PDC transfers [ Upstream commit 76e1d14b316d6f501ebc001e7a5d86b24ce5b615 ] Additionally to the current DMA transfer the PDC allows to set up a next DMA transfer. This is useful for larger SPI transfers. The driver currently waits for ENDRX as end of the transfer. But ENDRX is set when the current DMA transfer is done (RCR = 0), i.e. it doesn't include the next DMA transfer. Thus a subsequent SPI transfer could be started although there is currently a transfer in progress. This can cause invalid accesses to the SPI slave devices and to SPI transfer errors. This issue has been observed on a hardware with a M25P128 SPI NOR flash. So instead of ENDRX we should wait for RXBUFF. This flag is set if there is no more DMA transfer in progress (RCR = RNCR = 0). Signed-off-by: Torsten Fleischer Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit a0366884749ec748126fa1934a030f46dcbf8d45 Author: Christophe Ricard Date: Tue Jan 13 23:13:14 2015 +0100 tpm/tpm_i2c_stm_st33: Add status check when reading data on the FIFO [ Upstream commit c4eadfafb91d5501095c55ffadaa1168743f39d3 ] Add a return value check when reading data from the FIFO register. Cc: Reviewed-by: Jason Gunthorpe Signed-off-by: Christophe Ricard Reviewed-by: Peter Huewe Signed-off-by: Peter Huewe Signed-off-by: Sasha Levin commit 33c5b3ad4b54d9477d5ad85b5fd811d0500676e5 Author: jmlatten@linux.vnet.ibm.com Date: Fri Feb 20 18:11:24 2015 -0600 tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send [ Upstream commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1 ] Problem: When IMA and VTPM are both enabled in kernel config, kernel hangs during bootup on LE OS. Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send and tpm_ibmtpm_recv getting called. A trace showed that tpm_ibmtpm_recv was hanging. Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send was sending CRQ message that probably did not make much sense to phype because of Endianness. The fix below sends correctly converted CRQ for LE. This was not caught before because it seems IMA is not enabled by default in kernel config and IMA exercises this particular code path in vtpm. Tested with IMA and VTPM enabled in kernel config and VTPM enabled on both a BE OS and a LE OS ppc64 lpar. This exercised CRQ and TPM command code paths in vtpm. Patch is against Peter's tpmdd tree on github which included Vicky's previous vtpm le patches. Signed-off-by: Joy Latten Cc: # eb71f8a5e33f: "Added Little Endian support to vtpm module" Cc: Reviewed-by: Ashley Lai Signed-off-by: Peter Huewe Signed-off-by: Sasha Levin commit ea7358ff38e4f1b029fc7b5383f2f9d7b3a2f684 Author: Jason Low Date: Fri Feb 13 11:58:07 2015 +0800 cpuset: Fix cpuset sched_relax_domain_level [ Upstream commit 283cb41f426b723a0255702b761b0fc5d1b53a81 ] The cpuset.sched_relax_domain_level can control how far we do immediate load balancing on a system. However, it was found on recent kernels that echo'ing a value into cpuset.sched_relax_domain_level did not reduce any immediate load balancing. The reason this occurred was because the update_domain_attr_tree() traversal did not update for the "top_cpuset". This resulted in nothing being changed when modifying the sched_relax_domain_level parameter. This patch is able to address that problem by having update_domain_attr_tree() allow updates for the root in the cpuset traversal. Fixes: fc560a26acce ("cpuset: replace cpuset->stack_list with cpuset_for_each_descendant_pre()") Cc: # 3.9+ Signed-off-by: Jason Low Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Tested-by: Serge Hallyn Signed-off-by: Sasha Levin commit 79692efa3aadec55cbfbf385077a5415cf314f22 Author: Zefan Li Date: Fri Feb 13 11:20:30 2015 +0800 cpuset: fix a warning when clearing configured masks in old hierarchy [ Upstream commit 79063bffc81f82689bd90e16da1b49408f3bf095 ] When we clear cpuset.cpus, cpuset.effective_cpus won't be cleared: # mount -t cgroup -o cpuset xxx /mnt # mkdir /mnt/tmp # echo 0 > /mnt/tmp/cpuset.cpus # echo > /mnt/tmp/cpuset.cpus # cat cpuset.cpus # cat cpuset.effective_cpus 0-15 And a kernel warning in update_cpumasks_hier() is triggered: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 4028 at kernel/cpuset.c:894 update_cpumasks_hier+0x471/0x650() Cc: # 3.17+ Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Tested-by: Serge Hallyn Signed-off-by: Sasha Levin commit dacb6ccdcc8374f9d100c23d50087b8cb1fd0eb3 Author: Zefan Li Date: Fri Feb 13 11:19:49 2015 +0800 cpuset: initialize effective masks when clone_children is enabled [ Upstream commit 790317e1b266c776765a4bdcedefea706ff0fada ] If clone_children is enabled, effective masks won't be initialized due to the bug: # mount -t cgroup -o cpuset xxx /mnt # echo 1 > cgroup.clone_children # mkdir /mnt/tmp # cat /mnt/tmp/ # cat cpuset.effective_cpus # cat cpuset.cpus 0-15 And then this cpuset won't constrain the tasks in it. Either the bug or the fix has no effect on unified hierarchy, as there's no clone_chidren flag there any more. Reported-by: Christian Brauner Reported-by: Serge Hallyn Cc: # 3.17+ Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Tested-by: Serge Hallyn Signed-off-by: Sasha Levin commit d4bc18f7bbd9aa62b1794fe8f409bd0c1b88a597 Author: Tejun Heo Date: Thu Mar 5 08:04:13 2015 -0500 workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE [ Upstream commit 8603e1b30027f943cc9c1eef2b291d42c3347af1 ] cancel[_delayed]_work_sync() are implemented using __cancel_work_timer() which grabs the PENDING bit using try_to_grab_pending() and then flushes the work item with PENDING set to prevent the on-going execution of the work item from requeueing itself. try_to_grab_pending() can always grab PENDING bit without blocking except when someone else is doing the above flushing during cancelation. In that case, try_to_grab_pending() returns -ENOENT. In this case, __cancel_work_timer() currently invokes flush_work(). The assumption is that the completion of the work item is what the other canceling task would be waiting for too and thus waiting for the same condition and retrying should allow forward progress without excessive busy looping Unfortunately, this doesn't work if preemption is disabled or the latter task has real time priority. Let's say task A just got woken up from flush_work() by the completion of the target work item. If, before task A starts executing, task B gets scheduled and invokes __cancel_work_timer() on the same work item, its try_to_grab_pending() will return -ENOENT as the work item is still being canceled by task A and flush_work() will also immediately return false as the work item is no longer executing. This puts task B in a busy loop possibly preventing task A from executing and clearing the canceling state on the work item leading to a hang. task A task B worker executing work __cancel_work_timer() try_to_grab_pending() set work CANCELING flush_work() block for work completion completion, wakes up A __cancel_work_timer() while (forever) { try_to_grab_pending() -ENOENT as work is being canceled flush_work() false as work is no longer executing } This patch removes the possible hang by updating __cancel_work_timer() to explicitly wait for clearing of CANCELING rather than invoking flush_work() after try_to_grab_pending() fails with -ENOENT. Link: http://lkml.kernel.org/g/20150206171156.GA8942@axis.com v3: bit_waitqueue() can't be used for work items defined in vmalloc area. Switched to custom wake function which matches the target work item and exclusive wait and wakeup. v2: v1 used wake_up() on bit_waitqueue() which leads to NULL deref if the target bit waitqueue has wait_bit_queue's on it. Use DEFINE_WAIT_BIT() and __wake_up_bit() instead. Reported by Tomeu Vizoso. Signed-off-by: Tejun Heo Reported-by: Rabin Vincent Cc: Tomeu Vizoso Cc: stable@vger.kernel.org Tested-by: Jesper Nilsson Tested-by: Rabin Vincent Signed-off-by: Sasha Levin commit 9c8090e1e52cf9dc8ff730a6a4ea29153a69f315 Author: Ahmed S. Darwish Date: Thu Feb 26 10:22:02 2015 -0500 can: kvaser_usb: Read all messages in a bulk-in URB buffer [ Upstream commit 2fec5104f9c61de4cf2205aa355101e19a81f490 ] The Kvaser firmware can only read and write messages that are not crossing the USB endpoint's wMaxPacketSize boundary. While receiving commands from the CAN device, if the next command in the same URB buffer crossed that max packet size boundary, the firmware puts a zero-length placeholder command in its place then moves the real command to the next boundary mark. The driver did not recognize such behavior, leading to missing a good number of rx events during a heavy rx load session. Moreover, a tx URB context only gets freed upon receiving its respective tx ACK event. Over time, the free tx URB contexts pool gets depleted due to the missing ACK events. Consequently, the netif transmission queue gets __permanently__ stopped; no frames could be sent again except after restarting the CAN newtwork interface. Signed-off-by: Ahmed S. Darwish Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 9baee042462d0d5df166bab8a10c06ca3b8f2d0b Author: Oliver Hartkopp Date: Mon Feb 23 20:37:54 2015 +0100 can: add missing initialisations in CAN related skbuffs [ Upstream commit 969439016d2cf61fef53a973d7e6d2061c3793b1 ] When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient this can lead to a skb_under_panic due to missing skb initialisations. Add the missing initialisations at the CAN skbuff creation times on driver level (rx path) and in the network layer (tx path). Reported-by: Austin Schuh Reported-by: Daniel Steer Signed-off-by: Oliver Hartkopp Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 24cc23d3afc97e8fdbb82fabd80a270813268654 Author: Steven Rostedt (Red Hat) Date: Fri Mar 6 19:55:13 2015 -0500 ftrace: Fix ftrace enable ordering of sysctl ftrace_enabled [ Upstream commit 524a38682573b2e15ab6317ccfe50280441514be ] Some archs (specifically PowerPC), are sensitive with the ordering of the enabling of the calls to function tracing and setting of the function to use to be traced. That is, update_ftrace_function() sets what function the ftrace_caller trampoline should call. Some archs require this to be set before calling ftrace_run_update_code(). Another bug was discovered, that ftrace_startup_sysctl() called ftrace_run_update_code() directly. If the function the ftrace_caller trampoline changes, then it will not be updated. Instead a call to ftrace_startup_enable() should be called because it tests to see if the callback changed since the code was disabled, and will tell the arch to update appropriately. Most archs do not need this notification, but PowerPC does. The problem could be seen by the following commands: # echo 0 > /proc/sys/kernel/ftrace_enabled # echo function > /sys/kernel/debug/tracing/current_tracer # echo 1 > /proc/sys/kernel/ftrace_enabled # cat /sys/kernel/debug/tracing/trace The trace will show that function tracing was not active. Cc: stable@vger.kernel.org # 2.6.27+ Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 4184e5ecb946103f3989584a1e1f75f204d94e17 Author: Pratyush Anand Date: Fri Mar 6 23:58:06 2015 +0530 ftrace: Fix en(dis)able graph caller when en(dis)abling record via sysctl [ Upstream commit 1619dc3f8f555ee1cdd3c75db3885d5715442b12 ] When ftrace is enabled globally through the proc interface, we must check if ftrace_graph_active is set. If it is set, then we should also pass the FTRACE_START_FUNC_RET command to ftrace_run_update_code(). Similarly, when ftrace is disabled globally through the proc interface, we must check if ftrace_graph_active is set. If it is set, then we should also pass the FTRACE_STOP_FUNC_RET command to ftrace_run_update_code(). Consider the following situation. # echo 0 > /proc/sys/kernel/ftrace_enabled After this ftrace_enabled = 0. # echo function_graph > /sys/kernel/debug/tracing/current_tracer Since ftrace_enabled = 0, ftrace_enable_ftrace_graph_caller() is never called. # echo 1 > /proc/sys/kernel/ftrace_enabled Now ftrace_enabled will be set to true, but still ftrace_enable_ftrace_graph_caller() will not be called, which is not desired. Further if we execute the following after this: # echo nop > /sys/kernel/debug/tracing/current_tracer Now since ftrace_enabled is set it will call ftrace_disable_ftrace_graph_caller(), which causes a kernel warning on the ARM platform. On the ARM platform, when ftrace_enable_ftrace_graph_caller() is called, it checks whether the old instruction is a nop or not. If it's not a nop, then it returns an error. If it is a nop then it replaces instruction at that address with a branch to ftrace_graph_caller. ftrace_disable_ftrace_graph_caller() behaves just the opposite. Therefore, if generic ftrace code ever calls either ftrace_enable_ftrace_graph_caller() or ftrace_disable_ftrace_graph_caller() consecutively two times in a row, then it will return an error, which will cause the generic ftrace code to raise a warning. Note, x86 does not have an issue with this because the architecture specific code for ftrace_enable_ftrace_graph_caller() and ftrace_disable_ftrace_graph_caller() does not check the previous state, and calling either of these functions twice in a row has no ill effect. Link: http://lkml.kernel.org/r/e4fbe64cdac0dd0e86a3bf914b0f83c0b419f146.1425666454.git.panand@redhat.com Cc: stable@vger.kernel.org # 2.6.31+ Signed-off-by: Pratyush Anand [ removed extra if (ftrace_start_up) and defined ftrace_graph_active as 0 if CONFIG_FUNCTION_GRAPH_TRACER is not set. ] Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit b4521c3dbf60f83da48b7758c212c2e9a59f7df2 Author: Steven Rostedt (Red Hat) Date: Wed Mar 4 23:10:28 2015 -0500 ftrace: Clear REGS_EN and TRAMP_EN flags on disabling record via sysctl [ Upstream commit b24d443b8f17d9776f5fc1f6c780a0a21eb02913 ] When /proc/sys/kernel/ftrace_enabled is set to zero, all function tracing is disabled. But the records that represent the functions still hold information about the ftrace_ops that are hooked to them. ftrace_ops may request "REGS" (have a full set of pt_regs passed to the callback), or "TRAMP" (the ops has its own trampoline to use). When the record is updated to represent the state of the ops hooked to it, it sets "REGS_EN" and/or "TRAMP_EN" to state that the callback points to the correct trampoline (REGS has its own trampoline). When ftrace_enabled is set to zero, all ftrace locations are a nop, so they do not point to any trampoline. But the _EN flags are still set. This can cause the accounting to go wrong when ftrace_enabled is cleared and an ops that has a trampoline is registered or unregistered. For example, the following will cause ftrace to crash: # echo function_graph > /sys/kernel/debug/tracing/current_tracer # echo 0 > /proc/sys/kernel/ftrace_enabled # echo nop > /sys/kernel/debug/tracing/current_tracer # echo 1 > /proc/sys/kernel/ftrace_enabled # echo function_graph > /sys/kernel/debug/tracing/current_tracer As function_graph uses a trampoline, when ftrace_enabled is set to zero the updates to the record are not done. When enabling function_graph again, the record will still have the TRAMP_EN flag set, and it will look for an op that has a trampoline other than the function_graph ops, and fail to find one. Cc: stable@vger.kernel.org # 3.17+ Reported-by: Pratyush Anand Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 51ff22caa13c0e7a0f11d0a39f114de0fc44ff5c Author: Russell King Date: Fri Mar 6 10:49:21 2015 +0000 Change email address for 8250_pci [ Upstream commit f2e0ea861117bda073d1d7ffbd3120c07c0d5d34 ] I'm still receiving reports to my email address, so let's point this at the linux-serial mailing list instead. Cc: Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ee7fb5b37197d87a1bcf4e47b3b7f03ce6d02862 Author: Michael S. Tsirkin Date: Thu Mar 5 10:45:49 2015 +1030 virtio_console: avoid config access from irq [ Upstream commit eeb8a7e8bb123e84daeef84f5a2eab99ad2839a2 ] when multiport is off, virtio console invokes config access from irq context, config access is blocking on s390. Fix this up by scheduling work from config irq - similar to what we do for multiport configs. Signed-off-by: Michael S. Tsirkin Reviewed-by: Amit Shah Signed-off-by: Rusty Russell Cc: stable@kernel.org Signed-off-by: Sasha Levin commit 0b39fb19628e0f55676ce81e1411c45b7aebf43f Author: Michael S. Tsirkin Date: Thu Mar 5 10:45:30 2015 +1030 virtio_console: init work unconditionally [ Upstream commit 4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 ] when multiport is off, we don't initialize config work, but we then cancel uninitialized control_work on freeze. Signed-off-by: Michael S. Tsirkin Reviewed-by: Amit Shah Signed-off-by: Rusty Russell Cc: stable@kernel.org Signed-off-by: Sasha Levin commit 5850222dacf683137f7c6a893636daace65e6ad2 Author: Peter Hurley Date: Sun Mar 1 10:11:05 2015 -0500 console: Fix console name size mismatch commit 30a22c215a0007603ffc08021f2e8b64018517dd upstream. commit 6ae9200f2cab7 ("enlarge console.name") increased the storage for the console name to 16 bytes, but not the corresponding struct console_cmdline::name storage. Console names longer than 8 bytes cause read beyond end-of-string and failure to match console; I'm not sure if there are other unexpected consequences. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman (cherry picked from commit 2cf6258c282608633c9477e5c8e319e948565122) commit de62b348272ac2c5464e1fe7b90e0c2b5949849a Author: Peter Hurley Date: Wed Mar 11 09:19:16 2015 -0400 serial: 8250_dw: Fix deadlock in LCR workaround [ Upstream commit 7fd6f640f2dd17dac6ddd6702c378cb0bb9cfa11 ] Trying to write console output from within the serial console driver while the port->lock is held causes recursive deadlock: CPU 0 spin_lock_irqsave(&port->lock) printk() console_unlock() call_console_drivers() serial8250_console_write() spin_lock_irqsave(&port->lock) ** DEADLOCK ** The 8250_dw i/o accessors try to write a console error message if the LCR workaround was unsuccessful. When the port->lock is already held (eg., when called from serial8250_set_termios()), this deadlocks. Make the error message a FIXME until a general solution is devised. Cc: Tim Kryger Reported-by: Zhang Zhen Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 78df56cca6dcf5f2d8c65b642a3bbf2b199c8e88 Author: Miklos Szeredi Date: Thu Feb 26 11:45:47 2015 +0100 fuse: notify: don't move pages [ Upstream commit 0d2783626a53d4c922f82d51fa675cb5d13f0d36 ] fuse_try_move_page() is not prepared for replacing pages that have already been read. Reported-by: Al Viro Signed-off-by: Miklos Szeredi Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9525473566852df009ead45cf4d70c40452dd38a Author: Miklos Szeredi Date: Thu Feb 26 11:45:47 2015 +0100 fuse: set stolen page uptodate [ Upstream commit aa991b3b267e24f578bac7b09cc57579b660304b ] Regular pipe buffers' ->steal method (generic_pipe_buf_steal()) doesn't set PG_uptodate. Don't warn on this condition, just set the uptodate flag. Signed-off-by: Miklos Szeredi Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9bda2fc64c145fe4afa2ffcfdc2f78df5fcbfbdd Author: JeHyeon Yeon Date: Mon Mar 16 01:03:19 2015 +0000 LZ4 : fix the data abort issue [ Upstream commit d5e7cafd69da24e6d6cc988fab6ea313a2577efc ] If the part of the compression data are corrupted, or the compression data is totally fake, the memory access over the limit is possible. This is the log from my system usning lz4 decompression. [6502]data abort, halting [6503]r0 0x00000000 r1 0x00000000 r2 0xdcea0ffc r3 0xdcea0ffc [6509]r4 0xb9ab0bfd r5 0xdcea0ffc r6 0xdcea0ff8 r7 0xdce80000 [6515]r8 0x00000000 r9 0x00000000 r10 0x00000000 r11 0xb9a98000 [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc 0x820149bc [6528]spsr 0x400001f3 and the memory addresses of some variables at the moment are ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000 As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory over @oend. Signed-off-by: JeHyeon Yeon Reviewed-by: David Sterba Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7809f283e07340fa5b3dc01e2f23207c8521598e Author: Alex Deucher Date: Tue Mar 17 11:53:33 2015 -0400 drm/radeon: drop ttm two ended allocation [ Upstream commit a239118a24b3bf9089751068e431dfb63dc4168b ] radeon_bo_create() calls radeon_ttm_placement_from_domain() before ttm_bo_init() is called. radeon_ttm_placement_from_domain() uses the ttm bo size to determine when to select top down allocation but since the ttm bo is not initialized yet the check is always false. It only took effect when buffers were validated later. It also seemed to regress suspend and resume on some systems possibly due to it not taking effect in radeon_bo_create(). radeon_bo_create() and radeon_ttm_placement_from_domain() need to be reworked substantially for this to be optimally effective. Re-enable it at that point. Noticed-by: Oded Gabbay Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 764725a6ee43f8151005de778dffe58f5f84b5c9 Author: Maarten Lankhorst Date: Tue Mar 3 09:56:42 2015 +0100 drm/radeon: fix wait to actually occur after the signaling callback [ Upstream commit b6610101718d4ab90d793c482625e98eb1262cad ] A normal wait adds to the front of the tail. By doing something similar to fence_default_wait the fence code can run without racing. This is a complete fix for "panic on suspend from KDE with radeon", and a partial fix for "Radeon: System pauses on TAHITI". On tahiti si_irq_set needs to be fixed too, to completely flush the writes before radeon_fence_activity is called in radeon_fence_enable_signaling. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861 Signed-off-by: Maarten Lankhorst Reported-by: Jon Arne Jørgensen Reported-and-tested-by: Gustaw Smolarczyk Cc: stable@vger.kernel.org (v3.18+) Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6eef27b662aadf5488eb793c87143e0510ed3ada Author: Christian König Date: Thu Feb 19 09:40:28 2015 +0100 drm/radeon: drop setting UPLL to sleep mode [ Upstream commit a17d4996e051e78d164989b894608cf37cd5110b ] Just keep it working, seems to fix some PLL problems. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378 Signed-off-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 570f8c773958de8dde13d941c6d9631f828f687e Author: Alex Deucher Date: Tue Mar 3 17:00:43 2015 -0500 drm/radeon: fix interlaced modes on DCE8 [ Upstream commit 77ae5f4b48a0445426c9c1ef7c0f28b717e35d55 ] Need to double the viewport height. Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 2b4cdd25e9688b85296fd3ce61fc93490ef41922 Author: Alex Deucher Date: Mon Mar 2 20:39:56 2015 -0500 drm/radeon: do a posting read in rs600_set_irq [ Upstream commit 54acf107e4e66d1f4a697e08a7f60dba9fcf07c3 ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 030b28dca1deb116c759d7bec65541a14522e3df Author: Alex Deucher Date: Mon Mar 2 20:43:53 2015 -0500 drm/radeon: do a posting read in si_set_irq [ Upstream commit 0586915ec10d0ae60de5cd3381ad25a704760402 ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 09e605b31431b59a09c4e8ca3150590b929b2ed5 Author: Alex Deucher Date: Mon Mar 2 20:45:24 2015 -0500 drm/radeon: do a posting read in cik_set_irq [ Upstream commit cffefd9bb31cd35ab745d3b49005d10616d25bdc ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit a5f1220ce4120b18c72183908c30d3588442002a Author: Alex Deucher Date: Mon Mar 2 20:41:31 2015 -0500 drm/radeon: do a posting read in r600_set_irq [ Upstream commit 9d1393f23d5656cdd5f368efd60694d4aeed81d3 ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 226c62843fd105aab30f901182eca7ec39dcb683 Author: Alex Deucher Date: Mon Mar 2 20:36:26 2015 -0500 drm/radeon: do a posting read in r100_set_irq [ Upstream commit f957063fee6392bb9365370db6db74dc0b2dce0a ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 26f16cbdfdcf23b50be938f97ab581196e7bc73d Author: Alex Deucher Date: Mon Mar 2 20:42:53 2015 -0500 drm/radeon: do a posting read in evergreen_set_irq [ Upstream commit c320bb5f6dc0cb88a811cbaf839303e0a3916a92 ] To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7d5b23fa02b0a327eb1bdc5b854a773f00942304 Author: Tommi Rantala Date: Mon Mar 2 21:36:07 2015 +0200 drm/radeon: fix DRM_IOCTL_RADEON_CS oops [ Upstream commit a28b2a47edcd0cb7c051b445f71a426000394606 ] Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the following oops. Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort(). ---------------------------------- #include #include #include #include #include static const struct drm_radeon_cs cs; int main(int argc, char **argv) { return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs); } ---------------------------------- [ttrantal@test2 ~]$ ./main /dev/dri/card0 [ 46.904650] BUG: unable to handle kernel NULL pointer dereference at (null) [ 46.905022] IP: [] list_sort+0x42/0x240 [ 46.905022] PGD 68f29067 PUD 688b5067 PMD 0 [ 46.905022] Oops: 0002 [#1] SMP [ 46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58 [ 46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007 [ 46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000 [ 46.905022] RIP: 0010:[] [] list_sort+0x42/0x240 [ 46.905022] RSP: 0018:ffff880058e67998 EFLAGS: 00010246 [ 46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58 [ 46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000 [ 46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410 [ 46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0 [ 46.905022] FS: 00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000 [ 46.905022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0 [ 46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 [ 46.905022] Stack: [ 46.905022] ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] Call Trace: [ 46.905022] [] radeon_cs_parser_fini+0x195/0x220 [ 46.905022] [] radeon_cs_ioctl+0xa9/0x960 [ 46.905022] [] drm_ioctl+0x19c/0x640 [ 46.905022] [] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 46.905022] [] ? trace_hardirqs_on+0xd/0x10 [ 46.905022] [] radeon_drm_ioctl+0x46/0x80 [ 46.905022] [] do_vfs_ioctl+0x318/0x570 [ 46.905022] [] ? selinux_file_ioctl+0x56/0x110 [ 46.905022] [] SyS_ioctl+0x81/0xa0 [ 46.905022] [] system_call_fastpath+0x12/0x17 [ 46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7 00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85 [ 46.905022] RIP [] list_sort+0x42/0x240 [ 46.905022] RSP [ 46.905022] CR2: 0000000000000000 [ 47.149253] ---[ end trace 09576b4e8b2c20b8 ]--- Reviewed-by: Christian König Signed-off-by: Tommi Rantala Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit e9ab6db096e94d0e347ba5847022bfa1e80c2dca Author: Catalin Marinas Date: Wed Mar 11 12:20:39 2015 +0000 arm64: Invalidate the TLB corresponding to intermediate page table levels [ Upstream commit 285994a62c80f1d72c6924282bcb59608098d5ec ] The ARM architecture allows the caching of intermediate page table levels and page table freeing requires a sequence like: pmd_clear() TLB invalidation pte page freeing With commit 5e5f6dc10546 (arm64: mm: enable HAVE_RCU_TABLE_FREE logic), the page table freeing batching was moved from tlb_remove_page() to tlb_remove_table(). The former takes care of TLB invalidation as this is also shared with pte clearing and page cache page freeing. The latter, however, does not invalidate the TLBs for intermediate page table levels as it probably relies on the architecture code to do it if required. When the mm->mm_users < 2, tlb_remove_table() does not do any batching and page table pages are freed before tlb_finish_mmu() which performs the actual TLB invalidation. This patch introduces __tlb_flush_pgtable() for arm64 and calls it from the {pte,pmd,pud}_free_tlb() directly without relying on deferred page table freeing. Fixes: 5e5f6dc10546 arm64: mm: enable HAVE_RCU_TABLE_FREE logic Reported-by: Jon Masters Tested-by: Jon Masters Tested-by: Steve Capper Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit bf91097cd544111aa767482cc88bd46b67700046 Author: Will Deacon Date: Wed Oct 29 10:03:09 2014 +0000 mmu_gather: move minimal range calculations into generic code [ Upstream commit fb7332a9fedfd62b1ba6530c86f39f0fa38afd49 ] On architectures with hardware broadcasting of TLB invalidation messages , it makes sense to reduce the range of the mmu_gather structure when unmapping page ranges based on the dirty address information passed to tlb_remove_tlb_entry. arm64 already does this by directly manipulating the start/end fields of the gather structure, but this confuses the generic code which does not expect these fields to change and can end up calculating invalid, negative ranges when forcing a flush in zap_pte_range. This patch moves the minimal range calculation out of the arm64 code and into the generic implementation, simplifying zap_pte_range in the process (which no longer needs to care about start/end, since they will point to the appropriate ranges already). With the range being tracked by core code, the need_flush flag is dropped in favour of checking that the end of the range has actually been set. Cc: Benjamin Herrenschmidt Cc: Peter Zijlstra Cc: Russell King - ARM Linux Cc: Michal Simek Acked-by: Linus Torvalds Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0ef78141bea191058e585daebfcb8fc2e1f0de9e Author: Suzuki K. Poulose Date: Thu Mar 19 18:17:09 2015 +0000 arm64: Honor __GFP_ZERO in dma allocations [ Upstream commit 7132813c384515c9dede1ae20e56f3895feb7f1e ] Current implementation doesn't zero out the pages allocated. Honor the __GFP_ZERO flag and zero out if set. Cc: # v3.14+ Acked-by: Will Deacon Signed-off-by: Suzuki K. Poulose Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit e8f117f002cafb7a4a5a008b0251e5239207ebe1 Author: Eric Dumazet Date: Mon Nov 17 23:06:20 2014 -0800 tcp: make connect() mem charging friendly [ Upstream commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a ] While working on sk_forward_alloc problems reported by Denys Fedoryshchenko, we found that tcp connect() (and fastopen) do not call sk_wmem_schedule() for SYN packet (and/or SYN/DATA packet), so sk_forward_alloc is negative while connect is in progress. We can fix this by calling regular sk_stream_alloc_skb() both for the SYN packet (in tcp_connect()) and the syn_data packet in tcp_send_syn_data() Then, tcp_send_syn_data() can avoid copying syn_data as we simply can manipulate syn_data->cb[] to remove SYN flag (and increment seq) Instead of open coding memcpy_fromiovecend(), simply use this helper. This leaves in socket write queue clean fast clone skbs. This was tested against our fastopen packetdrill tests. Reported-by: Denys Fedoryshchenko Signed-off-by: Eric Dumazet Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 34ca18c8fbcd9debf4c558ab218f77c1d613f552 Author: Catalin Marinas Date: Fri Mar 20 16:48:13 2015 +0000 net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour [ Upstream commit 91edd096e224941131f896b86838b1e59553696a ] Commit db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an error) introduced the clamping of msg_namelen when the unsigned value was larger than sizeof(struct sockaddr_storage). This caused a msg_namelen of -1 to be valid. The native code was subsequently fixed by commit dbb490b96584 (net: socket: error on a negative msg_namelen). In addition, the native code sets msg_namelen to 0 when msg_name is NULL. This was done in commit (6a2a2b3ae075 net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr struct from userland) and subsequently updated by 08adb7dabd48 (fold verify_iovec() into copy_msghdr_from_user()). This patch brings the get_compat_msghdr() in line with copy_msghdr_from_user(). Fixes: db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an error) Cc: David S. Miller Cc: Dan Carpenter Signed-off-by: Catalin Marinas Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b182ecc84b3339e65569c01e0c8e3c09a0d9b6a4 Author: Josh Hunt Date: Thu Mar 19 19:19:30 2015 -0400 tcp: fix tcp fin memory accounting [ Upstream commit d22e1537181188e5dc8cbc51451832625035bdc2 ] tcp_send_fin() does not account for the memory it allocates properly, so sk_forward_alloc can be negative in cases where we've sent a FIN: ss example output (ss -amn | grep -B1 f4294): tcp FIN-WAIT-1 0 1 192.168.0.1:45520 192.0.2.1:8080 skmem:(r0,rb87380,t0,tb87380,f4294966016,w1280,o0,bl0) Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7f249ac587bcc0ed42a8aebf5240fe57171c8314 Author: Steven Barth Date: Thu Mar 19 16:16:04 2015 +0100 ipv6: fix backtracking for throw routes [ Upstream commit 73ba57bfae4a1914f6a6dac71e3168dd900e00af ] for throw routes to trigger evaluation of other policy rules EAGAIN needs to be propagated up to fib_rules_lookup similar to how its done for IPv4 A simple testcase for verification is: ip -6 rule add lookup 33333 priority 33333 ip -6 route add throw 2001:db8::1 ip -6 route add 2001:db8::1 via fe80::1 dev wlan0 table 33333 ip route get 2001:db8::1 Signed-off-by: Steven Barth Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5039b8cfb5efc13c18fe0de8fe63945f18ee45d7 Author: Ondrej Zary Date: Wed Mar 18 23:01:01 2015 +0100 Revert "net: cx82310_eth: use common match macro" [ Upstream commit 8d006e0105978619fb472e150c88b0d49337fe2b ] This reverts commit 11ad714b98f6d9ca0067568442afe3e70eb94845 because it breaks cx82310_eth. The custom USB_DEVICE_CLASS macro matches bDeviceClass, bDeviceSubClass and bDeviceProtocol but the common USB_DEVICE_AND_INTERFACE_INFO matches bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol instead, which are not specified. Signed-off-by: Ondrej Zary Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d1acc9e72b941480657c0a9877da467c0371ad5 Author: Al Viro Date: Sat Mar 14 05:34:56 2015 +0000 rxrpc: bogus MSG_PEEK test in rxrpc_recvmsg() [ Upstream commit 7d985ed1dca5c90535d67ce92ef6ca520302340a ] [I would really like an ACK on that one from dhowells; it appears to be quite straightforward, but...] MSG_PEEK isn't passed to ->recvmsg() via msg->msg_flags; as the matter of fact, neither the kernel users of rxrpc, nor the syscalls ever set that bit in there. It gets passed via flags; in fact, another such check in the same function is done correctly - as flags & MSG_PEEK. It had been that way (effectively disabled) for 8 years, though, so the patch needs beating up - that case had never been tested. If it is correct, it's -stable fodder. Signed-off-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 02bfe56e55e332c798cbf507bb157d66660dfd7b Author: Al Viro Date: Sat Mar 14 05:22:21 2015 +0000 caif: fix MSG_OOB test in caif_seqpkt_recvmsg() [ Upstream commit 3eeff778e00c956875c70b145c52638c313dfb23 ] It should be checking flags, not msg->msg_flags. It's ->sendmsg() instances that need to look for that in ->msg_flags, ->recvmsg() ones (including the other ->recvmsg() instance in that file, as well as unix_dgram_recvmsg() this one claims to be imitating) check in flags. Braino had been introduced in commit dcda13 ("caif: Bugfix - use MSG_TRUNC in receive") back in 2010, so it goes quite a while back. Signed-off-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e1f2092a94304bd8d9dbcdd12334ed8fac69161f Author: Eric Dumazet Date: Fri Mar 13 09:49:59 2015 -0700 inet_diag: fix possible overflow in inet_diag_dump_one_icsk() [ Upstream commit c8e2c80d7ec00d020320f905822bf49c5ad85250 ] inet_diag_dump_one_icsk() allocates too small skb. Add inet_sk_attr_size() helper right before inet_sk_diag_fill() so that it can be updated if/when new attributes are added. iproute2/ss currently does not use this dump_one() interface, this might explain nobody noticed this problem yet. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b9befa43034703b27026ef3f26d1993ce97163ff Author: Jason Wang Date: Thu Mar 12 13:57:44 2015 +0800 virtio-net: correctly delete napi hash [ Upstream commit ab3971b1e7d72270a2a259a29c1a40351b889740 ] We don't delete napi from hash list during module exit. This will cause the following panic when doing module load and unload: BUG: unable to handle kernel paging request at 0000004e00000075 IP: [] napi_hash_add+0x6b/0xf0 PGD 3c5d5067 PUD 0 Oops: 0000 [#1] SMP ... Call Trace: [] init_vqs+0x107/0x490 [virtio_net] [] virtnet_probe+0x562/0x791815639d880be [virtio_net] [] virtio_dev_probe+0x137/0x200 [] driver_probe_device+0x7a/0x250 [] __driver_attach+0x93/0xa0 [] ? __device_attach+0x40/0x40 [] bus_for_each_dev+0x63/0xa0 [] driver_attach+0x19/0x20 [] bus_add_driver+0x170/0x220 [] ? 0xffffffffa0a60000 [] driver_register+0x5f/0xf0 [] register_virtio_driver+0x1b/0x30 [] virtio_net_driver_init+0x10/0x12 [virtio_net] This patch fixes this by doing this in virtnet_free_queues(). And also don't delete napi in virtnet_freeze() since it will call virtnet_free_queues() which has already did this. Fixes 91815639d880 ("virtio-net: rx busy polling support") Cc: Rusty Russell Cc: Michael S. Tsirkin Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin Reviewed-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6ba8661b56d828d2c7b387e1f0b71cac7f70f08b Author: Arnd Bergmann Date: Wed Mar 11 22:46:59 2015 +0100 rds: avoid potential stack overflow [ Upstream commit f862e07cf95d5b62a5fc5e981dd7d0dbaf33a501 ] The rds_iw_update_cm_id function stores a large 'struct rds_sock' object on the stack in order to pass a pair of addresses. This happens to just fit withint the 1024 byte stack size warning limit on x86, but just exceed that limit on ARM, which gives us this warning: net/rds/iw_rdma.c:200:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=] As the use of this large variable is basically bogus, we can rearrange the code to not do that. Instead of passing an rds socket into rds_iw_get_device, we now just pass the two addresses that we have available in rds_iw_update_cm_id, and we change rds_iw_get_mr accordingly, to create two address structures on the stack there. Signed-off-by: Arnd Bergmann Acked-by: Sowmini Varadhan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c48cf4f27d4555a455c3fef71137bd0fc44d1656 Author: Alexey Kodanev Date: Wed Mar 11 14:29:17 2015 +0300 net: sysctl_net_core: check SNDBUF and RCVBUF for min length [ Upstream commit b1cb59cf2efe7971d3d72a7b963d09a512d994c9 ] sysctl has sysctl.net.core.rmem_*/wmem_* parameters which can be set to incorrect values. Given that 'struct sk_buff' allocates from rcvbuf, incorrectly set buffer length could result to memory allocation failures. For example, set them as follows: # sysctl net.core.rmem_default=64 net.core.wmem_default = 64 # sysctl net.core.wmem_default=64 net.core.wmem_default = 64 # ping localhost -s 1024 -i 0 > /dev/null This could result to the following failure: skbuff: skb_over_panic: text:ffffffff81628db4 len:-32 put:-32 head:ffff88003a1cc200 data:ffff88003a1cc200 tail:0xffffffe0 end:0xc0 dev: kernel BUG at net/core/skbuff.c:102! invalid opcode: 0000 [#1] SMP ... task: ffff88003b7f5550 ti: ffff88003ae88000 task.ti: ffff88003ae88000 RIP: 0010:[] [] skb_put+0xa1/0xb0 RSP: 0018:ffff88003ae8bc68 EFLAGS: 00010296 RAX: 000000000000008d RBX: 00000000ffffffe0 RCX: 0000000000000000 RDX: ffff88003fdcf598 RSI: ffff88003fdcd9c8 RDI: ffff88003fdcd9c8 RBP: ffff88003ae8bc88 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 00000000000002b2 R12: 0000000000000000 R13: 0000000000000000 R14: ffff88003d3f7300 R15: ffff88000012a900 FS: 00007fa0e2b4a840(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000d0f7e0 CR3: 000000003b8fb000 CR4: 00000000000006f0 Stack: ffff88003a1cc200 00000000ffffffe0 00000000000000c0 ffffffff818cab1d ffff88003ae8bd68 ffffffff81628db4 ffff88003ae8bd48 ffff88003b7f5550 ffff880031a09408 ffff88003b7f5550 ffff88000012aa48 ffff88000012ab00 Call Trace: [] unix_stream_sendmsg+0x2c4/0x470 [] sock_write_iter+0x146/0x160 [] new_sync_write+0x92/0xd0 [] vfs_write+0xd6/0x180 [] SyS_write+0x59/0xd0 [] system_call_fastpath+0x12/0x17 Code: 00 00 48 89 44 24 10 8b 87 c8 00 00 00 48 89 44 24 08 48 8b 87 d8 00 00 00 48 c7 c7 30 db 91 81 48 89 04 24 31 c0 e8 4f a8 0e 00 <0f> 0b eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 RIP [] skb_put+0xa1/0xb0 RSP Kernel panic - not syncing: Fatal exception Moreover, the possible minimum is 1, so we can get another kernel panic: ... BUG: unable to handle kernel paging request at ffff88013caee5c0 IP: [] __alloc_skb+0x12f/0x1f0 ... Signed-off-by: Alexey Kodanev Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 563d9192f9af5e02bfac34676e84b9c3909ef732 Author: Nimrod Andy Date: Tue Mar 10 19:09:41 2015 +0800 net: fec: fix receive VLAN CTAG HW acceleration issue [ Upstream commit af5cbc9822f6bbe399925760a4d5ee82c21f258c ] The current driver support receive VLAN CTAG HW acceleration feature (NETIF_F_HW_VLAN_CTAG_RX) through software simulation. There calls the api .skb_copy_to_linear_data_offset() to skip the VLAN tag, but there have overlap between the two memory data point range. The patch just fix the issue. V2: Michael Grzeschik suggest to use memmove() instead of skb_copy_to_linear_data_offset(). Reported-by: Michael Grzeschik Fixes: 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx performance") Signed-off-by: Fugang Duan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 06e0dd736849f9e34828fa9771298ecef0e49511 Author: WANG Cong Date: Mon Mar 9 17:03:40 2015 -0700 net_sched: fix struct tc_u_hnode layout in u32 [ Upstream commit 5778d39d070b4ac5f889928175b7f2d53ae7504e ] We dynamically allocate divisor+1 entries for ->ht[] in tc_u_hnode: ht = kzalloc(sizeof(*ht) + divisor*sizeof(void *), GFP_KERNEL); So ->ht is supposed to be the last field of this struct, however this is broken, since an rcu head is appended after it. Fixes: 1ce87720d456 ("net: sched: make cls_u32 lockless") Cc: Jamal Hadi Salim Cc: John Fastabend Signed-off-by: Cong Wang Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 62268585e544179b6694a13836ea34229817c57e Author: David S. Miller Date: Mon Mar 23 09:22:10 2015 -0700 sparc64: Fix several bugs in memmove(). [ Upstream commit 2077cef4d5c29cf886192ec32066f783d6a80db8 ] Firstly, handle zero length calls properly. Believe it or not there are a few of these happening during early boot. Next, we can't just drop to a memcpy() call in the forward copy case where dst <= src. The reason is that the cache initializing stores used in the Niagara memcpy() implementations can end up clearing out cache lines before we've sourced their original contents completely. For example, considering NG4memcpy, the main unrolled loop begins like this: load src + 0x00 load src + 0x08 load src + 0x10 load src + 0x18 load src + 0x20 store dst + 0x00 Assume dst is 64 byte aligned and let's say that dst is src - 8 for this memcpy() call. That store at the end there is the one to the first line in the cache line, thus clearing the whole line, which thus clobbers "src + 0x28" before it even gets loaded. To avoid this, just fall through to a simple copy only mildly optimized for the case where src and dst are 8 byte aligned and the length is a multiple of 8 as well. We could get fancy and call GENmemcpy() but this is good enough for how this thing is actually used. Reported-by: David Ahern Reported-by: Bob Picco Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 54762bf14816b87f86fc704ae7a438ff8f9ad5de Author: David Ahern Date: Thu Mar 19 16:06:53 2015 -0400 sparc: Touch NMI watchdog when walking cpus and calling printk [ Upstream commit 31aaa98c248da766ece922bbbe8cc78cfd0bc920 ] With the increase in number of CPUs calls to functions that dump output to console (e.g., arch_trigger_all_cpu_backtrace) can take a long time to complete. If IRQs are disabled eventually the NMI watchdog kicks in and creates more havoc. Avoid by telling the NMI watchdog everything is ok. Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4cd5bcca298e2a3210d4d043af3c1ac673b99b42 Author: David Ahern Date: Thu Mar 19 16:06:17 2015 -0400 sparc: perf: Make counting mode actually work [ Upstream commit d51291cb8f32bfae6b331e1838651f3ddefa73a5 ] Currently perf-stat (aka, counting mode) does not work: $ perf stat ls ... Performance counter stats for 'ls': 1.585665 task-clock (msec) # 0.580 CPUs utilized 24 context-switches # 0.015 M/sec 0 cpu-migrations # 0.000 K/sec 86 page-faults # 0.054 M/sec cycles stalled-cycles-frontend stalled-cycles-backend instructions branches branch-misses 0.002735100 seconds time elapsed The reason is that state is never reset (stays with PERF_HES_UPTODATE set). Add a call to sparc_pmu_enable_event during the added_event handling. Clean up the encoding since pmu_start calls sparc_pmu_enable_event which does the same. Passing PERF_EF_RELOAD to sparc_pmu_start means the call to sparc_perf_event_set_period can be removed as well. With this patch: $ perf stat ls ... Performance counter stats for 'ls': 1.552890 task-clock (msec) # 0.552 CPUs utilized 24 context-switches # 0.015 M/sec 0 cpu-migrations # 0.000 K/sec 86 page-faults # 0.055 M/sec 5,748,997 cycles # 3.702 GHz stalled-cycles-frontend:HG stalled-cycles-backend:HG 1,684,362 instructions:HG # 0.29 insns per cycle 295,133 branches:HG # 190.054 M/sec 28,007 branch-misses:HG # 9.49% of all branches 0.002815665 seconds time elapsed Signed-off-by: David Ahern Acked-by: Bob Picco Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 84763ada0622343e9bc3032a87f6c60191e93a11 Author: David Ahern Date: Thu Mar 19 16:05:57 2015 -0400 sparc: perf: Remove redundant perf_pmu_{en|dis}able calls [ Upstream commit 5b0d4b5514bbcce69b516d0742f2cfc84ebd6db3 ] perf_pmu_disable is called by core perf code before pmu->del and the enable function is called by core perf code afterwards. No need to call again within sparc_pmu_del. Ditto for pmu->add and sparc_pmu_add. Signed-off-by: David Ahern Acked-by: Bob Picco Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4fb82ed6c0e10d4386a70cca22fbe8bf56eadb9e Author: Rob Gardner Date: Mon Mar 2 23:16:55 2015 -0700 sparc: semtimedop() unreachable due to comparison error [ Upstream commit 53eb2516972b8c4628651dfcb926cb9ef8b2864a ] A bug was reported that the semtimedop() system call was always failing eith ENOSYS. Since SEMCTL is defined as 3, and SEMTIMEDOP is defined as 4, the comparison "call <= SEMCTL" will always prevent SEMTIMEDOP from getting through to the semaphore ops switch statement. This is corrected by changing the comparison to "call <= SEMTIMEDOP". Orabug: 20633375 Signed-off-by: Rob Gardner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b8b07bdf44650f331967b63875311a95d4b4d87d Author: Andreas Larsson Date: Thu Dec 18 13:23:23 2014 +0100 sparc32: destroy_context() and switch_mm() needs to disable interrupts. [ Upstream commit 66d0f7ec9f1038452178b1993fc07fd96d30fd38 ] Load balancing can be triggered in the critical sections protected by srmmu_context_spinlock in destroy_context() and switch_mm() and can hang the cpu waiting for the rq lock of another cpu that in turn has called switch_mm hangning on srmmu_context_spinlock leading to deadlock. So, disable interrupt while taking srmmu_context_spinlock in destroy_context() and switch_mm() so we don't deadlock. See also commit 77b838fa1ef0 ("[SPARC64]: destroy_context() needs to disable interrupts.") Signed-off-by: Andreas Larsson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin