commit bed4c611a3b80fae04d75b9f85fcaf174bac1b06 Author: Greg Kroah-Hartman Date: Wed Jul 27 08:42:34 2016 -0700 Linux 4.6.5 commit 429cc19dbdce4568f4d3f0da06596c1d4d559f24 Author: Vivek Goyal Date: Fri Jul 1 10:02:44 2016 -0400 ovl: warn instead of error if d_type is not supported commit e7c0b5991dd1be7b6f6dc2b54a15a0f47b64b007 upstream. overlay needs underlying fs to support d_type. Recently I put in a patch in to detect this condition and started failing mount if underlying fs did not support d_type. But this breaks existing configurations over kernel upgrade. Those who are running docker (partially broken configuration) with xfs not supporting d_type, are surprised that after kernel upgrade docker does not run anymore. https://github.com/docker/docker/issues/22937#issuecomment-229881315 So instead of erroring out, detect broken configuration and warn about it. This should allow existing docker setups to continue working after kernel upgrade. Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi Fixes: 45aebeaf4f67 ("ovl: Ensure upper filesystem supports d_type") Signed-off-by: Greg Kroah-Hartman commit 1cc1665689afab53364915003a945779589356b8 Author: Vivek Goyal Date: Fri May 20 09:04:26 2016 -0400 ovl: Do d_type check only if work dir creation was successful commit 21765194cecf2e4514ad75244df459f188140a0f upstream. d_type check requires successful creation of workdir as iterates through work dir and expects work dir to be present in it. If that's not the case, this check will always return d_type not supported even if underlying filesystem might be supporting it. So don't do this check if work dir creation failed in previous step. Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit b0f7095f8bd503eddf9a91a258e796da0058f182 Author: Mika Kahola Date: Mon Jun 20 11:10:26 2016 +0300 drm/i915: Revert DisplayPort fast link training feature commit 34511dce4b35685d3988d5c8b100d11a068db5bd upstream. It has been found out that in some HW combination the DisplayPort fast link training feature caused screen flickering. Let's revert this feature for now until we can ensure that the feature works for all platforms. This is a manual revert of commits 5fa836a9d859 ("drm/i915: DP link training optimization") and 4e96c97742f4 ("drm/i915: eDP link training optimization"). Fixes: 5fa836a9d859 ("drm/i915: DP link training optimization") Fixes: 4e96c97742f4 ("drm/i915: eDP link training optimization") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393 Reviewed-by: Jani Nikula Signed-off-by: Mika Kahola Signed-off-by: Jani Nikula Link: http://patchwork.freedesktop.org/patch/msgid/1466410226-19543-1-git-send-email-mika.kahola@intel.com (cherry picked from commit 91df09d92ad82c8778ca218097bf827f154292ca) Signed-off-by: Joakim Tjernlund Signed-off-by: Greg Kroah-Hartman commit baa4a006a9bc179bfe678aca4a72dd72eb3819c8 Author: Jan Stancek Date: Thu Jun 30 12:23:51 2016 +0200 crypto: qat - make qat_asym_algs.o depend on asn1 headers commit 81dc0365cfa7bc7c08a0e44d9ee04964df782e19 upstream. Parallel build can sporadically fail because asn1 headers may not be built yet by the time qat_asym_algs.o is compiled: drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: qat_rsapubkey-asn1.h: No such file or directory #include "qat_rsapubkey-asn1.h" Signed-off-by: Jan Stancek Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 16d5fa572ffd29d783309cfeb7cf364d3a643035 Author: Herbert Xu Date: Fri Jul 22 17:58:21 2016 +0800 crypto: rsa-pkcs1pad - fix rsa-pkcs1pad request struct commit 87dcdebd6beb54f183ae874664ba47bf071ebf95 upstream. To allow for child request context the struct akcipher_request child_req needs to be at the end of the structure. Signed-off-by: Tadeusz Struk Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4f024de7f1d1db5ebf21ec7fc64eda23d64c2069 Author: Hugh Dickins Date: Sun Jul 10 16:46:32 2016 -0700 tmpfs: fix regression hang in fallocate undo commit 7f556567036cb7f89aabe2f0954b08566b4efb53 upstream. The well-spotted fallocate undo fix is good in most cases, but not when fallocate failed on the very first page. index 0 then passes lend -1 to shmem_undo_range(), and that has two bad effects: (a) that it will undo every fallocation throughout the file, unrestricted by the current range; but more importantly (b) it can cause the undo to hang, because lend -1 is treated as truncation, which makes it keep on retrying until every page has gone, but those already fully instantiated will never go away. Big thank you to xfstests generic/269 which demonstrates this. Fixes: b9b4bb26af01 ("tmpfs: don't undo fallocate past its last page") Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 84277300e00cf88085711d69f494eeea32b186a8 Author: Anthony Romano Date: Fri Jun 24 14:48:43 2016 -0700 tmpfs: don't undo fallocate past its last page commit b9b4bb26af017dbe930cd4df7f9b2fc3a0497bfe upstream. When fallocate is interrupted it will undo a range that extends one byte past its range of allocated pages. This can corrupt an in-use page by zeroing out its first byte. Instead, undo using the inclusive byte range. Fixes: 1635f6a74152f1d ("tmpfs: undo fallocation on failure") Link: http://lkml.kernel.org/r/1462713387-16724-1-git-send-email-anthony.romano@coreos.com Signed-off-by: Anthony Romano Cc: Vlastimil Babka Cc: Hugh Dickins Cc: Brandon Philips Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 039e2836ca00b45c5c67797a7f16d1c57288df9e Author: Jan Beulich Date: Fri Jul 8 06:15:07 2016 -0600 xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7 commit 6f2d9d99213514360034c6d52d2c3919290b3504 upstream. As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on both Intel and AMD systems. Doing any kind of hardware capability checks in the driver as a prerequisite was wrong anyway: With the hypervisor being in charge, all such checking should be done by it. If ACPI data gets uploaded despite some missing capability, the hypervisor is free to ignore part or all of that data. Ditch the entire check_prereq() function, and do the only valid check (xen_initial_domain()) in the caller in its place. Signed-off-by: Jan Beulich Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit b571b6a0a563a6f3b518b037d1b73baf1b1e1ad4 Author: Steve French Date: Wed Jun 22 21:07:32 2016 -0500 File names with trailing period or space need special case conversion commit 45e8a2583d97ca758a55c608f78c4cef562644d1 upstream. POSIX allows files with trailing spaces or a trailing period but SMB3 does not, so convert these using the normal Services For Mac mapping as we do for other reserved characters such as : < > | ? * This is similar to what Macs do for the same problem over SMB3. Signed-off-by: Steve French Acked-by: Pavel Shilovsky Signed-off-by: Greg Kroah-Hartman commit 47a7cfe786e8e0d254ef40d50d02ed90ce2ff0e6 Author: Jerome Marchand Date: Thu May 26 11:52:25 2016 +0200 cifs: dynamic allocation of ntlmssp blob commit b8da344b74c822e966c6d19d6b2321efe82c5d97 upstream. In sess_auth_rawntlmssp_authenticate(), the ntlmssp blob is allocated statically and its size is an "empirical" 5*sizeof(struct _AUTHENTICATE_MESSAGE) (320B on x86_64). I don't know where this value comes from or if it was ever appropriate, but it is currently insufficient: the user and domain name in UTF16 could take 1kB by themselves. Because of that, build_ntlmssp_auth_blob() might corrupt memory (out-of-bounds write). The size of ntlmssp_blob in SMB2_sess_setup() is too small too (sizeof(struct _NEGOTIATE_MESSAGE) + 500). This patch allocates the blob dynamically in build_ntlmssp_auth_blob(). Signed-off-by: Jerome Marchand Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 419fad68e4c4135ff9859e9214dd6cf954413ca1 Author: Steve French Date: Wed Jun 22 20:12:05 2016 -0500 Fix reconnect to not defer smb3 session reconnect long after socket reconnect commit 4fcd1813e6404dd4420c7d12fb483f9320f0bf93 upstream. Azure server blocks clients that open a socket and don't do anything on it. In our reconnect scenarios, we can reconnect the tcp session and detect the socket is available but we defer the negprot and SMB3 session setup and tree connect reconnection until the next i/o is requested, but this looks suspicous to some servers who expect SMB3 negprog and session setup soon after a socket is created. In the echo thread, reconnect SMB3 sessions and tree connections that are disconnected. A later patch will replay persistent (and resilient) handle opens. Signed-off-by: Steve French Acked-by: Pavel Shilovsky Signed-off-by: Greg Kroah-Hartman commit 283e27e2313c63f10298e9a730c26f06c7774b73 Author: James Bottomley Date: Mon Jun 13 22:00:07 2016 -0700 53c700: fix BUG on untagged commands commit 8beb330044d0d1878c7b92290e91c0b889e92633 upstream. The untagged command case in the 53c700 driver has been broken since host wide tags were enabled because the replaced scsi_find_tag() function had a special case for the tag value SCSI_NO_TAG to retrieve sdev->current_cmnd. The replacement function scsi_host_find_tag() has no such special case and returns NULL causing untagged commands to trigger a BUG() in the driver. Inspection shows that the 53c700 is the only driver using this SCSI_NO_TAG case, so a local fix in the driver suffices to fix this problem globally. Fixes: 64d513ac31b - "scsi: use host wide tags by default" Reported-by: Helge Deller Tested-by: Helge Deller Signed-off-by: James Bottomley Reviewed-by: Johannes Thumshirn Reviewed-by: Ewan D. Milne Acked-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit cda1a747e63ad7c3c7f549f10526311e33b85e9b Author: Michael Holzheu Date: Mon Jun 13 17:03:48 2016 +0200 Revert "s390/kdump: Clear subchannel ID to signal non-CCW/SCSI IPL" commit 5419447e2142d6ed68c9f5c1a28630b3a290a845 upstream. This reverts commit 852ffd0f4e23248b47531058e531066a988434b5. There are use cases where an intermediate boot kernel (1) uses kexec to boot the final production kernel (2). For this scenario we should provide the original boot information to the production kernel (2). Therefore clearing the boot information during kexec() should not be done. Reported-by: Steffen Maier Signed-off-by: Michael Holzheu Reviewed-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 08d3eff690dcbdc4f27a212eb2b9578b8b579b11 Author: Martin Schwidefsky Date: Mon Jun 27 17:06:45 2016 +0200 s390: fix test_fp_ctl inline assembly contraints commit bcf4dd5f9ee096bd1510f838dd4750c35df4e38b upstream. The test_fp_ctl function is used to test if a given value is a valid floating-point control. The inline assembly in test_fp_ctl uses an incorrect constraint for the 'orig_fpc' variable. If the compiler chooses the same register for 'fpc' and 'orig_fpc' the test_fp_ctl() function always returns true. This allows user space to trigger kernel oopses with invalid floating-point control values on the signal stack. This problem has been introduced with git commit 4725c86055f5bbdcdf "s390: fix save and restore of the floating-point-control register" Reviewed-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit a497efc5759fd325496b29d411b0383db5c3e153 Author: Wei Fang Date: Tue Jun 7 14:53:56 2016 +0800 scsi: fix race between simultaneous decrements of ->host_failed commit 72d8c36ec364c82bf1bf0c64dfa1041cfaf139f7 upstream. sas_ata_strategy_handler() adds the works of the ata error handler to system_unbound_wq. This workqueue asynchronously runs work items, so the ata error handler will be performed concurrently on different CPUs. In this case, ->host_failed will be decreased simultaneously in scsi_eh_finish_cmd() on different CPUs, and become abnormal. It will lead to permanently inequality between ->host_failed and ->host_busy, and scsi error handler thread won't start running. IO errors after that won't be handled. Since all scmds must have been handled in the strategy handler, just remove the decrement in scsi_eh_finish_cmd() and zero ->host_busy after the strategy handler to fix this race. Fixes: 50824d6c5657 ("[SCSI] libsas: async ata-eh") Signed-off-by: Wei Fang Reviewed-by: James Bottomley Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 49573f8d8fbe8b2b8cec3ded667d7f8d81539708 Author: Maxim Patlasov Date: Thu Jul 21 18:24:26 2016 -0700 ovl: verify upper dentry in ovl_remove_and_whiteout() commit cfc9fde0b07c3b44b570057c5f93dda59dca1c94 upstream. The upper dentry may become stale before we call ovl_lock_rename_workdir. For example, someone could (mistakenly or maliciously) manually unlink(2) it directly from upperdir. To ensure it is not stale, let's lookup it after ovl_lock_rename_workdir and and check if it matches the upper dentry. Essentially, it is the same problem and similar solution as in commit 11f3710417d0 ("ovl: verify upper dentry before unlink and rename"). Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 51234eac5dd8b5feda9a3a8fa766f5398ecf91e3 Author: Miklos Szeredi Date: Mon Jul 4 16:49:48 2016 +0200 ovl: handle ATTR_KILL* commit b99c2d913810e56682a538c9f2394d76fca808f8 upstream. Before 4bacc9c9234c ("overlayfs: Make f_path...") file->f_path pointed to the underlying file, hence suid/sgid removal on write worked fine. After that patch file->f_path pointed to the overlay file, and the file mode bits weren't copied to overlay_inode->i_mode. So the suid/sgid removal simply stopped working. The fix is to copy the mode bits, but then ovl_setattr() needs to clear ATTR_MODE to avoid the BUG() in notify_change(). So do this first, then in the next patch copy the mode. Reported-by: Eryu Guan Signed-off-by: Miklos Szeredi Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Signed-off-by: Greg Kroah-Hartman commit 4289e00c9a26e9718b586fc49ec1bf5959e6bef3 Author: Vivek Goyal Date: Fri Jul 1 16:34:25 2016 -0400 ovl: Copy up underlying inode's ->i_mode to overlay inode commit 07a2daab49c549a37b5b744cbebb6e3f445f12bc upstream. Right now when a new overlay inode is created, we initialize overlay inode's ->i_mode from underlying inode ->i_mode but we retain only file type bits (S_IFMT) and discard permission bits. This patch changes it and retains permission bits too. This should allow overlay to do permission checks on overlay inode itself in task context. [SzM] It also fixes clearing suid/sgid bits on write. Signed-off-by: Vivek Goyal Reported-by: Eryu Guan Signed-off-by: Miklos Szeredi Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Signed-off-by: Greg Kroah-Hartman commit a7ed367c5cf3d455b8c3b85b2f6c222f01dddea1 Author: Miklos Szeredi Date: Wed Jun 29 16:03:55 2016 +0200 ovl: get_write_access() in truncate commit 03bea60409328de54e4ff7ec41672e12a9cb0908 upstream. When truncating a file we should check write access on the underlying inode. And we should do so on the lower file as well (before copy-up) for consistency. Original patch and test case by Aihua Zhang. - - >o >o - - test.c - - >o >o - - #include #include #include int main(int argc, char *argv[]) { int ret; ret = truncate(argv[0], 4096); if (ret != -1) { fprintf(stderr, "truncate(argv[0]) should have failed\n"); return 1; } if (errno != ETXTBSY) { perror("truncate(argv[0])"); return 1; } return 0; } - - >o >o - - >o >o - - >o >o - - Reported-by: Aihua Zhang Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit d5af2e4f46114089298ecae619ba1dbcc04d0135 Author: Miklos Szeredi Date: Wed Jun 29 08:26:59 2016 +0200 ovl: fix dentry leak for default_permissions commit a4859d75944a726533ab86d24bb5ffd1b2b7d6cc upstream. When using the 'default_permissions' mount option, ovl_permission() on non-directories was missing a dput(alias), resulting in "BUG Dentry still in use". Signed-off-by: Miklos Szeredi Fixes: 8d3095f4ad47 ("ovl: default permissions") Signed-off-by: Greg Kroah-Hartman commit 6fe5202594fa20e753dcd4bebf87a42d7784c46b Author: Thomas Petazzoni Date: Thu Jun 16 15:42:25 2016 +0200 ARM: mvebu: fix HW I/O coherency related deadlocks commit c5379ba8fccd99d5f99632c789f0393d84a57805 upstream. Until now, our understanding for HW I/O coherency to work on the Cortex-A9 based Marvell SoC was that only the PCIe regions should be mapped strongly-ordered. However, we were still encountering some deadlocks, especially when testing the CESA crypto engine. After checking with the HW designers, it was concluded that all the MMIO registers should be mapped as strongly ordered for the HW I/O coherency mechanism to work properly. This fixes some easy to reproduce deadlocks with the CESA crypto engine driver (dmcrypt on a sufficiently large disk partition). Tested-by: Terry Stockert Tested-by: Romain Perier Cc: Terry Stockert Cc: Romain Perier Signed-off-by: Thomas Petazzoni Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 7ed1332c01408ee1bfed17b20c35f4affc78b81e Author: Thomas Petazzoni Date: Thu Jun 16 15:42:27 2016 +0200 ARM: dts: armada-38x: fix MBUS_ID for crypto SRAM on Armada 385 Linksys commit 929e604efa3dc0522214e0dc18984be23993e9f0 upstream. When the support for the Marvell crypto engine was added in the Device Tree of the various Armada 385 Device Tree files in commit d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x boards"), a typo was made in the MBus window attributes for the Armada 385 Linksys board: 0x09/0x05 are used instead of 0x19/0x15. This commit fixes this typo, which makes the CESA engines operational on Armada 385 Linksys boards. Reported-by: Terry Stockert Cc: Terry Stockert Cc: Imre Kaloz Cc: Boris Brezillon Fixes: d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x boards") Signed-off-by: Thomas Petazzoni Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 59012669c68d4bffc0c43b96477cd4d4fcbb3c10 Author: Boris Brezillon Date: Wed Jun 15 13:20:19 2016 +0200 ARM: sunxi/dt: make the CHIP inherit from allwinner,sun5i-a13 commit 5fc39d347267bd029fcc9099c70e2fe2d53130e9 upstream. The sun4i-timer driver registers its sched_clock only if the machine is compatible with "allwinner,sun5i-a13", "allwinner,sun5i-a10s" or "allwinner,sun4i-a10". Add the missing "allwinner,sun5i-a13" string to the machine compatible. Signed-off-by: Boris Brezillon Fixes: 465a225fb2af ("ARM: sun5i: Add C.H.I.P DTS") Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit 5387cd434a12b453803a06e1f7fa502ec3c93aa6 Author: Awais Belal Date: Tue Jul 12 15:21:28 2016 +0500 ALSA: hda: add AMD Stoney PCI ID with proper driver caps commit d716fb03f76411fc7e138692e33b749cada5c094 upstream. This allows the device to correctly show up as ATI HDMI rather than a generic one and allows the driver to use the available caps. Signed-off-by: Awais Belal Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4c9e14a2c1990e6ab55fbe11d800094ed57e886e Author: Peter Wu Date: Mon Jul 11 19:51:06 2016 +0200 ALSA: hda - fix use-after-free after module unload commit ab58d8cc870ef3f0771c197700441936898d1f1d upstream. register_vga_switcheroo() sets the PM ops from the hda structure which is freed later in azx_free. Make sure that these ops are cleared. Caught by KASAN, initially noticed due to a general protection fault. Fixes: 246efa4a072f ("snd/hda: add runtime suspend/resume on optimus support (v4)") Signed-off-by: Peter Wu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 179f54fee5728e7f33587ffcde329ab5c6e56c3f Author: Takashi Iwai Date: Fri Jul 8 08:05:19 2016 +0200 ALSA: ctl: Stop notification after disconnection commit f388cdcdd160687c6650833f286b9c89c50960ff upstream. snd_ctl_remove() has a notification for the removal event. It's superfluous when done during the device got disconnected. Although the notification itself is mostly harmless, it may potentially be harmful, and should be suppressed. Actually some components PCM may free ctl elements during the disconnect or free callbacks, thus it's no theoretical issue. This patch adds the check of card->shutdown flag for avoiding unnecessary notifications after (or during) the disconnect. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c88e9adfdb62bf9728dd853c5144d7a7bc0d81a9 Author: Takashi Iwai Date: Fri Jul 8 08:23:43 2016 +0200 ALSA: pcm: Free chmap at PCM free callback, too commit a8ff48cb70835f48de5703052760312019afea55 upstream. The chmap ctls assigned to PCM streams are freed in the PCM disconnect callback. However, since the disconnect callback isn't called when the card gets freed before registering, the chmap ctls may still be left assigned. They are eventually freed together with other ctls, but it may cause an Oops at pcm_chmap_ctl_private_free(), as the function refers to the assigned PCM stream, while the PCM objects have been already freed beforehand. The fix is to free the chmap ctls also at PCM free callback, not only at PCM disconnect. Reported-by: Laxminath Kasam Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0e8e33aa7f5dc52382f2bc958254f547c9719a60 Author: Hui Wang Date: Fri Jul 8 14:26:57 2016 +0800 ALSA: hda/realtek - add new pin definition in alc225 pin quirk table commit 8a132099f080d7384bb6ab4cc168f76cb4b47d08 upstream. We have some Dell laptops which can't detect headset mic, the machines use the codec ALC225, they have some new pin configuration values, after adding them in the alc225 pin quirk table, they work well. Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3f5f500b1b660ee60558112c55f2464f341201e0 Author: Kazuki Oikawa Date: Mon Jul 18 01:16:15 2016 +0900 ALSA: usb-audio: Fix quirks code is not called commit 76df52969711ae3725a98f26fbbc6a349803dcbf upstream. snd_usb_{set_interface,ctl_msg}_quirk checks chip->usb_id to need calling a quirks code. But existed code path that not calling dev_set_drvdata in usb_audio_probe. Fixes: 79289e24194a ("ALSA: usb-audio: Refer to chip->usb_id for quirks and MIDI creation") Signed-off-by: Kazuki Oikawa Reviewed-by: Takashi Sakamoto Tested-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 85d9c85417b55bd3ded0a45463374d2e52762b0d Author: Bob Copeland Date: Sat Jun 25 07:58:45 2016 -0400 ALSA: hda - fix read before array start commit 81e43960dce1c8e58e682fb3ec26c1d8f83a9afc upstream. UBSAN reports the following warning from accessing path->path[-1] in set_path_power(): [ 16.078040] ================================================================================ [ 16.078124] UBSAN: Undefined behaviour in sound/pci/hda/hda_generic.c:3981:17 [ 16.078198] index -1 is out of range for type 'hda_nid_t [10]' [ 16.078270] CPU: 2 PID: 1738 Comm: modprobe Not tainted 4.7.0-rc1-wt+ #47 [ 16.078274] Hardware name: LENOVO 3443CTO/3443CTO, BIOS G6ET23WW (1.02 ) 08/14/2012 [ 16.078278] ffff8800cb246000 ffff8800cb3638b8 ffffffff815c4fe3 0000000000000032 [ 16.078286] ffff8800cb3638e0 ffffffffffffffff ffff8800cb3638d0 ffffffff8162443d [ 16.078294] ffffffffa0894200 ffff8800cb363920 ffffffff81624af7 0000000000000292 [ 16.078302] Call Trace: [ 16.078311] [] dump_stack+0x86/0xd3 [ 16.078317] [] ubsan_epilogue+0xd/0x40 [ 16.078324] [] __ubsan_handle_out_of_bounds+0x67/0x70 [ 16.078335] [] set_path_power+0x1bf/0x230 [snd_hda_codec_generic] [ 16.078344] [] add_pin_power_ctls+0x8d/0xc0 [snd_hda_codec_generic] [ 16.078352] [] ? pin_power_down_callback+0x20/0x20 [snd_hda_codec_generic] [ 16.078360] [] add_all_pin_power_ctls+0x107/0x150 [snd_hda_codec_generic] [ 16.078370] [] snd_hda_gen_parse_auto_config+0x2d73/0x49e0 [snd_hda_codec_generic] [ 16.078376] [] ? trace_hardirqs_on_caller+0x1b0/0x2c0 [ 16.078390] [] alc_parse_auto_config+0x147/0x310 [snd_hda_codec_realtek] [ 16.078402] [] patch_alc269+0x23a/0x560 [snd_hda_codec_realtek] [ 16.078417] [] hda_codec_driver_probe+0xa4/0x1a0 [snd_hda_codec] [ 16.078424] [] driver_probe_device+0x101/0x380 [ 16.078430] [] __driver_attach+0xb9/0x100 [ 16.078438] [] ? driver_probe_device+0x380/0x380 [ 16.078444] [] bus_for_each_dev+0x70/0xc0 [ 16.078449] [] driver_attach+0x27/0x50 [ 16.078454] [] bus_add_driver+0x166/0x2c0 [ 16.078460] [] ? 0xffffffffa0369000 [ 16.078465] [] driver_register+0x7d/0x130 [ 16.078477] [] __hda_codec_driver_register+0x6f/0x90 [snd_hda_codec] [ 16.078488] [] realtek_driver_init+0x1e/0x1000 [snd_hda_codec_realtek] [ 16.078493] [] do_one_initcall+0x4e/0x1d0 [ 16.078499] [] ? rcu_read_lock_sched_held+0x6d/0x80 [ 16.078504] [] ? kmem_cache_alloc_trace+0x391/0x560 [ 16.078510] [] ? do_init_module+0x28/0x273 [ 16.078515] [] do_init_module+0x9b/0x273 [ 16.078522] [] load_module+0x20b2/0x3410 [ 16.078527] [] ? m_show+0x210/0x210 [ 16.078533] [] ? kernel_read+0x66/0xe0 [ 16.078541] [] SYSC_finit_module+0xba/0xc0 [ 16.078547] [] SyS_finit_module+0xe/0x10 [ 16.078552] [] entry_SYSCALL_64_fastpath+0x1f/0xbd [ 16.078556] ================================================================================ Fix by checking path->depth before use. Signed-off-by: Bob Copeland Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cfc5828603ebe81224ccb3a4b065e886fe55aede Author: Vinod Koul Date: Wed Jun 29 10:27:52 2016 +0530 ALSA: hda - Add PCI ID for Kabylake-H commit 6858107e78b4ecb9f244db814ffbdba1b5ce759b upstream. Kabylake-H shows up as PCI ID 0xa2f0. We missed adding this earlier with other KBL IDs. Signed-off-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9b798654576f70415f5548bf5901c2afd19b7edf Author: Torsten Hilbrich Date: Tue Jul 5 10:40:22 2016 +0200 ALSA: hda/realtek: Add Lenovo L460 to docking unit fixup commit 9cd25743765cfe851aed8d655a62d60156aed293 upstream. This solves the issue that a headphone is not working on the docking unit. Signed-off-by: Torsten Hilbrich Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1c390f3dd65d471b60750168613f5b2e8e0779ab Author: Takashi Iwai Date: Mon Jul 4 14:02:15 2016 +0200 ALSA: timer: Fix negative queue usage by racy accesses commit 3fa6993fef634e05d200d141a85df0b044572364 upstream. The user timer tu->qused counter may go to a negative value when multiple concurrent reads are performed since both the check and the decrement of tu->qused are done in two individual locked contexts. This results in bogus read outs, and the endless loop in the user-space side. The fix is to move the decrement of the tu->qused counter into the same spinlock context as the zero-check of the counter. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b4095aacd5b02a6a2b9bf5bb913f9aede4833161 Author: Christophe JAILLET Date: Mon Jun 27 21:06:51 2016 +0200 ALSA: echoaudio: Fix memory allocation commit 9c6795a9b3cbb56a9fbfaf43909c5c22999ba317 upstream. 'commpage_bak' is allocated with 'sizeof(struct echoaudio)' bytes. We then copy 'sizeof(struct comm_page)' bytes in it. On my system, smatch complains because one is 2960 and the other is 3072. This would result in memory corruption or a oops. Signed-off-by: Christophe JAILLET Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7d4e6bea615ad52878775104f1103d7c63697c2d Author: Takashi Iwai Date: Wed Jun 29 15:23:08 2016 +0200 ALSA: au88x0: Fix calculation in vortex_wtdma_bufshift() commit 62db7152c924e4c060e42b34a69cd39658e8a0dc upstream. vortex_wtdma_bufshift() function does calculate the page index wrongly, first masking then shift, which always results in zero. The proper computation is to first shift, then mask. Reported-by: Dan Carpenter Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 15cda2ef2aae50f1b00822dbc8f110e46b87e668 Author: Jaroslav Kysela Date: Fri Jun 24 15:13:16 2016 +0200 ALSA: hda / realtek - add two more Thinkpad IDs (5050,5053) for tpt460 fixup commit 0f087ee3f3b86a4507db4ff1d2d5a3880e4cfd16 upstream. See: https://bugzilla.redhat.com/show_bug.cgi?id=1349539 See: https://bugzilla.kernel.org/show_bug.cgi?id=120961 Signed-off-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6f7aa1752f0466fc10003f54b0ce26074bfc7795 Author: Woodrow Shen Date: Fri Jun 24 15:58:34 2016 +0800 ALSA: hda - Fix the headset mic jack detection on Dell machine commit f83c32925d45926cd0e0f18bf28e6039116c4486 upstream. The new Dell laptop with codec 3246 can't detect headset mic when headset was inserted on the machine. So adding pin configurations into quirk table makes headset mic work correctly. Codec: Realtek ALC3246 Vendor Id: 0x10ec0256 Subsystem Id: 0x10280781 Signed-off-by: Woodrow Shen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5dbf9612eeb5bcb863d727439754980847e45d5a Author: Jaroslav Kysela Date: Fri Jun 17 13:35:56 2016 +0200 ALSA: hdac_regmap - fix the register access for runtime PM commit 8198868f0a283eb23e264951632ce61ec2f82228 upstream. Call path: 1) snd_hdac_power_up_pm() 2) snd_hdac_power_up() 3) pm_runtime_get_sync() 4) __pm_runtime_resume() 5) rpm_resume() The rpm_resume() returns 1 when the device is already active. Because the return value is unmodified, the hdac regmap read/write functions should allow this value for the retry I/O operation, too. Signed-off-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2addf5091bd36b2bf59ef3b18c6faadbc08a6653 Author: Takashi Iwai Date: Fri Jun 24 15:15:26 2016 +0200 ALSA: dummy: Fix a use-after-free at closing commit d5dbbe6569481bf12dcbe3e12cff72c5f78d272c upstream. syzkaller fuzzer spotted a potential use-after-free case in snd-dummy driver when hrtimer is used as backend: > ================================================================== > BUG: KASAN: use-after-free in rb_erase+0x1b17/0x2010 at addr ffff88005e5b6f68 > Read of size 8 by task syz-executor/8984 > ============================================================================= > BUG kmalloc-192 (Not tainted): kasan: bad access detected > ----------------------------------------------------------------------------- > > Disabling lock debugging due to kernel taint > INFO: Allocated in 0xbbbbbbbbbbbbbbbb age=18446705582212484632 > .... > [< none >] dummy_hrtimer_create+0x49/0x1a0 sound/drivers/dummy.c:464 > .... > INFO: Freed in 0xfffd8e09 age=18446705496313138713 cpu=2164287125 pid=-1 > [< none >] dummy_hrtimer_free+0x68/0x80 sound/drivers/dummy.c:481 > .... > Call Trace: > [] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:333 > [< inline >] rb_set_parent include/linux/rbtree_augmented.h:111 > [< inline >] __rb_erase_augmented include/linux/rbtree_augmented.h:218 > [] rb_erase+0x1b17/0x2010 lib/rbtree.c:427 > [] timerqueue_del+0x78/0x170 lib/timerqueue.c:86 > [] __remove_hrtimer+0x90/0x220 kernel/time/hrtimer.c:903 > [< inline >] remove_hrtimer kernel/time/hrtimer.c:945 > [] hrtimer_try_to_cancel+0x22a/0x570 kernel/time/hrtimer.c:1046 > [] hrtimer_cancel+0x22/0x40 kernel/time/hrtimer.c:1066 > [] dummy_hrtimer_stop+0x91/0xb0 sound/drivers/dummy.c:417 > [] dummy_pcm_trigger+0x17f/0x1e0 sound/drivers/dummy.c:507 > [] snd_pcm_do_stop+0x160/0x1b0 sound/core/pcm_native.c:1106 > [] snd_pcm_action_single+0x76/0x120 sound/core/pcm_native.c:956 > [] snd_pcm_action+0x231/0x290 sound/core/pcm_native.c:974 > [< inline >] snd_pcm_stop sound/core/pcm_native.c:1139 > [] snd_pcm_drop+0x12d/0x1d0 sound/core/pcm_native.c:1784 > [] snd_pcm_common_ioctl1+0xfae/0x2150 sound/core/pcm_native.c:2805 > [] snd_pcm_capture_ioctl1+0x2a1/0x5e0 sound/core/pcm_native.c:2976 > [] snd_pcm_kernel_ioctl+0x11c/0x160 sound/core/pcm_native.c:3020 > [] snd_pcm_oss_sync+0x3a4/0xa30 sound/core/oss/pcm_oss.c:1693 > [] snd_pcm_oss_release+0x1ad/0x280 sound/core/oss/pcm_oss.c:2483 > ..... A workaround is to call hrtimer_cancel() in dummy_hrtimer_sync() which is called certainly before other blocking ops. Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b5cf1368778963fb85ca296d04792b7b0078a977 Author: Pali Rohár Date: Sat Jun 18 00:54:47 2016 +0200 hwmon: (dell-smm) Cache fan_type() calls and change fan detection commit 5ce91714b0d8c0a3ff9b858966721f508351cf4c upstream. On more Dell machines (e.g. Dell Precision M3800) fan_type() call is too expensive (CPU is too long in SMM mode) and cause kernel to hang. This is bug in Dell SMM or BIOS. This patch caches type for each fan (as it should not change) and changes the way how fan presense is detected. First it try function fan_status() as was before commit f989e55452c7 ("i8k: Add support for fan labels"). And if that fails fallback to fan_type(). *_status() functions can fail in case fan is not currently accessible (e.g. present on GPU which is currently turned off). Reported-by: Tolga Cakir Signed-off-by: Pali Rohár Link: https://bugzilla.kernel.org/show_bug.cgi?id=112021 Tested-by: Tolga Cakir Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 0a3936e0941c7e9d342d56408385076bd643697f Author: Pali Rohár Date: Sat Jun 18 00:54:46 2016 +0200 hwmon: (dell-smm) Disallow fan_type() calls on broken machines commit 2744d2fde00dc8bcc3679eb72c81a63058e90faa upstream. Some Dell machines have especially broken SMM or BIOS which cause that once fan_type() is called then CPU fan speed going randomly up and down. And for fixing this behaviour reboot is required. So this patch creates fan_type blacklist of affected Dell machines and disallow fan_type() call on them to prevent that erratic behaviour. Old blacklist which disabled loading driver on some machines added in commits a4b45b25f18d ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8100") and 6220f4ebd7b4 ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8000") were moved to FAN_TYPE blacklist. Reported-by: Jan C Peters Signed-off-by: Pali Rohár Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121 Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit d2c0c2d381f812697d24cdb181e00a306c1d833f Author: Pali Rohár Date: Sat Jun 18 00:54:45 2016 +0200 hwmon: (dell-smm) Restrict fan control and serial number to CAP_SYS_ADMIN by default commit 7613663cc186f8f3c50279390ddc60286758001c upstream. For security reasons ordinary user must not be able to control fan speed via /proc/i8k by default. Some malicious software running under "nobody" user could be able to turn fan off and cause HW problems. So this patch changes default value of "restricted" parameter to 1. Also restrict reading of DMI_PRODUCT_SERIAL from /proc/i8k via "restricted" parameter. It is because non root user cannot read DMI_PRODUCT_SERIAL from sysfs file /sys/class/dmi/id/product_serial. Old non secure behaviour of file /proc/i8k can be achieved by loading this module with "restricted" parameter set to 0. Note that this patch has effects only for kernels compiled with CONFIG_I8K and only for file /proc/i8k. Hwmon interface provided by this driver was not changed and root access for setting fan speed was needed also before. Reported-by: Mario Limonciello Signed-off-by: Pali Rohár Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 78881b963f2f6302482aaa1c4486b3b4ed0d0f17 Author: Dmitry Torokhov Date: Mon Jun 27 14:12:34 2016 -0700 tty/vt/keyboard: fix OOB access in do_compute_shiftstate() commit 510cccb5b0c8868a2b302a0ab524da7912da648b upstream. The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS, which is currently 256, whereas number of keys/buttons in input device (and therefor in key_down) is much larger - KEY_CNT - 768, and that can cause out-of-bound access when we do sym = U(key_maps[0][k]); with large 'k'. To fix it we should not attempt iterating beyond smaller of NR_KEYS and KEY_CNT. Also while at it let's switch to for_each_set_bit() instead of open-coding it. Reported-by: Sasha Levin Reviewed-by: Guenter Roeck Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 68dd25deda2f7995f127abd206596c78d1fb4c09 Author: David Daney Date: Tue May 17 11:41:04 2016 -0700 tty: vt: Fix soft lockup in fbcon cursor blink timer. commit 1b45996d2ebf9680ccd0db875fc668aa025f40fd upstream. We are getting somewhat random soft lockups with this signature: [ 86.992215] [] el1_irq+0xa0/0x10c [ 86.997082] [] cursor_timer_handler+0x30/0x54 [ 87.002991] [] call_timer_fn+0x54/0x1a8 [ 87.008378] [] run_timer_softirq+0x1c4/0x2bc [ 87.014200] [] __do_softirq+0x114/0x344 [ 87.019590] [] irq_exit+0x74/0x98 [ 87.024458] [] __handle_domain_irq+0x98/0xfc [ 87.030278] [] gic_handle_irq+0x94/0x190 This is caused by the vt visual_init() function calling into fbcon_init() with a vc_cur_blink_ms value of zero. This is a transient condition, as it is later set to a non-zero value. But, if the timer happens to expire while the blink rate is zero, it goes into an endless loop, and we get soft lockup. The fix is to initialize vc_cur_blink_ms before calling the con_init() function. Signed-off-by: David Daney Acked-by: Pavel Machek Tested-by: Ming Lei Acked-by: Scot Doyle Tested-by: Henrique de Moraes Holschuh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 334f366ec63ad195dfb683c18cc37dac738292cd Author: Mark Brown Date: Mon Jun 20 13:53:34 2016 +0100 iio:ad7266: Fix probe deferral for vref commit 68b356eb3d9f5e38910fb62e22a78e2a18d544ae upstream. Currently the ad7266 driver treats any failure to get vref as though the regulator were not present but this means that if probe deferral is triggered the driver will act as though the regulator were not present. Instead only use the internal reference if we explicitly got -ENODEV which is what is returned for absent regulators. Signed-off-by: Mark Brown Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bab9b7393efed66c1781fc21b54ed421d6d9ca4c Author: Mark Brown Date: Mon Jun 20 13:53:33 2016 +0100 iio:ad7266: Fix support for optional regulators commit e5511c816e5ac4909bdd38e85ac344e2b9b8e984 upstream. The ad7266 driver attempts to support deciding between the use of internal and external power supplies by checking to see if an error is returned when requesting the regulator. This doesn't work with the current code since the driver uses a normal regulator_get() which is for non-optional supplies and so assumes that if a regulator is not provided by the platform then this is a bug in the platform integration and so substitutes a dummy regulator. Use regulator_get_optional() instead which indicates to the framework that the regulator may be absent and provides a dummy regulator instead. Signed-off-by: Mark Brown Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1ac9c884397b7caf2044fca8a64e337a87ccd060 Author: Mark Brown Date: Mon Jun 20 13:53:32 2016 +0100 iio:ad7266: Fix broken regulator error handling commit 6b7f4e25f3309f106a5c7ff42c8231494cf285d3 upstream. All regulator_get() variants return either a pointer to a regulator or an ERR_PTR() so testing for NULL makes no sense and may lead to bugs if we use NULL as a valid regulator. Fix this by using IS_ERR() as expected. Signed-off-by: Mark Brown Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 26b3c9975e2a6e456a98643e33a87458562f66ae Author: Linus Walleij Date: Fri Jun 17 15:22:24 2016 +0200 iio: accel: kxsd9: fix the usage of spi_w8r8() commit 0c1f91b98552da49d9d8eed32b3132a58d2f4598 upstream. These two spi_w8r8() calls return a value with is used by the code following the error check. The dubious use was caused by a cleanup patch. Fixes: d34dbee8ac8e ("staging:iio:accel:kxsd9 cleanup and conversion to iio_chan_spec.") Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3a305c4126f9b0855d7e142d84310553eea0d0e6 Author: Luis de Bethencourt Date: Wed Jun 22 20:43:30 2016 +0100 staging: iio: accel: fix error check commit ef3149eb3ddb7f9125e11c90f8330e371b55cffd upstream. sca3000_read_ctrl_reg() returns a negative number on failure, check for this instead of zero. Signed-off-by: Luis de Bethencourt Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a9a8bcdace6e3665287ff4bd9e95d99877c14c7c Author: Matt Ranostay Date: Sun May 29 19:52:02 2016 -0700 iio: hudmidity: hdc100x: fix incorrect shifting and scaling commit 94bef000f1d4aa111f4ddda1482cf3b30ad069ce upstream. Shifting sensor data to the right 2 bits was incorrect and caused the scaling values + offsets to be invalid. Reported-by: Alison Schofield Signed-off-by: Matt Ranostay Tested-by: Alison Schofield Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f5b3e8171c6249142308542007111a4a559772a8 Author: Matt Ranostay Date: Thu May 26 19:55:06 2016 -0700 iio: humidity: hdc100x: fix IIO_TEMP channel reporting commit 09bc0ddaab6cab0fa95a67d5535ec772e2671193 upstream. IIO_TEMP channel was being incorrectly reported back as Celsius when it should have been milliCelsius. This is via an incorrect scale value being returned to userspace. Signed-off-by: Matt Ranostay Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 65a39273cf07603ffe8734557c83ac3ce8917253 Author: Alison Schofield Date: Fri May 20 10:06:41 2016 -0700 iio: humidity: hdc100x: correct humidity integration time mask commit 0e35cf5ce00d873d6e529d2b2cd7598d52438051 upstream. Apply the correct mask to enable all available humidity integration times. Currently, the driver defaults to 6500 and all is okay with that. However, if 3850 is selected we get a stuck bit and can't change back to 6500 or select 2500. (Verified with HDC1008) Signed-off-by: Alison Schofield Cc: Daniel Baluta Reviewed-by: Matt Ranostay Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4866f01a114489b78f7a2443ec363a2330bf8ab1 Author: Matt Ranostay Date: Sat May 21 20:01:03 2016 -0700 iio: proximity: as3935: fix buffer stack trashing commit 37b1ba2c68cfbe37f5f45bb91bcfaf2b016ae6a1 upstream. Buffer wasn't of a valid size to allow the timestamp, and correct padding. This patchset also moves the buffer off the stack, and onto the heap. Cc: george.mccollister@gmail.com Signed-off-by: Matt Ranostay Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ccef316501702055682533e53597229e3f391ee2 Author: Matt Ranostay Date: Sat May 21 20:01:02 2016 -0700 iio: proximity: as3935: remove triggered buffer processing commit 7d0643634ea567969bf3f3ed6193a9d6fc75653b upstream. Triggered buffers shouldn't return processed data, and the respective conversion was overflowing the defined .realbits for the channel. Cc: george.mccollister@gmail.com Signed-off-by: Matt Ranostay Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f8e01fcf2911593bd9f149614d3540641fdba07c Author: Matt Ranostay Date: Sat May 21 20:01:01 2016 -0700 iio: proximity: as3935: correct IIO_CHAN_INFO_RAW output commit 5138806f16c74c7cb8ac3e408a859c79eb7c9567 upstream. IIO_CHAN_INFO_RAW was returning processed data which was incorrect. This also adds the IIO_CHAN_INFO_SCALE value to convert to a processed value. Signed-off-by: Matt Ranostay Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 43c1f4698602e3440968fc8df71d1ff4e69e33fe Author: Yong Li Date: Thu May 5 16:10:49 2016 +0800 iio: light apds9960: Add the missing dev.parent commit 590b92a30242dd3f73de3d9a51d9924f1ab33e93 upstream. Without this, the iio:deviceX is missing in the /sys/bus/i2c/devices/0-0039 Some userspace tools use this path to identify a specific instance of the device. Signed-off-by: Yong Li Reviewed-By: Matt Ranostay Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1c94121fddb2e823898d743d1935a045c9ef3ca1 Author: Gregor Boirie Date: Tue Apr 19 11:18:33 2016 +0200 iio:st_pressure: fix sampling gains (bring inline with ABI) commit d43a41152f8e9e4c0d19850884d1fada076dee10 upstream. Temperature channels report scaled samples in Celsius although expected as milli degree Celsius in Documentation/ABI/testing/sysfs-bus-iio. Gains are not implemented at all for LPS001WP pressure and temperature channels. This patch ensures that proper offsets and scales are exposed to userpace for both pressure and temperature channels. Also fix a NULL pointer exception when userspace reads content of sysfs scale attribute when gains are not defined. Signed-off-by: Gregor Boirie Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c2b621ce19615cbf5441f4ddc30f7e29dc183ca3 Author: Crestez Dan Leonard Date: Tue May 3 15:27:09 2016 +0300 iio: Fix error handling in iio_trigger_attach_poll_func commit 99543823357966ac938d9a310947e731b67338e6 upstream. When attaching a pollfunc iio_trigger_attach_poll_func will allocate a virtual irq and call the driver's set_trigger_state function. Fix error handling to undo previous steps if any fails. In particular this fixes handling errors from a driver's set_trigger_state function. When using triggered buffers a failure to enable the trigger used to make the buffer unusable. Signed-off-by: Crestez Dan Leonard Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 78b32b54518a86da0f42542953ff2827b10868a6 Author: Ross Lagerwall Date: Tue May 10 10:27:54 2016 +0100 xen/balloon: Fix declared-but-not-defined warning commit 842775f1509054ea969f1787f38d6a0ec2ccfaba upstream. Fix a declared-but-not-defined warning when building with XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by commit dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE"). Signed-off-by: Ross Lagerwall Acked-by: Juergen Gross Signed-off-by: David Vrabel Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 5109ee4274474fe3212d50d8083697e281ba7940 Author: David Miller Date: Sat Jun 18 23:52:25 2016 -0700 PCI: Fix unaligned accesses in VC code commit ef0dab4aae14e25efddf1577736f8450132800c5 upstream. The save/restore buffers for VC state is first composed of a 2-byte control register, then a bunch of 4-byte words. This causes unaligned accesses which trap on platform such as sparc. This is easy to fix by simply moving the buffer pointer forward by 4 bytes instead of 2 after dealing with the control register. The length adjustment needs to be changed likewise as well. Fixes: 5f8fc43217a0 ("PCI: Include pci/pcie/Kconfig directly from pci/Kconfig") Reported-by: Meelis Roos Reported-by: Anatoly Pugachev Signed-off-by: David S. Miller Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 0e3e49c34861ce25d8cb95b0fef1be249dfe2434 Author: Ocquidant, Sebastien Date: Wed Jun 15 13:47:35 2016 +0200 memory: omap-gpmc: Fix omap gpmc EXTRADELAY timing commit 8f50b8e57442d28e41bb736c173d8a2490549a82 upstream. In the omap gpmc driver it can be noticed that GPMC_CONFIG4_OEEXTRADELAY is overwritten by the WEEXTRADELAY value from the device tree and GPMC_CONFIG4_WEEXTRADELAY is not updated by the value from the device tree. As a consequence, the memory accesses cannot be configured properly when the extra delay are needed for OE and WE. Fix the update of GPMC_CONFIG4_WEEXTRADELAY with the value from the device tree file and prevents GPMC_CONFIG4_OEXTRADELAY being overwritten by the WEXTRADELAY value from the device tree. Signed-off-by: Ocquidant, Sebastien Signed-off-by: Roger Quadros Signed-off-by: Greg Kroah-Hartman commit ea6c83c80fc75f6dee0d0c52675287ff5f46a617 Author: Sinclair Yeh Date: Thu Jul 7 11:01:30 2016 -0700 drm/vmwgfx: Fix error paths when mapping framebuffer commit 58541f7a6458e17ab417321b284f0090f530aa91 upstream. Rather than returning immediately, make sure to unlock the mutexes first. Signed-off-by: Sinclair Yeh Reviewed-by: Charmaine Lee Reported-by: Emil Velikov Signed-off-by: Greg Kroah-Hartman commit 6a1c743a96ac3ac22249d0efb001a59165bd8e3d Author: Thomas Hellstrom Date: Wed Jun 29 13:37:35 2016 -0700 drm/vmwgfx: Fix corner case screen target management commit beca4cf55323147ca9c8a98de1871be6e4fe8f34 upstream. When the surface backing a framebuffer doesn't match the framebuffer's dimensions, the screen target code would test the framebuffer dimensions rather than the surface dimensions when deciding whether to bind the surface as a screen target directly. This causes a screen target - surface dimension mismatch and a subsequent device error. Fix this by testing against the surface dimension. v2: Fix review comments by Sinclair Yeh. Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh Signed-off-by: Greg Kroah-Hartman commit 14f0b144c4fcbc19b3a236802d8fdb84b1a57476 Author: Sinclair Yeh Date: Wed Jun 29 13:23:18 2016 -0700 drm/vmwgfx: Delay pinning fbdev framebuffer until after mode set commit d5f1a291e32309324a8c481ed84b5c118d1360ea upstream. For the Screen Object display unit, we need to reserve a guest-invisible region equal to the size of the framebuffer for the host. This region can only be reserved in VRAM, whereas the guest-visible framebuffer can be reserved in either VRAM or GMR. As such priority should be given to the guest-invisible region otherwise in a limited VRAM situation, we can fail to allocate this region. This patch makes it so that vmw_sou_backing_alloc() is called before the framebuffer is pinned. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit ea530263cd022119c3799ac932ebbd28e341b201 Author: Sinclair Yeh Date: Wed Jun 29 13:20:26 2016 -0700 drm/vmwgfx: Check pin count before attempting to move a buffer commit 4ed7e2242b637bc4af0416e4aa9f945db30fb44a upstream. In certain scenarios, e.g. when fbdev is enabled, we can get into a situation where a vmw_framebuffer_pin() is called on a buffer that is already pinned. When this happens, ttm_bo_validate() will unintentially remove the TTM_PL_FLAG_NO_EVICT flag, thus unpinning it, and leaving no way to actually pin the buffer again. To prevent this, if a buffer is already pinned, then instead of calling ttm_bo_validate(), just make sure the proposed placement is compatible with the existing placement. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit 3e2dd00e573542f0a97063f32b50f1e3a32ccaa2 Author: Sinclair Yeh Date: Wed Jun 29 11:29:47 2016 -0700 drm/vmwgfx: Work around mode set failure in 2D VMs commit 7c20d213dd3cd6295bf9162730e7a368af957854 upstream. In a low-memory 2D VM, fbdev can take up a large percentage of available memory, making them unavailable for other DRM clients. Since we do not take fbdev into account when filtering modes, we end up claiming to support more modes than we actually do. As a result, users get a black screen when setting a mode too large for current available memory. In a low-memory VM configuration, users can get a black screen for a mode as low as 1024x768. The current mode filtering mechanism keys off of SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount of surface memory we have. Since this value is a performance suggestion, not a hard limit, and since there should not be much of a performance impact for a 2D VM, rather than filtering out more modes, we will just allow ourselves to exceed the SVGA's performance suggestion. Also changed assumed bpp to 32 from 16 to make sure we can actually support all the modes listed. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit 33c4de41d7d0ec957994d31a39e621d4c2eb65cf Author: Sinclair Yeh Date: Wed Jun 29 12:15:48 2016 -0700 drm/vmwgfx: Add an option to change assumed FB bpp commit 04319d89fbec72dfd60738003c3813b97c1d5f5a upstream. Offer an option for advanced users who want larger modes at 16bpp. This becomes necessary after the fix: "Work around mode set failure in 2D VMs." Without this patch, there would be no way for existing advanced users to get to a high res mode, and the regression is they will likely get a black screen after a software update on their current VM. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit 70124a05e699c951f59a670bdca4872d6e75d701 Author: Sinclair Yeh Date: Wed Jun 29 12:58:49 2016 -0700 drm/ttm: Make ttm_bo_mem_compat available commit 94477bff390aa4612d2332c8abafaae0a13d6923 upstream. There are cases where it is desired to see if a proposed placement is compatible with a buffer object before calling ttm_bo_validate(). Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit 21b8579a4269abca96090544db8fb3499a5a24a7 Author: Maarten Lankhorst Date: Thu Jun 23 13:45:06 2016 +0200 drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx commit 81e257e964268d050f8e9188becd44d50f241d72 upstream. Atomic updates may acquire more state than initially locked through drm_modeset_lock_crtc, running with heavy stress can cause a WARN_ON(crtc->acquire_ctx) in drm_modeset_lock_crtc: [ 601.491296] ------------[ cut here ]------------ [ 601.491366] WARNING: CPU: 0 PID: 2411 at drivers/gpu/drm/drm_modeset_lock.c:191 drm_modeset_lock_crtc+0xeb/0xf0 [drm] [ 601.491369] Modules linked in: drm i915 drm_kms_helper [ 601.491414] CPU: 0 PID: 2411 Comm: kms_cursor_lega Tainted: G U 4.7.0-rc4-patser+ #4798 [ 601.491417] Hardware name: Intel Corporation Skylake Client [ 601.491420] 0000000000000000 ffff88044d153c98 ffffffff812ead28 0000000000000000 [ 601.491425] 0000000000000000 ffff88044d153cd8 ffffffff810868e6 000000bf58058030 [ 601.491431] ffff880088b415e8 ffff880458058030 ffff88008a271548 ffff88008a271568 [ 601.491436] Call Trace: [ 601.491443] [] dump_stack+0x4d/0x65 [ 601.491447] [] __warn+0xc6/0xe0 [ 601.491452] [] warn_slowpath_null+0x18/0x20 [ 601.491472] [] drm_modeset_lock_crtc+0xeb/0xf0 [drm] [ 601.491491] [] drm_mode_cursor_common+0x66/0x180 [drm] [ 601.491509] [] drm_mode_cursor_ioctl+0x3c/0x40 [drm] [ 601.491524] [] drm_ioctl+0x14d/0x530 [drm] [ 601.491540] [] ? drm_mode_setcrtc+0x520/0x520 [drm] [ 601.491545] [] ? handle_mm_fault+0x106b/0x1430 [ 601.491550] [] ? stop_one_cpu+0x61/0x70 [ 601.491556] [] do_vfs_ioctl+0x8d/0x570 [ 601.491560] [] ? security_file_ioctl+0x3e/0x60 [ 601.491565] [] SyS_ioctl+0x74/0x80 [ 601.491571] [] ? posix_get_monotonic_raw+0xc/0x10 [ 601.491576] [] entry_SYSCALL_64_fastpath+0x13/0x8f [ 601.491581] ---[ end trace 56f3d3d85f000d00 ]--- For good measure, test mode_config.acquire_ctx too, although this should never happen. Testcase: kms_cursor_legacy Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit d1cbd8dabac8ffff6b5ce1ba41b44fd09bbe3116 Author: Boris Brezillon Date: Fri May 27 16:09:25 2016 +0200 drm: atmel-hlcdc: actually disable scaling when no scaling is required commit 1b7e38b92b0bbd363369f5160f13f4d26140972d upstream. The driver is only enabling scaling, but never disabling it, thus, if you enable the scaling feature once it stays enabled forever. Signed-off-by: Boris Brezillon Reported-by: Alex Vazquez Reviewed-by: Nicolas Ferre Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support") Signed-off-by: Greg Kroah-Hartman commit dcab0eb0c8ec063200208dd34d68ec4d949abdd4 Author: Huang Rui Date: Wed Jul 6 09:32:24 2016 +0800 drm/amd/powerplay: fix incorrect voltage table value for tonga commit 1dfefee8939b07dd65a35bb78f6a06df85578301 upstream. Signed-off-by: Huang Rui Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6c0fe421ecbdac7e34ef3d16b8a90ea13439ed91 Author: Rex Zhu Date: Tue Jul 5 13:11:47 2016 +0800 drm/amd/powerplay: incorrectly use of the function return value commit 4b2427605e5325eafb5cfc2698f517db68e41075 upstream. '0' means true. Signed-off-by: Rex Zhu Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2bd21542f31fb3ab1c2155634e9e7002dedbdcfa Author: Rex Zhu Date: Fri Jun 17 18:21:01 2016 +0800 drm/amd/powerplay: fix logic error. commit 1d7b84d12af8312b52316029f1fa0fa4eac3c9e4 upstream. the error lead powerplay can't get display info in DGPU case. store_cc6_data just implement in APU. Signed-off-by: Rex Zhu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 02cfc0e22d35a28a7b4148ba9047f096c4f0a659 Author: Rex Zhu Date: Tue Jun 14 18:36:36 2016 +0800 drm/amd/powerplay: need to notify system bios pcie device ready commit 0a4fef559b69ae2e682c98f31d53a225fbda78bd upstream. before request performance state. Signed-off-by: Rex Zhu Reviewed-by: Alex Deucher Reviewed-by: Ken Wang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b506fd68bc4161c8b75628fc605c3ef9896fb07b Author: Rex Zhu Date: Mon Jun 13 17:39:19 2016 +0800 drm/amd/powerplay: fix bug that function parameter was incorect. commit 576b4401b1971fe40be4cfd379430a61cd8426b2 upstream. Wrong value passed to acpi_pcie_perf_request. Signed-off-by: Rex Zhu Reviewed-by: Alex Deucher Reviewed-by: Ken Wang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1cfbbfd091862ed9f8ffca88ff8f5d45ef04c1ba Author: Chris Wilson Date: Tue May 31 22:25:52 2016 +0100 drm: Wrap direct calls to driver->gem_free_object from CMA commit afe705be38f1e65b173868486944377186b9f206 upstream. Since the introduction of (struct_mutex) lockless GEM bo freeing, there are a pair of driver vfuncs for freeing the GEM bo, of which the driver may choose to only implement driver->gem_object_free_unlocked (and so avoid taking the struct_mutex along the free path). However, the CMA GEM helpers were still calling driver->gem_free_object directly, now NULL, and promptly dying on the fancy new lockless drivers. Oops. Robert Foss bisected this to b82caafcf2303 (drm/vc4: Use lockless gem BO free callback) on his vc4 device, but that just serves as an enabler for 9f0ba539d13ae (drm/gem: support BO freeing without dev->struct_mutex). Reported-by: Robert Foss Fixes: 9f0ba539d13ae (drm/gem: support BO freeing without dev->struct_mutex) Signed-off-by: Chris Wilson Cc: Robert Foss Cc: Daniel Vetter Cc: Eric Anholt Cc: Alex Deucher Cc: Lucas Stach Reviewed-by: Daniel Vetter Tested-by: Robert Foss Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 42097937a3f8c62d5e48a84805733e75ef8f7a97 Author: Tomi Valkeinen Date: Tue May 31 15:03:17 2016 +0300 drm: make drm_atomic_set_mode_prop_for_crtc() more reliable commit 6709887c448d1cff51b52d09763c7b834ea5f0be upstream. drm_atomic_set_mode_prop_for_crtc() does not clear the state->mode, so old data may be left there when a new mode is set, possibly causing odd issues. This patch improves the situation by always clearing the state->mode first. Signed-off-by: Tomi Valkeinen Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 0a71862ef55df9cb2b1dc6830774ead4709e09ec Author: Tomi Valkeinen Date: Tue May 31 15:03:15 2016 +0300 drm: add missing drm_mode_set_crtcinfo call commit b201e743f42d143f4bcdcb14587caf7cb1d99229 upstream. When setting mode via MODE_ID property, drm_atomic_set_mode_prop_for_crtc() does not call drm_mode_set_crtcinfo() which possibly causes: "[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't calculate constants, dotclock = 0!" Whether the error is seen depends on the previous data in state->mode, as state->mode is not cleared when setting new mode. This patch adds drm_mode_set_crtcinfo() call to drm_mode_convert_umode(), which is called in both legacy and atomic paths. This should be fine as there's no reason to call drm_mode_convert_umode() without also setting the crtc related fields. drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as that is no longer needed. Signed-off-by: Tomi Valkeinen Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 16a5bc9ccca04d42daee6e4310b2c96f4bfa9c12 Author: Chris Wilson Date: Mon Jul 11 14:46:17 2016 +0100 drm/i915: Update ifdeffery for mutex->owner commit b19240062722c39fa92c99f04cbfd93034625123 upstream. In commit 7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when appropriate") the owner field in the mutex was updated from being dependent upon CONFIG_SMP to using optimistic spin. Update our peek function to suite. Fixes:7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...") Reported-by: Hong Liu Signed-off-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/1468244777-4888-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld (cherry picked from commit 4f074a5393431a7d2cc0de7fcfe2f61d24854628) Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 393d93d25cefb3c9cf269ad44a9ba688d32042af Author: Ville Syrjälä Date: Fri May 13 20:53:56 2016 +0300 drm/i915: Refresh cached DP port register value on resume commit 664a84d2c77cbff2945ed7f96d08afbba42b6293 upstream. During hibernation the cached DP port register value will be left with whatever value we have there when we create the hibernation image. Currently that means the port (and eDP PLL) will be off in the cached value. However when we resume there is no guarantee that the value in the actual register will match the cached value. If i915 isn't loaded in the kernel that loads the hibernation image, the port may well be on (eg. left on by the BIOS). The encoder state readout does the right thing in this case and updates our encoder state to reflect the actual hardware state. However the post-resume modeset will then use the stale cached port register value in intel_dp_link_down() and potentially confuse the hardware. This was caught by the following assert WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184 assert_edp_pll+0x99/0xa0 [i915] eDP PLL state assertion failure (expected on, current off) on account of the eDP PLL getting prematurely turned off when shutting down the port, since the DP_PLL_ENABLE bit wasn't set in the cached register value. Presumably I introduced this problem in commit 6fec76628333 ("drm/i915: Use intel_dp->DP in eDP PLL setup") as before that we didn't update the cached value after shuttting the port down. That's assuming the port got enabled at least once prior to hibernating. If that didn't happen then the cached value would still have been totally out of sync with reality (eg. first boot w/o eDP on, then hibernate, and then resume with eDP on). So, let's fix this properly and refresh the cached register value from the hardware register during resume. DDI platforms shouldn't use the cached value during port disable at least, so shouldn't have this particular issue. They might still have issues if we skip the initial modeset and then try to retrain the link or something. But untangling this DP vs. DDI mess is a bigger topic, so let's jut punt on DDI for now. Cc: Jani Nikula Fixes: 6fec76628333 ("drm/i915: Use intel_dp->DP in eDP PLL setup") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1463162036-27931-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak (cherry picked from commit 64989ca4b27acb026b6496ec21e43bee66f86a5b) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 94516e76083532e8c8390dd1e07bee180f614bd0 Author: Lyude Date: Thu Jun 9 11:58:15 2016 -0400 drm/i915/fbc: Disable on HSW by default for now commit 1e3fa0acfec677e915d7de5ac6e1f18cfa4f805b upstream. >From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : This was kind of a difficult bug to track down. If you're using a Haswell system running GNOME and you have fbc completely enabled and working, playing videos can result in video artifacts. Steps to reproduce: - Run GNOME - Ensure FBC is enabled and active - Download a movie, I used the ogg version of Big Buck Bunny for this - Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin ! glimagesink` in a terminal - Watch for about over a minute, you'll see small horizontal lines go down the screen. For the time being, disable FBC for Haswell by default. Stefan Richter reported kernel freezes (no video artifacts) when fbc is on. (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE applications, thread begins at https://lkml.org/lkml/2016/4/26/813). We also got reports from Steven Honeyman on openbox+roxterm. v2 (From Paulo): - Add extra information to the commit message - Add Fixes tag - Rebase Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96461 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96464 Fixes: a98ee79317b4 ("drm/i915/fbc: enable FBC by default on HSW and BDW") Reviewed-by: Paulo Zanoni Signed-off-by: Lyude Signed-off-by: Paulo Zanoni Link: http://patchwork.freedesktop.org/patch/msgid/1465487895-7401-1-git-send-email-cpaul@redhat.com (cherry picked from commit c7f7e2feffb0294302041507dfd5fc15f01afccc) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit fc26f6e0e1862e72021232fd693819d5d29f6bd5 Author: Lyude Date: Tue Jun 14 11:04:09 2016 -0400 drm/i915/ilk: Don't disable SSC source if it's in use commit 476490a945e1f0f6bd58e303058d2d8ca93a974c upstream. Thanks to Ville Syrjälä for pointing me towards the cause of this issue. Unfortunately one of the sideaffects of having the refclk for a DPLL set to SSC is that as long as it's set to SSC, the GPU will prevent us from powering down any of the pipes or transcoders using it. A couple of BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL configurations. This causes issues on the first modeset, since we don't expect SSC to be left on and as a result, can't successfully power down the pipes or the transcoders using it. Here's an example from this Dell OptiPlex 990: [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled [drm:intel_modeset_init] 2 display pipes available. [drm:intel_update_cdclk] Current CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [drm:intel_crt_reset] crt adpa set to 0xf40000 [drm:intel_dp_init_connector] Adding DP connector on port C [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1 [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0 [drm:ironlake_init_pch_refclk] Disabling SSC entirely … later we try committing the first modeset … [drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A [drm:intel_dump_pipe_config] cpu_transcoder: A … [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07 [drm:intel_dump_pipe_config] planes on this crtc [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258 [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600 [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0 [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0 [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A [drm:intel_disable_pipe] disabling pipe A ------------[ cut here ]------------ WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915] pipe_off wait timed out … ---[ end trace 94fc8aa03ae139e8 ]--- [drm:intel_dp_link_down] [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A Later modesets succeed since they reset the DPLL's configuration anyway, but this is enough to get stuck with a big fat warning in dmesg. A better solution would be to add refcounts for the SSC source, but for now leaving the source clock on should suffice. Changes since v4: - Fix calculation of final for systems with LVDS panels (fixes BUG() on CI test suite) Changes since v3: - Move temp variable into loop - Move checks for using_ssc_source to after we've figured out has_ck505 - Add using_ssc_source to debug output Changes since v2: - Fix debug output for when we disable the CPU source Changes since v1: - Leave the SSC source clock on instead of just shutting it off on all of the DPLL configurations. Reviewed-by: Ville Syrjälä Signed-off-by: Lyude Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1465916649-10228-1-git-send-email-cpaul@redhat.com Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit b3c97aea022236de2ba6bc7f4812f23d088a7df0 Author: Ben Skeggs Date: Wed Jul 6 06:50:36 2016 +1000 drm/nouveau/disp/sor/gf119: select correct sor when poking training pattern commit 217215041b9285af2193a755b56a8f3ed408bfe2 upstream. Fixes a regression caused by a stupid thinko from "disp/sor/gf119: both links use the same training register". Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 757201791dc53f9fff1e094c6ecc5e37cc45481f Author: Dmitrii Tcvetkov Date: Mon Jun 20 13:52:14 2016 +0300 drm/nouveau: fix for disabled fbdev emulation commit 52dfcc5ccfbb6697ac3cac7f7ff1e712760e1216 upstream. Hello, after this commit: commit f045f459d925138fe7d6193a8c86406bda7e49da Author: Ben Skeggs Date: Thu Jun 2 12:23:31 2016 +1000 drm/nouveau/fbcon: fix out-of-bounds memory accesses kernel started to oops when loading nouveau module when using GTX 780 Ti video adapter. This patch fixes the problem. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=120591 Signed-off-by: Dmitrii Tcvetkov Suggested-by: Ilia Mirkin Fixes: f045f459d925 ("nouveau_fbcon_init()") Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit f3c9840b386cd7a59438a47eae5df6b7da585eed Author: Ben Skeggs Date: Fri Jun 3 15:05:52 2016 +1000 drm/nouveau/disp/sor/gm107: training pattern registers are like gm200 commit 4691409b3e2250ed66aa8dcefa23fe765daf7add upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit d91d25ce65ff5f6b98f07a8db89e7f83f4eb64cf Author: Ben Skeggs Date: Thu Jun 2 12:23:31 2016 +1000 drm/nouveau/fbcon: fix out-of-bounds memory accesses commit f045f459d925138fe7d6193a8c86406bda7e49da upstream. Reported by KASAN. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 3ad3daa7d761306cb036e5a149432b793f059d39 Author: Ben Skeggs Date: Fri May 27 12:01:27 2016 +1000 drm/nouveau/ltc/gm107-: fix typo in the address of NV_PLTCG_LTC0_LTS0_INTR commit 9057c8d75018f05bbc769d7b4602de3b8b20f8aa upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 2618f6cb55246bb84557a881e7d0c4bc4213f23f Author: Ben Skeggs Date: Wed Jun 1 16:20:10 2016 +1000 drm/nouveau/gr/gf100-: update sm error decoding from gk20a nvgpu headers commit 383d0a419f8e63e3d65e706c3c515fa9505ce364 upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit f6a9e388a22eb4c0d2cde21be3f02711716cb01a Author: Ben Skeggs Date: Fri Jun 3 14:37:40 2016 +1000 drm/nouveau/disp/sor/gf119: both links use the same training register commit a8953c52b95167b5d21a66f0859751570271d834 upstream. It appears that, for whatever reason, both link A and B use the same register to control the training pattern. It's a little odd, as the GPUs before this (Tesla/Fermi1) have per-link registers, as do newer GPUs (Maxwell). Fixes the third DP output on NVS 510 (GK107). Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 697de5db027e6a83a21ed3a19e1d2f7d1e0bbc43 Author: Ben Skeggs Date: Wed May 25 10:56:24 2016 +1000 drm/nouveau/bios/disp: fix handling of "match any protocol" entries commit bc9139d23f6b038e32bcd2dffdee70a8d76b3976 upstream. As it turns out, a value of 0xff means "any protocol" and not "VGA". Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 81f0444341a04dbc467225ff04cbe62db9eaf195 Author: Michael S. Tsirkin Date: Tue May 17 13:31:18 2016 +0300 virtio_balloon: fix PFN format for virtio-1 commit 87c9403b0d1de4676b0bd273eea68fcf6de68e68 upstream. Everything should be LE when using virtio-1, but the linux balloon driver does not seem to care about that. Reported-by: Cornelia Huck Signed-off-by: Michael S. Tsirkin Tested-by: Cornelia Huck Reviewed-by: Cornelia Huck Signed-off-by: Greg Kroah-Hartman commit 1501cf9c3c0bba712bbd41c825322603f24c07c1 Author: Andrey Grodzovsky Date: Wed May 25 16:45:43 2016 -0400 drm/dp/mst: Always clear proposed vcpi table for port. commit fd2d2bac6e79b0be91ab86a6075a0c46ffda658a upstream. Not clearing mst manager's proposed vcpis table for destroyed connectors when the manager is stopped leaves it pointing to unrefernced memory, this causes pagefault when the manager is restarted when plugging back a branch. Fixes: 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction") Signed-off-by: Andrey Grodzovsky Reviewed-by: Lyude Cc: Mykola Lysenko Cc: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e782f209b1076e1c552067d9a2d65e7f7aae2e2e Author: Oded Gabbay Date: Thu May 26 08:41:48 2016 +0300 drm/amdkfd: destroy dbgmgr in notifier release commit bc4755a4bd1845ef6e88ac8c62f12e05bb530256 upstream. amdkfd need to destroy the debug manager in case amdkfd's notifier function is called before the unbind function, because in that case, the unbind function will exit without destroying debug manager. Signed-off-by: Oded Gabbay Signed-off-by: Greg Kroah-Hartman commit 9ba7cca56a51eba95fbf655cad13cd74188e4683 Author: Oded Gabbay Date: Thu May 26 08:41:08 2016 +0300 drm/amdkfd: unbind only existing processes commit 121b78e679ee3ffab780115e260b2775d0cc1f73 upstream. When unbinding a process from a device (initiated by amd_iommu_v2), the driver needs to make sure that process still exists in the process table. There is a possibility that amdkfd's own notifier handler - kfd_process_notifier_release() - was called before the unbind function and it already removed the process from the process table. v2: Because there can be only one process with the specified pasid, and because *p can't be NULL inside the hash_for_each_rcu macro, it is more reasonable to just put the whole code inside the if statement that compares the pasid value. That way, when we exit hash_for_each_rcu, we simply exit the function as well. Signed-off-by: Oded Gabbay Signed-off-by: Greg Kroah-Hartman commit 6252b14d945c5cd12e61f9e9af10c8071d9aa4db Author: Richard Weinberger Date: Tue Jun 21 00:31:50 2016 +0200 ubi: Make recover_peb power cut aware commit 972228d87445dc46c0a01f5f3de673ac017626f7 upstream. recover_peb() was never power cut aware, if a power cut happened right after writing the VID header upon next attach UBI would blindly use the new partial written PEB and all data from the old PEB is lost. In order to make recover_peb() power cut aware, write the new VID with a proper crc and copy_flag set such that the UBI attach process will detect whether the new PEB is completely written or not. We cannot directly use ubi_eba_atomic_leb_change() since we'd have to unlock the LEB which is facing a write error. Reported-by: Jörg Pfähler Reviewed-by: Jörg Pfähler Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 3d14a5756dfc1a50a8615efa55bdf1a32be88781 Author: Nicolas Iooss Date: Sat Jun 18 22:55:00 2016 +0200 drm/amdgpu: initialize amdgpu_cgs_acpi_eval_object result value commit 29b9c528b8c295911e8b1e515273e89a2b7fa2d8 upstream. amdgpu_cgs_acpi_eval_object() returned the value of variable "result" without initializing it first. This bug has been found by compiling the kernel with clang. The compiler complained: drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:972:14: error: variable 'result' is used uninitialized whenever 'for' loop exits because its condition is false [-Werror,-Wsometimes-uninitialized] for (i = 0; i < count; i++) { ^~~~~~~~~ drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:1011:9: note: uninitialized use occurs here return result; ^~~~~~ drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:972:14: note: remove the condition if it is always true for (i = 0; i < count; i++) { ^~~~~~~~~ drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:864:12: note: initialize the variable 'result' to silence this warning int result; ^ = 0 Fixes: 3f1d35a03b3c ("drm/amdgpu: implement new cgs interface for acpi function") Signed-off-by: Nicolas Iooss Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8c37607b417d7b26c9c5776cb44f694c759cfe41 Author: Alex Deucher Date: Fri Jun 17 10:17:17 2016 -0400 drm/amdgpu: fix num_rbs exposed to userspace (v2) commit 0b10029d826ed8c18a5f9d2f4abfa415d15cd1d3 upstream. This was accidently broken for harvest cards when the code was refactored for Polaris support. v2: multiply by shader engines. Noticed by Nicolai. Reviewed-by: Nicolai Hähnle Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c3b568f8dc376679a6bca424b1708b72b2ab462f Author: Alex Deucher Date: Mon Jun 13 18:26:24 2016 -0400 drm/amdgpu/gfx7: fix broken condition check commit 8b18300c13a1e08e152f6b6a430faac84f986231 upstream. Wrong operator. Reported-by: David Binderman Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 24b37a769e0c8e9ca94282b233c73a1a1370a8b7 Author: Alex Deucher Date: Mon Jun 13 15:37:34 2016 -0400 drm/radeon: fix asic initialization for virtualized environments commit 05082b8bbd1a0ffc74235449c4b8930a8c240f85 upstream. When executing in a PCI passthrough based virtuzliation environment, the hypervisor will usually attempt to send a PCIe bus reset signal to the ASIC when the VM reboots. In this scenario, the card is not correctly initialized, but we still consider it to be posted. Therefore, in a passthrough based environemnt we should always post the card to guarantee it is in a good state for driver initialization. Ported from amdgpu commit: amdgpu: fix asic initialization for virtualized environments Cc: Andres Rodriguez Cc: Alex Williamson Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ba797a4f30a16cfc7337e86a8711996aa91b5f2a Author: Jeff Mahoney Date: Wed Jun 8 00:36:38 2016 -0400 btrfs: account for non-CoW'd blocks in btrfs_abort_transaction commit 64c12921e11b3a0c10d088606e328c58e29274d8 upstream. The test for !trans->blocks_used in btrfs_abort_transaction is insufficient to determine whether it's safe to drop the transaction handle on the floor. btrfs_cow_block, informed by should_cow_block, can return blocks that have already been CoW'd in the current transaction. trans->blocks_used is only incremented for new block allocations. If an operation overlaps the blocks in the current transaction entirely and must abort the transaction, we'll happily let it clean up the trans handle even though it may have modified the blocks and will commit an incomplete operation. In the long-term, I'd like to do closer tracking of when the fs is actually modified so we can still recover as gracefully as possible, but that approach will need some discussion. In the short term, since this is the only code using trans->blocks_used, let's just switch it to a bool indicating whether any blocks were used and set it when should_cow_block returns false. Signed-off-by: Jeff Mahoney Reviewed-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 05f18e6f0077123cae5533b9958a7a0ca40bfdf6 Author: Tejun Heo Date: Wed May 25 11:48:25 2016 -0400 percpu: fix synchronization between synchronous map extension and chunk destruction commit 6710e594f71ccaad8101bc64321152af7cd9ea28 upstream. For non-atomic allocations, pcpu_alloc() can try to extend the area map synchronously after dropping pcpu_lock; however, the extension wasn't synchronized against chunk destruction and the chunk might get freed while extension is in progress. This patch fixes the bug by putting most of non-atomic allocations under pcpu_alloc_mutex to synchronize against pcpu_balance_work which is responsible for async chunk management including destruction. Signed-off-by: Tejun Heo Reported-and-tested-by: Alexei Starovoitov Reported-by: Vlastimil Babka Reported-by: Sasha Levin Fixes: 1a4d76076cda ("percpu: implement asynchronous chunk population") Signed-off-by: Greg Kroah-Hartman commit 5825418a1516dd978aff837b4ab8acd81aa10689 Author: Tejun Heo Date: Wed May 25 11:48:25 2016 -0400 percpu: fix synchronization between chunk->map_extend_work and chunk destruction commit 4f996e234dad488e5d9ba0858bc1bae12eff82c3 upstream. Atomic allocations can trigger async map extensions which is serviced by chunk->map_extend_work. pcpu_balance_work which is responsible for destroying idle chunks wasn't synchronizing properly against chunk->map_extend_work and may end up freeing the chunk while the work item is still in flight. This patch fixes the bug by rolling async map extension operations into pcpu_balance_work. Signed-off-by: Tejun Heo Reported-and-tested-by: Alexei Starovoitov Reported-by: Vlastimil Babka Reported-by: Sasha Levin Fixes: 9c824b6a172c ("percpu: make sure chunk->map array has available space") Signed-off-by: Greg Kroah-Hartman commit d808791ed068f7dabcc54fe07f07636fa436ddbb Author: Miklos Szeredi Date: Fri May 20 22:13:45 2016 +0200 af_unix: fix hard linked sockets on overlay commit eb0a4a47ae89aaa0674ab3180de6a162f3be2ddf upstream. Overlayfs uses separate inodes even in the case of hard links on the underlying filesystems. This is a problem for AF_UNIX socket implementation which indexes sockets based on the inode. This resulted in hard linked sockets not working. The fix is to use the real, underlying inode. Test case follows: -- ovl-sock-test.c -- #include #include #include #include #define SOCK "test-sock" #define SOCK2 "test-sock2" int main(void) { int fd, fd2; struct sockaddr_un addr = { .sun_family = AF_UNIX, .sun_path = SOCK, }; struct sockaddr_un addr2 = { .sun_family = AF_UNIX, .sun_path = SOCK2, }; unlink(SOCK); unlink(SOCK2); if ((fd = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) err(1, "socket"); if (bind(fd, (struct sockaddr *) &addr, sizeof(addr)) == -1) err(1, "bind"); if (listen(fd, 0) == -1) err(1, "listen"); if (link(SOCK, SOCK2) == -1) err(1, "link"); if ((fd2 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) err(1, "socket"); if (connect(fd2, (struct sockaddr *) &addr2, sizeof(addr2)) == -1) err (1, "connect"); return 0; } ---- Reported-by: Alexander Morozov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 8b8b6b53d323131ee70ec817ac3b2a360ecaa65e Author: Miklos Szeredi Date: Fri May 20 22:13:45 2016 +0200 vfs: add d_real_inode() helper commit a118084432d642eeccb961c7c8cc61525a941fcb upstream. Needed by the following fix. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 2ce30374d2e2e1d063cc7c1a896ee835ec112b5b Author: James Morse Date: Mon Jun 20 18:28:01 2016 +0100 arm64: kernel: Save and restore UAO and addr_limit on exception entry commit e19a6ee2460bdd0d0055a6029383422773f9999a upstream. If we take an exception while at EL1, the exception handler inherits the original context's addr_limit and PSTATE.UAO values. To be consistent always reset addr_limit and PSTATE.UAO on (re-)entry to EL1. This prevents accidental re-use of the original context's addr_limit. Based on a similar patch for arm from Russell King. Acked-by: Will Deacon Reviewed-by: Mark Rutland Signed-off-by: James Morse Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit bd1e0058614563ba855974bf7c65da2f21124df5 Author: Shaokun Zhang Date: Tue Jun 21 15:32:57 2016 +0800 arm64: mm: remove page_mapping check in __sync_icache_dcache commit 20c27a4270c775d7ed661491af8ac03264d60fc6 upstream. __sync_icache_dcache unconditionally skips the cache maintenance for anonymous pages, under the assumption that flushing is only required in the presence of D-side aliases [see 7249b79f6b4cc ("arm64: Do not flush the D-cache for anonymous pages")]. Unfortunately, this breaks migration of anonymous pages holding self-modifying code, where userspace cannot be reasonably expected to reissue maintenance instructions in response to a migration. This patch fixes the problem by removing the broken page_mapping(page) check from the cache syncing code, otherwise we may end up fetching and executing stale instructions from the PoU. Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Reviewed-by: Catalin Marinas Signed-off-by: Shaokun Zhang Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit e75da3fe88133b6e6822f9098aabb893e98a799e Author: Mark Rutland Date: Mon Jun 13 11:15:14 2016 +0100 arm64: fix dump_instr when PAN and UAO are in use commit c5cea06be060f38e5400d796e61cfc8c36e52924 upstream. If the kernel is set to show unhandled signals, and a user task does not handle a SIGILL as a result of an instruction abort, we will attempt to log the offending instruction with dump_instr before killing the task. We use dump_instr to log the encoding of the offending userspace instruction. However, dump_instr is also used to dump instructions from kernel space, and internally always switches to KERNEL_DS before dumping the instruction with get_user. When both PAN and UAO are in use, reading a user instruction via get_user while in KERNEL_DS will result in a permission fault, which leads to an Oops. As we have regs corresponding to the context of the original instruction abort, we can inspect this and only flip to KERNEL_DS if the original abort was taken from the kernel, avoiding this issue. At the same time, remove the redundant (and incorrect) comments regarding the order dump_mem and dump_instr are called in. Cc: Catalin Marinas Cc: James Morse Cc: Robin Murphy Signed-off-by: Mark Rutland Reported-by: Vladimir Murzin Tested-by: Vladimir Murzin Fixes: 57f4959bad0a154a ("arm64: kernel: Add support for User Access Override") Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 896f190d1b7a02f78bd7893e4fd8265f37ae619d Author: Robin Murphy Date: Mon Jun 6 16:11:52 2016 +0900 drm/nouveau/Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64" commit 539aae6e3af97c7ec1602ff23e805f2852c2611c upstream. This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50. There is apparently something amiss with the way the TTM code handles DMA buffers, which the above commit was attempting to work around for arm64 systems with non-coherent PCI. Unfortunately, this completely breaks systems *with* coherent PCI (which appear to be the majority). Booting a plain arm64 defconfig + CONFIG_DRM + CONFIG_DRM_NOUVEAU on a machine with a PCI GPU having coherent dma_map_ops (in this case a 7600GT card plugged into an ARM Juno board) results in a fatal crash: [ 2.803438] nouveau 0000:06:00.0: DRM: allocated 1024x768 fb: 0x9000, bo ffffffc976141c00 [ 2.897662] Unable to handle kernel NULL pointer dereference at virtual address 000001ac [ 2.897666] pgd = ffffff8008e00000 [ 2.897675] [000001ac] *pgd=00000009ffffe003, *pud=00000009ffffe003, *pmd=0000000000000000 [ 2.897680] Internal error: Oops: 96000045 [#1] PREEMPT SMP [ 2.897685] Modules linked in: [ 2.897692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5+ #543 [ 2.897694] Hardware name: ARM Juno development board (r1) (DT) [ 2.897699] task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000 [ 2.897711] PC is at __memcpy+0x7c/0x180 [ 2.897719] LR is at OUT_RINGp+0x34/0x70 [ 2.897724] pc : [] lr : [] pstate: 80000045 [ 2.897726] sp : ffffffc9768ab360 [ 2.897732] x29: ffffffc9768ab360 x28: 0000000000000001 [ 2.897738] x27: ffffffc97624c000 x26: 0000000000000000 [ 2.897744] x25: 0000000000000080 x24: 0000000000006c00 [ 2.897749] x23: 0000000000000005 x22: ffffffc97624c010 [ 2.897755] x21: 0000000000000004 x20: 0000000000000004 [ 2.897761] x19: ffffffc9763da000 x18: ffffffc976b2491c [ 2.897766] x17: 0000000000000007 x16: 0000000000000006 [ 2.897771] x15: 0000000000000001 x14: 0000000000000001 [ 2.897777] x13: 0000000000e31b70 x12: ffffffc9768a0080 [ 2.897783] x11: 0000000000000000 x10: fffffffffffffb00 [ 2.897788] x9 : 0000000000000000 x8 : 0000000000000000 [ 2.897793] x7 : 0000000000000000 x6 : 00000000000001ac [ 2.897799] x5 : 00000000ffffffff x4 : 0000000000000000 [ 2.897804] x3 : 0000000000000010 x2 : 0000000000000010 [ 2.897810] x1 : ffffffc97624c010 x0 : 00000000000001ac ... [ 2.898494] Call trace: [ 2.898499] Exception stack(0xffffffc9768ab1a0 to 0xffffffc9768ab2c0) [ 2.898506] b1a0: ffffffc9763da000 0000000000000004 ffffffc9768ab360 ffffff80083465fc [ 2.898513] b1c0: ffffffc976801e00 ffffffc9762b8000 ffffffc9768ab1f0 ffffff80080ec158 [ 2.898520] b1e0: ffffffc9768ab230 ffffff8008496d04 ffffffc975ce6d80 ffffffc9768ab36e [ 2.898527] b200: ffffffc9768ab36f ffffffc9768ab29d ffffffc9768ab29e ffffffc9768a0000 [ 2.898533] b220: ffffffc9768ab250 ffffff80080e70c0 ffffffc9768ab270 ffffff8008496e44 [ 2.898540] b240: 00000000000001ac ffffffc97624c010 0000000000000010 0000000000000010 [ 2.898546] b260: 0000000000000000 00000000ffffffff 00000000000001ac 0000000000000000 [ 2.898552] b280: 0000000000000000 0000000000000000 fffffffffffffb00 0000000000000000 [ 2.898558] b2a0: ffffffc9768a0080 0000000000e31b70 0000000000000001 0000000000000001 [ 2.898566] [] __memcpy+0x7c/0x180 [ 2.898574] [] nv04_fbcon_imageblit+0x1d4/0x2e8 [ 2.898582] [] nouveau_fbcon_imageblit+0xd8/0xe0 [ 2.898591] [] soft_cursor+0x154/0x1d8 [ 2.898598] [] bit_cursor+0x4fc/0x538 [ 2.898605] [] fbcon_cursor+0x134/0x1a8 [ 2.898613] [] hide_cursor+0x38/0xa0 [ 2.898620] [] redraw_screen+0x120/0x228 [ 2.898628] [] fbcon_prepare_logo+0x370/0x3f8 [ 2.898635] [] fbcon_init+0x350/0x560 [ 2.898641] [] visual_init+0xac/0x108 [ 2.898648] [] do_bind_con_driver+0x1c4/0x3a8 [ 2.898655] [] do_take_over_console+0x174/0x1e8 [ 2.898662] [] do_fbcon_takeover+0x74/0x100 [ 2.898669] [] fbcon_event_notify+0x8cc/0x920 [ 2.898680] [] notifier_call_chain+0x50/0x90 [ 2.898685] [] __blocking_notifier_call_chain+0x4c/0x90 [ 2.898691] [] blocking_notifier_call_chain+0x14/0x20 [ 2.898696] [] fb_notifier_call_chain+0x1c/0x28 [ 2.898703] [] register_framebuffer+0x1cc/0x2e0 [ 2.898712] [] drm_fb_helper_initial_config+0x288/0x3e8 [ 2.898719] [] nouveau_fbcon_init+0xe0/0x118 [ 2.898727] [] nouveau_drm_load+0x268/0x890 [ 2.898734] [] drm_dev_register+0xbc/0xc8 [ 2.898740] [] drm_get_pci_dev+0xa0/0x180 [ 2.898747] [] nouveau_drm_probe+0x1a0/0x1e0 [ 2.898755] [] pci_device_probe+0x98/0x110 [ 2.898763] [] driver_probe_device+0x204/0x2b0 [ 2.898770] [] __driver_attach+0xac/0xb0 [ 2.898777] [] bus_for_each_dev+0x60/0xa0 [ 2.898783] [] driver_attach+0x20/0x28 [ 2.898789] [] bus_add_driver+0x1d0/0x238 [ 2.898796] [] driver_register+0x60/0xf8 [ 2.898802] [] __pci_register_driver+0x3c/0x48 [ 2.898809] [] drm_pci_init+0xf4/0x120 [ 2.898818] [] nouveau_drm_init+0x21c/0x230 [ 2.898825] [] do_one_initcall+0x8c/0x190 [ 2.898832] [] kernel_init_freeable+0x14c/0x1f0 [ 2.898839] [] kernel_init+0x10/0x100 [ 2.898845] [] ret_from_fork+0x10/0x40 [ 2.898853] Code: a88120c7 a8c12027 a88120c7 a8c12027 (a88120c7) [ 2.898871] ---[ end trace d5713dcad023ee04 ]--- [ 2.898888] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b In a toss-up between the GPU seeing stale data artefacts on some systems vs. catastrophic kernel crashes on other systems, the latter would seem to take precedence, so revert this change until the real underlying problem can be fixed. Signed-off-by: Robin Murphy Acked-by: Alexandre Courbot [acourbot@nvidia.com: port to Nouveau tree, remove bits in lib/] Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit b6d3c5d06a1c6d72d4a5242c3d204524145b257e Author: Junichi Nomura Date: Fri Jun 10 04:31:52 2016 +0000 ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg() commit ae4ea9a2460c7fee2ae8feeb4dfe96f5f6c3e562 upstream. Commit 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg() for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list. That could lead to following list corruption problems: 1) low-level function treats smi_msg as not connected to list handle_one_recv_msg() could end up calling smi_send(), which assumes the msg is not connected to list. For example, the following sequence could corrupt list by doing list_add_tail() for the entry still connected to other list. handle_new_recv_msgs() msg = list_entry(waiting_rcv_msgs) handle_one_recv_msg(msg) handle_ipmb_get_msg_cmd(msg) smi_send(msg) spin_lock(xmit_msgs_lock) list_add_tail(msg) spin_unlock(xmit_msgs_lock) 2) race between multiple handle_new_recv_msgs() instances handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling handle_one_recv_msg() then retakes the lock and list_del() it. If others call handle_new_recv_msgs() during the window shown below list_del() will be done twice for the same smi_msg. handle_new_recv_msgs() spin_lock(waiting_rcv_msgs_lock) msg = list_entry(waiting_rcv_msgs) spin_unlock(waiting_rcv_msgs_lock) | | handle_one_recv_msg(msg) | spin_lock(waiting_rcv_msgs_lock) list_del(msg) spin_unlock(waiting_rcv_msgs_lock) Fixes: 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces") Signed-off-by: Jun'ichi Nomura [Added a comment to describe why this works.] Signed-off-by: Corey Minyard Tested-by: Ye Feng Signed-off-by: Greg Kroah-Hartman commit c62d5ac161af8698d5e54febb112ab21e8cb3f1b Author: Stefan Agner Date: Fri Jun 3 14:21:34 2016 -0700 drm/fsl-dcu: use flat regmap cache commit ce492b3b8f99cf9d2f807ec22d8805c996a09503 upstream. Using flat regmap cache instead of RB-tree to avoid the following lockdep warning on driver load: WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755 lockdep_trace_alloc+0x15c/0x160() DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) The RB-tree regmap cache needs to allocate new space on first writes. However, allocations in an atomic context (e.g. when a spinlock is held) are not allowed. The function regmap_write calls map->lock, which acquires a spinlock in the fast_io case. Since the FSL DCU driver uses MMIO, the regmap bus of type regmap_mmio is being used which has fast_io set to true. Use flat regmap cache and specify max register to be large enouth to cover all registers available in LS1021a and Vybrids register space. Signed-off-by: Stefan Agner Cc: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6d3641826ff7ca205a62a01ff50083e954797595 Author: Mathieu Larouche Date: Fri May 27 15:12:50 2016 -0400 drm/mgag200: Black screen fix for G200e rev 4 commit d3922b69617b62bb2509936b68301f837229d9f0 upstream. - Fixed black screen for some resolutions of G200e rev4 - Fixed testm & testn which had predetermined value. Reported-by: Jan Beulich Signed-off-by: Mathieu Larouche Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit dba63efdec9c9d50e2cf37c8ba678f8e823cab9c Author: Vegard Nossum Date: Thu Jul 7 13:41:11 2016 -0700 apparmor: fix oops, validate buffer size in apparmor_setprocattr() commit 30a46a4647fd1df9cf52e43bf467f0d9265096ca upstream. When proc_pid_attr_write() was changed to use memdup_user apparmor's (interface violating) assumption that the setprocattr buffer was always a single page was violated. The size test is not strictly speaking needed as proc_pid_attr_write() will reject anything larger, but for the sake of robustness we can keep it in. SMACK and SELinux look safe to me, but somebody else should probably have a look just in case. Based on original patch from Vegard Nossum modified for the case that apparmor provides null termination. Fixes: bb646cdb12e75d82258c2f2e7746d5952d3e321a Reported-by: Vegard Nossum Cc: Al Viro Cc: John Johansen Cc: Paul Moore Cc: Stephen Smalley Cc: Eric Paris Cc: Casey Schaufler Signed-off-by: John Johansen Reviewed-by: Tyler Hicks Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 592354224cfd414078743efab8670ab7b56a2b0c Author: Joerg Roedel Date: Fri Jul 1 16:42:55 2016 +0200 iommu/amd: Fix unity mapping initialization race commit 522e5cb76d0663c88f96b6a8301451c8efa37207 upstream. There is a race condition in the AMD IOMMU init code that causes requested unity mappings to be blocked by the IOMMU for a short period of time. This results on boot failures and IO_PAGE_FAULTs on some machines. Fix this by making sure the unity mappings are installed before all other DMA is blocked. Fixes: aafd8ba0ca74 ('iommu/amd: Implement add_device and remove_device') Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit a1cf08028ab4288b352423409257f7ac0823f8d3 Author: Joerg Roedel Date: Fri Jun 17 11:29:48 2016 +0200 iommu/vt-d: Enable QI on all IOMMUs before setting root entry commit a4c34ff1c029e90e7d5f8dd8d29b0a93b31c3cb2 upstream. This seems to be required on some X58 chipsets on systems with more than one IOMMU. QI does not work until it is enabled on all IOMMUs in the system. Reported-by: Dheeraj CVR Tested-by: Dheeraj CVR Fixes: 5f0a7f7614a9 ('iommu/vt-d: Make root entry visible for hardware right after allocation') Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit ba785c647866fc9d112e535271243df07d136605 Author: Jean-Philippe Brucker Date: Fri Jun 3 11:50:30 2016 +0100 iommu/arm-smmu: Wire up map_sg for arm-smmu-v3 commit 9aeb26cfc2abc96be42b9df2d0f2dc5d805084ff upstream. The map_sg callback is missing from arm_smmu_ops, but is required by iommu.h. Similarly to most other IOMMU drivers, connect it to default_iommu_map_sg. Signed-off-by: Jean-Philippe Brucker Signed-off-by: Will Deacon Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit e44a3eee06b73c237392c166911f32ff1f00961e Author: John Keeping Date: Wed Jun 1 16:46:10 2016 +0100 iommu/rockchip: Fix zap cache during device attach commit ae8a7910fb0568531033bd6ebe65590f7a4fa6e2 upstream. rk_iommu_command() takes a struct rk_iommu and iterates over the slave MMUs, so this is doubly wrong in that we're passing in the wrong pointer and talking to MMUs that we shouldn't be. Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves") Signed-off-by: John Keeping Tested-by: Heiko Stuebner Reviewed-by: Heiko Stuebner Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 41fa543b014a75e71668177efc421da58728c414 Author: Jiri Slaby Date: Fri Jun 10 10:54:32 2016 +0200 base: make module_create_drivers_dir race-free commit 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 upstream. Modules which register drivers via standard path (driver_register) in parallel can cause a warning: WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename '/module/saa7146/drivers' Modules linked in: hexium_gemini(+) mxb(+) ... ... Call Trace: ... [] sysfs_warn_dup+0x62/0x80 [] sysfs_create_dir_ns+0x77/0x90 [] kobject_add_internal+0xb4/0x340 [] kobject_add+0x68/0xb0 [] kobject_create_and_add+0x31/0x70 [] module_add_driver+0xc3/0xd0 [] bus_add_driver+0x154/0x280 [] driver_register+0x60/0xe0 [] __pci_register_driver+0x60/0x70 [] saa7146_register_extension+0x64/0x90 [saa7146] [] hexium_init_module+0x11/0x1000 [hexium_gemini] ... As can be (mostly) seen, driver_register causes this call sequence: -> bus_add_driver -> module_add_driver -> module_create_drivers_dir The last one creates "drivers" directory in /sys/module/<...>. When this is done in parallel, the directory is attempted to be created twice at the same time. This can be easily reproduced by loading mxb and hexium_gemini in parallel: while :; do modprobe mxb & modprobe hexium_gemini wait rmmod mxb hexium_gemini saa7146_vv saa7146 done saa7146 calls pci_register_driver for both mxb and hexium_gemini, which means /sys/module/saa7146/drivers is to be created for both of them. Fix this by a new mutex in module_create_drivers_dir which makes the test-and-create "drivers" dir atomic. I inverted the condition and removed 'return' to avoid multiple unlocks or a goto. Signed-off-by: Jiri Slaby Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed) Signed-off-by: Greg Kroah-Hartman commit faa84d836ea205dc53942c3d115f73f11227515c Author: Steven Rostedt (Red Hat) Date: Fri Jun 17 16:10:42 2016 -0400 tracing: Handle NULL formats in hold_module_trace_bprintk_format() commit 70c8217acd4383e069fe1898bbad36ea4fcdbdcc upstream. If a task uses a non constant string for the format parameter in trace_printk(), then the trace_printk_fmt variable is set to NULL. This variable is then saved in the __trace_printk_fmt section. The function hold_module_trace_bprintk_format() checks to see if duplicate formats are used by modules, and reuses them if so (saves them to the list if it is new). But this function calls lookup_format() that does a strcmp() to the value (which is now NULL) and can cause a kernel oops. This wasn't an issue till 3debb0a9ddb ("tracing: Fix trace_printk() to print when not using bprintk()") which added "__used" to the trace_printk_fmt variable, and before that, the kernel simply optimized it out (no NULL value was saved). The fix is simply to handle the NULL pointer in lookup_format() and have the caller ignore the value if it was NULL. Link: http://lkml.kernel.org/r/1464769870-18344-1-git-send-email-zhengjun.xing@intel.com Reported-by: xingzhen Acked-by: Namhyung Kim Fixes: 3debb0a9ddb ("tracing: Fix trace_printk() to print when not using bprintk()") Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 3920fceb055b6bd367cb0ac4fbc511c69c5bd57d Author: Allen Hung Date: Thu Jun 23 16:31:30 2016 +0800 HID: multitouch: enable palm rejection for Windows Precision Touchpad commit 6dd2e27a103d716921cc4a1a96a9adc0a8e3ab57 upstream. The usage Confidence is mandary to Windows Precision Touchpad devices. If it is examined in input_mapping on a WIndows Precision Touchpad, a new add quirk MT_QUIRK_CONFIDENCE desgned for such devices will be applied to the device. A touch with the confidence bit is not set is determined as invalid. Tested on Dell XPS13 9343 Reviewed-by: Benjamin Tissoires Tested-by: Andy Lutomirski # XPS 13 9350, BIOS 1.4.3 Signed-off-by: Allen Hung Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 63abc957609314dc68ce2017b4ac685d1c656fa5 Author: Allen Hung Date: Thu Jun 23 16:31:29 2016 +0800 Revert "HID: multitouch: enable palm rejection if device implements confidence usage" commit 62630ea768869beeb1e514b0bf5607a0c9b93d12 upstream. This reverts commit 25a84db15b3f ("HID: multitouch: enable palm rejection if device implements confidence usage") The commit enables palm rejection for Win8 Precision Touchpad devices but the quirk MT_QUIRK_VALID_IS_CONFIDENCE it is using is not working very properly. This quirk is originally designed for some WIn7 touchscreens. Use of this for a Win8 Precision Touchpad will cause unexpected pointer jumping problem. Reviewed-by: Benjamin Tissoires Tested-by: Andy Lutomirski # XPS 13 9350, BIOS 1.4.3 Signed-off-by: Allen Hung Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5618231d6dade641382df9bfb9fa03fac8bbfbd2 Author: Scott Bauer Date: Thu Jun 23 08:59:47 2016 -0600 HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands commit 93a2001bdfd5376c3dc2158653034c20392d15c5 upstream. This patch validates the num_values parameter from userland during the HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter leading to a heap overflow. Signed-off-by: Scott Bauer Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit f956617cf07f2e91fd4804a675112b378da4c22a Author: Oliver Neukum Date: Tue May 31 14:48:15 2016 +0200 HID: elo: kill not flush the work commit ed596a4a88bd161f868ccba078557ee7ede8a6ef upstream. Flushing a work that reschedules itself is not a sensible operation. It needs to be killed. Failure to do so leads to a kernel panic in the timer code. Signed-off-by: Oliver Neukum Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit f846155f9b257fcd4707864f58495f0991b08179 Author: Quentin Casasnovas Date: Sat Jun 18 11:01:05 2016 +0200 KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode. commit ff30ef40deca4658e27b0c596e7baf39115e858f upstream. I couldn't get Xen to boot a L2 HVM when it was nested under KVM - it was getting a GP(0) on a rather unspecial vmread from Xen: (XEN) ----[ Xen-4.7.0-rc x86_64 debug=n Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: e008:[] vmx_get_segment_register+0x14e/0x450 (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor (d1v0) (XEN) rax: ffff82d0801e6288 rbx: ffff83003ffbfb7c rcx: fffffffffffab928 (XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: ffff83000bdd0000 (XEN) rbp: ffff83000bdd0000 rsp: ffff83003ffbfab0 r8: ffff830038813910 (XEN) r9: ffff83003faf3958 r10: 0000000a3b9f7640 r11: ffff83003f82d418 (XEN) r12: 0000000000000000 r13: ffff83003ffbffff r14: 0000000000004802 (XEN) r15: 0000000000000008 cr0: 0000000080050033 cr4: 00000000001526e0 (XEN) cr3: 000000003fc79000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen code around (vmx_get_segment_register+0x14e/0x450): (XEN) 00 00 41 be 02 48 00 00 <44> 0f 78 74 24 08 0f 86 38 56 00 00 b8 08 68 00 (XEN) Xen stack trace from rsp=ffff83003ffbfab0: ... (XEN) Xen call trace: (XEN) [] vmx_get_segment_register+0x14e/0x450 (XEN) [] get_page_from_gfn_p2m+0x165/0x300 (XEN) [] hvmemul_get_seg_reg+0x52/0x60 (XEN) [] hvm_emulate_prepare+0x53/0x70 (XEN) [] handle_mmio+0x2b/0xd0 (XEN) [] emulate.c#_hvm_emulate_one+0x111/0x2c0 (XEN) [] handle_hvm_io_completion+0x274/0x2a0 (XEN) [] __get_gfn_type_access+0xfa/0x270 (XEN) [] timer.c#add_entry+0x4b/0xb0 (XEN) [] timer.c#remove_entry+0x7c/0x90 (XEN) [] hvm_do_resume+0x23/0x140 (XEN) [] vmx_do_resume+0xa7/0x140 (XEN) [] context_switch+0x13b/0xe40 (XEN) [] schedule.c#schedule+0x22e/0x570 (XEN) [] softirq.c#__do_softirq+0x5c/0x90 (XEN) [] domain.c#idle_loop+0x25/0x50 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 1: (XEN) GENERAL PROTECTION FAULT (XEN) [error_code=0000] (XEN) **************************************** Tracing my host KVM showed it was the one injecting the GP(0) when emulating the VMREAD and checking the destination segment permissions in get_vmx_mem_address(): 3) | vmx_handle_exit() { 3) | handle_vmread() { 3) | nested_vmx_check_permission() { 3) | vmx_get_segment() { 3) 0.074 us | vmx_read_guest_seg_base(); 3) 0.065 us | vmx_read_guest_seg_selector(); 3) 0.066 us | vmx_read_guest_seg_ar(); 3) 1.636 us | } 3) 0.058 us | vmx_get_rflags(); 3) 0.062 us | vmx_read_guest_seg_ar(); 3) 3.469 us | } 3) | vmx_get_cs_db_l_bits() { 3) 0.058 us | vmx_read_guest_seg_ar(); 3) 0.662 us | } 3) | get_vmx_mem_address() { 3) 0.068 us | vmx_cache_reg(); 3) | vmx_get_segment() { 3) 0.074 us | vmx_read_guest_seg_base(); 3) 0.068 us | vmx_read_guest_seg_selector(); 3) 0.071 us | vmx_read_guest_seg_ar(); 3) 1.756 us | } 3) | kvm_queue_exception_e() { 3) 0.066 us | kvm_multiple_exception(); 3) 0.684 us | } 3) 4.085 us | } 3) 9.833 us | } 3) + 10.366 us | } Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine Control Structure", I found that we're enforcing that the destination operand is NOT located in a read-only data segment or any code segment when the L1 is in long mode - BUT that check should only happen when it is in protected mode. Shuffling the code a bit to make our emulation follow the specification allows me to boot a Xen dom0 in a nested KVM and start HVM L2 guests without problems. Fixes: f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions") Signed-off-by: Quentin Casasnovas Cc: Eugene Korenevsky Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 77588bda330dc187f2ab20665fc90dc779e67428 Author: James Morse Date: Wed Jun 8 17:24:45 2016 +0100 KVM: arm/arm64: Stop leaking vcpu pid references commit 591d215afcc2f94e8e2c69a63c924c044677eb31 upstream. kvm provides kvm_vcpu_uninit(), which amongst other things, releases the last reference to the struct pid of the task that was last running the vcpu. On arm64 built with CONFIG_DEBUG_KMEMLEAK, starting a guest with kvmtool, then killing it with SIGKILL results (after some considerable time) in: > cat /sys/kernel/debug/kmemleak > unreferenced object 0xffff80007d5ea080 (size 128): > comm "lkvm", pid 2025, jiffies 4294942645 (age 1107.776s) > hex dump (first 32 bytes): > 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > backtrace: > [] create_object+0xfc/0x278 > [] kmemleak_alloc+0x34/0x70 > [] kmem_cache_alloc+0x16c/0x1d8 > [] alloc_pid+0x34/0x4d0 > [] copy_process.isra.6+0x79c/0x1338 > [] _do_fork+0x74/0x320 > [] SyS_clone+0x18/0x20 > [] el0_svc_naked+0x24/0x28 > [] 0xffffffffffffffff On x86 kvm_vcpu_uninit() is called on the path from kvm_arch_destroy_vm(), on arm no equivalent call is made. Add the call to kvm_arch_vcpu_free(). Signed-off-by: James Morse Fixes: 749cf76c5a36 ("KVM: ARM: Initial skeleton to compile KVM support") Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit c091781639fe3e0c3ba683ab302f03673dcb5b4b Author: Christian Borntraeger Date: Mon Jun 13 13:14:56 2016 +0200 KVM: s390/mm: Fix CMMA reset during reboot commit 1c343f7b0e177e8ca7f4d4a5dd1fa790f85abbcc upstream. commit 1e133ab296f ("s390/mm: split arch/s390/mm/pgtable.c") factored out the page table handling code from __gmap_zap and __s390_reset_cmma into ptep_zap_unused and added a simple flag that tells which one of the function (reset or not) is to be made. This also changed the behaviour, as it also zaps unused page table entries on reset. Turns out that this is wrong as s390_reset_cmma uses the page walker, which DOES NOT take the ptl lock. The most simple fix is to not do the zapping part on reset (which uses the walker) Signed-off-by: Christian Borntraeger Fixes: 1e133ab296f ("s390/mm: split arch/s390/mm/pgtable.c") Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 95fddb6a6dedae452d317705f897304ee2ff0fa8 Author: Xiubo Li Date: Wed Jun 15 18:00:33 2016 +0800 kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES commit caf1ff26e1aa178133df68ac3d40815fed2187d9 upstream. These days, we experienced one guest crash with 8 cores and 3 disks, with qemu error logs as bellow: qemu-system-x86_64: /build/qemu-2.0.0/kvm-all.c:984: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. And then we found one patch(bdf026317d) in qemu tree, which said could fix this bug. Execute the following script will reproduce the BUG quickly: irq_affinity.sh ======================================================================== vda_irq_num=25 vdb_irq_num=27 while [ 1 ] do for irq in {1,2,4,8,10,20,40,80} do echo $irq > /proc/irq/$vda_irq_num/smp_affinity echo $irq > /proc/irq/$vdb_irq_num/smp_affinity dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct done done ======================================================================== The following qemu log is added in the qemu code and is displayed when this bug reproduced: kvm_irqchip_commit_routes: max gsi: 1008, nr_allocated_irq_routes: 1024, irq_routes->nr: 1024, gsi_count: 1024. That's to say when irq_routes->nr == 1024, there are 1024 routing entries, but in the kernel code when routes->nr >= 1024, will just return -EINVAL; The nr is the number of the routing entries which is in of [1 ~ KVM_MAX_IRQ_ROUTES], not the index in [0 ~ KVM_MAX_IRQ_ROUTES - 1]. This patch fix the BUG above. Signed-off-by: Xiubo Li Signed-off-by: Wei Tang Signed-off-by: Zhang Zhuoyu Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c91ef8db9c022bd3368209540469a9f35132252a Author: Yang Zhang Date: Mon Jun 13 09:56:56 2016 +0800 kvm: vmx: check apicv is active before using VT-d posted interrupt commit a0052191624e9bf8a8f9dc41b92ab5f252566c3c upstream. VT-d posted interrupt is relying on the CPU side's posted interrupt. Need to check whether VCPU's APICv is active before enabing VT-d posted interrupt. Fixes: d62caabb41f33d96333f9ef15e09cd26e1c12760 Signed-off-by: Yang Zhang Signed-off-by: Shengge Ding Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d8498ead3d50eb6cd1f5bf31b924ac927e89ee85 Author: Dan Carpenter Date: Thu Jun 16 15:48:57 2016 +0100 KEYS: potential uninitialized variable commit 38327424b40bcebe2de92d07312c89360ac9229a upstream. If __key_link_begin() failed then "edit" would be uninitialized. I've added a check to fix that. This allows a random user to crash the kernel, though it's quite difficult to achieve. There are three ways it can be done as the user would have to cause an error to occur in __key_link(): (1) Cause the kernel to run out of memory. In practice, this is difficult to achieve without ENOMEM cropping up elsewhere and aborting the attempt. (2) Revoke the destination keyring between the keyring ID being looked up and it being tested for revocation. In practice, this is difficult to time correctly because the KEYCTL_REJECT function can only be used from the request-key upcall process. Further, users can only make use of what's in /sbin/request-key.conf, though this does including a rejection debugging test - which means that the destination keyring has to be the caller's session keyring in practice. (3) Have just enough key quota available to create a key, a new session keyring for the upcall and a link in the session keyring, but not then sufficient quota to create a link in the nominated destination keyring so that it fails with EDQUOT. The bug can be triggered using option (3) above using something like the following: echo 80 >/proc/sys/kernel/keys/root_maxbytes keyctl request2 user debug:fred negate @t The above sets the quota to something much lower (80) to make the bug easier to trigger, but this is dependent on the system. Note also that the name of the keyring created contains a random number that may be between 1 and 10 characters in size, so may throw the test off by changing the amount of quota used. Assuming the failure occurs, something like the following will be seen: kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h ------------[ cut here ]------------ kernel BUG at ../mm/slab.c:2821! ... RIP: 0010:[] kfree_debugcheck+0x20/0x25 RSP: 0018:ffff8804014a7de8 EFLAGS: 00010092 RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000 RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300 RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202 R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001 ... Call Trace: kfree+0xde/0x1bc assoc_array_cancel_edit+0x1f/0x36 __key_link_end+0x55/0x63 key_reject_and_link+0x124/0x155 keyctl_reject_key+0xb6/0xe0 keyctl_negate_key+0x10/0x12 SyS_keyctl+0x9f/0xe7 do_syscall_64+0x63/0x13a entry_SYSCALL64_slow_path+0x25/0x25 Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()') Signed-off-by: Dan Carpenter Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2ac4d627cd27cfee683add65ad972de71e4df5c1 Author: Martin KaFai Lau Date: Tue Jul 5 12:10:23 2016 -0700 ipv6: Fix mem leak in rt6i_pcpu [ Upstream commit 903ce4abdf374e3365d93bcb3df56c62008835ba ] It was first reported and reproduced by Petr (thanks!) in https://bugzilla.kernel.org/show_bug.cgi?id=119581 free_percpu(rt->rt6i_pcpu) used to always happen in ip6_dst_destroy(). However, after fixing a deadlock bug in commit 9c7370a166b4 ("ipv6: Fix a potential deadlock when creating pcpu rt"), free_percpu() is not called before setting non_pcpu_rt->rt6i_pcpu to NULL. It is worth to note that rt6i_pcpu is protected by table->tb6_lock. kmemleak somehow did not report it. We nailed it down by observing the pcpu entries in /proc/vmallocinfo (first suggested by Hannes, thanks!). Signed-off-by: Martin KaFai Lau Fixes: 9c7370a166b4 ("ipv6: Fix a potential deadlock when creating pcpu rt") Reported-by: Petr Novopashenniy Tested-by: Petr Novopashenniy Acked-by: Hannes Frederic Sowa Cc: Hannes Frederic Sowa Cc: Petr Novopashenniy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 33884dbad2725a3e45e010f8d2e471a73f43c592 Author: Bjørn Mork Date: Sun Jul 3 22:24:50 2016 +0200 cdc_ncm: workaround for EM7455 "silent" data interface [ Upstream commit c086e7096170390594c425114d98172bc9aceb8a ] Several Lenovo users have reported problems with their Sierra Wireless EM7455 modem. The driver has loaded successfully and the MBIM management channel has appeared to work, including establishing a connection to the mobile network. But no frames have been received over the data interface. The problem affects all EM7455 and MC7455, and is assumed to affect other modems based on the same Qualcomm chipset and baseband firmware. Testing narrowed the problem down to what seems to be a firmware timing bug during initialization. Adding a short sleep while probing is sufficient to make the problem disappear. Experiments have shown that 1-2 ms is too little to have any effect, while 10-20 ms is enough to reliably succeed. Reported-by: Stefan Armbruster Reported-by: Ralph Plawetzki Reported-by: Andreas Fett Reported-by: Rasmus Lerdorf Reported-by: Samo Ratnik Reported-and-tested-by: Aleksander Morgado Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 309bcd10a7467abcf2b774d3ac289e128360872c Author: Haishuang Yan Date: Sat Jul 2 15:02:48 2016 +0800 geneve: fix max_mtu setting [ Upstream commit d5d5e8d55732c7c35c354e45e3b0af2795978a57 ] For ipv6+udp+geneve encapsulation data, the max_mtu should subtract sizeof(ipv6hdr), instead of sizeof(iphdr). Signed-off-by: Haishuang Yan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 80420d65a62a111162808a2cb10ce242304b6c77 Author: Daniel Borkmann Date: Fri Jul 1 00:00:54 2016 +0200 macsec: set actual real device for xmit when !protect_frames [ Upstream commit 79c62220d74a4a3f961a2cb7320da09eebf5daf7 ] Avoid recursions of dev_queue_xmit() to the wrong net device when frames are unprotected, since at that time skb->dev still points to our own macsec dev and unlike macsec_encrypt_finish() dev pointer doesn't get updated to real underlying device. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Signed-off-by: Daniel Borkmann Acked-by: Sabrina Dubroca Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 49729eccc9d7ef545d484fe3d277697fa2701840 Author: WANG Cong Date: Thu Jun 30 10:15:22 2016 -0700 net_sched: fix mirrored packets checksum [ Upstream commit 82a31b9231f02d9c1b7b290a46999d517b0d312a ] Similar to commit 9b368814b336 ("net: fix bridge multicast packet checksum validation") we need to fixup the checksum for CHECKSUM_COMPLETE when pushing skb on RX path. Otherwise we get similar splats. Cc: Jamal Hadi Salim Cc: Tom Herbert Signed-off-by: Cong Wang Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 74a601e604a228bacdb79323ec9667756eb3e162 Author: David S. Miller Date: Fri Jul 1 16:07:50 2016 -0400 packet: Use symmetric hash for PACKET_FANOUT_HASH. [ Upstream commit eb70db8756717b90c01ccc765fdefc4dd969fc74 ] People who use PACKET_FANOUT_HASH want a symmetric hash, meaning that they want packets going in both directions on a flow to hash to the same bucket. The core kernel SKB hash became non-symmetric when the ipv6 flow label and other entities were incorporated into the standard flow hash order to increase entropy. But there are no users of PACKET_FANOUT_HASH who want an assymetric hash, they all want a symmetric one. Therefore, use the flow dissector to compute a flat symmetric hash over only the protocol, addresses and ports. This hash does not get installed into and override the normal skb hash, so this change has no effect whatsoever on the rest of the stack. Reported-by: Eric Leblond Tested-by: Eric Leblond Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 59eca1a4c30d3bc3e3c002dd4cfbc12bc43c1874 Author: Peter Zijlstra Date: Thu Jun 16 10:50:40 2016 +0200 sched/fair: Fix cfs_rq avg tracking underflow commit 8974189222159154c55f24ddad33e3613960521a upstream. As per commit: b7fa30c9cc48 ("sched/fair: Fix post_init_entity_util_avg() serialization") > the code generated from update_cfs_rq_load_avg(): > > if (atomic_long_read(&cfs_rq->removed_load_avg)) { > s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0); > sa->load_avg = max_t(long, sa->load_avg - r, 0); > sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0); > removed_load = 1; > } > > turns into: > > ffffffff81087064: 49 8b 85 98 00 00 00 mov 0x98(%r13),%rax > ffffffff8108706b: 48 85 c0 test %rax,%rax > ffffffff8108706e: 74 40 je ffffffff810870b0 > ffffffff81087070: 4c 89 f8 mov %r15,%rax > ffffffff81087073: 49 87 85 98 00 00 00 xchg %rax,0x98(%r13) > ffffffff8108707a: 49 29 45 70 sub %rax,0x70(%r13) > ffffffff8108707e: 4c 89 f9 mov %r15,%rcx > ffffffff81087081: bb 01 00 00 00 mov $0x1,%ebx > ffffffff81087086: 49 83 7d 70 00 cmpq $0x0,0x70(%r13) > ffffffff8108708b: 49 0f 49 4d 70 cmovns 0x70(%r13),%rcx > > Which you'll note ends up with sa->load_avg -= r in memory at > ffffffff8108707a. So I _should_ have looked at other unserialized users of ->load_avg, but alas. Luckily nikbor reported a similar /0 from task_h_load() which instantly triggered recollection of this here problem. Aside from the intermediate value hitting memory and causing problems, there's another problem: the underflow detection relies on the signed bit. This reduces the effective width of the variables, IOW its effectively the same as having these variables be of signed type. This patch changes to a different means of unsigned underflow detection to not rely on the signed bit. This allows the variables to use the 'full' unsigned range. And it does so with explicit LOAD - STORE to ensure any intermediate value will never be visible in memory, allowing these unserialized loads. Note: GCC generates crap code for this, might warrant a look later. Note2: I say 'full' above, if we end up at U*_MAX we'll still explode; maybe we should do clamping on add too. Signed-off-by: Peter Zijlstra (Intel) Cc: Andrey Ryabinin Cc: Chris Wilson Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Yuyang Du Cc: bsegall@google.com Cc: kernel@kyup.com Cc: morten.rasmussen@arm.com Cc: pjt@google.com Cc: steve.muckle@linaro.org Fixes: 9d89c257dfb9 ("sched/fair: Rewrite runnable load and utilization average tracking") Link: http://lkml.kernel.org/r/20160617091948.GJ30927@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 27bd6fcb3a7facf0beb963c35d8b62d45329771d Author: Kirill A. Shutemov Date: Thu Jun 16 23:26:15 2016 +0200 UBIFS: Implement ->migratepage() commit 4ac1c17b2044a1b4b2fbed74451947e905fc2992 upstream. During page migrations UBIFS might get confused and the following assert triggers: [ 213.480000] UBIFS assert failed in ubifs_set_page_dirty at 1451 (pid 436) [ 213.490000] CPU: 0 PID: 436 Comm: drm-stress-test Not tainted 4.4.4-00176-geaa802524636-dirty #1008 [ 213.490000] Hardware name: Allwinner sun4i/sun5i Families [ 213.490000] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 213.490000] [] (show_stack) from [] (dump_stack+0x8c/0xa0) [ 213.490000] [] (dump_stack) from [] (ubifs_set_page_dirty+0x44/0x50) [ 213.490000] [] (ubifs_set_page_dirty) from [] (try_to_unmap_one+0x10c/0x3a8) [ 213.490000] [] (try_to_unmap_one) from [] (rmap_walk+0xb4/0x290) [ 213.490000] [] (rmap_walk) from [] (try_to_unmap+0x64/0x80) [ 213.490000] [] (try_to_unmap) from [] (migrate_pages+0x328/0x7a0) [ 213.490000] [] (migrate_pages) from [] (alloc_contig_range+0x168/0x2f4) [ 213.490000] [] (alloc_contig_range) from [] (cma_alloc+0x170/0x2c0) [ 213.490000] [] (cma_alloc) from [] (__alloc_from_contiguous+0x38/0xd8) [ 213.490000] [] (__alloc_from_contiguous) from [] (__dma_alloc+0x23c/0x274) [ 213.490000] [] (__dma_alloc) from [] (arm_dma_alloc+0x54/0x5c) [ 213.490000] [] (arm_dma_alloc) from [] (drm_gem_cma_create+0xb8/0xf0) [ 213.490000] [] (drm_gem_cma_create) from [] (drm_gem_cma_create_with_handle+0x1c/0xe8) [ 213.490000] [] (drm_gem_cma_create_with_handle) from [] (drm_gem_cma_dumb_create+0x3c/0x48) [ 213.490000] [] (drm_gem_cma_dumb_create) from [] (drm_ioctl+0x12c/0x444) [ 213.490000] [] (drm_ioctl) from [] (do_vfs_ioctl+0x3f4/0x614) [ 213.490000] [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) [ 213.490000] [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x34) UBIFS is using PagePrivate() which can have different meanings across filesystems. Therefore the generic page migration code cannot handle this case correctly. We have to implement our own migration function which basically does a plain copy but also duplicates the page private flag. UBIFS is not a block device filesystem and cannot use buffer_migrate_page(). Signed-off-by: Kirill A. Shutemov [rw: Massaged changelog, build fixes, etc...] Signed-off-by: Richard Weinberger Acked-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 3eaf687c3f4d40eb70d2227d737f6009380c9e50 Author: Richard Weinberger Date: Thu Jun 16 23:26:14 2016 +0200 mm: Export migrate_page_move_mapping and migrate_page_copy commit 1118dce773d84f39ebd51a9fe7261f9169cb056e upstream. Export these symbols such that UBIFS can implement ->migratepage. Signed-off-by: Richard Weinberger Acked-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit fe5b6d0086f221160173709d3f439d1a5b84ec3c Author: Harvey Hunt Date: Mon May 23 12:05:52 2016 +0100 irqchip/mips-gic: Fix IRQs in gic_dev_domain commit 4b2312bd0592708c85ed94368c874819e7013309 upstream. When allocating a new device IRQ, gic_dev_domain_alloc() correctly calls irq_domain_set_hwirq_and_chip(), but gic_irq_domain_alloc() does not. This means that gic_irq_domain believes all IRQs from the dev domain have an hwirq of 0 and creates incorrect mappings in the linear_revmap. As gic_irq_domain is a parent of the gic_dev_domain, this leads to an inability to boot on devices with a GIC. Excerpt of the error: [ 2.297649] irq 0: nobody cared (try booting with the "irqpoll" option) ... [ 2.436963] handlers: [ 2.439492] Disabling IRQ #0 Fix this by calling irq_domain_set_hwirq_and_chip() for both the dev and irq domain. Now that we are modifying the parent domain, be sure to clear it up in case of an allocation error. Fixes: c98c1822ee13 ("irqchip/mips-gic: Add device hierarchy domain") Fixes: 2af70a962070 ("irqchip/mips-gic: Add a IPI hierarchy domain") Signed-off-by: Harvey Hunt Tested-by: Govindraj Raja # On Pistachio SoC Reviewed-by: Matt Redfearn Cc: linux-mips@linux-mips.org Cc: Qais Yousef Cc: jason@lakedaemon.net Cc: marc.zyngier@arm.com Link: http://lkml.kernel.org/r/1464001552-31174-1-git-send-email-harvey.hunt@imgtec.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ce662f41ba65f1ced510207bac979b63808ae2bd Author: James Hogan Date: Thu Jun 9 10:50:43 2016 +0100 MIPS: KVM: Fix modular KVM under QEMU commit 797179bc4fe06c89e47a9f36f886f68640b423f8 upstream. Copy __kvm_mips_vcpu_run() into unmapped memory, so that we can never get a TLB refill exception in it when KVM is built as a module. This was observed to happen with the host MIPS kernel running under QEMU, due to a not entirely transparent optimisation in the QEMU TLB handling where TLB entries replaced with TLBWR are copied to a separate part of the TLB array. Code in those pages continue to be executable, but those mappings persist only until the next ASID switch, even if they are marked global. An ASID switch happens in __kvm_mips_vcpu_run() at exception level after switching to the guest exception base. Subsequent TLB mapped kernel instructions just prior to switching to the guest trigger a TLB refill exception, which enters the guest exception handlers without updating EPC. This appears as a guest triggered TLB refill on a host kernel mapped (host KSeg2) address, which is not handled correctly as user (guest) mode accesses to kernel (host) segments always generate address error exceptions. Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Ralf Baechle Cc: kvm@vger.kernel.org Cc: linux-mips@linux-mips.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 913ac340cc39b9103f8fdb63e5088ea078230331 Author: Chen-Yu Tsai Date: Wed May 11 13:23:13 2016 +0800 ARM: dts: sun6i: primo81: Drop constraints on dc1sw regulator commit cb84f6c0a25eb76b1f838eb63e212705c0c06b5f upstream. This is the same issue fixed in commit dcf5341f0150 ("ARM: dts: sun8i-q8-common: Do not set constraints on dc1sw regulator"). Commit message copied: dc1sw is an on/off only regulator and as such it cannot have constraints. This is a limitation of the kernel regulator implementation which resolves supplies on the first regulator_get(), which is done after applying constraints, and applying the constrains will fail because it calls _regulator_get_voltage() and _regulator_do_set_voltage() both of which will fail on a switch regulator when there is no supply (yet). This causes registering of all axp22x regulators to fail with the following errors: [ 1.395249] vcc-lcd: failed to get the current voltage(-22) [ 1.405131] axp20x-regulator axp20x-regulator: Failed to register dc1sw [ 1.412436] axp20x-regulator: probe of axp20x-regulator failed with error -22 This commit removes the constrains on dc1sw / vcc-lcd fixing this problem. Note that dcdc1 itself is contrained to the exact same values, so this does not change anything. Cc: Hans de Goede Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit 35af21cafa186f9b745751a16b68117d4f7fa781 Author: Chen-Yu Tsai Date: Wed May 11 13:23:14 2016 +0800 ARM: dts: sun6i: yones-toptech-bs1078-v2: Drop constraints on dc1sw regulator commit b223d6242c372a81cca3bb81998f53d3b3e3fb70 upstream. This is the same issue fixed in commit dcf5341f0150 ("ARM: dts: sun8i-q8-common: Do not set constraints on dc1sw regulator"). Commit message copied: dc1sw is an on/off only regulator and as such it cannot have constraints. This is a limitation of the kernel regulator implementation which resolves supplies on the first regulator_get(), which is done after applying constraints, and applying the constrains will fail because it calls _regulator_get_voltage() and _regulator_do_set_voltage() both of which will fail on a switch regulator when there is no supply (yet). This causes registering of all axp22x regulators to fail with the following errors: [ 1.395249] vcc-lcd: failed to get the current voltage(-22) [ 1.405131] axp20x-regulator axp20x-regulator: Failed to register dc1sw [ 1.412436] axp20x-regulator: probe of axp20x-regulator failed with error -22 This commit removes the constrains on dc1sw / vcc-lcd fixing this problem. Note that dcdc1 itself is contrained to the exact same values, so this does not change anything. Cc: Hans de Goede Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit 577419b34ae600ff74cbcb9b417feb23077fa500 Author: Steve Capper Date: Tue Jun 7 17:58:06 2016 +0100 ARM: 8579/1: mm: Fix definition of pmd_mknotpresent commit 56530f5d2ddc9b9fade7ef8db9cb886e9dc689b5 upstream. Currently pmd_mknotpresent will use a zero entry to respresent an invalidated pmd. Unfortunately this definition clashes with pmd_none, thus it is possible for a race condition to occur if zap_pmd_range sees pmd_none whilst __split_huge_pmd_locked is running too with pmdp_invalidate just called. This patch fixes the race condition by modifying pmd_mknotpresent to create non-zero faulting entries (as is done in other architectures), removing the ambiguity with pmd_none. [catalin.marinas@arm.com: using L_PMD_SECT_VALID instead of PMD_TYPE_SECT] Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.") Reported-by: Kirill A. Shutemov Acked-by: Will Deacon Cc: Russell King Signed-off-by: Steve Capper Signed-off-by: Catalin Marinas Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 39c52b22a0cfc3baaa18b9230bbee704e54a2f10 Author: Will Deacon Date: Tue Jun 7 17:57:54 2016 +0100 ARM: 8578/1: mm: ensure pmd_present only checks the valid bit commit 624531886987f0f1b5d01fb598034d039198e090 upstream. In a subsequent patch, pmd_mknotpresent will clear the valid bit of the pmd entry, resulting in a not-present entry from the hardware's perspective. Unfortunately, pmd_present simply checks for a non-zero pmd value and will therefore continue to return true even after a pmd_mknotpresent operation. Since pmd_mknotpresent is only used for managing huge entries, this is only an issue for the 3-level case. This patch fixes the 3-level pmd_present implementation to take into account the valid bit. For bisectability, the change is made before the fix to pmd_mknotpresent. [catalin.marinas@arm.com: comment update regarding pmd_mknotpresent patch] Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.") Cc: Russell King Cc: Steve Capper Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 02f86e376a4b8b17beecaed6b81ce561c5048d46 Author: Fabio Estevam Date: Wed May 11 16:39:30 2016 -0300 ARM: imx6ul: Fix Micrel PHY mask commit 20c15226d1c73150c4d9107301cac5dda0b7f995 upstream. The value used for Micrel PHY mask is not correct. Use the MICREL_PHY_ID_MASK definition instead. Thanks to Jiri Luznicky for proposing the fix at https://community.freescale.com/thread/387739 Fixes: 709bc0657fe6f9f55 ("ARM: imx6ul: add fec MAC refrence clock and phy fixup init") Signed-off-by: Fabio Estevam Reviewed-by: Andrew Lunn Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit edf508c3d35c9495a39be987a37214f684c2de76 Author: Srinivas Kandagatla Date: Fri Jun 3 12:23:09 2016 +0100 regulator: qcom_smd: add regulator ops for pm8941 lnldo commit d1e44b6b2823f1751ffe7e7589f545f05cfe2095 upstream. After "regulator: qcom_smd: add list_voltage callback" patch adding pm8941 lnldo regulators would bug on list_voltages as it is a fixed regulator without any linear range. This patch fixes that issue by adding dedicated ops for pm8941 lnldo without list_voltages callback. Signed-off-by: Srinivas Kandagatla Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 170d947606f6d54595a3d17fcdf3b0809a48b712 Author: Srinivas Kandagatla Date: Thu Jun 2 11:23:15 2016 +0100 regulator: qcom_smd: add list_voltage callback commit a8a47540ebe32f1733eebc3e5699af580ceaa3f5 upstream. This patch adds support to list_voltage callback, so that consumers like mmc core, can get information of supported voltage range. Without this patch there is no way for mmc core to know this voltage range. Signed-off-by: Srinivas Kandagatla Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ea22632f041a5f6e436ea308aaf7d84aaa6009b1 Author: J. Bruce Fields Date: Tue May 17 12:38:21 2016 -0400 rpc: share one xps between all backchannels commit 39a9beab5acb83176e8b9a4f0778749a09341f1f upstream. The spec allows backchannels for multiple clients to share the same tcp connection. When that happens, we need to use the same xprt for all of them. Similarly, we need the same xps. This fixes list corruption introduced by the multipath code. Signed-off-by: J. Bruce Fields Acked-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 863af7a779f0f0b6f2d49d32c8c23f4dd68507e5 Author: J. Bruce Fields Date: Fri May 20 17:07:17 2016 -0400 SUNRPC: fix xprt leak on xps allocation failure commit 1208fd569c07ab84aa5d024abd863267c2953b4a upstream. Callers of rpc_create_xprt expect it to put the xprt on success and failure. Signed-off-by: J. Bruce Fields Acked-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 71846b99fd7806a5785ec4f7b5dc9d3f63bc3963 Author: Trond Myklebust Date: Sat Jun 25 19:19:28 2016 -0400 NFS: Fix another OPEN_DOWNGRADE bug commit e547f2628327fec6afd2e03b46f113f614cca05b upstream. Olga Kornievskaia reports that the following test fails to trigger an OPEN_DOWNGRADE on the wire, and only triggers the final CLOSE. fd0 = open(foo, RDRW) -- should be open on the wire for "both" fd1 = open(foo, RDONLY) -- should be open on the wire for "read" close(fd0) -- should trigger an open_downgrade read(fd1) close(fd1) The issue is that we're missing a check for whether or not the current state transitioned from an O_RDWR state as opposed to having transitioned from a combination of O_RDONLY and O_WRONLY. Reported-by: Olga Kornievskaia Fixes: cd9288ffaea4 ("NFSv4: Fix another bug in the close/open_downgrade code") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit c45ef6742072e8cdd680233c4b02aa01105f9b4d Author: Al Viro Date: Mon Jun 20 13:14:36 2016 -0400 make nfs_atomic_open() call d_drop() on all ->open_context() errors. commit d20cb71dbf3487f24549ede1a8e2d67579b4632e upstream. In "NFSv4: Move dentry instantiation into the NFSv4-specific atomic open code" unconditional d_drop() after the ->open_context() had been removed. It had been correct for success cases (there ->open_context() itself had been doing dcache manipulations), but not for error ones. Only one of those (ENOENT) got a compensatory d_drop() added in that commit, but in fact it should've been done for all errors. As it is, the case of O_CREAT non-exclusive open on a hashed negative dentry racing with e.g. symlink creation from another client ended up with ->open_context() getting an error and proceeding to call nfs_lookup(). On a hashed dentry, which would've instantly triggered BUG_ON() in d_materialise_unique() (or, these days, its equivalent in d_splice_alias()). Tested-by: Oleg Drokin Signed-off-by: Al Viro Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit e7e4ce1e80cc01b48d14eeda1e7e10b592abdc5c Author: Trond Myklebust Date: Fri Jun 17 16:48:25 2016 -0400 NFS: Fix a double page unlock commit cbebaf897e5c4862567eb799dc84acc5d7ee2678 upstream. Since commit 0bcbf039f6b2, nfs_readpage_release() has been used to unlock the page in the read code. Fixes: 0bcbf039f6b2 ("nfs: handle request add failure properly") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 2c9b6fd1a97c7a791be561b77b9d94563850da9e Author: Weston Andros Adamson Date: Fri Jun 17 16:48:24 2016 -0400 pnfs_nfs: fix _cancel_empty_pagelist commit 5e3a98883e7ebdd1440f829a9e9dd5c3d2c5903b upstream. pnfs_generic_commit_cancel_empty_pagelist calls nfs_commitdata_release, but that is wrong: nfs_commitdata_release puts the open context, something that isn't valid until nfs_init_commit is called, which is never the case when pnfs_generic_commit_cancel_empty_pagelist is called. This was introduced in "nfs: avoid race that crashes nfs_init_commit". Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 46fc4f86b6e73a728aed58eb151e5354626c27b4 Author: Ben Hutchings Date: Wed Jun 22 19:43:35 2016 +0100 nfsd: check permissions when setting ACLs commit 999653786df6954a31044528ac3f7a5dadca08f4 upstream. Use set_posix_acl, which includes proper permission checks, instead of calling ->set_acl directly. Without this anyone may be able to grant themselves permissions to a file by setting the ACL. Lock the inode to make the new checks atomic with respect to set_acl. (Also, nfsd was the only caller of set_acl not locking the inode, so I suspect this may fix other races.) This also simplifies the code, and ensures our ACLs are checked by posix_acl_valid. The permission checks and the inode locking were lost with commit 4ac7249e, which changed nfsd to use the set_acl inode operation directly instead of going through xattr handlers. Reported-by: David Sinquin [agreunba@redhat.com: use set_posix_acl] Fixes: 4ac7249e Cc: Christoph Hellwig Cc: Al Viro Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit a621b910bc891fe605e8b4597fcea414807ea040 Author: Andreas Gruenbacher Date: Wed Jun 22 23:57:25 2016 +0200 posix_acl: Add set_posix_acl commit 485e71e8fb6356c08c7fc6bcce4bf02c9a9a663f upstream. Factor out part of posix_acl_xattr_set into a common function that takes a posix_acl, which nfsd can also call. The prototype already exists in include/linux/posix_acl.h. Signed-off-by: Andreas Gruenbacher Cc: Christoph Hellwig Cc: Al Viro Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit a337d04dba9e1e20191fd1eb150fbb6cccc4b113 Author: Oleg Drokin Date: Tue Jun 14 23:28:05 2016 -0400 nfsd: Extend the mutex holding region around in nfsd4_process_open2() commit 5cc1fb2a093e254b656c64ff24b0b76bed1d34d9 upstream. To avoid racing entry into nfs4_get_vfs_file(). Make init_open_stateid() return with locked stateid to be unlocked by the caller. Signed-off-by: Oleg Drokin Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 9c37c2aec4f0c7c450aa3f92cc0356698bde8c68 Author: Oleg Drokin Date: Tue Jun 14 23:28:04 2016 -0400 nfsd: Always lock state exclusively. commit feb9dad5209280085d5b0c094fa67e7a8d75c81a upstream. It used to be the case that state had an rwlock that was locked for write by downgrades, but for read for upgrades (opens). Well, the problem is if there are two competing opens for the same state, they step on each other toes potentially leading to leaking file descriptors from the state structure, since access mode is a bitmap only set once. Signed-off-by: Oleg Drokin Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 2de09ffe78ed319167f329f79dcefae32221fd55 Author: J. Bruce Fields Date: Mon May 16 17:03:42 2016 -0400 nfsd4/rpc: move backchannel create logic into rpc code commit d50039ea5ee63c589b0434baa5ecf6e5075bb6f9 upstream. Also simplify the logic a bit. Signed-off-by: J. Bruce Fields Acked-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit adae6e9e1e1bdaa416ce2bf433aea6c5d58ee8f5 Author: Martin K. Petersen Date: Thu May 12 22:17:34 2016 -0400 sd: Fix rw_max for devices that report an optimal xfer size commit 6b7e9cde49691e04314342b7dce90c67ad567fcc upstream. For historic reasons, io_opt is in bytes and max_sectors in block layer sectors. This interface inconsistency is error prone and should be fixed. But for 4.4--4.7 let's make the unit difference explicit via a wrapper function. Fixes: d0eb20a863ba ("sd: Optimal I/O size is in bytes, not sectors") Reported-by: Fam Zheng Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Tested-by: Andrew Patterson Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 83649f97cadad20ffb43b891784d10c449dbe535 Author: Tejun Heo Date: Fri May 27 14:34:46 2016 -0400 writeback: use higher precision calculation in domain_dirty_limits() commit 62a584fe05eef1f80ed49a286a29328f1a224fb9 upstream. As vm.dirty_[background_]bytes can't be applied verbatim to multiple cgroup writeback domains, they get converted to percentages in domain_dirty_limits() and applied the same way as vm.dirty_[background]ratio. However, if the specified bytes is lower than 1% of available memory, the calculated ratios become zero and the writeback domain gets throttled constantly. Fix it by using per-PAGE_SIZE instead of percentage for ratio calculations. Also, the updated DIV_ROUND_UP() usages now should yield 1/4096 (0.0244%) as the minimum ratio as long as the specified bytes are above zero. Signed-off-by: Tejun Heo Reported-by: Miao Xie Link: http://lkml.kernel.org/g/57333E75.3080309@huawei.com Fixes: 9fc3a43e1757 ("writeback: separate out domain_dirty_limits()") Reviewed-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Adjusted comment based on Jan's suggestion. Signed-off-by: Jens Axboe commit b988f19a7a1c2674982679d1f764dc16ad250b91 Author: Lukasz Luba Date: Tue May 31 11:32:02 2016 +0100 thermal: cpu_cooling: fix improper order during initialization commit f840ab18bdf2e415dac21d09fbbbd2873111bd48 upstream. The freq_table array is not populated before calling thermal_of_cooling_register. The code which populates the freq table was introduced in commit f6859014. This should be done before registering new thermal cooling device. The log shows effects of this wrong decision. [ 2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34 [ 2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34 Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order") Signed-off-by: Lukasz Luba Acked-by: Javi Merino Acked-by: Viresh Kumar Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman commit c9abd3376c581e18d1878435daf9dcfafc75dd3b Author: Andy Lutomirski Date: Tue May 24 15:13:02 2016 -0700 uvc: Forward compat ioctls to their handlers directly commit a44323e2a8f342848bb77e8e04fcd85fcb91b3b4 upstream. The current code goes through a lot of indirection just to call a known handler. Simplify it: just call the handlers directly. Signed-off-by: Andy Lutomirski Signed-off-by: Greg Kroah-Hartman commit b184a66e847ddd5895c59cff34ec7a369d69067f Author: Larry Finger Date: Sat May 21 11:50:35 2016 -0500 rtlwifi: Fix scheduling while atomic error from commit 49f86ec21c01 commit de26859dcf363d520cc44e59f6dcaf20ebe0aadf upstream. Commit 49f86ec21c01 ("rtlwifi: Change long delays to sleeps") was correct for most cases; however, driver rtl8192ce calls the affected routines while in atomic context. The kernel bug output is as follows: BUG: scheduling while atomic: wpa_supplicant/627/0x00000002 [...] [] __schedule+0x899/0xad0 [] schedule+0x3c/0x90 [] schedule_hrtimeout_range_clock+0xa2/0x120 [] ? hrtimer_init+0x120/0x120 [] ? schedule_hrtimeout_range_clock+0x96/0x120 [] schedule_hrtimeout_range+0x13/0x20 [] usleep_range+0x4f/0x70 [] rtl_rfreg_delay+0x38/0x50 [rtlwifi] [] rtl92c_phy_config_rf_with_headerfile+0xc7/0xe0 [rtl8192ce] To fix this bug, three of the changes from delay to sleep are reverted. Unfortunately, one of the changes involves a delay of 50 msec. The calling code will be modified so that this long delay can be avoided; however, this change is being pushed now to fix the problem in kernel 4.6.0. Fixes: 49f86ec21c01 ("rtlwifi: Change long delays to sleeps") Reported-by: James Feeney Signed-off-by: Larry Finger Cc: James Feeney Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 21eb7f2839e4384550cc1f5132b5590f52405f1d Author: Al Viro Date: Sun Jun 5 00:23:09 2016 -0400 autofs braino fix for do_last() commit e6ec03a25f12b312b7e0c037fe4a6471c4ee5665 upstream. It's an analogue of commit 7500c38a (fix the braino in "namei: massage lookup_slow() to be usable by lookup_one_len_unlocked()"). The same problem (->lookup()-returned unhashed negative dentry just might be an autofs one with ->d_manage() that would wait until the daemon makes it positive) applies in do_last() - we need to do follow_managed() first. Fortunately, remaining callers of follow_managed() are OK - only autofs has that weirdness (negative dentry that does not mean an instant -ENOENT)) and autofs never has its negative dentries hashed, so we can't pick one from a dcache lookup. ->d_manage() is a bloody mess ;-/ Spotted-by: Ian Kent Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 2710687940b78c28ce1200f30a384637bf52723c Author: Johan Hovold Date: Sun Jul 3 18:32:05 2016 +0200 Revert "gpiolib: Split GPIO flags parsing and GPIO configuration" commit 85b03b3033fd4eba82665b3b9902c095a08cc52f upstream. This reverts commit 923b93e451db876d1479d3e4458fce14fec31d1c. Make sure consumers do not overwrite gpio flags for pins that have already been claimed. While adding support for gpio drivers to refuse a request using unsupported flags, the order of when the requested flag was checked and the new flags were applied was reversed to that consumers could overwrite flags for already requested gpios. This not only affects device-tree setups where two drivers could request the same gpio using conflicting configurations, but also allowed user space to clear gpio flags for already claimed pins simply by attempting to export them through the sysfs interface. By for example clearing the FLAG_ACTIVE_LOW flag this way, user space could effectively change the polarity of a signal. Reverting this change obviously prevents gpio drivers from doing sanity checks on the flags in their request callbacks. Fortunately only one recently added driver (gpio-tps65218 in v4.6) appears to do this, and a follow up patch could restore this functionality through a different interface. Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 71ae82e9b250e1bd9258bda8067615364b531eff Author: Colin Pitrat Date: Sat Jun 18 19:05:04 2016 +0100 gpio: sch: Fix Oops on module load on Asus Eee PC 1201 commit 87041a58d3b19455d39baed2a5e5bb43b58fb915 upstream. This fixes the issue descirbe in bug 117531 (https://bugzilla.kernel.org/show_bug.cgi?id=117531). It's a regression introduced in linux 4.5 that causes a Oops at load of gpio_sch and prevents powering off the computer. The issue is that sch_gpio_reg_set is called in sch_gpio_probe before gpio_chip data is initialized with the pointer to the sch_gpio struct. As sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes the Oops. The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a sch_gpio struct directly instead of a gpio_chip, which avoids the call to gpiochip_get_data. Thanks Mika for your patience with me :-) Signed-off-by: Colin Pitrat Acked-by: Alexandre Courbot Acked-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 70e0536488069faa8381a44f9e97a03c6c02e8d3 Author: Linus Walleij Date: Thu Jun 16 11:55:55 2016 +0200 gpio: make library immune to error pointers commit c0a1ecb9f4e208f4b75d88fa9669748e3fd705ab upstream. Most functions that take a GPIO descriptor in need to check the descriptor for IS_ERR(). We do this mostly in the VALIDATE_DESC() macro except for the gpiod_to_irq() function which needs special handling. Reported-by: Grygorii Strashko Reviewed-by: Grygorii Strashko Acked-by: Alexandre Courbot Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 37a34e975688905519568a5f75014d52f4cdfaf5 Author: Roger Quadros Date: Wed Jun 15 11:12:05 2016 +0300 extcon: palmas: Fix boot up state of VBUS when using GPIO detection commit 62e6d1e59c77316768a663d1328390b4cd33801f upstream. If USB cable is connected prior to boot, we don't get any interrupts so we must manually check the VBUS state and report it during probe. If we don't do it then USB controller will never know that peripheral cable was connected till the user unplugs and replugs the cable. Fixes: b7aad8e2685b ("extcon: palmas: Add the support for VBUS detection by using GPIO") Signed-off-by: Roger Quadros Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 2211c1f2168b51d2961b4520b32ab99ab48e6517 Author: Josh Poimboeuf Date: Fri Jul 1 23:02:05 2016 -0500 perf/x86: Fix 32-bit perf user callgraph collection commit fc18822510721fe694d273c5211c71ea52796d76 upstream. A basic perf callgraph record operation causes an immediate panic on a 32-bit kernel compiled with CONFIG_CC_STACKPROTECTOR=y: $ perf record -g ls Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: c0404fbd CPU: 0 PID: 998 Comm: ls Not tainted 4.7.0-rc5+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014 c0dd5967 ff7afe1c 00000086 f41dbc2c c07445a0 464c457f f41dbca8 f41dbc44 c05646f4 f41dbca8 464c457f f41dbca8 464c457f f41dbc54 c04625be c0ce56fc c0404fbd f41dbc88 c0404fbd b74668f0 f41dc000 00000000 c0000000 00000000 Call Trace: [] dump_stack+0x58/0x78 [] panic+0x8e/0x1c6 [] __stack_chk_fail+0x1e/0x30 [] ? perf_callchain_user+0x22d/0x230 [] perf_callchain_user+0x22d/0x230 [] get_perf_callchain+0x1ff/0x270 [] perf_callchain+0x78/0x90 [] perf_prepare_sample+0x24b/0x370 [] perf_event_output_forward+0x24/0x70 [] __perf_event_overflow+0xa0/0x210 [] ? cpu_clock_event_read+0x43/0x50 [] perf_swevent_hrtimer+0x101/0x180 [] ? kmap_atomic_prot+0x35/0x140 [] ? get_page_from_freelist+0x279/0x950 [] ? vma_interval_tree_remove+0x158/0x230 [] ? wp_page_copy.isra.82+0x2f4/0x630 [] ? page_add_file_rmap+0x1d/0x50 [] ? unlock_page+0x61/0x80 [] ? filemap_map_pages+0x305/0x320 [] ? handle_mm_fault+0xb7f/0x1560 [] ? timerqueue_del+0x1b/0x70 [] ? __remove_hrtimer+0x2e/0x60 [] __hrtimer_run_queues+0xcb/0x2a0 [] ? __perf_event_overflow+0x210/0x210 [] hrtimer_interrupt+0x8a/0x180 [] local_apic_timer_interrupt+0x32/0x60 [] smp_apic_timer_interrupt+0x33/0x50 [] apic_timer_interrupt+0x34/0x3c Kernel Offset: disabled ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: c0404fbd The panic is caused by the fact that perf_callchain_user() mistakenly assumes it's 64-bit only and ends up corrupting the stack. Signed-off-by: Josh Poimboeuf Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: 75925e1ad7f5 ("perf/x86: Optimize stack walk user accesses") Link: http://lkml.kernel.org/r/1a547f5077ec30f75f9b57074837c3c80df86e5e.1467432113.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 5e1347c688747a68bf02b4c8ec7abf2a0f77f0b5 Author: Borislav Petkov Date: Thu Jun 16 19:13:49 2016 +0200 x86/amd_nb: Fix boot crash on non-AMD systems commit 1ead852dd88779eda12cb09cc894a03d9abfe1ec upstream. Fix boot crash that triggers if this driver is built into a kernel and run on non-AMD systems. AMD northbridges users call amd_cache_northbridges() and it returns a negative value to signal that we weren't able to cache/detect any northbridges on the system. At least, it should do so as all its callers expect it to do so. But it does return a negative value only when kmalloc() fails. Fix it to return -ENODEV if there are no NBs cached as otherwise, amd_nb users like amd64_edac, for example, which relies on it to know whether it should load or not, gets loaded on systems like Intel Xeons where it shouldn't. Reported-and-tested-by: Tony Battersby Signed-off-by: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1466097230-5333-2-git-send-email-bp@alien8.de Link: https://lkml.kernel.org/r/5761BEB0.9000807@cybernetics.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c49c99f65b5ffa1397a26dc5c8c0a1ca961c2565 Author: Vincent Stehlé Date: Tue May 24 16:53:49 2016 +0200 perf/x86/intel/rapl: Fix pmus free during cleanup commit 275ae411e56f8f900fa364da29c4706f9af4e1f3 upstream. On rapl cleanup path, kfree() is given by mistake the address of the pointer of the structure to free (rapl_pmus->pmus + i). Pass the pointer instead (rapl_pmus->pmus[i]). Fixes: 9de8d686955b "perf/x86/intel/rapl: Convert it to a per package facility" Signed-off-by: Vincent Stehlé Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1464101629-14905-1-git-send-email-vincent.stehle@intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 541421338b0f8dc9ea26b4cd254ad1acd6849ea3 Author: Masami Hiramatsu Date: Sat Jun 11 23:06:53 2016 +0900 kprobes/x86: Clear TF bit in fault on single-stepping commit dcfc47248d3f7d28df6f531e6426b933de94370d upstream. Fix kprobe_fault_handler() to clear the TF (trap flag) bit of the flags register in the case of a fault fixup on single-stepping. If we put a kprobe on the instruction which caused a page fault (e.g. actual mov instructions in copy_user_*), that fault happens on the single-stepping buffer. In this case, kprobes resets running instance so that the CPU can retry execution on the original ip address. However, current code forgets to reset the TF bit. Since this fault happens with TF bit set for enabling single-stepping, when it retries, it causes a debug exception and kprobes can not handle it because it already reset itself. On the most of x86-64 platform, it can be easily reproduced by using kprobe tracer. E.g. # cd /sys/kernel/debug/tracing # echo p copy_user_enhanced_fast_string+5 > kprobe_events # echo 1 > events/kprobes/enable And you'll see a kernel panic on do_debug(), since the debug trap is not handled by kprobes. To fix this problem, we just need to clear the TF bit when resetting running kprobe. Signed-off-by: Masami Hiramatsu Reviewed-by: Ananth N Mavinakayanahalli Acked-by: Steven Rostedt Cc: Alexander Shishkin Cc: Andy Lutomirski Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: systemtap@sourceware.org Link: http://lkml.kernel.org/r/20160611140648.25885.37482.stgit@devbox [ Updated the comments. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 66615932d02aa0a4b0c1f51135c1647a91947949 Author: H. Peter Anvin Date: Tue Apr 5 17:01:33 2016 -0700 x86, build: copy ldlinux.c32 to image.iso commit 9c77679cadb118c0aa99e6f88533d91765a131ba upstream. For newer versions of Syslinux, we need ldlinux.c32 in addition to isolinux.bin to reside on the boot disk, so if the latter is found, copy it, too, to the isoimage tree. Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 94611d6e867fa01d33f2f1c5321e88ca47b5a74f Author: Catalin Marinas Date: Wed Jun 1 18:52:16 2016 +0100 cpuidle: Do not access cpuidle_devices when !CONFIG_CPU_IDLE commit 9bd616e3dbedfc103f158197c8ad93678849b1ed upstream. The cpuidle_devices per-CPU variable is only defined when CPU_IDLE is enabled. Commit c8cc7d4de7a4 ("sched/idle: Reorganize the idle loop") removed the #ifdef CONFIG_CPU_IDLE around cpuidle_idle_call() with the compiler optimising away __this_cpu_read(cpuidle_devices). However, with CONFIG_UBSAN && !CONFIG_CPU_IDLE, this optimisation no longer happens and the kernel fails to link since cpuidle_devices is not defined. This patch introduces an accessor function for the current CPU cpuidle device (returning NULL when !CONFIG_CPU_IDLE) and uses it in cpuidle_idle_call(). Signed-off-by: Catalin Marinas Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 88a7b2532dca4f4850a35ef16016986600e3bad0 Author: Paolo Bonzini Date: Tue Jun 21 18:52:17 2016 +0200 locking/static_key: Fix concurrent static_key_slow_inc() commit 4c5ea0a9cd02d6aa8adc86e100b2a4cff8d614ff upstream. The following scenario is possible: CPU 1 CPU 2 static_key_slow_inc() atomic_inc_not_zero() -> key.enabled == 0, no increment jump_label_lock() atomic_inc_return() -> key.enabled == 1 now static_key_slow_inc() atomic_inc_not_zero() -> key.enabled == 1, inc to 2 return ** static key is wrong! jump_label_update() jump_label_unlock() Testing the static key at the point marked by (**) will follow the wrong path for jumps that have not been patched yet. This can actually happen when creating many KVM virtual machines with userspace LAPIC emulation; just run several copies of the following program: #include #include #include #include int main(void) { for (;;) { int kvmfd = open("/dev/kvm", O_RDONLY); int vmfd = ioctl(kvmfd, KVM_CREATE_VM, 0); close(ioctl(vmfd, KVM_CREATE_VCPU, 1)); close(vmfd); close(kvmfd); } return 0; } Every KVM_CREATE_VCPU ioctl will attempt a static_key_slow_inc() call. The static key's purpose is to skip NULL pointer checks and indeed one of the processes eventually dereferences NULL. As explained in the commit that introduced the bug: 706249c222f6 ("locking/static_keys: Rework update logic") jump_label_update() needs key.enabled to be true. The solution adopted here is to temporarily make key.enabled == -1, and use go down the slow path when key.enabled <= 0. Reported-by: Dmitry Vyukov Signed-off-by: Paolo Bonzini Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 706249c222f6 ("locking/static_keys: Rework update logic") Link: http://lkml.kernel.org/r/1466527937-69798-1-git-send-email-pbonzini@redhat.com [ Small stylistic edits to the changelog and the code. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2f5367e5031cebf0513c96a4736bf7767fce4a7d Author: Peter Zijlstra Date: Wed Jun 8 10:19:51 2016 +0200 locking/qspinlock: Fix spin_unlock_wait() some more commit 2c610022711675ee908b903d242f0b90e1db661f upstream. While this prior commit: 54cf809b9512 ("locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()") ... fixes spin_is_locked() and spin_unlock_wait() for the usage in ipc/sem and netfilter, it does not in fact work right for the usage in task_work and futex. So while the 2 locks crossed problem: spin_lock(A) spin_lock(B) if (!spin_is_locked(B)) spin_unlock_wait(A) foo() foo(); ... works with the smp_mb() injected by both spin_is_locked() and spin_unlock_wait(), this is not sufficient for: flag = 1; smp_mb(); spin_lock() spin_unlock_wait() if (!flag) // add to lockless list // iterate lockless list ... because in this scenario, the store from spin_lock() can be delayed past the load of flag, uncrossing the variables and loosing the guarantee. This patch reworks spin_is_locked() and spin_unlock_wait() to work in both cases by exploiting the observation that while the lock byte store can be delayed, the contender must have registered itself visibly in other state contained in the word. It also allows for architectures to override both functions, as PPC and ARM64 have an additional issue for which we currently have no generic solution. Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Boqun Feng Cc: Davidlohr Bueso Cc: Giovanni Gherdovich Cc: Linus Torvalds Cc: Pan Xinhui Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Waiman Long Cc: Will Deacon Fixes: 54cf809b9512 ("locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 35b47ab53c5c5454713240a28858fb616dea367a Author: Chris Wilson Date: Thu May 26 21:08:17 2016 +0100 locking/ww_mutex: Report recursive ww_mutex locking early commit 0422e83d84ae24b933e4b0d4c1e0f0b4ae8a0a3b upstream. Recursive locking for ww_mutexes was originally conceived as an exception. However, it is heavily used by the DRM atomic modesetting code. Currently, the recursive deadlock is checked after we have queued up for a busy-spin and as we never release the lock, we spin until kicked, whereupon the deadlock is discovered and reported. A simple solution for the now common problem is to move the recursive deadlock discovery to the first action when taking the ww_mutex. Suggested-by: Maarten Lankhorst Signed-off-by: Chris Wilson Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Maarten Lankhorst Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1464293297-19777-1-git-send-email-chris@chris-wilson.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 65d99663eb8bd68c20ccfb753f0a38a5fdea6782 Author: Dr. David Alan Gilbert Date: Fri Jun 3 19:00:59 2016 +0100 x86/msr: Use the proper trace point conditional for writes commit 08dd8cd06ed95625b9e2fac43c78fcb45b7eaf94 upstream. The msr tracing for writes is incorrectly conditional on the read trace. Fixes: 7f47d8cc039f "x86, tracing, perf: Add trace point for MSR accesses" Signed-off-by: Dr. David Alan Gilbert Cc: ak@linux.intel.com Link: http://lkml.kernel.org/r/1464976859-21850-1-git-send-email-dgilbert@redhat.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 424f68c3d4e6b048aa8a855bbe3634d4909b66f6 Author: Sergei Shtylyov Date: Sat May 28 23:02:50 2016 +0300 of: irq: fix of_irq_get[_byname]() kernel-doc commit 3993546646baf1dab5f5c4f7d9bb58f2046fd1c1 upstream. The kernel-doc for the of_irq_get[_byname]() is clearly inadequate in describing the return values -- of_irq_get_byname() is documented better than of_irq_get() but it still doesn't mention that 0 is returned iff irq_create_of_mapping() fails (it doesn't return an error code in this case). Document all possible return value variants, making the writing of the word "IRQ" consistent, while at it... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Fixes: ad69674e73a1 ("of/irq: do irq resolution in platform_get_irq_byname()") Signed-off-by: Sergei Shtylyov Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit b9c5c0044c1db5193a53f10bb0dc6fe72739eea2 Author: Wolfram Sang Date: Mon Jun 6 18:48:38 2016 +0200 of: fix autoloading due to broken modalias with no 'compatible' commit b3c0a4dab7e35a9b6d69c0415641d2280fdefb2b upstream. Because of an improper dereference, a stray 'C' character was output to the modalias when no 'compatible' was specified. This is the case for some old PowerMac drivers which only set the 'name' property. Fix it to let them match again. Reported-by: Mathieu Malaterre Signed-off-by: Wolfram Sang Tested-by: Mathieu Malaterre Cc: Philipp Zabel Cc: Andreas Schwab Fixes: 6543becf26fff6 ("mod/file2alias: make modalias generation safe for cross compiling") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 06eaa264f3d8c870b7f8c17605dfcdfc19538dba Author: Eric W. Biederman Date: Mon Jun 6 15:36:07 2016 -0500 mnt: If fs_fully_visible fails call put_filesystem. commit 97c1df3e54e811aed484a036a798b4b25d002ecf upstream. Add this trivial missing error handling. Fixes: 1b852bceb0d1 ("mnt: Refactor the logic for mounting sysfs and proc in a user namespace") Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 619ca9fb435417803b978efdc2de43ae2b772148 Author: Eric W. Biederman Date: Fri Jun 10 12:21:40 2016 -0500 mnt: Account for MS_RDONLY in fs_fully_visible commit 695e9df010e40f407f4830dc11d53dce957710ba upstream. In rare cases it is possible for s_flags & MS_RDONLY to be set but MNT_READONLY to be clear. This starting combination can cause fs_fully_visible to fail to ensure that the new mount is readonly. Therefore force MNT_LOCK_READONLY in the new mount if MS_RDONLY is set on the source filesystem of the mount. In general both MS_RDONLY and MNT_READONLY are set at the same for mounts so I don't expect any programs to care. Nor do I expect MS_RDONLY to be set on proc or sysfs in the initial user namespace, which further decreases the likelyhood of problems. Which means this change should only affect system configurations by paranoid sysadmins who should welcome the additional protection as it keeps people from wriggling out of their policies. Fixes: 8c6cf9cc829f ("mnt: Modify fs_fully_visible to deal with locked ro nodev and atime") Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit f366536a7d82581b0e6dd6af35cdafeaf6c6a7b6 Author: Eric W. Biederman Date: Fri May 27 14:50:05 2016 -0500 mnt: fs_fully_visible test the proper mount for MNT_LOCKED commit d71ed6c930ac7d8f88f3cef6624a7e826392d61f upstream. MNT_LOCKED implies on a child mount implies the child is locked to the parent. So while looping through the children the children should be tested (not their parent). Typically an unshare of a mount namespace locks all mounts together making both the parent and the slave as locked but there are a few corner cases where other things work. Fixes: ceeb0e5d39fc ("vfs: Ignore unlocked mounts in fs_fully_visible") Reported-by: Seth Forshee Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 2843019b6cabcb8f85b42c91994f4adfda44c21c Author: Oscar Date: Tue Jun 14 14:14:35 2016 +0800 usb: common: otg-fsm: add license to usb-otg-fsm commit ea1d39a31d3b1b6060b6e83e5a29c069a124c68a upstream. Fix warning about tainted kernel because usb-otg-fsm has no license. WARNING: with this patch usb-otg-fsm module can be loaded but then the kernel will hang. Tested with a udoo quad board. Signed-off-by: Oscar Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman commit c25a9f850b2d236725eca3f6392c15615b3f13fe Author: Alan Stern Date: Mon Jun 27 10:23:10 2016 -0400 USB: don't free bandwidth_mutex too early commit ab2a4bf83902c170d29ba130a8abb5f9d90559e1 upstream. The USB core contains a bug that can show up when a USB-3 host controller is removed. If the primary (USB-2) hcd structure is released before the shared (USB-3) hcd, the core will try to do a double-free of the common bandwidth_mutex. The problem was described in graphical form by Chung-Geol Kim, who first reported it: ================================================= At *remove USB(3.0) Storage sequence <1> --> <5> ((Problem Case)) ================================================= VOLD ------------------------------------|------------ (uevent) ________|_________ |<1> | |dwc3_otg_sm_work | |usb_put_hcd | |peer_hcd(kref=2)| |__________________| ________|_________ |<2> | |New USB BUS #2 | | | |peer_hcd(kref=1) | | | --(Link)-bandXX_mutex| | |__________________| | ___________________ | |<3> | | |dwc3_otg_sm_work | | |usb_put_hcd | | |primary_hcd(kref=1)| | |___________________| | _________|_________ | |<4> | | |New USB BUS #1 | | |hcd_release | | |primary_hcd(kref=0)| | | | | |bandXX_mutex(free) |<- |___________________| (( VOLD )) ______|___________ |<5> | | SCSI | |usb_put_hcd | |peer_hcd(kref=0) | |*hcd_release | |bandXX_mutex(free*)|<- double free |__________________| ================================================= This happens because hcd_release() frees the bandwidth_mutex whenever it sees a primary hcd being released (which is not a very good idea in any case), but in the course of releasing the primary hcd, it changes the pointers in the shared hcd in such a way that the shared hcd will appear to be primary when it gets released. This patch fixes the problem by changing hcd_release() so that it deallocates the bandwidth_mutex only when the _last_ hcd structure referencing it is released. The patch also removes an unnecessary test, so that when an hcd is released, both the shared_hcd and primary_hcd pointers in the hcd's peer will be cleared. Signed-off-by: Alan Stern Reported-by: Chung-Geol Kim Tested-by: Chung-Geol Kim Signed-off-by: Greg Kroah-Hartman commit b93dad4c8d8eb9e200a600ee30ca383e6639d031 Author: Alan Stern Date: Thu Jun 23 14:54:37 2016 -0400 USB: EHCI: declare hostpc register as zero-length array commit 7e8b3dfef16375dbfeb1f36a83eb9f27117c51fd upstream. The HOSTPC extension registers found in some EHCI implementations form a variable-length array, with one element for each port. Therefore the hostpc field in struct ehci_regs should be declared as a zero-length array, not a single-element array. This fixes a problem reported by UBSAN. Signed-off-by: Alan Stern Reported-by: Wilfried Klaebe Tested-by: Wilfried Klaebe Signed-off-by: Greg Kroah-Hartman commit 6d1eb7ef8c573a34bfde018fe3c9af2c3b896fc2 Author: Arnd Bergmann Date: Fri May 13 15:52:27 2016 +0200 usb: dwc2: fix regression on big-endian PowerPC/ARM systems commit 23e3439296a55affce3ef0ab78f1c2e03aec8767 upstream. A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq MIPS system unfortunately broke big-endian operation on PowerPC APM82181 as reported by Christian Lamparter, and likely other systems. It actually introduced multiple issues: - it broke big-endian ARM kernels: any machine that was working correctly with a little-endian kernel is no longer using byteswaps on big-endian kernels, which clearly breaks them. - On PowerPC the same thing must be true: if it was working before, using big-endian kernels is now broken. Unlike ARM, 32-bit PowerPC usually uses big-endian kernels, so they are likely all broken. - The barrier for dwc2_writel is on the wrong side of the __raw_writel(), so the MMIO no longer synchronizes with DMA operations. - On architectures that require specific CPU instructions for MMIO access, using the __raw_ variant may turn this into a pointer dereference that does not have the same effect as the readl/writel. This patch is a simple revert for all architectures other than MIPS, in the hope that we can more easily backport it to fix the regression on PowerPC and ARM systems without breaking the Lantiq system again. We should follow this up with a more elaborate change to add runtime detection of endianness, to make sure it also works on all other combinations of architectures and implementations of the usb-dwc2 device. That patch however will be fairly large and not appropriate for backports to stable kernels. Felipe suggested a different approach, using an endianness switching register to always put the device into LE mode, but unfortunately the dwc2 hardware does not provide a generic way to do that. Also, I see no practical way of addressing the problem more generally by patching architecture specific code on MIPS. Fixes: 95c8bc360944 ("usb: dwc2: Use platform endianness when accessing registers") Acked-by: John Youn Tested-by: Christian Lamparter Signed-off-by: Arnd Bergmann Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 5b7ef8eff33ff8b3d87071a5fa463da15ec8a0c0 Author: Cyril Bur Date: Fri Jun 17 14:58:34 2016 +1000 powerpc/tm: Always reclaim in start_thread() for exec() class syscalls commit 8e96a87c5431c256feb65bcfc5aec92d9f7839b6 upstream. Userspace can quite legitimately perform an exec() syscall with a suspended transaction. exec() does not return to the old process, rather it load a new one and starts that, the expectation therefore is that the new process starts not in a transaction. Currently exec() is not treated any differently to any other syscall which creates problems. Firstly it could allow a new process to start with a suspended transaction for a binary that no longer exists. This means that the checkpointed state won't be valid and if the suspended transaction were ever to be resumed and subsequently aborted (a possibility which is exceedingly likely as exec()ing will likely doom the transaction) the new process will jump to invalid state. Secondly the incorrect attempt to keep the transactional state while still zeroing state for the new process creates at least two TM Bad Things. The first triggers on the rfid to return to userspace as start_thread() has given the new process a 'clean' MSR but the suspend will still be set in the hardware MSR. The second TM Bad Thing triggers in __switch_to() as the processor is still transactionally suspended but __switch_to() wants to zero the TM sprs for the new process. This is an example of the outcome of calling exec() with a suspended transaction. Note the first 700 is likely the first TM bad thing decsribed earlier only the kernel can't report it as we've loaded userspace registers. c000000000009980 is the rfid in fast_exception_return() Bad kernel stack pointer 3fffcfa1a370 at c000000000009980 Oops: Bad kernel stack pointer, sig: 6 [#1] CPU: 0 PID: 2006 Comm: tm-execed Not tainted NIP: c000000000009980 LR: 0000000000000000 CTR: 0000000000000000 REGS: c00000003ffefd40 TRAP: 0700 Not tainted MSR: 8000000300201031 CR: 00000000 XER: 00000000 CFAR: c0000000000098b4 SOFTE: 0 PACATMSCRATCH: b00000010000d033 GPR00: 0000000000000000 00003fffcfa1a370 0000000000000000 0000000000000000 GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 00003fff966611c0 0000000000000000 0000000000000000 0000000000000000 NIP [c000000000009980] fast_exception_return+0xb0/0xb8 LR [0000000000000000] (null) Call Trace: Instruction dump: f84d0278 e9a100d8 7c7b03a6 e84101a0 7c4ff120 e8410170 7c5a03a6 e8010070 e8410080 e8610088 e8810090 e8210078 <4c000024> 48000000 e8610178 88ed023b Kernel BUG at c000000000043e80 [verbose debug info unavailable] Unexpected TM Bad Thing exception at c000000000043e80 (msr 0x201033) Oops: Unrecoverable exception, sig: 6 [#2] CPU: 0 PID: 2006 Comm: tm-execed Tainted: G D task: c0000000fbea6d80 ti: c00000003ffec000 task.ti: c0000000fb7ec000 NIP: c000000000043e80 LR: c000000000015a24 CTR: 0000000000000000 REGS: c00000003ffef7e0 TRAP: 0700 Tainted: G D MSR: 8000000300201033 CR: 28002828 XER: 00000000 CFAR: c000000000015a20 SOFTE: 0 PACATMSCRATCH: b00000010000d033 GPR00: 0000000000000000 c00000003ffefa60 c000000000db5500 c0000000fbead000 GPR04: 8000000300001033 2222222222222222 2222222222222222 00000000ff160000 GPR08: 0000000000000000 800000010000d033 c0000000fb7e3ea0 c00000000fe00004 GPR12: 0000000000002200 c00000000fe00000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 c0000000fbea7410 00000000ff160000 GPR24: c0000000ffe1f600 c0000000fbea8700 c0000000fbea8700 c0000000fbead000 GPR28: c000000000e20198 c0000000fbea6d80 c0000000fbeab680 c0000000fbea6d80 NIP [c000000000043e80] tm_restore_sprs+0xc/0x1c LR [c000000000015a24] __switch_to+0x1f4/0x420 Call Trace: Instruction dump: 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020 This fixes CVE-2016-5828. Fixes: bc2a9408fa65 ("powerpc: Hook in new transactional memory code") Signed-off-by: Cyril Bur Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit a630198b127c901c0be68b4d9b4ac212cb1cee69 Author: Michael Ellerman Date: Wed Jun 8 10:01:23 2016 +1000 powerpc/pseries: Fix IBM_ARCH_VEC_NRCORES_OFFSET since POWER8NVL was added commit 2c2a63e301fd19ccae673e79de59b30a232ff7f9 upstream. The recent commit 7cc851039d64 ("powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call") added a new PVR mask & value to the start of the ibm_architecture_vec[] array. However it missed the fact that further down in the array, we hard code the offset of one of the fields, and then at boot use that value to patch the value in the array. This means every update to the array must also update the #define, ugh. This means that on pseries machines we will misreport to firmware the number of cores we support, by a factor of threads_per_core. Fix it for now by updating the #define. Fixes: 7cc851039d64 ("powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 92bac7bf7ea0d3c4e74345fc9378f7ff34ededca Author: Gavin Shan Date: Thu May 26 09:56:07 2016 +1000 powerpc/pseries: Fix PCI config address for DDW commit 8a934efe94347eee843aeea65bdec8077a79e259 upstream. In commit 8445a87f7092 "powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism", the PE address was replaced with the PCI config address in order to remove dependency on EEH. According to PAPR spec, firmware (pHyp or QEMU) should accept "xxBBSSxx" format PCI config address, not "xxxxBBSS" provided by the patch. Note that "BB" is PCI bus number and "SS" is the combination of slot and function number. This fixes the PCI address passed to DDW RTAS calls. Fixes: 8445a87f7092 ("powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism") Reported-by: Guilherme G. Piccoli Signed-off-by: Gavin Shan Tested-by: Guilherme G. Piccoli Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 5adc5149471369da6003ca984aeceddc13cd1a86 Author: Guilherme G. Piccoli Date: Mon Apr 11 16:17:23 2016 -0300 powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism commit 8445a87f7092bc8336ea1305be9306f26b846d93 upstream. Commit 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn") changed the pci_dn struct by removing its EEH-related members. As part of this clean-up, DDW mechanism was modified to read the device configuration address from eeh_dev struct. As a consequence, now if we disable EEH mechanism on kernel command-line for example, the DDW mechanism will fail, generating a kernel oops by dereferencing a NULL pointer (which turns to be the eeh_dev pointer). This patch just changes the configuration address calculation on DDW functions to a manual calculation based on pci_dn members instead of using eeh_dev-based address. No functional changes were made. This was tested on pSeries, both in PHyp and qemu guest. Fixes: 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn") Reviewed-by: Gavin Shan Signed-off-by: Guilherme G. Piccoli Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit c7c108b7f61c3b325435c571d64f44fd2399496e Author: Jason Gunthorpe Date: Wed Jun 8 17:28:29 2016 -0600 IB/mlx4: Properly initialize GRH TClass and FlowLabel in AHs commit 8c5122e45a10a9262f872b53f151a592e870f905 upstream. When this code was reworked for IBoE support the order of assignments for the sl_tclass_flowlabel got flipped around resulting in TClass & FlowLabel being permanently set to 0 in the packet headers. This breaks IB routers that rely on these headers, but only affects kernel users - libmlx4 does this properly for user space. Fixes: fa417f7b520e ("IB/mlx4: Add support for IBoE") Signed-off-by: Jason Gunthorpe Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 68439a76dd421a4aa0663ab19291a91c3f876840 Author: Mike Marciniszyn Date: Wed Jun 22 13:29:33 2016 -0700 IB/rdmavt: Correct qp_priv_alloc() return value test commit c755f4afa66ad3ed98870bd3254f37c47fb2c800 upstream. The current drivers return errors from this calldown wrapped in an ERR_PTR(). The rdmavt code incorrectly tests for NULL. The code is fixed to use IS_ERR() and change ret according to the driver return value. Reviewed-by: Dennis Dalessandro Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 03ea1bce809b176d509d6f5036dcbcbfcb17bf6c Author: Bart Van Assche Date: Fri Mar 25 08:33:16 2016 -0700 IB/cm: Fix a recently introduced locking bug commit 943f44d94aa26bfdcaafc40d3701e24eeb58edce upstream. ib_cm_notify() can be called from interrupt context. Hence do not reenable interrupts unconditionally in cm_establish(). This patch avoids that lockdep reports the following warning: WARNING: CPU: 0 PID: 23317 at kernel/locking/lockdep.c:2624 trace _hardirqs_on_caller+0x112/0x1b0 DEBUG_LOCKS_WARN_ON(current->hardirq_context) Call Trace: [] dump_stack+0x67/0x92 [] __warn+0xc1/0xe0 [] warn_slowpath_fmt+0x4a/0x50 [] trace_hardirqs_on_caller+0x112/0x1b0 [] trace_hardirqs_on+0xd/0x10 [] _raw_spin_unlock_irq+0x27/0x40 [] ib_cm_notify+0x25c/0x290 [ib_cm] [] srpt_qp_event+0xa1/0xf0 [ib_srpt] [] mlx4_ib_qp_event+0x67/0xd0 [mlx4_ib] [] mlx4_qp_event+0x5a/0xc0 [mlx4_core] [] mlx4_eq_int+0x3d8/0xcf0 [mlx4_core] [] mlx4_msi_x_interrupt+0xc/0x20 [mlx4_core] [] handle_irq_event_percpu+0x64/0x100 [] handle_irq_event+0x34/0x60 [] handle_edge_irq+0x6a/0x150 [] handle_irq+0x15/0x20 [] do_IRQ+0x5c/0x110 [] common_interrupt+0x89/0x89 [] blk_run_queue_async+0x37/0x40 [] rq_completed+0x43/0x70 [dm_mod] [] dm_softirq_done+0x176/0x280 [dm_mod] [] blk_done_softirq+0x52/0x90 [] __do_softirq+0x10f/0x230 [] irq_exit+0xa8/0xb0 [] smp_trace_call_function_single_interrupt+0x2e/0x30 [] smp_call_function_single_interrupt+0x9/0x10 [] call_function_single_interrupt+0x89/0x90 Fixes: commit be4b499323bf (IB/cm: Do not queue work to a device that's going away) Signed-off-by: Bart Van Assche Cc: Erez Shitrit Cc: Sean Hefty Cc: Nikolay Borisov Acked-by: Erez Shitrit Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 09b0a8d39f310d8b91f4cbda48a5c31fcdfd063a Author: Max Gurtovoy Date: Mon Jun 6 19:34:39 2016 +0300 IB/core: Fix bit curruption in ib_device_cap_flags structure commit 47355b3cd7d3c9c5226bff7c449b9d269fb17fa6 upstream. ib_device_cap_flags 64-bit expansion caused caps overlapping and made consumers read wrong device capabilities. For example IB_DEVICE_SG_GAPS_REG was falsely read by the iser driver causing it to use a non-existing capability. This happened because signed int becomes sign extended when converted it to u64. Fix this by casting IB_DEVICE_ON_DEMAND_PAGING enumeration to ULL. Fixes: f5aa9159a418 ('IB/core: Add arbitrary sg_list support') Reported-by: Robert LeBlanc Acked-by: Sagi Grimberg Signed-off-by: Max Gurtovoy Signed-off-by: Matan Barak Reviewed-by: Christoph Hellwig Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 6c446f65550a48f975b3352b338352b10a63c47f Author: Mel Gorman Date: Wed Jun 8 14:25:22 2016 +0100 futex: Calculate the futex key based on a tail page for file-based futexes commit 077fa7aed17de5022e44bf07dbaf732078b7b5b2 upstream. Mike Galbraith reported that the LTP test case futex_wake04 was broken by commit 65d8fc777f6d ("futex: Remove requirement for lock_page() in get_futex_key()"). This test case uses futexes backed by hugetlbfs pages and so there is an associated inode with a futex stored on such pages. The problem is that the key is being calculated based on the head page index of the hugetlbfs page and not the tail page. Prior to the optimisation, the page lock was used to stabilise mappings and pin the inode is file-backed which is overkill. If the page was a compound page, the head page was automatically looked up as part of the page lock operation but the tail page index was used to calculate the futex key. After the optimisation, the compound head is looked up early and the page lock is only relied upon to identify truncated pages, special pages or a shmem page moving to swapcache. The head page is looked up because without the page lock, special care has to be taken to pin the inode correctly. However, the tail page is still required to calculate the futex key so this patch records the tail page. On vanilla 4.6, the output of the test case is; futex_wake04 0 TINFO : Hugepagesize 2097152 futex_wake04 1 TFAIL : futex_wake04.c:126: Bug: wait_thread2 did not wake after 30 secs. With the patch applied futex_wake04 0 TINFO : Hugepagesize 2097152 futex_wake04 1 TPASS : Hi hydra, thread2 awake! Fixes: 65d8fc777f6d "futex: Remove requirement for lock_page() in get_futex_key()" Reported-and-tested-by: Mike Galbraith Signed-off-by: Mel Gorman Acked-by: Peter Zijlstra (Intel) Reviewed-by: Davidlohr Bueso Cc: Sebastian Andrzej Siewior Link: http://lkml.kernel.org/r/20160608132522.GM2469@suse.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 01d8238019fbca7b51875f12b68a4ad5519f037f Author: Tony Luck Date: Tue May 31 11:50:28 2016 -0700 EDAC, sb_edac: Fix rank lookup on Broadwell commit c7103f650a11328f28b9fa1c95027db331b7774b upstream. Broadwell made a small change to the rank target register moving the target rank ID field up from bits 16:19 to bits 20:23. Also found that the offset field grew by one bit in the IVY_BRIDGE to HASWELL transition, so fix the RIR_OFFSET() macro too. Signed-off-by: Tony Luck Cc: Aristeu Rozanski Cc: Mauro Carvalho Chehab Cc: linux-edac Link: http://lkml.kernel.org/r/2943fb819b1f7e396681165db9c12bb3df0e0b16.1464735623.git.tony.luck@intel.com Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 34c1416699777268bc753614bf61160a43f4e47c Author: Nicholas Krause Date: Thu May 19 18:45:58 2016 -0400 EDAC: Fix workqueues poll period resetting commit fbedcaf43fba35677c01a4ae51e6f79edf4049ba upstream. After the workqueue cleanup, we're registering workqueues based on the presence of an ->edac_check function. When that is the case, we're setting OP_RUNNING_POLL. But we forgot to check that in edac_mc_reset_delay_period(), leading to: BUG: unable to handle kernel paging request at 0000000000015d10 IP: [ .. ] queued_spin_lock_slowpath PGD 3ffcc8067 PUD 3ffc56067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: ... CPU: 1 PID: 2792 Comm: edactest Not tainted 4.6.0-dirty #1 Hardware name: HP ProLiant MicroServer, BIOS O41 10/01/2013 Stack: Call Trace: ? _raw_spin_lock_irqsave ? lock_timer_base.isra.34 ? del_timer ? try_to_grab_pending ? mod_delayed_work_on ? edac_mc_reset_delay_period ? edac_set_poll_msec ? param_attr_store ? module_attr_store ? kernfs_fop_write ? __vfs_write ? __vfs_read ? __alloc_fd ? vfs_write ? SyS_write ? entry_SYSCALL_64_fastpath Code: RIP [ .. ] queued_spin_lock_slowpath RSP <> CR2: 0000000000015d10 ---[ end trace 3f286bc71cca15d1 ]--- Kernel panic - not syncing: Fatal exception Fix it. Signed-off-by: Nicholas Krause Cc: Mauro Carvalho Chehab Cc: linux-edac Link: http://lkml.kernel.org/r/1463697958-13406-1-git-send-email-xerofoify@gmail.com [ Rewrite commit message. ] Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit ac2b80507d990bcc2d682cc1506741afcbcf2904 Author: Felix Fietkau Date: Wed Jun 29 10:36:39 2016 +0200 cfg80211: fix proto in ieee80211_data_to_8023 for frames without LLC header commit c041778c966c92c964033f1cdfee60a9f2b5e465 upstream. The PDU length of incoming LLC frames is set to the total skb payload size in __ieee80211_data_to_8023() of net/wireless/util.c which incorrectly includes the length of the IEEE 802.11 header. The resulting LLC frame header has a too large PDU length, causing the llc_fixup_skb() function of net/llc/llc_input.c to reject the incoming skb, effectively breaking STP. Solve the problem by properly substracting the IEEE 802.11 frame header size from the PDU length, allowing the LLC processor to pick up the incoming control messages. Special thanks to Gerry Rozema for tracking down the regression and proposing a suitable patch. Fixes: 2d1c304cb2d5 ("cfg80211: add function for 802.3 conversion with separate output buffer") Reported-by: Gerry Rozema Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 18c1df61dd764c2dcd97a90af91ac5a64ad95fd6 Author: Jouni Malinen Date: Sun Jun 19 23:51:02 2016 +0300 mac80211: Fix mesh estab_plinks counting in STA removal case commit 126e7557328a1cd576be4fca95b133a2695283ff upstream. If a user space program (e.g., wpa_supplicant) deletes a STA entry that is currently in NL80211_PLINK_ESTAB state, the number of established plinks counter was not decremented and this could result in rejecting new plink establishment before really hitting the real maximum plink limit. For !user_mpm case, this decrementation is handled by mesh_plink_deactive(). Fix this by decrementing estab_plinks on STA deletion (mesh_sta_cleanup() gets called from there) so that the counter has a correct value and the Beacon frame advertisement in Mesh Configuration element shows the proper value for capability to accept additional peers. Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9d8bdf761e1cc2739f87ddae1747400213a2ad97 Author: Martin Willi Date: Fri May 13 12:41:48 2016 +0200 mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL commit 62397da50bb20a6b812c949ef465d7e69fe54bb6 upstream. A wmediumd that does not send this attribute causes a NULL pointer dereference, as the attribute is accessed even if it does not exist. The attribute was required but never checked ever since userspace frame forwarding has been introduced. The issue gets more problematic once we allow wmediumd registration from user namespaces. Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx") Signed-off-by: Martin Willi Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a7db982a262e939e687b014b1c501e701d085578 Author: Bob Copeland Date: Sun May 15 13:19:16 2016 -0400 mac80211: mesh: flush mesh paths unconditionally commit fe7a7c57629e8dcbc0e297363a9b2366d67a6dc5 upstream. Currently, the mesh paths associated with a nexthop station are cleaned up in the following code path: __sta_info_destroy_part1 synchronize_net() __sta_info_destroy_part2 -> cleanup_single_sta -> mesh_sta_cleanup -> mesh_plink_deactivate -> mesh_path_flush_by_nexthop However, there are a couple of problems here: 1) the paths aren't flushed at all if the MPM is running in userspace (e.g. when using wpa_supplicant or authsae) 2) there is no synchronize_rcu between removing the path and readers accessing the nexthop, which means the following race is possible: CPU0 CPU1 ~~~~ ~~~~ sta_info_destroy_part1() synchronize_net() rcu_read_lock() mesh_nexthop_resolve() mpath = mesh_path_lookup() [...] -> mesh_path_flush_by_nexthop() sta = rcu_dereference( mpath->next_hop) kfree(sta) access sta <-- CRASH Fix both of these by unconditionally flushing paths before destroying the sta, and by adding a synchronize_net() after path flush to ensure no active readers can still dereference the sta. Fixes this crash: [ 348.529295] BUG: unable to handle kernel paging request at 00020040 [ 348.530014] IP: [] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] *pde = 00000000 [ 348.530014] Oops: 0000 [#1] PREEMPT [ 348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ] [ 348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G O 4.6.0-rc5-wt=V1 #1 [ 348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014 [ 348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000 [ 348.530014] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [ 348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008 [ 348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40 [ 348.530014] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690 [ 348.530014] Stack: [ 348.530014] 00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0 [ 348.530014] f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320 [ 348.530014] f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1 [ 348.530014] Call Trace: [ 348.530014] [] mesh_nexthop_lookup+0xbb/0xc8 [mac80211] [ 348.530014] [] mesh_nexthop_resolve+0x34/0xd8 [mac80211] [ 348.530014] [] ieee80211_xmit+0x92/0xc1 [mac80211] [ 348.530014] [] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211] [ 348.530014] [] ? sch_direct_xmit+0xd7/0x1b3 [ 348.530014] [] ? __local_bh_enable_ip+0x5d/0x7b [ 348.530014] [] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4] [ 348.530014] [] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat] [ 348.530014] [] ? netif_skb_features+0x14d/0x30a [ 348.530014] [] ieee80211_subif_start_xmit+0xa/0xe [mac80211] [ 348.530014] [] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [] dev_queue_xmit+0xa/0xc [ 348.530014] [] batadv_send_skb_packet+0xd6/0xec [batman_adv] [ 348.530014] [] batadv_send_unicast_skb+0x15/0x4a [batman_adv] [ 348.530014] [] batadv_dat_send_data+0x27e/0x310 [batman_adv] [ 348.530014] [] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv] [ 348.530014] [] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv] [ 348.530014] [] batadv_interface_tx+0x206/0x385 [batman_adv] [ 348.530014] [] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [] ? igb_xmit_frame+0x57/0x72 [igb] [ 348.530014] [] dev_queue_xmit+0xa/0xc [ 348.530014] [] br_dev_queue_push_xmit+0xeb/0xfb [bridge] [ 348.530014] [] br_forward_finish+0x29/0x74 [bridge] [ 348.530014] [] ? deliver_clone+0x3b/0x3b [bridge] [ 348.530014] [] __br_forward+0x89/0xe7 [bridge] [ 348.530014] [] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge] [ 348.530014] [] deliver_clone+0x34/0x3b [bridge] [ 348.530014] [] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [] br_flood+0x77/0x95 [bridge] [ 348.530014] [] br_flood_forward+0x13/0x1a [bridge] [ 348.530014] [] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [] br_handle_frame_finish+0x392/0x3db [bridge] [ 348.530014] [] ? nf_iterate+0x2b/0x6b [ 348.530014] [] br_handle_frame+0x1e6/0x240 [bridge] [ 348.530014] [] ? br_handle_local_finish+0x6a/0x6a [bridge] [ 348.530014] [] __netif_receive_skb_core+0x43a/0x66b [ 348.530014] [] ? br_handle_frame_finish+0x3db/0x3db [bridge] [ 348.530014] [] ? resched_curr+0x19/0x37 [ 348.530014] [] ? check_preempt_wakeup+0xbf/0xfe [ 348.530014] [] ? ktime_get_with_offset+0x5c/0xfc [ 348.530014] [] __netif_receive_skb+0x47/0x55 [ 348.530014] [] netif_receive_skb_internal+0x40/0x5a [ 348.530014] [] napi_gro_receive+0x3a/0x94 [ 348.530014] [] igb_poll+0x6fd/0x9ad [igb] [ 348.530014] [] ? swake_up_locked+0x14/0x26 [ 348.530014] [] net_rx_action+0xde/0x250 [ 348.530014] [] __do_softirq+0x8a/0x163 [ 348.530014] [] ? __hrtimer_tasklet_trampoline+0x19/0x19 [ 348.530014] [] do_softirq_own_stack+0x26/0x2c [ 348.530014] [ 348.530014] [] irq_exit+0x31/0x6f [ 348.530014] [] do_IRQ+0x8d/0xa0 [ 348.530014] [] common_interrupt+0x2c/0x40 [ 348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005 [ 348.530014] EIP: [] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40 [ 348.530014] CR2: 0000000000020040 [ 348.530014] ---[ end trace 48556ac26779732e ]--- [ 348.530014] Kernel panic - not syncing: Fatal exception in interrupt [ 348.530014] Kernel Offset: disabled Reported-by: Fred Veldini Tested-by: Fred Veldini Signed-off-by: Bob Copeland Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 84119a97162460f5ff796ada1756abab8dba187b Author: Felix Fietkau Date: Thu May 19 17:34:38 2016 +0200 mac80211: fix fast_tx header alignment commit 6fe04128f158c5ad27e7504bfdf1b12e63331bc9 upstream. The header field is defined as u8[] but also accessed as struct ieee80211_hdr. Enforce an alignment of 2 to prevent unnecessary unaligned accesses, which can be very harmful for performance on many platforms. Fixes: e495c24731a2 ("mac80211: extend fast-xmit for more ciphers") Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 44d30733158515c291ce28d8a8b19202b581c7e3 Author: Johannes Berg Date: Thu Jun 9 09:40:55 2016 +0200 cfg80211: remove get/set antenna and tx power warnings commit 6cbf6236d54c24b9a29e6892549c25b6902b44ce upstream. Since set_tx_power and set_antenna are frequently implemented without the matching get_tx_power/get_antenna, we shouldn't have added warnings for those. Remove them. The remaining ones are correct and need to be implemented symmetrically for correct operation. Fixes: de3bb771f471 ("cfg80211: add more warnings for inconsistent ops") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman