3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Tissoires <redacted>
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 <redacted>
Acked-by: Kees Cook <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 16 +++++++---------
drivers/hid/hid-input.c | 11 ++++++++++-
2 files changed, 17 insertions(+), 10 deletions(-)
@@ -94,7 +94,6 @@ EXPORT_SYMBOL_GPL(hid_register_report);staticstructhid_field*hid_register_field(structhid_report*report,unsignedusages,unsignedvalues){structhid_field*field;-inti;if(report->maxfield==HID_MAX_FIELDS){hid_err(report->device,"too many fields in report\n");
@@ -266,13 +263,14 @@ static int hid_add_field(struct hid_parsfield->application=hid_lookup_collection(parser,HID_COLLECTION_APPLICATION);for(i=0;i<usages;i++){-intj=i;+unsignedj=i;/* Duplicate the last usage we parsed if we have excess values */if(i>=parser->local.usage_index)j=parser->local.usage_index-1;field->usage[i].hid=parser->local.usage[j];field->usage[i].collection_index=parser->local.collection_index[j];+field->usage[i].usage_index=i;}field->maxusage=usages;
@@ -1295,7 +1293,7 @@ int hid_report_raw_event(struct hid_devigotoout;}-if(hid->claimed!=HID_CLAIMED_HIDRAW){+if(hid->claimed!=HID_CLAIMED_HIDRAW&&report->maxfield){for(a=0;a<report->maxfield;a++)hid_input_field(hid,report->field[a],cdata,interrupt);hdrv=hid->driver;---a/drivers/hid/hid-input.c+++b/drivers/hid/hid-input.c
@@ -485,6 +485,10 @@ static void hidinput_configure_usage(strif(field->flags&HID_MAIN_ITEM_CONSTANT)gotoignore;+/* Ignore if report count is out of bounds. */+if(field->report_count<1)+gotoignore;+/* only LED usages are supported in output fields */if(field->report_type==HID_OUTPUT_REPORT&&(usage->hid&HID_USAGE_PAGE)!=HID_UP_LED){
@@ -1168,7 +1172,11 @@ static void report_features(struct hid_drep_enum=&hid->report_enum[HID_FEATURE_REPORT];list_for_each_entry(rep,&rep_enum->report_list,list)-for(i=0;i<rep->maxfield;i++)+for(i=0;i<rep->maxfield;i++){+/* Ignore if report count is out of bounds. */+if(rep->field[i]->report_count<1)+continue;+for(j=0;j<rep->field[i]->maxusage;j++){/* Verify if Battery Strength feature is available */hidinput_setup_battery(hid,HID_FEATURE_REPORT,rep->field[i]);
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <redacted>
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 <redacted>
Signed-off-by: Benjamin Tissoires <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-lenovo-tpkbd.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <stern@rowland.harvard.edu>
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 <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/dummy_hcd.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <redacted>
commit 122f46badaafbe651f05c2c0f24cadee692f761b upstream.
Since we've started to clean up pending flips when the gpu hangs in
commit 96a02917a0131e52efefde49c2784c0421d6c439
Author: Ville Syrjälä [off-list ref]
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 <redacted>
Cc: Ville Syrjälä <redacted>
Cc: Chris Wilson <redacted>
Reviewed-by: Chris Wilson <redacted>
Signed-off-by: Daniel Vetter <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_irq.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <redacted>
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ä [off-list ref]
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ä <redacted>
Cc: Chris Wilson <redacted>
Reviewed-by: Chris Wilson <redacted>
Signed-off-by: Daniel Vetter <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_irq.c | 68 +++++++++++++++++++++++++++++++---------
1 file changed, 54 insertions(+), 14 deletions(-)
@@ -1407,6 +1407,34 @@ done:returnret;}+staticvoidi915_error_wake_up(structdrm_i915_private*dev_priv,+boolreset_completed)+{+structintel_ring_buffer*ring;+inti;++/*+*NotifyallwaitersforGPUcompletioneventsthatresetstatehas+*beenchanged,andthattheyneedtorestarttheirwaitafter+*checkingforpotentialerrors(andbailouttodroplocksifthereis+*agpuresetpendingsothati915_error_work_funccanacquirethem).+*/++/* Wake up __wait_seqno, potentially holding dev->struct_mutex. */+for_each_ring(ring,dev_priv,i)+wake_up_all(&ring->irq_queue);++/* Wake up intel_crtc_wait_for_pending_flips, holding crtc->mutex. */+wake_up_all(&dev_priv->pending_flip_queue);++/*+*Signaltasksblockedini915_gem_wait_for_errorthatthepending+*resetstateiscleared.+*/+if(reset_completed)+wake_up_all(&dev_priv->gpu_error.reset_queue);+}+/***i915_error_work_func-doprocesscontexterrorhandlingwork*@work:workstruct
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <redacted>
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ä <redacted>
Reviewed-by: Ville Syrjälä <redacted>
Signed-off-by: Jani Nikula <redacted>
Tested-by: Paulo Zanoni <redacted>
Signed-off-by: Daniel Vetter <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_display.c | 9 ---------
1 file changed, 9 deletions(-)
@@ -4837,9 +4837,6 @@ static int i9xx_crtc_mode_set(struct drmreturn-EINVAL;}-/* Ensure that the cursor is valid for the new mode before changing... */-intel_crtc_update_cursor(crtc,true);-if(is_lvds&&dev_priv->lvds_downclock_avail){/**Ensurewematchthereducedclock'sPtothetargetclock.
@@ -5688,9 +5685,6 @@ static int ironlake_crtc_mode_set(structintel_crtc->config.dpll.p2=clock.p2;}-/* Ensure that the cursor is valid for the new mode before changing... */-intel_crtc_update_cursor(crtc,true);-/* CPU eDP is the only output that doesn't need a PCH PLL of its own. */if(intel_crtc->config.has_pch_encoder){fp=i9xx_dpll_compute_fp(&intel_crtc->config.dpll);
@@ -5897,9 +5891,6 @@ static int haswell_crtc_mode_set(structif(!intel_ddi_pll_mode_set(crtc))return-EINVAL;-/* Ensure that the cursor is valid for the new mode before changing... */-intel_crtc_update_cursor(crtc,true);-if(intel_crtc->config.has_dp_encoder)intel_dp_set_m_n(intel_crtc);
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Herrmann <redacted>
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 [off-list ref]
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 <redacted>
Reviewed-by: Chris Wilson <redacted>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_crtc.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
@@ -2604,10 +2604,22 @@ int drm_mode_getfb(struct drm_device *der->depth=fb->depth;r->bpp=fb->bits_per_pixel;r->pitch=fb->pitches[0];-if(fb->funcs->create_handle)-ret=fb->funcs->create_handle(fb,file_priv,&r->handle);-else+if(fb->funcs->create_handle){+if(file_priv->is_master||capable(CAP_SYS_ADMIN)){+ret=fb->funcs->create_handle(fb,file_priv,+&r->handle);+}else{+/* GET_FB() is an unprivileged ioctl so we must not+*returnabuffer-handletonon-masterprocesses!For+*backwards-compatibilityreasons,wecannotmake+*GET_FB()privileged,sojustreturnaninvalidhandle+*fornon-masters.*/+r->handle=0;+ret=0;+}+}else{ret=-ENODEV;+}drm_framebuffer_unreference(fb);
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Skeggs <redacted>
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 <redacted>
Reviewed-by: Thomas Hellstrom <redacted>
Cc: Jerome Glisse <redacted>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <redacted>
commit f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20 upstream.
My commit
commit c630ccf1a127578421a928489d51e99c05037054
Author: Stanislaw Gruszka [off-list ref]
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 <redacted>
Bisected-by: Igor Gnatenko [off-list ref]
Signed-off-by: Stanislaw Gruszka <redacted>
Signed-off-by: John W. Linville <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <redacted>
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 <redacted>
Signed-off-by: Stanislaw Gruszka <redacted>
Signed-off-by: John W. Linville <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 7 +++++++
1 file changed, 7 insertions(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 [off-list ref]
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/evergreen.c | 25 +++++++++++++++++++++----
drivers/gpu/drm/radeon/evergreend.h | 4 ++++
2 files changed, 25 insertions(+), 4 deletions(-)
@@ -1830,18 +1831,34 @@ static u32 evergreen_line_buffer_adjust(*non-linkedcrtcsformaximumlinebufferallocation.*/if(radeon_crtc->base.enabled&&mode){-if(other_mode)+if(other_mode){tmp=0;/* 1/2 */-else+buffer_alloc=1;+}else{tmp=2;/* whole */-}else+buffer_alloc=2;+}+}else{tmp=0;+buffer_alloc=0;+}/* second controller of the pair uses second half of the lb */if(radeon_crtc->crtc_id%2)tmp+=4;WREG32(DC_LB_MEMORY_SPLIT+radeon_crtc->crtc_offset,tmp);+if(ASIC_IS_DCE41(rdev)||ASIC_IS_DCE5(rdev)){+WREG32(PIPE0_DMIF_BUFFER_CONTROL+pipe_offset,+DMIF_BUFFERS_ALLOCATED(buffer_alloc));+for(i=0;i<rdev->usec_timeout;i++){+if(RREG32(PIPE0_DMIF_BUFFER_CONTROL+pipe_offset)&+DMIF_BUFFERS_ALLOCATED_COMPLETED)+break;+udelay(1);+}+}+if(radeon_crtc->base.enabled&&mode){switch(tmp){case0:---a/drivers/gpu/drm/radeon/evergreend.h+++b/drivers/gpu/drm/radeon/evergreend.h
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/btc_dpm.c | 6 ++++++
drivers/gpu/drm/radeon/ni_dpm.c | 6 ++++++
drivers/gpu/drm/radeon/si_dpm.c | 6 ++++++
3 files changed, 18 insertions(+)
@@ -2699,6 +2699,12 @@ int btc_dpm_init(struct radeon_device *relserdev->pm.dpm.dyn_state.sclk_mclk_delta=10000;+/* make sure dc limits are valid */+if((rdev->pm.dpm.dyn_state.max_clock_voltage_on_dc.sclk==0)||+(rdev->pm.dpm.dyn_state.max_clock_voltage_on_dc.mclk==0))+rdev->pm.dpm.dyn_state.max_clock_voltage_on_dc=+rdev->pm.dpm.dyn_state.max_clock_voltage_on_ac;+return0;}---a/drivers/gpu/drm/radeon/ni_dpm.c+++b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -4270,6 +4270,12 @@ int ni_dpm_init(struct radeon_device *rdni_pi->use_power_boost_limit=true;+/* make sure dc limits are valid */+if((rdev->pm.dpm.dyn_state.max_clock_voltage_on_dc.sclk==0)||+(rdev->pm.dpm.dyn_state.max_clock_voltage_on_dc.mclk==0))+rdev->pm.dpm.dyn_state.max_clock_voltage_on_dc=+rdev->pm.dpm.dyn_state.max_clock_voltage_on_ac;+return0;}---a/drivers/gpu/drm/radeon/si_dpm.c+++b/drivers/gpu/drm/radeon/si_dpm.c
@@ -6401,6 +6401,12 @@ int si_dpm_init(struct radeon_device *rdsi_initialize_powertune_defaults(rdev);+/* make sure dc limits are valid */+if((rdev->pm.dpm.dyn_state.max_clock_voltage_on_dc.sclk==0)||+(rdev->pm.dpm.dyn_state.max_clock_voltage_on_dc.mclk==0))+rdev->pm.dpm.dyn_state.max_clock_voltage_on_dc=+rdev->pm.dpm.dyn_state.max_clock_voltage_on_ac;+return0;}
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_atombios.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <redacted>
Tested-by: Daniel Tobias <redacted>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/rs400.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
@@ -174,10 +174,13 @@ int rs400_gart_enable(struct radeon_devi/* FIXME: according to doc we should set HIDE_MMCFG_BAR=0,*AGPMODE30=0&AGP30ENHANCED=0inNB_CNTL*/if((rdev->family==CHIP_RS690)||(rdev->family==CHIP_RS740)){-WREG32_MC(RS480_MC_MISC_CNTL,-(RS480_GART_INDEX_REG_EN|RS690_BLOCK_GFX_D3_EN));+tmp=RREG32_MC(RS480_MC_MISC_CNTL);+tmp|=RS480_GART_INDEX_REG_EN|RS690_BLOCK_GFX_D3_EN;+WREG32_MC(RS480_MC_MISC_CNTL,tmp);}else{-WREG32_MC(RS480_MC_MISC_CNTL,RS480_GART_INDEX_REG_EN);+tmp=RREG32_MC(RS480_MC_MISC_CNTL);+tmp|=RS480_GART_INDEX_REG_EN;+WREG32_MC(RS480_MC_MISC_CNTL,tmp);}/* Enable gart */WREG32_MC(RS480_AGP_ADDRESS_SPACE_SIZE,(RS480_GART_EN|size_reg));
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/atombios_encoders.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
@@ -1652,8 +1652,12 @@ radeon_atom_encoder_dpms_dig(struct drm_atombios_dig_encoder_setup(encoder,ATOM_ENABLE,0);atombios_dig_transmitter_setup(encoder,ATOM_TRANSMITTER_ACTION_SETUP,0,0);atombios_dig_transmitter_setup(encoder,ATOM_TRANSMITTER_ACTION_ENABLE,0,0);-/* some early dce3.2 boards have a bug in their transmitter control table */-if((rdev->family!=CHIP_RV710)&&(rdev->family!=CHIP_RV730))+/* some dce3.x boards have a bug in their transmitter control table.+*ACTION_ENABLE_OUTPUTcanprobablybedroppedsinceACTION_ENABLE+*doesthesamethingandmore.+*/+if((rdev->family!=CHIP_RV710)&&(rdev->family!=CHIP_RV730)&&+(rdev->family!=CHIP_RS880))atombios_dig_transmitter_setup(encoder,ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT,0,0);}if(ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder))&&connector){
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
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 <mpatocka@redhat.com>
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Reported-by: Vasiliy Glazov <redacted>
Tested-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/marvell/skge.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Khlebnikov <redacted>
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 <redacted>
Cc: Luiz Capitulino <redacted>
Cc: Richard Guy Briggs <redacted>
Cc: Eric Paris <eparis@redhat.com>
Cc: Chuck Anderson <redacted>
Cc: Dan Duval <redacted>
Cc: Dave Kleikamp <redacted>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jonghwan Choi <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/audit.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anatol Pomozov <redacted>
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 <redacted>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Cc: Jonghwan Choi <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
block/cfq-iosched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/atombios_dp.c | 6 +++---
drivers/gpu/drm/radeon/atombios_i2c.c | 4 +++-
2 files changed, 6 insertions(+), 4 deletions(-)
@@ -50,7 +50,7 @@ static char *pre_emph_names[] = {*orfromatom.Notethatatomoperateson*dwunits.*/-staticvoidradeon_copy_swap(u8*dst,u8*src,u8num_bytes,boolto_le)+voidradeon_atom_copy_swap(u8*dst,u8*src,u8num_bytes,boolto_le){#ifdef __BIG_ENDIANu8src_tmp[20],dst_tmp[20];/* used for byteswapping */
@@ -100,7 +100,7 @@ static int radeon_process_aux_ch(structbase=(unsignedchar*)(rdev->mode_info.atom_context->scratch+1);-radeon_copy_swap(base,send,send_bytes,true);+radeon_atom_copy_swap(base,send,send_bytes,true);args.v1.lpAuxRequest=cpu_to_le16((u16)(0+4));args.v1.lpDataOut=cpu_to_le16((u16)(16+4));
@@ -137,7 +137,7 @@ static int radeon_process_aux_ch(structrecv_bytes=recv_size;if(recv&&recv_size)-radeon_copy_swap(recv,base+16,recv_bytes,false);+radeon_atom_copy_swap(recv,base+16,recv_bytes,false);returnrecv_bytes;}---a/drivers/gpu/drm/radeon/atombios_i2c.c+++b/drivers/gpu/drm/radeon/atombios_i2c.c
@@ -27,6 +27,8 @@#include"radeon.h"#include"atom.h"+externvoidradeon_atom_copy_swap(u8*dst,u8*src,u8num_bytes,boolto_le);+#define TARGET_HW_I2C_CLOCK 50/* these are a limitation of ProcessI2cChannelTransaction not the hw */
@@ -77,7 +79,7 @@ static int radeon_process_i2c_ch(struct}if(!(flags&HW_I2C_WRITE))-memcpy(buf,base,num);+radeon_atom_copy_swap(buf,base,num,false);return0;}
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <redacted>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/cik.c | 9 +++++----
drivers/gpu/drm/radeon/evergreen.c | 9 +++++----
drivers/gpu/drm/radeon/ni.c | 9 +++++----
drivers/gpu/drm/radeon/r600.c | 9 +++++----
drivers/gpu/drm/radeon/rv770.c | 9 +++++----
drivers/gpu/drm/radeon/si.c | 9 +++++----
6 files changed, 30 insertions(+), 24 deletions(-)
@@ -6007,6 +6007,11 @@ static int cik_startup(struct radeon_devstructradeon_ring*ring;intr;+/* scratch needs to be initialized before MC */+r=r600_vram_scratch_init(rdev);+if(r)+returnr;+cik_mc_program(rdev);if(rdev->flags&RADEON_IS_IGP){
@@ -6036,10 +6041,6 @@ static int cik_startup(struct radeon_dev}}-r=r600_vram_scratch_init(rdev);-if(r)-returnr;-r=cik_pcie_gart_enable(rdev);if(r)returnr;---a/drivers/gpu/drm/radeon/evergreen.c+++b/drivers/gpu/drm/radeon/evergreen.c
@@ -5106,6 +5106,11 @@ static int evergreen_startup(struct rade/* enable aspm */evergreen_program_aspm(rdev);+/* scratch needs to be initialized before MC */+r=r600_vram_scratch_init(rdev);+if(r)+returnr;+evergreen_mc_program(rdev);if(ASIC_IS_DCE5(rdev)){
@@ -5131,10 +5136,6 @@ static int evergreen_startup(struct rade}}-r=r600_vram_scratch_init(rdev);-if(r)-returnr;-if(rdev->flags&RADEON_IS_AGP){evergreen_agp_enable(rdev);}else{---a/drivers/gpu/drm/radeon/ni.c+++b/drivers/gpu/drm/radeon/ni.c
@@ -2083,6 +2083,11 @@ static int cayman_startup(struct radeon_/* enable aspm */evergreen_program_aspm(rdev);+/* scratch needs to be initialized before MC */+r=r600_vram_scratch_init(rdev);+if(r)+returnr;+evergreen_mc_program(rdev);if(rdev->flags&RADEON_IS_IGP){
@@ -2109,10 +2114,6 @@ static int cayman_startup(struct radeon_}}-r=r600_vram_scratch_init(rdev);-if(r)-returnr;-r=cayman_pcie_gart_enable(rdev);if(r)returnr;---a/drivers/gpu/drm/radeon/r600.c+++b/drivers/gpu/drm/radeon/r600.c
@@ -3334,6 +3334,11 @@ static int r600_startup(struct radeon_de/* enable pcie gen2 link */r600_pcie_gen2_enable(rdev);+/* scratch needs to be initialized before MC */+r=r600_vram_scratch_init(rdev);+if(r)+returnr;+r600_mc_program(rdev);if(!rdev->me_fw||!rdev->pfp_fw||!rdev->rlc_fw){
@@ -3344,10 +3349,6 @@ static int r600_startup(struct radeon_de}}-r=r600_vram_scratch_init(rdev);-if(r)-returnr;-if(rdev->flags&RADEON_IS_AGP){r600_agp_enable(rdev);}else{---a/drivers/gpu/drm/radeon/rv770.c+++b/drivers/gpu/drm/radeon/rv770.c
@@ -1829,6 +1829,11 @@ static int rv770_startup(struct radeon_d/* enable pcie gen2 link */rv770_pcie_gen2_enable(rdev);+/* scratch needs to be initialized before MC */+r=r600_vram_scratch_init(rdev);+if(r)+returnr;+rv770_mc_program(rdev);if(!rdev->me_fw||!rdev->pfp_fw||!rdev->rlc_fw){
@@ -1839,10 +1844,6 @@ static int rv770_startup(struct radeon_d}}-r=r600_vram_scratch_init(rdev);-if(r)-returnr;-if(rdev->flags&RADEON_IS_AGP){rv770_agp_enable(rdev);}else{---a/drivers/gpu/drm/radeon/si.c+++b/drivers/gpu/drm/radeon/si.c
@@ -6422,6 +6422,11 @@ static int si_startup(struct radeon_devi/* enable aspm */si_program_aspm(rdev);+/* scratch needs to be initialized before MC */+r=r600_vram_scratch_init(rdev);+if(r)+returnr;+si_mc_program(rdev);if(!rdev->me_fw||!rdev->pfp_fw||!rdev->ce_fw||
@@ -6439,10 +6444,6 @@ static int si_startup(struct radeon_devireturnr;}-r=r600_vram_scratch_init(rdev);-if(r)-returnr;-r=si_pcie_gart_enable(rdev);if(r)returnr;
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emil Velikov <redacted>
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 <redacted>
Signed-off-by: Emil Velikov <redacted>
Signed-off-by: Ben Skeggs <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit 0431b2742f8e7755f3bbf5924900d12973412e94 upstream.
This adds the pci ids for the berlin GPU core.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/drm/drm_pciids.h | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit 7c4622d5415038a74964480844de885e7253a0f4 upstream.
Sets the right paramters for the new pci id.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/cik.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 [off-list ref]
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/cik.c | 29 ++++++++++++++++++++++-------
drivers/gpu/drm/radeon/cikd.h | 4 ++++
2 files changed, 26 insertions(+), 7 deletions(-)
@@ -6452,22 +6452,37 @@ static u32 dce8_line_buffer_adjust(struc*themusingthestereoblender.*/if(radeon_crtc->base.enabled&&mode){-if(mode->crtc_hdisplay<1920)+if(mode->crtc_hdisplay<1920){tmp=1;-elseif(mode->crtc_hdisplay<2560)+buffer_alloc=2;+}elseif(mode->crtc_hdisplay<2560){tmp=2;-elseif(mode->crtc_hdisplay<4096)+buffer_alloc=2;+}elseif(mode->crtc_hdisplay<4096){tmp=0;-else{+buffer_alloc=(rdev->flags&RADEON_IS_IGP)?2:4;+}else{DRM_DEBUG_KMS("Mode too big for LB!\n");tmp=0;+buffer_alloc=(rdev->flags&RADEON_IS_IGP)?2:4;}-}else+}else{tmp=1;+buffer_alloc=0;+}WREG32(LB_MEMORY_CTRL+radeon_crtc->crtc_offset,LB_MEMORY_CONFIG(tmp)|LB_MEMORY_SIZE(0x6B0));+WREG32(PIPE0_DMIF_BUFFER_CONTROL+pipe_offset,+DMIF_BUFFERS_ALLOCATED(buffer_alloc));+for(i=0;i<rdev->usec_timeout;i++){+if(RREG32(PIPE0_DMIF_BUFFER_CONTROL+pipe_offset)&+DMIF_BUFFERS_ALLOCATED_COMPLETED)+break;+udelay(1);+}+if(radeon_crtc->base.enabled&&mode){switch(tmp){case0:---a/drivers/gpu/drm/radeon/cikd.h+++b/drivers/gpu/drm/radeon/cikd.h
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/cik.c | 41 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian König <christian.koenig@amd.com>
commit 6a3808b8233eb91b57c230cf1161ac116a189ffd upstream.
The same as on evergreen.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reported-by: FrankR Huang <redacted>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/cik.c | 4 ++++
1 file changed, 4 insertions(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Smith <redacted>
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 <redacted>
Signed-off-by: Jozsef Kadlecsik <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netfilter/ipset/ip_set_hash_gen.h | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Solomon Peachy <redacted>
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 <redacted>
Signed-off-by: John W. Linville <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/cw1200/cw1200_spi.c | 19 ++++++++++++++++---
drivers/net/wireless/cw1200/fwio.c | 2 +-
drivers/net/wireless/cw1200/hwbus.h | 1 +
drivers/net/wireless/cw1200/hwio.c | 15 +++++++++++++++
4 files changed, 33 insertions(+), 4 deletions(-)
@@ -270,13 +273,22 @@ exit:staticintcw1200_spi_irq_unsubscribe(structhwbus_priv*self){-intret=0;-pr_debug("SW IRQ unsubscribe\n");disable_irq_wake(self->func->irq);free_irq(self->func->irq,self);-returnret;+return0;+}++staticintcw1200_spi_irq_enable(structhwbus_priv*self,intenable)+{+/* Disables are handled by the interrupt handler */+if(enable&&self->irq_disabled){+enable_irq(self->func->irq);+self->irq_disabled=0;+}++return0;}staticintcw1200_spi_off(conststructcw1200_platform_data_spi*pdata)
@@ -356,6 +368,7 @@ static struct hwbus_ops cw1200_spi_hwbus.unlock=cw1200_spi_unlock,.align_size=cw1200_spi_align_size,.power_mgmt=cw1200_spi_pm,+.irq_enable=cw1200_spi_irq_enable,};/* Probe Function to be called by SPI stack when device is discovered */---a/drivers/net/wireless/cw1200/fwio.c+++b/drivers/net/wireless/cw1200/fwio.c
@@ -273,6 +273,21 @@ int __cw1200_irq_enable(struct cw1200_cou16val16;intret;+/* We need to do this hack because the SPI layer can sleep on I/O+andthegeneralpathinvolvesI/Otothedeviceininterrupt+context.++However,theinitialenablecallneedstogotothehardware.++Wedon'tworryaboutshutdownbecausewedoafullresetwhich+clearstheinterruptenabledbits.+*/+if(priv->hwbus_ops->irq_enable){+ret=priv->hwbus_ops->irq_enable(priv->hwbus_priv,enable);+if(ret||enable<2)+returnret;+}+if(HIF_8601_SILICON==priv->hw_type){ret=__cw1200_reg_read_32(priv,ST90TDS_CONFIG_REG_ID,&val32);if(ret<0){
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Solomon Peachy <redacted>
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 <redacted>
Signed-off-by: John W. Linville <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/cw1200/cw1200_spi.c | 9 +++++++++
1 file changed, 9 insertions(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: "J. Bruce Fields" <redacted>
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 <redacted>
Signed-off-by: J. Bruce Fields <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sunrpc/auth_gss/gss_rpc_upcall.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: "J. Bruce Fields" <redacted>
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 <redacted>
Signed-off-by: J. Bruce Fields <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sunrpc/auth_gss/gss_rpc_upcall.c | 30 ++++++++++++++++++++++++++++++
net/sunrpc/auth_gss/gss_rpc_xdr.c | 3 +++
net/sunrpc/auth_gss/gss_rpc_xdr.h | 5 ++++-
3 files changed, 37 insertions(+), 1 deletion(-)
@@ -213,6 +213,30 @@ static int gssp_call(struct net *net, streturnstatus;}+staticvoidgssp_free_receive_pages(structgssx_arg_accept_sec_context*arg)+{+inti;++for(i=0;i<arg->npages&&arg->pages[i];i++)+__free_page(arg->pages[i]);+}++staticintgssp_alloc_receive_pages(structgssx_arg_accept_sec_context*arg)+{+inti;++arg->npages=DIV_ROUND_UP(NGROUPS_MAX*4,PAGE_SIZE);+arg->pages=kzalloc(arg->npages*sizeof(structpage*),GFP_KERNEL);++for(i=0;i<arg->npages;i++){+arg->pages[i]=alloc_page(GFP_KERNEL);+if(arg->pages[i]==NULL){+gssp_free_receive_pages(arg);+return-ENOMEM;+}+}+return0;+}/**Publicfunctions
@@ -261,10 +285,16 @@ int gssp_accept_sec_context_upcall(strucarg.context_handle=&ctxh;res.output_token->len=GSSX_max_output_token_sz;+ret=gssp_alloc_receive_pages(&arg);+if(ret)+returnret;+/* use nfs/ for targ_name ? */ret=gssp_call(net,&msg);+gssp_free_receive_pages(&arg);+/* we need to fetch all data even in case of error so*thatwecanfreespecialstrcturesistheyhavebeenallocated*/data->major_status=res.status.major_status;---a/net/sunrpc/auth_gss/gss_rpc_xdr.c+++b/net/sunrpc/auth_gss/gss_rpc_xdr.c
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: "J. Bruce Fields" <redacted>
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 <redacted>
Signed-off-by: J. Bruce Fields <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sunrpc/auth_gss/gss_rpc_xdr.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
@@ -166,14 +166,15 @@ static int dummy_dec_opt_array(struct xdreturn0;}-staticintget_s32(structxdr_stream*xdr,s32*res)+staticintget_host_u32(structxdr_stream*xdr,u32*res){__be32*p;p=xdr_inline_decode(xdr,4);if(!p)return-EINVAL;-memcpy(res,p,sizeof(s32));+/* Contents of linux creds are all host-endian: */+memcpy(res,p,sizeof(u32));return0;}
@@ -182,8 +183,9 @@ static int gssx_dec_linux_creds(struct x{u32length;__be32*p;-s32tmp;-intN,i,err;+u32tmp;+u32N;+inti,err;p=xdr_inline_decode(xdr,4);if(unlikely(p==NULL))
@@ -195,19 +197,19 @@ static int gssx_dec_linux_creds(struct xreturn-ENOSPC;/* uid */-err=get_s32(xdr,&tmp);+err=get_host_u32(xdr,&tmp);if(err)returnerr;creds->cr_uid=make_kuid(&init_user_ns,tmp);/* gid */-err=get_s32(xdr,&tmp);+err=get_host_u32(xdr,&tmp);if(err)returnerr;creds->cr_gid=make_kgid(&init_user_ns,tmp);/* number of additional gid's */-err=get_s32(xdr,&tmp);+err=get_host_u32(xdr,&tmp);if(err)returnerr;N=tmp;
@@ -220,7 +222,7 @@ static int gssx_dec_linux_creds(struct x/* gid's */for(i=0;i<N;i++){kgid_tkgid;-err=get_s32(xdr,&tmp);+err=get_host_u32(xdr,&tmp);if(err)gotoout_free_groups;err=-EINVAL;
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: "J. Bruce Fields" <redacted>
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 <redacted>
Signed-off-by: J. Bruce Fields <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sunrpc/auth_gss/gss_rpc_xdr.c | 32 +++++++++++++-------------------
1 file changed, 13 insertions(+), 19 deletions(-)
@@ -166,14 +166,14 @@ static int dummy_dec_opt_array(struct xdreturn0;}-staticintget_s32(void**p,void*max,s32*res)+staticintget_s32(structxdr_stream*xdr,s32*res){-void*base=*p;-void*next=(void*)((char*)base+sizeof(s32));-if(unlikely(next>max||next<base))+__be32*p;++p=xdr_inline_decode(xdr,4);+if(!p)return-EINVAL;-memcpy(res,base,sizeof(s32));-*p=next;+memcpy(res,p,sizeof(s32));return0;}
@@ -182,7 +182,6 @@ static int gssx_dec_linux_creds(struct x{u32length;__be32*p;-void*q,*end;s32tmp;intN,i,err;
@@ -192,33 +191,28 @@ static int gssx_dec_linux_creds(struct xlength=be32_to_cpup(p);-/* FIXME: we do not want to use the scratch buffer for this one-*mayneedtousefunctionsthatallowsustoaccessaniovector-*directly*/-p=xdr_inline_decode(xdr,length);-if(unlikely(p==NULL))+if(length>(3+NGROUPS_MAX)*sizeof(u32))return-ENOSPC;-q=p;-end=q+length;-/* uid */-err=get_s32(&q,end,&tmp);+err=get_s32(xdr,&tmp);if(err)returnerr;creds->cr_uid=make_kuid(&init_user_ns,tmp);/* gid */-err=get_s32(&q,end,&tmp);+err=get_s32(xdr,&tmp);if(err)returnerr;creds->cr_gid=make_kgid(&init_user_ns,tmp);/* number of additional gid's */-err=get_s32(&q,end,&tmp);+err=get_s32(xdr,&tmp);if(err)returnerr;N=tmp;+if((3+N)*sizeof(u32)!=length)+return-EINVAL;creds->cr_group_info=groups_alloc(N);if(creds->cr_group_info==NULL)return-ENOMEM;
@@ -226,7 +220,7 @@ static int gssx_dec_linux_creds(struct x/* gid's */for(i=0;i<N;i++){kgid_tkgid;-err=get_s32(&q,end,&tmp);+err=get_s32(xdr,&tmp);if(err)gotoout_free_groups;err=-EINVAL;
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Khalid Aziz <redacted>
commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream.
I am working with a tool that simulates oracle database I/O workload.
This tool (orion to be specific -
<http://docs.oracle.com/cd/E11882_01/server.112/e16638/iodesign.htm#autoId24>)
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 <redacted>
Cc: Pravin B Shelar <redacted>
Cc: Christoph Lameter <redacted>
Cc: Andrea Arcangeli <redacted>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <redacted>
Cc: Rik van Riel <redacted>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Andi Kleen <redacted>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/swap.c | 77 +++++++++++++++++++++++++++++++++++++++++---------------------
1 file changed, 52 insertions(+), 25 deletions(-)
@@ -81,6 +82,19 @@ static void __put_compound_page(struct pstaticvoidput_compound_page(structpage*page){+/*+*hugetlbfspagescannotbesplitfromunderus.Ifthisisa+*hugetlbfspage,checkrefcountonheadpageandreleasethepageif+*therefcountbecomeszero.+*/+if(PageHuge(page)){+page=compound_head(page);+if(put_page_testzero(page))+__put_compound_page(page);++return;+}+if(unlikely(PageTail(page))){/* __split_huge_page_refcount can run under us */structpage*page_head=compound_trans_head(page);
@@ -184,38 +198,51 @@ bool __get_page_tail(struct page *page)*properPTlockthatalreadyserializesagainst*split_huge_page().*/-unsignedlongflags;boolgot=false;-structpage*page_head=compound_trans_head(page);+structpage*page_head;-if(likely(page!=page_head&&get_page_unless_zero(page_head))){+/*+*Ifthisisahugetlbfspageitcannotbesplitunderus.Simply+*incrementrefcountfortheheadpage.+*/+if(PageHuge(page)){+page_head=compound_head(page);+atomic_inc(&page_head->_count);+got=true;+}else{+unsignedlongflags;++page_head=compound_trans_head(page);+if(likely(page!=page_head&&+get_page_unless_zero(page_head))){++/* Ref to put_compound_page() comment. */+if(PageSlab(page_head)){+if(likely(PageTail(page))){+__get_page_tail_foll(page,false);+returntrue;+}else{+put_page(page_head);+returnfalse;+}+}-/* Ref to put_compound_page() comment. */-if(PageSlab(page_head)){+/*+*page_headwasn'tadanglingpointerbutit+*maynotbeaheadpageanymorebythetime+*weobtainthelock.Thatisokaslongasit+*can'tbefreedfromunderus.+*/+flags=compound_lock_irqsave(page_head);+/* here __split_huge_page_refcount won't run anymore */if(likely(PageTail(page))){__get_page_tail_foll(page,false);-returntrue;-}else{-put_page(page_head);-returnfalse;+got=true;}+compound_unlock_irqrestore(page_head,flags);+if(unlikely(!got))+put_page(page_head);}--/*-*page_headwasn'tadanglingpointerbutit-*maynotbeaheadpageanymorebythetime-*weobtainthelock.Thatisokaslongasit-*can'tbefreedfromunderus.-*/-flags=compound_lock_irqsave(page_head);-/* here __split_huge_page_refcount won't run anymore */-if(likely(PageTail(page))){-__get_page_tail_foll(page,false);-got=true;-}-compound_unlock_irqrestore(page_head,flags);-if(unlikely(!got))-put_page(page_head);}returngot;}
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Reported-by: normalrawr@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/rv770_dpm.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
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 <redacted>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/udf/super.c | 42 ++++++++++++++++++++++++------------------
1 file changed, 24 insertions(+), 18 deletions(-)
--- a/fs/udf/super.c+++ b/fs/udf/super.c
@@ -630,6 +630,12 @@ static int udf_remount_fs(struct super_bstructudf_sb_info*sbi=UDF_SB(sb);interror=0;+if(sbi->s_lvid_bh){+intwrite_rev=le16_to_cpu(udf_sb_lvidiu(sbi)->minUDFWriteRev);+if(write_rev>UDF_MAX_WRITE_VERSION&&!(*flags&MS_RDONLY))+return-EACCES;+}+uopt.flags=sbi->s_flags;uopt.uid=sbi->s_uid;uopt.gid=sbi->s_gid;
@@ -649,12 +655,6 @@ static int udf_remount_fs(struct super_bsbi->s_dmode=uopt.dmode;write_unlock(&sbi->s_cred_lock);-if(sbi->s_lvid_bh){-intwrite_rev=le16_to_cpu(udf_sb_lvidiu(sbi)->minUDFWriteRev);-if(write_rev>UDF_MAX_WRITE_VERSION)-*flags|=MS_RDONLY;-}-if((*flags&MS_RDONLY)==(sb->s_flags&MS_RDONLY))gotoout_unlock;
@@ -1284,16 +1284,18 @@ static int udf_load_partdesc(struct supegotoout_bh;}}else{+/*+*Ifwehaveapartitionwithvirtualmap,wedon'thandle+*writingtoit(weoverwriteblocksinsteadofrelocating+*them).+*/+if(!(sb->s_flags&MS_RDONLY)){+ret=-EACCES;+gotoout_bh;+}ret=udf_load_vat(sb,i,type1_idx);if(ret<0)gotoout_bh;-/*-*Markfilesystemread-onlyifwehaveapartitionwith-*virtualmapsincewedon'thandlewritingtoit(we-*overwriteblocksinsteadofrelocatingthem).-*/-sb->s_flags|=MS_RDONLY;-pr_notice("Filesystem marked read-only because writing to pseudooverwrite partition is not implemented\n");}ret=0;out_bh:
@@ -2103,8 +2105,11 @@ static int udf_fill_super(struct super_bUDF_MAX_READ_VERSION);ret=-EINVAL;gotoerror_out;-}elseif(minUDFWriteRev>UDF_MAX_WRITE_VERSION)-sb->s_flags|=MS_RDONLY;+}elseif(minUDFWriteRev>UDF_MAX_WRITE_VERSION&&+!(sb->s_flags&MS_RDONLY)){+ret=-EACCES;+gotoerror_out;+}sbi->s_udfrev=minUDFWriteRev;
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
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 <jack@suse.cz>
Cc: Hui Wang <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/udf/super.c | 300 ++++++++++++++++++++++++++++++++++-----------------------
1 file changed, 183 insertions(+), 117 deletions(-)
--- a/fs/udf/super.c+++ b/fs/udf/super.c
@@ -843,27 +843,38 @@ static int udf_find_fileset(struct superreturn1;}+/*+*LoadprimaryVolumeDescriptorSequence+*+*Return<0onerror,0onsuccess.-EAGAINisspecialmeaningnextsequence+*shouldbetried.+*/staticintudf_load_pvoldesc(structsuper_block*sb,sector_tblock){structprimaryVolDesc*pvoldesc;structustr*instr,*outstr;structbuffer_head*bh;uint16_tident;-intret=1;+intret=-ENOMEM;instr=kmalloc(sizeof(structustr),GFP_NOFS);if(!instr)-return1;+return-ENOMEM;outstr=kmalloc(sizeof(structustr),GFP_NOFS);if(!outstr)gotoout1;bh=udf_read_tagged(sb,block,block,&ident);-if(!bh)+if(!bh){+ret=-EAGAIN;gotoout2;+}-BUG_ON(ident!=TAG_IDENT_PVD);+if(ident!=TAG_IDENT_PVD){+ret=-EIO;+gotoout_bh;+}pvoldesc=(structprimaryVolDesc*)bh->b_data;
@@ -889,8 +900,9 @@ static int udf_load_pvoldesc(struct supeif(udf_CS0toUTF8(outstr,instr))udf_debug("volSetIdent[] = '%s'\n",outstr->u_name);-brelse(bh);ret=0;+out_bh:+brelse(bh);out2:kfree(outstr);out1:
@@ -947,7 +959,7 @@ static int udf_load_metadata_files(strucif(mdata->s_mirror_fe==NULL){udf_err(sb,"Both metadata and mirror metadata inode efe can not found\n");-gotoerror_exit;+return-EIO;}}
@@ -964,23 +976,18 @@ static int udf_load_metadata_files(strucaddr.logicalBlockNum,addr.partitionReferenceNum);mdata->s_bitmap_fe=udf_iget(sb,&addr);-if(mdata->s_bitmap_fe==NULL){if(sb->s_flags&MS_RDONLY)udf_warn(sb,"bitmap inode efe not found but it's ok since the disc is mounted read-only\n");else{udf_err(sb,"bitmap inode efe not found and attempted read-write mount\n");-gotoerror_exit;+return-EIO;}}}udf_debug("udf_load_metadata_files Ok\n");-return0;--error_exit:-return1;}staticvoidudf_load_fileset(structsuper_block*sb,structbuffer_head*bh,
@@ -1113,7 +1120,7 @@ static int udf_fill_partdesc_info(structif(phd->freedSpaceBitmap.extLength){structudf_bitmap*bitmap=udf_sb_alloc_bitmap(sb,p_index);if(!bitmap)-return1;+return-ENOMEM;map->s_fspace.s_bitmap=bitmap;bitmap->s_extPosition=le32_to_cpu(phd->freedSpaceBitmap.extPosition);
@@ -1165,7 +1172,7 @@ static int udf_load_vat(struct super_bloudf_find_vat_block(sb,p_index,type1_index,blocks-1);}if(!sbi->s_vat_inode)-return1;+return-EIO;if(map->s_partition_type==UDF_VIRTUAL_MAP15){map->s_type_specific.s_virtual.s_start_offset=0;
@@ -1177,7 +1184,7 @@ static int udf_load_vat(struct super_blopos=udf_block_map(sbi->s_vat_inode,0);bh=sb_bread(sb,pos);if(!bh)-return1;+return-EIO;vat20=(structvirtualAllocationTable20*)bh->b_data;}else{vat20=(structvirtualAllocationTable20*)
@@ -1195,6 +1202,12 @@ static int udf_load_vat(struct super_bloreturn0;}+/*+*Loadpartitiondescriptorblock+*+*Returns<0onerror,0onsuccess,-EAGAINisspecial-trynextdescriptor+*sequence.+*/staticintudf_load_partdesc(structsuper_block*sb,sector_tblock){structbuffer_head*bh;
@@ -1204,13 +1217,15 @@ static int udf_load_partdesc(struct supeinti,type1_idx;uint16_tpartitionNumber;uint16_tident;-intret=0;+intret;bh=udf_read_tagged(sb,block,block,&ident);if(!bh)-return1;-if(ident!=TAG_IDENT_PD)+return-EAGAIN;+if(ident!=TAG_IDENT_PD){+ret=0;gotoout_bh;+}p=(structpartitionDesc*)bh->b_data;partitionNumber=le16_to_cpu(p->partitionNumber);
@@ -1229,10 +1244,13 @@ static int udf_load_partdesc(struct supeif(i>=sbi->s_partitions){udf_debug("Partition (%d) not found in partition map\n",partitionNumber);+ret=0;gotoout_bh;}ret=udf_fill_partdesc_info(sb,p,i);+if(ret<0)+gotoout_bh;/**NowrescanforVIRTUALorMETADATApartitionswhenSPARABLEand
@@ -1275,6 +1295,7 @@ static int udf_load_partdesc(struct supesb->s_flags|=MS_RDONLY;pr_notice("Filesystem marked read-only because writing to pseudooverwrite partition is not implemented\n");}+ret=0;out_bh:/* In case loading failed, we handle cleanup in udf_fill_super */brelse(bh);
@@ -1340,11 +1361,11 @@ static int udf_load_logicalvol(struct suuint16_tident;structbuffer_head*bh;unsignedinttable_len;-intret=0;+intret;bh=udf_read_tagged(sb,block,block,&ident);if(!bh)-return1;+return-EAGAIN;BUG_ON(ident!=TAG_IDENT_LVD);lvd=(structlogicalVolDesc*)bh->b_data;table_len=le32_to_cpu(lvd->mapTableLength);
@@ -1352,7 +1373,7 @@ static int udf_load_logicalvol(struct suudf_err(sb,"error loading logical volume descriptor: ""Partition table too long (%u > %lu)\n",table_len,sb->s_blocksize-sizeof(*lvd));-ret=1;+ret=-EIO;gotoout_bh;}
@@ -1396,11 +1417,10 @@ static int udf_load_logicalvol(struct su}elseif(!strncmp(upm2->partIdent.ident,UDF_ID_SPARABLE,strlen(UDF_ID_SPARABLE))){-if(udf_load_sparable_map(sb,map,-(structsparablePartitionMap*)gpm)<0){-ret=1;+ret=udf_load_sparable_map(sb,map,+(structsparablePartitionMap*)gpm);+if(ret<0)gotoout_bh;-}}elseif(!strncmp(upm2->partIdent.ident,UDF_ID_METADATA,strlen(UDF_ID_METADATA))){
@@ -1465,7 +1485,7 @@ static int udf_load_logicalvol(struct su}if(lvd->integritySeqExt.extLength)udf_load_logicalvolint(sb,leea_to_cpu(lvd->integritySeqExt));-+ret=0;out_bh:brelse(bh);returnret;
@@ -1529,6 +1545,7 @@ static noinline int udf_process_sequenceuint32_tvdsn;uint16_tident;longnext_s=0,next_e=0;+intret;memset(vds,0,sizeof(structudf_vds_record)*VDS_POS_LENGTH);
@@ -1543,7 +1560,7 @@ static noinline int udf_process_sequenceudf_err(sb,"Block %llu of volume descriptor sequence is corrupted or we could not read it\n",(unsignedlonglong)block);-return1;+return-EAGAIN;}/* Process each descriptor (ISO 13346 3/8.3-8.4) */
@@ -1616,14 +1633,19 @@ static noinline int udf_process_sequence*/if(!vds[VDS_POS_PRIMARY_VOL_DESC].block){udf_err(sb,"Primary Volume Descriptor not found!\n");-return1;+return-EAGAIN;+}+ret=udf_load_pvoldesc(sb,vds[VDS_POS_PRIMARY_VOL_DESC].block);+if(ret<0)+returnret;++if(vds[VDS_POS_LOGICAL_VOL_DESC].block){+ret=udf_load_logicalvol(sb,+vds[VDS_POS_LOGICAL_VOL_DESC].block,+fileset);+if(ret<0)+returnret;}-if(udf_load_pvoldesc(sb,vds[VDS_POS_PRIMARY_VOL_DESC].block))-return1;--if(vds[VDS_POS_LOGICAL_VOL_DESC].block&&udf_load_logicalvol(sb,-vds[VDS_POS_LOGICAL_VOL_DESC].block,fileset))-return1;if(vds[VDS_POS_PARTITION_DESC].block){/*
@@ -1632,19 +1654,27 @@ static noinline int udf_process_sequence*/for(block=vds[VDS_POS_PARTITION_DESC].block;block<vds[VDS_POS_TERMINATING_DESC].block;-block++)-if(udf_load_partdesc(sb,block))-return1;+block++){+ret=udf_load_partdesc(sb,block);+if(ret<0)+returnret;+}}return0;}+/*+*LoadVolumeDescriptorSequencedescribedbyanchorinbh+*+*Returns<0onerror,0onsuccess+*/staticintudf_load_sequence(structsuper_block*sb,structbuffer_head*bh,structkernel_lb_addr*fileset){structanchorVolDescPtr*anchor;-longmain_s,main_e,reserve_s,reserve_e;+sector_tmain_s,main_e,reserve_s,reserve_e;+intret;anchor=(structanchorVolDescPtr*)bh->b_data;
@@ -1662,18 +1692,26 @@ static int udf_load_sequence(struct supe/* Process the main & reserve sequences *//* responsible for finding the PartitionDesc(s) */-if(!udf_process_sequence(sb,main_s,main_e,fileset))-return1;+ret=udf_process_sequence(sb,main_s,main_e,fileset);+if(ret!=-EAGAIN)+returnret;udf_sb_free_partitions(sb);-if(!udf_process_sequence(sb,reserve_s,reserve_e,fileset))-return1;-udf_sb_free_partitions(sb);-return0;+ret=udf_process_sequence(sb,reserve_s,reserve_e,fileset);+if(ret<0){+udf_sb_free_partitions(sb);+/* No sequence was OK, return -EIO */+if(ret==-EAGAIN)+ret=-EIO;+}+returnret;}/**Checkwhetherthereisananchorblockinthegivenblockand*loadVolumeDescriptorSequenceifso.+*+*Returns<0onerror,0onsuccess,-EAGAINisspecial-trynextanchor+*block*/staticintudf_check_anchor_block(structsuper_block*sb,sector_tblock,structkernel_lb_addr*fileset)
@@ -1685,33 +1723,40 @@ static int udf_check_anchor_block(structif(UDF_QUERY_FLAG(sb,UDF_FLAG_VARCONV)&&udf_fixed_to_variable(block)>=sb->s_bdev->bd_inode->i_size>>sb->s_blocksize_bits)-return0;+return-EAGAIN;bh=udf_read_tagged(sb,block,block,&ident);if(!bh)-return0;+return-EAGAIN;if(ident!=TAG_IDENT_AVDP){brelse(bh);-return0;+return-EAGAIN;}ret=udf_load_sequence(sb,bh,fileset);brelse(bh);returnret;}-/* Search for an anchor volume descriptor pointer */-staticsector_tudf_scan_anchors(structsuper_block*sb,sector_tlastblock,-structkernel_lb_addr*fileset)+/*+*Searchforananchorvolumedescriptorpointer.+*+*Returns<0onerror,0onsuccess.-EAGAINisspecial-trynextset+*ofanchors.+*/+staticintudf_scan_anchors(structsuper_block*sb,sector_t*lastblock,+structkernel_lb_addr*fileset){sector_tlast[6];inti;structudf_sb_info*sbi=UDF_SB(sb);intlast_count=0;+intret;/* First try user provided anchor */if(sbi->s_anchor){-if(udf_check_anchor_block(sb,sbi->s_anchor,fileset))-returnlastblock;+ret=udf_check_anchor_block(sb,sbi->s_anchor,fileset);+if(ret!=-EAGAIN)+returnret;}/**accordingtospec,anchorisineither:
@@ -1720,39 +1765,46 @@ static sector_t udf_scan_anchors(struct*lastblock*however,ifthediscisn'tclosed,itcouldbe512.*/-if(udf_check_anchor_block(sb,sbi->s_session+256,fileset))-returnlastblock;+ret=udf_check_anchor_block(sb,sbi->s_session+256,fileset);+if(ret!=-EAGAIN)+returnret;/**Thetroubleiswhichblockisthelastone.Drivesoftenmisreport*thissowetryvariouspossibilities.*/-last[last_count++]=lastblock;-if(lastblock>=1)-last[last_count++]=lastblock-1;-last[last_count++]=lastblock+1;-if(lastblock>=2)-last[last_count++]=lastblock-2;-if(lastblock>=150)-last[last_count++]=lastblock-150;-if(lastblock>=152)-last[last_count++]=lastblock-152;+last[last_count++]=*lastblock;+if(*lastblock>=1)+last[last_count++]=*lastblock-1;+last[last_count++]=*lastblock+1;+if(*lastblock>=2)+last[last_count++]=*lastblock-2;+if(*lastblock>=150)+last[last_count++]=*lastblock-150;+if(*lastblock>=152)+last[last_count++]=*lastblock-152;for(i=0;i<last_count;i++){if(last[i]>=sb->s_bdev->bd_inode->i_size>>sb->s_blocksize_bits)continue;-if(udf_check_anchor_block(sb,last[i],fileset))-returnlast[i];+ret=udf_check_anchor_block(sb,last[i],fileset);+if(ret!=-EAGAIN){+if(!ret)+*lastblock=last[i];+returnret;+}if(last[i]<256)continue;-if(udf_check_anchor_block(sb,last[i]-256,fileset))-returnlast[i];+ret=udf_check_anchor_block(sb,last[i]-256,fileset);+if(ret!=-EAGAIN){+if(!ret)+*lastblock=last[i];+returnret;+}}/* Finally try block 512 in case media is open */-if(udf_check_anchor_block(sb,sbi->s_session+512,fileset))-returnlast[0];-return0;+returnudf_check_anchor_block(sb,sbi->s_session+512,fileset);}/*
@@ -1760,54 +1812,59 @@ static sector_t udf_scan_anchors(struct*areaspecifiedbyit.Thefunctionexpectssbi->s_lastblocktobethelast*blockonthemedia.*-*Return1ifok,0ifnotfound.-*+*Return<0onerror,0ifanchorfound.-EAGAINisspecialmeaninganchor+*wasnotfound.*/staticintudf_find_anchor(structsuper_block*sb,structkernel_lb_addr*fileset){-sector_tlastblock;structudf_sb_info*sbi=UDF_SB(sb);+sector_tlastblock=sbi->s_last_block;+intret;-lastblock=udf_scan_anchors(sb,sbi->s_last_block,fileset);-if(lastblock)+ret=udf_scan_anchors(sb,&lastblock,fileset);+if(ret!=-EAGAIN)gotoout;/* No anchor found? Try VARCONV conversion of block numbers */UDF_SET_FLAG(sb,UDF_FLAG_VARCONV);+lastblock=udf_variable_to_fixed(sbi->s_last_block);/* Firstly, we try to not convert number of the last block */-lastblock=udf_scan_anchors(sb,-udf_variable_to_fixed(sbi->s_last_block),-fileset);-if(lastblock)+ret=udf_scan_anchors(sb,&lastblock,fileset);+if(ret!=-EAGAIN)gotoout;+lastblock=sbi->s_last_block;/* Secondly, we try with converted number of the last block */-lastblock=udf_scan_anchors(sb,sbi->s_last_block,fileset);-if(!lastblock){+ret=udf_scan_anchors(sb,&lastblock,fileset);+if(ret<0){/* VARCONV didn't help. Clear it. */UDF_CLEAR_FLAG(sb,UDF_FLAG_VARCONV);-return0;}out:-sbi->s_last_block=lastblock;-return1;+if(ret==0)+sbi->s_last_block=lastblock;+returnret;}/**CheckVolumeStructureDescriptor,findAnchorblockandloadVolume-*DescriptorSequence+*DescriptorSequence.+*+*Returns<0onerror,0onsuccess.-EAGAINisspecialmeaninganchor+*blockwasnotfound.*/staticintudf_load_vrs(structsuper_block*sb,structudf_options*uopt,intsilent,structkernel_lb_addr*fileset){structudf_sb_info*sbi=UDF_SB(sb);loff_tnsr_off;+intret;if(!sb_set_blocksize(sb,uopt->blocksize)){if(!silent)udf_warn(sb,"Bad block size\n");-return0;+return-EINVAL;}sbi->s_last_block=uopt->lastblock;if(!uopt->novrs){
@@ -1828,12 +1885,13 @@ static int udf_load_vrs(struct super_blo/* Look for anchor block and load Volume Descriptor Sequence */sbi->s_anchor=uopt->anchor;-if(!udf_find_anchor(sb,fileset)){-if(!silent)+ret=udf_find_anchor(sb,fileset);+if(ret<0){+if(!silent&&ret==-EAGAIN)udf_warn(sb,"No anchor found\n");-return0;+returnret;}-return1;+return0;}staticvoidudf_open_lvid(structsuper_block*sb)
@@ -2011,7 +2069,7 @@ static int udf_fill_super(struct super_b}else{uopt.blocksize=bdev_logical_block_size(sb->s_bdev);ret=udf_load_vrs(sb,&uopt,silent,&fileset);-if(!ret&&uopt.blocksize!=UDF_DEFAULT_BLOCKSIZE){+if(ret==-EAGAIN&&uopt.blocksize!=UDF_DEFAULT_BLOCKSIZE){if(!silent)pr_notice("Rescanning with blocksize %d\n",UDF_DEFAULT_BLOCKSIZE);
@@ -2021,8 +2079,11 @@ static int udf_fill_super(struct super_bret=udf_load_vrs(sb,&uopt,silent,&fileset);}}-if(!ret){-udf_warn(sb,"No partition found (1)\n");+if(ret<0){+if(ret==-EAGAIN){+udf_warn(sb,"No partition found (1)\n");+ret=-EINVAL;+}gotoerror_out;}
@@ -2040,6 +2101,7 @@ static int udf_fill_super(struct super_budf_err(sb,"minUDFReadRev=%x (max is %x)\n",le16_to_cpu(lvidiu->minUDFReadRev),UDF_MAX_READ_VERSION);+ret=-EINVAL;gotoerror_out;}elseif(minUDFWriteRev>UDF_MAX_WRITE_VERSION)sb->s_flags|=MS_RDONLY;
@@ -2054,6 +2116,7 @@ static int udf_fill_super(struct super_bif(!sbi->s_partitions){udf_warn(sb,"No partition found (2)\n");+ret=-EINVAL;gotoerror_out;}
@@ -2065,6 +2128,7 @@ static int udf_fill_super(struct super_bif(udf_find_fileset(sb,&fileset,&rootdir)){udf_warn(sb,"No fileset found\n");+ret=-EINVAL;gotoerror_out;}
@@ -2086,6 +2150,7 @@ static int udf_fill_super(struct super_bif(!inode){udf_err(sb,"Error in udf_iget, block=%d, partition=%d\n",rootdir.logicalBlockNum,rootdir.partitionReferenceNum);+ret=-EIO;gotoerror_out;}
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian König <christian.koenig@amd.com>
commit 4f66c59922cbcda14c9e103e6c7f4ee616360d43 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_cs.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
@@ -80,9 +80,11 @@ static int radeon_cs_parser_relocs(strucp->relocs[i].lobj.bo=p->relocs[i].robj;p->relocs[i].lobj.written=!!r->write_domain;-/* the first reloc of an UVD job is the-msgandthatmustbeinVRAM*/-if(p->ring==R600_RING_TYPE_UVD_INDEX&&i==0){+/* the first reloc of an UVD job is the msg and that must be in+VRAM,alsobuteverythingintoVRAMonAGPcardstoavoid+imagecorruptions*/+if(p->ring==R600_RING_TYPE_UVD_INDEX&&+(i==0||p->rdev->flags&RADEON_IS_AGP)){/* TODO: is this still needed for NI+ ? */p->relocs[i].lobj.domain=RADEON_GEM_DOMAIN_VRAM;
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/ppsmc.h | 2 ++
drivers/gpu/drm/radeon/trinity_dpm.c | 2 ++
drivers/gpu/drm/radeon/trinity_dpm.h | 1 +
drivers/gpu/drm/radeon/trinity_smc.c | 8 ++++++++
4 files changed, 13 insertions(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_connectors.c | 34 ++++++++++++++++++++++++++---
1 file changed, 31 insertions(+), 3 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/rs780_dpm.c | 3 +++
1 file changed, 3 insertions(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/rs780_dpm.c | 10 +++++++---
drivers/gpu/drm/radeon/rv770_dpm.c | 10 +++++++---
2 files changed, 14 insertions(+), 6 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_atombios.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/r600.c | 5 +++++
drivers/gpu/drm/radeon/radeon_asic.c | 2 ++
drivers/gpu/drm/radeon/radeon_asic.h | 1 +
3 files changed, 8 insertions(+)
@@ -119,6 +119,11 @@ u32 r600_get_xclk(struct radeon_device *returnrdev->clock.spll.reference_freq;}+intr600_set_uvd_clocks(structradeon_device*rdev,u32vclk,u32dclk)+{+return0;+}+/* get temperature in millidegrees */intrv6xx_get_temp(structradeon_device*rdev){---a/drivers/gpu/drm/radeon/radeon_asic.c+++b/drivers/gpu/drm/radeon/radeon_asic.c
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nithin Sujir <redacted>
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 <redacted>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 1 +
1 file changed, 1 insertion(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nithin Sujir <redacted>
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 <redacted>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
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 [off-list ref]
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/si.c | 23 +++++++++++++++++++----
drivers/gpu/drm/radeon/sid.h | 4 ++++
2 files changed, 23 insertions(+), 4 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tom Stellard <redacted>
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 <redacted>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_kms.c | 3 +
drivers/gpu/drm/radeon/si.c | 106 ++++++++++++++++++++----------------
include/uapi/drm/radeon_drm.h | 2
3 files changed, 66 insertions(+), 45 deletions(-)
@@ -433,6 +433,9 @@ int radeon_info_ioctl(struct drm_devicereturn-EINVAL;}break;+caseRADEON_INFO_SI_CP_DMA_COMPUTE:+*value=1;+break;default:DRM_DEBUG_KMS("Invalid request %d\n",info->request);return-EINVAL;---a/drivers/gpu/drm/radeon/si.c+++b/drivers/gpu/drm/radeon/si.c
@@ -4083,13 +4083,64 @@ static int si_vm_packet3_ce_check(structreturn0;}+staticintsi_vm_packet3_cp_dma_check(u32*ib,u32idx)+{+u32start_reg,reg,i;+u32command=ib[idx+4];+u32info=ib[idx+1];+u32idx_value=ib[idx];+if(command&PACKET3_CP_DMA_CMD_SAS){+/* src address space is register */+if(((info&0x60000000)>>29)==0){+start_reg=idx_value<<2;+if(command&PACKET3_CP_DMA_CMD_SAIC){+reg=start_reg;+if(!si_vm_reg_valid(reg)){+DRM_ERROR("CP DMA Bad SRC register\n");+return-EINVAL;+}+}else{+for(i=0;i<(command&0x1fffff);i++){+reg=start_reg+(4*i);+if(!si_vm_reg_valid(reg)){+DRM_ERROR("CP DMA Bad SRC register\n");+return-EINVAL;+}+}+}+}+}+if(command&PACKET3_CP_DMA_CMD_DAS){+/* dst address space is register */+if(((info&0x00300000)>>20)==0){+start_reg=ib[idx+2];+if(command&PACKET3_CP_DMA_CMD_DAIC){+reg=start_reg;+if(!si_vm_reg_valid(reg)){+DRM_ERROR("CP DMA Bad DST register\n");+return-EINVAL;+}+}else{+for(i=0;i<(command&0x1fffff);i++){+reg=start_reg+(4*i);+if(!si_vm_reg_valid(reg)){+DRM_ERROR("CP DMA Bad DST register\n");+return-EINVAL;+}+}+}+}+}+return0;+}+staticintsi_vm_packet3_gfx_check(structradeon_device*rdev,u32*ib,structradeon_cs_packet*pkt){+intr;u32idx=pkt->idx+1;u32idx_value=ib[idx];u32start_reg,end_reg,reg,i;-u32command,info;switch(pkt->opcode){casePACKET3_NOP:
@@ -4190,50 +4241,9 @@ static int si_vm_packet3_gfx_check(struc}break;casePACKET3_CP_DMA:-command=ib[idx+4];-info=ib[idx+1];-if(command&PACKET3_CP_DMA_CMD_SAS){-/* src address space is register */-if(((info&0x60000000)>>29)==0){-start_reg=idx_value<<2;-if(command&PACKET3_CP_DMA_CMD_SAIC){-reg=start_reg;-if(!si_vm_reg_valid(reg)){-DRM_ERROR("CP DMA Bad SRC register\n");-return-EINVAL;-}-}else{-for(i=0;i<(command&0x1fffff);i++){-reg=start_reg+(4*i);-if(!si_vm_reg_valid(reg)){-DRM_ERROR("CP DMA Bad SRC register\n");-return-EINVAL;-}-}-}-}-}-if(command&PACKET3_CP_DMA_CMD_DAS){-/* dst address space is register */-if(((info&0x00300000)>>20)==0){-start_reg=ib[idx+2];-if(command&PACKET3_CP_DMA_CMD_DAIC){-reg=start_reg;-if(!si_vm_reg_valid(reg)){-DRM_ERROR("CP DMA Bad DST register\n");-return-EINVAL;-}-}else{-for(i=0;i<(command&0x1fffff);i++){-reg=start_reg+(4*i);-if(!si_vm_reg_valid(reg)){-DRM_ERROR("CP DMA Bad DST register\n");-return-EINVAL;-}-}-}-}-}+r=si_vm_packet3_cp_dma_check(ib,idx);+if(r)+returnr;break;default:DRM_ERROR("Invalid GFX packet3: 0x%x\n",pkt->opcode);
@@ -4245,6 +4255,7 @@ static int si_vm_packet3_gfx_check(strucstaticintsi_vm_packet3_compute_check(structradeon_device*rdev,u32*ib,structradeon_cs_packet*pkt){+intr;u32idx=pkt->idx+1;u32idx_value=ib[idx];u32start_reg,reg,i;
@@ -4317,6 +4328,11 @@ static int si_vm_packet3_compute_check(sreturn-EINVAL;}break;+casePACKET3_CP_DMA:+r=si_vm_packet3_cp_dma_check(ib,idx);+if(r)+returnr;+break;default:DRM_ERROR("Invalid Compute packet3: 0x%x\n",pkt->opcode);return-EINVAL;---a/include/uapi/drm/radeon_drm.h+++b/include/uapi/drm/radeon_drm.h
@@ -979,6 +979,8 @@ struct drm_radeon_cs {#define RADEON_INFO_RING_WORKING 0x15/* SI tile mode array */#define RADEON_INFO_SI_TILE_MODE_ARRAY 0x16+/* query if CP DMA is supported on the compute ring */+#define RADEON_INFO_SI_CP_DMA_COMPUTE 0x17structdrm_radeon_info{
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <redacted>
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 <redacted>
Signed-off-by: Stanislaw Gruszka <redacted>
Cc: stable@vger.kernel.org
Cc: Frederic Weisbecker <redacted>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul E. McKenney <redacted>
Cc: Borislav Petkov <bp@alien8.de>
Link: http://lkml.kernel.org/r/20130904131602.GC2564@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/cputime.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <redacted>
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: [<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 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 <redacted>
Tested-by: Lin Ming <redacted>
Signed-off-by: John Stultz <redacted>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: http://lkml.kernel.org/r/1378943457-27314-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/timex.h | 1 +
kernel/time/ntp.c | 6 ++----
kernel/time/timekeeping.c | 2 ++
3 files changed, 5 insertions(+), 4 deletions(-)
@@ -141,6 +141,7 @@ extern int do_adjtimex(struct timex *);externvoidhardpps(conststructtimespec*,conststructtimespec*);intread_current_timer(unsignedlong*timer_val);+voidntp_notify_cmos_timer(void);/* The clock frequency of the i8253/i8254 PIT */#define PIT_TICK_RATE 1193182ul---a/kernel/time/ntp.c+++b/kernel/time/ntp.c
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafał Miłecki <zajec5@gmail.com>
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 <zajec5@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bgmac.c | 2 +-
drivers/net/ethernet/broadcom/bgmac.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <redacted>
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 <redacted>
Cc: Steve French <sfrench@samba.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/dir.c | 1 +
1 file changed, 1 insertion(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <tony@atomide.com>
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 <redacted>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-omap2/cclock44xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Airlie <airlied@redhat.com>
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 <redacted>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/ast/ast_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ville Syrjälä <redacted>
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ä <redacted>
Tested-by: Paulo Zanoni <redacted>
Reviewed-by: Paulo Zanoni <redacted>
Signed-off-by: Daniel Vetter <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_display.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <redacted>
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 [off-list ref]
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 [off-list ref]
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 <redacted>
Cc: Stuart Abercrombie <redacted>
Reported-by: Stuart Abercrombie <redacted>
References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/26239
Reviewed-by: Chris Wilson <redacted>
[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 <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++++++
drivers/gpu/drm/i915/i915_irq.c | 9 +++++++--
2 files changed, 14 insertions(+), 2 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <redacted>
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 <redacted>
Signed-off-by: Jani Nikula <redacted>
Reviewed-by: Aaron Lu <redacted>
Signed-off-by: Daniel Vetter <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_opregion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <redacted>
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: [<ffffffff815d50aa>] logi_dj_recv_send_report.isra.11+0x1a/0x90
CVE-2013-2895
Signed-off-by: Kees Cook <redacted>
Signed-off-by: Benjamin Tissoires <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-logitech-dj.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
@@ -461,7 +461,7 @@ static int logi_dj_recv_send_report(strustructhid_report*report;structhid_report_enum*output_report_enum;u8*data=(u8*)(&dj_report->device_index);-inti;+unsignedinti;output_report_enum=&hdev->report_enum[HID_OUTPUT_REPORT];report=output_report_enum->report_id_hash[REPORT_ID_DJ_SHORT];
@@ -471,7 +471,7 @@ static int logi_dj_recv_send_report(strureturn-ENODEV;}-for(i=0;i<report->field[0]->report_count;i++)+for(i=0;i<DJREPORT_SHORT_LENGTH-1;i++)report->field[0]->value[i]=data[i];hid_hw_request(hdev,report,HID_REQ_SET_REPORT);
@@ -783,6 +783,12 @@ static int logi_dj_probe(struct hid_devigotohid_parse_fail;}+if(!hid_validate_values(hdev,HID_OUTPUT_REPORT,REPORT_ID_DJ_SHORT,+0,DJREPORT_SHORT_LENGTH-1)){+retval=-ENODEV;+gotohid_parse_fail;+}+/* Starts the usb device and connects to upper interfaces hiddev and*hidraw*/retval=hid_hw_start(hdev,HID_CONNECT_DEFAULT);
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <redacted>
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 <david.e.box@intel.com>
Signed-off-by: Rafael J. Wysocki <redacted>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/pci-acpi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <redacted>
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 <redacted>
Reviewed-by: Benjamin Tissoires <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-sony.c | 4 ++++
1 file changed, 4 insertions(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <redacted>
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 <redacted>
Reviewed-by: Benjamin Tissoires <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-steelseries.c | 5 +++++
1 file changed, 5 insertions(+)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Tissoires <redacted>
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 <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-lenovo-tpkbd.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <redacted>
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 <redacted>
Reviewed-by: Benjamin Tissoires <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-zpff.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <redacted>
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 <redacted>
Reviewed-by: Benjamin Tissoires <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-lg2ff.c | 19 +++----------------
drivers/hid/hid-lg3ff.c | 29 ++++++-----------------------
drivers/hid/hid-lg4ff.c | 20 +-------------------
drivers/hid/hid-lgff.c | 17 ++---------------
4 files changed, 12 insertions(+), 73 deletions(-)
@@ -64,26 +64,13 @@ int lg2ff_init(struct hid_device *hid)structhid_report*report;structhid_input*hidinput=list_entry(hid->inputs.next,structhid_input,list);-structlist_head*report_list=-&hid->report_enum[HID_OUTPUT_REPORT].report_list;structinput_dev*dev=hidinput->input;interror;-if(list_empty(report_list)){-hid_err(hid,"no output report found\n");+/* Check that the report looks ok */+report=hid_validate_values(hid,HID_OUTPUT_REPORT,0,0,7);+if(!report)return-ENODEV;-}--report=list_entry(report_list->next,structhid_report,list);--if(report->maxfield<1){-hid_err(hid,"output report is empty\n");-return-ENODEV;-}-if(report->field[0]->report_count<7){-hid_err(hid,"not enough values in the field\n");-return-ENODEV;-}lg2ff=kmalloc(sizeof(structlg2ff_device),GFP_KERNEL);if(!lg2ff)---a/drivers/hid/hid-lg3ff.c+++b/drivers/hid/hid-lg3ff.c
@@ -66,10 +66,11 @@ static int hid_lg3ff_play(struct input_dintx,y;/*-*Maxusageshouldalwaysbe63(maximumfields)-*likelyabetterwaytoensurethisdataisclean+*Availablevaluesinthefieldshouldalwaysbe63,butweonlyuseupto+*35.Instead,cleartheentirearea,howeverbigitis.*/-memset(report->field[0]->value,0,sizeof(__s32)*report->field[0]->maxusage);+memset(report->field[0]->value,0,+sizeof(__s32)*report->field[0]->report_count);switch(effect->type){caseFF_CONSTANT:
@@ -129,32 +130,14 @@ static const signed short ff3_joystick_aintlg3ff_init(structhid_device*hid){structhid_input*hidinput=list_entry(hid->inputs.next,structhid_input,list);-structlist_head*report_list=&hid->report_enum[HID_OUTPUT_REPORT].report_list;structinput_dev*dev=hidinput->input;-structhid_report*report;-structhid_field*field;constsignedshort*ff_bits=ff3_joystick_ac;interror;inti;-/* Find the report to use */-if(list_empty(report_list)){-hid_err(hid,"No output report found\n");-return-1;-}-/* Check that the report looks ok */-report=list_entry(report_list->next,structhid_report,list);-if(!report){-hid_err(hid,"NULL output report\n");-return-1;-}--field=report->field[0];-if(!field){-hid_err(hid,"NULL field\n");-return-1;-}+if(!hid_validate_values(hid,HID_OUTPUT_REPORT,0,0,35))+return-ENODEV;/* Assume single fixed device G940 */for(i=0;ff_bits[i]>=0;i++)---a/drivers/hid/hid-lg4ff.c+++b/drivers/hid/hid-lg4ff.c
@@ -484,34 +484,16 @@ static enum led_brightness lg4ff_led_getintlg4ff_init(structhid_device*hid){structhid_input*hidinput=list_entry(hid->inputs.next,structhid_input,list);-structlist_head*report_list=&hid->report_enum[HID_OUTPUT_REPORT].report_list;structinput_dev*dev=hidinput->input;-structhid_report*report;-structhid_field*field;structlg4ff_device_entry*entry;structlg_drv_data*drv_data;structusb_device_descriptor*udesc;interror,i,j;__u16bcdDevice,rev_maj,rev_min;-/* Find the report to use */-if(list_empty(report_list)){-hid_err(hid,"No output report found\n");-return-1;-}-/* Check that the report looks ok */-report=list_entry(report_list->next,structhid_report,list);-if(!report){-hid_err(hid,"NULL output report\n");-return-1;-}--field=report->field[0];-if(!field){-hid_err(hid,"NULL field\n");+if(!hid_validate_values(hid,HID_OUTPUT_REPORT,0,0,7))return-1;-}/* Check what wheel has been connected */for(i=0;i<ARRAY_SIZE(lg4ff_devices);i++){---a/drivers/hid/hid-lgff.c+++b/drivers/hid/hid-lgff.c
@@ -128,27 +128,14 @@ static void hid_lgff_set_autocenter(struintlgff_init(structhid_device*hid){structhid_input*hidinput=list_entry(hid->inputs.next,structhid_input,list);-structlist_head*report_list=&hid->report_enum[HID_OUTPUT_REPORT].report_list;structinput_dev*dev=hidinput->input;-structhid_report*report;-structhid_field*field;constsignedshort*ff_bits=ff_joystick;interror;inti;-/* Find the report to use */-if(list_empty(report_list)){-hid_err(hid,"No output report found\n");-return-1;-}-/* Check that the report looks ok */-report=list_entry(report_list->next,structhid_report,list);-field=report->field[0];-if(!field){-hid_err(hid,"NULL field\n");-return-1;-}+if(!hid_validate_values(hid,HID_OUTPUT_REPORT,0,0,7))+return-ENODEV;for(i=0;i<ARRAY_SIZE(devices);i++){if(dev->id.vendor==devices[i].idVendor&&
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Tissoires <redacted>
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 <redacted>
Acked-by: Kees Cook <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-multitouch.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
@@ -101,9 +101,9 @@ struct mt_device {unsignedlast_slot_field;/* the last field of a slot */unsignedmt_report_id;/* the report ID of the multitouch device */unsignedpen_report_id;/* the report ID of the pen device */-__s8inputmode;/* InputMode HID feature, -1 if non-existent */-__s8inputmode_index;/* InputMode HID feature index in the report */-__s8maxcontact_report_id;/* Maximum Contact Number HID feature,+__s16inputmode;/* InputMode HID feature, -1 if non-existent */+__s16inputmode_index;/* InputMode HID feature index in the report */+__s16maxcontact_report_id;/* Maximum Contact Number HID feature,-1ifnon-existent*/__u8num_received;/* how many contacts we received */__u8num_expected;/* expected last contact index */
@@ -317,20 +317,18 @@ static void mt_feature_mapping(struct histructhid_field*field,structhid_usage*usage){structmt_device*td=hid_get_drvdata(hdev);-inti;switch(usage->hid){caseHID_DG_INPUTMODE:-td->inputmode=field->report->id;-td->inputmode_index=0;/* has to be updated below */--for(i=0;i<field->maxusage;i++){-if(field->usage[i].hid==usage->hid){-td->inputmode_index=i;-break;-}+/* Ignore if value index is out of bounds. */+if(usage->usage_index>=field->report_count){+dev_err(&hdev->dev,"HID_DG_INPUTMODE out of range\n");+break;}+td->inputmode=field->report->id;+td->inputmode_index=usage->usage_index;+break;caseHID_DG_CONTACTMAX:td->maxcontact_report_id=field->report->id;
@@ -536,6 +534,10 @@ static int mt_touch_input_mapping(structmt_store_field(usage,td,hi);return1;caseHID_DG_CONTACTCOUNT:+/* Ignore if indexes are out of bounds. */+if(field->index>=field->report->maxfield||+usage->usage_index>=field->report_count)+return1;td->cc_index=field->index;td->cc_value_index=usage->usage_index;return1;
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <redacted>
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 <redacted>
Reviewed-by: Benjamin Tissoires <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/hid.h | 4 +++
2 files changed, 62 insertions(+)
@@ -759,6 +759,64 @@ int hid_parse_report(struct hid_device *}EXPORT_SYMBOL_GPL(hid_parse_report);+staticconstchar*consthid_report_names[]={+"HID_INPUT_REPORT",+"HID_OUTPUT_REPORT",+"HID_FEATURE_REPORT",+};+/**+*hid_validate_values-validateexistingdevicereport'svalueindexes+*+*@device:hiddevice+*@type:whichreporttypetoexamine+*@id:whichreportIDtoexamine(0forfirst)+*@field_index:whichreportfieldtoexamine+*@report_counts:expectednumberofvalues+*+*Validatethenumberofvaluesinagivenfieldofagivenreport,after+*parsing.+*/+structhid_report*hid_validate_values(structhid_device*hid,+unsignedinttype,unsignedintid,+unsignedintfield_index,+unsignedintreport_counts)+{+structhid_report*report;++if(type>HID_FEATURE_REPORT){+hid_err(hid,"invalid HID report type %u\n",type);+returnNULL;+}++if(id>=HID_MAX_IDS){+hid_err(hid,"invalid HID report id %u\n",id);+returnNULL;+}++/*+*Explicitlynotusinghid_get_report()heresinceitdependson+*->numberedbeingchecked,whichmaynotalwaysbethecasewhen+*driversgotoaccessreportvalues.+*/+report=hid->report_enum[type].report_id_hash[id];+if(!report){+hid_err(hid,"missing %s %u\n",hid_report_names[type],id);+returnNULL;+}+if(report->maxfield<=field_index){+hid_err(hid,"not enough fields in %s %u\n",+hid_report_names[type],id);+returnNULL;+}+if(report->field[field_index]->report_count<report_counts){+hid_err(hid,"not enough values in %s %u field %u\n",+hid_report_names[type],id,field_index);+returnNULL;+}+returnreport;+}+EXPORT_SYMBOL_GPL(hid_validate_values);+/***hid_open_report-openadriver-specificdevicereport*---a/include/linux/hid.h+++b/include/linux/hid.h
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daisuke Nishimura <redacted>
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: [<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 <redacted>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/039601ceae06$733d3130$59b79390$@mxp.nes.nec.co.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/fair.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
This is the start of the stable review cycle for the 3.11.3 release.
There are 71 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Tue Oct 1 19:26:27 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.3-rc1.gz
and the diffstat can be found below.
Build test results:
total: 110 pass: 108 skipped: 2 fail: 0
Same as with 3.11.2.
qemu:
arm, microblaze, mips, mips64, ppc, sparc, sparc64, x86, x86_64 pass.
sh passed with warning (same as with 3.11.2).
Guenter
On Sun, Sep 29, 2013 at 06:28:51PM -0700, Guenter Roeck wrote:
On 09/29/2013 12:27 PM, Greg Kroah-Hartman wrote:
quoted
This is the start of the stable review cycle for the 3.11.3 release.
There are 71 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Tue Oct 1 19:26:27 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.3-rc1.gz
and the diffstat can be found below.
Build test results:
total: 110 pass: 108 skipped: 2 fail: 0
Same as with 3.11.2.
Thanks for testing. Any chance we can ever get those two skipped ones
fixed. It feels odd that 3.10 passes those and 3.11 doesn't
thanks,
greg k-h
On Sun, Sep 29, 2013 at 06:28:51PM -0700, Guenter Roeck wrote:
quoted
On 09/29/2013 12:27 PM, Greg Kroah-Hartman wrote:
quoted
This is the start of the stable review cycle for the 3.11.3 release.
There are 71 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Tue Oct 1 19:26:27 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.3-rc1.gz
and the diffstat can be found below.
Build test results:
total: 110 pass: 108 skipped: 2 fail: 0
Same as with 3.11.2.
Thanks for testing. Any chance we can ever get those two skipped ones
fixed. It feels odd that 3.10 passes those and 3.11 doesn't
Maybe I should just not report those. "Skipped" means that the configuration
no longer exists (or that it does not yet exist).
Guenter