commit db203880b7011d880ace4894fe6afe5533c5459b Author: Greg Kroah-Hartman Date: Tue Oct 1 09:41:12 2013 -0700 Linux 3.11.3 commit a1028f77b217757b8650068568191db69c22c790 Author: Oliver Smith Date: Mon Sep 16 20:30:57 2013 +0200 netfilter: ipset: Fix serious failure in CIDR tracking commit 2cf55125c64d64cc106e204d53b107094762dfdf upstream. This fixes a serious bug affecting all hash types with a net element - specifically, if a CIDR value is deleted such that none of the same size exist any more, all larger (less-specific) values will then fail to match. Adding back any prefix with a CIDR equal to or more specific than the one deleted will fix it. Steps to reproduce: ipset -N test hash:net ipset -A test 1.1.0.0/16 ipset -A test 2.2.2.0/24 ipset -T test 1.1.1.1 #1.1.1.1 IS in set ipset -D test 2.2.2.0/24 ipset -T test 1.1.1.1 #1.1.1.1 IS NOT in set This is due to the fact that the nets counter was unconditionally decremented prior to the iteration that shifts up the entries. Now, we first check if there is a proceeding entry and if not, decrement it and return. Otherwise, we proceed to iterate and then zero the last element, which, in most cases, will already be zero. Signed-off-by: Oliver Smith Signed-off-by: Jozsef Kadlecsik Signed-off-by: Greg Kroah-Hartman commit 2236ad2913d353ecb1d78231600372def5c94473 Author: Solomon Peachy Date: Tue Aug 27 20:29:46 2013 -0400 cw1200: Don't perform SPI transfers in interrupt context commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35 upstream. When we get an interrupt from the hardware, the first thing the driver does is tell the device to mask off the interrupt line. Unfortunately this involves a SPI transaction in interrupt context. Some (most?) SPI controllers perform the transfer asynchronously and try to sleep. This is bad, and triggers a BUG(). So, work around this by using adding a hwbus hook for the cw1200 driver core to call. The cw1200_spi driver translates this into irq_disable()/irq_enable() calls instead, which can safely be called in interrupt context. Apparently the platforms I used to develop the cw1200_spi driver used synchronous spi_sync() implementations, which is why this didn't surface until now. Many thanks to Dave Sizeburns for the inital bug report and his services as a tester. Signed-off-by: Solomon Peachy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 524a992af32af99a4fa8521640ba5bb38fde41d1 Author: Solomon Peachy Date: Tue Aug 27 20:29:47 2013 -0400 cw1200: Prevent a lock-related hang in the cw1200_spi driver commit 85ba8f529c57ac6e2fca9be0d9e17920a1afb2e8 upstream. The cw1200_spi driver tries to mirror the cw1200_sdio driver's lock API, which relies on sdio_claim_host/sdio_release_host to serialize hardware operations across multiple threads. Unfortunately the implementation was flawed, as it lacked a way to wake up the lock requestor when there was contention, often resulting in a hang. This problem was uncovered while trying to fix the spi-transfers-in-interrupt-context BUG() corrected in the previous patch. Many thanks to Dave Sizeburns for his assistance in fixing this. Signed-off-by: Solomon Peachy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 4179ebecdc904aef8625afc1c227a2b591c5ed44 Author: J. Bruce Fields Date: Fri Aug 23 17:26:28 2013 -0400 rpc: let xdr layer allocate gssproxy receieve pages commit d4a516560fc96a9d486a9939bcb567e3fdce8f49 upstream. In theory the linux cred in a gssproxy reply can include up to NGROUPS_MAX data, 256K of data. In the common case we expect it to be shorter. So do as the nfsv3 ACL code does and let the xdr code allocate the pages as they come in, instead of allocating a lot of pages that won't typically be used. Tested-by: Simo Sorce Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 42c446598e47a18a48da6c8c2eab6ea73da881ee Author: J. Bruce Fields Date: Tue Aug 20 18:13:27 2013 -0400 rpc: fix huge kmalloc's in gss-proxy commit 9dfd87da1aeb0fd364167ad199f40fe96a6a87be upstream. The reply to a gssproxy can include up to NGROUPS_MAX gid's, which will take up more than a page. We therefore need to allocate an array of pages to hold the reply instead of trying to allocate a single huge buffer. Tested-by: Simo Sorce Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 25aa4abcf089f849705d232f9028516f9f95c121 Author: J. Bruce Fields Date: Fri Aug 23 11:17:53 2013 -0400 rpc: comment on linux_cred encoding, treat all as unsigned commit 6a36978e6931e6601be586eb313375335f2cfaa3 upstream. The encoding of linux creds is a bit confusing. Also: I think in practice it doesn't really matter whether we treat any of these things as signed or unsigned, but unsigned seems more straightforward: uid_t/gid_t are unsigned and it simplifies the ngroups overflow check. Tested-by: Simo Sorce Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 4a3c0a03cbc9eec8bafbcf76448494b469ef903b Author: J. Bruce Fields Date: Wed Aug 21 10:32:52 2013 -0400 rpc: clean up decoding of gssproxy linux creds commit 778e512bb1d3315c6b55832248cd30c566c081d7 upstream. We can use the normal coding infrastructure here. Two minor behavior changes: - we're assuming no wasted space at the end of the linux cred. That seems to match gss-proxy's behavior, and I can't see why it would need to do differently in the future. - NGROUPS_MAX check added: note groups_alloc doesn't do this, this is the caller's responsibility. Tested-by: Simo Sorce Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 02911e1cf4c15e4046480ae33ff44d91cd6c0b36 Author: Anatol Pomozov Date: Sun Sep 22 12:43:47 2013 -0600 cfq: explicitly use 64bit divide operation for 64bit arguments commit f3cff25f05f2ac29b2ee355e611b0657482f6f1d upstream. 'samples' is 64bit operant, but do_div() second parameter is 32. do_div silently truncates high 32 bits and calculated result is invalid. In case if low 32bit of 'samples' are zeros then do_div() produces kernel crash. Signed-off-by: Anatol Pomozov Acked-by: Tejun Heo Signed-off-by: Jens Axboe Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 9d51f688c6b430d76683a964adc947c00e23f78a Author: Bjorn Helgaas Date: Wed May 29 16:29:55 2013 -0600 bio-integrity: Fix use of bs->bio_integrity_pool after free commit adbe6991efd36104ac9eaf751993d35eaa7f493a upstream. This fixes a copy and paste error introduced by 9f060e2231 ("block: Convert integrity to bvec_alloc_bs()"). Found by Coverity (CID 1020654). Signed-off-by: Bjorn Helgaas Acked-by: Kent Overstreet Signed-off-by: Jens Axboe Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 348944504362417205107e63cfe4821aa87ec1bb Author: Khalid Aziz Date: Wed Sep 11 14:22:20 2013 -0700 mm: fix aio performance regression for database caused by THP commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream. I am working with a tool that simulates oracle database I/O workload. This tool (orion to be specific - ) allocates hugetlbfs pages using shmget() with SHM_HUGETLB flag. It then does aio into these pages from flash disks using various common block sizes used by database. I am looking at performance with two of the most common block sizes - 1M and 64K. aio performance with these two block sizes plunged after Transparent HugePages was introduced in the kernel. Here are performance numbers: pre-THP 2.6.39 3.11-rc5 1M read 8384 MB/s 5629 MB/s 6501 MB/s 64K read 7867 MB/s 4576 MB/s 4251 MB/s I have narrowed the performance impact down to the overheads introduced by THP in __get_page_tail() and put_compound_page() routines. perf top shows >40% of cycles being spent in these two routines. Every time direct I/O to hugetlbfs pages starts, kernel calls get_page() to grab a reference to the pages and calls put_page() when I/O completes to put the reference away. THP introduced significant amount of locking overhead to get_page() and put_page() when dealing with compound pages because hugepages can be split underneath get_page() and put_page(). It added this overhead irrespective of whether it is dealing with hugetlbfs pages or transparent hugepages. This resulted in 20%-45% drop in aio performance when using hugetlbfs pages. Since hugetlbfs pages can not be split, there is no reason to go through all the locking overhead for these pages from what I can see. I added code to __get_page_tail() and put_compound_page() to bypass all the locking code when working with hugetlbfs pages. This improved performance significantly. Performance numbers with this patch: pre-THP 3.11-rc5 3.11-rc5 + Patch 1M read 8384 MB/s 6501 MB/s 8371 MB/s 64K read 7867 MB/s 4251 MB/s 6510 MB/s Performance with 64K read is still lower than what it was before THP, but still a 53% improvement. It does mean there is more work to be done but I will take a 53% improvement for now. Please take a look at the following patch and let me know if it looks reasonable. [akpm@linux-foundation.org: tweak comments] Signed-off-by: Khalid Aziz Cc: Pravin B Shelar Cc: Christoph Lameter Cc: Andrea Arcangeli Cc: Johannes Weiner Cc: Mel Gorman Cc: Rik van Riel Cc: Minchan Kim Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5047adbd8567e85ac6a0f356a131663b7a32dabd Author: Konstantin Khlebnikov Date: Tue Sep 24 15:27:42 2013 -0700 audit: fix endless wait in audit_log_start() commit 8ac1c8d5deba65513b6a82c35e89e73996c8e0d6 upstream. After commit 829199197a43 ("kernel/audit.c: avoid negative sleep durations") audit emitters will block forever if userspace daemon cannot handle backlog. After the timeout the waiting loop turns into busy loop and runs until daemon dies or returns back to work. This is a minimal patch for that bug. Signed-off-by: Konstantin Khlebnikov Cc: Luiz Capitulino Cc: Richard Guy Briggs Cc: Eric Paris Cc: Chuck Anderson Cc: Dan Duval Cc: Dave Kleikamp Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit e3bbf180fae3a912252247df288665b0ebdb9c50 Author: Jan Kara Date: Thu Jul 25 16:15:16 2013 +0200 udf: Refuse RW mount of the filesystem instead of making it RO commit e729eac6f65e11c5f03b09adcc84bd5bcb230467 upstream. Refuse RW mount of udf filesystem. So far we just silently changed it to RO mount but when the media is writeable, block layer won't notice this change and thus will think device is used RW and will block eject button of the drive. That is unexpected by users because for non-writeable media eject button works just fine. Userspace mount(8) command handles this just fine and retries mounting with MS_RDONLY set so userspace shouldn't see any regression. Plus any tool mounting udf is likely confronted with the case of read-only media where block layer already refuses to mount the filesystem without MS_RDONLY set so our behavior shouldn't be anything new for it. Reported-by: Hui Wang Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit e1891c4845a169722145155688da639a44d2969f Author: Jan Kara Date: Thu Jul 25 19:10:59 2013 +0200 udf: Standardize return values in mount sequence commit d759bfa4e7919b89357de50a2e23817079889195 upstream. Change all function used in filesystem discovery during mount to user standard kernel return values - -errno on error, 0 on success instead of 1 on failure and 0 on success. This allows us to pass error number (not just failure / success) so we can abort device scanning earlier in case of errors like EIO or ENOMEM . Also we will be able to return EROFS in case writeable mount is requested but writing isn't supported. Signed-off-by: Jan Kara Cc: Hui Wang Signed-off-by: Greg Kroah-Hartman commit 80a96c500ef5de9f3ceca4bdb02a3155b43297a8 Author: Mikulas Patocka Date: Thu Sep 19 14:13:17 2013 -0400 skge: fix broken driver commit c194992cbe71c20bb3623a566af8d11b0bfaa721 upstream. The patch 136d8f377e1575463b47840bc5f1b22d94bf8f63 broke the skge driver. Note this part of the patch: + if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) { + dev_kfree_skb(nskb); + goto resubmit; + } + pci_unmap_single(skge->hw->pdev, dma_unmap_addr(e, mapaddr), dma_unmap_len(e, maplen), PCI_DMA_FROMDEVICE); skb = e->skb; prefetch(skb->data); - skge_rx_setup(skge, e, nskb, skge->rx_buf_size); The function skge_rx_setup modifies e->skb to point to the new skb. Thus, after this change, the new buffer, not the old, is returned to the networking stack. This bug is present in kernels 3.11, 3.11.1 and 3.12-rc1. The patch should be queued for 3.11-stable. Signed-off-by: Mikulas Patocka Reported-by: Mikulas Patocka Reported-by: Vasiliy Glazov Tested-by: Mikulas Patocka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0160ad17164c340a6b83d69e481624b2509f64c6 Author: Christian König Date: Sun Sep 15 13:31:28 2013 +0200 drm/radeon: avoid UVD corruptions on AGP cards commit 4f66c59922cbcda14c9e103e6c7f4ee616360d43 upstream. Putting everything into VRAM seems to help. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ec44008171fd346c31d8f54ff2e05748fa3b88f7 Author: Alex Deucher Date: Fri Sep 13 18:33:16 2013 -0400 drm/radeon: fix panel scaling with eDP and LVDS bridges commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream. We were using the wrong set_properly callback so we always ended up with Full scaling even if something else (Center or Full aspect) was selected. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a6ec1251f171fe06eda183ea40ac975336fa6a52 Author: Alex Deucher Date: Fri Sep 13 10:55:10 2013 -0400 drm/radeon/dpm/rs780: don't enable sclk scaling if not required commit e40210cca98068835acd5a4fe760bf96b3a1aa48 upstream. If the low and high sclks are the same, there is no need to enable sclk scaling. This causes display stability issues on certain boards. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60857 Signed-off-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 93a6c524b6c1822501d825c501fc778a7eb22fed Author: Alex Deucher Date: Tue Sep 10 09:40:37 2013 -0400 drm/radeon/dpm: fix fallback for empty UVD clocks commit 84f3d9f7b4781dea6e11dcaf7f81367c1b39fef0 upstream. Some older 6xx-7xx boards didn't always fill in the UVD clocks properly in the UVD power states. This leads to the driver trying to set a 0 clock which results in slow or broken UVD playback. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69120 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2777fa045530884335b9d570b4db51df753a768d Author: Alex Deucher Date: Mon Sep 9 18:56:50 2013 -0400 drm/radeon/dpm: handle bapm on trinity commit ef4e03658420bbf91365647615460668c2510e79 upstream. bapm is a power management feature for handling the power budget between the CPU and GPU on APUs. This patch adds support for enabling or disabling it. For now disable it by default. Enabling it properly requires quite a bit more work and will be addressed in a separate patch. This patch fixes hangs on boot on certain trinity laptops when the system is on battery power. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 00a9b0b1970d5a818cb57ae03d8213c71a460738 Author: Alex Deucher Date: Mon Sep 9 10:54:22 2013 -0400 drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2) commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream. The OUTPUT_ENABLE action jumps past the point in the coder where the data_offset is set on certain rs780 cards. This worked previously because the OUTPUT_ENABLE action is always called immediately after the ENABLE action so the data_offset remained set. In 6f8bbaf568c7f2c497558bfd04654c0b9841ad57 (drm/radeon/atom: initialize more atom interpretor elements to 0), we explictly reset data_offset to 0 between atom calls which then caused this to fail. The fix is to just skip calling the OUTPUT_ENABLE action on the problematic chipsets. The ENABLE action does the same thing and more. Ultimately, we could probably drop the OUTPUT_ENABLE action all together on DCE3 asics. fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60791 v2: only rs880 seems to be affected Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4a22ee8332dbbc138917e6838fafc5bddac4f906 Author: Alex Deucher Date: Thu Sep 5 09:52:37 2013 -0400 drm/radeon/r6xx: add a stubbed out set_uvd_clocks callback commit 1b9ba70a49ba92e910d8e5df702edf8c1858cecf upstream. Certain r6xx boards use the same power state for both UVD and other things. Since we don't support UVD on r6xx boards at the moment, there was no callback installed for setting the UVD clocks, however, on systems that use the same power state, this leads to a NULL pointer dereference. Fill in a stubbed out implementation for now to avoid the crash. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66963 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4ef082b56fd09e8f1fcd9a18311cfb679fb0e46a Author: Alex Deucher Date: Wed Sep 4 16:48:40 2013 -0400 drm/radeon: add some additional berlin pci ids commit 9a71677874d200865433647e9282fcf9fa6b05dd upstream. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 354d4648f1fd42a596e6df1a251dd3e800e20897 Author: Nithin Sujir Date: Thu Sep 12 14:01:31 2013 -0700 tg3: Expand led off fix to include 5720 commit 300cf9b93f74c3d969a0ad50bdac65416107c44c upstream. Commit 989038e217e94161862a959e82f9a1ecf8dda152 ("tg3: Don't turn off led on 5719 serdes port 0") added code to skip turning led off on port 0 of the 5719 since it powered down other ports. This workaround needs to be enabled on the 5720 as well. Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f1f7d9989f5917f43bfd884da1ed36ac50a76072 Author: Nithin Sujir Date: Fri Aug 30 17:01:36 2013 -0700 tg3: Don't turn off led on 5719 serdes port 0 commit 989038e217e94161862a959e82f9a1ecf8dda152 upstream. Turning off led on port 0 of the 5719 serdes causes all other ports to lose power and stop functioning. Add tg3_phy_led_bug() function to check for this condition. We use a switch() in tg3_phy_led_bug() for consistency with the tg3_phy_power_bug() function. Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dd0920e688b3886587ba02d82c5b0eebf1705cb5 Author: Alex Deucher Date: Fri Aug 30 16:18:35 2013 -0400 drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2) commit 1ff60ddb84bb9ff6fa182710c4e08b66badf918c upstream. Check to make sure the dc limits are valid before using them. Some systems may not have a dc limits table. In that case just use the ac limits. This fixes hangs on systems when the power state is changed when on battery (dc) due to invalid performance state parameters. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=68708 v2: fix up limits in dpm_init() Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d692b2fa12c635ee2fef4ab4d41b5f874754886f Author: Alex Deucher Date: Tue Aug 27 12:36:01 2013 -0400 drm/radeon: fix handling of variable sized arrays for router objects commit fb93df1c2d8b3b1fb16d6ee9e32554e0c038815d upstream. The table has the following format: typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset pointing to this structure { UCHAR ucNumberOfSrc; USHORT usSrcObjectID[1]; UCHAR ucNumberOfDst; USHORT usDstObjectID[1]; }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT; usSrcObjectID[] and usDstObjectID[] are variably sized, so we can't access them directly. Use pointers and update the offset appropriately when accessing the Dst members. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d7e8af270c620e63314612735e0e04ecceaf9ea0 Author: Alex Deucher Date: Mon Aug 26 17:52:12 2013 -0400 drm/radeon: fix resume on some rs4xx boards (v2) commit acf88deb8ddbb73acd1c3fa32fde51af9153227f upstream. Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on some boards on resume. The systems seem to work fine without touching this bit so leave it as is. v2: read-modify-write the GART_INDEX_REG_EN bit. I suspect the problem is that we are losing the other settings in the register. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=52952 Reported-by: Ondrej Zary Tested-by: Daniel Tobias Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3f570ac2effe8f7ffd7da5fb90685ebafcbb44a4 Author: Alex Deucher Date: Mon Aug 19 11:15:43 2013 -0400 drm/radeon: update line buffer allocation for dce6 commit 290d24576ccf1aa0373d2185cedfe262d0d4952a upstream. We need to allocate line buffer to each display when setting up the watermarks. Failure to do so can lead to a blank screen. This fixes blank screen problems on dce6 asics. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=64850 Based on an initial fix from: Jay Cornwall Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1f7b127114c018e6b02afde7f4b12404c0255e26 Author: Alex Deucher Date: Mon Aug 19 11:06:50 2013 -0400 drm/radeon: update line buffer allocation for dce4.1/5 commit 0b31e02363b0db4e7931561bc6c141436e729d9f upstream. We need to allocate line buffer to each display when setting up the watermarks. Failure to do so can lead to a blank screen. This fixes blank screen problems on dce4.1/5 asics. Based on an initial fix from: Jay Cornwall Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 47965ab529450180363b4677ee8de72a509bff93 Author: Tom Stellard Date: Fri Aug 16 17:47:39 2013 -0400 drm/radeon/si: Add support for CP DMA to CS checker for compute v2 commit e5b9e7503eb1f4884efa3b321d3cc47806779202 upstream. Also add a new RADEON_INFO query to check that CP DMA packets are supported on the compute ring. CP DMA has been supported since the 3.8 kernel, but due to an oversight we forgot to teach the CS checker that the CP DMA packet was legal for the compute ring on Southern Islands GPUs. This patch fixes a bug where the radeon driver will incorrectly reject a legal CP DMA packet from user space. I would like to have the patch backported to stable so that we don't have to require Mesa users to use a bleeding edge kernel in order to take advantage of this feature which is already present in the stable kernels (3.8 and newer). v2: - Don't bump kms version, so this patch can be backported to stable kernels. Signed-off-by: Tom Stellard Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 91c5e46be9d59a7446135d6ea3af985db89bbb5b Author: Alex Deucher Date: Mon Jun 10 15:51:21 2013 -0400 drm/radeon: add berlin pci ids commit 0431b2742f8e7755f3bbf5924900d12973412e94 upstream. This adds the pci ids for the berlin GPU core. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d74a8998d565d0b8b2f9a844becddd3930614c42 Author: Alex Deucher Date: Wed Sep 4 16:46:07 2013 -0400 drm/radeon/cik: update gpu_init for an additional berlin gpu commit 7c4622d5415038a74964480844de885e7253a0f4 upstream. Sets the right paramters for the new pci id. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3b81d4a478c958ca4bc15806198044161b704765 Author: Alex Deucher Date: Fri Aug 30 08:58:20 2013 -0400 drm/radeon: fix init ordering for r600+ commit e5903d399a7b0e5c14673c1206f4aeec2859c730 upstream. The vram scratch buffer needs to be initialized before the mc is programmed otherwise we program 0 as the GPU address of the default GPU fault page. In most cases we put vram at zero anyway and reserve a page for the legacy vga buffer so in practice this shouldn't cause any problems, but better to make it correct. Was changed in: 6fab3febf6d949b0a12b1e4e73db38e4a177a79e Reported-by: FrankR Huang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e87c2ac1de54d7cf1746401fb13d96923fd9a362 Author: Alex Deucher Date: Mon Aug 19 11:39:27 2013 -0400 drm/radeon: update line buffer allocation for dce8 commit bc01a8c7a24169f8b111b7dda6f5d8e7088309af upstream. We need to allocate line buffer to each display when setting up the watermarks. Failure to do so can lead to a blank screen. This fixes blank screen problems on dce8 asics. Based on an initial fix from: Jay Cornwall Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 42db51e22b83eb790a155e8a0c5301103088be63 Author: Alex Deucher Date: Mon Jun 10 15:18:26 2013 -0400 drm/radeon: fill in gpu_init for berlin GPU cores commit b2e4c70a9747ecb618d563b004ba746869dde5aa upstream. This fills in the GPU specific details for berlin GPU cores so that the driver will work with them. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ca877a1a51e624a2412462c41ba1b62275253751 Author: Christian König Date: Fri Aug 30 11:10:33 2013 +0200 drm/radeon: enable UVD interrupts on CIK commit 6a3808b8233eb91b57c230cf1161ac116a189ffd upstream. The same as on evergreen. Signed-off-by: Christian König Reported-by: FrankR Huang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c69f8373831cc6bf4fdf46ad34ae907a9b424292 Author: Alex Deucher Date: Wed Aug 7 19:34:53 2013 -0400 drm/radeon: fix endian bugs in hw i2c atom routines commit 4543eda52113d1e2cc0e9bf416f79597e6ef1ec7 upstream. Need to swap the data fetched over i2c properly. This is the same fix as the endian fix for aux channel transactions. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b41829203011e44b87a8cf406a58d49537cbbe74 Author: Alex Deucher Date: Mon Aug 12 11:24:05 2013 -0400 drm/radeon/dpm: add reclocking quirk for ASUS K70AF commit f75195cac32bfd2ef07764bd370d3b788bd8b003 upstream. The LCD has a relatively short vblank time (216us), but the card is able to reclock memory fine in that time. Signed-off-by: Alex Deucher Reported-by: normalrawr@gmail.com Signed-off-by: Greg Kroah-Hartman commit 77d2f036b1c63ce7febf9528d69928b1f4b53881 Author: Alex Deucher Date: Tue Aug 20 14:59:01 2013 -0400 drm/radeon: fix LCD record parsing commit 95663948ba22a4be8b99acd67fbf83e86ddffba4 upstream. If the LCD table contains an EDID record, properly account for the edid size when walking through the records. This should fix error messages about unknown LCD records. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b6a43016c4a80c04899d3c83aafb172e2549e4b6 Author: Emil Velikov Date: Fri Aug 23 18:43:42 2013 +0100 drm/nv50/disp: prevent false output detection on the original nv50 commit 5087f51da805f53cba7366f70d596e7bde2a5486 upstream. Commit ea9197cc323839ef3d5280c0453b2c622caa6bc7 effectively enabled the use of an improved DAC detection code, but introduced a regression on the original nv50 chipset, causing a ghost monitor to be detected. v2 (Ben Skeggs): the offending line was likely a thinko, removed it for all chipsets (tested nv50 and nve6 to cover entire range) and added some additional debugging. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67382 Tested-by: Martin Peres Signed-off-by: Emil Velikov Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 2a9dacd5573e410ef5b66718de8c1d21e8857088 Author: Sergey Senozhatsky Date: Thu Aug 29 12:29:35 2013 +0300 radeon kms: fix uninitialised hotplug work usage in r100_irq_process() commit 27c505ca84e164ec66ad55dcf3f5befaac83f10a upstream. Commit a01c34f72e7cd2624570818f579b5ab464f93de2 (radeon kms: do not flush uninitialized hotplug work) moved work initialisation phase to the last step of radeon_irq_kms_init(). Meelis Roos reported that this causes problems on his machine because drm_irq_install() uses hotplug work on r100. hotplug work flushed in radeon_irq_kms_fini(), with two possible cases: -- radeon_irq_kms_fini() call after successful radeon_irq_kms_init() -- radeon_irq_kms_fini() call after unsuccessful (or not called at all) radeon_irq_kms_init() The latter one causes flush work on uninitialised hotplug work. Move work initialisation before drm_irq_install(), but keep existing agreement to flush hotplug work in radeon_irq_kms_fini() only for `irq.installed' (successful radeon_irq_kms_init()) case. WARNING: CPU: 0 PID: 243 at kernel/workqueue.c:1378 __queue_work+0x132/0x16d() Call Trace: [] ? dump_stack+0xa/0x13 [] ? warn_slowpath_common+0x75/0x8a [] ? __queue_work+0x132/0x16d [] ? __queue_work+0x132/0x16d [] ? warn_slowpath_null+0x1b/0x1f [] ? __queue_work+0x132/0x16d [] ? queue_work_on+0x30/0x40 [] ? r100_irq_process+0x16d/0x1e6 [radeon] [] ? radeon_driver_irq_preinstall_kms+0xc2/0xc5 [radeon] [] ? drm_irq_install+0xb2/0x1ac [drm] [] ? drm_vblank_init+0x196/0x1d2 [drm] [] ? radeon_irq_kms_init+0x33/0xc6 [radeon] [] ? r100_startup+0x1a3/0x1d6 [radeon] [] ? radeon_ttm_init+0x26e/0x287 [radeon] [] ? r100_init+0x2b3/0x309 [radeon] [] ? vga_client_register+0x39/0x40 [] ? radeon_device_init+0x54b/0x61b [radeon] [] ? cail_mc_write+0x13/0x13 [radeon] [] ? radeon_driver_load_kms+0x82/0xda [radeon] [] ? drm_get_pci_dev+0x136/0x22d [drm] [] ? radeon_pci_probe+0x6c/0x86 [radeon] [] ? pci_device_probe+0x4c/0x83 [] ? driver_probe_device+0x80/0x184 [] ? pci_match_id+0x18/0x36 [] ? __driver_attach+0x44/0x5f [] ? bus_for_each_dev+0x50/0x5a [] ? driver_attach+0x14/0x16 [] ? __device_attach+0x28/0x28 [] ? bus_add_driver+0xd6/0x1bf [] ? driver_register+0x78/0xcf [] ? 0xf8ba7fff [] ? do_one_initcall+0x8b/0x121 [] ? change_page_attr_clear+0x2e/0x33 [] ? 0xf8ba7fff [] ? set_memory_ro+0x1c/0x20 [] ? set_page_attributes+0x11/0x12 [] ? load_module+0x12fa/0x17e8 [] ? map_vm_area+0x22/0x31 [] ? SyS_init_module+0x67/0x7d [] ? sysenter_do_call+0x12/0x26 Reported-by: Meelis Roos Tested-by: Meelis Roos Signed-off-by: Sergey Senozhatsky Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 820ea14fd902f5a7a61d5a83cce5f21a0249cf44 Author: Ben Skeggs Date: Tue Sep 17 14:21:15 2013 +1000 drm/ttm: fix the tt_populated check in ttm_tt_destroy() commit 182b17c8dc4e83aab000ce86587b6810e515da87 upstream. After a vmalloc failure in ttm_dma_tt_alloc_page_directory(), ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up inside the driver's unpopulate() hook when populate() has never yet been called. On nouveau, the first issue to be hit because of this is that dma_address[] may be a NULL pointer. After working around this, ttm_pool_unpopulate() may potentially hit the same issue with the pages[] array. It seems to make more sense to avoid calling unpopulate on already unpopulated TTMs than to add checks to all the implementations. Signed-off-by: Ben Skeggs Reviewed-by: Thomas Hellstrom Cc: Jerome Glisse Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 9f4225978a34b488e2801113b7a7ccb0953bc342 Author: Dave Airlie Date: Thu Sep 12 15:31:04 2013 +1000 drm/ast: fix the ast open key function commit 2e8378136f28bea960cec643d3fa5d843c9049ec upstream. When porting from UMS I mistyped this from the wrong place, AST noticed and pointed it out, so we should fix it to be like the X.org driver. Reported-by: Y.C. Chen Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c7e42b111702f79c8774d475cfbc278c61fdb6f9 Author: David Herrmann Date: Mon Aug 26 15:16:49 2013 +0200 drm: fix DRM_IOCTL_MODE_GETFB handle-leak commit 101b96f32956ee99bf1468afaf572b88cda9f88b upstream. DRM_IOCTL_MODE_GETFB is used to retrieve information about a given framebuffer ID. It is a read-only helper and was thus declassified for unprivileged access in: commit a14b1b42477c5ef089fcda88cbaae50d979eb8f9 Author: Mandeep Singh Baines Date: Fri Jan 20 12:11:16 2012 -0800 drm: remove master fd restriction on mode setting getters However, alongside width, height and stride information, DRM_IOCTL_MODE_GETFB also passes back a handle to the underlying buffer of the framebuffer. This handle allows users to mmap() it and read or write into it. Obviously, this should be restricted to DRM-Master. With the current setup, *any* process with access to /dev/dri/card0 (which means any process with access to hardware-accelerated rendering) can access the current screen framebuffer and modify it ad libitum. For backwards-compatibility reasons we want to keep the DRM_IOCTL_MODE_GETFB call unprivileged. Besides, it provides quite useful information regarding screen setup. So we simply test whether the caller is the current DRM-Master and if not, we return 0 as handle, which is always invalid. A following DRM_IOCTL_GEM_CLOSE on this handle will fail with EINVAL, but we accept this. Users shouldn't test for errors during GEM_CLOSE, anyway. And it is still better as a failing MODE_GETFB call. v2: add capable(CAP_SYS_ADMIN) check for compatibility with i-g-t Signed-off-by: David Herrmann Reviewed-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 7ad24d0b37bbbe6eea2c723c84bcd6b529711c80 Author: Ville Syrjälä Date: Tue Sep 17 18:33:44 2013 +0300 drm/i915: Don't enable the cursor on a disable pipe commit f2f5f771c5fc0fa252cde3d0d0452dcc785cc17a upstream. On HSW enabling a plane on a disabled pipe may hang the entire system. And there's no good reason for doing it ever, so just don't. v2: Move the crtc active checks to intel_crtc_cursor_{set,move} to avoid confusing people during modeset Signed-off-by: Ville Syrjälä Tested-by: Paulo Zanoni Reviewed-by: Paulo Zanoni Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit cce85343c70f468d3d119016c280cc3b7d30db39 Author: Jani Nikula Date: Tue Sep 17 18:33:43 2013 +0300 drm/i915: do not update cursor in crtc mode set commit cc173961a68034c1171a421f0dbed39edfb60880 upstream. The cursor is disabled before crtc mode set in crtc disable (and we assert this is the case), and enabled afterwards in crtc enable. Do not update it in crtc mode set. On HSW enabling a plane on a disabled pipe may hang the entire system. And there's no good reason for doing it ever, so just don't. v2: Add note about HSW hangs - vsyrjala Suggested-by: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Tested-by: Paulo Zanoni Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit a3d7ac2284a90e6aad1c5f77641169faad03d26f Author: Daniel Vetter Date: Sun Sep 8 21:57:13 2013 +0200 drm/i915: fix wait_for_pending_flips vs gpu hang deadlock commit 17e1df07df0fbc77696a1e1b6ccf9f2e5af70e40 upstream. My g33 here seems to be shockingly good at hitting them all. This time around kms_flip/flip-vs-panning-vs-hang blows up: intel_crtc_wait_for_pending_flips correctly checks for gpu hangs and if a gpu hang is pending aborts the wait for outstanding flips so that the setcrtc call will succeed and release the crtc mutex. And the gpu hang handler needs that lock in intel_display_handle_reset to be able to complete outstanding flips. The problem is that we can race in two ways: - Waiters on the dev_priv->pending_flip_queue aren't woken up after we've the reset as pending, but before we actually start the reset work. This means that the waiter doesn't notice the pending reset and hence will keep on hogging the locks. Like with dev->struct_mutex and the ring->irq_queue wait queues we there need to wake up everyone that potentially holds a lock which the reset handler needs. - intel_display_handle_reset was called _after_ we've already signalled the completion of the reset work. Which means a waiter could sneak in, grab the lock and never release it (since the pageflips won't ever get released). Similar to resetting the gem state all the reset work must complete before we update the reset counter. Contrary to the gem reset we don't need to have a second explicit wake up call since that will have happened already when completing the pageflips. We also don't have any issues that the completion happens while the reset state is still pending - wait_for_pending_flips is only there to ensure we display the right frame. After a gpu hang&reset events such guarantees are out the window anyway. This is in contrast to the gem code where too-early wake-up would result in unnecessary restarting of ioctls. Also, since we've gotten these various deadlocks and ordering constraints wrong so often throw copious amounts of comments at the code. This deadlock regression has been introduced in the commit which added the pageflip reset logic to the gpu hang work: commit 96a02917a0131e52efefde49c2784c0421d6c439 Author: Ville Syrjälä Date: Mon Feb 18 19:08:49 2013 +0200 drm/i915: Finish page flips and update primary planes after a GPU reset v2: - Add comments to explain how the wake_up serves as memory barriers for the atomic_t reset counter. - Improve the comments a bit as suggested by Chris Wilson. - Extract the wake_up calls before/after the reset into a little i915_error_wake_up and unconditionally wake up the pending_flip_queue waiters, again as suggested by Chris Wilson. v3: Throw copious amounts of comments at i915_error_wake_up as suggested by Chris Wilson. Cc: Ville Syrjälä Cc: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 9db0f612b7578f881ac8d749b3007d3be3ea49da Author: Daniel Vetter Date: Wed Sep 4 17:36:14 2013 +0200 drm/i915: fix gpu hang vs. flip stall deadlocks commit 122f46badaafbe651f05c2c0f24cadee692f761b upstream. Since we've started to clean up pending flips when the gpu hangs in commit 96a02917a0131e52efefde49c2784c0421d6c439 Author: Ville Syrjälä Date: Mon Feb 18 19:08:49 2013 +0200 drm/i915: Finish page flips and update primary planes after a GPU reset the gpu reset work now also grabs modeset locks. But since work items on our private work queue are not allowed to do that due to the flush_workqueue from the pageflip code this results in a neat deadlock: INFO: task kms_flip:14676 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kms_flip D ffff88019283a5c0 0 14676 13344 0x00000004 ffff88018e62dbf8 0000000000000046 ffff88013bdb12e0 ffff88018e62dfd8 ffff88018e62dfd8 00000000001d3b00 ffff88019283a5c0 ffff88018ec21000 ffff88018f693f00 ffff88018eece000 ffff88018e62dd60 ffff88018eece898 Call Trace: [] schedule+0x60/0x62 [] intel_crtc_wait_for_pending_flips+0xb2/0x114 [i915] [] ? finish_wait+0x60/0x60 [] intel_crtc_set_config+0x7f3/0x81e [i915] [] drm_mode_set_config_internal+0x4f/0xc6 [drm] [] drm_mode_setcrtc+0x44d/0x4f9 [drm] [] ? might_fault+0x38/0x86 [] drm_ioctl+0x2f9/0x447 [drm] [] ? trace_hardirqs_off+0xd/0xf [] ? drm_mode_setplane+0x343/0x343 [drm] [] ? mntput_no_expire+0x3e/0x13d [] vfs_ioctl+0x18/0x34 [] do_vfs_ioctl+0x396/0x454 [] ? sysret_check+0x1b/0x56 [] SyS_ioctl+0x52/0x7d [] system_call_fastpath+0x16/0x1b 2 locks held by kms_flip/14676: #0: (&dev->mode_config.mutex){+.+.+.}, at: [] drm_modeset_lock_all+0x22/0x59 [drm] #1: (&crtc->mutex){+.+.+.}, at: [] drm_modeset_lock_all+0x48/0x59 [drm] INFO: task kworker/u8:4:175 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u8:4 D ffff88018de9a5c0 0 175 2 0x00000000 Workqueue: i915 i915_error_work_func [i915] ffff88018e37dc30 0000000000000046 ffff8801938ab8a0 ffff88018e37dfd8 ffff88018e37dfd8 00000000001d3b00 ffff88018de9a5c0 ffff88018ec21018 0000000000000246 ffff88018e37dca0 000000005a865a86 ffff88018de9a5c0 Call Trace: [] schedule+0x60/0x62 [] schedule_preempt_disabled+0x9/0xb [] mutex_lock_nested+0x205/0x3b1 [] ? intel_display_handle_reset+0x7e/0xbd [i915] [] ? intel_display_handle_reset+0x7e/0xbd [i915] [] intel_display_handle_reset+0x7e/0xbd [i915] [] i915_error_work_func+0x128/0x147 [i915] [] process_one_work+0x1d4/0x35a [] ? process_one_work+0x15b/0x35a [] worker_thread+0x144/0x1f0 [] ? rescuer_thread+0x275/0x275 [] kthread+0xac/0xb4 [] ? finish_task_switch+0x3b/0xc0 [] ? __kthread_parkme+0x60/0x60 [] ret_from_fork+0x7c/0xb0 [] ? __kthread_parkme+0x60/0x60 3 locks held by kworker/u8:4/175: #0: (i915){.+.+.+}, at: [] process_one_work+0x15b/0x35a #1: ((&dev_priv->gpu_error.work)){+.+.+.}, at: [] process_one_work+0x15b/0x35a #2: (&crtc->mutex){+.+.+.}, at: [] intel_display_handle_reset+0x7e/0xbd [i915] This blew up while running kms_flip/flip-vs-panning-vs-hang-interruptible on one of my older machines. Unfortunately (despite the proper lockdep annotations for flush_workqueue) lockdep still doesn't detect this correctly, so we need to rely on chance to discover these bugs. Apply the usual bugfix and schedule the reset work on the system workqueue to keep our own driver workqueue free of any modeset lock grabbing. Note that this is not a terribly serious regression since before the offending commit we'd simply have stalled userspace forever due to failing to abort all outstanding pageflips. v2: Add a comment as requested by Chris. Cc: Thomas Gleixner Cc: Ville Syrjälä Cc: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit a25eb759ee3a1ff80a9cb40e465e8bfefb001c07 Author: Daniel Vetter Date: Mon Sep 2 16:22:25 2013 +0200 drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock commit 645416f5adc87c8fae44289cdba7562f3ade8f5c upstream. Historically we've run our own driver hotplug handling in our own work-queue, which then launched the drm core hotplug handling in the system workqueue. This is important since we flush our own driver workqueue in the pageflip code while hodling modeset locks, and only the drm hotplug code grabbed these locks. But with commit 69787f7da6b2adc4054357a661aaa1701a9ca76f Author: Daniel Vetter Date: Tue Oct 23 18:23:34 2012 +0000 drm: run the hpd irq event code directly this was changed and now we could deadlock in our flip handler if there's a hotplug work blocking the progress of the crucial unpin works. So this broke the careful deadlock avoidance implemented in commit b4a98e57fc27854b5938fc8b08b68e5e68b91e1f Author: Chris Wilson Date: Thu Nov 1 09:26:26 2012 +0000 drm/i915: Flush outstanding unpin tasks before pageflipping Since the rule thus far has been that work items on our own workqueue may never grab modeset locks simply restore that rule again. v2: Add a comment to the declaration of dev_priv->wq to warn readers about the tricky implications of using it. Suggested by Chris Wilson. Cc: Chris Wilson Cc: Stuart Abercrombie Reported-by: Stuart Abercrombie References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/26239 Reviewed-by: Chris Wilson [danvet: Squash in a comment at the place where we schedule the work. Requested after-the-fact by Chris on irc since the hpd work isn't the only place we botch this.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 65d7c76f6355b74032b9642446378e6938c41769 Author: Jani Nikula Date: Fri Aug 23 10:50:39 2013 +0300 drm/i915: try not to lose backlight CBLV precision commit cac6a5ae0118832936eb162ec4cedb30f2422bcc upstream. ACPI has _BCM and _BQC methods to set and query the backlight brightness, respectively. The ACPI opregion has variables BCLP and CBLV to hold the requested and current backlight brightness, respectively. The BCLP variable has range 0..255 while the others have range 0..100. This means the _BCM method has to scale the brightness for BCLP, and the gfx driver has to scale the requested value back for CBLV. If the _BQC method uses the CBLV variable (apparently some implementations do, some don't) for current backlight level reporting, there's room for rounding errors. Use DIV_ROUND_UP for scaling back to CBLV to get back to the same values that were passed to _BCM, presuming the _BCM simply uses bclp = (in * 255) / 100 for scaling to BCLP. Reference: https://gist.github.com/aaronlu/6314920 Reported-by: Aaron Lu Signed-off-by: Jani Nikula Reviewed-by: Aaron Lu Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 6e52ea46b556dec8aa5932b0e60cc58f4682d8ee Author: Alan Stern Date: Tue Jul 30 15:18:15 2013 -0400 usb: gadget: fix a bug and a WARN_ON in dummy-hcd commit 5f5610f69be3a925b1f79af27150bb7377bc9ad6 upstream. This patch fixes a NULL pointer dereference and a WARN_ON in dummy-hcd. These things were the result of moving to the UDC core framework, and possibly of changes to that framework. Now unloading a gadget driver causes the UDC to be stopped after the gadget driver is unbound, not before. Therefore the "driver" argument to dummy_udc_stop() can be NULL, so we must not try to print the driver's name without checking first. Also, the UDC framework automatically unregisters the gadget when the UDC is deleted. Therefore a sysfs attribute file attached to the gadget must be removed before the UDC is deleted, not after. Signed-off-by: Alan Stern Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 9d22fcf02bcb3415b112e37db87322ebcc3b8edf Author: Kees Cook Date: Wed Sep 11 21:56:56 2013 +0200 HID: logitech-dj: validate output report details commit 297502abb32e225fb23801fcdb0e4f6f8e17099a upstream. A HID device could send a malicious output report that would cause the logitech-dj HID driver to leak kernel memory contents to the device, or trigger a NULL dereference during initialization: [ 304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b ... [ 304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 [ 304.781409] IP: [] logi_dj_recv_send_report.isra.11+0x1a/0x90 CVE-2013-2895 Signed-off-by: Kees Cook Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c20600981b3bc41bdb2e13b428c882b968b044d7 Author: Kees Cook Date: Wed Sep 11 21:56:55 2013 +0200 HID: lenovo-tpkbd: validate output report details commit 0a9cd0a80ac559357c6a90d26c55270ed752aa26 upstream. A HID device could send a malicious output report that would cause the lenovo-tpkbd HID driver to write just beyond the output report allocation during initialization, causing a heap overflow: [ 76.109807] usb 1-1: New USB device found, idVendor=17ef, idProduct=6009 ... [ 80.462540] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten CVE-2013-2894 Signed-off-by: Kees Cook Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 17ef9210ba84f30031dd9ee1536eebeeba767b9c Author: Kees Cook Date: Wed Sep 11 21:56:52 2013 +0200 HID: sony: validate HID output report details commit 9446edb9a1740989cf6c20daf7510fb9a23be14a upstream. This driver must validate the availability of the HID output report and its size before it can write LED states via buzz_set_leds(). This stops a heap overflow that is possible if a device provides a malicious HID output report: [ 108.171280] usb 1-1: New USB device found, idVendor=054c, idProduct=0002 ... [ 117.507877] BUG kmalloc-192 (Not tainted): Redzone overwritten CVE-2013-2890 Signed-off-by: Kees Cook Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 8fbcdb237b5020cbe3cf9582b838898f6028dea3 Author: Kees Cook Date: Wed Sep 11 21:56:53 2013 +0200 HID: steelseries: validate output report details commit 41df7f6d43723deb7364340b44bc5d94bf717456 upstream. A HID device could send a malicious output report that would cause the steelseries HID driver to write beyond the output report allocation during initialization, causing a heap overflow: [ 167.981534] usb 1-1: New USB device found, idVendor=1038, idProduct=1410 ... [ 182.050547] BUG kmalloc-256 (Tainted: G W ): Redzone overwritten CVE-2013-2891 Signed-off-by: Kees Cook Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 295ae396b5eed66eac154e2b23617305cc61f289 Author: Benjamin Tissoires Date: Wed Sep 11 21:56:59 2013 +0200 HID: lenovo-tpkbd: fix leak if tpkbd_probe_tp fails commit 0ccdd9e7476680c16113131264ad6597bd10299d upstream. If tpkbd_probe_tp() bails out, the probe() function return an error, but hid_hw_stop() is never called. fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1003998 Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b04b069219d20fe6ba08a7294efb41811addbf16 Author: Kees Cook Date: Wed Sep 11 21:56:51 2013 +0200 HID: zeroplus: validate output report details commit 78214e81a1bf43740ce89bb5efda78eac2f8ef83 upstream. The zeroplus HID driver was not checking the size of allocated values in fields it used. A HID device could send a malicious output report that would cause the driver to write beyond the output report allocation during initialization, causing a heap overflow: [ 1442.728680] usb 1-1: New USB device found, idVendor=0c12, idProduct=0005 ... [ 1466.243173] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten CVE-2013-2889 Signed-off-by: Kees Cook Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 8aa75ad17e5a0c10f89844edf777f49fdc48a39c Author: Kees Cook Date: Wed Sep 11 21:56:54 2013 +0200 HID: LG: validate HID output report details commit 0fb6bd06e06792469acc15bbe427361b56ada528 upstream. A HID device could send a malicious output report that would cause the lg, lg3, and lg4 HID drivers to write beyond the output report allocation during an event, causing a heap overflow: [ 325.245240] usb 1-1: New USB device found, idVendor=046d, idProduct=c287 ... [ 414.518960] BUG kmalloc-4096 (Not tainted): Redzone overwritten Additionally, while lg2 did correctly validate the report details, it was cleaned up and shortened. CVE-2013-2893 Signed-off-by: Kees Cook Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 09dce56863280e987715f8a0303f9451df145ca4 Author: Benjamin Tissoires Date: Wed Sep 11 21:56:58 2013 +0200 HID: multitouch: validate indexes details commit 8821f5dc187bdf16cfb32ef5aa8c3035273fa79a upstream. When working on report indexes, always validate that they are in bounds. Without this, a HID device could report a malicious feature report that could trick the driver into a heap overflow: [ 634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500 ... [ 676.469629] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten Note that we need to change the indexes from s8 to s16 as they can be between -1 and 255. CVE-2013-2897 Signed-off-by: Benjamin Tissoires Acked-by: Kees Cook Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 12b5c3cc9ca345ae880ae811fae565ed208e96a5 Author: Benjamin Tissoires Date: Wed Sep 11 21:56:57 2013 +0200 HID: validate feature and input report details commit cc6b54aa54bf40b762cab45a9fc8aa81653146eb upstream. When dealing with usage_index, be sure to properly use unsigned instead of int to avoid overflows. When working on report fields, always validate that their report_counts are in bounds. Without this, a HID device could report a malicious feature report that could trick the driver into a heap overflow: [ 634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500 ... [ 676.469629] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten CVE-2013-2897 Signed-off-by: Benjamin Tissoires Acked-by: Kees Cook Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit e7a21c6037777270ad215d0c5d8bee75c9740cba Author: Kees Cook Date: Wed Sep 11 21:56:50 2013 +0200 HID: provide a helper for validating hid reports commit 331415ff16a12147d57d5c953f3a961b7ede348b upstream. Many drivers need to validate the characteristics of their HID report during initialization to avoid misusing the reports. This adds a common helper to perform validation of the report exisitng, the field existing, and the expected number of values within the field. Signed-off-by: Kees Cook Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit cb76760862b055d56562ed3d7340336a6164f062 Author: Daisuke Nishimura Date: Tue Sep 10 18:16:36 2013 +0900 sched/fair: Fix small race where child->se.parent,cfs_rq might point to invalid ones commit 6c9a27f5da9609fca46cb2b183724531b48f71ad upstream. There is a small race between copy_process() and cgroup_attach_task() where child->se.parent,cfs_rq points to invalid (old) ones. parent doing fork() | someone moving the parent to another cgroup -------------------------------+--------------------------------------------- copy_process() + dup_task_struct() -> parent->se is copied to child->se. se.parent,cfs_rq of them point to old ones. cgroup_attach_task() + cgroup_task_migrate() -> parent->cgroup is updated. + cpu_cgroup_attach() + sched_move_task() + task_move_group_fair() +- set_task_rq() -> se.parent,cfs_rq of parent are updated. + cgroup_fork() -> parent->cgroup is copied to child->cgroup. (*1) + sched_fork() + task_fork_fair() -> se.parent,cfs_rq of child are accessed while they point to old ones. (*2) In the worst case, this bug can lead to "use-after-free" and cause a panic, because it's new cgroup's refcount that is incremented at (*1), so the old cgroup(and related data) can be freed before (*2). In fact, a panic caused by this bug was originally caught in RHEL6.4. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] sched_slice+0x6e/0xa0 [...] Call Trace: [] place_entity+0x75/0xa0 [] task_fork_fair+0xaa/0x160 [] sched_fork+0x6b/0x140 [] copy_process+0x5b2/0x1450 [] ? wake_up_new_task+0xd9/0x130 [] do_fork+0x94/0x460 [] ? sys_wait4+0xae/0x100 [] sys_clone+0x28/0x30 [] stub_clone+0x13/0x20 [] ? system_call_fastpath+0x16/0x1b Signed-off-by: Daisuke Nishimura Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/039601ceae06$733d3130$59b79390$@mxp.nes.nec.co.jp Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bf022ac3b26c9a585c4efd38a44bad34f3f43433 Author: Stanislaw Gruszka Date: Wed Sep 4 15:16:03 2013 +0200 sched/cputime: Do not scale when utime == 0 commit 5a8e01f8fa51f5cbce8f37acc050eb2319d12956 upstream. scale_stime() silently assumes that stime < rtime, otherwise when stime == rtime and both values are big enough (operations on them do not fit in 32 bits), the resulting scaling stime can be bigger than rtime. In consequence utime = rtime - stime results in negative value. User space visible symptoms of the bug are overflowed TIME values on ps/top, for example: $ ps aux | grep rcu root 8 0.0 0.0 0 0 ? S 12:42 0:00 [rcuc/0] root 9 0.0 0.0 0 0 ? S 12:42 0:00 [rcub/0] root 10 62422329 0.0 0 0 ? R 12:42 21114581:37 [rcu_preempt] root 11 0.1 0.0 0 0 ? S 12:42 0:02 [rcuop/0] root 12 62422329 0.0 0 0 ? S 12:42 21114581:35 [rcuop/1] root 10 62422329 0.0 0 0 ? R 12:42 21114581:37 [rcu_preempt] or overflowed utime values read directly from /proc/$PID/stat Reference: https://lkml.org/lkml/2013/8/20/259 Reported-and-tested-by: Sergey Senozhatsky Signed-off-by: Stanislaw Gruszka Cc: stable@vger.kernel.org Cc: Frederic Weisbecker Cc: Peter Zijlstra Cc: Paul E. McKenney Cc: Borislav Petkov Link: http://lkml.kernel.org/r/20130904131602.GC2564@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7ee4ddd24bf7ceee9400de450f69e327f7970f7c Author: John Stultz Date: Wed Sep 11 16:50:56 2013 -0700 timekeeping: Fix HRTICK related deadlock from ntp lock changes commit 7bd36014460f793c19e7d6c94dab67b0afcfcb7f upstream. Gerlando Falauto reported that when HRTICK is enabled, it is possible to trigger system deadlocks. These were hard to reproduce, as HRTICK has been broken in the past, but seemed to be connected to the timekeeping_seq lock. Since seqlock/seqcount's aren't supported w/ lockdep, I added some extra spinlock based locking and triggered the following lockdep output: [ 15.849182] ntpd/4062 is trying to acquire lock: [ 15.849765] (&(&pool->lock)->rlock){..-...}, at: [] __queue_work+0x145/0x480 [ 15.850051] [ 15.850051] but task is already holding lock: [ 15.850051] (timekeeper_lock){-.-.-.}, at: [] do_adjtimex+0x7f/0x100 [ 15.850051] Chain exists of: &(&pool->lock)->rlock --> &p->pi_lock --> timekeeper_lock [ 15.850051] Possible unsafe locking scenario: [ 15.850051] [ 15.850051] CPU0 CPU1 [ 15.850051] ---- ---- [ 15.850051] lock(timekeeper_lock); [ 15.850051] lock(&p->pi_lock); [ 15.850051] lock(timekeeper_lock); [ 15.850051] lock(&(&pool->lock)->rlock); [ 15.850051] [ 15.850051] *** DEADLOCK *** The deadlock was introduced by 06c017fdd4dc48451a ("timekeeping: Hold timekeepering locks in do_adjtimex and hardpps") in 3.10 This patch avoids this deadlock, by moving the call to schedule_delayed_work() outside of the timekeeper lock critical section. Reported-by: Gerlando Falauto Tested-by: Lin Ming Signed-off-by: John Stultz Cc: Mathieu Desnoyers Link: http://lkml.kernel.org/r/1378943457-27314-1-git-send-email-john.stultz@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b8a1785c3c1ce85a36d3088e3322f9a2619716bd Author: Stanislaw Gruszka Date: Mon Aug 26 15:18:53 2013 +0200 rt2800: fix wrong TX power compensation commit 6e956da2027c767859128b9bfef085cf2a8e233b upstream. We should not do temperature compensation on devices without EXTERNAL_TX_ALC bit set (called DynamicTxAgcControl on vendor driver). Such devices can have totally bogus TSSI parameters on the EEPROM, but still threaded by us as valid and result doing wrong TX power calculations. This fix inability to connect to AP on slightly longer distance on some Ralink chips/devices. Reported-and-tested-by: Fabien ADAM Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 2ad776fc3d2c243dc6fd51139dde92aac9c841ac Author: Stanislaw Gruszka Date: Mon Sep 9 12:37:37 2013 +0200 rt2800: change initialization sequence to fix system freeze commit f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20 upstream. My commit commit c630ccf1a127578421a928489d51e99c05037054 Author: Stanislaw Gruszka Date: Sat Mar 16 19:19:46 2013 +0100 rt2800: rearrange bbp/rfcsr initialization make Maxim machine freeze when try to start wireless device. Initialization order and sending MCU_BOOT_SIGNAL request, changed in above commit, is important. Doing things incorrectly make PCIe bus problems, which can froze the machine. This patch change initialization sequence like vendor driver do: function NICInitializeAsic() from 2011_1007_RT5390_RT5392_Linux_STA_V2.5.0.3_DPO (PCI devices) and DPO_RT5572_LinuxSTA_2.6.1.3_20121022 (according Mediatek, latest driver for RT8070/RT3070/RT3370/RT3572/RT5370/RT5372/RT5572 USB devices). It fixes freezes on Maxim system. Resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1000679 Reported-and-tested-by: Maxim Polyakov Bisected-by: Igor Gnatenko Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 622693b31ebe725722cfab70a721546b826e2d5a Author: Rafał Miłecki Date: Sun Sep 15 00:22:47 2013 +0200 bgmac: fix internal switch initialization commit 6a391e7bf26c04a6df5f77290e1146941d210d49 upstream. Some devices (BCM4749, BCM5357, BCM53572) have internal switch that requires initialization. We already have code for this, but because of the typo in code it was never working. This resulted in network not working for some routers and possibility of soft-bricking them. Use correct bit for switch initialization and fix typo in the define. Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 03c58b665fd0ce5f0acc6ebcd3c3a0df586e05d3 Author: Miklos Szeredi Date: Mon Sep 16 14:51:59 2013 +0200 cifs: fix filp leak in cifs_atomic_open() commit dfb1d61b0e9f9e2c542e9adc8d970689f4114ff6 upstream. If an error occurs after having called finish_open() then fput() needs to be called on the already opened file. Signed-off-by: Miklos Szeredi Cc: Steve French Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 157c2c2d4500977dc280901dbbdf6edcf1613965 Author: Fabio Porcedda Date: Mon Sep 16 11:47:50 2013 +0200 net: usb: cdc_ether: Use wwan interface for Telit modules commit 0092820407901a0b2c4e343e85f96bb7abfcded1 upstream. Signed-off-by: Fabio Porcedda Acked-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1cd0ef237293972436aa9db877d347afb4c0d9df Author: Tony Lindgren Date: Wed Sep 18 12:01:58 2013 -0700 ARM: OMAP4: Fix clock_get error for GPMC during boot commit 2cfeed314207f808077edb2f1ba41ba1ebbe3e69 upstream. Looks like we still have the legacy clock alias name for omap4 GPMC (General Purpose Memory Controller), so let's fix it for the device tree naming. There's no need to keep the legacy naming as omap4 is DT only nowadays. Without this fix we get the following error while booting: [ 0.440399] omap-gpmc 50000000.gpmc: error: clk_get Reported-by: Olof Johansson Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 3334c081d7bcfe1933d2f4fbced1b20be0a6130b Author: Rafael J. Wysocki Date: Sat Sep 14 03:38:20 2013 +0200 PCI / ACPI / PM: Clear pme_poll for devices in D3cold on wakeup commit 834145156bedadfb50121f0bc5e9d9f9f942bcca upstream. Commit 448bd85 (PCI/PM: add PCIe runtime D3cold support) added a piece of code to pci_acpi_wake_dev() causing that function to behave in a special way for devices in D3cold (so that their configuration registers are not accessed before those devices are resumed). However, it didn't take the clearing of the pme_poll flag into account. That has to be done for all devices, even if they are in D3cold, or pci_pme_list_scan() will not know that wakeup has been signaled for the device and will poll its PME Status bit unnecessarily. Fix the problem by moving the clearing of the pme_poll flag in pci_acpi_wake_dev() before the code introduced by commit 448bd85. Reported-and-tested-by: David E. Box Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman