- 01 Oct, 2013 40 commits
-
-
Konstantin Khlebnikov authored
commit 8ac1c8d5 upstream. After commit 82919919 ("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 <khlebnikov@openvz.org> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Richard Guy Briggs <rgb@redhat.com> Cc: Eric Paris <eparis@redhat.com> Cc: Chuck Anderson <chuck.anderson@oracle.com> Cc: Dan Duval <dan.duval@oracle.com> Cc: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit e729eac6 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 <hui.wang@canonical.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jan Kara authored
commit d759bfa4 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:
-
Mauro Carvalho Chehab authored
commit 5077ac3b 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 <mchehab@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Randy Dunlap authored
commit a0f9354b 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" <yann.morin.1998@free.fr> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Christian König authored
commit 4f66c599 upstream. Putting everything into VRAM seems to help. Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 855f5f1d 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 authored
commit 91f3a6aa 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 6f8bbaf5 (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:
-
Stanislaw Gruszka authored
commit f4e1a4d3 upstream. My commit commit c630ccf1 Author: Stanislaw Gruszka <stf_xl@wp.pl> 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=1000679Reported-and-tested-by:
Maxim Polyakov <polyakov@dexmalabs.com> Bisected-by:
Igor Gnatenko <i.gnatenko.brain@gmail.com> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Alex Deucher authored
commit fb93df1c 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 authored
commit acf88deb 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=52952Reported-by:
Ondrej Zary <linux@rainbow-software.org> Tested-by:
Daniel Tobias <dan.g.tob@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit 290d2457 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 <jay.cornwall@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 0b31e023 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 <jay.cornwall@amd.com> Signed-off-by:
-
Tom Stellard authored
commit e5b9e750 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 <thomas.stellard@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 4543eda5 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 authored
commit 95663948 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:
-
Emil Velikov authored
commit 5087f51d upstream. Commit ea9197cc 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=67382Tested-by:
Martin Peres <martin.peres@labri.fr> Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Ben Skeggs authored
commit 182b17c8 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:
Thomas Hellstrom <thellstrom@vmware.com> Cc: Jerome Glisse <jglisse@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
commit 2e837813 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 <yc_chen@aspeedtech.com> Signed-off-by:
-
David Herrmann authored
commit 101b96f3 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 a14b1b42 Author: Mandeep Singh Baines <mandeep.baines@gmail.com> 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 <dh.herrmann@gmail.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
commit 17e1df07 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 96a02917 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> 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ä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
commit 122f46ba upstream. Since we've started to clean up pending flips when the gpu hangs in commit 96a02917 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> 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: [<ffffffff8138ee7b>] schedule+0x60/0x62 [<ffffffffa046c0dd>] intel_crtc_wait_for_pending_flips+0xb2/0x114 [i915] [<ffffffff81050ff4>] ? finish_wait+0x60/0x60 [<ffffffffa0478041>] intel_crtc_set_config+0x7f3/0x81e [i915] [<ffffffffa031780a>] drm_mode_set_config_internal+0x4f/0xc6 [drm] [<ffffffffa0319cf3>] drm_mode_setcrtc+0x44d/0x4f9 [drm] [<ffffffff810e44da>] ? might_fault+0x38/0x86 [<ffffffffa030d51f>] drm_ioctl+0x2f9/0x447 [drm] [<ffffffff8107a722>] ? trace_hardirqs_off+0xd/0xf [<ffffffffa03198a6>] ? drm_mode_setplane+0x343/0x343 [drm] [<ffffffff8112222f>] ? mntput_no_expire+0x3e/0x13d [<ffffffff81117f33>] vfs_ioctl+0x18/0x34 [<ffffffff81118776>] do_vfs_ioctl+0x396/0x454 [<ffffffff81396b37>] ? sysret_check+0x1b/0x56 [<ffffffff81118886>] SyS_ioctl+0x52/0x7d [<ffffffff81396b12>] system_call_fastpath+0x16/0x1b 2 locks held by kms_flip/14676: #0: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa0316545>] drm_modeset_lock_all+0x22/0x59 [drm] #1: (&crtc->mutex){+.+.+.}, at: [<ffffffffa031656b>] 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: [<ffffffff8138ee7b>] schedule+0x60/0x62 [<ffffffff8138f23d>] schedule_preempt_disabled+0x9/0xb [<ffffffff8138d0cd>] mutex_lock_nested+0x205/0x3b1 [<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915] [<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915] [<ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915] [<ffffffffa044e0a2>] i915_error_work_func+0x128/0x147 [i915] [<ffffffff8104a89a>] process_one_work+0x1d4/0x35a [<ffffffff8104a821>] ? process_one_work+0x15b/0x35a [<ffffffff8104b4a5>] worker_thread+0x144/0x1f0 [<ffffffff8104b361>] ? rescuer_thread+0x275/0x275 [<ffffffff8105076d>] kthread+0xac/0xb4 [<ffffffff81059d30>] ? finish_task_switch+0x3b/0xc0 [<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60 [<ffffffff81396a6c>] ret_from_fork+0x7c/0xb0 [<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60 3 locks held by kworker/u8:4/175: #0: (i915){.+.+.+}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a #1: ((&dev_priv->gpu_error.work)){+.+.+.}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a #2: (&crtc->mutex){+.+.+.}, at: [<ffffffffa0477094>] 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 <tglx@linutronix.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Alan Stern authored
commit 5f5610f6 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 <stern@rowland.harvard.edu> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Kees Cook authored
commit 297502ab 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: [<ffffffff815d50aa>] logi_dj_recv_send_report.isra.11+0x1a/0x90 CVE-2013-2895 Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Kees Cook authored
commit 0a9cd0a8 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:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Kees Cook authored
commit 41df7f6d 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:
-
Benjamin Tissoires authored
commit 0ccdd9e7 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=1003998Signed-off-by:
-
Kees Cook authored
commit 78214e81 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 authored
commit 0fb6bd06 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:
-
Benjamin Tissoires authored
commit 8821f5dc 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 authored
commit cc6b54aa 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:
-
Kees Cook authored
commit 331415ff 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:
-
Daisuke Nishimura authored
commit 6c9a27f5 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: [<ffffffff81051e3e>] sched_slice+0x6e/0xa0 [...] Call Trace: [<ffffffff81051f25>] place_entity+0x75/0xa0 [<ffffffff81056a3a>] task_fork_fair+0xaa/0x160 [<ffffffff81063c0b>] sched_fork+0x6b/0x140 [<ffffffff8106c3c2>] copy_process+0x5b2/0x1450 [<ffffffff81063b49>] ? wake_up_new_task+0xd9/0x130 [<ffffffff8106d2f4>] do_fork+0x94/0x460 [<ffffffff81072a9e>] ? sys_wait4+0xae/0x100 [<ffffffff81009598>] sys_clone+0x28/0x30 [<ffffffff8100b393>] stub_clone+0x13/0x20 [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b Signed-off-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/039601ceae06$733d3130$59b79390$@mxp.nes.nec.co.jpSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit 5a8e01f8 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/259Reported-and-tested-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
-
John Stultz authored
commit 7bd36014 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: [<ffffffff810aa9b5>] __queue_work+0x145/0x480 [ 15.850051] [ 15.850051] but task is already holding lock: [ 15.850051] (timekeeper_lock){-.-.-.}, at: [<ffffffff810df6df>] do_adjtimex+0x7f/0x100 <snip> [ 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 06c017fd ("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 <gerlando.falauto@keymile.com> Tested-by:
Lin Ming <minggr@gmail.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: http://lkml.kernel.org/r/1378943457-27314-1-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Stanislaw Gruszka authored
commit 6e956da2 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 <id2ndr@crocobox.org> Signed-off-by:
-
Rafał Miłecki authored
commit 6a391e7b 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 <zajec5@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Miklos Szeredi authored
commit dfb1d61b 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 <mszeredi@suse.cz> Cc: Steve French <sfrench@samba.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Fabio Porcedda authored
commit 00928204 upstream. Signed-off-by:
Fabio Porcedda <fabio.porcedda@gmail.com> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Rafael J. Wysocki authored
commit 83414515 upstream. Commit 448bd857 (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 448bd857. Reported-and-tested-by:
David E. Box <david.e.box@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
