commit 8e952ae717dea59aa8104421dc4d3b9e66981c7d Author: Greg Kroah-Hartman Date: Fri Sep 5 16:34:59 2014 -0700 Linux 3.14.18 commit 472faa93165a83df31af25f9097b23c981d26968 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 07675d98fa2304b6c64ded1099f2b08777316241 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 efe17240f3780af81ab8f410cabc825fe958ff9b 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 862fd32cef8b6d2c1365245f38d631fb838ea90b 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 96a93162e29169cb7cd5b0343953b6e41b260b1f 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 78359f18aa15699d96b613c8cb7b43471c7157da 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 d29135ddc8f0c3084693d6770c412f3b3b94a1c0 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 323308e6f5ea6e0fa311478581c87b09fa219f9c 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 a9cedf67702b5298f730e15ccda60753b9cb7f96 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 ebc8083c7fe92a2a4ab8eed0572882c3dfd3746a 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 f0fb2f24c10bdb4964d897ae9ec276e83d4e1a5a 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 21f4a77a3fcb54e6a1c81b71f2ca14a94406b7c7 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 937f8d16add25c86fc4da26087703020df8ac26a 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 307dad0645cb01e61a78099a975a84fd9b86cc36 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 d5dbf1cb56d041075a3ad98153030d7cb7232a4d 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 769459b97e4d441edcc02dd886e7a6170b648288 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 ec93840789a96dcca9e9209220269b3a87088481 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 980fc16422e324e7bff64930003ff4899d837765 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 834adfb2e2319aea050e3b5da85dcef09b221633 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 78353ceb3c1e3526b2538188f4f005dbb07fd67c 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 08dc1706c61301a0476284edabd06618e9567674 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 3e6c4753bc410f788d81566d6d915f26ff315ba2 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 fec95c2a6e2af47f2a0aa406859d88a957b97a11 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 a848c23fb1e59ddcde23b7715b08ad8bfef78ee0 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 bd7c57d3ca1a55a601c9f9e2d3b0fe8be197ea8e 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 8a6de3b6c9dd8b1fb52b40e4aa4d6c8bd9ce0a26 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 dcc48de73f9a8d7c85f27579ba9cc11000910cd7 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 1b37263cbe5803bbd4008829910969e84e234ca1 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 cf5d3012553ae171303879e8c82f3e2e5ed00d95 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 f3ccb9a920720f514bad0d3fd8927c132150fd7d 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 8e669fe4fcd6be33c827acd303f17c588f9f0b5f 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 0a00abaee6e1b0d8ef5d5989259db2e186a204ba 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 924c4521bdb0b47ec3483be157408ced6d923cde 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 1b313b33fa279914ba462a45f80858ed8095f8f3 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 c2c5bc2de2a6da85e3a1cacd81bbe15c4322afa4 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 daaa4960907048e5c454e3f37a618b187befd933 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 51d79fc2bc76246b3f098480404837bfdf1c76eb 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 bc9043277554c6cb45d78c7fc4f6ee03787b2b75 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 639b96cc09f759a129beb065c7a09e44aeed8f88 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 e9746f982fbed12d576ab6a225494efbbb304f84 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 f92f2ce22cd58eb94386ae17a76d25b3b1d05ee0 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 6429fe880ef7ec4117a525271b462e648acfc983 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 2db7dd758bf4b599bcf8c56dde21b6e4cb9de583 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 8bafd6054e09fd2c866bf0d031855eafd29fc200 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 42a1927a7a1d9e9992a7d1cd43a797e461019e01 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 98a634d07e5d01ca089e08916477b43805e13c41 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 dfc7aa43fd0d6f706a4286dd96db676a7309961e 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 a5d5291d5ba8bea645321277b5e5786a7ef7a76b 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 f0ed4477b731c45fe4d4f22a657a8854a9664164 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 da660d1a92bdbe1b8bf74ec93ac89c4e2371e09b 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 de63adc7629e75df90814f4203a54a44cd3d10f6 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 253992a1e80fcb0a05b94ac08101b6dc228c9784 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 3677d454540c015b6c32d908ff73ef0f5d70534e 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 ee7fad10b37ac5afc1413deb42916738731062c5 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 ea05c57b12deb061e6288354a25093a097255d39 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 3a0b88ddc2933e5c7d2951cde5d1665a4047ce80 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 cfaf021518b15f5afc412e746785d3d8cca3e143 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 e5b3467d236838ee4d2b14ea3c470fd333da15b7 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 708fae99f656df1fade6ae9e8c1fdb3a68e78705 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 7d6e5a9dbeaf5788ebb9fb1471168814d7225d20 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 d9ef104e7990ad0cbe3314fa4eca192a2f8ca316 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 b0f4549190f3d46acfb0d192802aa1d21410d012 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 728d3c854de8f28464e7a3127e21abde735eb796 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 0e28d9e39645c427815ebcdd5409187e8db9b10b 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 9e260decf4c843b65ea08c8a5d5fb7644af5286a 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 c8e16cc2538ab8eb5ec23e10c95c3aa35ab0ab37 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 5d7ee4f6ec49900c1ebef87240336c73f14f174d 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 8185982aa13b9000ac7c42f936c23cbbb882a31e 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 dcb785742a05ffa8be4d00a886daa7ba5d831302 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 14334811dcf5b61fc6f43f8a5c4dfae38d927496 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 2647be2bcabab844fb5820bdbc3646f2913bacf2 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 155ffca14e35e3a8edad39c5a65524ce8b93464c 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 2d4d34e1fb4b2ed0358add1048d709b60bf94394 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 85d526418933905bf0e94b6923c264d8f4aa17be 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 1ce3b22b30dc69359499551799b0274400b05511 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 77f994024840b31bc5a8b93582756cf56d4fa1ee 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 839772d70f7455c2b7bd1f55dfad72fe4020fddb 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 d70593c4dc3484e58b27e90a673fec8db7c75c19 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 5d2ce3661231cdd37d7a504703507f8fefc6a3cb 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 42bd4b30dac9e4a0976a4b7363398454b3e4f7d7 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 21252ab1d9ed8cfee8708fa7954b5b14d69c29e9 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 55d90311ecef6ea616d44bca7efc6b395308351b 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 774710c90e906c0984b45f9591835a577f8e80f9 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 f9fd934da7adc03cb8d341a4ae4ffac038b5adff 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 3ca762283e2af911674dea8c54631d2d45b04dbf 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 1de1376b8e805c553d28354c9ae5d5fddb8bbff8 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 b165b85cb5359d7d223b6d4fa645302891c44013 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 90805fe951b65eb938f9ffaf232454a96a0cfbab 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