commit 8c15abc94c737f9120d3d4a550abbcbb9be121f6 Author: Greg Kroah-Hartman Date: Tue Oct 1 09:18:05 2013 -0700 Linux 3.10.14 commit 97d2a12a277626098d6a001db1166447f86998d4 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 ab2b9429c40a4083d675e15d79dc34f363096235 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 fea655196e39b35ef0d6c5a6372edb53315031db 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 577e9397bcfaa293bb8de0e619fe93f69bf992b9 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 d68b9c457e6298e941b8b574f921624c6c648218 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 85f58908c038a5e1f51fb9014f0b0954f66be1d4 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 edc96e2c36766db781313a53ba130e52e74d3296 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 71828ed93986ea0f89c0daf739e13aadb870a3ef Author: Andi Kleen Date: Wed Apr 24 17:03:02 2013 -0700 perf tools: Handle JITed code in shared memory commit 89365e6c9ad4c0e090e4c6a4b67a3ce319381d89 upstream. Need to check for /dev/zero. Most likely more strings are missing too. Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1366848182-30449-1-git-send-email-andi@firstfloor.org Signed-off-by: Arnaldo Carvalho de Melo Cc: Vinson Lee Signed-off-by: Greg Kroah-Hartman commit 09642082b35034719f6916ee83b0a6251620ba74 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 3ed3690eac0c839c6216fd7f7ce0add6a1f593b2 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 39b79aa3f1554bb1e39be3b25d6c12fd429583d4 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 66ccf96185266dee7b0b15ae08e9c1359e0e1c47 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 7b7b9915f77d3c5db399866080751e9dafc9136f Author: Mauro Carvalho Chehab Date: Wed May 22 11:25:52 2013 -0300 Properly handle tristate dependencies on USB/PCI menus commit 5077ac3b8108007f4a2b4589f2d373cf55453206 upstream. As USB/PCI/MEDIA_SUPPORT dependencies can be tristate, we can't simply make the bool menu to be dependent on it. Everything below the menu should also depend on it, otherwise, we risk to allow building them with 'y', while only 'm' would be supported. So, add an IF just before everything below, in order to avoid such risks. Signed-off-by: Mauro Carvalho Chehab Cc: Randy Dunlap Signed-off-by: Greg Kroah-Hartman commit 3db27a31a8b1c89bd6a0736559ee58550efe6278 Author: Randy Dunlap Date: Wed May 8 17:28:13 2013 -0300 media: media/usb: fix kconfig dependencies commit a0f9354b1a319cb29c331bfd2e5a15d7f9b87fa4 upstream. (a.k.a. Kconfig bool depending on a tristate considered harmful) Fix various build errors when CONFIG_USB=m and media USB drivers are builtin. In this case, CONFIG_USB_ZR364XX=y, CONFIG_VIDEO_PVRUSB2=y, and CONFIG_VIDEO_STK1160=y. This is caused by (from drivers/media/usb/Kconfig): menuconfig MEDIA_USB_SUPPORT bool "Media USB Adapters" depends on USB && MEDIA_SUPPORT =m =y so MEDIA_USB_SUPPORT=y and all following Kconfig 'source' lines are included. By adding an "if USB" guard around most of this file, the needed dependencies are enforced. drivers/built-in.o: In function `zr364xx_start_readpipe': zr364xx.c:(.text+0xc726a): undefined reference to `usb_alloc_urb' zr364xx.c:(.text+0xc72bb): undefined reference to `usb_submit_urb' drivers/built-in.o: In function `zr364xx_stop_readpipe': zr364xx.c:(.text+0xc72fd): undefined reference to `usb_kill_urb' zr364xx.c:(.text+0xc7309): undefined reference to `usb_free_urb' drivers/built-in.o: In function `read_pipe_completion': zr364xx.c:(.text+0xc7acc): undefined reference to `usb_submit_urb' drivers/built-in.o: In function `send_control_msg.constprop.12': zr364xx.c:(.text+0xc7d2f): undefined reference to `usb_control_msg' drivers/built-in.o: In function `pvr2_ctl_timeout': pvrusb2-hdw.c:(.text+0xcadb6): undefined reference to `usb_unlink_urb' pvrusb2-hdw.c:(.text+0xcadcb): undefined reference to `usb_unlink_urb' drivers/built-in.o: In function `pvr2_hdw_create': (.text+0xcc42c): undefined reference to `usb_alloc_urb' drivers/built-in.o: In function `pvr2_hdw_create': (.text+0xcc448): undefined reference to `usb_alloc_urb' drivers/built-in.o: In function `pvr2_hdw_create': (.text+0xcc5f9): undefined reference to `usb_set_interface' drivers/built-in.o: In function `pvr2_hdw_create': (.text+0xcc65a): undefined reference to `usb_free_urb' drivers/built-in.o: In function `pvr2_hdw_create': (.text+0xcc666): undefined reference to `usb_free_urb' drivers/built-in.o: In function `pvr2_send_request_ex.part.22': pvrusb2-hdw.c:(.text+0xccbe3): undefined reference to `usb_submit_urb' pvrusb2-hdw.c:(.text+0xccc83): undefined reference to `usb_submit_urb' drivers/built-in.o: In function `pvr2_hdw_remove_usb_stuff.part.25': pvrusb2-hdw.c:(.text+0xcd3f9): undefined reference to `usb_kill_urb' pvrusb2-hdw.c:(.text+0xcd405): undefined reference to `usb_free_urb' pvrusb2-hdw.c:(.text+0xcd421): undefined reference to `usb_kill_urb' pvrusb2-hdw.c:(.text+0xcd42d): undefined reference to `usb_free_urb' drivers/built-in.o: In function `pvr2_hdw_device_reset': (.text+0xcd658): undefined reference to `usb_lock_device_for_reset' drivers/built-in.o: In function `pvr2_hdw_device_reset': (.text+0xcd664): undefined reference to `usb_reset_device' drivers/built-in.o: In function `pvr2_hdw_cpureset_assert': (.text+0xcd6f9): undefined reference to `usb_control_msg' drivers/built-in.o: In function `pvr2_hdw_cpufw_set_enabled': (.text+0xcd84e): undefined reference to `usb_control_msg' drivers/built-in.o: In function `pvr2_upload_firmware1': pvrusb2-hdw.c:(.text+0xcda47): undefined reference to `usb_clear_halt' pvrusb2-hdw.c:(.text+0xcdb04): undefined reference to `usb_control_msg' drivers/built-in.o: In function `pvr2_upload_firmware2': (.text+0xce7dc): undefined reference to `usb_bulk_msg' drivers/built-in.o: In function `pvr2_stream_buffer_count': pvrusb2-io.c:(.text+0xd2e05): undefined reference to `usb_alloc_urb' pvrusb2-io.c:(.text+0xd2e5b): undefined reference to `usb_kill_urb' pvrusb2-io.c:(.text+0xd2e9f): undefined reference to `usb_free_urb' drivers/built-in.o: In function `pvr2_stream_internal_flush': pvrusb2-io.c:(.text+0xd2f9b): undefined reference to `usb_kill_urb' drivers/built-in.o: In function `pvr2_buffer_queue': (.text+0xd3328): undefined reference to `usb_kill_urb' drivers/built-in.o: In function `pvr2_buffer_queue': (.text+0xd33ea): undefined reference to `usb_submit_urb' drivers/built-in.o: In function `stk1160_read_reg': (.text+0xd3efa): undefined reference to `usb_control_msg' drivers/built-in.o: In function `stk1160_write_reg': (.text+0xd3f4f): undefined reference to `usb_control_msg' drivers/built-in.o: In function `stop_streaming': stk1160-v4l.c:(.text+0xd4997): undefined reference to `usb_set_interface' drivers/built-in.o: In function `start_streaming': stk1160-v4l.c:(.text+0xd4a9f): undefined reference to `usb_set_interface' stk1160-v4l.c:(.text+0xd4afa): undefined reference to `usb_submit_urb' stk1160-v4l.c:(.text+0xd4ba3): undefined reference to `usb_set_interface' drivers/built-in.o: In function `stk1160_isoc_irq': stk1160-video.c:(.text+0xd509b): undefined reference to `usb_submit_urb' drivers/built-in.o: In function `stk1160_cancel_isoc': (.text+0xd50ef): undefined reference to `usb_kill_urb' drivers/built-in.o: In function `stk1160_free_isoc': (.text+0xd5155): undefined reference to `usb_free_coherent' drivers/built-in.o: In function `stk1160_free_isoc': (.text+0xd515d): undefined reference to `usb_free_urb' drivers/built-in.o: In function `stk1160_alloc_isoc': (.text+0xd5278): undefined reference to `usb_alloc_urb' drivers/built-in.o: In function `stk1160_alloc_isoc': (.text+0xd52c2): undefined reference to `usb_alloc_coherent' drivers/built-in.o: In function `stk1160_alloc_isoc': (.text+0xd53c4): undefined reference to `usb_free_urb' drivers/built-in.o: In function `zr364xx_driver_init': zr364xx.c:(.init.text+0x463e): undefined reference to `usb_register_driver' drivers/built-in.o: In function `pvr_init': pvrusb2-main.c:(.init.text+0x4662): undefined reference to `usb_register_driver' drivers/built-in.o: In function `stk1160_usb_driver_init': stk1160-core.c:(.init.text+0x467d): undefined reference to `usb_register_driver' drivers/built-in.o: In function `zr364xx_driver_exit': zr364xx.c:(.exit.text+0x1377): undefined reference to `usb_deregister' drivers/built-in.o: In function `pvr_exit': pvrusb2-main.c:(.exit.text+0x1389): undefined reference to `usb_deregister' drivers/built-in.o: In function `stk1160_usb_driver_exit': stk1160-core.c:(.exit.text+0x13a0): undefined reference to `usb_deregister' Suggested-by: "Yann E. MORIN" Signed-off-by: Randy Dunlap Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 075bf1f91aba3d3c689fa370850a6b89aa31cfe5 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 85faca8521551b799955359334969b2b58cdd2fa 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 abc1e807c2bd7cd5b1aeedca2c4bb41eb786828c 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 39bad38d5dddaaf1296a1e3f0bd75ee952521afc 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 Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 911181cc6e98ee814b4f1616d1b59a54b6bb8e6f 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 a7b153243b75dc0633a0ef85f1598d719a6624e6 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 c74a65651ddcef3f06e10364809452191ac6cba6 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 410653c1e46c54436a66ccf1216ffc7e8b3bd4dd 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 c7384791a785d8f356aa9de8038596cfd2ea87d3 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 5c6ece5d3786f287d61bc0ffd1ab372f47df2b81 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 6d90714d9a0d4b9c5c17952cb5affe7a1e3b6fb3 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 262246999a59ac0aab5c4dd586b16d191ffe386b 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 3614efdf382ea9da5c04ae1f312c441b78a9fafc 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 2781ca89611907abc45110fd992dc5e9d21924d9 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 b61d2139fb615a89d30d144907aefa5e66e3348f 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 590f5c013918d7d9724f048fa9d0c09e36446e20 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 d553bc6d55ec6e27cb46e6d2dd3e7e4e1f33d04b 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 45f785a21a8a8a782ceb920487b2c3da78ee77b8 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 7661107379d11e11736e3c3210a95eb421a1ad3d 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 855f21e01243b09e5166b10e9c9e88585fc8e0c5 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 dcfd5f582c316c3e595c3bb28473efb30f4c2e6c 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 30c1e32f6fb5b48d6fd1625858c25b38af9ee91f 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 be3cdbf50f4f72325d145318d6ce02acad478925 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 2ec96f1b2beb4f755a61ee961ae2dbd7ad922a35 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 9f3383881d9b8f2ea3a1e8453e4e62a57b4af9ab 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 ae5c98a48258dbdb742be23eadf9261b70d642c3 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 791abfbee86161ad63bddc6af88c0391ef7332bd 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 51f5294797f14185f9b25ad0972a4abbbeff70c6 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 013b14c3067f0d55ab115405647d9f035f67737e 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 63946e8616205dafe39b4d88f9fc3dc7c4fd79aa 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 beb6f0e8d246adca601d786d206d414d1d0a549b 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 86f7c9950b9378ed4d9e9bf8fbdf515d03fa6820 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 b1bf3479808bfb56cec46edf5dd9f47364715f46 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 22df37406d8f90135b77ec6deb9950b68bcf3f4e 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 65e8f55e673adae0177488ddb20444076f702a47 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