commit 64124d136db6d4fe8508125c6378d8d3fe89ad0c Author: Jiri Slaby Date: Mon Oct 17 09:48:06 2016 +0200 Linux 3.12.65 commit 168e5ebbd63eaf2557b5e37be1afb8c143de2380 Author: James Hogan Date: Thu Sep 15 17:20:06 2016 +0100 KVM: MIPS: Drop other CPU ASIDs on guest MMU changes commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream. When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate TLB entries on the local CPU. This doesn't work correctly on an SMP host when the guest is migrated to a different physical CPU, as it could pick up stale TLB mappings from the last time the vCPU ran on that physical CPU. Therefore invalidate both user and kernel host ASIDs on other CPUs, which will cause new ASIDs to be generated when it next runs on those CPUs. We're careful only to do this if the TLB entry was already valid, and only for the kernel ASID where the virtual address it mapped is outside of the guest user address range. Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Jiri Slaby commit 50b5e30e8111f88029dd0f6e922251f1839a1044 Author: Thomas Huth Date: Wed Sep 21 15:06:45 2016 +0200 KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register commit fa73c3b25bd8d0d393dc6109a1dba3c2aef0451e upstream. The MMCR2 register is available twice, one time with number 785 (privileged access), and one time with number 769 (unprivileged, but it can be disabled completely). In former times, the Linux kernel was using the unprivileged register 769 only, but since commit 8dd75ccb571f3c92c ("powerpc: Use privileged SPR number for MMCR2"), it uses the privileged register 785 instead. The KVM-PR code then of course also switched to use the SPR 785, but this is causing older guest kernels to crash, since these kernels still access 769 instead. So to support older kernels with KVM-PR again, we have to support register 769 in KVM-PR, too. Fixes: 8dd75ccb571f3c92c48014b3dabd3d51a115ab41 Signed-off-by: Thomas Huth Signed-off-by: Paul Mackerras Signed-off-by: Jiri Slaby commit dc4a264e8c427223541d96130edc3f9103fbcd3f Author: Uwe Kleine-König Date: Fri Jul 29 21:29:15 2016 +0200 mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled commit 88003fb10f1fc606e1704611c62ceae95fd1d7da upstream. This fixes a compile failure: drivers/built-in.o: In function `wm8350_i2c_probe': core.c:(.text+0x828b0): undefined reference to `__devm_regmap_init_i2c' Makefile:953: recipe for target 'vmlinux' failed Fixes: 52b461b86a9f ("mfd: Add regmap cache support for wm8350") Signed-off-by: Uwe Kleine-König Acked-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Jiri Slaby commit b13589e8b0ec18ce4efc9e67b20bf06c341608c3 Author: Dan Carpenter Date: Thu Aug 4 08:26:56 2016 +0300 mfd: 88pm80x: Double shifting bug in suspend/resume commit 9a6dc644512fd083400a96ac4a035ac154fe6b8d upstream. set_bit() and clear_bit() take the bit number so this code is really doing "1 << (1 << irq)" which is a double shift bug. It's done consistently so it won't cause a problem unless "irq" is more than 4. Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver') Signed-off-by: Dan Carpenter Signed-off-by: Lee Jones Signed-off-by: Jiri Slaby commit 841abffa182dfd9f19e3420037b3edad18916f9c Author: Takashi Sakamoto Date: Sun Sep 25 22:00:20 2016 +0900 ALSA: usb-line6: use the same declaration as definition in header for MIDI manufacturer ID commit 8da08ca03b73593d5299893bf29fc08569c3fb5f upstream. Currently, usb-line6 module exports an array of MIDI manufacturer ID and usb-pod module uses it. However, the declaration is not the definition in common header. The difference is explicit length of array. Although compiler calculates it and everything goes well, it's better to use the same representation between definition and declaration. This commit fills the length of array for usb-line6 module. As a small good sub-effect, this commit suppress below warnings from static analysis by sparse v0.5.0. sound/usb/line6/driver.c:274:43: error: cannot size expression sound/usb/line6/driver.c:275:16: error: cannot size expression sound/usb/line6/driver.c:276:16: error: cannot size expression sound/usb/line6/driver.c:277:16: error: cannot size expression Fixes: 705ececd1c60 ("Staging: add line6 usb driver") Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit b3b34980847468b6bb0b26b3909e514a1c47d383 Author: Takashi Iwai Date: Wed Sep 21 14:38:02 2016 +0200 ALSA: ali5451: Fix out-of-bound position reporting commit db68577966abc1aeae4ec597b3dcfa0d56e92041 upstream. The pointer callbacks of ali5451 driver may return the value at the boundary occasionally, and it results in the kernel warning like snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024 It seems that folding the position offset is enough for fixing the warning and no ill-effect has been seen by that. Reported-by: Enrico Mioso Tested-by: Enrico Mioso Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit cf28bd0ce8c6f14374c8747bbcb73f1d0afd6d91 Author: Alexander Graf Date: Fri Apr 25 16:07:21 2014 +0200 KVM: PPC: Book3S PR: Emulate TIR register commit a5948fa092a04dfd6b9ee31c99eb6896c158eb08 upstream. In parallel to the Processor ID Register (PIR) threaded POWER8 also adds a Thread ID Register (TIR). Since PR KVM doesn't emulate more than one thread per core, we can just always expose 0 here. Signed-off-by: Alexander Graf Signed-off-by: Jiri Slaby commit 3bf7e13f8efaddeb67174fe66537a2eab35544a2 Author: Alexander Graf Date: Tue Apr 22 12:41:06 2014 +0200 KVM: PPC: Book3S PR: Ignore PMU SPRs commit f8f6eb0d189cf2724af5ebc8cad460c78fb1994e upstream. When we expose a POWER8 CPU into the guest, it will start accessing PMU SPRs that we don't emulate. Just ignore accesses to them. Signed-off-by: Alexander Graf Signed-off-by: Jiri Slaby commit d0a76cede6667d365eaba9c9f5f342f3266ca2cf Author: Jann Horn Date: Wed Jan 20 15:00:01 2016 -0800 security: let security modules use PTRACE_MODE_* with bitmasks commit 3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 upstream. It looks like smack and yama weren't aware that the ptrace mode can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch, all modes have flags ORed into them. [js] no smack changes in 3.12 as the code is not there yet Signed-off-by: Jann Horn Acked-by: Kees Cook Acked-by: Casey Schaufler Cc: Oleg Nesterov Cc: Ingo Molnar Cc: James Morris Cc: "Serge E. Hallyn" Cc: Andy Shevchenko Cc: Andy Lutomirski Cc: Al Viro Cc: "Eric W. Biederman" Cc: Willy Tarreau Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit b1c40c03452e58440e286fdffc7a725fab4c2e76 Author: Prarit Bhargava Date: Tue Dec 29 13:52:41 2015 +0800 ACPICA: acpi_get_sleep_type_data: Reduce warnings commit a59b679ab85635737947310323f2f2bcfa0664a7 upstream. ACPICA commit 7bb77313091e52a846df4c9c2bea90be31bfb9d8 Eliminate warnings for "not found" _Sx errors, since these are optional. Original NOT_FOUND status is still returned. Original changes by Prarit Bhargava. ACPICA BZ 1208. Link: https://github.com/acpica/acpica/commit/7bb77313 Link: https://bugs.acpica.org/show_bug.cgi?id=1208 Signed-off-by: Prarit Bhargava Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Cc: "Charles (Chas) Williams" Signed-off-by: Jiri Slaby commit f50798220707b64d67b530dba36a972467c81f23 Author: Greg Kroah-Hartman Date: Wed Sep 28 11:48:44 2016 +0200 Revert "usbtmc: convert to devm_kzalloc" commit ab21b63e8aedfc73565dd9cdd51eb338341177cb upstream. This reverts commit e6c7efdcb76f11b04e3d3f71c8d764ab75c9423b. Turns out it was totally wrong. The memory is supposed to be bound to the kref, as the original code was doing correctly, not the device/driver binding as the devm_kzalloc() would cause. This fixes an oops when read would be called after the device was unbound from the driver. Reported-by: Ladislav Michl Cc: Andy Shevchenko Signed-off-by: Jiri Slaby commit bf170848ce79f15ea877392729e0aebe637363f0 Author: Kyle Jones Date: Fri Sep 23 13:28:37 2016 -0500 USB: serial: cp210x: Add ID for a Juniper console commit decc5360f23e9efe0252094f47f57f254dcbb3a9 upstream. Signed-off-by: Kyle Jones Signed-off-by: Jiri Slaby commit 55b6c165bdf9b2808137cc5d49066e8a5344622a Author: Greg Kroah-Hartman Date: Mon Sep 19 19:09:51 2016 +0100 usb: misc: legousbtower: Fix NULL pointer deference commit 2fae9e5a7babada041e2e161699ade2447a01989 upstream. This patch fixes a NULL pointer dereference caused by a race codition in the probe function of the legousbtower driver. It re-structures the probe function to only register the interface after successfully reading the board's firmware ID. The probe function does not deregister the usb interface after an error receiving the devices firmware ID. The device file registered (/dev/usb/legousbtower%d) may be read/written globally before the probe function returns. When tower_delete is called in the probe function (after an r/w has been initiated), core dev structures are deleted while the file operation functions are still running. If the 0 address is mappable on the machine, this vulnerability can be used to create a Local Priviege Escalation exploit via a write-what-where condition by remapping dev->interrupt_out_buffer in tower_write. A forged USB device and local program execution would be required for LPE. The USB device would have to delay the control message in tower_probe and accept the control urb in tower_open whilst guest code initiated a write to the device file as tower_delete is called from the error in tower_probe. This bug has existed since 2003. Patch tested by emulated device. Reported-by: James Patrick-Evans Tested-by: James Patrick-Evans Signed-off-by: James Patrick-Evans Signed-off-by: Jiri Slaby commit 70104af05fc8ad4f85510b8d442d0bd1886ed716 Author: Konstantin Shkolnyy Date: Wed May 4 16:56:52 2016 -0500 USB: serial: cp210x: fix hardware flow-control disable commit a377f9e906af4df9071ba8ddba60188cb4013d93 upstream. A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS is transmit active signal" and CRTSCTS=1 => "RTS is used for receive flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS is used for receive flow control" This only happened after first having enabled CRTSCTS. Signed-off-by: Konstantin Shkolnyy Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control") [johan: reword commit message ] Signed-off-by: Johan Hovold [johan: backport to 4.4 ] Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 3a6d50fe6a54175cadd8e0f3881cfff3ef5ca82c Author: Alex Vesker Date: Mon Sep 12 19:16:18 2016 +0300 IB/mlx4: Fix incorrect MC join state bit-masking on SR-IOV commit e5ac40cd66c2f3cd11bc5edc658f012661b16347 upstream. Because of an incorrect bit-masking done on the join state bits, when handling a join request we failed to detect a difference between the group join state and the request join state when joining as send only full member (0x8). This caused the MC join request not to be sent. This issue is relevant only when SRIOV is enabled and SM supports send only full member. This fix separates scope bits and join states bits a nibble each. Fixes: b9c5d6a64358 ('IB/mlx4: Add multicast group (MCG) paravirtualization for SR-IOV') Signed-off-by: Alex Vesker Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 8a9d8dc9ce83a90bfbbe69181acc4cf1beff46f5 Author: Alex Vesker Date: Mon Sep 12 09:55:28 2016 +0300 IB/ipoib: Don't allow MC joins during light MC flush commit 344bacca8cd811809fc33a249f2738ab757d327f upstream. This fix solves a race between light flush and on the fly joins. Light flush doesn't set the device to down and unset IPOIB_OPER_UP flag, this means that if while flushing we have a MC join in progress and the QP was attached to BC MGID we can have a mismatches when re-attaching a QP to the BC MGID. The light flush would set the broadcast group to NULL causing an on the fly join to rejoin and reattach to the BC MCG as well as adding the BC MGID to the multicast list. The flush process would later on remove the BC MGID and detach it from the QP. On the next flush the BC MGID is present in the multicast list but not found when trying to detach it because of the previous double attach and single detach. [18332.714265] ------------[ cut here ]------------ [18332.717775] WARNING: CPU: 6 PID: 3767 at drivers/infiniband/core/verbs.c:280 ib_dealloc_pd+0xff/0x120 [ib_core] ... [18332.775198] Hardware name: Red Hat KVM, BIOS Bochs 01/01/2011 [18332.779411] 0000000000000000 ffff8800b50dfbb0 ffffffff813fed47 0000000000000000 [18332.784960] 0000000000000000 ffff8800b50dfbf0 ffffffff8109add1 0000011832f58300 [18332.790547] ffff880226a596c0 ffff880032482000 ffff880032482830 ffff880226a59280 [18332.796199] Call Trace: [18332.798015] [] dump_stack+0x63/0x8c [18332.801831] [] __warn+0xd1/0xf0 [18332.805403] [] warn_slowpath_null+0x1d/0x20 [18332.809706] [] ib_dealloc_pd+0xff/0x120 [ib_core] [18332.814384] [] ipoib_transport_dev_cleanup+0xfc/0x1d0 [ib_ipoib] [18332.820031] [] ipoib_ib_dev_cleanup+0x98/0x110 [ib_ipoib] [18332.825220] [] ipoib_dev_cleanup+0x2d8/0x550 [ib_ipoib] [18332.830290] [] ipoib_uninit+0x2f/0x40 [ib_ipoib] [18332.834911] [] rollback_registered_many+0x1aa/0x2c0 [18332.839741] [] rollback_registered+0x31/0x40 [18332.844091] [] unregister_netdevice_queue+0x48/0x80 [18332.848880] [] ipoib_vlan_delete+0x1fb/0x290 [ib_ipoib] [18332.853848] [] delete_child+0x7d/0xf0 [ib_ipoib] [18332.858474] [] dev_attr_store+0x18/0x30 [18332.862510] [] sysfs_kf_write+0x3a/0x50 [18332.866349] [] kernfs_fop_write+0x120/0x170 [18332.870471] [] __vfs_write+0x28/0xe0 [18332.874152] [] ? percpu_down_read+0x1f/0x50 [18332.878274] [] vfs_write+0xa2/0x1a0 [18332.881896] [] SyS_write+0x46/0xa0 [18332.885632] [] do_syscall_64+0x57/0xb0 [18332.889709] [] entry_SYSCALL64_slow_path+0x25/0x25 [18332.894727] ---[ end trace 09ebbe31f831ef17 ]--- Fixes: ee1e2c82c245 ("IPoIB: Refresh paths instead of flushing them on SM change events") Signed-off-by: Alex Vesker Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 72ff96b3154c4215c584b60bd7da45eec52a3431 Author: Erez Shitrit Date: Sun Aug 28 10:58:30 2016 +0300 IB/core: Fix use after free in send_leave function commit 68c6bcdd8bd00394c234b915ab9b97c74104130c upstream. The function send_leave sets the member: group->query_id (group->query_id = ret) after calling the sa_query, but leave_handler can be executed before the setting and it might delete the group object, and will get a memory corruption. Additionally, this patch gets rid of group->query_id variable which is not used. Fixes: faec2f7b96b5 ('IB/sa: Track multicast join/leave requests') Signed-off-by: Erez Shitrit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 711b7a2b0fabb47eed6f1e4bf9f91e11f06be045 Author: Erez Shitrit Date: Sun Aug 28 10:58:31 2016 +0300 IB/ipoib: Fix memory corruption in ipoib cm mode connect flow commit 546481c2816ea3c061ee9d5658eb48070f69212e upstream. When a new CM connection is being requested, ipoib driver copies data from the path pointer in the CM/tx object, the path object might be invalid at the point and memory corruption will happened later when now the CM driver will try using that data. The next scenario demonstrates it: neigh_add_path --> ipoib_cm_create_tx --> queue_work (pointer to path is in the cm/tx struct) #while the work is still in the queue, #the port goes down and causes the ipoib_flush_paths: ipoib_flush_paths --> path_free --> kfree(path) #at this point the work scheduled starts. ipoib_cm_tx_start --> copy from the (invalid)path pointer: (memcpy(&pathrec, &p->path->pathrec, sizeof pathrec);) -> memory corruption. To fix that the driver now starts the CM/tx connection only if that specific path exists in the general paths database. This check is protected with the relevant locks, and uses the gid from the neigh member in the CM/tx object which is valid according to the ref count that was taken by the CM/tx. Fixes: 839fcaba35 ('IPoIB: Connected mode experimental support') Signed-off-by: Erez Shitrit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit f6829ed2fa5287b378c9bd0ad24d43861c69070c Author: Radim Krčmář Date: Mon Aug 8 20:16:23 2016 +0200 KVM: nVMX: postpone VMCS changes on MSR_IA32_APICBASE write commit dccbfcf52cebb8963246eba5b177b77f26b34da0 upstream. If vmcs12 does not intercept APIC_BASE writes, then KVM will handle the write with vmcs02 as the current VMCS. This will incorrectly apply modifications intended for vmcs01 to vmcs02 and L2 can use it to gain access to L0's x2APIC registers by disabling virtualized x2APIC while using msr bitmap that assumes enabled. Postpone execution of vmx_set_virtual_x2apic_mode until vmcs01 is the current VMCS. An alternative solution would temporarily make vmcs01 the current VMCS, but it requires more care. Fixes: 8d14695f9542 ("x86, apicv: add virtual x2apic support") Reported-by: Jim Mattson Reviewed-by: Wanpeng Li Signed-off-by: Radim Krčmář Signed-off-by: Jiri Slaby commit fd4d32067be5014cff77c8f4c61c395ee7248ab9 Author: Peter Ujfalusi Date: Tue Aug 23 10:27:19 2016 +0300 ASoC: omap-mcpdm: Fix irq resource handling commit a8719670687c46ed2e904c0d05fa4cd7e4950cd1 upstream. Fixes: ddd17531ad908 ("ASoC: omap-mcpdm: Clean up with devm_* function") Managed irq request will not doing any good in ASoC probe level as it is not going to free up the irq when the driver is unbound from the sound card. Signed-off-by: Peter Ujfalusi Reported-by: Russell King Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 0025fcb8532a1f0a8ff566943a3b43419c4dcc6c Author: Michael Ellerman Date: Fri Aug 12 21:45:52 2016 +1000 powerpc/prom: Fix sub-processor option passed to ibm, client-architecture-support commit 66443efa83dc73775100b7442962ce2cb0d4472e upstream. When booting from an OpenFirmware which supports it, we use the "ibm,client-architecture-support" firmware call to communicate our capabilities to firmware. The format of the structure we pass to firmware is specified in PAPR (Power Architecture Platform Requirements), or the public version LoPAPR (Linux on Power Architecture Platform Reference). Referring to table 244 in LoPAPR v1.1, option vector 5 contains a 4 byte field at bytes 17-20 for the "Platform Facilities Enable". This is followed by a 1 byte field at byte 21 for "Sub-Processor Represenation Level". Comparing to the code, there we have the Platform Facilities options (OV5_PFO_*) at byte 17, but we fail to pad that field out to its full width of 4 bytes. This means the OV5_SUB_PROCESSORS option is incorrectly placed at byte 18. Fix it by adding zero bytes for bytes 18, 19, 20, and comment the bytes to hopefully make it clearer in future. As far as I'm aware nothing actually consumes this value at this time, so the effect of this bug is nil in practice. It does mean we've been incorrectly setting bit 15 of the "Platform Facilities Enable" option for the past ~3 1/2 years, so we should avoid allocating that bit to anything else in future. Fixes: df77c7992029 ("powerpc/pseries: Update ibm,architecture.vec for PAPR 2.7/POWER8") Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 8477def3d2180df5cb4cf8a7a3b6de938d076033 Author: Florian Fainelli Date: Mon Jul 18 16:24:37 2016 -0700 brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get() commit f823a2aa8f4674c095a5413b9e3ba12d82df06f2 upstream. wlc_phy_txpower_get_current() does a logical OR of power->flags, which presumes that power.flags was initiliazed earlier by the caller, unfortunately, this is not the case, so make sure we zero out the struct tx_power before calling into wlc_phy_txpower_get_current(). Reported-by: coverity (CID 146011) Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers") Signed-off-by: Florian Fainelli Acked-by: Arend van Spriel Signed-off-by: Kalle Valo Signed-off-by: Jiri Slaby commit a2fc96f78a6e8c585d768aab3b22d00dc096ce4d Author: Florian Fainelli Date: Mon Jul 18 16:24:35 2016 -0700 brcmsmac: Free packet if dma_mapping_error() fails in dma_rxfill commit 5c5fa1f464ac954982df1d96b9f9a5103d21aedd upstream. In case dma_mapping_error() returns an error in dma_rxfill, we would be leaking a packet that we allocated with brcmu_pkt_buf_get_skb(). Reported-by: coverity (CID 1081819) Fixes: 67d0cf50bd32 ("brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()") Signed-off-by: Florian Fainelli Acked-by: Arend van Spriel Signed-off-by: Kalle Valo Signed-off-by: Jiri Slaby commit 9ed365af7518fe62d50f24d70829bd437f443c33 Author: Chuck Lever Date: Wed Jun 29 13:55:22 2016 -0400 NFS: Don't drop CB requests with invalid principals commit a4e187d83d88eeaba6252aac0a2ffe5eaa73a818 upstream. Before commit 778be232a207 ("NFS do not find client in NFSv4 pg_authenticate"), the Linux callback server replied with RPC_AUTH_ERROR / RPC_AUTH_BADCRED, instead of dropping the CB request. Let's restore that behavior so the server has a chance to do something useful about it, and provide a warning that helps admins correct the problem. Fixes: 778be232a207 ("NFS do not find client in NFSv4 ...") Signed-off-by: Chuck Lever Tested-by: Steve Wise Signed-off-by: Anna Schumaker Signed-off-by: Jiri Slaby commit a298420136714ed7e91bf8f76bddbdabda35c1e3 Author: Chuck Lever Date: Wed Jun 29 13:55:14 2016 -0400 svc: Avoid garbage replies when pc_func() returns rpc_drop_reply commit 0533b13072f4bf35738290d2cf9e299c7bc6c42a upstream. If an RPC program does not set vs_dispatch and pc_func() returns rpc_drop_reply, the server sends a reply anyway containing a single word containing the value RPC_DROP_REPLY (in network byte-order, of course). This is a nonsense RPC message. Fixes: 9e701c610923 ("svcrpc: simpler request dropping") Signed-off-by: Chuck Lever Tested-by: Steve Wise Signed-off-by: Anna Schumaker Signed-off-by: Jiri Slaby commit 5bc28d50a47c0d8c79f3c318736781cd83952963 Author: Dan Carpenter Date: Wed Jul 13 13:08:55 2016 +0300 avr32: off by one in at32_init_pio() commit 55f1cf83d5cf885c75267269729805852039c834 upstream. The pio_dev[] array has MAX_NR_PIO_DEVICES elements so the > should be >=. Fixes: 5f97f7f9400d ('[PATCH] avr32 architecture') Signed-off-by: Dan Carpenter Signed-off-by: Jiri Slaby commit 4ecf557350704055cba0f3eff9bcc5ab8bd7d4df Author: Arnd Bergmann Date: Mon Jul 4 10:21:40 2016 -0300 gspca: avoid unused variable warnings commit d7e92e15e92fc987640772bf110586898b5f15aa upstream. When CONFIG_INPUT is disabled, multiple gspca backend drivers print compile-time warnings about unused variables: media/usb/gspca/cpia1.c: In function 'sd_stopN': media/usb/gspca/cpia1.c:1627:13: error: unused variable 'sd' [-Werror=unused-variable] media/usb/gspca/konica.c: In function 'sd_stopN': media/usb/gspca/konica.c:246:13: error: unused variable 'sd' [-Werror=unused-variable] This annotates the variables as __maybe_unused, to let the compiler know that they are declared intentionally. Fixes: ee186fd96a5f ("[media] gscpa_t613: Add support for the camera button") Fixes: c2f644aeeba3 ("[media] gspca_cpia1: Add support for button") Fixes: b517af722860 ("V4L/DVB: gspca_konica: New gspca subdriver for konica chipset using cams") Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit e7489df4b7f8cb12522a52a28e381ac4a60a9bc5 Author: Dan Carpenter Date: Mon May 9 05:22:55 2016 -0300 em28xx-i2c: rt_mutex_trylock() returns zero on failure commit e44c153b30c9a0580fc2b5a93f3c6d593def2278 upstream. The code is checking for negative returns but it should be checking for zero. Fixes: aab3125c43d8 ('[media] em28xx: add support for registering multiple i2c buses') Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit 4d85f96ee10cdeaa306652a4aeffc73bdc76708d Author: James Hogan Date: Mon Jul 25 16:59:54 2016 +0100 tile: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO commit cdf8b4633075f2171d440d2e37c9c2609019a81a upstream. AT_VECTOR_SIZE_ARCH should be defined with the maximum number of NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined for tile at all even though ARCH_DLINFO will contain one NEW_AUX_ENT for the VDSO address. This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for AT_BASE_PLATFORM which tile doesn't use, but lets define it now and add the comment above ARCH_DLINFO as found in several other architectures to remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to date. Fixes: 4a556f4f56da ("tile: implement gettimeofday() via vDSO") Signed-off-by: James Hogan Cc: Chris Metcalf Signed-off-by: Chris Metcalf Signed-off-by: Jiri Slaby commit b4c3486e71beef32a2e67451a0e916e894401afe Author: Nishanth Menon Date: Fri Jun 24 11:50:39 2016 -0500 hwrng: omap - Fix assumption that runtime_get_sync will always succeed commit 61dc0a446e5d08f2de8a24b45f69a1e302bb1b1b upstream. pm_runtime_get_sync does return a error value that must be checked for error conditions, else, due to various reasons, the device maynot be enabled and the system will crash due to lack of clock to the hardware module. Before: 12.562784] [00000000] *pgd=fe193835 12.562792] Internal error: : 1406 [#1] SMP ARM [...] 12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2 12.562867] Hardware name: Generic DRA74X (Flattened Device Tree) 12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000 12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng] 12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core] [...] After the proper checks: [ 94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info [ 94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19 [ 94.382351] omap_rng 48090000.rng: initialization failed. Fixes: 665d92fa85b5 ("hwrng: OMAP: convert to use runtime PM") Cc: Paul Walmsley Signed-off-by: Nishanth Menon Signed-off-by: Herbert Xu Signed-off-by: Jiri Slaby commit 6fd1d5bfa438a89147b968ea7c56350b4940df79 Author: Russell King Date: Tue Sep 6 14:34:05 2016 +0100 ARM: sa1111: fix pcmcia suspend/resume commit 06dfe5cc0cc684e735cb0232fdb756d30780b05d upstream. SA1111 PCMCIA was broken when PCMCIA switched to using dev_pm_ops for the PCMCIA socket class. PCMCIA used to handle suspend/resume via the socket hosting device, which happened at normal device suspend/resume time. However, the referenced commit changed this: much of the resume now happens much earlier, in the noirq resume handler of dev_pm_ops. However, on SA1111, the PCMCIA device is not accessible as the SA1111 has not been resumed at _noirq time. It's slightly worse than that, because the SA1111 has already been put to sleep at _noirq time, so suspend doesn't work properly. Fix this by converting the core SA1111 code to use dev_pm_ops as well, and performing its own suspend/resume at noirq time. This fixes these errors in the kernel log: pcmcia_socket pcmcia_socket0: time out after reset pcmcia_socket pcmcia_socket1: time out after reset and the resulting lack of PCMCIA cards after a S2RAM cycle. Fixes: d7646f7632549 ("pcmcia: use dev_pm_ops for class pcmcia_socket_class") Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 18d3d066a55f2fdfdac35418c2d2c20440ac836d Author: Russell King Date: Fri Aug 19 16:34:45 2016 +0100 ARM: sa1100: clear reset status prior to reboot commit da60626e7d02a4f385cae80e450afc8b07035368 upstream. Clear the current reset status prior to rebooting the platform. This adds the bit missing from 04fef228fb00 ("[ARM] pxa: introduce reset_status and clear_reset_status for driver's usage"). Fixes: 04fef228fb00 ("[ARM] pxa: introduce reset_status and clear_reset_status for driver's usage") Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 0dfa6ed5b7c1766a4d9bf721e98e5171189c32c0 Author: Nicolas Iooss Date: Thu Aug 25 15:17:00 2016 -0700 printk: fix parsing of "brl=" option commit ae6c33ba6e37eea3012fe2640b22400ef3f2d0f3 upstream. Commit bbeddf52adc1 ("printk: move braille console support into separate braille.[ch] files") moved the parsing of braille-related options into _braille_console_setup(), changing the type of variable str from char* to char**. In this commit, memcmp(str, "brl,", 4) was correctly updated to memcmp(*str, "brl,", 4) but not memcmp(str, "brl=", 4). Update the code to make "brl=" option work again and replace memcmp() with strncmp() to make the compiler able to detect such an issue. Fixes: bbeddf52adc1 ("printk: move braille console support into separate braille.[ch] files") Link: http://lkml.kernel.org/r/20160823165700.28952-1-nicolas.iooss_linux@m4x.org Signed-off-by: Nicolas Iooss Cc: Joe Perches Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 159e118992d49740319f003d7230f550e5172e33 Author: Paul Burton Date: Fri Sep 2 16:07:10 2016 +0100 MIPS: Malta: Fix IOCU disable switch read for MIPS64 commit 305723ab439e14debc1d339aa04e835d488b8253 upstream. Malta boards used with CPU emulators feature a switch to disable use of an IOCU. Software has to check this switch & ignore any present IOCU if the switch is closed. The read used to do this was unsafe for 64 bit kernels, as it simply casted the address 0xbf403000 to a pointer & dereferenced it. Whilst in a 32 bit kernel this would access kseg1, in a 64 bit kernel this attempts to access xuseg & results in an address error exception. Fix by accessing a correctly formed ckseg1 address generated using the CKSEG1ADDR macro. Whilst modifying this code, define the name of the register and the bit we care about within it, which indicates whether PCI DMA is routed to the IOCU or straight to DRAM. The code previously checked that bit 0 was also set, but the least significant 7 bits of the CONFIG_GEN0 register contain the value of the MReqInfo signal provided to the IOCU OCP bus, so singling out bit 0 makes little sense & that part of the check is dropped. Signed-off-by: Paul Burton Fixes: b6d92b4a6bdb ("MIPS: Add option to disable software I/O coherency.") Cc: Matt Redfearn Cc: Masahiro Yamada Cc: Kees Cook Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14187/ Signed-off-by: Ralf Baechle Signed-off-by: Jiri Slaby commit 2bcf08b8e1b3897ad970a9825cd90d45375b96eb Author: Will Deacon Date: Fri Aug 26 11:36:39 2016 +0100 arm64: debug: avoid resetting stepping state machine when TIF_SINGLESTEP commit 3a402a709500c5a3faca2111668c33d96555e35a upstream. When TIF_SINGLESTEP is set for a task, the single-step state machine is enabled and we must take care not to reset it to the active-not-pending state if it is already in the active-pending state. Unfortunately, that's exactly what user_enable_single_step does, by unconditionally setting the SS bit in the SPSR for the current task. This causes failures in the GDB testsuite, where GDB ends up missing expected step traps if the instruction being stepped generates another trap, e.g. PTRACE_EVENT_FORK from an SVC instruction. This patch fixes the problem by preserving the current state of the stepping state machine when TIF_SINGLESTEP is set on the current thread. Cc: Reported-by: Yao Qi Signed-off-by: Will Deacon Signed-off-by: Jiri Slaby commit 8e1c919ad28ad39eef42f8bc278cce31f73cb684 Author: Srinivas Ramana Date: Fri Sep 30 15:03:31 2016 +0100 ARM: 8618/1: decompressor: reset ttbcr fields to use TTBR0 on ARMv7 commit 117e5e9c4cfcb7628f08de074fbfefec1bb678b7 upstream. If the bootloader uses the long descriptor format and jumps to kernel decompressor code, TTBCR may not be in a right state. Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use TTBR0 for translation table walks. The commit dbece45894d3a ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N. Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to indicate the use of TTBR0 and the correct base address width. Fixes: dbece45894d3 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") Acked-by: Robin Murphy Signed-off-by: Srinivas Ramana Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 8a511b12a7690ac5224c88ab151fcf83503a01aa Author: Dan Carpenter Date: Fri Jul 15 14:15:47 2016 +0300 usb: gadget: fsl_qe_udc: signedness bug in qe_get_frame() commit f4693b08cc901912a87369c46537b94ed4084ea0 upstream. We can't assign -EINVAL to a u16. Fixes: 3948f0e0c999 ('usb: add Freescale QE/CPM USB peripheral controller driver') Acked-by: Peter Chen Signed-off-by: Dan Carpenter Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit d723c203fe07c4e40d9a135589dc488032ff8c22 Author: Sara Sharon Date: Thu Jun 9 17:19:35 2016 +0300 iwlwifi: pcie: fix access to scratch buffer commit d5d0689aefc59c6a5352ca25d7e6d47d03f543ce upstream. This fixes a pretty ancient bug that hasn't manifested itself until now. The scratchbuf for command queue is allocated only for 32 slots but is accessed with the queue write pointer - which can be up to 256. Since the scratch buf size was 16 and there are up to 256 TFDs we never passed a page boundary when accessing the scratch buffer, but when attempting to increase the size of the scratch buffer a panic was quick to follow when trying to access the address resulted in a page boundary. Signed-off-by: Sara Sharon Fixes: 38c0f334b359 ("iwlwifi: use coherent DMA memory for command header") Signed-off-by: Luca Coelho Signed-off-by: Jiri Slaby commit f94e64b204af5d2abd6cf3b87ac60040e925e1a5 Author: Michael Walle Date: Tue Jul 19 16:43:26 2016 +0200 hwmon: (adt7411) set bit 3 in CFG1 register commit b53893aae441a034bf4dbbad42fe218561d7d81f upstream. According to the datasheet you should only write 1 to this bit. If it is not set, at least AIN3 will return bad values on newer silicon revisions. Fixes: d84ca5b345c2 ("hwmon: Add driver for ADT7411 voltage and temperature sensor") Signed-off-by: Michael Walle Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit f366279b2864460d5bb5a9df212594207910c655 Author: Dan Carpenter Date: Wed Jul 20 15:45:05 2016 -0700 tools/vm/slabinfo: fix an unintentional printf commit 2d6a4d64812bb12dda53704943b61a7496d02098 upstream. The curly braces are missing here so we print stuff unintentionally. Fixes: 9da4714a2d44 ('slub: slabinfo update for cmpxchg handling') Link: http://lkml.kernel.org/r/20160715211243.GE19522@mwanda Signed-off-by: Dan Carpenter Acked-by: Christoph Lameter Cc: Sergey Senozhatsky Cc: Colin Ian King Cc: Laura Abbott Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit b9e0d1cebcac8aeba3fb8608db6e9ee772ed32a6 Author: Robin Murphy Date: Mon Sep 26 16:50:55 2016 +0100 ARM: 8616/1: dt: Respect property size when parsing CPUs commit ba6dea4f7cedb4b1c17e36f4087675d817c2e24b upstream. Whilst MPIDR values themselves are less than 32 bits, it is still perfectly valid for a DT to have #address-cells > 1 in the CPUs node, resulting in the "reg" property having leading zero cell(s). In that situation, the big-endian nature of the data conspires with the current behaviour of only reading the first cell to cause the kernel to think all CPUs have ID 0, and become resoundingly unhappy as a consequence. Take the full property length into account when parsing CPUs so as to be correct under any circumstances. Cc: Russell King Signed-off-by: Robin Murphy Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 88aef089920e0c1ab7c49aeb1539d4119b5219dc Author: Alex Deucher Date: Mon Sep 26 15:32:50 2016 -0400 drm/radeon/si/dpm: add workaround for for Jet parts commit 670bb4fd21c966d0d2a59ad4a99bb4889f9a2987 upstream. Add clock quirks for Jet parts. Reviewed-by: Sonny Jiang Tested-by: Sonny Jiang Signed-off-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 1ab93b13fe17bbab243148d6b77ed672bd558c53 Author: Sergei Miroshnichenko Date: Wed Sep 7 16:51:12 2016 +0300 can: dev: fix deadlock reported after bus-off commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream. A timer was used to restart after the bus-off state, leading to a relatively large can_restart() executed in an interrupt context, which in turn sets up pinctrl. When this happens during system boot, there is a high probability of grabbing the pinctrl_list_mutex, which is locked already by the probe() of other device, making the kernel suspect a deadlock condition [1]. To resolve this issue, the restart_timer is replaced by a delayed work. [1] https://github.com/victronenergy/venus/issues/24 Signed-off-by: Sergei Miroshnichenko Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit 3d0183af15bdd4d28677e0058645a2183cff7ed8 Author: zhong jiang Date: Wed Sep 28 15:22:30 2016 -0700 mm,ksm: fix endless looping in allocating memory when ksm enable commit 5b398e416e880159fe55eefd93c6588fa072cd66 upstream. I hit the following hung task when runing a OOM LTP test case with 4.1 kernel. Call trace: [] __switch_to+0x74/0x8c [] __schedule+0x23c/0x7bc [] schedule+0x3c/0x94 [] rwsem_down_write_failed+0x214/0x350 [] down_write+0x64/0x80 [] __ksm_exit+0x90/0x19c [] mmput+0x118/0x11c [] do_exit+0x2dc/0xa74 [] do_group_exit+0x4c/0xe4 [] get_signal+0x444/0x5e0 [] do_signal+0x1d8/0x450 [] do_notify_resume+0x70/0x78 The oom victim cannot terminate because it needs to take mmap_sem for write while the lock is held by ksmd for read which loops in the page allocator ksm_do_scan scan_get_next_rmap_item down_read get_next_rmap_item alloc_rmap_item #ksmd will loop permanently. There is no way forward because the oom victim cannot release any memory in 4.1 based kernel. Since 4.6 we have the oom reaper which would solve this problem because it would release the memory asynchronously. Nevertheless we can relax alloc_rmap_item requirements and use __GFP_NORETRY because the allocation failure is acceptable as ksm_do_scan would just retry later after the lock got dropped. Such a patch would be also easy to backport to older stable kernels which do not have oom_reaper. While we are at it add GFP_NOWARN so the admin doesn't have to be alarmed by the allocation failure. Link: http://lkml.kernel.org/r/1474165570-44398-1-git-send-email-zhongjiang@huawei.com Signed-off-by: zhong jiang Suggested-by: Hugh Dickins Suggested-by: Michal Hocko Acked-by: Michal Hocko Acked-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit ebc9785ba8082bf12feefef9849b5dc7f27e3b65 Author: Karl Beldan Date: Mon Aug 29 07:45:49 2016 +0000 mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl commit f6d7c1b5598b6407c3f1da795dd54acf99c1990c upstream. This fixes subpage writes when using 4-bit HW ECC. There has been numerous reports about ECC errors with devices using this driver for a while. Also the 4-bit ECC has been reported as broken with subpages in [1] and with 16 bits NANDs in the driver and in mach* board files both in mainline and in the vendor BSPs. What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to try reinitializing the ECC engine: - R/W on whole pages properly generates/checks RS code - try writing the 1st subpage only of a blank page, the subpage is well written and the RS code properly generated, re-reading the same page the HW detects some ECC error, reading the same page again no ECC error is detected Note that the ECC engine is already reinitialized in the 1-bit case. Tested on my LCDK with UBI+UBIFS using subpages. This could potentially get rid of the issue workarounded in [1]. [1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand") Fixes: 6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage") Signed-off-by: Karl Beldan Acked-by: Boris Brezillon Signed-off-by: Brian Norris Signed-off-by: Jiri Slaby commit 9dcc5e15a0c2f491d6e3794625007a825d293411 Author: Michael Ellerman Date: Fri Aug 29 17:01:43 2014 +1000 powerpc: Add macros for the ibm_architecture_vec[] lengths commit e8a4fd0afe05d5213d809fa686d3b8319464acfd upstream. The encoding of the lengths in the ibm_architecture_vec array is "interesting" to say the least. It's non-obvious how the number of bytes we provide relates to the length value. In fact we already got it wrong once, see 11e9ed43ca8a "Fix up ibm_architecture_vec definition". So add some macros to make it (hopefully) clearer. These at least have the property that the integer present in the code is equal to the number of bytes that follows it. Signed-off-by: Michael Ellerman Reviewed-by: Stewart Smith Signed-off-by: Jiri Slaby commit ac080ae1df7ef5145348571484cba47e6678557b Author: Peter Zijlstra Date: Wed Oct 7 14:14:13 2015 +0200 sched/core: Fix an SMP ordering race in try_to_wake_up() vs. schedule() commit ecf7d01c229d11a44609c0067889372c91fb4f36 upstream. Oleg noticed that its possible to falsely observe p->on_cpu == 0 such that we'll prematurely continue with the wakeup and effectively run p on two CPUs at the same time. Even though the overlap is very limited; the task is in the middle of being scheduled out; it could still result in corruption of the scheduler data structures. CPU0 CPU1 set_current_state(...) context_switch(X, Y) prepare_lock_switch(Y) Y->on_cpu = 1; finish_lock_switch(X) store_release(X->on_cpu, 0); try_to_wake_up(X) LOCK(p->pi_lock); t = X->on_cpu; // 0 context_switch(Y, X) prepare_lock_switch(X) X->on_cpu = 1; finish_lock_switch(Y) store_release(Y->on_cpu, 0); schedule(); deactivate_task(X); X->on_rq = 0; if (X->on_rq) // false if (t) while (X->on_cpu) cpu_relax(); context_switch(X, ..) finish_lock_switch(X) store_release(X->on_cpu, 0); Avoid the load of X->on_cpu being hoisted over the X->on_rq load. Reported-by: Oleg Nesterov Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Ingo Molnar Cc: Mike Galbraith Signed-off-by: Jiri Slaby commit bc6ff6988f2049c5a2b73623a5dacfa778a4f5aa Author: Jeff Mahoney Date: Thu Oct 6 08:18:16 2016 +0200 xfs: fixed signedness of error code in xfs_inode_buf_verify Prior to v3.17, XFS used positive error codes internally. Commit af8d971602b9583e5e8400e637e2a48c7480bc64 (xfs: inode recovery readahead can race with inode buffer creation), upstream commit b79f4a1c68bb99152d0785ee4ea3ab4396cdacc6 backported from later releases need the error code signs reversed. Negative error codes will cause assertion failures (BUG_ON on kernels with assertions enabled. Signed-off-by: Jeff Mahoney Cc: Dave Chinner Cc: Brian Foster Signed-off-by: Jiri Slaby commit 979f1b7344634315d895025b53b002896057c09d Author: Bart Van Assche Date: Thu Feb 11 11:03:09 2016 -0800 IB/srpt: Simplify srpt_handle_tsk_mgmt() commit 51093254bf879bc9ce96590400a87897c7498463 upstream. Let the target core check task existence instead of the SRP target driver. Additionally, let the target core check the validity of the task management request instead of the ib_srpt driver. This patch fixes the following kernel crash: BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 IP: [] srpt_handle_new_iu+0x6d7/0x790 [ib_srpt] Oops: 0002 [#1] SMP Call Trace: [] srpt_process_completion+0xde/0x570 [ib_srpt] [] srpt_compl_thread+0x13f/0x160 [ib_srpt] [] kthread+0xcf/0xe0 [] ret_from_fork+0x7c/0xb0 Signed-off-by: Bart Van Assche Fixes: 3e4f574857ee ("ib_srpt: Convert TMR path to target_submit_tmr") Tested-by: Alex Estrin Reviewed-by: Christoph Hellwig Cc: Nicholas Bellinger Cc: Sagi Grimberg Cc: stable Signed-off-by: Doug Ledford Acked-by: Benjamin Poirier Signed-off-by: Jiri Slaby commit 67eb69ec167ac7feb03162c7bc909a4747dca1de Author: Oliver Neukum Date: Wed Aug 17 15:51:55 2016 +0200 kaweth: fix firmware download commit 60bcabd080f53561efa9288be45c128feda1a8bb upstream. This fixes the oops discovered by the Umap2 project and Alan Stern. The intf member needs to be set before the firmware is downloaded. Signed-off-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit b682d39e66ad5087303147d9bb9fb4ac57154686 Author: Kinglong Mee Date: Mon Mar 24 11:56:59 2014 +0800 NFSD: Using free_conn free connection commit 3f42d2c428c724212c5f4249daea97e254eb0546 upstream. Connection from alloc_conn must be freed through free_conn, otherwise, the reference of svc_xprt will never be put. Signed-off-by: Kinglong Mee Signed-off-by: J. Bruce Fields Signed-off-by: Jiri Slaby commit 95bacfe606044096ee391b4693548529e95eb186 Author: Michal Hocko Date: Thu Sep 1 16:15:13 2016 -0700 kernel/fork: fix CLONE_CHILD_CLEARTID regression in nscd commit 735f2770a770156100f534646158cb58cb8b2939 upstream. Commit fec1d0115240 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit") has caused a subtle regression in nscd which uses CLONE_CHILD_CLEARTID to clear the nscd_certainly_running flag in the shared databases, so that the clients are notified when nscd is restarted. Now, when nscd uses a non-persistent database, clients that have it mapped keep thinking the database is being updated by nscd, when in fact nscd has created a new (anonymous) one (for non-persistent databases it uses an unlinked file as backend). The original proposal for the CLONE_CHILD_CLEARTID change claimed (https://lkml.org/lkml/2006/10/25/233): : The NPTL library uses the CLONE_CHILD_CLEARTID flag on clone() syscalls : on behalf of pthread_create() library calls. This feature is used to : request that the kernel clear the thread-id in user space (at an address : provided in the syscall) when the thread disassociates itself from the : address space, which is done in mm_release(). : : Unfortunately, when a multi-threaded process incurs a core dump (such as : from a SIGSEGV), the core-dumping thread sends SIGKILL signals to all of : the other threads, which then proceed to clear their user-space tids : before synchronizing in exit_mm() with the start of core dumping. This : misrepresents the state of process's address space at the time of the : SIGSEGV and makes it more difficult for someone to debug NPTL and glibc : problems (misleading him/her to conclude that the threads had gone away : before the fault). : : The fix below is to simply avoid the CLONE_CHILD_CLEARTID action if a : core dump has been initiated. The resulting patch from Roland (https://lkml.org/lkml/2006/10/26/269) seems to have a larger scope than the original patch asked for. It seems that limitting the scope of the check to core dumping should work for SIGSEGV issue describe above. [Changelog partly based on Andreas' description] Fixes: fec1d0115240 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit") Link: http://lkml.kernel.org/r/1471968749-26173-1-git-send-email-mhocko@kernel.org Signed-off-by: Michal Hocko Tested-by: William Preston Acked-by: Oleg Nesterov Cc: Roland McGrath Cc: Andreas Schwab Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 0d6a2bb674f96c9463ce7daefb9b5837adfb7194 Author: Vitaly Kuznetsov Date: Fri Feb 27 11:25:56 2015 -0800 clockevents: export clockevents_unbind_device instead of clockevents_unbind commit 32a158325acf12842764b1681f53903673f2f22e upstream. It looks like clockevents_unbind is being exported by mistake as: - it is static; - it is not listed in include/linux/clockchips.h; - EXPORT_SYMBOL_GPL(clockevents_unbind) follows clockevents_unbind_device() implementation. I think clockevents_unbind_device should be exported instead. This is going to be used to teardown Hyper-V clockevent devices on module unload. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit ca7119939db8a242ce3848f44c6039e06a8563bb Author: Joerg Roedel Date: Tue Jul 26 15:18:54 2016 +0200 iommu/amd: Update Alias-DTE in update_device_table() commit 3254de6bf74fe94c197c9f819fe62a3a3c36f073 upstream. Not doing so might cause IO-Page-Faults when a device uses an alias request-id and the alias-dte is left in a lower page-mode which does not cover the address allocated from the iova-allocator. Fixes: 492667dacc0a ('x86/amd-iommu: Remove amd_iommu_pd_table') Signed-off-by: Joerg Roedel Signed-off-by: Jiri Slaby commit e550951c8b8b1acb30e31c22ac3404648c9aa213 Author: WANG Cong Date: Tue Jul 5 22:12:36 2016 -0700 ppp: defer netns reference release for ppp channel commit 205e1e255c479f3fd77446415706463b282f94e4 upstream. Matt reported that we have a NULL pointer dereference in ppp_pernet() from ppp_connect_channel(), i.e. pch->chan_net is NULL. This is due to that a parallel ppp_unregister_channel() could happen while we are in ppp_connect_channel(), during which pch->chan_net set to NULL. Since we need a reference to net per channel, it makes sense to sync the refcnt with the life time of the channel, therefore we should release this reference when we destroy it. Fixes: 1f461dcdd296 ("ppp: take reference on channels netns") Reported-by: Matt Bennett Cc: Paul Mackerras Cc: linux-ppp@vger.kernel.org Cc: Guillaume Nault Cc: Cyrill Gorcunov Signed-off-by: Cong Wang Reviewed-by: Cyrill Gorcunov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1917f9179621548e9498b5751d6ad9fa381a60d2 Author: Khem Raj Date: Mon Apr 25 09:19:17 2016 -0700 powerpc/ptrace: Fix out of bounds array access warning commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream. gcc-6 correctly warns about a out of bounds access arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Warray-bounds] offsetof(struct thread_fp_state, fpr[32][0])); ^ check the end of array instead of beginning of next element to fix this Signed-off-by: Khem Raj Cc: Kees Cook Cc: Michael Ellerman Cc: Segher Boessenkool Tested-by: Aaro Koskinen Acked-by: Olof Johansson Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby commit f1991d49095ac4ba324da1aafcc0a94f323aacf1 Author: Michael Ellerman Date: Fri Sep 25 12:14:48 2015 +1000 powerpc/ps3: Remove unused os_area_db_id_video_mode commit 4fa9a3f6b616fd9f2555d9d0c04513a942750986 upstream. This struct is unused, which is now a build error with gcc 6: error: 'os_area_db_id_video_mode' defined but not used There doesn't seem to be any good reason to keep it around so remove it, it's in the history if anyone needs it. Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby commit 82210dfb2c489680c99af5e4acb68f8712a49357 Author: Sam Ravnborg Date: Mon Jul 14 17:08:29 2014 +0200 CRIS: Fix headers_install commit 6eb64b8c64f7177b160b4bdbabd317d523bf4bfc upstream. Fix headers_install by adjusting the path to arch files. And delete unused Kbuild file. Drop special handling of cris in the headers.sh script as a nice side-effect. Signed-off-by: Sam Ravnborg Cc: Mikael Starvik Cc: David Howells Signed-off-by: Jesper Nilsson Signed-off-by: Jiri Slaby commit 5e102d1f7260e8264d1bc8c28e8de163fbab88a8 Author: Balbir Singh Date: Mon Sep 5 13:16:40 2016 +1000 sched/core: Fix a race between try_to_wake_up() and a woken up task commit 135e8c9250dd5c8c9aae5984fde6f230d0cbfeaf upstream. The origin of the issue I've seen is related to a missing memory barrier between check for task->state and the check for task->on_rq. The task being woken up is already awake from a schedule() and is doing the following: do { schedule() set_current_state(TASK_(UN)INTERRUPTIBLE); } while (!cond); The waker, actually gets stuck doing the following in try_to_wake_up(): while (p->on_cpu) cpu_relax(); Analysis: The instance I've seen involves the following race: CPU1 CPU2 while () { if (cond) break; do { schedule(); set_current_state(TASK_UN..) } while (!cond); wakeup_routine() spin_lock_irqsave(wait_lock) raw_spin_lock_irqsave(wait_lock) wake_up_process() } try_to_wake_up() set_current_state(TASK_RUNNING); .. list_del(&waiter.list); CPU2 wakes up CPU1, but before it can get the wait_lock and set current state to TASK_RUNNING the following occurs: CPU3 wakeup_routine() raw_spin_lock_irqsave(wait_lock) if (!list_empty) wake_up_process() try_to_wake_up() raw_spin_lock_irqsave(p->pi_lock) .. if (p->on_rq && ttwu_wakeup()) .. while (p->on_cpu) cpu_relax() .. CPU3 tries to wake up the task on CPU1 again since it finds it on the wait_queue, CPU1 is spinning on wait_lock, but immediately after CPU2, CPU3 got it. CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and the task is spinning on the wait_lock. Interestingly since p->on_rq is checked under pi_lock, I've noticed that try_to_wake_up() finds p->on_rq to be 0. This was the most confusing bit of the analysis, but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq check is not reliable without this fix IMHO. The race is visible (based on the analysis) only when ttwu_queue() does a remote wakeup via ttwu_queue_remote. In which case the p->on_rq change is not done uder the pi_lock. The result is that after a while the entire system locks up on the raw_spin_irqlock_save(wait_lock) and the holder spins infintely Reproduction of the issue: The issue can be reproduced after a long run on my system with 80 threads and having to tweak available memory to very low and running memory stress-ng mmapfork test. It usually takes a long time to reproduce. I am trying to work on a test case that can reproduce the issue faster, but thats work in progress. I am still testing the changes on my still in a loop and the tests seem OK thus far. Big thanks to Benjamin and Nick for helping debug this as well. Ben helped catch the missing barrier, Nick caught every missing bit in my theory. Signed-off-by: Balbir Singh [ Updated comment to clarify matching barriers. Many architectures do not have a full barrier in switch_to() so that cannot be relied upon. ] Signed-off-by: Peter Zijlstra (Intel) Acked-by: Benjamin Herrenschmidt Cc: Alexey Kardashevskiy Cc: Linus Torvalds Cc: Nicholas Piggin Cc: Nicholas Piggin Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/e02cce7b-d9ca-1ad0-7a61-ea97c7582b37@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 89f00a62a495d5ac668d40e8012dfd828d686c08 Author: Dan Carpenter Date: Wed Jul 13 13:12:34 2016 +0300 hostfs: Freeing an ERR_PTR in hostfs_fill_sb_common() commit 8a545f185145e3c09348cd74326268ecfc6715a3 upstream. We can't pass error pointers to kfree() or it causes an oops. Fixes: 52b209f7b848 ('get rid of hostfs_read_inode()') Signed-off-by: Dan Carpenter Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit e80908c3e9a982564f020f51e78952e4af93e8a3 Author: Dan Carpenter Date: Mon Jul 11 11:46:33 2016 +0300 qxl: check for kmap failures commit f4cceb2affcd1285d4ce498089e8a79f4cd2fa66 upstream. If kmap fails, it leads to memory corruption. Fixes: f64122c1f6ad ('drm: add new QXL driver. (v1.4)') Signed-off-by: Dan Carpenter Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20160711084633.GA31411@mwanda Signed-off-by: Jiri Slaby commit 876726eba0e3f161ef038def82be6dc713b818f5 Author: Yadi.hu Date: Sun Sep 18 18:52:31 2016 +0800 i2c-eg20t: fix race between i2c init and interrupt enable commit 371a015344b6e270e7e3632107d9554ec6d27a6b upstream. the eg20t driver call request_irq() function before the pch_base_address, base address of i2c controller's register, is assigned an effective value. there is one possible scenario that an interrupt which isn't inside eg20t arrives immediately after request_irq() is executed when i2c controller shares an interrupt number with others. since the interrupt handler pch_i2c_handler() has already active as shared action, it will be called and read its own register to determine if this interrupt is from itself. At that moment, since base address of i2c registers is not remapped in kernel space yet,so the INT handler will access an illegal address and then a error occurs. Signed-off-by: Yadi.hu Signed-off-by: Wolfram Sang Signed-off-by: Jiri Slaby commit c8f8006ac4d51b641a089acef8295bb8ac62eef6 Author: Jeff Mahoney Date: Wed Sep 21 08:31:29 2016 -0400 btrfs: ensure that file descriptor used with subvol ioctls is a dir commit 325c50e3cebb9208009083e841550f98a863bfa0 upstream. If the subvol/snapshot create/destroy ioctls are passed a regular file with execute permissions set, we'll eventually Oops while trying to do inode->i_op->lookup via lookup_one_len. This patch ensures that the file descriptor refers to a directory. Fixes: cb8e70901d (Btrfs: Fix subvolume creation locking rules) Fixes: 76dda93c6a (Btrfs: add snapshot/subvolume destroy ioctl) Signed-off-by: Jeff Mahoney Signed-off-by: Chris Mason Signed-off-by: Jiri Slaby commit 544baf9ab46761dc13beb9c02ecd645919b3b85d Author: Fabio Estevam Date: Wed Aug 17 12:41:08 2016 -0300 can: flexcan: fix resume function commit 4de349e786a3a2d51bd02d56f3de151bbc3c3df9 upstream. On a imx6ul-pico board the following error is seen during system suspend: dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110 PM: Device 2090000.flexcan failed to resume: error -110 The reason for this suspend error is because when the CAN interface is not active the clocks are disabled and then flexcan_chip_enable() will always fail due to a timeout error. In order to fix this issue, only call flexcan_chip_enable/disable() when the CAN interface is active. Based on a patch from Dong Aisheng in the NXP kernel. Signed-off-by: Fabio Estevam Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit cc2b40c45c0f9a8685e6f18d370ec2c3fd705e2d Author: Steven Rostedt (Red Hat) Date: Fri Sep 23 22:57:13 2016 -0400 tracing: Move mutex to protect against resetting of seq data commit 1245800c0f96eb6ebb368593e251d66c01e61022 upstream. The iter->seq can be reset outside the protection of the mutex. So can reading of user data. Move the mutex up to the beginning of the function. Fixes: d7350c3f45694 ("tracing/core: make the read callbacks reentrants") Reported-by: Al Viro Signed-off-by: Steven Rostedt Signed-off-by: Jiri Slaby commit c46e22a8540ee14967fd1f344388ca7c382b3a35 Author: Al Viro Date: Sat Sep 17 18:31:46 2016 -0400 fix memory leaks in tracing_buffers_splice_read() commit 1ae2293dd6d2f5c823cf97e60b70d03631cd622f upstream. Signed-off-by: Al Viro Signed-off-by: Jiri Slaby commit 32505f2117d863f83148819db36c3218c35cd544 Author: Dan Carpenter Date: Thu Jul 14 13:44:56 2016 +0300 mtd: pmcmsp-flash: Allocating too much in init_msp_flash() commit 79ad07d45743721010e766e65dc004ad249bd429 upstream. There is a cut and paste issue here. The bug is that we are allocating more memory than necessary for msp_maps. We should be allocating enough space for a map_info struct (144 bytes) but we instead allocate enough for an mtd_info struct (1840 bytes). It's a small waste. The other part of this is not harmful but when we allocated msp_flash then we allocated enough space fro a map_info pointer instead of an mtd_info pointer. But since pointers are the same size it works out fine. Anyway, I decided to clean up all three allocations a bit to make them a bit more consistent and clear. Fixes: 68aa0fa87f6d ('[MTD] PMC MSP71xx flash/rootfs mappings') Signed-off-by: Dan Carpenter Signed-off-by: Brian Norris Signed-off-by: Jiri Slaby commit 79c7058361e80854e207be04bc880cf991a49ebf Author: Al Viro Date: Tue Sep 20 20:07:42 2016 +0100 fix fault_in_multipages_...() on architectures with no-op access_ok() commit e23d4159b109167126e5bcd7f3775c95de7fee47 upstream. Switching iov_iter fault-in to multipages variants has exposed an old bug in underlying fault_in_multipages_...(); they break if the range passed to them wraps around. Normally access_ok() done by callers will prevent such (and it's a guaranteed EFAULT - ERR_PTR() values fall into such a range and they should not point to any valid objects). However, on architectures where userland and kernel live in different MMU contexts (e.g. s390) access_ok() is a no-op and on those a range with a wraparound can reach fault_in_multipages_...(). Since any wraparound means EFAULT there, the fix is trivial - turn those while (uaddr <= end) ... into if (unlikely(uaddr > end)) return -EFAULT; do ... while (uaddr <= end); Reported-by: Jan Stancek Tested-by: Jan Stancek Signed-off-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 031e6fb3ebd90adf6d2a1e3b74ddb835b25584e3 Author: Colin Ian King Date: Sat Jan 23 19:33:10 2016 +0000 Staging: iio: adc: fix indent on break statement commit b6acb0cfc21293a1bfc283e9217f58f7474ef728 upstream. Fix indent warning when building with gcc 6: drivers/staging/iio/adc/ad7192.c:239:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] Signed-off-by: Colin Ian King Signed-off-by: Jonathan Cameron Signed-off-by: Jiri Slaby commit f71895b16026247f3bea66b897e1f2f2f785462d Author: Arnd Bergmann Date: Thu May 19 09:58:49 2016 +0200 iwlegacy: avoid warning about missing braces commit 2cce76c3fab410520610a7d2f52faebc3cfcf843 upstream. gcc-6 warns about code in il3945_hw_txq_ctx_free() being somewhat ambiguous: drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses] This adds a set of curly braces to avoid the warning. Signed-off-by: Arnd Bergmann Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Signed-off-by: Jiri Slaby commit 93a443b33068176f332eabebe8da2060e983e18d Author: Arnd Bergmann Date: Mon Mar 14 15:18:38 2016 +0100 net: caif: fix misleading indentation commit 8e0cc8c326d99e41468c96fea9785ab78883a281 upstream. gcc points out code that is not indented the way it is interpreted: net/caif/cfpkt_skbuff.c: In function 'cfpkt_setlen': net/caif/cfpkt_skbuff.c:289:4: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] return cfpkt_getlen(pkt); ^~~~~~ net/caif/cfpkt_skbuff.c:286:3: note: ...this 'else' clause, but it is not else ^~~~ It is clear from the context that not returning here would be a bug, as we'd end up passing a negative length into a function that takes a u16 length, so it is not missing curly braces here, and I'm assuming that the indentation is the only part that's wrong about it. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit ea837f4b8359c3b30ccc3ed85ee6a06c33503a67 Author: Steven Rostedt Date: Thu Jul 28 22:30:43 2016 -0400 Makefile: Mute warning for __builtin_return_address(>0) for tracing only commit 377ccbb483738f84400ddf5840c7dd8825716985 upstream. With the latest gcc compilers, they give a warning if __builtin_return_address() parameter is greater than 0. That is because if it is used by a function called by a top level function (or in the case of the kernel, by assembly), it can try to access stack frames outside the stack and crash the system. The tracing system uses __builtin_return_address() of up to 2! But it is well aware of the dangers that it may have, and has even added precautions to protect against it (see the thunk code in arch/x86/entry/thunk*.S) Linus originally added KBUILD_CFLAGS that would suppress the warning for the entire kernel, as simply adding KBUILD_CFLAGS to the tracing directory wouldn't work. The tracing directory plays a bit with the CFLAGS and requires a little more logic. This adds that special logic to only suppress the warning for the tracing directory. If it is used anywhere else outside of tracing, the warning will still be triggered. Link: http://lkml.kernel.org/r/20160728223043.51996267@grimm.local.home Tested-by: Linus Torvalds Signed-off-by: Steven Rostedt Signed-off-by: Jiri Slaby commit 9bfa085336f2f11b23a2b3c80ae6dede32874e12 Author: Linus Torvalds Date: Wed Jul 27 19:03:04 2016 -0700 Disable "frame-address" warning commit 124a3d88fa20e1869fc229d7d8c740cc81944264 upstream. Newer versions of gcc warn about the use of __builtin_return_address() with a non-zero argument when "-Wall" is specified: kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); [ .. repeats a few times for other similar cases .. ] It is true that a non-zero argument is somewhat dangerous, and we do not actually have very many uses of that in the kernel - but the ftrace code does use it, and as Stephen Rostedt says: "We are well aware of the danger of using __builtin_return_address() of > 0. In fact that's part of the reason for having the "thunk" code in x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames when tracking irqs off sections, to prevent __builtin_return_address() from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)'." For now, __builtin_return_address() with a non-zero argument is the best we can do, and the warning is not helpful and can end up making people miss other warnings for real problems. So disable the frame-address warning on compilers that need it. Acked-by: Steven Rostedt Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit b06dcea1a7f3c849928ce6d6d1b26bf4dd655684 Author: Linus Torvalds Date: Wed Jul 27 13:17:41 2016 -0700 Disable "maybe-uninitialized" warning globally commit 6e8d666e925333c55378e8d5540a8a9ee0eea9c5 upstream. Several build configurations had already disabled this warning because it generates a lot of false positives. But some had not, and it was still enabled for "allmodconfig" builds, for example. Looking at the warnings produced, every single one I looked at was a false positive, and the warnings are frequent enough (and big enough) that they can easily hide real problems that you don't notice in the noise generated by -Wmaybe-uninitialized. The warning is good in theory, but this is a classic case of a warning that causes more problems than the warning can solve. If gcc gets better at avoiding false positives, we may be able to re-enable this warning. But as is, we're better off without it, and I want to be able to see the *real* warnings. Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 79a24f75853bf0f78374c979b62697b01740f074 Author: Arnd Bergmann Date: Mon Apr 25 17:35:31 2016 +0200 gcov: disable -Wmaybe-uninitialized warning commit e72e2dfe7c16ffbfbabf9cb24adc6d9f93a4fe37 upstream. When gcov profiling is enabled, we see a lot of spurious warnings about possibly uninitialized variables being used: arch/arm/mm/dma-mapping.c: In function 'arm_coherent_iommu_map_page': arch/arm/mm/dma-mapping.c:1085:16: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/clk/st/clk-flexgen.c: In function 'st_of_flexgen_setup': drivers/clk/st/clk-flexgen.c:323:9: warning: 'num_parents' may be used uninitialized in this function [-Wmaybe-uninitialized] kernel/cgroup.c: In function 'cgroup_mount': kernel/cgroup.c:2119:11: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized] All of these are false positives, so it seems better to just disable the warnings whenever GCOV is enabled. Most users don't enable GCOV, and based on a prior patch, it is now also disabled for 'allmodconfig' builds, so there should be no downsides of doing this. Signed-off-by: Arnd Bergmann Acked-by: Peter Oberparleiter Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit 67804f8ec5be9ef45e324f58edbfd23b751a366f Author: Arnd Bergmann Date: Mon Apr 25 17:35:28 2016 +0200 Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHES commit 815eb71e7149ecce40db9dd0ad09c4dd9d33c60f upstream. CONFIG_PROFILE_ALL_BRANCHES confuses gcc-5.x to the degree that it prints incorrect warnings about a lot of variables that it thinks can be used uninitialized, e.g.: i2c/busses/i2c-diolan-u2c.c: In function 'diolan_usb_xfer': i2c/busses/i2c-diolan-u2c.c:391:16: warning: 'byte' may be used uninitialized in this function iio/gyro/itg3200_core.c: In function 'itg3200_probe': iio/gyro/itg3200_core.c:213:6: warning: 'val' may be used uninitialized in this function leds/leds-lp55xx-common.c: In function 'lp55xx_update_bits': leds/leds-lp55xx-common.c:350:6: warning: 'tmp' may be used uninitialized in this function misc/bmp085.c: In function 'show_pressure': misc/bmp085.c:363:10: warning: 'pressure' may be used uninitialized in this function power/ds2782_battery.c: In function 'ds2786_get_capacity': power/ds2782_battery.c:214:17: warning: 'raw' may be used uninitialized in this function These are all false positives that either rob someone's time when trying to figure out whether they are real, or they get people to send wrong patches to shut up the warnings. Nobody normally wants to run a CONFIG_PROFILE_ALL_BRANCHES kernel in production, so disabling the whole class of warnings for this configuration has no serious downsides either. Signed-off-by: Arnd Bergmann Acked-by: Steven Rostedt Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit 941646b92f425a42c5fea6f1290f81471fa8acfa Author: Robert Jarzmik Date: Sat Apr 2 21:38:53 2016 +0200 kbuild: forbid kernel directory to contain spaces and colons commit 51193b76bfff5027cf96ba63effae808ad67cca7 upstream. When the kernel path contains a space or a colon somewhere in the path name, the modules_install target doesn't work anymore, as the path names are not enclosed in double quotes. It is also supposed that and O= build will suffer from the same weakness as modules_install. Instead of checking and improving kbuild to resist to directories including these characters, error out early to prevent any build if the kernel's main directory contains a space. Signed-off-by: Robert Jarzmik Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit 55ee86c958a2ad4a4119c6f715a57ba8bbdd2c50 Author: Wang YanQing Date: Fri Dec 11 00:35:19 2015 +0800 Makefile: revert "Makefile: Document ability to make file.lst and file.S" partially commit 40ab87a4003c7952976ce901a2b9ece5ed833168 upstream. Commit 627189797807 ("Makefile: Document ability to make file.lst and file.S") document ability to make file.S, but there isn't such ability in kbuild, so revert it. Signed-off-by: Wang YanQing Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit 7e87d5a7b7c880a6d540314fcb36e39dc7520351 Author: Michal Marek Date: Thu Dec 10 15:53:06 2015 +0100 kbuild: Do not run modules_install and install in paralel commit a85a41ed69f27c4c667d8c418df14b4fb220c4ad upstream. Based on a x86-only patch by Andy Lutomirski With modular kernels, 'make install' is going to need the installed modules at some point to generate the initramfs. Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit 341ec0a305e2e64d67f346c09445c7328579f120 Author: Ashish Samant Date: Mon Sep 19 14:44:42 2016 -0700 ocfs2: fix start offset to ocfs2_zero_range_for_truncate() commit d21c353d5e99c56cdd5b5c1183ffbcaf23b8b960 upstream. If we punch a hole on a reflink such that following conditions are met: 1. start offset is on a cluster boundary 2. end offset is not on a cluster boundary 3. (end offset is somewhere in another extent) or (hole range > MAX_CONTIG_BYTES(1MB)), we dont COW the first cluster starting at the start offset. But in this case, we were wrongly passing this cluster to ocfs2_zero_range_for_truncate() to zero out. This will modify the cluster in place and zero it in the source too. Fix this by skipping this cluster in such a scenario. To reproduce: 1. Create a random file of say 10 MB xfs_io -c 'pwrite -b 4k 0 10M' -f 10MBfile 2. Reflink it reflink -f 10MBfile reflnktest 3. Punch a hole at starting at cluster boundary with range greater that 1MB. You can also use a range that will put the end offset in another extent. fallocate -p -o 0 -l 1048615 reflnktest 4. sync 5. Check the first cluster in the source file. (It will be zeroed out). dd if=10MBfile iflag=direct bs= count=1 | hexdump -C Link: http://lkml.kernel.org/r/1470957147-14185-1-git-send-email-ashish.samant@oracle.com Signed-off-by: Ashish Samant Reported-by: Saar Maoz Reviewed-by: Srinivas Eeda Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Eric Ren Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 84f0c561eb604f27b6df9ced98a0ad545e44a44b Author: Joseph Qi Date: Mon Sep 19 14:43:55 2016 -0700 ocfs2/dlm: fix race between convert and migration commit e6f0c6e6170fec175fe676495f29029aecdf486c upstream. Commit ac7cf246dfdb ("ocfs2/dlm: fix race between convert and recovery") checks if lockres master has changed to identify whether new master has finished recovery or not. This will introduce a race that right after old master does umount ( means master will change), a new convert request comes. In this case, it will reset lockres state to DLM_RECOVERING and then retry convert, and then fail with lockres->l_action being set to OCFS2_AST_INVALID, which will cause inconsistent lock level between ocfs2 and dlm, and then finally BUG. Since dlm recovery will clear lock->convert_pending in dlm_move_lockres_to_recovery_list, we can use it to correctly identify the race case between convert and recovery. So fix it. Fixes: ac7cf246dfdb ("ocfs2/dlm: fix race between convert and recovery") Link: http://lkml.kernel.org/r/57CE1569.8010704@huawei.com Signed-off-by: Joseph Qi Signed-off-by: Jun Piao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 6b809482afd7a1020ba8400a1773b6e90f538f1e Author: Herbert Xu Date: Tue Sep 13 14:43:29 2016 +0800 crypto: skcipher - Fix blkcipher walk OOM crash commit acdb04d0b36769b3e05990c488dc74d8b7ac8060 upstream. When we need to allocate a temporary blkcipher_walk_next and it fails, the code is supposed to take the slow path of processing the data block by block. However, due to an unrelated change we instead end up dereferencing the NULL pointer. This patch fixes it by moving the unrelated bsize setting out of the way so that we enter the slow path as inteded. Fixes: 7607bd8ff03b ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block") Reported-by: xiakaixu Reported-by: Ard Biesheuvel Signed-off-by: Herbert Xu Tested-by: Ard Biesheuvel Signed-off-by: Jiri Slaby commit 49680201829f0997cc75ab72fe385e0819d945c0 Author: Jeff Mahoney Date: Tue Aug 2 14:05:33 2016 -0700 reiserfs: fix "new_insert_key may be used uninitialized ..." commit 0a11b9aae49adf1f952427ef1a1d9e793dd6ffb6 upstream. new_insert_key only makes any sense when it's associated with a new_insert_ptr, which is initialized to NULL and changed to a buffer_head when we also initialize new_insert_key. We can key off of that to avoid the uninitialized warning. Link: http://lkml.kernel.org/r/5eca5ffb-2155-8df2-b4a2-f162f105efed@suse.com Signed-off-by: Jeff Mahoney Cc: Arnd Bergmann Cc: Jan Kara Cc: Linus Torvalds Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 2d291fde5f706ac081e8cfc0ebe7e31dd534dfe7 Author: Arnd Bergmann Date: Mon Apr 25 17:35:30 2016 +0200 gcov: disable tree-loop-im to reduce stack usage commit c87bf431448b404a6ef5fbabd74c0e3e42157a7f upstream. Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx': lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=] After some investigation, I found that this behavior started with gcc-4.9, and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702. A suggested workaround for it is to use the -fno-tree-loop-im flag that turns off one of the optimization stages in gcc, so the code runs a little slower but does not use excessive amounts of stack. We could make this conditional on the gcc version, but I could not find an easy way to do this in Kbuild and the benefit would be fairly small, given that most of the gcc version in production are affected now. I'm marking this for 'stable' backports because it addresses a bug with code generation in gcc that exists in all kernel versions with the affected gcc releases. Signed-off-by: Arnd Bergmann Acked-by: Peter Oberparleiter Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby