commit 888172862fa78505c4e4674c205a06586443d83f Author: Sasha Levin Date: Mon Jun 6 19:13:11 2016 -0400 Linux 4.1.26 Signed-off-by: Sasha Levin commit 3b14279924b57534832b3c1a0f5b890191777c4e Author: Mikulas Patocka Date: Tue May 24 22:49:18 2016 +0200 hpfs: implement the show_options method [ Upstream commit 037369b872940cd923835a0a589763180c4a36bc ] The HPFS filesystem used generic_show_options to produce string that is displayed in /proc/mounts. However, there is a problem that the options may disappear after remount. If we mount the filesystem with option1 and then remount it with option2, /proc/mounts should show both option1 and option2, however it only shows option2 because the whole option string is replaced with replace_mount_options in hpfs_remount_fs. To fix this bug, implement the hpfs_show_options function that prints options that are currently selected. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9df75cfc33830bc3aaf625728e01f3e80a1c711e Author: Mikulas Patocka Date: Tue May 24 22:48:33 2016 +0200 affs: fix remount failure when there are no options changed [ Upstream commit 01d6e08711bf90bc4d7ead14a93a0cbd73b1896a ] Commit c8f33d0bec99 ("affs: kstrdup() memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: c8f33d0bec99 ("affs: kstrdup() memory handling") Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ffd9e8e871d65a6fb87433fe0811289e5dadcd5d Author: Mikulas Patocka Date: Tue May 24 22:47:00 2016 +0200 hpfs: fix remount failure when there are no options changed [ Upstream commit 44d51706b4685f965cd32acde3fe0fcc1e6198e8 ] Commit ce657611baf9 ("hpfs: kstrdup() out of memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: ce657611baf9 ("hpfs: kstrdup() out of memory handling") Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b289a9dc95c5967d453762a6f33147b3638cb30b Author: Manfred Schlaegl Date: Fri May 27 16:36:36 2016 -0700 Input: pwm-beeper - fix - scheduling while atomic [ Upstream commit f49cf3b8b4c841457244c461c66186a719e13bcc ] Pwm config may sleep so defer it using a worker. On a Freescale i.MX53 based board we ran into "BUG: scheduling while atomic" because input_inject_event locks interrupts, but imx_pwm_config_v2 sleeps. Tested on Freescale i.MX53 SoC with 4.6.0. Signed-off-by: Manfred Schlaegl Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 25fda3aef19fc295e7e0e978ad39445548ef48af Author: Ville Syrjälä Date: Thu May 26 15:16:25 2016 -0700 dma-debug: avoid spinlock recursion when disabling dma-debug [ Upstream commit 3017cd63f26fc655d56875aaf497153ba60e9edf ] With netconsole (at least) the pr_err("... disablingn") call can recurse back into the dma-debug code, where it'll try to grab free_entries_lock again. Avoid the problem by doing the printk after dropping the lock. Link: http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 88fe30012aa53af5929155b95800d125cb258147 Author: Richard Weinberger Date: Tue Apr 26 16:39:48 2016 +0200 UBI: Fix static volume checks when Fastmap is used [ Upstream commit 1900149c835ab5b48bea31a823ea5e5a401fb560 ] Ezequiel reported that he's facing UBI going into read-only mode after power cut. It turned out that this behavior happens only when updating a static volume is interrupted and Fastmap is used. A possible trace can look like: ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012 0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841 ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6 ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0 Call Trace: [] dump_stack+0x63/0x82 [] ubi_eba_read_leb+0x486/0x4a0 [ubi] [] ubi_check_volume+0x83/0xf0 [ubi] [] ubi_open_volume+0x177/0x350 [ubi] [] vol_cdev_open+0x58/0xb0 [ubi] [] chrdev_open+0xae/0x1d0 [] do_dentry_open+0x1ff/0x300 [] ? cdev_put+0x30/0x30 [] vfs_open+0x56/0x60 [] path_openat+0x4f4/0x1190 [] do_filp_open+0x91/0x100 [] ? __alloc_fd+0xc7/0x190 [] do_sys_open+0x13f/0x210 [] SyS_open+0x1e/0x20 [] entry_SYSCALL_64_fastpath+0x1a/0xa4 UBI checks static volumes for data consistency and reads the whole volume upon first open. If the volume is found erroneous users of UBI cannot read from it, but another volume update is possible to fix it. The check is performed by running ubi_eba_read_leb() on every allocated LEB of the volume. For static volumes ubi_eba_read_leb() computes the checksum of all data stored in a LEB. To verify the computed checksum it has to read the LEB's volume header which stores the original checksum. If the volume header is not found UBI treats this as fatal internal error and switches to RO mode. If the UBI device was attached via a full scan the assumption is correct, the volume header has to be present as it had to be there while scanning to get known as mapped. If the attach operation happened via Fastmap the assumption is no longer correct. When attaching via Fastmap UBI learns the mapping table from Fastmap's snapshot of the system state and not via a full scan. It can happen that a LEB got unmapped after a Fastmap was written to the flash. Then UBI can learn the LEB still as mapped and accessing it returns only 0xFF bytes. As UBI is not a FTL it is allowed to have mappings to empty PEBs, it assumes that the layer above takes care of LEB accounting and referencing. UBIFS does so using the LEB property tree (LPT). For static volumes UBI blindly assumes that all LEBs are present and therefore special actions have to be taken. The described situation can happen when updating a static volume is interrupted, either by a user or a power cut. The volume update code first unmaps all LEBs of a volume and then writes LEB by LEB. If the sequence of operations is interrupted UBI detects this either by the absence of LEBs, no volume header present at scan time, or corrupted payload, detected via checksum. In the Fastmap case the former method won't trigger as no scan happened and UBI automatically thinks all LEBs are present. Only by reading data from a LEB it detects that the volume header is missing and incorrectly treats this as fatal error. To deal with the situation ubi_eba_read_leb() from now on checks whether we attached via Fastmap and handles the absence of a volume header like a data corruption error. This way interrupted static volume updates will correctly get detected also when Fastmap is used. Cc: Reported-by: Ezequiel Garcia Tested-by: Ezequiel Garcia Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 22ada7cca2bf9fe6f214d83cb79c6bd95b2313cc Author: Ross Lagerwall Date: Tue May 10 16:11:00 2016 +0100 xen/events: Don't move disabled irqs [ Upstream commit f0f393877c71ad227d36705d61d1e4062bc29cf5 ] Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded irq_move_irq() but left out checking if the IRQ is disabled. This broke resuming from suspend since it tries to move a (disabled) irq without holding the IRQ's desc->lock. Fix it by adding in a check for disabled IRQs. The resulting stacktrace was: kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31! invalid opcode: 0000 [#1] SMP Modules linked in: xenfs xen_privcmd ... CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016 task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000 RIP: 0010:[] [] irq_move_masked_irq+0xd2/0xe0 RSP: 0018:ffff88003d7bfc50 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8 RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000 R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0 R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff FS: 0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66 Call Trace: [] eoi_pirq+0xb2/0xf0 [] __startup_pirq+0xe6/0x150 [] xen_irq_resume+0x319/0x360 [] xen_suspend+0xb5/0x180 [] multi_cpu_stop+0xb5/0xe0 [] ? cpu_stop_queue_work+0x80/0x80 [] cpu_stopper_thread+0xb0/0x140 [] ? finish_task_switch+0x76/0x220 [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [] smpboot_thread_fn+0x105/0x160 [] ? sort_range+0x30/0x30 [] kthread+0xd8/0xf0 [] ? kthread_create_on_node+0x1e0/0x1e0 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x1e0/0x1e0 Signed-off-by: Ross Lagerwall Reviewed-by: Boris Ostrovsky Cc: Signed-off-by: David Vrabel Signed-off-by: Sasha Levin commit 1cf63e8af115eb4bb83d28528d16e62c1d6cfa4f Author: Stefano Stabellini Date: Wed Apr 20 14:15:01 2016 +0100 xen/x86: actually allocate legacy interrupts on PV guests [ Upstream commit 702f926067d2a4b28c10a3c41a1172dd62d9e735 ] b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number of legacy interrupts when actually nr_legacy_irqs() returns 0 after probe_8259A(). Use NR_IRQS_LEGACY instead. Signed-off-by: Stefano Stabellini CC: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 448691a78243ae617a77689847a5c2232939fbc4 Author: Oleg Nesterov Date: Mon May 23 16:23:50 2016 -0700 wait/ptrace: assume __WALL if the child is traced [ Upstream commit bf959931ddb88c4e4366e96dd22e68fa0db9527c ] The following program (simplified version of generated by syzkaller) #include #include #include #include #include void *thread_func(void *arg) { ptrace(PTRACE_TRACEME, 0,0,0); return 0; } int main(void) { pthread_t thread; if (fork()) return 0; while (getppid() != 1) ; pthread_create(&thread, NULL, thread_func, NULL); pthread_join(thread, NULL); return 0; } creates an unreapable zombie if /sbin/init doesn't use __WALL. This is not a kernel bug, at least in a sense that everything works as expected: debugger should reap a traced sub-thread before it can reap the leader, but without __WALL/__WCLONE do_wait() ignores sub-threads. Unfortunately, it seems that /sbin/init in most (all?) distributions doesn't use it and we have to change the kernel to avoid the problem. Note also that most init's use sys_waitid() which doesn't allow __WALL, so the necessary user-space fix is not that trivial. This patch just adds the "ptrace" check into eligible_child(). To some degree this matches the "tsk->ptrace" in exit_notify(), ->exit_signal is mostly ignored when the tracee reports to debugger. Or WSTOPPED, the tracer doesn't need to set this flag to wait for the stopped tracee. This obviously means the user-visible change: __WCLONE and __WALL no longer have any meaning for debugger. And I can only hope that this won't break something, but at least strace/gdb won't suffer. We could make a more conservative change. Say, we can take __WCLONE into account, or !thread_group_leader(). But it would be nice to not complicate these historical/confusing checks. Signed-off-by: Oleg Nesterov Reported-by: Dmitry Vyukov Cc: Denys Vlasenko Cc: Jan Kratochvil Cc: "Michael Kerrisk (man-pages)" Cc: Pedro Alves Cc: Roland McGrath Cc: Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9a9586d6bd8e09d49f17ccf50a4a371565e204f7 Author: Tomáš Trnka Date: Fri May 20 16:41:10 2016 +0200 sunrpc: fix stripping of padded MIC tokens [ Upstream commit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 ] The length of the GSS MIC token need not be a multiple of four bytes. It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data() would previously only trim mic.len + 4 B. The remaining up to three bytes would then trigger a check in nfs4svc_decode_compoundargs(), leading to a "garbage args" error and mount failure: nfs4svc_decode_compoundargs: compound not properly padded! nfsd: failed to decode arguments! This would prevent older clients using the pre-RFC 4121 MIC format (37-byte MIC including a 9-byte OID) from mounting exports from v3.9+ servers using krb5i. The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off trailing checksum before returning decrypted or integrity authenticated buffer"). Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..." Signed-off-by: Tomáš Trnka Cc: stable@vger.kernel.org Acked-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit bd41a6cc5996b394b48b2f1a47b61cb6bb4d0bd3 Author: Adrian Hunter Date: Fri May 20 10:33:48 2016 +0300 mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers [ Upstream commit 265984b36ce82fec67957d452dd2b22e010611e4 ] The CMD19/CMD14 bus width test has been found to be unreliable in some cases. It is not essential, so simply remove it. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a0b7f5619bd13ac231bae4931358d0199b019892 Author: Matt Gumbel Date: Fri May 20 10:33:46 2016 +0300 mmc: longer timeout for long read time quirk [ Upstream commit 32ecd320db39bcb007679ed42f283740641b81ea ] 008GE0 Toshiba mmc in some Intel Baytrail tablets responds to MMC_SEND_EXT_CSD in 450-600ms. This patch will... () Increase the long read time quirk timeout from 300ms to 600ms. Original author of that quirk says 300ms was only a guess and that the number may need to be raised in the future. () Add this specific MMC to the quirk Signed-off-by: Matt Gumbel Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9b78827acea8c1d39c9d88b19d713c17b0e2bf74 Author: Ville Syrjälä Date: Fri May 13 17:55:17 2016 +0300 drm/i915: Don't leave old junk in ilk active watermarks on readout [ Upstream commit 7045c3689f148a0c95f42bae8ef3eb2829ac7de9 ] When we read out the watermark state from the hardware we're supposed to transfer that into the active watermarks, but currently we fail to any part of the active watermarks that isn't explicitly written. Let's clear it all upfront. Looks like this has been like this since the beginning, when I added the readout. No idea why I didn't clear it up. Cc: Matt Roper Fixes: 243e6a44b9ca ("drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()") Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä Reviewed-by: Matt Roper Signed-off-by: Matt Roper Link: http://patchwork.freedesktop.org/patch/msgid/1463151318-14719-2-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit 15606534bf0a65d8a74a90fd57b8712d147dbca6) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit a6fccead2b1285eb96e15e219467f985db0871b9 Author: Rafael J. Wysocki Date: Fri May 20 23:09:49 2016 +0200 PM / sleep: Handle failures in device_suspend_late() consistently [ Upstream commit 3a17fb329da68cb00558721aff876a80bba2fdb9 ] Grygorii Strashko reports: The PM runtime will be left disabled for the device if its .suspend_late() callback fails and async suspend is not allowed for this device. In this case device will not be added in dpm_late_early_list and dpm_resume_early() will ignore this device, as result PM runtime will be disabled for it forever (side effect: after 8 subsequent failures for the same device the PM runtime will be reenabled due to disable_depth overflow). To fix this problem, add devices to dpm_late_early_list regardless of whether or not device_suspend_late() returns errors for them. That will ensure failures in there to be handled consistently for all devices regardless of their async suspend/resume status. Reported-by: Grygorii Strashko Tested-by: Grygorii Strashko Signed-off-by: Rafael J. Wysocki Cc: All applicable Signed-off-by: Sasha Levin commit 8a1a3f78830798b519870ce05fd68e65848a9da3 Author: Ricky Liang Date: Fri May 20 10:58:59 2016 -0700 Input: uinput - handle compat ioctl for UI_SET_PHYS [ Upstream commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 ] When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS ioctl needs to be treated with special care, as it has the pointer size encoded in the command. Signed-off-by: Ricky Liang Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit fb4e7a0a3fc65ccdd3600970d3e225808a61a81a Author: Matt Evans Date: Mon May 16 13:54:56 2016 +0100 kvm: arm64: Fix EC field in inject_abt64 [ Upstream commit e4fe9e7dc3828bf6a5714eb3c55aef6260d823a2 ] The EC field of the constructed ESR is conditionally modified by ORing in ESR_ELx_EC_DABT_LOW for a data abort. However, ESR_ELx_EC_SHIFT is missing from this condition. Signed-off-by: Matt Evans Acked-by: Marc Zyngier Cc: Signed-off-by: Christoffer Dall Signed-off-by: Sasha Levin commit 0d4a4eba82e4334897d7577b69cdc58fb150c5a5 Author: Kai-Heng Feng Date: Fri May 20 15:47:23 2016 +0800 ALSA: hda - Fix headphone noise on Dell XPS 13 9360 [ Upstream commit 423cd785619ac6778252fbdb916505aa1c153959 ] The headphone has noise when playing sound or switching microphone sources. It uses the same codec on XPS 13 9350, but with different subsystem ID. Applying the fixup can solve the issue. Also, changing the model name to better differentiate models. v2: Reorder by device ID. Signed-off-by: Kai-Heng Feng Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 71f788d68dbe931b42c7318f5cb5cb0dfae0773b Author: David Henningsson Date: Tue Dec 15 14:44:03 2015 +0100 ALSA: hda - Fix headphone mic input on a few Dell ALC293 machines [ Upstream commit c04017ea81dc1eccae87be7ac7b82b2972f9931f ] These laptops support both headphone, headset and mic modes for the 3.5mm jack. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1526330 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f1f125da12d365c4459aa356ea33459039966355 Author: Sachin Prabhu Date: Tue May 17 18:20:13 2016 -0500 cifs: Create dedicated keyring for spnego operations [ Upstream commit b74cb9a80268be5c80cf4c87c74debf0ff2129ac ] The session key is the default keyring set for request_key operations. This session key is revoked when the user owning the session logs out. Any long running daemon processes started by this session ends up with revoked session keyring which prevents these processes from using the request_key mechanism from obtaining the krb5 keys. The problem has been reported by a large number of autofs users. The problem is also seen with multiuser mounts where the share may be used by processes run by a user who has since logged out. A reproducer using automount is available on the Red Hat bz. The patch creates a new keyring which is used to cache cifs spnego upcalls. Red Hat bz: 1267754 Signed-off-by: Sachin Prabhu Reported-by: Scott Mayhew Reviewed-by: Shirish Pargaonkar CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ded044fcdd60ec9fea0e3cc512d85073f88d129b Author: Mark Brown Date: Wed May 18 18:30:39 2016 +0100 ASoC: ak4642: Enable cache usage to fix crashes on resume [ Upstream commit d3030d11961a8c103cf07aed59905276ddfc06c2 ] The ak4642 driver is using a regmap cache sync to restore the configuration of the chip on resume but (as Peter observed) does not actually define a register cache which means that the resume is never going to work and we trigger asserts in regmap. Fix this by enabling caching. Reported-by: Geert Uytterhoeven Reported-by: Peter Ujfalusi Tested-by: Geert Uytterhoeven Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 141afa30231ef169dc4d1bcc00c00478068cf2f7 Author: Axel Lin Date: Wed Jul 1 00:56:36 2015 +0800 ASoC: ak4642: Fix up max_register setting [ Upstream commit f8ea6cebcfa6499949392da71fc427567c9e5a0e ] The max_register setting for ak4642, ak4643 and ak4648 are wrong, fix it. According to the datasheet: the maximum valid register for ak4642 is 0x1f the maximum valid register for ak4643 is 0x24 the maximum valid register for ak4648 is 0x27 The default settings for ak4642 and ak4643 are the same for 0x0 ~ 0x1f registers, so it's fine to use the same reg_default table with differnt num_reg_defaults setting. Signed-off-by: Axel Lin Tested-by: Kuninori Morimoto Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4b126ba9fab396983926238ab018c727a086996e Author: Dave Chinner Date: Wed May 18 13:54:23 2016 +1000 xfs: skip stale inodes in xfs_iflush_cluster [ Upstream commit 7d3aa7fe970791f1a674b14572a411accf2f4d4e ] We don't write back stale inodes so we should skip them in xfs_iflush_cluster, too. cc: # 3.10.x- Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 3eeb7e764de82bba421e04154bb62b8dc518c3a1 Author: Dave Chinner Date: Wed May 18 13:54:22 2016 +1000 xfs: fix inode validity check in xfs_iflush_cluster [ Upstream commit 51b07f30a71c27405259a0248206ed4e22adbee2 ] Some careless idiot(*) wrote crap code in commit 1a3e8f3 ("xfs: convert inode cache lookups to use RCU locking") back in late 2010, and so xfs_iflush_cluster checks the wrong inode for whether it is still valid under RCU protection. Fix it to lock and check the correct inode. (*) Careless-idiot: Dave Chinner cc: # 3.10.x- Discovered-by: Brain Foster Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 6659d79405e4c4ec1abac74aaf551fb822081112 Author: Dave Chinner Date: Wed May 18 13:53:42 2016 +1000 xfs: xfs_iflush_cluster fails to abort on error [ Upstream commit b1438f477934f5a4d5a44df26f3079a7575d5946 ] When a failure due to an inode buffer occurs, the error handling fails to abort the inode writeback correctly. This can result in the inode being reclaimed whilst still in the AIL, leading to use-after-free situations as well as filesystems that cannot be unmounted as the inode log items left in the AIL never get removed. Fix this by ensuring fatal errors from xfs_imap_to_bp() result in the inode flush being aborted correctly. cc: # 3.10.x- Reported-by: Shyam Kaushik Diagnosed-by: Shyam Kaushik Tested-by: Shyam Kaushik Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit c504b774bcd91a3c5963c8a81573a46dc0a8d0f8 Author: Daniel Lezcano Date: Tue May 17 16:54:00 2016 +0200 cpuidle: Fix cpuidle_state_is_coupled() argument in cpuidle_enter() [ Upstream commit e7387da52028b072489c45efeb7a916c0205ebd2 ] Commit 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle) rightfully fixed a regression by letting the coupled idle state framework to handle local interrupt enabling when the CPU is exiting an idle state. The current code checks if the idle state is coupled and, if so, it will let the coupled code to enable interrupts. This way, it can decrement the ready-count before handling the interrupt. This mechanism prevents the other CPUs from waiting for a CPU which is handling interrupts. But the check is done against the state index returned by the back end driver's ->enter functions which could be different from the initial index passed as parameter to the cpuidle_enter_state() function. entered_state = target_state->enter(dev, drv, index); [ ... ] if (!cpuidle_state_is_coupled(drv, entered_state)) local_irq_enable(); [ ... ] If the 'index' is referring to a coupled idle state but the 'entered_state' is *not* coupled, then the interrupts are enabled again. All CPUs blocked on the sync barrier may busy loop longer if the CPU has interrupts to handle before decrementing the ready-count. That's consuming more energy than saving. Fixes: 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle) Signed-off-by: Daniel Lezcano Cc: 3.15+ # 3.15+ [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d3bbf7b3c6c919f9b19dcc8277603c1885e487b7 Author: Xunlei Pang Date: Tue Aug 4 13:48:56 2015 +0800 cpuidle/coupled: Remove redundant 'dev' argument of cpuidle_state_is_coupled() [ Upstream commit 4c1ed5a6079078699128064664913ae7b079648f ] For cpuidle_state_is_coupled(), 'dev' is not used, so remove it. Signed-off-by: Xunlei Pang Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit cde02e3a5b143885f6b68b7e687eb4326d5da99d Author: Steve French Date: Thu May 12 21:20:36 2016 -0500 remove directory incorrectly tries to set delete on close on non-empty directories [ Upstream commit 897fba1172d637d344f009d700f7eb8a1fa262f1 ] Wrong return code was being returned on SMB3 rmdir of non-empty directory. For SMB3 (unlike for cifs), we attempt to delete a directory by set of delete on close flag on the open. Windows clients set this flag via a set info (SET_FILE_DISPOSITION to set this flag) which properly checks if the directory is empty. With this patch on smb3 mounts we correctly return "DIRECTORY NOT EMPTY" on attempts to remove a non-empty directory. Signed-off-by: Steve French CC: Stable Acked-by: Sachin Prabhu Signed-off-by: Sasha Levin commit b6044542f162483636dae70bb691d50e483fb438 Author: Stefan Metzmacher Date: Tue May 3 10:52:30 2016 +0200 fs/cifs: correctly to anonymous authentication for the NTLM(v2) authentication [ Upstream commit 1a967d6c9b39c226be1b45f13acd4d8a5ab3dc44 ] Only server which map unknown users to guest will allow access using a non-null NTLMv2_Response. For Samba it's the "map to guest = bad user" option. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913 Signed-off-by: Stefan Metzmacher CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 6842cd24b8ce4f6f540184a16d134cf4ebfe337c Author: Stefan Metzmacher Date: Tue May 3 10:52:30 2016 +0200 fs/cifs: correctly to anonymous authentication for the NTLM(v1) authentication [ Upstream commit 777f69b8d26bf35ade4a76b08f203c11e048365d ] Only server which map unknown users to guest will allow access using a non-null NTChallengeResponse. For Samba it's the "map to guest = bad user" option. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913 Signed-off-by: Stefan Metzmacher CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 8f83c4496e5a08bc834a7475129f64d6e21789aa Author: Stefan Metzmacher Date: Tue May 3 10:52:30 2016 +0200 fs/cifs: correctly to anonymous authentication for the LANMAN authentication [ Upstream commit fa8f3a354bb775ec586e4475bcb07f7dece97e0c ] Only server which map unknown users to guest will allow access using a non-null LMChallengeResponse. For Samba it's the "map to guest = bad user" option. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913 Signed-off-by: Stefan Metzmacher CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f39b179308d938c7bb6da74fd0699c0eb4356ef8 Author: Stefan Metzmacher Date: Tue May 3 10:52:30 2016 +0200 fs/cifs: correctly to anonymous authentication via NTLMSSP [ Upstream commit cfda35d98298131bf38fbad3ce4cd5ecb3cf18db ] See [MS-NLMP] 3.2.5.1.2 Server Receives an AUTHENTICATE_MESSAGE from the Client: ... Set NullSession to FALSE If (AUTHENTICATE_MESSAGE.UserNameLen == 0 AND AUTHENTICATE_MESSAGE.NtChallengeResponse.Length == 0 AND (AUTHENTICATE_MESSAGE.LmChallengeResponse == Z(1) OR AUTHENTICATE_MESSAGE.LmChallengeResponse.Length == 0)) -- Special case: client requested anonymous authentication Set NullSession to TRUE ... Only server which map unknown users to guest will allow access using a non-null NTChallengeResponse. For Samba it's the "map to guest = bad user" option. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913 CC: Stable Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 9a2257ff4ccf1ccd1ed0446f9ff5813232594ffc Author: Lyude Date: Thu May 12 10:56:59 2016 -0400 drm/fb_helper: Fix references to dev->mode_config.num_connector [ Upstream commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 ] During boot, MST hotplugs are generally expected (even if no physical hotplugging occurs) and result in DRM's connector topology changing. This means that using num_connector from the current mode configuration can lead to the number of connectors changing under us. This can lead to some nasty scenarios in fbcon: - We allocate an array to the size of dev->mode_config.num_connectors. - MST hotplug occurs, dev->mode_config.num_connectors gets incremented. - We try to loop through each element in the array using the new value of dev->mode_config.num_connectors, and end up going out of bounds since dev->mode_config.num_connectors is now larger then the array we allocated. fb_helper->connector_count however, will always remain consistent while we do a modeset in fb_helper. Note: This is just polish for 4.7, Dave Airlie's drm_connector refcounting fixed these bugs for real. But it's good enough duct-tape for stable kernel backporting, since backporting the refcounting changes is way too invasive. Cc: stable@vger.kernel.org Signed-off-by: Lyude [danvet: Clarify why we need this. Also remove the now unused "dev" local variable to appease gcc.] Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com Signed-off-by: Sasha Levin commit d648fcdb0adc44bafa01dc1cd0fbc3e4c9375488 Author: Lyude Date: Thu May 12 10:56:58 2016 -0400 drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config() [ Upstream commit 14a3842a1d5945067d1dd0788f314e14d5b18e5b ] During boot time, MST devices usually send a ton of hotplug events irregardless of whether or not any physical hotplugs actually occurred. Hotplugs mean connectors being created/destroyed, and the number of DRM connectors changing under us. This isn't a problem if we use fb_helper->connector_count since we only set it once in the code, however if we use num_connector from struct drm_mode_config we risk it's value changing under us. On top of that, there's even a chance that dev->mode_config.num_connector != fb_helper->connector_count. If the number of connectors happens to increase under us, we'll end up using the wrong array size for memcpy and start writing beyond the actual length of the array, occasionally resulting in kernel panics. Note: This is just polish for 4.7, Dave Airlie's drm_connector refcounting fixed these bugs for real. But it's good enough duct-tape for stable kernel backporting, since backporting the refcounting changes is way too invasive. Cc: stable@vger.kernel.org Signed-off-by: Lyude [danvet: Clarify why we need this.] Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-2-git-send-email-cpaul@redhat.com Signed-off-by: Sasha Levin commit f52a1b990cc3b4d4c4f0135ea3569848dca16784 Author: Maciej W. Rozycki Date: Tue May 17 06:12:27 2016 +0100 MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC [ Upstream commit e49d38488515057dba8f0c2ba4cfde5be4a7281f ] Fix a build regression from commit c9017757c532 ("MIPS: init upper 64b of vector registers when MSA is first used"): arch/mips/built-in.o: In function `enable_restore_fp_context': traps.c:(.text+0xbb90): undefined reference to `_init_msa_upper' traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper' traps.c:(.text+0xbef0): undefined reference to `_init_msa_upper' traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper' to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are unable to figure out that calls to `_init_msa_upper' are indeed dead. Of the many ways to tackle this failure choose the approach we have already taken in `thread_msa_context_live'. [ralf@linux-mips.org: Drop patch segment to junk file.] Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v3.16+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13271/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 8f25a2f3345dcee6608b55d50b34f8c1bb782f7b Author: Prarit Bhargava Date: Wed May 11 12:27:16 2016 -0400 PCI: Disable all BAR sizing for devices with non-compliant BARs [ Upstream commit ad67b437f187ea818b2860524d10f878fadfdd99 ] b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with the PCI spec. But it didn't do anything for expansion ROM BARs, so we still try to size them, resulting in warnings like this on Broadwell-EP: pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref] Move the non-compliant BAR check from __pci_read_base() up to pci_read_bases() so it applies to the expansion ROM BAR as well as to BARs 0-5. Note that direct callers of __pci_read_base(), like sriov_init(), will now bypass this check. We haven't had reports of devices with broken SR-IOV BARs yet. [bhelgaas: changelog] Fixes: b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs") Signed-off-by: Prarit Bhargava Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org CC: Thomas Gleixner CC: Ingo Molnar CC: "H. Peter Anvin" CC: Andi Kleen Signed-off-by: Sasha Levin commit a87165993a3702ec5ec8f3af87df8edcce26b3da Author: Adrian Hunter Date: Thu May 5 08:12:28 2016 +0300 mmc: mmc: Fix partition switch timeout for some eMMCs [ Upstream commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 ] Some eMMCs set the partition switch timeout too low. Now typically eMMCs are considered a critical component (e.g. because they store the root file system) and consequently are expected to be reliable. Thus we can neglect the use case where eMMCs can't switch reliably and we might want a lower timeout to facilitate speedy recovery. Although we could employ a quirk for the cards that are affected (if we could identify them all), as described above, there is little benefit to having a low timeout, so instead simply set a minimum timeout. The minimum is set to 300ms somewhat arbitrarily - the examples that have been seen had a timeout of 10ms but were sometimes taking 60-70ms. Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ab2cfdb8ef5da3d4cd237a3f15cc2d7ad4623260 Author: Steven Rostedt (Red Hat) Date: Fri May 13 09:34:12 2016 -0400 ring-buffer: Prevent overflow of size in ring_buffer_resize() [ Upstream commit 59643d1535eb220668692a5359de22545af579f6 ] If the size passed to ring_buffer_resize() is greater than MAX_LONG - BUF_PAGE_SIZE then the DIV_ROUND_UP() will return zero. Here's the details: # echo 18014398509481980 > /sys/kernel/debug/tracing/buffer_size_kb tracing_entries_write() processes this and converts kb to bytes. 18014398509481980 << 10 = 18446744073709547520 and this is passed to ring_buffer_resize() as unsigned long size. size = DIV_ROUND_UP(size, BUF_PAGE_SIZE); Where DIV_ROUND_UP(a, b) is (a + b - 1)/b BUF_PAGE_SIZE is 4080 and here 18446744073709547520 + 4080 - 1 = 18446744073709551599 where 18446744073709551599 is still smaller than 2^64 2^64 - 18446744073709551599 = 17 But now 18446744073709551599 / 4080 = 4521260802379792 and size = size * 4080 = 18446744073709551360 This is checked to make sure its still greater than 2 * 4080, which it is. Then we convert to the number of buffer pages needed. nr_page = DIV_ROUND_UP(size, BUF_PAGE_SIZE) but this time size is 18446744073709551360 and 2^64 - (18446744073709551360 + 4080 - 1) = -3823 Thus it overflows and the resulting number is less than 4080, which makes 3823 / 4080 = 0 an nr_pages is set to this. As we already checked against the minimum that nr_pages may be, this causes the logic to fail as well, and we crash the kernel. There's no reason to have the two DIV_ROUND_UP() (that's just result of historical code changes), clean up the code and fix this bug. Cc: stable@vger.kernel.org # 3.5+ Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic") Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 453babf108cade06562021a1ce8787f28e5fee08 Author: Steven Rostedt (Red Hat) Date: Thu May 12 11:01:24 2016 -0400 ring-buffer: Use long for nr_pages to avoid overflow failures [ Upstream commit 9b94a8fba501f38368aef6ac1b30e7335252a220 ] The size variable to change the ring buffer in ftrace is a long. The nr_pages used to update the ring buffer based on the size is int. On 64 bit machines this can cause an overflow problem. For example, the following will cause the ring buffer to crash: # cd /sys/kernel/debug/tracing # echo 10 > buffer_size_kb # echo 8556384240 > buffer_size_kb Then you get the warning of: WARNING: CPU: 1 PID: 318 at kernel/trace/ring_buffer.c:1527 rb_update_pages+0x22f/0x260 Which is: RB_WARN_ON(cpu_buffer, nr_removed); Note each ring buffer page holds 4080 bytes. This is because: 1) 10 causes the ring buffer to have 3 pages. (10kb requires 3 * 4080 pages to hold) 2) (2^31 / 2^10 + 1) * 4080 = 8556384240 The value written into buffer_size_kb is shifted by 10 and then passed to ring_buffer_resize(). 8556384240 * 2^10 = 8761737461760 3) The size passed to ring_buffer_resize() is then divided by BUF_PAGE_SIZE which is 4080. 8761737461760 / 4080 = 2147484672 4) nr_pages is subtracted from the current nr_pages (3) and we get: 2147484669. This value is saved in a signed integer nr_pages_to_update 5) 2147484669 is greater than 2^31 but smaller than 2^32, a signed int turns into the value of -2147482627 6) As the value is a negative number, in update_pages_handler() it is negated and passed to rb_remove_pages() and 2147482627 pages will be removed, which is much larger than 3 and it causes the warning because not all the pages asked to be removed were removed. Link: https://bugzilla.kernel.org/show_bug.cgi?id=118001 Cc: stable@vger.kernel.org # 2.6.28+ Fixes: 7a8e76a3829f1 ("tracing: unified trace buffer") Reported-by: Hao Qin Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit d6bdff22c8511e4f7d489d180997c929fa7b55b8 Author: Steven Rostedt (Red Hat) Date: Wed May 27 10:27:47 2015 -0400 ring-buffer: Move recursive check to per_cpu descriptor [ Upstream commit 58a09ec6e3ec88c9c7e061479f1ef7fe93324a87 ] Instead of using a global per_cpu variable to perform the recursive checks into the ring buffer, use the already existing per_cpu descriptor that is part of the ring buffer itself. Not only does this simplify the code, it also allows for one ring buffer to be used within the guts of the use of another ring buffer. For example trace_printk() can now be used within the ring buffer to record changes done by an instance into the main ring buffer. The recursion checks will prevent the trace_printk() itself from causing recursive issues with the main ring buffer (it is just ignored), but the recursive checks wont prevent the trace_printk() from recording other ring buffers. Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit ac4e03df07cba1d92e4555c577bc3179a10c6a72 Author: Steven Rostedt (Red Hat) Date: Thu May 21 17:39:29 2015 -0400 ring-buffer: Add unlikelys to make fast path the default [ Upstream commit 3205f8063b6cc54b20d5080fb79dfcbd9c39e93d ] I was running the trace_event benchmark and noticed that the times to record a trace_event was all over the place. I looked at the assembly of the ring_buffer_lock_reserver() and saw this: : 31 c0 xor %eax,%eax 48 83 3d 76 47 bd 00 cmpq $0x1,0xbd4776(%rip) # ffffffff81d10d60 01 55 push %rbp 48 89 e5 mov %rsp,%rbp 75 1d jne ffffffff8113c60d 65 ff 05 69 e3 ec 7e incl %gs:0x7eece369(%rip) # a960 <__preempt_count> 8b 47 08 mov 0x8(%rdi),%eax 85 c0 test %eax,%eax +---- 74 12 je ffffffff8113c610 | 65 ff 0d 5b e3 ec 7e decl %gs:0x7eece35b(%rip) # a960 <__preempt_count> | 0f 84 85 00 00 00 je ffffffff8113c690 | 31 c0 xor %eax,%eax | 5d pop %rbp | c3 retq | 90 nop +---> 65 44 8b 05 48 e3 ec mov %gs:0x7eece348(%rip),%r8d # a960 <__preempt_count> 7e 41 81 e0 ff ff ff 7f and $0x7fffffff,%r8d b0 08 mov $0x8,%al 65 8b 0d 58 36 ed 7e mov %gs:0x7eed3658(%rip),%ecx # fc80 41 f7 c0 00 ff 1f 00 test $0x1fff00,%r8d 74 1e je ffffffff8113c64f 41 f7 c0 00 00 10 00 test $0x100000,%r8d b0 01 mov $0x1,%al 75 13 jne ffffffff8113c64f 41 81 e0 00 00 0f 00 and $0xf0000,%r8d 49 83 f8 01 cmp $0x1,%r8 19 c0 sbb %eax,%eax 83 e0 02 and $0x2,%eax 83 c0 02 add $0x2,%eax 85 c8 test %ecx,%eax 75 ab jne ffffffff8113c5fe 09 c8 or %ecx,%eax 65 89 05 24 36 ed 7e mov %eax,%gs:0x7eed3624(%rip) # fc80 The arrow is the fast path. After adding the unlikely's, the fast path looks a bit better: : 31 c0 xor %eax,%eax 48 83 3d 76 47 bd 00 cmpq $0x1,0xbd4776(%rip) # ffffffff81d10d60 01 55 push %rbp 48 89 e5 mov %rsp,%rbp 75 7b jne ffffffff8113c66b 65 ff 05 69 e3 ec 7e incl %gs:0x7eece369(%rip) # a960 <__preempt_count> 8b 47 08 mov 0x8(%rdi),%eax 85 c0 test %eax,%eax 0f 85 9f 00 00 00 jne ffffffff8113c6a1 65 8b 0d 57 e3 ec 7e mov %gs:0x7eece357(%rip),%ecx # a960 <__preempt_count> 81 e1 ff ff ff 7f and $0x7fffffff,%ecx b0 08 mov $0x8,%al 65 8b 15 68 36 ed 7e mov %gs:0x7eed3668(%rip),%edx # fc80 f7 c1 00 ff 1f 00 test $0x1fff00,%ecx 75 50 jne ffffffff8113c670 85 d0 test %edx,%eax 75 7d jne ffffffff8113c6a1 09 d0 or %edx,%eax 65 89 05 53 36 ed 7e mov %eax,%gs:0x7eed3653(%rip) # fc80 65 8b 05 fc da ec 7e mov %gs:0x7eecdafc(%rip),%eax # a130 89 c2 mov %eax,%edx Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit daf7322babd9946b7c2e2eae53d1f68f7665766b Author: Paul Burton Date: Thu Apr 21 12:43:57 2016 +0100 MIPS: Disable preemption during prctl(PR_SET_FP_MODE, ...) [ Upstream commit bd239f1e1429e7781096bf3884bdb1b2b1bb4f28 ] Whilst a PR_SET_FP_MODE prctl is performed there are decisions made based upon whether the task is executing on the current CPU. This may change if we're preempted, so disable preemption to avoid such changes for the lifetime of the mode switch. Signed-off-by: Paul Burton Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") Reviewed-by: Maciej W. Rozycki Tested-by: Aurelien Jarno Cc: Adam Buchbinder Cc: James Hogan Cc: stable # v4.0+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13144/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 49dc90fd14c0ce2ec494d44f1cd6594603d7c4a0 Author: Maciej W. Rozycki Date: Thu May 12 10:19:08 2016 +0100 MIPS: ptrace: Prevent writes to read-only FCSR bits [ Upstream commit abf378be49f38c4d3e23581d3df3fa9f1b1b11d2 ] Correct the cases missed with commit 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling") and prevent writes to read-only FCSR bits there. This in particular applies to FP context initialisation where any IEEE 754-2008 bits preset by `mips_set_personality_nan' are cleared before the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request addressing FPC_CSR where no masking of read-only FCSR bits is done. Remove the FCSR clearing from FP context initialisation then and unify PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out code from `ptrace_setfpregs' and calling it from both places. This mostly matters to soft float configurations where the emulator can be switched this way to a mode which should not be accessible and cannot be set with the CTC1 instruction. With hard float configurations any effect is transient anyway as read-only bits will retain their values at the time the FP context is restored. Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v4.0+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13239/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit ba1ccd8e28e1009a1866bea1580fa565c244a353 Author: Maciej W. Rozycki Date: Thu May 12 10:18:27 2016 +0100 MIPS: ptrace: Fix FP context restoration FCSR regression [ Upstream commit 4249548454f7ba4581aeee26bd83f42b48a14d15 ] Fix a floating-point context restoration regression introduced with commit 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling") that causes a Floating Point exception and consequently a kernel oops with hard float configurations when one or more FCSR Enable and their corresponding Cause bits are set both at a time via a ptrace(2) call. To do so reinstate Cause bit masking originally introduced with commit b1442d39fac2 ("MIPS: Prevent user from setting FCSR cause bits") to address this exact problem and then inadvertently removed from the PTRACE_SETFPREGS request with the commit referred above. Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v4.0+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13238/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit fc39f274bfb6bcff688b099ccbcc081460bb0325 Author: Paul Burton Date: Thu Apr 21 14:04:55 2016 +0100 MIPS: math-emu: Fix jalr emulation when rd == $0 [ Upstream commit ab4a92e66741b35ca12f8497896bafbe579c28a1 ] When emulating a jalr instruction with rd == $0, the code in isBranchInstr was incorrectly writing to GPR $0 which should actually always remain zeroed. This would lead to any further instructions emulated which use $0 operating on a bogus value until the task is next context switched, at which point the value of $0 in the task context would be restored to the correct zero by a store in SAVE_SOME. Fix this by not writing to rd if it is $0. Fixes: 102cedc32a6e ("MIPS: microMIPS: Floating point support.") Signed-off-by: Paul Burton Cc: Maciej W. Rozycki Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable # v3.10 Patchwork: https://patchwork.linux-mips.org/patch/13160/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 4a16f41bf4a45e70a73e0fdc9bfcc81776387783 Author: James Hogan Date: Mon Feb 8 18:43:51 2016 +0000 MIPS: Fix uapi include in exported asm/siginfo.h [ Upstream commit 987e5b834467c9251ca584febda65ef8f66351a9 ] Since commit 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime"), MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h directly before defining MIPS' struct siginfo, in order to get the necessary definitions needed for the siginfo struct without the generic copy_siginfo() hitting compiler errors due to struct siginfo not yet being defined. Now that the generic copy_siginfo() is moved out to linux/signal.h we can safely include asm-generic/siginfo.h before defining the MIPS specific struct siginfo, which avoids the uapi/ include as well as breakage due to generic copy_siginfo() being defined before struct siginfo. Reported-by: Christopher Ferris Fixes: 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime") Signed-off-by: James Hogan Cc: Petr Malat Cc: linux-mips@linux-mips.org Cc: # 4.0- Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 175c648589e0b55645854a95895554b0887af9af Author: James Hogan Date: Mon Feb 8 18:43:50 2016 +0000 SIGNAL: Move generic copy_siginfo() to signal.h [ Upstream commit ca9eb49aa9562eaadf3cea071ec7018ad6800425 ] The generic copy_siginfo() is currently defined in asm-generic/siginfo.h, after including uapi/asm-generic/siginfo.h which defines the generic struct siginfo. However this makes it awkward for an architecture to use it if it has to define its own struct siginfo (e.g. MIPS and potentially IA64), since it means that asm-generic/siginfo.h can only be included after defining the arch-specific siginfo, which may be problematic if the arch-specific definition needs definitions from uapi/asm-generic/siginfo.h. It is possible to work around this by first including uapi/asm-generic/siginfo.h to get the constants before defining the arch-specific siginfo, and include asm-generic/siginfo.h after. However uapi headers can't be included by other uapi headers, so that first include has to be in an ifdef __kernel__, with the non __kernel__ case including the non-UAPI header instead. Instead of that mess, move the generic copy_siginfo() definition into linux/signal.h, which allows an arch-specific uapi/asm/siginfo.h to include asm-generic/siginfo.h and define the arch-specific siginfo, and for the generic copy_siginfo() to see that arch-specific definition. Signed-off-by: James Hogan Cc: Arnd Bergmann Cc: Ralf Baechle Cc: Petr Malat Cc: Tony Luck Cc: Fenghua Yu Cc: Christopher Ferris Cc: linux-arch@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-ia64@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: # 4.0- Patchwork: https://patchwork.linux-mips.org/patch/12478/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit de444b25c68049fb560e0530ee0425fd9db981f0 Author: Paul Burton Date: Tue Mar 1 02:37:59 2016 +0000 MIPS: Sync icache & dcache in set_pte_at [ Upstream commit 37d22a0d798b5c938b277d32cfd86dc231381342 ] It's possible for pages to become visible prior to update_mmu_cache running if a thread within the same address space preempts the current thread or runs simultaneously on another CPU. That is, the following scenario is possible: CPU0 CPU1 write to page flush_dcache_page flush_icache_page set_pte_at map page update_mmu_cache If CPU1 maps the page in between CPU0's set_pte_at, which marks it valid & visible, and update_mmu_cache where the dcache flush occurs then CPU1s icache will fill from stale data (unless it fills from the dcache, in which case all is good, but most MIPS CPUs don't have this property). Commit 4d46a67a3eb8 ("MIPS: Fix race condition in lazy cache flushing.") attempted to fix that by performing the dcache flush in flush_icache_page such that it occurs before the set_pte_at call makes the page visible. However it has the problem that not all code that writes to pages exposed to userland call flush_icache_page. There are many callers of set_pte_at under mm/ and only 2 of them do call flush_icache_page. Thus the race window between a page becoming visible & being coherent between the icache & dcache remains open in some cases. To illustrate some of the cases, a WARN was added to __update_cache with this patch applied that triggered in cases where a page about to be flushed from the dcache was not the last page provided to flush_icache_page. That is, backtraces were obtained for cases in which the race window is left open without this patch. The 2 standout examples follow. When forking a process: [ 15.271842] [<80417630>] __update_cache+0xcc/0x188 [ 15.277274] [<80530394>] copy_page_range+0x56c/0x6ac [ 15.282861] [<8042936c>] copy_process.part.54+0xd40/0x17ac [ 15.289028] [<80429f80>] do_fork+0xe4/0x420 [ 15.293747] [<80413808>] handle_sys+0x128/0x14c When exec'ing an ELF binary: [ 14.445964] [<80417630>] __update_cache+0xcc/0x188 [ 14.451369] [<80538d88>] move_page_tables+0x414/0x498 [ 14.457075] [<8055d848>] setup_arg_pages+0x220/0x318 [ 14.462685] [<805b0f38>] load_elf_binary+0x530/0x12a0 [ 14.468374] [<8055ec3c>] search_binary_handler+0xbc/0x214 [ 14.474444] [<8055f6c0>] do_execveat_common+0x43c/0x67c [ 14.480324] [<8055f938>] do_execve+0x38/0x44 [ 14.485137] [<80413808>] handle_sys+0x128/0x14c These code paths write into a page, call flush_dcache_page then call set_pte_at without flush_icache_page inbetween. The end result is that the icache can become corrupted & userland processes may execute unexpected or invalid code, typically resulting in a reserved instruction exception, a trap or a segfault. Fix this race condition fully by performing any cache maintenance required to keep the icache & dcache in sync in set_pte_at, before the page is made valid. This has the added bonus of ensuring the cache maintenance always happens in one location, rather than being duplicated in flush_icache_page & update_mmu_cache. It also matches the way other architectures solve the same problem (see arm, ia64 & powerpc). Signed-off-by: Paul Burton Reported-by: Ionela Voinescu Cc: Lars Persson Fixes: 4d46a67a3eb8 ("MIPS: Fix race condition in lazy cache flushing.") Cc: Steven J. Hill Cc: David Daney Cc: Huacai Chen Cc: Aneesh Kumar K.V Cc: Andrew Morton Cc: Jerome Marchand Cc: Kirill A. Shutemov Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable # v4.1+ Patchwork: https://patchwork.linux-mips.org/patch/12722/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 8c99d76129a9a429a9410df4811b13c091aaa889 Author: Paul Burton Date: Tue Mar 1 02:37:58 2016 +0000 MIPS: Handle highmem pages in __update_cache [ Upstream commit f4281bba818105c7c91799abe40bc05c0dbdaa25 ] The following patch will expose __update_cache to highmem pages. Handle them by mapping them in for the duration of the cache maintenance, just like in __flush_dcache_page. The code for that isn't shared because we need the page address in __update_cache so sharing became messy. Given that the entirity is an extra 5 lines, just duplicate it. Signed-off-by: Paul Burton Cc: Lars Persson Cc: Andrew Morton Cc: Jerome Marchand Cc: Kirill A. Shutemov Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable # v4.1+ Patchwork: https://patchwork.linux-mips.org/patch/12721/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit e7c735b01d8fdfd7215a133dfe9072d73502acfd Author: Paul Burton Date: Tue Mar 1 02:37:57 2016 +0000 MIPS: Flush highmem pages in __flush_dcache_page [ Upstream commit 234859e49a15323cf1b2331bdde7f658c4cb45fb ] When flush_dcache_page is called on an executable page, that page is about to be provided to userland & we can presume that the icache contains no valid entries for its address range. However if the icache does not fill from the dcache then we cannot presume that the pages content has been written back as far as the memories that the dcache will fill from (ie. L2 or further out). This was being done for lowmem pages, but not for highmem which can lead to icache corruption. Fix this by mapping highmem pages & flushing their content from the dcache in __flush_dcache_page before providing the page to userland, just as is done for lowmem pages. Signed-off-by: Paul Burton Cc: Lars Persson Cc: Andrew Morton Cc: Kirill A. Shutemov Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12720/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit deee8f00eda629080d81bf57de8e5d174fb3fce8 Author: Guilherme G. Piccoli Date: Mon Apr 11 16:17:22 2016 -0300 Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell" [ Upstream commit c2078d9ef600bdbe568c89e5ddc2c6f15b7982c8 ] This reverts commit 89a51df5ab1d38b257300b8ac940bbac3bb0eb9b. The function eeh_add_device_early() is used to perform EEH initialization in devices added later on the system, like in hotplug/DLPAR scenarios. Since the commit 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell") a new check was introduced in this function - Cell has no EEH capabilities which led to kernel oops if hotplug was performed, so checking for eeh_enabled() was introduced to avoid the issue. However, in architectures that EEH is present like pSeries or PowerNV, we might reach a case in which no PCI devices are present on boot time and so EEH is not initialized. Then, if a device is added via DLPAR for example, eeh_add_device_early() fails because eeh_enabled() is false, and EEH end up not being enabled at all. This reverts the aforementioned patch since a new verification was introduced by the commit d91dafc02f42 ("powerpc/eeh: Delay probing EEH device during hotplug") and so the original Cell issue does not happen anymore. Cc: stable@vger.kernel.org # v4.1+ Reviewed-by: Gavin Shan Signed-off-by: Guilherme G. Piccoli Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 75d03a9ef249f1ce07e8aad0411e04b0bbfb5910 Author: Gavin Shan Date: Wed Apr 27 11:14:51 2016 +1000 powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover() [ Upstream commit 5a0cdbfd17b90a89c64a71d8aec9773ecdb20d0d ] The function eeh_pe_reset_and_recover() is used to recover EEH error when the passthrou device are transferred to guest and backwards. The content in the device's config space will be lost on PE reset issued in the middle of the recovery. The function saves/restores it before/after the reset. However, config access to some adapters like Broadcom BCM5719 at this point will causes fenced PHB. The config space is always blocked and we save 0xFF's that are restored at late point. The memory BARs are totally corrupted, causing another EEH error upon access to one of the memory BARs. This restores the config space on those adapters like BCM5719 from the content saved to the EEH device when it's populated, to resolve above issue. Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices") Cc: stable@vger.kernel.org #v3.18+ Signed-off-by: Gavin Shan Reviewed-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b7ccd2a25cc0b57564f7d446b97c3ce7295f2919 Author: Gavin Shan Date: Wed Apr 27 11:14:50 2016 +1000 powerpc/eeh: Don't report error in eeh_pe_reset_and_recover() [ Upstream commit affeb0f2d3a9af419ad7ef4ac782e1540b2f7b28 ] The function eeh_pe_reset_and_recover() is used to recover EEH error when the passthrough device are transferred to guest and backwards, meaning the device's driver is vfio-pci or none. When the driver is vfio-pci that provides error_detected() error handler only, the handler simply stops the guest and it's not expected behaviour. On the other hand, no error handlers will be called if we don't have a bound driver. This ignores the error handler in eeh_pe_reset_and_recover() that reports the error to device driver to avoid the exceptional behaviour. Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices") Cc: stable@vger.kernel.org #v3.18+ Signed-off-by: Gavin Shan Reviewed-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 18fc656941a1e06de8bbcf642cc3c43757b890ae Author: Sasha Levin Date: Tue May 31 21:11:00 2016 -0400 sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems [ Upstream commit 20878232c52329f92423d27a60e48b6a6389e0dd ] Systems show a minimal load average of 0.00, 0.01, 0.05 even when they have no load at all. Uptime and /proc/loadavg on all systems with kernels released during the last five years up until kernel version 4.6-rc5, show a 5- and 15-minute minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on idle systems, but the way the kernel calculates this value prevents it from getting lower than the mentioned values. Likewise but not as obviously noticeable, a fully loaded system with no processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95 (multiplied by number of cores). Once the (old) load becomes 93 or higher, it mathematically can never get lower than 93, even when the active (load) remains 0 forever. This results in the strange 0.00, 0.01, 0.05 uptime values on idle systems. Note: 93/2048 = 0.0454..., which rounds up to 0.05. It is not correct to add a 0.5 rounding (=1024/2048) here, since the result from this function is fed back into the next iteration again, so the result of that +0.5 rounding value then gets multiplied by (2048-2037), and then rounded again, so there is a virtual "ghost" load created, next to the old and active load terms. By changing the way the internally kept value is rounded, that internal value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon increasing load, the internally kept load value is rounded up, when the load is decreasing, the load value is rounded down. The modified code was tested on nohz=off and nohz kernels. It was tested on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was tested on single, dual, and octal cores system. It was tested on virtual hosts and bare hardware. No unwanted effects have been observed, and the problems that the patch intended to fix were indeed gone. Tested-by: Damien Wyart Signed-off-by: Vik Heyndrickx Signed-off-by: Peter Zijlstra (Intel) Cc: Cc: Doug Smythies Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 0f004f5a696a ("sched: Cure more NO_HZ load average woes") Link: http://lkml.kernel.org/r/e8d32bff-d544-7748-72b5-3c86cc71f09f@veribox.net Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit fa5c124f7dbee615a8e1fe7c1cb8f65a29040202 Author: Sasha Levin Date: Tue May 31 21:07:16 2016 -0400 rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring [ Upstream commit cf968937d27751296920e6b82ffa89735e3a0023 ] We can't use kfree_skb in irq disable context, because spin_lock_irqsave make sure we are always in irq disable context, use dev_kfree_skb_irq instead of kfree_skb is better than dev_kfree_skb_any. This patch fix below kernel warning: [ 7612.095528] ------------[ cut here ]------------ [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80() [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G W 4.4.0+ #4 [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015 [ 7612.095574] 00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454 [ 7612.095584] 00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400 [ 7612.095594] f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8 [ 7612.095604] Call Trace: [ 7612.095614] [] dump_stack+0x41/0x5c [ 7612.095620] [] warn_slowpath_common+0x89/0xc0 [ 7612.095628] [] ? __local_bh_enable_ip+0x58/0x80 [ 7612.095634] [] ? __local_bh_enable_ip+0x58/0x80 [ 7612.095640] [] warn_slowpath_null+0x1d/0x20 [ 7612.095646] [] __local_bh_enable_ip+0x58/0x80 [ 7612.095653] [] destroy_conntrack+0x64/0xa0 [ 7612.095660] [] nf_conntrack_destroy+0xf/0x20 [ 7612.095665] [] skb_release_head_state+0x55/0xa0 [ 7612.095670] [] skb_release_all+0xb/0x20 [ 7612.095674] [] __kfree_skb+0xb/0x60 [ 7612.095679] [] kfree_skb+0x30/0x70 [ 7612.095686] [] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci] [ 7612.095692] [] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci] [ 7612.095698] [] rtl_pci_start+0x19/0x190 [rtl_pci] [ 7612.095705] [] rtl_op_start+0x56/0x90 [rtlwifi] [ 7612.095712] [] drv_start+0x36/0xc0 [ 7612.095717] [] ieee80211_do_open+0x2d3/0x890 [ 7612.095725] [] ? call_netdevice_notifiers_info+0x2e/0x60 [ 7612.095730] [] ieee80211_open+0x4d/0x50 [ 7612.095736] [] __dev_open+0xa3/0x130 [ 7612.095742] [] ? _raw_spin_unlock_bh+0x13/0x20 [ 7612.095748] [] __dev_change_flags+0x89/0x140 [ 7612.095753] [] ? selinux_capable+0xd/0x10 [ 7612.095759] [] dev_change_flags+0x29/0x60 [ 7612.095765] [] devinet_ioctl+0x553/0x670 [ 7612.095772] [] ? _copy_to_user+0x28/0x40 [ 7612.095777] [] inet_ioctl+0x85/0xb0 [ 7612.095783] [] sock_ioctl+0x67/0x260 [ 7612.095788] [] ? sock_fasync+0x80/0x80 [ 7612.095795] [] do_vfs_ioctl+0x6b/0x550 [ 7612.095800] [] ? selinux_file_ioctl+0x102/0x1e0 [ 7612.095807] [] ? timekeeping_suspend+0x294/0x320 [ 7612.095813] [] ? __hrtimer_run_queues+0x14a/0x210 [ 7612.095820] [] ? security_file_ioctl+0x34/0x50 [ 7612.095827] [] SyS_ioctl+0x70/0x80 [ 7612.095832] [] do_fast_syscall_32+0x84/0x120 [ 7612.095839] [] sysenter_past_esp+0x36/0x55 [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]--- Signed-off-by: Wang YanQing Cc: Stable Acked-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 5de658d6f56a158f29baa789880732dbc4375e33 Author: Sasha Levin Date: Tue May 31 21:04:01 2016 -0400 rtlwifi: Fix logic error in enter/exit power-save mode [ Upstream commit 873ffe154ae074c46ed2d72dbd9a2a99f06f55b4 ] In commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue"), the tests for enter/exit power-save mode were inverted. With this change applied, the wifi connection becomes much more stable. Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue") Signed-off-by: Wang YanQing CC: Stable [3.10+] Acked-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 4cfbd2198055655a81aef121a6031867765fa64f Author: Arnd Bergmann Date: Tue May 10 23:30:01 2016 +0200 kbuild: move -Wunused-const-variable to W=1 warning level [ Upstream commit c9c6837d39311b0cc14cdbe7c18e815ab44aefb1 ] gcc-6 started warning by default about variables that are not used anywhere and that are marked 'const', generating many false positives in an allmodconfig build, e.g.: arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=] arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=] drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=] drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=] drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=] drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=] This is similar to the existing -Wunused-but-set-variable warning that was added in an earlier release and that we disable by default now and only enable when W=1 is set, so it makes sense to do the same here. Once we have eliminated the majority of the warnings for both, we can put them back into the default list. We probably want this in backport kernels as well, to allow building them with gcc-6 without introducing extra warnings. Signed-off-by: Arnd Bergmann Acked-by: Olof Johansson Acked-by: Lee Jones Cc: stable@vger.kernel.org Signed-off-by: Michal Marek Signed-off-by: Sasha Levin commit 10443b37022d55e8ff0c705f167b43855155ae81 Author: Marc Zyngier Date: Fri May 6 19:41:56 2016 +0100 irqchip/gic-v3: Configure all interrupts as non-secure Group-1 [ Upstream commit 7c9b973061b03af62734f613f6abec46c0dd4a88 ] The GICv3 driver wrongly assumes that it runs on the non-secure side of a secure-enabled system, while it could be on a system with a single security state, or a GICv3 with GICD_CTLR.DS set. Either way, it is important to configure this properly, or interrupts will simply not be delivered on this HW. Cc: stable@vger.kernel.org Reported-by: Peter Maydell Tested-by: Peter Maydell Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit bfc9ab721fdd1d0a9669cc979c52242c92c586d2 Author: Will Deacon Date: Tue Apr 26 12:00:00 2016 +0100 irqchip/gic: Ensure ordering between read of INTACK and shared data [ Upstream commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496 ] When an IPI is generated by a CPU, the pattern looks roughly like: smp_wmb(); On the receiving CPU we rely on the fact that, once we've taken the interrupt, then the freshly written shared data must be visible to us. Put another way, the CPU isn't going to speculate taking an interrupt. Unfortunately, this assumption turns out to be broken. Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy to read some shared_data. Before CPUx has done anything, a random peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised. CPUy then takes the IRQ and starts executing the entry code, heading towards gic_handle_irq. Furthermore, let's assume that a bunch of the previous interrupts handled by CPUy were SGIs, so the branch predictor kicks in and speculates that irqnr will be <16 and we're likely to head into handle_IPI. The prefetcher then grabs a speculative copy of shared_data which contains a stale value. Meanwhile, CPUx gets round to updating shared_data and asking the GIC to send an SGI to CPUy. Internally, the GIC decides that the SGI is more important than the peripheral interrupt (which hasn't yet been ACKed) but doesn't need to do anything to CPUy, because the IRQ line is already raised. CPUy then reads the ACK register on the GIC, sees the SGI value which confirms the branch prediction and we end up with a stale shared_data value. This patch fixes the problem by adding an smp_rmb() to the IPI entry code in gic_handle_irq. As it turns out, the combination of a control dependency and an ISB instruction from the EOI in the GICv3 driver is enough to provide the ordering we need, so we add a comment there justifying the absence of an explicit smp_rmb(). Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit ff0ee291ab639071bf868d904ec7f99de37480c5 Author: Arnd Bergmann Date: Mon Apr 25 17:35:30 2016 +0200 gcov: disable tree-loop-im to reduce stack usage [ Upstream commit c87bf431448b404a6ef5fbabd74c0e3e42157a7f ] 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 Cc: stable@vger.kernel.org Signed-off-by: Michal Marek Signed-off-by: Sasha Levin commit 456b98fed981449d4304b4a6bf0fbfd8ddc266e7 Author: James Hogan Date: Fri Apr 22 10:38:46 2016 +0100 MIPS: KVM: Fix timer IRQ race when writing CP0_Compare [ Upstream commit b45bacd2d048f405c7760e5cc9b60dd67708734f ] Writing CP0_Compare clears the timer interrupt pending bit (CP0_Cause.TI), but this wasn't being done atomically. If a timer interrupt raced with the write of the guest CP0_Compare, the timer interrupt could end up being pending even though the new CP0_Compare is nowhere near CP0_Count. We were already updating the hrtimer expiry with kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and kvm_mips_resume_hrtimer(). Close the race window by expanding out kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting CP0_Compare between the freeze and resume. Since the pending timer interrupt should not be cleared when CP0_Compare is written via the KVM user API, an ack argument is added to distinguish the source of the write. Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation") 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 Cc: # 3.16.x- Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 8106278c3064f730d8257f74498b1c18dbb66e93 Author: James Hogan Date: Fri Apr 22 10:38:45 2016 +0100 MIPS: KVM: Fix timer IRQ race when freezing timer [ Upstream commit 4355c44f063d3de4f072d796604c7f4ba4085cc3 ] There's a particularly narrow and subtle race condition when the software emulated guest timer is frozen which can allow a guest timer interrupt to be missed. This happens due to the hrtimer expiry being inexact, so very occasionally the freeze time will be after the moment when the emulated CP0_Count transitions to the same value as CP0_Compare (so an IRQ should be generated), but before the moment when the hrtimer is due to expire (so no IRQ is generated). The IRQ won't be generated when the timer is resumed either, since the resume CP0_Count will already match CP0_Compare. With VZ guests in particular this is far more likely to happen, since the soft timer may be frozen frequently in order to restore the timer state to the hardware guest timer. This happens after 5-10 hours of guest soak testing, resulting in an overflow in guest kernel timekeeping calculations, hanging the guest. A more focussed test case to intentionally hit the race (with the help of a new hypcall to cause the timer state to migrated between hardware & software) hits the condition fairly reliably within around 30 seconds. Instead of relying purely on the inexact hrtimer expiry to determine whether an IRQ should be generated, read the guest CP0_Compare and directly check whether the freeze time is before or after it. Only if CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to determine whether the last IRQ has already been generated (which will have pushed back the expiry by one timer period). Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation") 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 Cc: # 3.16.x- Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit ceee7b2f9dbb0c8ac05b00f2095662587c98f861 Author: Catalin Vasile Date: Fri May 6 16:18:53 2016 +0300 crypto: caam - fix caam_jr_alloc() ret code [ Upstream commit e930c765ca5c6b039cd22ebfb4504ea7b5dab43d ] caam_jr_alloc() used to return NULL if a JR device could not be allocated for a session. In turn, every user of this function used IS_ERR() function to verify if anything went wrong, which does NOT look for NULL values. This made the kernel crash if the sanity check failed, because the driver continued to think it had allocated a valid JR dev instance to the session and at some point it tries to do a caam_jr_free() on a NULL JR dev pointer. This patch is a fix for this issue. Cc: Signed-off-by: Catalin Vasile Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7124f5dfff7b22fd91546ce7dbf9e80b56f0d61f Author: Johan Hovold Date: Sun May 8 20:08:02 2016 +0200 USB: serial: quatech2: fix use-after-free in probe error path [ Upstream commit 028c49f5e02a257c94129cd815f7c8485f51d4ef ] The interface read URB is submitted in attach, but was only unlinked by the driver at disconnect. In case of a late probe error (e.g. due to failed minor allocation), disconnect is never called and we would end up with active URBs for an unbound interface. This in turn could lead to deallocated memory being dereferenced in the completion callback. Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Cc: stable # v3.5: 40d04738491d Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 17e958ca3f508c361325688ab1da7144febb35fe Author: Johan Hovold Date: Sun May 8 20:08:01 2016 +0200 USB: serial: mxuport: fix use-after-free in probe error path [ Upstream commit 9e45284984096314994777f27e1446dfbfd2f0d7 ] The interface read and event URBs are submitted in attach, but were never explicitly unlinked by the driver. Instead the URBs would have been killed by usb-serial core on disconnect. In case of a late probe error (e.g. due to failed minor allocation), disconnect is never called and we could end up with active URBs for an unbound interface. This in turn could lead to deallocated memory being dereferenced in the completion callbacks. Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX driver") Cc: stable # v3.14 Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d2e9eeb2504c73c09c415e5d4fc4cc33ffc4cb9f Author: Johan Hovold Date: Sun May 8 20:07:58 2016 +0200 USB: serial: keyspan: fix use-after-free in probe error path [ Upstream commit 35be1a71d70775e7bd7e45fa6d2897342ff4c9d2 ] The interface instat and indat URBs were submitted in attach, but never unlinked in release before deallocating the corresponding transfer buffers. In the case of a late probe error (e.g. due to failed minor allocation), disconnect would not have been called before release, causing the buffers to be freed while the URBs are still in use. We'd also end up with active URBs for an unbound interface. Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect, release") Cc: stable # v2.6.31 Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 90eb29f547e7de02d663257a3e8b042b80940925 Author: Johan Hovold Date: Sun May 8 20:07:57 2016 +0200 USB: serial: io_edgeport: fix memory leaks in probe error path [ Upstream commit c8d62957d450cc1a22ce3242908709fe367ddc8e ] URBs and buffers allocated in attach for Epic devices would never be deallocated in case of a later probe error (e.g. failure to allocate minor numbers) as disconnect is then never called. Fix by moving deallocation to release and making sure that the URBs are first unlinked. Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect, release") Cc: stable # v2.6.31 Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7bbc1379766b1887cd7b3c225c78acca5b82ec5e Author: Johan Hovold Date: Sun May 8 20:07:56 2016 +0200 USB: serial: io_edgeport: fix memory leaks in attach error path [ Upstream commit c5c0c55598cefc826d6cfb0a417eeaee3631715c ] Private data, URBs and buffers allocated for Epic devices during attach were never released on errors (e.g. missing endpoints). Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver") Cc: stable # v2.6.21 Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ec391566f8e498f5f3d92ff6c6abfdf6ac5a164b Author: Roger Quadros Date: Mon May 9 11:28:37 2016 +0300 mfd: omap-usb-tll: Fix scheduling while atomic BUG [ Upstream commit b49b927f16acee626c56a1af4ab4cb062f75b5df ] We shouldn't be calling clk_prepare_enable()/clk_prepare_disable() in an atomic context. Fixes the following issue: [ 5.830970] ehci-omap: OMAP-EHCI Host Controller driver [ 5.830974] driver_register 'ehci-omap' [ 5.895849] driver_register 'wl1271_sdio' [ 5.896870] BUG: scheduling while atomic: udevd/994/0x00000002 [ 5.896876] 4 locks held by udevd/994: [ 5.896904] #0: (&dev->mutex){......}, at: [] __driver_attach+0x60/0xac [ 5.896923] #1: (&dev->mutex){......}, at: [] __driver_attach+0x70/0xac [ 5.896946] #2: (tll_lock){+.+...}, at: [] omap_tll_enable+0x2c/0xd0 [ 5.896966] #3: (prepare_lock){+.+...}, at: [] clk_prepare_lock+0x48/0xe0 [ 5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine [ 5.897048] Preemption disabled at:[< (null)>] (null) [ 5.897051] [ 5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ #233 [ 5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.897076] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 5.897087] [] (show_stack) from [] (dump_stack+0x88/0xc0) [ 5.897099] [] (dump_stack) from [] (__schedule_bug+0xac/0xd0) [ 5.897111] [] (__schedule_bug) from [] (__schedule+0x88/0x7e4) [ 5.897120] [] (__schedule) from [] (schedule+0x9c/0xc0) [ 5.897129] [] (schedule) from [] (schedule_preempt_disabled+0x14/0x20) [ 5.897140] [] (schedule_preempt_disabled) from [] (mutex_lock_nested+0x258/0x43c) [ 5.897150] [] (mutex_lock_nested) from [] (clk_prepare_lock+0x48/0xe0) [ 5.897160] [] (clk_prepare_lock) from [] (clk_prepare+0x10/0x28) [ 5.897169] [] (clk_prepare) from [] (omap_tll_enable+0x64/0xd0) [ 5.897180] [] (omap_tll_enable) from [] (usbhs_runtime_resume+0x18/0x17c) [ 5.897192] [] (usbhs_runtime_resume) from [] (pm_generic_runtime_resume+0x2c/0x40) [ 5.897202] [] (pm_generic_runtime_resume) from [] (__rpm_callback+0x38/0x68) [ 5.897210] [] (__rpm_callback) from [] (rpm_callback+0x70/0x88) [ 5.897218] [] (rpm_callback) from [] (rpm_resume+0x4ec/0x7ec) [ 5.897227] [] (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) [ 5.897236] [] (__pm_runtime_resume) from [] (driver_probe_device+0x30/0x70) [ 5.897246] [] (driver_probe_device) from [] (__driver_attach+0x88/0xac) [ 5.897256] [] (__driver_attach) from [] (bus_for_each_dev+0x50/0x84) [ 5.897267] [] (bus_for_each_dev) from [] (bus_add_driver+0xcc/0x1e4) [ 5.897276] [] (bus_add_driver) from [] (driver_register+0xac/0xf4) [ 5.897286] [] (driver_register) from [] (do_one_initcall+0x100/0x1b8) [ 5.897296] [] (do_one_initcall) from [] (do_init_module+0x58/0x1c0) [ 5.897304] [] (do_init_module) from [] (SyS_finit_module+0x88/0x90) [ 5.897313] [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x1c) [ 5.912697] ------------[ cut here ]------------ [ 5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 _raw_spin_unlock+0x28/0x58 [ 5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count()) Cc: Reported-by: H. Nikolaus Schaller Tested-by: H. Nikolaus Schaller Signed-off-by: Roger Quadros Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 1187e91bc7a476df4c2d78baa257517c33bca5dc Author: Leonid Yegoshin Date: Tue Apr 28 12:53:35 2015 -0700 MIPS64: R6: R2 emulation bugfix [ Upstream commit 41fa29e4d8cf4150568a0fe9bb4d62229f9caed5 ] Error recovery pointers for fixups was improperly set as ".word" which is unsuitable for MIPS64. Replaced by STR(PTR) [ralf@linux-mips.org: Apply changes as requested in the review process.] Signed-off-by: Leonid Yegoshin Reviewed-by: James Hogan Reviewed-by: Markos Chandras Fixes: b0a668fb2038 ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for MIPS R6") Cc: macro@linux-mips.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: # 4.0+ Patchwork: https://patchwork.linux-mips.org/patch/9911/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit c2915ee9fcb019acacd50015e6f9dd01e878d966 Author: James Hogan Date: Fri Dec 4 22:25:02 2015 +0000 MIPS: Avoid using unwind_stack() with usermode [ Upstream commit 81a76d7119f63c359750e4adeff922a31ad1135f ] When showing backtraces in response to traps, for example crashes and address errors (usually unaligned accesses) when they are set in debugfs to be reported, unwind_stack will be used if the PC was in the kernel text address range. However since EVA it is possible for user and kernel address ranges to overlap, and even without EVA userland can still trigger an address error by jumping to a KSeg0 address. Adjust the check to also ensure that it was running in kernel mode. I don't believe any harm can come of this problem, since unwind_stack() is sufficiently defensive, however it is only meant for unwinding kernel code, so to be correct it should use the raw backtracing instead. Signed-off-by: James Hogan Reviewed-by: Leonid Yegoshin Cc: linux-mips@linux-mips.org Cc: # 3.15+ Patchwork: https://patchwork.linux-mips.org/patch/11701/ Signed-off-by: Ralf Baechle (cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9) Signed-off-by: Sasha Levin commit dd95033f7d938a3c8521bb0f4abeeee032fb35a1 Author: James Hogan Date: Fri Dec 4 22:25:01 2015 +0000 MIPS: Don't unwind to user mode with EVA [ Upstream commit a816b306c62195b7c43c92cb13330821a96bdc27 ] When unwinding through IRQs and exceptions, the unwinding only continues if the PC is a kernel text address, however since EVA it is possible for user and kernel address ranges to overlap, potentially allowing unwinding to continue to user mode if the user PC happens to be in the kernel text address range. Adjust the check to also ensure that the register state from before the exception is actually running in kernel mode, i.e. !user_mode(regs). I don't believe any harm can come of this problem, since the PC is only output, the stack pointer is checked to ensure it resides within the task's stack page before it is dereferenced in search of the return address, and the return address register is similarly only output (if the PC is in a leaf function or the beginning of a non-leaf function). However unwind_stack() is only meant for unwinding kernel code, so to be correct the unwind should stop there. Signed-off-by: James Hogan Reviewed-by: Leonid Yegoshin Cc: linux-mips@linux-mips.org Cc: # 3.15+ Patchwork: https://patchwork.linux-mips.org/patch/11700/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 22a4a25999d813d6256077de45f859411b766cd9 Author: James Hogan Date: Mon Feb 8 18:43:49 2016 +0000 MIPS: Fix siginfo.h to use strict posix types [ Upstream commit 5daebc477da4dfeb31ae193d83084def58fd2697 ] Commit 85efde6f4e0d ("make exported headers use strict posix types") changed the asm-generic siginfo.h to use the __kernel_* types, and commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal types accessible only to the kernel, but the MIPS implementation hasn't been updated to match. Switch to proper types now so that the exported asm/siginfo.h won't produce quite so many compiler errors when included alone by a user program. Signed-off-by: James Hogan Cc: Christopher Ferris Cc: linux-mips@linux-mips.org Cc: # 2.6.30- Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12477/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 5b59ae1ed02bc606b5c32e4ce3f5afd6691cafb4 Author: Oliver Hartkopp Date: Mon Mar 21 20:18:21 2016 +0100 can: fix handling of unmodifiable configuration options [ Upstream commit bb208f144cf3f59d8f89a09a80efd04389718907 ] As described in 'can: m_can: tag current CAN FD controllers as non-ISO' (6cfda7fbebe) it is possible to define fixed configuration options by setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'. This leads to the incovenience that the fixed configuration bits can not be passed by netlink even when they have the correct values (e.g. non-ISO, FD). This patch fixes that issue and not only allows fixed set bit values to be set again but now requires(!) to provide these fixed values at configuration time. A valid CAN FD configuration consists of a nominal/arbitration bittiming, a data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now enforced by a new can_validate() function. This fix additionally removed the inconsistency that was prohibiting the support of 'CANFD-only' controller drivers, like the RCar CAN FD. For this reason a new helper can_set_static_ctrlmode() has been introduced to provide a proper interface to handle static enabled CAN controller options. Reported-by: Ramesh Shanmugasundaram Signed-off-by: Oliver Hartkopp Reviewed-by: Ramesh Shanmugasundaram Cc: # >= 3.18 Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 0839058ab07fde8fb6edbebcc4046dd3b49a951f Author: Catalin Marinas Date: Thu May 5 10:44:02 2016 +0100 arm64: Ensure pmd_present() returns false after pmd_mknotpresent() [ Upstream commit 5bb1cc0ff9a6b68871970737e6c4c16919928d8b ] Currently, pmd_present() only checks for a non-zero value, returning true even after pmd_mknotpresent() (which only clears the type bits). This patch converts pmd_present() to using pte_present(), similar to the other pmd_*() checks. As a side effect, it will return true for PROT_NONE mappings, though they are not yet used by the kernel with transparent huge pages. For consistency, also change pmd_mknotpresent() to only clear the PMD_SECT_VALID bit, even though the PMD_TABLE_BIT is already 0 for block mappings (no functional change). The unused PMD_SECT_PROT_NONE definition is removed as transparent huge pages use the pte page prot values. Fixes: 9c7e535fcc17 ("arm64: mm: Route pmd thp functions through pte equivalents") Cc: # 3.15+ Reviewed-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 7346b8742de4bd56008f26cf36a1d59a0534f430 Author: Nicolai Stange Date: Thu May 5 19:46:19 2016 -0400 ext4: silence UBSAN in ext4_mb_init() [ Upstream commit 935244cd54b86ca46e69bc6604d2adfb1aec2d42 ] Currently, in ext4_mb_init(), there's a loop like the following: do { ... offset += 1 << (sb->s_blocksize_bits - i); i++; } while (i <= sb->s_blocksize_bits + 1); Note that the updated offset is used in the loop's next iteration only. However, at the last iteration, that is at i == sb->s_blocksize_bits + 1, the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3)) and UBSAN reports UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15 shift exponent 4294967295 is too large for 32-bit type 'int' [...] Call Trace: [] dump_stack+0xbc/0x117 [] ? _atomic_dec_and_lock+0x169/0x169 [] ubsan_epilogue+0xd/0x4e [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [] ? __ubsan_handle_load_invalid_value+0x158/0x158 [] ? kmem_cache_alloc+0x101/0x390 [] ? ext4_mb_init+0x13b/0xfd0 [] ? create_cache+0x57/0x1f0 [] ? create_cache+0x11a/0x1f0 [] ? mutex_lock+0x38/0x60 [] ? mutex_unlock+0x1b/0x50 [] ? put_online_mems+0x5b/0xc0 [] ? kmem_cache_create+0x117/0x2c0 [] ext4_mb_init+0xc49/0xfd0 [...] Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1. Unless compilers start to do some fancy transformations (which at least GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the such calculated value of offset is never used again. Silence UBSAN by introducing another variable, offset_incr, holding the next increment to apply to offset and adjust that one by right shifting it by one position per loop iteration. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161 Cc: stable@vger.kernel.org Signed-off-by: Nicolai Stange Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 76caa7178c24de91cdb2ed0033650c623ad580e3 Author: Nicolai Stange Date: Thu May 5 17:38:03 2016 -0400 ext4: address UBSAN warning in mb_find_order_for_block() [ Upstream commit b5cb316cdf3a3f5f6125412b0f6065185240cfdc ] Currently, in mb_find_order_for_block(), there's a loop like the following: while (order <= e4b->bd_blkbits + 1) { ... bb += 1 << (e4b->bd_blkbits - order); } Note that the updated bb is used in the loop's next iteration only. However, at the last iteration, that is at order == e4b->bd_blkbits + 1, the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11 shift exponent -1 is negative [...] Call Trace: [] dump_stack+0xbc/0x117 [] ? _atomic_dec_and_lock+0x169/0x169 [] ubsan_epilogue+0xd/0x4e [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [] ? __ubsan_handle_load_invalid_value+0x158/0x158 [] ? ext4_mb_generate_from_pa+0x590/0x590 [] ? ext4_read_block_bitmap_nowait+0x598/0xe80 [] mb_find_order_for_block+0x1ce/0x240 [...] Unless compilers start to do some fancy transformations (which at least GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the such calculated value of bb is never used again. Silence UBSAN by introducing another variable, bb_incr, holding the next increment to apply to bb and adjust that one by right shifting it by one position per loop iteration. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161 Cc: stable@vger.kernel.org Signed-off-by: Nicolai Stange Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit f245ed015ed94730b9a9fea17029d7d79fa88dd7 Author: Jan Kara Date: Thu May 5 11:10:15 2016 -0400 ext4: fix oops on corrupted filesystem [ Upstream commit 74177f55b70e2f2be770dd28684dd6d17106a4ba ] When filesystem is corrupted in the right way, it can happen ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we subsequently remove inode from the in-memory orphan list. However this deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we leave i_orphan list_head with a stale content. Later we can look at this content causing list corruption, oops, or other issues. The reported trace looked like: WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100() list_del corruption, 0000000061c1d6e0->next is LIST_POISON1 0000000000100100) CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250 Stack: 60462947 62219960 602ede24 62219960 602ede24 603ca293 622198f0 602f02eb 62219950 6002c12c 62219900 601b4d6b Call Trace: [<6005769c>] ? vprintk_emit+0x2dc/0x5c0 [<602ede24>] ? printk+0x0/0x94 [<600190bc>] show_stack+0xdc/0x1a0 [<602ede24>] ? printk+0x0/0x94 [<602ede24>] ? printk+0x0/0x94 [<602f02eb>] dump_stack+0x2a/0x2c [<6002c12c>] warn_slowpath_common+0x9c/0xf0 [<601b4d6b>] ? __list_del_entry+0x6b/0x100 [<6002c254>] warn_slowpath_fmt+0x94/0xa0 [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0 [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0 [<60023ebf>] ? set_signals+0x3f/0x50 [<600a205a>] ? kmem_cache_free+0x10a/0x180 [<602f4e88>] ? mutex_lock+0x18/0x30 [<601b4d6b>] __list_del_entry+0x6b/0x100 [<601177ec>] ext4_orphan_del+0x22c/0x2f0 [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0 [<6010b973>] ? ext4_truncate+0x383/0x390 [<6010bc8b>] ext4_write_begin+0x30b/0x4b0 [<6001bb50>] ? copy_from_user+0x0/0xb0 [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0 [<60072c4f>] generic_perform_write+0xaf/0x1e0 [<600c4166>] ? file_update_time+0x46/0x110 [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0 [<6010030f>] ext4_file_write_iter+0x15f/0x470 [<60094e10>] ? unlink_file_vma+0x0/0x70 [<6009b180>] ? unlink_anon_vmas+0x0/0x260 [<6008f169>] ? free_pgtables+0xb9/0x100 [<600a6030>] __vfs_write+0xb0/0x130 [<600a61d5>] vfs_write+0xa5/0x170 [<600a63d6>] SyS_write+0x56/0xe0 [<6029fcb0>] ? __libc_waitpid+0x0/0xa0 [<6001b698>] handle_syscall+0x68/0x90 [<6002633d>] userspace+0x4fd/0x600 [<6002274f>] ? save_registers+0x1f/0x40 [<60028bd7>] ? arch_prctl+0x177/0x1b0 [<60017bd5>] fork_handler+0x85/0x90 Fix the problem by using list_del_init() as we always should with i_orphan list. CC: stable@vger.kernel.org Reported-by: Vegard Nossum Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e4e5983477fd480a044bbaef62a4c53529879b2e Author: Konstantin Shkolnyy Date: Wed May 4 16:56:52 2016 -0500 USB: serial: cp210x: fix hardware flow-control disable [ Upstream commit a377f9e906af4df9071ba8ddba60188cb4013d93 ] 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") Cc: stable [johan: reword commit message ] Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit f26c00e60f4ddac7cf972f2752d50094b0d60ff7 Author: Konstantin Shkolnyy Date: Wed Oct 28 16:02:34 2015 -0500 USB: cp210x: relocate private data from USB interface to port [ Upstream commit e2ae67a3b55188b0342522d8139acf013feb2a69 ] This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 18a6470484918d01746712ce33e5fbbd1373edff Author: Lv Zheng Date: Tue May 3 16:48:20 2016 +0800 ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings [ Upstream commit 30c9bb0d7603e7b3f4d6a0ea231e1cddae020c32 ] The order of the _OSI related functionalities is as follows: acpi_blacklisted() acpi_dmi_osi_linux() acpi_osi_setup() acpi_osi_setup() acpi_update_interfaces() if "!*" <<<<<<<<<<<<<<<<<<<<<<<< parse_args() __setup("acpi_osi=") acpi_osi_setup_linux() acpi_update_interfaces() if "!*" <<<<<<<<<<<<<<<<<<<<<<<< acpi_early_init() acpi_initialize_subsystem() acpi_ut_initialize_interfaces() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ acpi_bus_init() acpi_os_initialize1() acpi_install_interface_handler(acpi_osi_handler) acpi_osi_setup_late() acpi_update_interfaces() for "!" >>>>>>>>>>>>>>>>>>>>>>>> acpi_osi_handler() Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command line setting can override the DMI detection. That's why acpi_blacklisted() is put before __setup("acpi_osi="). Then we can notice the following wrong invocation order. There are acpi_update_interfaces() (marked by <<<<) calls invoked before acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible to use acpi_osi=!* correctly from OSI DMI table or from the command line. The use of acpi_osi=!* is meant to disable both ACPICA (acpi_gbl_supported_interfaces) and Linux specific strings (osi_setup_entries) while the ACPICA part should have stopped working because of the order issue. This patch fixes this issue by moving acpi_update_interfaces() to where it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux specific strings are still handled in the original place in order to make the following command line working: acpi_osi=!* acpi_osi="Module Device". Note that since acpi_osi=!* is meant to further disable linux specific string comparing to the acpi_osi=!, there is no such use case in our bug fixing work and hence there is no one using acpi_osi=!* either from the command line or from the DMI quirks, this issue is just a theoretical issue. Fixes: 741d81280ad2 (ACPI: Add facility to remove all _OSI strings) Cc: 3.12+ # 3.12+ Tested-by: Lukas Wunner Tested-by: Chen Yu Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4d5aaca6145b49ef9fe82dfa6db61a90e83ba912 Author: Lei Liu Date: Wed May 4 16:34:22 2016 +0800 USB: serial: option: add even more ZTE device ids [ Upstream commit 74d2a91aec97ab832790c9398d320413ad185321 ] Add even more ZTE device ids. Signed-off-by: lei liu Cc: stable [johan: rebase and replace commit message ] Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit feb498621fc35eb2d8e4929a466abf38c7c60543 Author: lei liu Date: Tue May 3 14:44:19 2016 -0700 USB: serial: option: add more ZTE device ids [ Upstream commit f0d09463c59c2d764a6c6d492cbe6d2c77f27153 ] More ZTE device ids. Signed-off-by: lei liu Cc: stable [properly sort them - gregkh] Signed-off-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 39a8fc74ecc0eaea82f2e32a35f93d584b3de615 Author: Andreas Werner Date: Tue May 3 12:42:00 2016 +0200 mcb: Fixed bar number assignment for the gdd [ Upstream commit f75564d343010b025301d9548f2304f48eb25f01 ] The bar number is found in reg2 within the gdd. Therefore we need to change the assigment from reg1 to reg2 which is the correct location. Signed-off-by: Andreas Werner Fixes: '3764e82e5' drivers: Introduce MEN Chameleon Bus Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Johannes Thumshirn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 27094468938ac9cc4a0b87ed7d5899bd8717e73b Author: Mathias Nyman Date: Mon May 2 11:39:03 2016 +0300 usb: misc: usbtest: fix pattern tests for scatterlists. [ Upstream commit cdc77c82a8286b1181b81b6e5ef60c8e83ded7bc ] The current implemenentation restart the sent pattern for each entry in the sg list. The receiving end expects a continuous pattern, and test will fail unless scatterilst entries happen to be aligned with the pattern Fix this by calculating the pattern byte based on total sent size instead of just the current sg entry. Signed-off-by: Mathias Nyman Fixes: 8b5249019352 ("[PATCH] USB: usbtest: scatterlist OUT data pattern testing") Cc: # v2.6.18+ Acked-by: Felipe Balbi Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cf2f44ddb7bb3deaee324cc549300484946b19c7 Author: Alan Stern Date: Tue Sep 1 09:48:01 2015 +0800 usb: misc: usbtest: format the data pattern according to max packet size [ Upstream commit b9a6e8e1001e28fecbd74c073f5503dac2790563 ] With this change, the host and gadget doesn't need to agree with transfer length for comparing the data, since they doesn't know each other's transfer size, but know max packet size. Signed-off-by: Peter Chen Acked-by: Michal Nazarewicz (Fixed the 'line over 80 characters warning' by Peter Chen) Tested-by: Peter Chen Signed-off-by: Alan Stern Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit d0270cd8487a8cfef918e2a9cd7b6348a4c74618 Author: Alan Stern Date: Fri Apr 29 15:25:17 2016 -0400 USB: leave LPM alone if possible when binding/unbinding interface drivers [ Upstream commit 6fb650d43da3e7054984dc548eaa88765a94d49f ] When a USB driver is bound to an interface (either through probing or by claiming it) or is unbound from an interface, the USB core always disables Link Power Management during the transition and then re-enables it afterward. The reason is because the driver might want to prevent hub-initiated link power transitions, in which case the HCD would have to recalculate the various LPM parameters. This recalculation takes place when LPM is re-enabled and the new parameters are sent to the device and its parent hub. However, if the driver does not want to prevent hub-initiated link power transitions then none of this work is necessary. The parameters don't need to be recalculated, and LPM doesn't need to be disabled and re-enabled. It turns out that disabling and enabling LPM can be time-consuming, enough so that it interferes with user programs that want to claim and release interfaces rapidly via usbfs. Since the usbfs kernel driver doesn't set the disable_hub_initiated_lpm flag, we can speed things up and get the user programs to work by leaving LPM alone whenever the flag isn't set. And while we're improving the way disable_hub_initiated_lpm gets used, let's also fix its kerneldoc. Signed-off-by: Alan Stern Tested-by: Matthew Giassa CC: Mathias Nyman CC: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 38f005d9fe711b883f9d836c3ee67b4c1275bd9a Author: Schemmel Hans-Christoph Date: Fri Apr 29 08:51:06 2016 +0000 USB: serial: option: add support for Cinterion PH8 and AHxx [ Upstream commit 444f94e9e625f6ec6bbe2cb232a6451c637f35a3 ] Added support for Gemalto's Cinterion PH8 and AHxx products with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface. In addition some minor renaming and formatting. Signed-off-by: Hans-Christoph Schemmel [johan: sort current entries and trim trailing whitespace ] Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 1dab35a8a62e5e7c49bf89b844b6efbdebdd34c1 Author: Andreas Noever Date: Sun Apr 10 12:48:27 2016 +0200 thunderbolt: Fix double free of drom buffer [ Upstream commit 2ffa9a5d76a75abbc1f95c17959fced666095bdd ] If tb_drom_read() fails, sw->drom is freed but not set to NULL. sw->drom is then freed again in the error path of tb_switch_alloc(). The bug can be triggered by unplugging a thunderbolt device shortly after it is detected by the thunderbolt driver. Clear sw->drom if tb_drom_read() fails. [bhelgaas: add Fixes:, stable versions of interest] Fixes: 343fcb8c70d7 ("thunderbolt: Fix nontrivial endpoint devices.") Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.17+ CC: Lukas Wunner Signed-off-by: Sasha Levin commit 4efcad5278a3a11312b3b2c9afa3d4bed60b318f Author: Zhao Qiang Date: Wed Mar 9 09:48:11 2016 +0800 QE-UART: add "fsl,t1040-ucc-uart" to of_device_id [ Upstream commit 11ca2b7ab432eb90906168c327733575e68d388f ] New bindings use "fsl,t1040-ucc-uart" as the compatible for qe-uart. So add it. Signed-off-by: Zhao Qiang Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 29a7543e33dbb168c1e044a3ad411ce96286924b Author: Brian Bloniarz Date: Sun Mar 6 13:16:30 2016 -0800 Fix OpenSSH pty regression on close [ Upstream commit 0f40fbbcc34e093255a2b2d70b6b0fb48c3f39aa ] OpenSSH expects the (non-blocking) read() of pty master to return EAGAIN only if it has received all of the slave-side output after it has received SIGCHLD. This used to work on pre-3.12 kernels. This fix effectively forces non-blocking read() and poll() to block for parallel i/o to complete for all ttys. It also unwinds these changes: 1) f8747d4a466ab2cafe56112c51b3379f9fdb7a12 tty: Fix pty master read() after slave closes 2) 52bce7f8d4fc633c9a9d0646eef58ba6ae9a3b73 pty, n_tty: Simplify input processing on final close 3) 1a48632ffed61352a7810ce089dc5a8bcd505a60 pty: Fix input race when closing Inspired by analysis and patch from Marc Aurele La France Reported-by: Volth Reported-by: Marc Aurele La France BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52 BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492 Signed-off-by: Brian Bloniarz Reviewed-by: Peter Hurley Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d46be34398ab85c4d80ce2747eeef71497d8a01e Author: Matthias Schiffer Date: Thu Mar 24 16:02:52 2016 +0100 MIPS: ath79: make bootconsole wait for both THRE and TEMT [ Upstream commit f5b556c94c8490d42fea79d7b4ae0ecbc291e69d ] This makes the ath79 bootconsole behave the same way as the generic 8250 bootconsole. Also waiting for TEMT (transmit buffer is empty) instead of just THRE (transmit buffer is not full) ensures that all characters have been transmitted before the real serial driver starts reconfiguring the serial controller (which would sometimes result in garbage being transmitted.) This change does not cause a visible performance loss. In addition, this seems to fix a hang observed in certain configurations on many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver. A more complete follow-up patch will disable 8250 autoconfig for ath79 altogether (the serial controller is detected as a 16550A, which is not fully compatible with the ath79 serial, and the autoconfig may lead to undefined behavior on ath79.) Cc: Signed-off-by: Matthias Schiffer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e0934da7eb12fe444a9b9225a9f2c9281d3e2b8a Author: Theodore Ts'o Date: Sat Apr 30 00:49:54 2016 -0400 ext4: clean up error handling when orphan list is corrupted [ Upstream commit 7827a7f6ebfcb7f388dc47fddd48567a314701ba ] Instead of just printing warning messages, if the orphan list is corrupted, declare the file system is corrupted. If there are any reserved inodes in the orphaned inode list, declare the file system corrupted and stop right away to avoid doing more potential damage to the file system. Cc: stable@vger.kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 06c6dcb86328d114709b2f464ce9c6f015acad70 Author: Theodore Ts'o Date: Sat Apr 30 00:48:54 2016 -0400 ext4: fix hang when processing corrupted orphaned inode list [ Upstream commit c9eb13a9105e2e418f72e46a2b6da3f49e696902 ] If the orphaned inode list contains inode #5, ext4_iget() returns a bad inode (since the bootloader inode should never be referenced directly). Because of the bad inode, we end up processing the inode repeatedly and this hangs the machine. This can be reproduced via: mke2fs -t ext4 /tmp/foo.img 100 debugfs -w -R "ssv last_orphan 5" /tmp/foo.img mount -o loop /tmp/foo.img /mnt (But don't do this if you are using an unpatched kernel if you care about the system staying functional. :-) This bug was found by the port of American Fuzzy Lop into the kernel to find file system problems[1]. (Since it *only* happens if inode #5 shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not surprising that AFL needed two hours before it found it.) [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf Cc: stable@vger.kernel.org Reported by: Vegard Nossum Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit bb3412ec3763dd295615e164c1ae898df670bf99 Author: Raghava Aditya Renukunta Date: Mon Apr 25 23:32:37 2016 -0700 aacraid: Fix for KDUMP driver hang [ Upstream commit 78cbccd3bd683c295a44af8050797dc4a41376ff ] When KDUMP is triggered the driver first talks to the firmware in INTX mode, but the adapter firmware is still in MSIX mode. Therefore the first driver command hangs since the driver is waiting for an INTX response and firmware gives a MSIX response. If when the OS is installed on a RAID drive created by the adapter KDUMP will hang since the driver does not receive a response in sync mode. Fixed by: Change the firmware to INTX mode if it is in MSIX mode before sending the first sync command. Cc: stable@vger.kernel.org Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ca7bb254849946e13eaf3adf23e1220cb863bca9 Author: Raghava Aditya Renukunta Date: Mon Apr 25 23:31:57 2016 -0700 aacraid: Fix for aac_command_thread hang [ Upstream commit fc4bf75ea300a5e62a2419f89dd0e22189dd7ab7 ] Typically under error conditions, it is possible for aac_command_thread() to miss the wakeup from kthread_stop() and go back to sleep, causing it to hang aac_shutdown. In the observed scenario, the adapter is not functioning correctly and so aac_fib_send() never completes (or time-outs depending on how it was called). Shortly after aac_command_thread() starts it performs aac_fib_send(SendHostTime) which hangs. When aac_probe_one /aac_get_adapter_info send time outs, kthread_stop is called which breaks the command thread out of it's hang. The code will still go back to sleep in schedule_timeout() without checking kthread_should_stop() so it causes aac_probe_one to hang until the schedule_timeout() which is 30 minutes. Fixed by: Adding another kthread_should_stop() before schedule_timeout() Cc: stable@vger.kernel.org Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e452f7382f5715d7d8b1d5f1129ded8870eaed5e Author: Raghava Aditya Renukunta Date: Mon Apr 25 23:31:26 2016 -0700 aacraid: Relinquish CPU during timeout wait [ Upstream commit 07beca2be24cc710461c0b131832524c9ee08910 ] aac_fib_send has a special function case for initial commands during driver initialization using wait < 0(pseudo sync mode). In this case, the command does not sleep but rather spins checking for timeout.This loop is calls cpu_relax() in an attempt to allow other processes/threads to use the CPU, but this function does not relinquish the CPU and so the command will hog the processor. This was observed in a KDUMP "crashkernel" and that prevented the "command thread" (which is responsible for completing the command from being timed out) from starting because it could not get the CPU. Fixed by replacing "cpu_relax()" call with "schedule()" Cc: stable@vger.kernel.org Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 660cd2235c5ac7a4d3aa5c3370b63124fb50cf81 Author: Marc Zyngier Date: Thu Apr 28 16:16:31 2016 +0100 arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables [ Upstream commit d4b9e0790aa764c0b01e18d4e8d33e93ba36d51f ] The ARM architecture mandates that when changing a page table entry from a valid entry to another valid entry, an invalid entry is first written, TLB invalidated, and only then the new entry being written. The current code doesn't respect this, directly writing the new entry and only then invalidating TLBs. Let's fix it up. Cc: Reported-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Sasha Levin commit 788da6ee7dc349b45047212f7dbce31e3fdc82b0 Author: H Hartley Sweeten Date: Fri Apr 8 10:14:58 2016 -0700 staging: comedi: das1800: fix possible NULL dereference [ Upstream commit d375278d666760e195693b57415ba0a125cadd55 ] DMA is optional with this driver. If it was not enabled the devpriv->dma pointer will be NULL. Fix the possible NULL pointer dereference when trying to disable the DMA channels in das1800_ai_cancel() and tidy up the comments to fix the checkpatch.pl issues: WARNING: line over 80 characters It's probably harmless in das1800_ai_setup_dma() because the 'desc' pointer will not be used if DMA is disabled but fix it there also. Fixes: 99dfc3357e98 ("staging: comedi: das1800: remove depends on ISA_DMA_API limitation") Cc: # 4.0+ Signed-off-by: H Hartley Sweeten Reviewed-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 14023eff33a9a587f6d5ca65d8298802ffeae811 Author: Jiri Slaby Date: Tue Mar 22 18:09:51 2016 +0100 TTY: n_gsm, fix false positive WARN_ON [ Upstream commit d175feca89a1c162f60f4e3560ca7bc9437c65eb ] Dmitry reported, that the current cleanup code in n_gsm can trigger a warning: WARNING: CPU: 2 PID: 24238 at drivers/tty/n_gsm.c:2048 gsm_cleanup_mux+0x166/0x6b0() ... Call Trace: ... [] warn_slowpath_null+0x29/0x30 kernel/panic.c:490 [] gsm_cleanup_mux+0x166/0x6b0 drivers/tty/n_gsm.c:2048 [] gsmld_open+0x5b7/0x7a0 drivers/tty/n_gsm.c:2386 [] tty_ldisc_open.isra.2+0x78/0xd0 drivers/tty/tty_ldisc.c:447 [] tty_set_ldisc+0x1ca/0xa70 drivers/tty/tty_ldisc.c:567 [< inline >] tiocsetd drivers/tty/tty_io.c:2650 [] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2883 ... But this is a legal path when open fails to find a space in the gsm_mux array and tries to clean up. So make it a standard test instead of a warning. Reported-by: "Dmitry Vyukov" Cc: Alan Cox Link: http://lkml.kernel.org/r/CACT4Y+bHQbAB68VFi7Romcs-Z9ZW3kQRvcq+BvHH1oa5NcAdLA@mail.gmail.com Fixes: 5a640967 ("tty/n_gsm.c: fix a memory leak in gsmld_open()") Cc: stable Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c91d8c2d38843168a5b58bdc6b809495f5f31863 Author: David Müller Date: Wed Apr 27 11:58:32 2016 +0200 serial: 8250_pci: fix divide error bug if baud rate is 0 [ Upstream commit 6f210c18c1c0f016772c8cd51ae12a02bfb9e7ef ] Since commit 21947ba654a6 ("serial: 8250_pci: replace switch-case by formula"), the 8250 driver crashes in the byt_set_termios() function with a divide error. This is caused by the fact that a baud rate of 0 (B0) is not handled properly. Fix it by falling back to B9600 in this case. Signed-off-by: David Müller Fixes: 21947ba654a6 ("serial: 8250_pci: replace switch-case by formula") Cc: stable@vger.kernel.org Suggested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3afbd3e3a9a95054c0a2a4bb14cf07aaf0c8cde7 Author: Chris Bainbridge Date: Mon Apr 25 13:48:38 2016 +0100 usb: core: hub: hub_port_init lock controller instead of bus [ Upstream commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 ] The XHCI controller presents two USB buses to the system - one for USB2 and one for USB3. The hub init code (hub_port_init) is reentrant but only locks one bus per thread, leading to a race condition failure when two threads attempt to simultaneously initialise a USB2 and USB3 device: [ 8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command [ 13.183701] usb 3-3: device descriptor read/all, error -110 On a test system this failure occurred on 6% of all boots. The call traces at the point of failure are: Call Trace: [] schedule+0x37/0x90 [] usb_kill_urb+0x8d/0xd0 [] ? wake_up_atomic_t+0x30/0x30 [] usb_start_wait_urb+0xbe/0x150 [] usb_control_msg+0xbc/0xf0 [] hub_port_init+0x51e/0xb70 [] hub_event+0x817/0x1570 [] process_one_work+0x1ff/0x620 [] ? process_one_work+0x15f/0x620 [] worker_thread+0x64/0x4b0 [] ? rescuer_thread+0x390/0x390 [] kthread+0x105/0x120 [] ? kthread_create_on_node+0x200/0x200 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x200/0x200 Call Trace: [] xhci_setup_device+0x53d/0xa40 [] xhci_address_device+0xe/0x10 [] hub_port_init+0x1bf/0xb70 [] ? trace_hardirqs_on+0xd/0x10 [] hub_event+0x817/0x1570 [] process_one_work+0x1ff/0x620 [] ? process_one_work+0x15f/0x620 [] worker_thread+0x64/0x4b0 [] ? rescuer_thread+0x390/0x390 [] kthread+0x105/0x120 [] ? kthread_create_on_node+0x200/0x200 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x200/0x200 Which results from the two call chains: hub_port_init usb_get_device_descriptor usb_get_descriptor usb_control_msg usb_internal_control_msg usb_start_wait_urb usb_submit_urb / wait_for_completion_timeout / usb_kill_urb hub_port_init hub_set_address xhci_address_device xhci_setup_device Mathias Nyman explains the current behaviour violates the XHCI spec: hub_port_reset() will end up moving the corresponding xhci device slot to default state. As hub_port_reset() is called several times in hub_port_init() it sounds reasonable that we could end up with two threads having their xhci device slots in default state at the same time, which according to xhci 4.5.3 specs still is a big no no: "Note: Software shall not transition more than one Device Slot to the Default State at a time" So both threads fail at their next task after this. One fails to read the descriptor, and the other fails addressing the device. Fix this in hub_port_init by locking the USB controller (instead of an individual bus) to prevent simultaneous initialisation of both buses. Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Link: https://lkml.org/lkml/2016/2/8/312 Link: https://lkml.org/lkml/2016/2/4/748 Signed-off-by: Chris Bainbridge Cc: stable Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7ac47d24c2c58732650b40e87c616b2778c985a3 Author: Luke Dashjr Date: Thu Oct 29 08:22:21 2015 +0000 btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl [ Upstream commit 4c63c2454eff996c5e27991221106eb511f7db38 ] 32-bit ioctl uses these rather than the regular FS_IOC_* versions. They can be handled in btrfs using the same code. Without this, 32-bit {ch,ls}attr fail. Signed-off-by: Luke Dashjr Cc: stable@vger.kernel.org Reviewed-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 93ddb49f922bc625f6abe56169bca3d642befc16 Author: Andrew Jeffery Date: Wed Apr 20 11:24:17 2016 +0930 pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range [ Upstream commit 71324fdc72ef0163e57631aa814a9a81e9e4770b ] The range is registered into a linked list which can be referenced throughout the lifetime of the driver. Ensure the range's memory is useful for the same lifetime by adding it to the driver's private data structure. The bug was introduced in the driver's initial commit, which was present in v3.10. Fixes: f0b9a7e521fa ("pinctrl: exynos5440: add pinctrl driver for Samsung EXYNOS5440 SoC") Cc: stable@vger.kernel.org Signed-off-by: Andrew Jeffery Acked-by: Tomasz Figa Reviewed-by: Krzysztof Kozlowski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit a774710f2d27a61ad7cfd0b449e6708e03d70c7d Author: Vittorio Gambaletta (VittGam) Date: Mon Apr 11 04:48:55 2016 +0200 ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. [ Upstream commit 0f9edcdd88a993914fa1d1dc369b35dc503979db ] The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity (active high instead of active low). The same PCI Subsystem ID is used by both cards, which are based on the same Atheros MB92 design. Cc: Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit d24f503d5c01eb3f33a2dde74b6893c7ec2816ad Author: Vittorio Gambaletta (VittGam) Date: Mon Apr 11 04:48:54 2016 +0200 ath9k: Add a module parameter to invert LED polarity. [ Upstream commit cd84042ce9040ad038e958bc67a46fcfc015c736 ] The LED can be active high instead of active low on some hardware. Add the led_active_high module parameter. It defaults to -1 to obey platform data as before. Setting the parameter to 1 or 0 will force the LED respectively active high or active low. Cc: Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 6be9e6ec17c65c289f5bb0afabe977d2d748b4c2 Author: Krzysztof Kozlowski Date: Fri Apr 22 14:15:23 2016 +0200 crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks [ Upstream commit 79152e8d085fd64484afd473ef6830b45518acba ] The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on testing 8 kB size blocks: $ sudo modprobe tcrypt sec=1 mode=500 testing speed of async ecb(aes) (ecb-aes-s5p) encryption test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes) test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes) test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes) test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes) test 4 (128 bit key, 8192 byte blocks): This was caused by a race issue of missed BRDMA_DONE ("Block cipher Receiving DMA") interrupt. Device starts processing the data in DMA mode immediately after setting length of DMA block: receiving (FCBRDMAL) or transmitting (FCBTDMAL). The driver sets these lengths from interrupt handler through s5p_set_dma_indata() function (or xxx_setdata()). However the interrupt handler was first dealing with receive buffer (dma-unmap old, dma-map new, set receive block length which starts the operation), then with transmit buffer and finally was clearing pending interrupts (FCINTPEND). Because of the time window between setting receive buffer length and clearing pending interrupts, the operation on receive buffer could end already and driver would miss new interrupt. User manual for Exynos5422 confirms in example code that setting DMA block lengths should be the last operation. The tcrypt hang could be also observed in following blocked-task dmesg: INFO: task modprobe:258 blocked for more than 120 seconds. Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D c06b09d8 0 258 256 0x00000000 [] (__schedule) from [] (schedule+0x40/0xac) [] (schedule) from [] (schedule_timeout+0x124/0x178) [] (schedule_timeout) from [] (wait_for_common+0xb8/0x144) [] (wait_for_common) from [] (test_acipher_speed+0x49c/0x740 [tcrypt]) [] (test_acipher_speed [tcrypt]) from [] (do_test+0x2240/0x30ec [tcrypt]) [] (do_test [tcrypt]) from [] (tcrypt_mod_init+0x48/0xa4 [tcrypt]) [] (tcrypt_mod_init [tcrypt]) from [] (do_one_initcall+0x3c/0x16c) [] (do_one_initcall) from [] (do_init_module+0x5c/0x1ac) [] (do_init_module) from [] (load_module+0x1a30/0x1d08) [] (load_module) from [] (SyS_finit_module+0x8c/0x98) [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x3c) Fixes: a49e490c7a8a ("crypto: s5p-sss - add S5PV210 advanced crypto engine support") Cc: Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cc706ae1a874eab7f5bc6a09286c95a5ca75b59c Author: Krzysztof Kozlowski Date: Tue Apr 19 15:44:12 2016 +0200 crypto: s5p-sss - Remove useless hash interrupt handler [ Upstream commit 5512442553bbe8d4fcdba3e17b30f187706384a7 ] Beside regular feed control interrupt, the driver requires also hash interrupt for older SoCs (samsung,s5pv210-secss). However after requesting it, the interrupt handler isn't doing anything with it, not even clearing the hash interrupt bit. Driver does not provide hash functions so it is safe to remove the hash interrupt related code and to not require the interrupt in Device Tree. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit dae205d180835de781ef49edd47c46e31b43e1e4 Author: Ulf Hansson Date: Fri Apr 8 13:10:23 2016 +0200 PM / Runtime: Fix error path in pm_runtime_force_resume() [ Upstream commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f ] As pm_runtime_set_active() may fail because the device's parent isn't active, we can end up executing the ->runtime_resume() callback for the device when it isn't allowed. Fix this by invoking pm_runtime_set_active() before running the callback and let's also deal with the error code. Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions) Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Cc: 3.15+ # 3.15+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b9a5eef06ce1e717f119ed5312216b6dfd80c935 Author: Hari Bathini Date: Fri Apr 15 22:48:02 2016 +1000 powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel [ Upstream commit 8ed8ab40047a570fdd8043a40c104a57248dd3fd ] Some of the interrupt vectors on 64-bit POWER server processors are only 32 bytes long (8 instructions), which is not enough for the full first-level interrupt handler. For these we need to branch to an out-of-line (OOL) handler. But when we are running a relocatable kernel, interrupt vectors till __end_interrupts marker are copied down to real address 0x100. So, branching to labels (ie. OOL handlers) outside this section must be handled differently (see LOAD_HANDLER()), considering relocatable kernel, which would need at least 4 instructions. However, branching from interrupt vector means that we corrupt the CFAR (come-from address register) on POWER7 and later processors as mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions) that contains the part up to the point where the CFAR is saved in the PACA should be part of the short interrupt vectors before we branch out to OOL handlers. But as mentioned already, there are interrupt vectors on 64-bit POWER server processors that are only 32 bytes long (like vectors 0x4f00, 0x4f20, etc.), which cannot accomodate the above two cases at the same time owing to space constraint. Currently, in these interrupt vectors, we simply branch out to OOL handlers, without using LOAD_HANDLER(), which leaves us vulnerable when running a relocatable kernel (eg. kdump case). While this has been the case for sometime now and kdump is used widely, we were fortunate not to see any problems so far, for three reasons: 1. In almost all cases, production kernel (relocatable) is used for kdump as well, which would mean that crashed kernel's OOL handler would be at the same place where we end up branching to, from short interrupt vector of kdump kernel. 2. Also, OOL handler was unlikely the reason for crash in almost all the kdump scenarios, which meant we had a sane OOL handler from crashed kernel that we branched to. 3. On most 64-bit POWER server processors, page size is large enough that marking interrupt vector code as executable (see commit 429d2e83) leads to marking OOL handler code from crashed kernel, that sits right below interrupt vector code from kdump kernel, as executable as well. Let us fix this by moving the __end_interrupts marker down past OOL handlers to make sure that we also copy OOL handlers to real address 0x100 when running a relocatable kernel. This fix has been tested successfully in kdump scenario, on an LPAR with 4K page size by using different default/production kernel and kdump kernel. Also tested by manually corrupting the OOL handlers in the first kernel and then kdump'ing, and then causing the OOL handlers to fire - mpe. Fixes: c1fb6816fb1b ("powerpc: Add relocation on exception vector handlers") Cc: stable@vger.kernel.org Signed-off-by: Hari Bathini Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 599a6fc37a01f5b77f9ebf6e03f70375e4d236b4 Author: Takashi Iwai Date: Thu Apr 14 17:32:19 2016 +0200 Bluetooth: vhci: Fix race at creating hci device [ Upstream commit c7c999cb18da88a881e10e07f0724ad0bfaff770 ] hci_vhci driver creates a hci device object dynamically upon each HCI_VENDOR_PKT write. Although it checks the already created object and returns an error, it's still racy and may build multiple hci_dev objects concurrently when parallel writes are performed, as the device tracks only a single hci_dev object. This patch introduces a mutex to protect against the concurrent device creations. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit ef83ef608320a02f1fa84e5e77743038ee134e54 Author: Akshay Bhat Date: Mon Apr 18 15:47:53 2016 -0400 hwmon: (ads7828) Enable internal reference [ Upstream commit 7a18afe8097731b8ffb6cb5b2b3b418ded77c105 ] On ads7828 the internal reference defaults to off upon power up. When using internal reference, it needs to be turned on and the voltage needs to settle before normal conversion cycle can be started. Hence perform a dummy read in the probe to enable the internal reference allowing the voltage to settle before performing a normal read. Without this fix, the first read from the ADC when using internal reference always returns incorrect data. Signed-off-by: Akshay Bhat Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f5a300ce8c288f470af4cfdcc16294515cb61753 Author: Michal Nazarewicz Date: Fri Apr 8 10:24:11 2016 +0200 usb: f_mass_storage: test whether thread is running before starting another [ Upstream commit f78bbcae86e676fad9e6c6bb6cd9d9868ba23696 ] When binding the function to usb_configuration, check whether the thread is running before starting another one. Without that, when function instance is added to multiple configurations, fsg_bing starts multiple threads with all but the latest one being forgotten by the driver. This leads to obvious thread leaks, possible lockups when trying to halt the machine and possible more issues. This fixes issues with legacy/multi¹ gadget as well as configfs gadgets when mass_storage function is added to multiple configurations. This change also simplifies API since the legacy gadgets no longer need to worry about starting the thread by themselves (which was where bug in legacy/multi was in the first place). N.B., this patch doesn’t address adding single mass_storage function instance to a single configuration twice. Thankfully, there’s no legitimate reason for such setup plus, if I’m not mistaken, configfs gadget doesn’t even allow it to be expressed. ¹ I have no example failure though. Conclusion that legacy/multi has a bug is based purely on me reading the code. Acked-by: Alan Stern Signed-off-by: Michal Nazarewicz Tested-by: Ivaylo Dimitrov Cc: Alan Stern Cc: Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 799f55d219e12c930eb248dbb5403adf4dc78edc Author: Krzysztof Opasiak Date: Fri Jul 31 13:46:07 2015 +0200 usb: gadget: mass_storage: Use static array for luns [ Upstream commit dd02ea5a33059e4a753ae8bb877b698c54ee2907 ] This patch replace dynamicly allocated luns array with static one. This simplifies the code of mass storage function and modules. Signed-off-by: Krzysztof Opasiak Acked-by: Michal Nazarewicz Signed-off-by: Sasha Levin commit a27b3984f7fdea785e67195f6de3d06c4835e325 Author: Krzysztof Opasiak Date: Fri Jul 31 13:37:45 2015 +0200 usb: gadget: mass_storage: Fix freeing luns sysfs implementation [ Upstream commit 5542f58c95aef67bc9016855f7c0bd6117b43100 ] Use device_is_registered() instad of sysfs flag to determine if we should free sysfs representation of particular LUN. sysfs flag in fsg common determines if luns attributes should be exposed using sysfs. This flag is used when creating and freeing luns. Unfortunately there is no guarantee that this flag will not be changed between creation and removal of particular LUN. Especially because of lun.0 which is created during allocating instance of function. This may lead to resource leak or NULL pointer dereference: [ 62.539925] Unable to handle kernel NULL pointer dereference at virtual address 00000044 [ 62.548014] pgd = ec994000 [ 62.550679] [00000044] *pgd=6d7be831, *pte=00000000, *ppte=00000000 [ 62.556933] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 62.562310] Modules linked in: g_mass_storage(+) [ 62.566916] CPU: 2 PID: 613 Comm: insmod Not tainted 4.2.0-rc4-00077-ge29ee91-dirty #125 [ 62.574984] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 62.581061] task: eca56e80 ti: eca76000 task.ti: eca76000 [ 62.586450] PC is at kernfs_find_ns+0x8/0xe8 [ 62.590698] LR is at kernfs_find_and_get_ns+0x30/0x48 [ 62.595732] pc : [] lr : [] psr: 40010053 [ 62.595732] sp : eca77c40 ip : eca77c38 fp : 000008c1 [ 62.607187] r10: 00000001 r9 : c0082f38 r8 : ed41ce40 [ 62.612395] r7 : c05c1484 r6 : 00000000 r5 : 00000000 r4 : c0814488 [ 62.618904] r3 : 00000000 r2 : 00000000 r1 : c05c1484 r0 : 00000000 [ 62.625417] Flags: nZcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment user [ 62.632620] Control: 10c5387d Table: 6c99404a DAC: 00000015 [ 62.638348] Process insmod (pid: 613, stack limit = 0xeca76210) [ 62.644251] Stack: (0xeca77c40 to 0xeca78000) [ 62.648594] 7c40: c0814488 00000000 00000000 c05c1484 ed41ce40 c0127b88 00000000 c0824888 [ 62.656753] 7c60: ed41d038 ed41d030 ed41d000 c012af4c 00000000 c0824858 ed41d038 c02e3314 [ 62.664912] 7c80: ed41d030 00000000 ed41ce04 c02d9e8c c070eda8 eca77cb4 000008c1 c058317c [ 62.673071] 7ca0: 000008c1 ed41d030 ed41ce00 ed41ce04 ed41d000 c02da044 ed41cf48 c0375870 [ 62.681230] 7cc0: ed9d3c04 ed9d3c00 ed52df80 bf000940 fffffff0 c03758f4 c03758c0 00000000 [ 62.689389] 7ce0: bf000564 c03614e0 ed9d3c04 bf000194 c0082f38 00000001 00000000 c0000100 [ 62.697548] 7d00: c0814488 c0814488 c086b1dc c05893a8 00000000 ed7e8320 00000000 c0128b88 [ 62.705707] 7d20: ed8a6b40 00000000 00000000 ed410500 ed8a6b40 c0594818 ed7e8320 00000000 [ 62.713867] 7d40: 00000000 c0129f20 00000000 c082c444 ed8a6b40 c012a684 00001000 00000000 [ 62.722026] 7d60: c0594818 c082c444 00000000 00000000 ed52df80 ed52df80 00000000 00000000 [ 62.730185] 7d80: 00000000 00000000 00000001 00000002 ed8e9b70 ed52df80 bf0006d0 00000000 [ 62.738345] 7da0: ed8e9b70 ed410500 ed618340 c036129c ed8c1c00 bf0006d0 c080b158 ed8c1c00 [ 62.746504] 7dc0: bf0006d0 c080b158 ed8c1c08 ed410500 c0082f38 ed618340 000008c1 c03640ac [ 62.754663] 7de0: 00000000 bf0006d0 c082c8dc c080b158 c080b158 c03642d4 00000000 bf003000 [ 62.762822] 7e00: 00000000 c0009784 00000000 00000001 00000000 c05849b0 00000002 ee7ab780 [ 62.770981] 7e20: 00000002 ed4105c0 0000c53e 000000d0 c0808600 eca77e5c 00000004 00000000 [ 62.779140] 7e40: bf000000 c0095680 c08075a0 ee001f00 ed4105c0 c00cadc0 ed52df80 bf000780 [ 62.787300] 7e60: ed4105c0 bf000780 00000001 bf0007c8 c0082f38 ed618340 000008c1 c0083e24 [ 62.795459] 7e80: 00000001 bf000780 00000001 eca77f58 00000001 bf000780 00000001 c00857f4 [ 62.803618] 7ea0: bf00078c 00007fff 00000000 c00835b4 eca77f58 00000000 c0082fac eca77f58 [ 62.811777] 7ec0: f05038c0 0003b008 bf000904 00000000 00000000 bf00078c 6e72656b 00006c65 [ 62.819936] 7ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 62.828095] 7f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 62.836255] 7f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000003 0003b008 [ 62.844414] 7f40: 0000017b c000f5c8 eca76000 00000000 0003b008 c0085df8 f04ef000 0001b8a9 [ 62.852573] 7f60: f0503258 f05030c2 f0509fe8 00000968 00000dc8 00000000 00000000 00000000 [ 62.860732] 7f80: 00000029 0000002a 00000011 00000000 0000000a 00000000 33f6eb00 0003b008 [ 62.868892] 7fa0: bef01cac c000f400 33f6eb00 0003b008 00000003 0003b008 00000000 00000003 [ 62.877051] 7fc0: 33f6eb00 0003b008 bef01cac 0000017b 00000000 0003b008 0000000b 0003b008 [ 62.885210] 7fe0: bef01ae0 bef01ad0 0001dc23 b6e8c162 800b0070 00000003 c0c0c0c0 c0c0c0c0 [ 62.893380] [] (kernfs_find_ns) from [] (pm_qos_latency_tolerance_attr_group+0x0/0x10) [ 62.903005] Code: e28dd00c e8bd80f0 e92d41f0 e2923000 (e1d0e4b4) [ 62.909115] ---[ end trace 02fb4373ef095c7b ]--- Acked-by: Michal Nazarewicz Signed-off-by: Krzysztof Opasiak Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit c387f28f6f54fc8bd5d9c05d9c4b35cc0910d207 Author: Krzysztof Opasiak Date: Mon Jul 20 20:15:17 2015 +0200 usb: gadget: mass_storage: Free buffers if create lun fails [ Upstream commit 903588a99c26ed6f103eaa0cfa4ccbe9cd779398 ] Creation of LUN 0 may fail (for example due to ENOMEM). As fsg_common_set_num_buffers() does some memory allocation we should free it before it becomes unavailable. Signed-off-by: Krzysztof Opasiak Acked-by: Michal Nazarewicz Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 5b1e48946e2d73a1b332ca84c2d7aba2136911e2 Author: Tiffany Lin Date: Mon Mar 14 08:16:14 2016 -0300 [media] media: v4l2-compat-ioctl32: fix missing reserved field copy in put_v4l2_create32 [ Upstream commit baf43c6eace43868e490f18560287fa3481b2159 ] In v4l2-compliance utility, test VIDIOC_CREATE_BUFS will check whether reserved filed of v4l2_create_buffers filled with zero Reserved field is filled with zero in v4l_create_bufs. This patch copy reserved field of v4l2_create_buffer from kernel space to user space Signed-off-by: Tiffany Lin Signed-off-by: Hans Verkuil Cc: # for v3.19 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 633b243bb2fcc9546f87123598130831c406e629 Author: Andy Shevchenko Date: Fri Oct 23 12:16:42 2015 +0300 mfd: intel_quark_i2c_gpio: load gpio driver first [ Upstream commit c39dc960e9c5196022cbc46507d4782b6fc314f6 ] On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it is able to generate interrupt, but interrupt line is connected to GPIO. That's why we have to have GPIO driver in place when we will probe i2c host with device connected to it. Acked-by: Lee Jones Signed-off-by: Andy Shevchenko Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 16de798078e646c2f668c8d03be79dfdd53db3a1 Author: Dave Gerlach Date: Tue Apr 5 14:05:38 2016 -0500 cpuidle: Indicate when a device has been unregistered [ Upstream commit c998c07836f985b24361629dc98506ec7893e7a0 ] Currently the 'registered' member of the cpuidle_device struct is set to 1 during cpuidle_register_device. In this same function there are checks to see if the device is already registered to prevent duplicate calls to register the device, but this value is never set to 0 even on unregister of the device. Because of this, any attempt to call cpuidle_register_device after a call to cpuidle_unregister_device will fail which shouldn't be the case. To prevent this, set registered to 0 when the device is unregistered. Fixes: c878a52d3c7c (cpuidle: Check if device is already registered) Signed-off-by: Dave Gerlach Acked-by: Daniel Lezcano Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b2df540f5e80e7d8106fe3e8113f22bc359ed15c Author: Jiri Slaby Date: Sat Mar 19 11:49:43 2016 +0100 Bluetooth: vhci: purge unhandled skbs [ Upstream commit 13407376b255325fa817798800117a839f3aa055 ] The write handler allocates skbs and queues them into data->readq. Read side should read them, if there is any. If there is none, skbs should be dropped by hdev->flush. But this happens only if the device is HCI_UP, i.e. hdev->power_on work was triggered already. When it was not, skbs stay allocated in the queue when /dev/vhci is closed. So purge the queue in ->release. Program to reproduce: #include #include #include #include #include #include #include int main() { char buf[] = { 0xff, 0 }; struct iovec iov = { .iov_base = buf, .iov_len = sizeof(buf), }; int fd; while (1) { fd = open("/dev/vhci", O_RDWR); if (fd < 0) err(1, "open"); usleep(50); if (writev(fd, &iov, 1) < 0) err(1, "writev"); usleep(50); close(fd); } return 0; } Result: kmemleak: 4609 new suspected memory leaks unreferenced object 0xffff88059f4d5440 (size 232): comm "vhci", pid 1084, jiffies 4294912542 (age 37569.296s) hex dump (first 32 bytes): 20 f0 23 87 05 88 ff ff 20 f0 23 87 05 88 ff ff .#..... .#..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: ... [] __alloc_skb+0x0/0x5a0 [] vhci_create_device+0x5c/0x580 [hci_vhci] [] vhci_write+0x306/0x4c8 [hci_vhci] Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers) Signed-off-by: Jiri Slaby Signed-off-by: Marcel Holtmann Cc: stable 3.13+ Signed-off-by: Sasha Levin commit 497519c4a3bf22c5d7fa2e6da6424e07e6ac543c Author: Jiri Slaby Date: Sat Mar 19 11:05:18 2016 +0100 Bluetooth: vhci: fix open_timeout vs. hdev race [ Upstream commit 373a32c848ae3a1c03618517cce85f9211a6facf ] Both vhci_get_user and vhci_release race with open_timeout work. They both contain cancel_delayed_work_sync, but do not test whether the work actually created hdev or not. Since the work can be in progress and _sync will wait for finishing it, we can have data->hdev allocated when cancel_delayed_work_sync returns. But the call sites do 'if (data->hdev)' *before* cancel_delayed_work_sync. As a result: * vhci_get_user allocates a second hdev and puts it into data->hdev. The former is leaked. * vhci_release does not release data->hdev properly as it thinks there is none. Fix both cases by moving the actual test *after* the call to cancel_delayed_work_sync. This can be hit by this program: #include #include #include #include #include #include #include #include int main(int argc, char **argv) { int fd; srand(time(NULL)); while (1) { const int delta = (rand() % 200 - 100) * 100; fd = open("/dev/vhci", O_RDWR); if (fd < 0) err(1, "open"); usleep(1000000 + delta); close(fd); } return 0; } And the result is: BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228 Read of size 8 by task kworker/u13:1/32068 ============================================================================= BUG kmalloc-192 (Tainted: G E ): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040 ... kmem_cache_alloc_trace+0x150/0x190 vhci_open+0x50/0x330 [hci_vhci] misc_open+0x35b/0x4e0 chrdev_open+0x23b/0x510 ... INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040 ... __slab_free+0x204/0x310 vhci_release+0xa4/0xd0 [hci_vhci] ... INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080 INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600 Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00 ...k............ Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff ...k.......k.... Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff .F.k.....F.k.... Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00 ................ Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff @..k....@..k.... Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de P.n............. Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00 .........b...... Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff ........8..k.... Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00 .. ............. Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff ...........=.... Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . .............. Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb ........ Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00 ........ CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G B E 4.4.6-0-default #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014 Workqueue: hci0 hci_cmd_work [bluetooth] 00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180 ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320 ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80 Call Trace: ... [] ? skb_queue_tail+0x13e/0x150 [] ? vhci_send_frame+0xac/0x100 [hci_vhci] [] ? hci_send_frame+0x188/0x320 [bluetooth] [] ? hci_cmd_work+0x115/0x310 [bluetooth] [] ? process_one_work+0x815/0x1340 [] ? worker_thread+0xe5/0x11f0 [] ? process_one_work+0x1340/0x1340 [] ? kthread+0x1c8/0x230 ... Memory state around the buggy address: ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers) Signed-off-by: Jiri Slaby Signed-off-by: Marcel Holtmann Cc: Dmitry Vyukov Cc: stable 3.13+ Signed-off-by: Sasha Levin commit dde143909bd9e295cf6c89c3e7606f15fcc693a4 Author: Itai Handler Date: Tue Nov 3 00:20:56 2015 +0200 drm/gma500: Fix possible out of bounds read [ Upstream commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 ] Fix possible out of bounds read, by adding missing comma. The code may read pass the end of the dsi_errors array when the most significant bit (bit #31) in the intr_stat register is set. This bug has been detected using CppCheck (static analysis tool). Cc: stable@vger.kernel.org Signed-off-by: Itai Handler Signed-off-by: Patrik Jakobsson Signed-off-by: Sasha Levin commit f448f47758d1e23385fd0846dc27015330908f0d Author: Larry Finger Date: Wed Mar 16 13:33:35 2016 -0500 rtlwifi: btcoexist: Implement antenna selection [ Upstream commit baa1702290953295e421f0f433e2b1ff4815827c ] The previous patch added an option to rtl8723be to manually select the antenna for those cases when only a single antenna is present, and the on-board EEPROM is incorrectly programmed. This patch implements the necessary changes in the Bluetooth coexistence driver. Signed-off-by: Larry Finger Cc: Stable [V4.0+] Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 7138f9840bea22badaeea76433957f8d88596554 Author: Larry Finger Date: Wed Mar 16 13:33:34 2016 -0500 rtlwifi: rtl8723be: Add antenna select module parameter [ Upstream commit c18d8f5095715c56bb3cd9cba64242542632054b ] A number of new laptops have been delivered with only a single antenna. In principle, this is OK; however, a problem arises when the on-board EEPROM is programmed to use the other antenna connection. The option of opening the computer and moving the connector is not always possible as it will void the warranty in some cases. In addition, this solution breaks the Windows driver when the box dual boots Linux and Windows. A fix involving a new module parameter has been developed. This commit adds the new parameter and implements the changes needed for the driver. Signed-off-by: Larry Finger Cc: Stable [V4.0+] Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit db4ec7cf24d08d9da4d17fd78294cb8e7f0574d6 Author: Sasha Levin Date: Mon May 30 18:24:55 2016 -0400 rtlwifi: rtl8723be: Fix module parameter initialization [ Upstream commit 7079604ddb83f428359feace3aeaf8a9f435be4a ] This driver has a number of errors in the module initialization. These include the following: Parameter msi_support is stored in two places - one is removed. Paramters sw_crypto and disable_watchdog were never stored in the final locations, nor were they initialized properly. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit e8663801545a5e1059da85b5210a9a23939f3a82 Author: Darrick J. Wong Date: Mon Jan 4 16:13:21 2016 +1100 libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct [ Upstream commit 96f859d52bcb1c6ea6f3388d39862bf7143e2f30 ] Because struct xfs_agfl is 36 bytes long and has a 64-bit integer inside it, gcc will quietly round the structure size up to the nearest 64 bits -- in this case, 40 bytes. This results in the XFS_AGFL_SIZE macro returning incorrect results for v5 filesystems on 64-bit machines (118 items instead of 119). As a result, a 32-bit xfs_repair will see garbage in AGFL item 119 and complain. Therefore, tell gcc not to pad the structure so that the AGFL size calculation is correct. cc: # 3.10 - 4.4 Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 1fe949f6d0036130e1c62d2e5bee01d9b4ef0e51 Author: Dave Chinner Date: Wed Apr 6 07:06:20 2016 +1000 xfs: Don't wrap growfs AGFL indexes [ Upstream commit ad747e3b299671e1a53db74963cc6c5f6cdb9f6d ] Commit 96f859d ("libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct") allowed the freelist to use the empty slot at the end of the freelist on 64 bit systems that was not being used due to sizeof() rounding up the structure size. This has caused versions of xfs_repair prior to 4.5.0 (which also has the fix) to report this as a corruption once the filesystem has been grown. Older kernels can also have problems (seen from a whacky container/vm management environment) mounting filesystems grown on a system with a newer kernel than the vm/container it is deployed on. To avoid this problem, change the initial free list indexes not to wrap across the end of the AGFL, hence avoiding the initialisation of agf_fllast to the last index in the AGFL. cc: # 4.4-4.5 Signed-off-by: Dave Chinner Reviewed-by: Carlos Maiolino Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 9c153a82fb6f9a177d0ec2034005b4245973a28f Author: Eric Sandeen Date: Wed Apr 6 07:05:41 2016 +1000 xfs: disallow rw remount on fs with unknown ro-compat features [ Upstream commit d0a58e833931234c44e515b5b8bede32bd4e6eed ] Today, a kernel which refuses to mount a filesystem read-write due to unknown ro-compat features can still transition to read-write via the remount path. The old kernel is most likely none the wiser, because it's unaware of the new feature, and isn't using it. However, writing to the filesystem may well corrupt metadata related to that new feature, and moving to a newer kernel which understand the feature will have problems. Right now the only ro-compat feature we have is the free inode btree, which showed up in v3.16. It would be good to push this back to all the active stable kernels, I think, so that if anyone is using newer mkfs (which enables the finobt feature) with older kernel releases, they'll be protected. Cc: # 3.10.x- Signed-off-by: Eric Sandeen Reviewed-by: Bill O'Donnell Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 67b8cea5cc2222a2c7397161ea58b656793956e2 Author: Joseph Salisbury Date: Mon Mar 14 14:51:48 2016 -0400 ath5k: Change led pin configuration for compaq c700 laptop [ Upstream commit 7b9bc799a445aea95f64f15e0083cb19b5789abe ] BugLink: http://bugs.launchpad.net/bugs/972604 Commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin configuration for compaq c700 laptop") added a pin configuration for the Compaq c700 laptop. However, the polarity of the led pin is reversed. It should be red for wifi off and blue for wifi on, but it is the opposite. This bug was reported in the following bug report: http://pad.lv/972604 Fixes: 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin configuration for compaq c700 laptop") Signed-off-by: Joseph Salisbury Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit db9c6316bb5a33c02bba78b23101e917b012e399 Author: Javier Martinez Canillas Date: Wed Mar 23 20:59:34 2016 -0300 regulator: Try to resolve regulators supplies on registration [ Upstream commit 5e3ca2b349b1e2c80b060b51bbf2af37448fad85 ] Commit 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") moved the regulator supplies lookup logic from the regulators registration to the regulators get time. Unfortunately, that changed the behavior of the regulator core since now a parent supply with a child regulator marked as always-on, won't be enabled unless a client driver attempts to get the child regulator during boot. This patch tries to resolve the parent supply for the already registered regulators each time that a new regulator is registered. So the regulators that have child regulators marked as always on will be enabled regardless if a driver gets the child regulator or not. That was the behavior before the mentioned commit, since parent supplies were looked up at regulator registration time instead of during child get. Since regulator_resolve_supply() checks for rdev->supply, most of the times it will be a no-op. Errors aren't checked to keep the possible out of order dependencies which was the motivation for the mentioned commit. Also, the supply being available will be enforced on regulator get anyways in case the resolve fails on regulators registration. Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") Suggested-by: Mark Brown Signed-off-by: Javier Martinez Canillas Signed-off-by: Mark Brown Cc: # 4.1+ Signed-off-by: Sasha Levin commit 28c94eff0f24045ff56867196a8a564cc4c5419a Author: Mark Brown Date: Mon Aug 10 19:43:47 2015 +0100 regulator: core: Use class device list for regulator_list in late init [ Upstream commit 609ca5f3cb32c2d11fd8cabe293ff3689e7d2613 ] The regulator_list has exactly the same contents as the list that the driver core maintains of regulator_class members so is redundant. As a first step in converting over to use the class device list convert our iteration in late_initcall() to use the class device iterator. Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3dec2ae8b610b459b1e37591149c4065ad343978 Author: Anilkumar Kolli Date: Fri Mar 11 11:46:39 2016 +0530 ath10k: fix debugfs pktlog_filter write [ Upstream commit 9ddc486aa09a3413a6c492fcf160ce61bfccb7b1 ] It is observed that, we are disabling the packet log if we write same value to the pktlog_filter for the second time. Always enable pktlogs on non zero filter. Fixes: 90174455ae05 ("ath10k: add support to configure pktlog filter") Cc: stable@vger.kernel.org Signed-off-by: Anilkumar Kolli Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 861c13e117c6c7a21e0a38ea18d68a1fa9d661eb Author: Rajkumar Manoharan Date: Wed Mar 2 20:13:52 2016 +0530 ath10k: fix firmware assert in monitor mode [ Upstream commit 8a75fc54745fd3ce9062ab1cc6429a9da9ac2a68 ] commit 166de3f1895d ("ath10k: remove supported chain mask") had revealed an issue on monitor mode. Configuring NSS upon monitor interface creation is causing target assert in all qca9888x and qca6174 firmware. Firmware assert issue can be reproduced by below sequence even after reverting commit 166de3f1895d ("ath10k: remove supported chain mask"). ip link set wlan0 down iw wlan0 set type monitor iw phy0 set antenna 7 ip link set wlan0 up This issue is originally reported on qca9888 with 10.1 firmware. Fixes: 5572a95b4b ("ath10k: apply chainmask settings to vdev on creation") Cc: stable@vger.kernel.org Reported-by: Janusz Dziedzic Signed-off-by: Rajkumar Manoharan Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 9a243f2469d31682394673bfe37954789ba50176 Author: Sasha Levin Date: Mon May 30 17:50:36 2016 -0400 perf/x86/intel/pt: Generate PMI in the STOP region as well [ Upstream commit ab92b232ae05c382c3df0e3d6a5c6d16b639ac8c ] Currently, the PT driver always sets the PMI bit one region (page) before the STOP region so that we can wake up the consumer before we run out of room in the buffer and have to disable the event. However, we also need an interrupt in the last output region, so that we actually get to disable the event (if no more room from new data is available at that point), otherwise hardware just quietly refuses to start, but the event is scheduled in and we end up losing trace data till the event gets removed. For a cpu-wide event it is even worse since there may not be any re-scheduling at all and no chance for the ring buffer code to notice that its buffer is filled up and the event needs to be disabled (so that the consumer can re-enable it when it finishes reading the data out). In other words, all the trace data will be lost after the buffer gets filled up. This patch makes PT also generate a PMI when the last output region is full. Reported-by: Markus Metzger Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: vince@deater.net Link: http://lkml.kernel.org/r/1462886313-13660-2-git-send-email-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin