commit 62de88e8e65811010deac5375f8f0d8b14dc4d94 Author: Greg Kroah-Hartman Date: Fri Sep 5 16:37:11 2014 -0700 Linux 3.16.2 commit 3e20bb5a9d388554ceab73858fbf606a4d43f2dc Author: Greg Kroah-Hartman Date: Wed Aug 27 16:55:29 2014 -0700 USB: fix build error with CONFIG_PM_RUNTIME disabled commit a9ef803d740bfadf5e505fbc57efa57692e27025 upstream. commit bdd405d2a528 ("usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1") causes a build error if CONFIG_PM_RUNTIME is disabled. Fix that by doing a simple #ifdef guard around it. Reported-by: Stephen Rothwell Reported-by: kbuild test robot Cc: Roger Quadros Cc: Michael Welling Cc: Alan Stern Signed-off-by: Greg Kroah-Hartman commit c7e25a7a902b13f90ffa3eb4c21e4c3714a1913c Author: Oleg Nesterov Date: Fri Aug 8 14:19:17 2014 -0700 vm_is_stack: use for_each_thread() rather then buggy while_each_thread() commit 4449a51a7c281602d3a385044ab928322a122a02 upstream. Aleksei hit the soft lockup during reading /proc/PID/smaps. David investigated the problem and suggested the right fix. while_each_thread() is racy and should die, this patch updates vm_is_stack(). Signed-off-by: Oleg Nesterov Reported-by: Aleksei Besogonov Tested-by: Aleksei Besogonov Suggested-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7d21e3d5ee56d7a3bac4645dcbabb90d3bf8731e Author: Trond Myklebust Date: Mon Aug 25 22:33:12 2014 -0400 NFSv4: Fix problems with close in the presence of a delegation commit aee7af356e151494d5014f57b33460b162f181b5 upstream. In the presence of delegations, we can no longer assume that the state->n_rdwr, state->n_rdonly, state->n_wronly reflect the open stateid share mode, and so we need to calculate the initial value for calldata->arg.fmode using the state->flags. Reported-by: James Drews Fixes: 88069f77e1ac5 (NFSv41: Fix a potential state leakage when...) Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 96bd3efeed06462bb87d6fdd6d8e66750f294d08 Author: Trond Myklebust Date: Mon Aug 25 22:09:08 2014 -0400 NFSv4: Don't clear the open state when we just did an OPEN_DOWNGRADE commit 412f6c4c26fb1eba8844290663837561ac53fa6e upstream. If we did an OPEN_DOWNGRADE, then the right thing to do on success, is to apply the new open mode to the struct nfs4_state. Instead, we were unconditionally clearing the state, making it appear to our state machinery as if we had just performed a CLOSE. Fixes: 226056c5c312b (NFSv4: Use correct locking when updating nfs4_state...) Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit e77da97c5aefbc9828313f3b8da4ac5ee4260e53 Author: Trond Myklebust Date: Sun Aug 24 14:46:48 2014 -0400 NFSv3: Fix another acl regression commit f87d928f6d98644d39809a013a22f981d39017cf upstream. When creating a new object on the NFS server, we should not be sending posix setacl requests unless the preceding posix_acl_create returned a non-trivial acl. Doing so, causes Solaris servers in particular to return an EINVAL. Fixes: 013cdf1088d72 (nfs: use generic posix ACL infrastructure,,,) Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1132786 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c7650a012929bc8e1393423e7bb29a4a6a808f12 Author: Chuck Lever Date: Wed Jul 16 15:38:32 2014 -0400 svcrdma: Select NFSv4.1 backchannel transport based on forward channel commit 3c45ddf823d679a820adddd53b52c6699c9a05ac upstream. The current code always selects XPRT_TRANSPORT_BC_TCP for the back channel, even when the forward channel was not TCP (eg, RDMA). When a 4.1 mount is attempted with RDMA, the server panics in the TCP BC code when trying to send CB_NULL. Instead, construct the transport protocol number from the forward channel transport or'd with XPRT_TRANSPORT_BC. Transports that do not support bi-directional RPC will not have registered a "BC" transport, causing create_backchannel_client() to fail immediately. Fixes: https://bugzilla.linux-nfs.org/show_bug.cgi?id=265 Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit e313ec518ba580268f03e36bc0bac3457db4c163 Author: Scott Mayhew Date: Mon Aug 4 17:37:27 2014 -0400 nfs: reject changes to resvport and sharecache during remount commit 71a6ec8ac587418ceb6b420def1ca44b334c1ff7 upstream. Commit c8e47028 made it possible to change resvport/noresvport and sharecache/nosharecache via a remount operation, neither of which should be allowed. Signed-off-by: Scott Mayhew Fixes: c8e47028 (nfs: Apply NFS_MOUNT_CMP_FLAGMASK to nfs_compare_remount_data) Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 66c0bfe3e4eb4c69378f9df3ad08e34c9c85f65f Author: Andrey Utkin Date: Sat Jul 26 14:58:01 2014 +0300 nfs3_list_one_acl(): check get_acl() result with IS_ERR_OR_NULL commit 7a9e75a185e6b3a3860e6a26fb6e88691fc2c9d9 upstream. There was a check for result being not NULL. But get_acl() may return NULL, or ERR_PTR, or actual pointer. The purpose of the function where current change is done is to "list ACLs only when they are available", so any error condition of get_acl() mustn't be elevated, and returning 0 there is still valid. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81111 Signed-off-by: Andrey Utkin Reviewed-by: Christoph Hellwig Fixes: 74adf83f5d77 (nfs: only show Posix ACLs in listxattr if actually...) Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 8b1a7f3dc1e0ba5f886f90ad53bb354fafe87284 Author: Kinglong Mee Date: Wed Jul 30 21:26:05 2014 +0800 NFSD: Decrease nfsd_users in nfsd_startup_generic fail commit d9499a95716db0d4bc9b67e88fd162133e7d6b08 upstream. A memory allocation failure could cause nfsd_startup_generic to fail, in which case nfsd_users wouldn't be incorrectly left elevated. After nfsd restarts nfsd_startup_generic will then succeed without doing anything--the first consequence is likely nfs4_start_net finding a bad laundry_wq and crashing. Signed-off-by: Kinglong Mee Fixes: 4539f14981ce "nfsd: replace boolean nfsd_up flag by users counter" Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 242af703ab4e00eeba1b82468706e430572f2392 Author: Takashi Iwai Date: Tue Aug 19 17:37:55 2014 +0200 usbcore: Fix wrong device in an error message in hub_port_connect() commit dd5f5006d1035547559c8a90781a7e249787a7a2 upstream. The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce failures of the same port] added the check of the reliable port, but it also replaced the device argument to dev_err() wrongly, which leads to a NULL dereference. This patch restores the right device, port_dev->dev. Also, since dev_err() itself shows the port number, reduce the port number shown in the error message, essentially reverting to the state before the commit 5ee0f803cc3a. [The fix suggested by Hannes, and the error message cleanup suggested by Alan Stern] Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures of the same port') Reported-by: Hannes Reinecke Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 37f0326a649ac1e4aed3061052aafdc0159dc42e Author: Roger Quadros Date: Mon Aug 4 12:44:46 2014 +0300 usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1 commit bdd405d2a5287bdb9b04670ea255e1f122138e66 upstream. If user specifies that USB autosuspend must be disabled by module parameter "usbcore.autosuspend=-1" then we must prevent autosuspend of USB hub devices as well. commit 596d789a211d introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0" Signed-off-by: Roger Quadros Tested-by: Michael Welling Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit d4b19cc3f412158d31c4ce9127da7a340714a584 Author: Peter Chen Date: Tue Aug 5 08:28:19 2014 +0800 usb: ehci: using wIndex + 1 for hub port commit 5cbcc35e5bf0eae3c7494ce3efefffc9977827ae upstream. The roothub's index per controller is from 0, but the hub port index per hub is from 1, this patch fixes "can't find device at roohub" problem for connecting test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical Test. This patch is for v3.12+. Signed-off-by: Peter Chen Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit cf89514aaaf8004b3d180b797e7e6d4bc95a4c74 Author: James Forshaw Date: Sat Aug 23 14:39:48 2014 -0700 USB: whiteheat: Added bounds checking for bulk command response commit 6817ae225cd650fb1c3295d769298c38b1eba818 upstream. This patch fixes a potential security issue in the whiteheat USB driver which might allow a local attacker to cause kernel memory corrpution. This is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On EHCI and XHCI busses it's possible to craft responses greater than 64 bytes leading a buffer overflow. Signed-off-by: James Forshaw Signed-off-by: Greg Kroah-Hartman commit 8cc98726591bc4c48c56e2d4118a00717a554e8f Author: Jaša Bartelj Date: Sat Aug 16 12:44:27 2014 +0200 USB: ftdi_sio: Added PID for new ekey device commit 646907f5bfb0782c731ae9ff6fb63471a3566132 upstream. Added support to the ftdi_sio driver for ekey Converter USB which uses an FT232BM chip. Signed-off-by: Jaša Bartelj Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8f3aafa971c6923fb924d1c3673f35b7e9a347d0 Author: Johan Hovold Date: Wed Aug 13 17:56:52 2014 +0200 USB: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID commit 6552cc7f09261db2aeaae389aa2c05a74b3a93b4 upstream. Add device id for Basic Micro ATOM Nano USB2Serial adapters. Reported-by: Nicolas Alt Tested-by: Nicolas Alt Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ad83772f7aa178653589fc5a7a2c3071673226a9 Author: Tony Lindgren Date: Mon Aug 25 16:15:35 2014 -0700 ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled commit cc824534d4fef0e46e4486d5c1e10d3c6b1ebadc upstream. Looks like MUSB cable removal can cause wake-up interrupts to stop working for device tree based booting at least for UART3 even as nothing is dynamically remuxed. This can be fixed by calling reconfigure_io_chain() for device tree based booting in hwmod code. Note that we already do that for legacy booting if the legacy mux is configured. My guess is that this is related to UART3 and MUSB ULPI hsusb0_data0 and hsusb0_data1 support for Carkit mode that somehow affect the configured IO chain for UART3 and require rearming the wake-up interrupts. In general, for device tree based booting, pinctrl-single calls the rearm hook that in turn calls reconfigure_io_chain so calling reconfigure_io_chain should not be needed from the hwmod code for other events. So let's limit the hwmod rearming of iochain only to HWMOD_FORCE_MSTANDBY where MUSB is currently the only user of it. If we see other devices needing similar changes we can add more checks for it. Cc: Paul Walmsley Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 9fa500c425cea115011d67b0cbea3635621b3b54 Author: Hans de Goede Date: Mon Aug 25 12:21:56 2014 +0200 xhci: Disable streams on Via XHCI with device-id 0x3432 commit e21eba05afd288a227320f797864ddd859397eed upstream. This is a bit bigger hammer then I would like to use for this, but for now it will have to make do. I'm working on getting my hands on one of these so that I can try to get streams to work (with a quirk flag if necessary) and then we can re-enable them. For now this at least makes uas capable disk enclosures work again by forcing fallback to the usb-storage driver. https://bugzilla.kernel.org/show_bug.cgi?id=79511 Signed-off-by: Hans de Goede Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 4914ed7547e1716c9fbec6e3ac865bdc0944467b Author: Mathias Nyman Date: Tue Aug 19 15:17:58 2014 +0300 xhci: rework cycle bit checking for new dequeue pointers commit 365038d83313951d6ace15342eb24624bbef1666 upstream. When we manually need to move the TR dequeue pointer we need to set the correct cycle bit as well. Previously we used the trb pointer from the last event received as a base, but this was changed in commit 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer") to use the dequeue pointer from the endpoint context instead It turns out some Asmedia controllers advance the dequeue pointer stored in the endpoint context past the event triggering TRB, and this messed up the way the cycle bit was calculated. Instead of adding a quirk or complicating the already hard to follow cycle bit code, the whole cycle bit calculation is now simplified and adapted to handle event and endpoint context dequeue pointer differences. Fixes: 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer") Reported-by: Maciej Puzio Reported-by: Evan Langlois Reviewed-by: Julius Werner Tested-by: Maciej Puzio Tested-by: Evan Langlois Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit b381372cd317743f06e0f6aa618d0a10c4f489de Author: Huang Rui Date: Tue Aug 19 15:17:57 2014 +0300 usb: xhci: amd chipset also needs short TX quirk commit 2597fe99bb0259387111d0431691f5daac84f5a5 upstream. AMD xHC also needs short tx quirk after tested on most of chipset generations. That's because there is the same incorrect behavior like Fresco Logic host. Please see below message with on USB webcam attached on xHC host: [ 139.262944] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.266934] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.270913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.274937] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.278914] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.282936] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.286915] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.290938] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.294913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.298917] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? Reported-by: Arindam Nath Tested-by: Shriraj-Rai P Signed-off-by: Huang Rui Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit e9822113b2aece247cce2a8afeb58e950a4143d0 Author: Hans de Goede Date: Tue Aug 19 15:17:56 2014 +0300 xhci: Treat not finding the event_seg on COMP_STOP the same as COMP_STOP_INVAL commit 9a54886342e227433aebc9d374f8ae268a836475 upstream. When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a the integrated Intel xhci controller on a Haswell laptop: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) The following error gets logged to dmesg: xhci error: Transfer event TRB DMA ptr not part of current TD Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found fixes this. Signed-off-by: Hans de Goede Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 77fe4d2df751754d310a4e3e2c9b8c628a990463 Author: Larry Finger Date: Mon Aug 25 16:05:38 2014 -0500 staging: r8188eu: Add new USB ID commit a2fa6721c7237b5a666f16f732628c0c09c0b954 upstream. The Elecom WDC-150SU2M uses this chip. Reported-by: Hiroki Kondo Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit 27b1bb889146b0b3262cb7c0af46ad94b8b0fff1 Author: Holger Paradies Date: Wed Aug 13 13:22:49 2014 -0500 staging/rtl8188eu: add 0df6:0076 Sitecom Europe B.V. commit 8626d524ef08f10fccc0c41e5f75aef8235edf47 upstream. The stick is not recognized. This dongle uses r8188eu but usb-id is missing. 3.16.0 Signed-off-by: Holger Paradies Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit 641b609cfebfc87c07eaec6f16b11b3333deae91 Author: Mark Einon Date: Sun Aug 10 22:16:55 2014 +0100 staging: et131x: Fix errors caused by phydev->addr accesses before initialisation commit ec0a38bf8b28b036202070cf3ef271e343d9eafc upstream. Fix two reported bugs, caused by et131x_adapter->phydev->addr being accessed before it is initialised, by: - letting et131x_mii_write() take a phydev address, instead of using the one stored in adapter by default. This is so et131x_mdio_write() can use it's own addr value. - removing implementation of et131x_mdio_reset(), as it's not needed. - moving a call to et131x_disable_phy_coma() in et131x_pci_setup(), which uses phydev->addr, until after the mdiobus has been registered. Link: https://bugzilla.kernel.org/show_bug.cgi?id=80751 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77121 Signed-off-by: Mark Einon Signed-off-by: Greg Kroah-Hartman commit 2395e389e36013abc9864ea53720612faa2529cd Author: Pranith Kumar Date: Tue Aug 5 12:27:15 2014 -0400 staging: lustre: Remove circular dependency on header commit e409842a03b0c2c41c0959fef8a7563208af36c1 upstream. The following patch fixes a build error on sparc32. I think it should go to stable 3.16. Remove a circular dependency on atomic.h header file which leads to compilation failure on sparc32 as reported here: http://kisskb.ellerman.id.au/kisskb/buildresult/11340509/ The specific dependency is as follows: In file included from arch/sparc/include/asm/smp_32.h:24:0, from arch/sparc/include/asm/smp.h:6, from arch/sparc/include/asm/switch_to_32.h:4, from arch/sparc/include/asm/switch_to.h:6, from arch/sparc/include/asm/ptrace.h:84, from arch/sparc/include/asm/processor_32.h:16, from arch/sparc/include/asm/processor.h:6, from arch/sparc/include/asm/barrier_32.h:4, from arch/sparc/include/asm/barrier.h:6, from arch/sparc/include/asm/atomic_32.h:17, from arch/sparc/include/asm/atomic.h:6, from drivers/staging/lustre/lustre/obdclass/class_obd.c:38 Signed-off-by: Pranith Kumar Signed-off-by: Greg Kroah-Hartman commit 4fcb573b61c82250fa98a7795280009916e9a101 Author: Darrick J. Wong Date: Wed Aug 27 18:40:07 2014 -0400 jbd2: fix descriptor block size handling errors with journal_csum commit db9ee220361de03ee86388f9ea5e529eaad5323c upstream. It turns out that there are some serious problems with the on-disk format of journal checksum v2. The foremost is that the function to calculate descriptor tag size returns sizes that are too big. This causes alignment issues on some architectures and is compounded by the fact that some parts of jbd2 use the structure size (incorrectly) to determine the presence of a 64bit journal instead of checking the feature flags. Therefore, introduce journal checksum v3, which enlarges the descriptor block tag format to allow for full 32-bit checksums of journal blocks, fix the journal tag function to return the correct sizes, and fix the jbd2 recovery code to use feature flags to determine 64bitness. Add a few function helpers so we don't have to open-code quite so many pieces. Switching to a 16-byte block size was found to increase journal size overhead by a maximum of 0.1%, to convert a 32-bit journal with no checksumming to a 32-bit journal with checksum v3 enabled. Signed-off-by: Darrick J. Wong Reported-by: TR Reardon Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit ec44d1903e186cbecdb40ede0a7f38b47226f7dd Author: Darrick J. Wong Date: Wed Aug 27 18:40:05 2014 -0400 jbd2: fix infinite loop when recovering corrupt journal blocks commit 022eaa7517017efe4f6538750c2b59a804dc7df7 upstream. When recovering the journal, don't fall into an infinite loop if we encounter a corrupt journal block. Instead, just skip the block and return an error, which fails the mount and thus forces the user to run a full filesystem fsck. Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit ee1c1d5a2851faff041338d013174937d0676399 Author: Darrick J. Wong Date: Wed Aug 27 18:40:09 2014 -0400 ext4: fix same-dir rename when inline data directory overflows commit d80d448c6c5bdd32605b78a60fe8081d82d4da0f upstream. When performing a same-directory rename, it's possible that adding or setting the new directory entry will cause the directory to overflow the inline data area, which causes the directory to be converted to an extent-based directory. Under this circumstance it is necessary to re-read the directory when deleting the old dirent because the "old directory" context still points to i_block in the inode table, which is now an extent tree root! The delete fails with an FS error, and the subsequent fsck complains about incorrect link counts and hardlinked directories. Test case (originally found with flat_dir_test in the metadata_csum test program): # mkfs.ext4 -O inline_data /dev/sda # mount /dev/sda /mnt # mkdir /mnt/x # touch /mnt/x/changelog.gz /mnt/x/copyright /mnt/x/README.Debian # sync # for i in /mnt/x/*; do mv $i $i.longer; done # ls -la /mnt/x/ total 0 -rw-r--r-- 1 root root 0 Aug 25 12:03 changelog.gz.longer -rw-r--r-- 1 root root 0 Aug 25 12:03 copyright -rw-r--r-- 1 root root 0 Aug 25 12:03 copyright.longer -rw-r--r-- 1 root root 0 Aug 25 12:03 README.Debian.longer (Hey! Why are there four files now??) Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit e531b072556fdb32ca36f6d73902b1433af2a264 Author: Dmitry Monakhov Date: Wed Aug 27 18:40:03 2014 -0400 ext4: update i_disksize coherently with block allocation on error path commit 6603120e96eae9a5d6228681ae55c7fdc998d1bb upstream. In case of delalloc block i_disksize may be less than i_size. So we have to update i_disksize each time we allocated and submitted some blocks beyond i_disksize. We weren't doing this on the error paths, so fix this. testcase: xfstest generic/019 Signed-off-by: Dmitry Monakhov Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d89b2f764e9f9eb6c1ac90d25e6fc5b43b676a48 Author: Dmitry Monakhov Date: Wed Aug 27 18:40:00 2014 -0400 ext4: fix transaction issues for ext4_fallocate and ext_zero_range commit c174e6d6979a04b7b77b93f244396be4b81f8bfb upstream. After commit f282ac19d86f we use different transactions for preallocation and i_disksize update which result in complain from fsck after power-failure. spotted by generic/019. IMHO this is regression because fs becomes inconsistent, even more 'e2fsck -p' will no longer works (which drives admins go crazy) Same transaction requirement applies ctime,mtime updates testcase: xfstest generic/019 Signed-off-by: Dmitry Monakhov Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 69fa118cd621a59032a41d2e7ff913bf06ce57b7 Author: Dmitry Monakhov Date: Wed Aug 27 18:33:49 2014 -0400 ext4: fix incorect journal credits reservation in ext4_zero_range commit 69dc9536405213c1d545fcace1fc15c481d00aae upstream. Currently we reserve only 4 blocks but in worst case scenario ext4_zero_partial_blocks() may want to zeroout and convert two non adjacent blocks. Signed-off-by: Dmitry Monakhov Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 43fc7fe25e51c6e9c22b872292cf2327a0fd37a6 Author: Dmitry Monakhov Date: Sat Aug 23 17:48:28 2014 -0400 ext4: move i_size,i_disksize update routines to helper function commit 4631dbf677ded0419fee35ca7408285dabfaef1a upstream. Signed-off-by: Dmitry Monakhov Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 3099fab527ba36c6ddf309db16108fe65225239e Author: Alexander Usyskin Date: Tue Aug 12 18:07:57 2014 +0300 mei: nfc: fix memory leak in error path commit 8e8248b1369c97c7bb6f8bcaee1f05deeabab8ef upstream. NFC will leak buffer if send failed. Use single exit point that does the freeing Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit c079d35b714c3608077982e6270b11074b97e8d4 Author: Alexander Usyskin Date: Tue Aug 12 18:07:56 2014 +0300 mei: reset client state on queued connect request commit 73ab4232388b7a08f17c8d08141ff2099fa0b161 upstream. If connect request is queued (e.g. device in pg) set client state to initializing, thus avoid preliminary exit in wait if current state is disconnected. This is regression from: commit e4d8270e604c3202131bac607969605ac397b893 Author: Alexander Usyskin mei: set connecting state just upon connection request is sent to the fw Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 8b7ac9fcb2cbc466e62167974803d654938238be Author: Liu Bo Date: Fri Aug 15 23:36:53 2014 +0800 Btrfs: fix task hang under heavy compressed write commit 9e0af23764344f7f1b68e4eefbe7dc865018b63d upstream. This has been reported and discussed for a long time, and this hang occurs in both 3.15 and 3.16. Btrfs now migrates to use kernel workqueue, but it introduces this hang problem. Btrfs has a kind of work queued as an ordered way, which means that its ordered_func() must be processed in the way of FIFO, so it usually looks like -- normal_work_helper(arg) work = container_of(arg, struct btrfs_work, normal_work); work->func() <---- (we name it work X) for ordered_work in wq->ordered_list ordered_work->ordered_func() ordered_work->ordered_free() The hang is a rare case, first when we find free space, we get an uncached block group, then we go to read its free space cache inode for free space information, so it will file a readahead request btrfs_readpages() for page that is not in page cache __do_readpage() submit_extent_page() btrfs_submit_bio_hook() btrfs_bio_wq_end_io() submit_bio() end_workqueue_bio() <--(ret by the 1st endio) queue a work(named work Y) for the 2nd also the real endio() So the hang occurs when work Y's work_struct and work X's work_struct happens to share the same address. A bit more explanation, A,B,C -- struct btrfs_work arg -- struct work_struct kthread: worker_thread() pick up a work_struct from @worklist process_one_work(arg) worker->current_work = arg; <-- arg is A->normal_work worker->current_func(arg) normal_work_helper(arg) A = container_of(arg, struct btrfs_work, normal_work); A->func() A->ordered_func() A->ordered_free() <-- A gets freed B->ordered_func() submit_compressed_extents() find_free_extent() load_free_space_inode() ... <-- (the above readhead stack) end_workqueue_bio() btrfs_queue_work(work C) B->ordered_free() As if work A has a high priority in wq->ordered_list and there are more ordered works queued after it, such as B->ordered_func(), its memory could have been freed before normal_work_helper() returns, which means that kernel workqueue code worker_thread() still has worker->current_work pointer to be work A->normal_work's, ie. arg's address. Meanwhile, work C is allocated after work A is freed, work C->normal_work and work A->normal_work are likely to share the same address(I confirmed this with ftrace output, so I'm not just guessing, it's rare though). When another kthread picks up work C->normal_work to process, and finds our kthread is processing it(see find_worker_executing_work()), it'll think work C as a collision and skip then, which ends up nobody processing work C. So the situation is that our kthread is waiting forever on work C. Besides, there're other cases that can lead to deadlock, but the real problem is that all btrfs workqueue shares one work->func, -- normal_work_helper, so this makes each workqueue to have its own helper function, but only a wraper pf normal_work_helper. With this patch, I no long hit the above hang. Signed-off-by: Liu Bo Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit a1bbac07b61162c67f5d814db0502b188d3eb30e Author: Chris Mason Date: Wed Aug 20 07:15:33 2014 -0700 Btrfs: fix filemap_flush call in btrfs_file_release commit f6dc45c7a93a011dff6eb9b2ffda59c390c7705a upstream. We should only be flushing on close if the file was flagged as needing it during truncate. I broke this with my ordered data vs transaction commit deadlock fix. Thanks to Miao Xie for catching this. Signed-off-by: Chris Mason Reported-by: Miao Xie Reported-by: Fengguang Wu Signed-off-by: Greg Kroah-Hartman commit ddef1474c305ea0d1cb5a93398db014caf141d64 Author: Liu Bo Date: Tue Aug 19 23:33:13 2014 +0800 Btrfs: fix crash on endio of reading corrupted block commit 38c1c2e44bacb37efd68b90b3f70386a8ee370ee upstream. The crash is ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:2124! [...] Workqueue: btrfs-endio normal_work_helper [btrfs] RIP: 0010:[] [] end_bio_extent_readpage+0xb45/0xcd0 [btrfs] This is in fact a regression. It is because we forgot to increase @offset properly in reading corrupted block, so that the @offset remains, and this leads to checksum errors while reading left blocks queued up in the same bio, and then ends up with hiting the above BUG_ON. Reported-by: Chris Murphy Signed-off-by: Liu Bo Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 5792fa6bad8a1c55be3be37d6e89081c4cf7b112 Author: Chris Mason Date: Tue Aug 12 10:47:42 2014 -0700 btrfs: disable strict file flushes for renames and truncates commit 8d875f95da43c6a8f18f77869f2ef26e9594fecc upstream. Truncates and renames are often used to replace old versions of a file with new versions. Applications often expect this to be an atomic replacement, even if they haven't done anything to make sure the new version is fully on disk. Btrfs has strict flushing in place to make sure that renaming over an old file with a new file will fully flush out the new file before allowing the transaction commit with the rename to complete. This ordering means the commit code needs to be able to lock file pages, and there are a few paths in the filesystem where we will try to end a transaction with the page lock held. It's rare, but these things can deadlock. This patch removes the ordered flushes and switches to a best effort filemap_flush like ext4 uses. It's not perfect, but it should fix the deadlocks. Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 8e46c5dc5e3e7e861b1211a679b8e38ba01699a8 Author: Liu Bo Date: Thu Jul 24 22:48:05 2014 +0800 Btrfs: fix compressed write corruption on enospc commit ce62003f690dff38d3164a632ec69efa15c32cbf upstream. When failing to allocate space for the whole compressed extent, we'll fallback to uncompressed IO, but we've forgotten to redirty the pages which belong to this compressed extent, and these 'clean' pages will simply skip 'submit' part and go to endio directly, at last we got data corruption as we write nothing. Signed-off-by: Liu Bo Tested-By: Martin Steigerwald Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 480f1ea5e0697c721149fb6abe93652dc48e30ae Author: Filipe Manana Date: Wed Jul 2 20:07:54 2014 +0100 Btrfs: read lock extent buffer while walking backrefs commit 6f7ff6d7832c6be13e8c95598884dbc40ad69fb7 upstream. Before processing the extent buffer, acquire a read lock on it, so that we're safe against concurrent updates on the extent buffer. Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 4dc6ec45580779f8d79972d32ffe7501f6f5cf6d Author: Filipe Manana Date: Sat Aug 9 21:22:27 2014 +0100 Btrfs: fix csum tree corruption, duplicate and outdated checksums commit 27b9a8122ff71a8cadfbffb9c4f0694300464f3b upstream. Under rare circumstances we can end up leaving 2 versions of a checksum for the same file extent range. The reason for this is that after calling btrfs_next_leaf we process slot 0 of the leaf it returns, instead of processing the slot set in path->slots[0]. Most of the time (by far) path->slots[0] is 0, but after btrfs_next_leaf() releases the path and before it searches for the next leaf, another task might cause a split of the next leaf, which migrates some of its keys to the leaf we were processing before calling btrfs_next_leaf(). In this case btrfs_next_leaf() returns again the same leaf but with path->slots[0] having a slot number corresponding to the first new key it got, that is, a slot number that didn't exist before calling btrfs_next_leaf(), as the leaf now has more keys than it had before. So we must really process the returned leaf starting at path->slots[0] always, as it isn't always 0, and the key at slot 0 can have an offset much lower than our search offset/bytenr. For example, consider the following scenario, where we have: sums->bytenr: 40157184, sums->len: 16384, sums end: 40173568 four 4kb file data blocks with offsets 40157184, 40161280, 40165376, 40169472 Leaf N: slot = 0 slot = btrfs_header_nritems() - 1 |-------------------------------------------------------------------| | [(CSUM CSUM 39239680), size 8] ... [(CSUM CSUM 40116224), size 4] | |-------------------------------------------------------------------| Leaf N + 1: slot = 0 slot = btrfs_header_nritems() - 1 |--------------------------------------------------------------------| | [(CSUM CSUM 40161280), size 32] ... [((CSUM CSUM 40615936), size 8 | |--------------------------------------------------------------------| Because we are at the last slot of leaf N, we call btrfs_next_leaf() to find the next highest key, which releases the current path and then searches for that next key. However after releasing the path and before finding that next key, the item at slot 0 of leaf N + 1 gets moved to leaf N, due to a call to ctree.c:push_leaf_left() (via ctree.c:split_leaf()), and therefore btrfs_next_leaf() will returns us a path again with leaf N but with the slot pointing to its new last key (CSUM CSUM 40161280). This new version of leaf N is then: slot = 0 slot = btrfs_header_nritems() - 2 slot = btrfs_header_nritems() - 1 |----------------------------------------------------------------------------------------------------| | [(CSUM CSUM 39239680), size 8] ... [(CSUM CSUM 40116224), size 4] [(CSUM CSUM 40161280), size 32] | |----------------------------------------------------------------------------------------------------| And incorrecly using slot 0, makes us set next_offset to 39239680 and we jump into the "insert:" label, which will set tmp to: tmp = min((sums->len - total_bytes) >> blocksize_bits, (next_offset - file_key.offset) >> blocksize_bits) = min((16384 - 0) >> 12, (39239680 - 40157184) >> 12) = min(4, (u64)-917504 = 18446744073708634112 >> 12) = 4 and ins_size = csum_size * tmp = 4 * 4 = 16 bytes. In other words, we insert a new csum item in the tree with key (CSUM_OBJECTID CSUM_KEY 40157184 = sums->bytenr) that contains the checksums for all the data (4 blocks of 4096 bytes each = sums->len). Which is wrong, because the item with key (CSUM CSUM 40161280) (the one that was moved from leaf N + 1 to the end of leaf N) contains the old checksums of the last 12288 bytes of our data and won't get those old checksums removed. So this leaves us 2 different checksums for 3 4kb blocks of data in the tree, and breaks the logical rule: Key_N+1.offset >= Key_N.offset + length_of_data_its_checksums_cover An obvious bad effect of this is that a subsequent csum tree lookup to get the checksum of any of the blocks with logical offset of 40161280, 40165376 or 40169472 (the last 3 4kb blocks of file data), will get the old checksums. Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 3173e852f05a359645eb3c9e141f3cff7d317c45 Author: Takashi Iwai Date: Mon Jul 28 10:57:04 2014 +0200 Btrfs: Fix memory corruption by ulist_add_merge() on 32bit arch commit 4eb1f66dce6c4dc28dd90a7ffbe6b2b1cb08aa4e upstream. We've got bug reports that btrfs crashes when quota is enabled on 32bit kernel, typically with the Oops like below: BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: [] find_parent_nodes+0x360/0x1380 [btrfs] *pde = 00000000 Oops: 0000 [#1] SMP CPU: 0 PID: 151 Comm: kworker/u8:2 Tainted: G S W 3.15.2-1.gd43d97e-default #1 Workqueue: btrfs-qgroup-rescan normal_work_helper [btrfs] task: f1478130 ti: f147c000 task.ti: f147c000 EIP: 0060:[] EFLAGS: 00010213 CPU: 0 EIP is at find_parent_nodes+0x360/0x1380 [btrfs] EAX: f147dda8 EBX: f147ddb0 ECX: 00000011 EDX: 00000000 ESI: 00000000 EDI: f147dda4 EBP: f147ddf8 ESP: f147dd38 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 00000004 CR3: 00bf3000 CR4: 00000690 Stack: 00000000 00000000 f147dda4 00000050 00000001 00000000 00000001 00000050 00000001 00000000 d3059000 00000001 00000022 000000a8 00000000 00000000 00000000 000000a1 00000000 00000000 00000001 00000000 00000000 11800000 Call Trace: [] __btrfs_find_all_roots+0x9d/0xf0 [btrfs] [] btrfs_qgroup_rescan_worker+0x401/0x760 [btrfs] [] normal_work_helper+0xc8/0x270 [btrfs] [] process_one_work+0x11b/0x390 [] worker_thread+0x101/0x340 [] kthread+0x9b/0xb0 [] ret_from_kernel_thread+0x21/0x30 [] kthread_create_on_node+0x110/0x110 This indicates a NULL corruption in prefs_delayed list. The further investigation and bisection pointed that the call of ulist_add_merge() results in the corruption. ulist_add_merge() takes u64 as aux and writes a 64bit value into old_aux. The callers of this function in backref.c, however, pass a pointer of a pointer to old_aux. That is, the function overwrites 64bit value on 32bit pointer. This caused a NULL in the adjacent variable, in this case, prefs_delayed. Here is a quick attempt to band-aid over this: a new function, ulist_add_merge_ptr() is introduced to pass/store properly a pointer value instead of u64. There are still ugly void ** cast remaining in the callers because void ** cannot be taken implicitly. But, it's safer than explicit cast to u64, anyway. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=887046 Signed-off-by: Takashi Iwai Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 13ca262a53e8cc5516ee8d16a42470383470d988 Author: Stephen M. Cameron Date: Thu Jul 3 10:18:03 2014 -0500 hpsa: fix bad -ENOMEM return value in hpsa_big_passthru_ioctl commit 0758f4f732b08b6ef07f2e5f735655cf69fea477 upstream. When copy_from_user fails, return -EFAULT, not -ENOMEM Signed-off-by: Stephen M. Cameron Reported-by: Robert Elliott Reviewed-by: Joe Handzik Reviewed-by: Scott Teel Reviewed by: Mike MIller Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit d3e123315a7c770be8db64507cba95585285de23 Author: Hugh Dickins Date: Fri Aug 29 15:18:44 2014 -0700 x86,mm: fix pte_special versus pte_numa commit b38af4721f59d0b564468f623b3e52a638195015 upstream. Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: where zap_pte_range() checks page->mapping to see if PageAnon(page). Those addresses fit struct pages for pfns d2001 and d2000, and in each dump a register or a stack slot showed d2001730 or d2000730: pte flags 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has a hole between cfffffff and 100000000, which would need special access. Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL pte no longer passes the pte_special() test, so zap_pte_range() goes on to try to access a non-existent struct page. Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). A hint that this was a problem was that c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: This was papering over a pte_special() snag when the zero page was encountered during zap. This patch reverts vm_normal_page() to how it was before, relying on pte_special(). It still appears that this patch may be incomplete: aren't there other places which need to be handling PROTNONE along with PRESENT? For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE area, that would make it pte_special(). This is side-stepped by the fact that NUMA hinting faults skipped PROT_NONE VMAs and there are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be interesting. Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") Reported-by: Sasha Levin Tested-by: Sasha Levin Signed-off-by: Hugh Dickins Signed-off-by: Mel Gorman Cc: "Kirill A. Shutemov" Cc: Peter Zijlstra Cc: Rik van Riel Cc: Johannes Weiner Cc: Cyrill Gorcunov Cc: Matthew Wilcox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d752dc49bdf17acf7e075091a6a8c97612a673a1 Author: David Vrabel Date: Thu Aug 7 17:06:06 2014 +0100 x86/xen: resume timer irqs early commit 8d5999df35314607c38fbd6bdd709e25c3a4eeab upstream. If the timer irqs are resumed during device resume it is possible in certain circumstances for the resume to hang early on, before device interrupts are resumed. For an Ubuntu 14.04 PVHVM guest this would occur in ~0.5% of resume attempts. It is not entirely clear what is occuring the point of the hang but I think a task necessary for the resume calls schedule_timeout(), waiting for a timer interrupt (which never arrives). This failure may require specific tasks to be running on the other VCPUs to trigger (processes are not frozen during a suspend/resume if PREEMPT is disabled). Add IRQF_EARLY_RESUME to the timer interrupts so they are resumed in syscore_resume(). Signed-off-by: David Vrabel Reviewed-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 434d59e0718f5fdf91ff9a9bb6c98887e42ba912 Author: David Vrabel Date: Tue Aug 5 11:49:19 2014 +0100 x86/xen: use vmap() to map grant table pages in PVH guests commit 7d951f3ccb0308c95bf76d5eef9886dea35a7013 upstream. Commit b7dd0e350e0b (x86/xen: safely map and unmap grant frames when in atomic context) causes PVH guests to crash in arch_gnttab_map_shared() when they attempted to map the pages for the grant table. This use of a PV-specific function during the PVH grant table setup is non-obvious and not needed. The standard vmap() function does the right thing. Signed-off-by: David Vrabel Reported-by: Mukesh Rathor Tested-by: Mukesh Rathor Signed-off-by: Greg Kroah-Hartman commit ae37cf1978872f14850ee4d7bb7c538c9c32ba04 Author: Matt Fleming Date: Fri Jul 11 08:45:25 2014 +0100 x86/efi: Enforce CONFIG_RELOCATABLE for EFI boot stub commit 7b2a583afb4ab894f78bc0f8bd136e96b6499a7e upstream. Without CONFIG_RELOCATABLE the early boot code will decompress the kernel to LOAD_PHYSICAL_ADDR. While this may have been fine in the BIOS days, that isn't going to fly with UEFI since parts of the firmware code/data may be located at LOAD_PHYSICAL_ADDR. Straying outside of the bounds of the regions we've explicitly requested from the firmware will cause all sorts of trouble. Bruno reports that his machine resets while trying to decompress the kernel image. We already go to great pains to ensure the kernel is loaded into a suitably aligned buffer, it's just that the address isn't necessarily LOAD_PHYSICAL_ADDR, because we can't guarantee that address isn't in-use by the firmware. Explicitly enforce CONFIG_RELOCATABLE for the EFI boot stub, so that we can load the kernel at any address with the correct alignment. Reported-by: Bruno Prémont Tested-by: Bruno Prémont Cc: H. Peter Anvin Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 31c05d1c2672eab3a9cc8c4c0c01183b4be45cec Author: David Vrabel Date: Thu Jul 31 16:22:25 2014 +0100 xen/events/fifo: ensure all bitops are properly aligned even on x86 commit dcecb8fd93a65787130a74e61fdf29932c8d85eb upstream. When using the FIFO-based ABI on x86_64, if the last port is at the end of an event array page then sync_test_bit() on this port's event word will read beyond the end of the page and in certain circumstances this may fault. The fault requires the following page in the kernel's direct mapping to be not present, which would mean: a) the array page is the last page of RAM; or b) the following page is ballooned out /and/ it has been used for a foreign mapping by a kernel driver (such as netback or blkback) /and/ the grant has been unmapped. Use the infrastructure added for arm64 to ensure that all bitops operating on event words are unsigned long aligned. Signed-off-by: David Vrabel Reviewed-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit c5abe8034fe4c15479edc329b895dcc495beef2c Author: Thomas Gleixner Date: Tue Aug 5 22:57:19 2014 +0200 x86: MCE: Add raw_lock conversion again commit ed5c41d30ef2ce578fd6b6e2f7ec23f2a58b1eba upstream. Commit ea431643d6c3 ("x86/mce: Fix CMCI preemption bugs") breaks RT by the completely unrelated conversion of the cmci_discover_lock to a regular (non raw) spinlock. This lock was annotated in commit 59d958d2c7de ("locking, x86: mce: Annotate cmci_discover_lock as raw") with a proper explanation why. The argument for converting the lock back to a regular spinlock was: - it does percpu ops without disabling preemption. Preemption is not disabled due to the mistaken use of a raw spinlock. Which is complete nonsense. The raw_spinlock is disabling preemption in the same way as a regular spinlock. In mainline spinlock maps to raw_spinlock, in RT spinlock becomes a "sleeping" lock. raw_spinlock has on RT exactly the same semantics as in mainline. And because this lock is taken in non preemptible context it must be raw on RT. Undo the locking brainfart. Reported-by: Clark Williams Reported-by: Steven Rostedt Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e6ff6f134b62c4d9888a4c480be6a055bf5b91bf Author: Arnd Bergmann Date: Thu Jun 26 15:44:52 2014 +0200 hpsa: fix non-x86 builds commit 0b9e7b741f2bf8103b15bb14d5b4a6f5ee91c59a upstream. commit 28e134464734 "[SCSI] hpsa: enable unit attention reporting" turns on unit attention notifications, but got the change wrong for all architectures other than x86, which now store an uninitialized value into the device register. Gcc helpfully warns about this: ../drivers/scsi/hpsa.c: In function 'hpsa_set_driver_support_bits': ../drivers/scsi/hpsa.c:6373:17: warning: 'driver_support' is used uninitialized in this function [-Wuninitialized] driver_support |= ENABLE_UNIT_ATTN; ^ This moves the #ifdef so only the prefetch-enable is conditional on x86, not also reading the initial register contents. Signed-off-by: Arnd Bergmann Fixes: 28e134464734 "[SCSI] hpsa: enable unit attention reporting" Acked-by: Stephen M. Cameron Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 5b34537474526e19cea311fb460507a77b867c67 Author: Andy Lutomirski Date: Fri Jul 25 16:30:27 2014 -0700 x86_64/vsyscall: Fix warn_bad_vsyscall log output commit 53b884ac3745353de220d92ef792515c3ae692f0 upstream. This commit in Linux 3.6: commit c767a54ba0657e52e6edaa97cbe0b0a8bf1c1655 Author: Joe Perches Date: Mon May 21 19:50:07 2012 -0700 x86/debug: Add KERN_ to bare printks, convert printks to pr_ caused warn_bad_vsyscall to output garbage in the middle of the line. Revert the bad part of it. The printk in question isn't actually bare; the level is "%s". The bug this fixes is purely cosmetic; backports are optional. Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/03eac1f24110bbe496ecc12a4df467e0d88466d4.1406330947.git.luto@amacapital.net Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit bc3c16626e2eb90607bbb72408b7a01a197d3a8d Author: Brian W Hart Date: Thu Jul 31 14:24:37 2014 -0500 powerpc/powernv: Update dev->dma_mask in pci_set_dma_mask() path commit a32305bf90a2ae0e6a9a93370c7616565f75e15a upstream. powerpc defines various machine-specific routines for handling pci_set_dma_mask(). The routines for machine "PowerNV" may neglect to set dev->dma_mask. This could confuse anyone (e.g. drivers) that consult dev->dma_mask to find the current mask. Set the dma_mask in the PowerNV leaf routine. Signed-off-by: Brian W. Hart Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 6f519e9053920b1c450a6147b4dfc849449a3008 Author: Tyrel Datwyler Date: Tue Jul 29 13:48:13 2014 -0400 powerpc/pci: Reorder pci bus/bridge unregistration during PHB removal commit 7340056567e32b2c9d3554eb146e1977c93da116 upstream. Commit bcdde7e made __sysfs_remove_dir() recursive and introduced a BUG_ON during PHB removal while attempting to delete the power managment attribute group of the bus. This is a result of tearing the bridge and bus devices down out of order in remove_phb_dynamic. Since, the the bus resides below the bridge in the sysfs device tree it should be torn down first. This patch simply moves the device_unregister call for the PHB bridge device after the device_unregister call for the PHB bus. Fixes: bcdde7e221a8 ("sysfs: make __sysfs_remove_dir() recursive") Signed-off-by: Tyrel Datwyler Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 3aa12318ea90682474b7346ca7d0f81a332cc698 Author: Mike Qiu Date: Tue Jul 15 01:42:22 2014 -0400 powerpc/eeh: Wrong place to call pci_get_slot() commit 9e5c6e5a3be0b2e17ff61b9b74adef4a2c9e6934 upstream. pci_get_slot() is called with hold of PCI bus semaphore and it's not safe to be called in interrupt context. However, we possibly checks EEH error and calls the function in interrupt context. To avoid using pci_get_slot(), we turn into device tree for fetching location code. Otherwise, we might run into WARN_ON() as following messages indicate: WARNING: at drivers/pci/search.c:223 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc3+ #72 task: c000000001367af0 ti: c000000001444000 task.ti: c000000001444000 NIP: c000000000497b70 LR: c000000000037530 CTR: 000000003003d114 REGS: c000000001446fa0 TRAP: 0700 Not tainted (3.16.0-rc3+) MSR: 9000000000029032 CR: 48002422 XER: 20000000 CFAR: c00000000003752c SOFTE: 0 : NIP [c000000000497b70] .pci_get_slot+0x40/0x110 LR [c000000000037530] .eeh_pe_loc_get+0x150/0x190 Call Trace: .of_get_property+0x30/0x60 (unreliable) .eeh_pe_loc_get+0x150/0x190 .eeh_dev_check_failure+0x1b4/0x550 .eeh_check_failure+0x90/0xf0 .lpfc_sli_check_eratt+0x504/0x7c0 [lpfc] .lpfc_poll_eratt+0x64/0x100 [lpfc] .call_timer_fn+0x64/0x190 .run_timer_softirq+0x2cc/0x3e0 Signed-off-by: Mike Qiu Acked-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 42dbd25aa491fb4ab3c80cbd84a6622efd86d027 Author: Christoph Schulz Date: Wed Jul 16 10:00:57 2014 +0200 x86: don't exclude low BIOS area when allocating address space for non-PCI cards commit cbace46a9710a480cae51e4611697df5de41713e upstream. Commit 30919b0bf356 ("x86: avoid low BIOS area when allocating address space") moved the test for resource allocations that fall within the first 1MB of address space from the PCI-specific path to a generic path, such that all resource allocations will avoid this area. However, this breaks ISA cards which need to allocate a memory region within the first 1MB. An example is the i82365 PCMCIA controller and derivatives like the Ricoh RF5C296/396 which map part of the PCMCIA socket memory address space into the first 1MB of system memory address space. They do not work anymore as no usable memory region exists due to this change: Intel ISA PCIC probe: Ricoh RF5C296/396 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets host opts [0]: none host opts [1]: none ISA irqs (scanned) = 3,4,5,9,10 status change on irq 10 pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1 pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean. pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0d0000-0x0dffff: clean. pcmcia_socket pcmcia_socket0: cs: memory probe 0x0e0000-0x0effff: clean. pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: clean. pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: clean. pcmcia_socket pcmcia_socket1: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff pcmcia_socket pcmcia_socket1: cs: IO port probe 0xa00-0xaff: clean. pcmcia_socket pcmcia_socket1: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0d0000-0x0dffff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0x0e0000-0x0effff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0x60000000-0x60ffffff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0xa0000000-0xa0ffffff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0x0cc000-0x0effff: excluding 0xe0000-0xeffff pcmcia_socket pcmcia_socket1: cs: unable to map card memory! If filtering out the first 1MB is reverted, everything works as expected. Tested-by: Robert Resch Signed-off-by: Christoph Schulz Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 3b7d7354294b0741da9853c7b0218d123f1bcada Author: Simone Gotti Date: Wed Jun 18 16:55:30 2014 +0200 ACPI / PCI: Fix sysfs acpi_index and label errors commit dcfa9be83866e28fcb8b7e22b4eeb4ba63bd3174 upstream. Fix errors in handling "device label" _DSM return values. If _DSM returns a Unicode string, the ACPI type is ACPI_TYPE_BUFFER, not ACPI_TYPE_STRING. Fix dsm_label_utf16s_to_utf8s() to convert UTF-16 from acpi_object->buffer instead of acpi_object->string. Prior to v3.14, we accepted Unicode labels (ACPI_TYPE_BUFFER return values). But after 1d0fcef73283, we accepted only ASCII (ACPI_TYPE_STRING) (and we incorrectly tried to convert those ASCII labels from UTF-16 to UTF-8). Rejecting Unicode labels made us return -EPERM when reading sysfs "acpi_index" or "label" files, which in turn caused on-board network interfaces on a Dell PowerEdge E420 to be renamed (by udev net_id internal) from eno1/eno2 to enp2s0f0/enp2s0f1. Fix this by accepting either ACPI_TYPE_STRING (and treating it as ASCII) or ACPI_TYPE_BUFFER (and converting from UTF-16 to UTF-8). [bhelgaas: changelog] Fixes: 1d0fcef73283 ("ACPI / PCI: replace open-coded _DSM code with helper functions") Signed-off-by: Simone Gotti Signed-off-by: Bjorn Helgaas Reviewed-by: Jiang Liu Signed-off-by: Greg Kroah-Hartman commit 5de9628c8b21e8bf960b6709198eb506029de173 Author: Myron Stowe Date: Tue Jun 17 13:27:34 2014 -0600 PCI: pciehp: Clear Data Link Layer State Changed during init commit 0d25d35c987d7b0b63368d9c1ae35a917e1a7bab upstream. During PCIe hot-plug initialization - pciehp_probe() - data structures related to slot capabilities are set up. As part of this set up, ISRs are put in place to handle slot events and all event bits are cleared out. This patch adds the Data Link Layer State Changed (PCI_EXP_SLTSTA_DLLSC) Slot Status bit to the event bits that are cleared out during initialization. If the BIOS doesn't clear DLLSC before handoff to the OS, pciehp notices that it's set and interprets it as a new Link Up event, which results in spurious messages: pciehp 0000:82:04.0:pcie24: slot(4): Link Up event pciehp 0000:82:04.0:pcie24: Device 0000:83:00.0 already exists at 0000:83:00, cannot hot-add pciehp 0000:82:04.0:pcie24: Cannot add device at 0000:83:00 Prior to e48f1b67f668 ("PCI: pciehp: Use link change notifications for hot-plug and removal"), pciehp ignored DLLSC. Reference: PCI-SIG. PCI Express Base Specification Revision 4.0 Version 0.3 (PCI-SIG, 2014): 7.8.11. Slot Status Register (Offset 1Ah). [bhelgaas: add e48f1b67f668 ref and stable tag] Fixes: e48f1b67f668 ("PCI: pciehp: Use link change notifications for hot-plug and removal") Link: https://bugzilla.kernel.org/show_bug.cgi?id=79611 Signed-off-by: Myron Stowe Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 360049733665da5875bbe91d26d029575b768656 Author: Guo Chao Date: Thu Jul 3 18:30:29 2014 -0600 PCI: Keep original resource if we fail to expand it commit c33377082dd9ede1e998f7ce416077e4b1c2276c upstream. If we have space assigned to a resource, we try to expand the resource (e.g., to accommodate SR-IOV resources), and the expansion attempt fails, we should keep the original assignment. After bd064f0a231a ("PCI: Mark resources as IORESOURCE_UNSET if we can't assign them"), we left the resource marked IORESOURCE_UNSET when the expansion failed, even if it had originally been set. That caused errors like this: pci 0003:00:00.0: can't enable device: BAR 15 [mem size 0x0c000000 64bit pref] not assigned pci 0003:00:00.0: Error enabling bridge (-22), continuing Fix this by restoring the original flags when reassignment fails. [bhelgaas: reworked to simplify, changelog] Fixes: bd064f0a231a ("PCI: Mark resources as IORESOURCE_UNSET if we can't assign them") Signed-off-by: Guo Chao Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 3ade630fc60a19d1176cc88f46199b2a49d0a779 Author: Vidya Sagar Date: Wed Jul 16 15:33:42 2014 +0530 PCI: Configure ASPM when enabling device commit 1f6ae47ecff7f23da73417e068018b311f3b5583 upstream. We can't do ASPM configuration at enumeration-time because enabling it makes some defective hardware unresponsive, even if ASPM is disabled later (see 41cd766b0659 ("PCI: Don't enable aspm before drivers have had a chance to veto it"). Therefore, we have to do it after a driver claims the device. We previously configured ASPM in pci_set_power_state(), but that's not a very good place because it's not really related to setting the PCI device power state, and doing it there means: - We incorrectly skipped ASPM config when setting a device that's already in D0 to D0. - We unnecessarily configured ASPM when setting a device to a low-power state (the ASPM feature only applies when the device is in D0). - We unnecessarily configured ASPM when called from a .resume() method (ASPM configuration needs to be restored during resume, but pci_restore_pcie_state() should already do this). Move ASPM configuration from pci_set_power_state() to do_pci_enable_device() so we do it when a driver enables a device. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=79621 Fixes: db288c9c5f9d ("PCI / PM: restore the original behavior of pci_set_power_state()") Suggested-by: Bjorn Helgaas Signed-off-by: Vidya Sagar Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 8912590e88cefeddd70270987a336e7e81a87552 Author: Alex Deucher Date: Thu Aug 21 10:55:07 2014 -0400 drm/radeon: add additional SI pci ids commit 37dbeab788a8f23fd946c0be083e5484d6f929a1 upstream. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b7561c9e352099a953b0b78a2ead3eae4fa33ac7 Author: Alex Deucher Date: Thu Aug 21 10:48:11 2014 -0400 drm/radeon: add new bonaire pci ids commit 5fc540edc8ea1297c76685f74bc82a2107fe6731 upstream. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit cb521eaa29b085ab22db0f8a647583b92365f62f Author: Alex Deucher Date: Thu Aug 21 10:41:42 2014 -0400 drm/radeon: add new KV pci id commit 6dc14baf4ced769017c7a7045019c7a19f373865 upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=82912 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 08b9d6b9eaf616f94cddb23216ac5e9b9a589cd0 Author: Theodore Ts'o Date: Sat Aug 23 17:47:28 2014 -0400 ext4: fix BUG_ON in mb_free_blocks() commit c99d1e6e83b06744c75d9f5e491ed495a7086b7b upstream. If we suffer a block allocation failure (for example due to a memory allocation failure), it's possible that we will call ext4_discard_allocated_blocks() before we've actually allocated any blocks. In that case, fe_len and fe_start in ac->ac_f_ex will still be zero, and this will result in mb_free_blocks(inode, e4b, 0, 0) triggering the BUG_ON on mb_free_blocks(): BUG_ON(last >= (sb->s_blocksize << 3)); Fix this by bailing out of ext4_discard_allocated_blocks() if fs_len is zero. Also fix a missing ext4_mb_unload_buddy() call in ext4_discard_allocated_blocks(). Google-Bug-Id: 16844242 Fixes: 86f0afd463215fc3e58020493482faa4ac3a4d69 Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 35df08d69519d3a0e92c18b62e434c926ba63164 Author: Michael S. Tsirkin Date: Tue Aug 19 19:14:50 2014 +0800 kvm: iommu: fix the third parameter of kvm_iommu_put_pages (CVE-2014-3601) commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream. The third parameter of kvm_iommu_put_pages is wrong, It should be 'gfn - slot->base_gfn'. By making gfn very large, malicious guest or userspace can cause kvm to go to this error path, and subsequently to pass a huge value as size. Alternatively if gfn is small, then pages would be pinned but never unpinned, causing host memory leak and local DOS. Passing a reasonable but large value could be the most dangerous case, because it would unpin a page that should have stayed pinned, and thus allow the device to DMA into arbitrary memory. However, this cannot happen because of the condition that can trigger the error: - out of memory (where you can't allocate even a single page) should not be possible for the attacker to trigger - when exceeding the iommu's address space, guest pages after gfn will also exceed the iommu's address space, and inside kvm_iommu_put_pages() the iommu_iova_to_phys() will fail. The page thus would not be unpinned at all. Reported-by: Jack Morgenstein Signed-off-by: Michael S. Tsirkin Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 836251bf9278993862f573a40452594b2dd89b3f Author: Paolo Bonzini Date: Mon Aug 18 16:39:48 2014 +0200 Revert "KVM: x86: Increase the number of fixed MTRR regs to 10" commit 0d234daf7e0a3290a3a20c8087eefbd6335a5bd4 upstream. This reverts commit 682367c494869008eb89ef733f196e99415ae862, which causes 32-bit SMP Windows 7 guests to panic. SeaBIOS has a limit on the number of MTRRs that it can handle, and this patch exceeded the limit. Better revert it. Thanks to Nadav Amit for debugging the cause. Reported-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f5c694cf797f7e6652125fbf7d781a76aeab6527 Author: Wanpeng Li Date: Tue Aug 5 12:42:24 2014 +0800 KVM: nVMX: fix "acknowledge interrupt on exit" when APICv is in use commit 56cc2406d68c0f09505c389e276f27a99f495cbd upstream. After commit 77b0f5d (KVM: nVMX: Ack and write vector info to intr_info if L1 asks us to), "Acknowledge interrupt on exit" behavior can be emulated. To do so, KVM will ask the APIC for the interrupt vector if during a nested vmexit if VM_EXIT_ACK_INTR_ON_EXIT is set. With APICv, kvm_get_apic_interrupt would return -1 and give the following WARNING: Call Trace: [] dump_stack+0x49/0x5e [] warn_slowpath_common+0x7c/0x96 [] ? nested_vmx_vmexit+0xa4/0x233 [kvm_intel] [] warn_slowpath_null+0x15/0x17 [] nested_vmx_vmexit+0xa4/0x233 [kvm_intel] [] ? nested_vmx_exit_handled+0x6a/0x39e [kvm_intel] [] ? kvm_apic_has_interrupt+0x80/0xd5 [kvm] [] vmx_check_nested_events+0xc3/0xd3 [kvm_intel] [] inject_pending_event+0xd0/0x16e [kvm] [] vcpu_enter_guest+0x319/0x704 [kvm] To fix this, we cannot rely on the processor's virtual interrupt delivery, because "acknowledge interrupt on exit" must only update the virtual ISR/PPR/IRR registers (and SVI, which is just a cache of the virtual ISR) but it should not deliver the interrupt through the IDT. Thus, KVM has to deliver the interrupt "by hand", similar to the treatment of EOI in commit fc57ac2c9ca8 (KVM: lapic: sync highest ISR to hardware apic on EOI, 2014-05-14). The patch modifies kvm_cpu_get_interrupt to always acknowledge an interrupt; there are only two callers, and the other is not affected because it is never reached with kvm_apic_vid_enabled() == true. Then it modifies apic_set_isr and apic_clear_irr to update SVI and RVI in addition to the registers. Suggested-by: Paolo Bonzini Suggested-by: "Zhang, Yang Z" Tested-by: Liu, RongrongX Tested-by: Felipe Reyes Fixes: 77b0f5d67ff2781f36831cba79674c3e97bd7acf Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d376ef4620b1d17e63c9878da6f88c0e5a890d9f Author: Alexey Kardashevskiy Date: Sat Jul 19 17:59:34 2014 +1000 KVM: PPC: Book3S: Fix LPCR one_reg interface commit a0840240c0c6bcbac8f0f5db11f95c19aaf9b52f upstream. Unfortunately, the LPCR got defined as a 32-bit register in the one_reg interface. This is unfortunate because KVM allows userspace to control the DPFD (default prefetch depth) field, which is in the upper 32 bits. The result is that DPFD always get set to 0, which reduces performance in the guest. We can't just change KVM_REG_PPC_LPCR to be a 64-bit register ID, since that would break existing userspace binaries. Instead we define a new KVM_REG_PPC_LPCR_64 id which is 64-bit. Userspace can still use the old KVM_REG_PPC_LPCR id, but it now only modifies those fields in the bottom 32 bits that userspace can modify (ILE, TC and AIL). If userspace uses the new KVM_REG_PPC_LPCR_64 id, it can modify DPFD as well. Signed-off-by: Alexey Kardashevskiy Signed-off-by: Paul Mackerras Signed-off-by: Alexander Graf Signed-off-by: Greg Kroah-Hartman commit dd713bdfd1e1b4d7a33a3a6f91e5e9886d13af4b Author: Christian Borntraeger Date: Fri Jul 25 14:23:29 2014 +0200 KVM: s390/mm: Fix page table locking vs. split pmd lock commit 55e4283c3eb1d850893f645dd695c9c75d5fa1fc upstream. commit ec66ad66a0de87866be347b5ecc83bd46427f53b (s390/mm: enable split page table lock for PMD level) activated the split pmd lock for s390. Turns out that we missed one place: We also have to take the pmd lock instead of the page table lock when we reallocate the page tables (==> changing entries in the PMD) during sie enablement. Signed-off-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit e54e26909c9aa220379a19509c491fa14855185a Author: Paolo Bonzini Date: Wed Jul 30 18:07:24 2014 +0200 KVM: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table commit 0f6c0a740b7d3e1f3697395922d674000f83d060 upstream. Currently, the EOI exit bitmap (used for APICv) does not include interrupts that are masked. However, this can cause a bug that manifests as an interrupt storm inside the guest. Alex Williamson reported the bug and is the one who really debugged this; I only wrote the patch. :) The scenario involves a multi-function PCI device with OHCI and EHCI USB functions and an audio function, all assigned to the guest, where both USB functions use legacy INTx interrupts. As soon as the guest boots, interrupts for these devices turn into an interrupt storm in the guest; the host does not see the interrupt storm. Basically the EOI path does not work, and the guest continues to see the interrupt over and over, even after it attempts to mask it at the APIC. The bug is only visible with older kernels (RHEL6.5, based on 2.6.32 with not many changes in the area of APIC/IOAPIC handling). Alex then tried forcing bit 59 (corresponding to the USB functions' IRQ) on in the eoi_exit_bitmap and TMR, and things then work. What happens is that VFIO asserts IRQ11, then KVM recomputes the EOI exit bitmap. It does not have set bit 59 because the RTE was masked, so the IOAPIC never sees the EOI and the interrupt continues to fire in the guest. My guess was that the guest is masking the interrupt in the redirection table in the interrupt routine, i.e. while the interrupt is set in a LAPIC's ISR, The simplest fix is to ignore the masking state, we would rather have an unnecessary exit rather than a missed IRQ ACK and anyway IOAPIC interrupts are not as performance-sensitive as for example MSIs. Alex tested this patch and it fixed his bug. [Thanks to Alex for his precise description of the problem and initial debugging effort. A lot of the text above is based on emails exchanged with him.] Reported-by: Alex Williamson Tested-by: Alex Williamson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 540b55f9cbbdac37e2fd278a1072eaa2d833a2d5 Author: Nadav Amit Date: Sun Jun 15 16:12:59 2014 +0300 KVM: x86: Inter-privilege level ret emulation is not implemeneted commit 9e8919ae793f4edfaa29694a70f71a515ae9942a upstream. Return unhandlable error on inter-privilege level ret instruction. This is since the current emulation does not check the privilege level correctly when loading the CS, and does not pop RSP/SS as needed. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 306ccdfd7d0dcc3579770a0803bb5d23878501a9 Author: Steven Rostedt Date: Mon Jun 9 14:06:07 2014 -0400 debugfs: Fix corrupted loop in debugfs_remove_recursive commit 485d44022a152c0254dd63445fdb81c4194cbf0e upstream. [ I'm currently running my tests on it now, and so far, after a few hours it has yet to blow up. I'll run it for 24 hours which it never succeeded in the past. ] The tracing code has a way to make directories within the debugfs file system as well as deleting them using mkdir/rmdir in the instance directory. This is very limited in functionality, such as there is no renames, and the parent directory "instance" can not be modified. The tracing code creates the instance directory from the debugfs code and then replaces the dentry->d_inode->i_op with its own to allow for mkdir/rmdir to work. When these are called, the d_entry and inode locks need to be released to call the instance creation and deletion code. That code has its own accounting and locking to serialize everything to prevent multiple users from causing harm. As the parent "instance" directory can not be modified this simplifies things. I created a stress test that creates several threads that randomly creates and deletes directories thousands of times a second. The code stood up to this test and I submitted it a while ago. Recently I added a new test that adds readers to the mix. While the instance directories were being added and deleted, readers would read from these directories and even enable tracing within them. This test was able to trigger a bug: general protection fault: 0000 [#1] PREEMPT SMP Modules linked in: ... CPU: 3 PID: 17789 Comm: rmdir Tainted: G W 3.15.0-rc2-test+ #41 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000 RIP: 0010:[] [] debugfs_remove_recursive+0x1bd/0x367 RSP: 0018:ffff880077019df8 EFLAGS: 00010246 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7 FS: 00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0 Stack: ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640 0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000 00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28 Call Trace: [] ? instance_rmdir+0x15b/0x1de [] ? vfs_rmdir+0x80/0xd3 [] ? do_rmdir+0xd1/0x139 [] ? trace_hardirqs_on_thunk+0x3a/0x3c [] ? system_call_fastpath+0x16/0x1b Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08 RIP [] debugfs_remove_recursive+0x1bd/0x367 RSP It took a while, but every time it triggered, it was always in the same place: list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) { Where the child->d_u.d_child seemed to be corrupted. I added lots of trace_printk()s to see what was wrong, and sure enough, it was always the child's d_u.d_child field. I looked around to see what touches it and noticed that in __dentry_kill() which calls dentry_free(): static void dentry_free(struct dentry *dentry) { /* if dentry was never visible to RCU, immediate free is OK */ if (!(dentry->d_flags & DCACHE_RCUACCESS)) __d_free(&dentry->d_u.d_rcu); else call_rcu(&dentry->d_u.d_rcu, __d_free); } I also noticed that __dentry_kill() unlinks the child->d_u.child under the parent->d_lock spin_lock. Looking back at the loop in debugfs_remove_recursive() it never takes the parent->d_lock to do the list walk. Adding more tracing, I was able to prove this was the issue: ftrace-t-15385 1.... 246662024us : dentry_kill : free ffff88006d573600 rmdir-15409 2.... 246662024us : debugfs_remove_recursive : child=ffff88006d573600 next=dead000000100058 The dentry_kill freed ffff88006d573600 just as the remove recursive was walking it. In order to fix this, the list walk needs to be modified a bit to take the parent->d_lock. The safe version is no longer necessary, as every time we remove a child, the parent->d_lock must be released and the list walk must start over. Each time a child is removed, even though it may still be on the list, it should be skipped by the first check in the loop: if (!debugfs_positive(child)) continue; Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 5bdc9b9d053238a771e3345e919f1eee74a74ad6 Author: Arnd Bergmann Date: Thu Jun 26 13:43:02 2014 +0200 crypto: ux500 - make interrupt mode plausible commit e1f8859ee265fc89bd21b4dca79e8e983a044892 upstream. The interrupt handler in the ux500 crypto driver has an obviously incorrect way to access the data buffer, which for a while has caused this build warning: ../ux500/cryp/cryp_core.c: In function 'cryp_interrupt_handler': ../ux500/cryp/cryp_core.c:234:5: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast [enabled by default] writel_relaxed(ctx->indata, ^ In file included from ../include/linux/swab.h:4:0, from ../include/uapi/linux/byteorder/big_endian.h:12, from ../include/linux/byteorder/big_endian.h:4, from ../arch/arm/include/uapi/asm/byteorder.h:19, from ../include/asm-generic/bitops/le.h:5, from ../arch/arm/include/asm/bitops.h:340, from ../include/linux/bitops.h:33, from ../include/linux/kernel.h:10, from ../include/linux/clk.h:16, from ../drivers/crypto/ux500/cryp/cryp_core.c:12: ../include/uapi/linux/swab.h:57:119: note: expected '__u32' but argument is of type 'const u8 *' static inline __attribute_const__ __u32 __fswab32(__u32 val) There are at least two, possibly three problems here: a) when writing into the FIFO, we copy the pointer rather than the actual data we want to give to the hardware b) the data pointer is an array of 8-bit values, while the FIFO is 32-bit wide, so both the read and write access fail to do a proper type conversion c) This seems incorrect for big-endian kernels, on which we need to byte-swap any register access, but not normally FIFO accesses, at least the DMA case doesn't do it either. This converts the bogus loop to use the same readsl/writesl pair that we use for the two other modes (DMA and polling). This is more efficient and consistent, and probably correct for endianess. The bug has existed since the driver was first merged, and was probably never detected because nobody tried to use interrupt mode. It might make sense to backport this fix to stable kernels, depending on how the crypto maintainers feel about that. Signed-off-by: Arnd Bergmann Cc: linux-crypto@vger.kernel.org Cc: Fabio Baltieri Cc: Linus Walleij Cc: Herbert Xu Cc: "David S. Miller" Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 0a11a0ce4802d4648c4d08969389726b7dd41f11 Author: Peter Hurley Date: Wed Jul 9 09:21:14 2014 -0400 serial: core: Preserve termios c_cflag for console resume commit ae84db9661cafc63d179e1d985a2c5b841ff0ac4 upstream. When a tty is opened for the serial console, the termios c_cflag settings are inherited from the console line settings. However, if the tty is subsequently closed, the termios settings are lost. This results in a garbled console if the console is later suspended and resumed. Preserve the termios c_cflag for the serial console when the tty is shutdown; this reflects the most recent line settings. Fixes: Bugzilla #69751, 'serial console does not wake from S3' Reported-by: Valerio Vanni Acked-by: Alan Cox Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 868be28e321b764da29592cfd9fd659434e823aa Author: Theodore Ts'o Date: Wed Jul 30 22:17:17 2014 -0400 ext4: fix ext4_discard_allocated_blocks() if we can't allocate the pa struct commit 86f0afd463215fc3e58020493482faa4ac3a4d69 upstream. If there is a failure while allocating the preallocation structure, a number of blocks can end up getting marked in the in-memory buddy bitmap, and then not getting released. This can result in the following corruption getting reported by the kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:758: group 1126, 12793 clusters in bitmap, 12729 in gd In that case, we need to release the blocks using mb_free_blocks(). Tested: fs smoke test; also demonstrated that with injected errors, the file system is no longer getting corrupted Google-Bug-Id: 16657874 Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit ccc8bd5c3264262e8527e068ee5f33bc68257338 Author: Lukas Czerner Date: Tue Jul 15 06:03:38 2014 -0400 ext4: fix punch hole on files with indirect mapping commit 4f579ae7de560e5f449587a6c3f02594d53d4d51 upstream. Currently punch hole code on files with direct/indirect mapping has some problems which may lead to a data loss. For example (from Jan Kara): fallocate -n -p 10240000 4096 will punch the range 10240000 - 12632064 instead of the range 1024000 - 10244096. Also the code is a bit weird and it's not using infrastructure provided by indirect.c, but rather creating it's own way. This patch fixes the issues as well as making the operation to run 4 times faster from my testing (punching out 60GB file). It uses similar approach used in ext4_ind_truncate() which takes advantage of ext4_free_branches() function. Also rename the ext4_free_hole_blocks() to something more sensible, like the equivalent we have for extent mapped files. Call it ext4_ind_remove_space(). This has been tested mostly with fsx and some xfstests which are testing punch hole but does not require unwritten extents which are not supported with direct/indirect mapping. Not problems showed up even with 1024k block size. Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit da65260675d977aec93a59771721e32bffdbd043 Author: addy ke Date: Fri Aug 8 17:41:40 2014 +0800 i2c: rk3x: fix interrupt handling issue commit 9c5f7cad3acc69ce623d04d646950183a759949e upstream. If slave holds scl, I2C_IPD[7] will be set 1 by controller for debugging. Driver must ignore it. [ 5.752391] rk3x-i2c ff160000.i2c: unexpected irq in WRITE: 0x80 [ 5.939027] rk3x-i2c ff160000.i2c: timeout, ipd: 0x80, state: 4 Signed-off-by: Addy Ke Reviewed-by: Heiko Stuebner Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit eec28d8e5a66f37d3549f30a00a8b461ea203066 Author: Wolfram Sang Date: Mon Jul 21 11:42:03 2014 +0200 drivers/i2c/busses: use correct type for dma_map/unmap commit 28772ac8711e4d7268c06e765887dd8cb6924f98 upstream. dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'. Signed-off-by: Wolfram Sang Acked-by: Ludovic Desroches Signed-off-by: Greg Kroah-Hartman commit fe1df3fb351f56721db389eb1b3721c682bc75f4 Author: Jason Gunthorpe Date: Sat Nov 9 11:17:00 2013 -0700 tpm: Add missing tpm_do_selftest to ST33 I2C driver commit f07a5e9a331045e976a3d317ba43d14859d9407c upstream. Most device drivers do call 'tpm_do_selftest' which executes a TPM_ContinueSelfTest. tpm_i2c_stm_st33 is just pointlessly different, I think it is bug. These days we have the general assumption that the TPM is usable by the kernel immediately after the driver is finished, so we can no longer defer the mandatory self test to userspace. Reported-by: Richard Marciel Signed-off-by: Jason Gunthorpe Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit 99348bdedca59b84ab42db96377880e72450f2b5 Author: Axel Lin Date: Tue Aug 5 10:08:31 2014 +0800 hwmon: (lm92) Prevent overflow problem when writing large limits commit 5b963089161b8fb244889c972edf553b9d737545 upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. The hysteresis temperature range depends on the value of data->temp[attr->index], since val is subtracted from it. Use a wider clamp, [-120000, 220000] should do to cover the possible range. Also add missing TEMP_TO_REG() on writes into cached hysteresis value. Also uses clamp_val to simplify the code a bit. Signed-off-by: Axel Lin [Guenter Roeck: Fixed double TEMP_TO_REG on hysteresis updates] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 26a05f267c31903055b5a54fc88bcd5ef711da73 Author: Axel Lin Date: Wed Aug 6 08:02:44 2014 +0800 hwmon: (dme1737) Prevent overflow problem when writing large limits commit d58e47d787c09fe5c61af3c6ce7d784762f29c3d upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Voltage limits, fan minimum speed, pwm frequency, pwm ramp rate, and other attributes have the same problem, fix them as well. Zone temperature limits are signed, but were cached as u8, causing unepected values to be reported for negative temperatures. Cache as s8 to fix the problem. vrm is an u8, so the written value needs to be limited to [0, 255]. Signed-off-by: Axel Lin [Guenter Roeck: Fix zone temperature cache] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 58e566ec41cd2fa203a1f917ffb7810c18dfabc8 Author: Axel Lin Date: Tue Aug 5 09:59:49 2014 +0800 hwmon: (ads1015) Fix out-of-bounds array access commit e981429557cbe10c780fab1c1a237cb832757652 upstream. Current code uses data_rate as array index in ads1015_read_adc() and uses pga as array index in ads1015_reg_to_mv, so we must make sure both data_rate and pga settings are in valid value range. Return -EINVAL if the setting is out-of-range. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 8c0a3ce257982b44ec1a67602a8d26f973fe8aaa Author: Guenter Roeck Date: Tue Jul 29 22:23:12 2014 -0700 hwmon: (lm85) Fix various errors on attribute writes commit 3248c3b771ddd9d31695da17ba350eb6e1b80a53 upstream. Temperature limit register writes did not account for negative numbers. As a result, writing -127000 resulted in -126000 written into the temperature limit register. This problem affected temp[1-3]_min, temp[1-3]_max, temp[1-3]_auto_temp_crit, and temp[1-3]_auto_temp_min. When writing pwm[1-3]_freq, a long variable was auto-converted into an int without range check. Wiring values larger than MAXINT resulted in unexpected register values. When writing temp[1-3]_auto_temp_max, an unsigned long variable was auto-converted into an int without range check. Writing values larger than MAXINT resulted in unexpected register values. vrm is an u8, so the written value needs to be limited to [0, 255]. Cc: Axel Lin Reviewed-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit ecba6775bfe1ba997d125d45235f88bc144c3a50 Author: Axel Lin Date: Wed Jul 30 11:13:52 2014 +0800 hwmon: (ads1015) Fix off-by-one for valid channel index checking commit 56de1377ad92f72ee4e5cb0faf7a9b6048fdf0bf upstream. Current code uses channel as array index, so the valid channel value is 0 .. ADS1015_CHANNELS - 1. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 0429797f80eadbc707789d205759d40d0378abbf Author: Axel Lin Date: Sat Aug 2 13:36:38 2014 +0800 hwmon: (gpio-fan) Prevent overflow problem when writing large limits commit 2565fb05d1e9fc0831f7b1c083bcfcb1cba1f020 upstream. On platforms with sizeof(int) < sizeof(unsigned long), writing a rpm value larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from unsigned long to int to fix the problem. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 0a98f94333be31a9918a7b826249661281800bcf Author: Guenter Roeck Date: Tue Jul 29 20:48:59 2014 -0700 hwmon: (lm78) Fix overflow problems seen when writing large temperature limits commit 1074d683a51f1aded3562add9ef313e75d557327 upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Cc: Axel Lin Reviewed-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit cbde0b494ebc1a08c0200185ce2aa91409beb62d Author: Axel Lin Date: Thu Jul 31 09:43:19 2014 +0800 hwmon: (amc6821) Fix possible race condition bug commit cf44819c98db11163f58f08b822d626c7a8f5188 upstream. Ensure mutex lock protects the read-modify-write period to prevent possible race condition bug. In additional, update data->valid should also be protected by the mutex lock. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 49aad90172d1f48dc76091ec6522cf55a0c31f31 Author: Axel Lin Date: Thu Jul 31 22:27:04 2014 +0800 hwmon: (sis5595) Prevent overflow problem when writing large limits commit cc336546ddca8c22de83720632431c16a5f9fe9a upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4f46f895a8da8284fcc6b4394242a94e1facbd96 Author: Ulf Hansson Date: Thu Jun 12 15:01:57 2014 +0200 mmc: mmci: Move all CMD irq handling to mmci_cmd_irq() commit ad82bfea44835da9633548e2031a1af4a9965c14 upstream. This patch won't change the behavior of how mmci deals with CMD irqs. By moving code from mmci_irq() to mmci_cmd_irq(), we getter a better overview of what going on. Cc: Peter Maydell Cc: John Stultz Cc: Russell King Tested-by: Kees Cook Tested-by: John Stultz Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d34227cdbbdf5d8fe6e274b94974ad2e94686fe6 Author: Ulf Hansson Date: Thu Jun 12 14:42:23 2014 +0200 mmc: mmci: Remove redundant check of status for DATA irq commit 1cb9da502835dad73dda772b20c1e792f4e71589 upstream. We don't need to verify the content of the status register twice, while we are about to handle a DATA irq. Instead let's leave all verification to be handled by mmci_data_irq(). Cc: Peter Maydell Cc: John Stultz Cc: Russell King Tested-by: Kees Cook Tested-by: John Stultz Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 9a35c3ef8c7afffec42bb806cd03c53bb7b57020 Author: Russell King Date: Sat Jul 12 10:53:41 2014 +0100 drm: omapdrm: fix compiler errors commit 2d31ca3ad7d5d44c8adc7f253c96ce33f3a2e931 upstream. Regular randconfig nightly testing has detected problems with omapdrm. omapdrm fails to build when the kernel is built to support 64-bit DMA addresses and/or 64-bit physical addresses due to an assumption about the width of these types. Use %pad to print DMA addresses, rather than %x or %Zx (which is even more wrong than %x). Avoid passing a uint32_t pointer into a function which expects dma_addr_t pointer. drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply': drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Werror=format] drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Werror=format] make[5]: *** [drivers/gpu/drm/omapdrm/omap_plane.o] Error 1 drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_get_paddr': drivers/gpu/drm/omapdrm/omap_gem.c:794:4: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' [-Werror=format] drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_describe': drivers/gpu/drm/omapdrm/omap_gem.c:991:4: error: format '%Zx' expects argument of type 'size_t', but argument 7 has type 'dma_addr_t' [-Werror=format] drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_init': drivers/gpu/drm/omapdrm/omap_gem.c:1470:4: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Werror=format] make[5]: *** [drivers/gpu/drm/omapdrm/omap_gem.o] Error 1 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c: In function 'dmm_txn_append': drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:226:2: error: passing argument 3 of 'alloc_dma' from incompatible pointer type [-Werror] make[5]: *** [drivers/gpu/drm/omapdrm/omap_dmm_tiler.o] Error 1 make[5]: Target `__build' not remade because of errors. make[4]: *** [drivers/gpu/drm/omapdrm] Error 2 Signed-off-by: Russell King Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 3d111c8a18244debd152e8e10ddea871e8a56d9d Author: Jeremy Vial Date: Thu Jul 31 15:10:33 2014 +0200 ARM: OMAP3: Fix choice of omap3_restore_es function in OMAP34XX rev3.1.2 case. commit 9b5f7428f8b16bd8980213f2b70baf1dd0b9e36c upstream. According to the comment “restore_es3: applies to 34xx >= ES3.0" in "arch/arm/mach-omap2/sleep34xx.S”, omap3_restore_es3 should be used if the revision of an OMAP34xx is ES3.1.2. Signed-off-by: Jeremy Vial Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit fffc11e12291b99f25eb55fe9052c077577a1093 Author: Baruch Siach Date: Wed Jul 9 13:33:13 2014 +0100 ARM: 8097/1: unistd.h: relocate comments back to place commit bc994c77ce82576209dcf08f71de9ae51b0b100f upstream. Commit cb8db5d45 (UAPI: (Scripted) Disintegrate arch/arm/include/asm) moved these syscall comments out of their context into the UAPI headers. Fix this. Fixes: cb8db5d4578a ("UAPI: (Scripted) Disintegrate arch/arm/include/asm") Signed-off-by: Baruch Siach Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 8c4239d6b9615a5673e3dfcba0461f6683b49195 Author: Suman Anna Date: Fri Jul 11 16:44:37 2014 -0500 ARM: dts: AM4372: Correct mailbox node data commit 44e6ab1b619853f05bf7250e55a6d82864e340d7 upstream. The mailbox DT node for AM4372 is enabled and is corrected to remove some properties that have crept in by mistake. Fixes: 9e3269b (ARM: dts: AM4372: Add L2, EDMA, mailbox, MMC and SHAM nodes) Signed-off-by: Suman Anna Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit e4c353d25fcefd4be9a85f696a2775426d956523 Author: Semen Protsenko Date: Fri Aug 15 16:22:44 2014 +0300 efi/arm64: Store Runtime Services revision commit 6a7519e81321343165f89abb8b616df186d3e57a upstream. "efi" global data structure contains "runtime_version" field which must be assigned in order to use it later in Runtime Services virtual calls (virt_efi_* functions). Before this patch "runtime_version" was unassigned (0), so each Runtime Service virtual call that checks revision would fail. Signed-off-by: Semen Protsenko Acked-by: Ard Biesheuvel Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit b0daf4dfc34cb2e638da582889b2ac32f0ba98a6 Author: Will Deacon Date: Thu Jul 31 11:36:08 2014 +0100 arm64: don't call break hooks for BRK exceptions from EL0 commit c878e0cff5c5e56b216951cbe75f7a3dd500a736 upstream. Our break hooks are used to handle brk exceptions from kgdb (and potentially kprobes if that code ever resurfaces), so don't bother calling them if the BRK exception comes from userspace. This prevents userspace from trapping to a kdb shell on systems where kgdb is enabled and active. Reported-by: Omar Sandoval Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit b991e16449d59404a45699b629d720e3c699df3c Author: Catalin Marinas Date: Mon Jun 9 11:55:03 2014 +0100 arm64: Fix barriers used for page table modifications commit 7f0b1bf04511348995d6fce38c87c98a3b5cb781 upstream. The architecture specification states that both DSB and ISB are required between page table modifications and subsequent memory accesses using the corresponding virtual address. When TLB invalidation takes place, the tlb_flush_* functions already have the necessary barriers. However, there are other functions like create_mapping() for which this is not the case. The patch adds the DSB+ISB instructions in the set_pte() function for valid kernel mappings. The invalid pte case is handled by tlb_flush_* and the user mappings in general have a corresponding update_mmu_cache() call containing a DSB. Even when update_mmu_cache() isn't called, the kernel can still cope with an unlikely spurious page fault by re-executing the instruction. In addition, the set_pmd, set_pud() functions gain an ISB for architecture compliance when block mappings are created. Signed-off-by: Catalin Marinas Reported-by: Leif Lindholm Acked-by: Steve Capper Cc: Will Deacon Signed-off-by: Greg Kroah-Hartman commit c1d97766689182f2d8e79eae5c58b0901ee200c3 Author: Daniel Bristot de Oliveira Date: Tue Jul 22 23:27:41 2014 -0300 sched: Fix sched_setparam() policy == -1 logic commit d8d28c8f00e84a72e8bee39a85835635417bee49 upstream. The scheduler uses policy == -1 to preserve the current policy state to implement sched_setparam(). But, as (int) -1 is equals to 0xffffffff, it's matching the if (policy & SCHED_RESET_ON_FORK) on _sched_setscheduler(). This match changes the policy value to an invalid value, breaking the sched_setparam() syscall. This patch checks policy == -1 before check the SCHED_RESET_ON_FORK flag. The following program shows the bug: int main(void) { struct sched_param param = { .sched_priority = 5, }; sched_setscheduler(0, SCHED_FIFO, ¶m); param.sched_priority = 1; sched_setparam(0, ¶m); param.sched_priority = 0; sched_getparam(0, ¶m); if (param.sched_priority != 1) printf("failed priority setting (found %d instead of 1)\n", param.sched_priority); else printf("priority setting fine\n"); } Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Peter Zijlstra Reviewed-by: Steven Rostedt Cc: Linus Torvalds Cc: linux-kernel@vger.kernel.org Fixes: 7479f3c9cf67 "sched: Move SCHED_RESET_ON_FORK into attr::sched_flags" Link: http://lkml.kernel.org/r/9ebe0566a08dbbb3999759d3f20d6004bb2dbcfa.1406079891.git.bristot@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 55c60159acdb03e6272d68c494f4c13a8643fa79 Author: Hans de Goede Date: Fri Jul 25 22:01:18 2014 +0200 xhci: Blacklist using streams on the Etron EJ168 controller commit 8f873c1ff4ca034626093d03b254e7cb8bb782dd upstream. Streams on the EJ168 do not work as they should. I've spend 2 days trying to get them to work, but without success. The first problem is that when ever you ring the stream-ring doorbell, the controller starts executing trbs at the beginning of the first ring segment, event if it ended somewhere else previously. This can be worked around by allowing enqueing only one td (not a problem with how streams are typically used) and then resetting our copies of the enqueueing en dequeueing pointers on a td completion to match what the controller seems to be doing. This way things seem to start working with uas and instead of being able to complete only the very first scsi command, the scsi core can probe the disk. But then things break later on when td-s get enqueued with more then one trb. The controller does seem to increase its dequeue pointer while executing a stream-ring (data transfer events I inserted for debugging do trigger). However execution seems to stop at the final normal trb of a multi trb td, even if there is a data transfer event inserted after the final trb. The first problem alone is a serious deviation from the spec, and esp. dealing with cancellation would have been very tricky if not outright impossible, but the second problem simply is a deal breaker altogether, so this patch simply disables streams. Note this will cause the usb-storage + uas driver pair to automatically switch to using usb-storage instead of uas on these devices, essentially reverting to the 3.14 and earlier behavior when uas was marked CONFIG_BROKEN. https://bugzilla.redhat.com/show_bug.cgi?id=1121288 https://bugzilla.kernel.org/show_bug.cgi?id=80101 Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 71433d9dfa4bedba17b555d96431314c89f4bad0 Author: Alexander Usyskin Date: Thu Jul 17 10:53:38 2014 +0300 mei: fix return value on disconnect timeout commit fe2f17eb3da38ac0d5a00c511255bf3a33d16d24 upstream. wait_event_timeout can return 0 or the remaining jiffies so return -ETIME if disconnected state not reached. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit df060ede29c85fb3c79037342b75e5666fbf1b90 Author: Alexander Usyskin Date: Thu Jul 17 10:53:36 2014 +0300 mei: don't schedule suspend in pm idle commit d5d83f8abea13d0b50ee762276c6c900d1946264 upstream. Calling pm_schedule_suspend from the runtime pm idle callback may reschedule existing timer, thus in case of frequent runtime rpm idle call the suspend maybe starved. Instead we call pm_runtime_autosuspend which is checking if the timer is already charged. An example is monitoring device pci config space. Pci config sysfs handlers calls pci_config_pm_runtime_put/get helpers which in turns calls to device idle callback Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 06dcc69217177e10028898abbf29d5cc8a582303 Author: Alexander Usyskin Date: Thu Jul 17 10:53:35 2014 +0300 mei: start disconnect request timer consistently commit 22b987a325701223f9a37db700c6eb20b9924c6f upstream. Link must be reset in case the fw doesn't respond to client disconnect request. We did charge the timer only in irq path from mei_cl_irq_close and not in mei_cl_disconnect Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit a7c2d23699f7d059498abcbffaa38d60603291ad Author: Alexander Usyskin Date: Thu Jul 17 10:53:34 2014 +0300 mei: reset client connection state on timeout commit 3e37ebb7183f0c4eb92a88c60657ac319c01b3e9 upstream. On connection timeout we leave the connecting client in connecting state. Since a new connection is stalled till previous connection is completed in this case no new connection is possible till the user space does release the file handle. Therefore on timeout we move the client to disconnected state. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 890d72d98598c475a56f74f154274086bc071563 Author: Takashi Iwai Date: Fri Aug 15 17:35:00 2014 +0200 ALSA: hda/realtek - Avoid setting wrong COEF on ALC269 & co commit f3ee07d8b6e061bf34a7167c3f564e8da4360a99 upstream. ALC269 & co have many vendor-specific setups with COEF verbs. However, some verbs seem specific to some codec versions and they result in the codec stalling. Typically, such a case can be avoided by checking the return value from reading a COEF. If the return value is -1, it implies that the COEF is invalid, thus it shouldn't be written. This patch adds the invalid COEF checks in appropriate places accessing ALC269 and its variants. The patch actually fixes the resume problem on Acer AO725 laptop. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181 Tested-by: Francesco Muzio Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 93b0526997a77113018f0ae34ce64c825cee7aa1 Author: Hui Wang Date: Tue Aug 19 12:07:03 2014 +0800 ALSA: hda - restore the gpio led after resume commit f475371aa65de84fa483a998ab7594531026b9d9 upstream. On some HP laptops, the mute led is controlled by codec gpio. When some machine resume from s3/s4, the codec gpio data will be cleared to 0 by BIOS: Before suspend: IO[3]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0 After resume: IO[3]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 To skip the AFG node to enter D3 can't fix this problem. A workaround is to restore the gpio data when the system resume back from s3/s4. It is safe even on the machines without this problem. BugLink: https://bugs.launchpad.net/bugs/1358116 Tested-by: Franz Hsieh Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 90d56ca39f7ed1c69c16e6f34ce896ea16e43c87 Author: David Henningsson Date: Tue Jul 22 11:42:17 2014 +0200 ALSA: hda - Add mute LED pin quirk for HP 15 touchsmart commit 423044744aa4c250058e976474856a7a41972182 upstream. This makes the mute LED work on a HP 15 touchsmart machine. BugLink: https://bugs.launchpad.net/bugs/1334950 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c39ef485e4d59ec4db391089f7da4996f4961a4d Author: Clemens Ladisch Date: Sat Aug 9 17:19:41 2014 +0200 ALSA: usb-audio: fix BOSS ME-25 MIDI regression commit 53da5ebfef66ea6e478ad9c6add3781472b79475 upstream. The BOSS ME-25 turns out not to have any useful descriptors in its MIDI interface, so its needs a quirk entry after all. Reported-and-tested-by: Kees van Veen Fixes: 8e5ced83dd1c ("ALSA: usb-audio: remove superfluous Roland quirks") Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 55d17469faa5358128b3a6edc8aece8be11bcaf0 Author: Takashi Iwai Date: Sun Aug 10 13:30:08 2014 +0200 ALSA: hda/ca0132 - Don't try loading firmware at resume when already failed commit e24aa0a4c5ac92a171d9dd74a8d3dbf652990d36 upstream. CA0132 driver tries to reload the firmware at resume. Usually this works since the firmware loader core caches the firmware contents by itself. However, if the driver failed to load the firmwares (e.g. missing files), reloading the firmware at resume goes through the actual file loading code path, and triggers a kernel WARNING like: WARNING: CPU: 10 PID:11371 at drivers/base/firmware_class.c:1105 _request_firmware+0x9ab/0x9d0() For avoiding this situation, this patch makes CA0132 skipping the f/w loading at resume when it failed at probe time. Reported-and-tested-by: Janek Kozicki Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a2fe338ae99f446f896d6a6cff9462cfdc18a3d5 Author: Clemens Ladisch Date: Mon Aug 4 15:17:55 2014 +0200 ALSA: virtuoso: add Xonar Essence STX II support commit f42bb22243d2ae264d721b055f836059fe35321f upstream. Just add the PCI ID for the STX II. It appears to work the same as the STX, except for the addition of the not-yet-supported daughterboard. Tested-by: Mario Tested-by: corubba Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 14835c8336e1dbc22903dc45f97740ecb75ae7c8 Author: Paul S McSpadden Date: Sun Aug 3 17:47:36 2014 -0500 ALSA: usb-audio: Adjust Gamecom 780 volume level commit 542baf94ec3c5526955b4c9fd899c7f30fae4ebe upstream. Original patch fixed the original problem, but the sound was far too low for most users. This patch references a compare matrix to allow the volume levels to act normally. I personally tested this patch myself, and volume levels returned to normal. Please see this discussion for more details: https://bugzilla.kernel.org/show_bug.cgi?id=65251 Signed-off-by: Paul S McSpadden Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 72ab8a66852e6d1159d3477f8329ea32ae40ebc3 Author: Hui Wang Date: Wed Jul 30 11:11:48 2014 +0800 ALSA: hda - fix an external mic jack problem on a HP machine commit 7440850c20b69658f322119d20a94dc914127cc7 upstream. ON the machine, two pin complex (0xb and 0xe) are both routed to the same external right-side mic jack, this makes the jack can't work. To fix this problem, set the 0xe to "not connected". BugLink: https://bugs.launchpad.net/bugs/1350148 Tested-by: Franz Hsieh Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7b9b999c206e68e9208e69e8b8823c63fc696894 Author: Pratyush Anand Date: Fri Jul 18 12:37:10 2014 +0530 USB: Fix persist resume of some SS USB devices commit a40178b2fa6ad87670fb1e5fa4024db00c149629 upstream. Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Signed-off-by: Pratyush Anand Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 2bf6557409304a8972d475d81f0d6fb26abf092f Author: Bryan O'Donoghue Date: Wed Jul 2 01:58:18 2014 -0700 USB: ehci-pci: USB host controller support for Intel Quark X1000 commit 6e693739e9b603b3ca9ce0d4f4178f0633458465 upstream. The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000 USB host controller, and the default value is 0x20 dwords. The in/out threshold can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance, but only when isochronous/interrupt transactions are not initiated by the USB host controller. This patch is to reconfigure the packet buffer in/out threshold as maximal as possible to maximize the performance, and 0x7F dwords (508 Bytes) should be used because the USB host controller initiates isochronous/interrupt transactions. Signed-off-by: Bryan O'Donoghue Signed-off-by: Alvin (Weike) Chen Acked-by: Alan Stern Reviewed-by: Jingoo Han Signed-off-by: Greg Kroah-Hartman commit f57a4db52a24888e82508e315c2556182dc81ca6 Author: Patrick Riphagen Date: Thu Jul 24 09:09:50 2014 +0200 USB: serial: ftdi_sio: Add support for new Xsens devices commit 4bdcde358b4bda74e356841d351945ca3f2245dd upstream. This adds support for new Xsens devices, using Xsens' own Vendor ID. Signed-off-by: Patrick Riphagen Signed-off-by: Frans Klaver Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3a19cc51050227eb6549b2b25a1427a057f03781 Author: Patrick Riphagen Date: Thu Jul 24 09:12:52 2014 +0200 USB: serial: ftdi_sio: Annotate the current Xsens PID assignments commit 9273b8a270878906540349422ab24558b9d65716 upstream. The converters are used in specific products. It can be useful to know which they are exactly. Signed-off-by: Patrick Riphagen Signed-off-by: Frans Klaver Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit b427ea79e9d546f3d08c8057e22bd474f34b17d4 Author: Oliver Neukum Date: Fri Aug 1 09:55:20 2014 +0200 USB: devio: fix issue with log flooding commit d310d05f1225d1f6f2bf505255fdf593bfbb3051 upstream. usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK for output URBs. That causes usbcore to log messages without limit for a nonsensical disallowed combination. The fix is to silently drop the attribute in usbfs. The problem is reported to exist since 3.14 https://www.virtualbox.org/ticket/13085 Signed-off-by: Oliver Neukum Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 6d481291409440362ce280aaf9ed3a931d8a5c81 Author: Oliver Neukum Date: Mon Jul 14 15:39:49 2014 +0200 usbcore: don't log on consecutive debounce failures of the same port commit 5ee0f803cc3a0738a63288e4a2f453c85889fbda upstream. Some laptops have an internal port for a BT device which picks up noise when the kill switch is used, but not enough to trigger printk_rlimit(). So we shouldn't log consecutive faults of this kind. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit c2f318586623cae4b6c756414cb8ca99ce474e7f Author: Alan Stern Date: Thu Jul 17 16:34:29 2014 -0400 USB: OHCI: don't lose track of EDs when a controller dies commit 977dcfdc60311e7aa571cabf6f39c36dde13339e upstream. This patch fixes a bug in ohci-hcd. When an URB is unlinked, the corresponding Endpoint Descriptor is added to the ed_rm_list and taken off the hardware schedule. Once the ED is no longer visible to the hardware, finish_unlinks() handles the URBs that were unlinked or have completed. If any URBs remain attached to the ED, the ED is added back to the hardware schedule -- but only if the controller is running. This fails when a controller dies. A non-empty ED does not get added back to the hardware schedule and does not remain on the ed_rm_list; ohci-hcd loses track of it. The remaining URBs cannot be unlinked, which causes the USB stack to hang. The patch changes finish_unlinks() so that non-empty EDs remain on the ed_rm_list if the controller isn't running. This requires moving some of the existing code around, to avoid modifying the ED's hardware fields more than once. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 963e36047caa985a5cc008424fd0500a145c2018 Author: Alan Stern Date: Thu Jul 17 16:32:26 2014 -0400 USB: OHCI: fix bugs in debug routines commit 256dbcd80f1ccf8abf421c1d72ba79a4e29941dd upstream. The debug routine fill_async_buffer() in ohci-hcd is buggy: It never produces any output because it forgets to initialize the output buffer size. Also, the debug routine ohci_dump() has an unused argument. This patch adds the correct initialization and removes the unused argument. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 98f37b96dd9a017479fc5fa35b3fefc8de2bb4b5 Author: Hans de Goede Date: Fri Aug 1 17:33:08 2014 +0200 uas: Limit qdepth to 32 when connected over usb-2 commit e2875c33787ebda21aeecc1a9d3ff52b3aa413ec upstream. Some jmicron uas chipsets act up (they disconnect from the bus) when sending more then 32 commands to them at once. Rather then building an ever growing list with usb-id based quirks for devices using this chipset, simply reduce the qdepth to 32 when connected over usb-2. 32 should be plenty to keep things close to maximum possible throughput on usb-2. Tested-and-reported-by: Laszlo T. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 32134a15e8a2a5024806dc8f794df18ae3564f00 Author: Jan Kara Date: Sun Aug 17 11:49:57 2014 +0200 isofs: Fix unbounded recursion when processing relocated directories commit 410dd3cf4c9b36f27ed4542ee18b1af5e68645a4 upstream. We did not check relocated directory in any way when processing Rock Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL entry pointing to another CL entry leading to possibly unbounded recursion in kernel code and thus stack overflow or deadlocks (if there is a loop created from CL entries). Fix the problem by not allowing CL entry to point to a directory entry with CL entry (such use makes no good sense anyway) and by checking whether CL entry doesn't point to itself. Reported-by: Chris Evans Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit fc1d74628298b9c14bd978ada534731e369dc29c Author: Jiri Kosina Date: Thu Aug 21 09:57:48 2014 -0500 HID: fix a couple of off-by-ones commit 4ab25786c87eb20857bbb715c3ae34ec8fd6a214 upstream. There are a few very theoretical off-by-one bugs in report descriptor size checking when performing a pre-parsing fixup. Fix those. Reported-by: Ben Hawkes Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit e98c81884fe28d29a48a6dfa6512deccb8482fb7 Author: Jiri Kosina Date: Thu Aug 21 09:57:17 2014 -0500 HID: logitech: perform bounds checking on device_id early enough commit ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 upstream. device_index is a char type and the size of paired_dj_deivces is 7 elements, therefore proper bounds checking has to be applied to device_index before it is used. We are currently performing the bounds checking in logi_dj_recv_add_djhid_device(), which is too late, as malicious device could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the problem in one of the report forwarding functions called from logi_dj_raw_event(). Fix this by performing the check at the earliest possible ocasion in logi_dj_raw_event(). Reported-by: Ben Hawkes Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b8c0d10f1f43301bab6146874963749003a3d567 Author: Jiri Kosina Date: Thu Aug 21 09:56:47 2014 -0500 HID: logitech: fix bounds checking on LED report size commit 51217e69697fba92a06e07e16f55c9a52d8e8945 upstream. The check on report size for REPORT_TYPE_LEDS in logi_dj_ll_raw_request() is wrong; the current check doesn't make any sense -- the report allocated by HID core in hid_hw_raw_request() can be much larger than DJREPORT_SHORT_LENGTH, and currently logi_dj_ll_raw_request() doesn't handle this properly at all. Fix the check by actually trimming down the report size properly if it is too large. Reported-by: Ben Hawkes Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit d1b28b69bc0961d7408a73d9219fa295c9d4e235 Author: Rob Kendrick Date: Wed Jul 23 10:03:58 2014 +0100 MIPS: math-emu: Fix instruction decoding. commit c3b9b945e02e011c63522761e91133ea43eb6939 upstream. Tested-by: Aurelien Jarno Reviewed-by: Aurelien Jarno Signed-off-by: Ralf Baechle Cc: Markos Chandras Signed-off-by: Greg Kroah-Hartman commit f349e64de26e0c2bef7e7f957dd9b49e5e6146e6 Author: Dave Chiluk Date: Tue Jun 24 10:11:26 2014 -0500 stable_kernel_rules: Add pointer to netdev-FAQ for network patches commit b76fc285337b6b256e9ba20a40cfd043f70c27af upstream. Stable_kernel_rules should point submitters of network stable patches to the netdev_FAQ.txt as requests for stable network patches should go to netdev first. Signed-off-by: Dave Chiluk Signed-off-by: Greg Kroah-Hartman