<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/gpu/drm, branch v3.2.68</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>drm/i915: Only fence tiled region of object.</title>
<updated>2015-02-20T00:49:39+00:00</updated>
<author>
<name>Bob Paauwe</name>
<email>bob.j.paauwe@intel.com</email>
</author>
<published>2014-12-18T17:51:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=875cf1b62db4f0cfe8c082c78f8f0bb7bb71bc9b'/>
<id>875cf1b62db4f0cfe8c082c78f8f0bb7bb71bc9b</id>
<content type='text'>
commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.

When creating a fence for a tiled object, only fence the area that
makes up the actual tiles.  The object may be larger than the tiled
area and if we allow those extra addresses to be fenced, they'll
get converted to addresses beyond where the object is mapped. This
opens up the possiblity of writes beyond the end of object.

To prevent this, we adjust the size of the fence to only encompass
the area that makes up the actual tiles.  The extra space is considered
un-tiled and now behaves as if it was a linear object.

Testcase: igt/gem_tiled_fence_overflow
Reported-by: Dan Hettena &lt;danh@ghs.com&gt;
Signed-off-by: Bob Paauwe &lt;bob.j.paauwe@intel.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
[bwh: Backported to 3.2:
 - Adjust context, indentation
 - Apply to both i965_write_fence_reg() and sandybridge_write_fence_reg(),
   which have been combined into one function upstream]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.

When creating a fence for a tiled object, only fence the area that
makes up the actual tiles.  The object may be larger than the tiled
area and if we allow those extra addresses to be fenced, they'll
get converted to addresses beyond where the object is mapped. This
opens up the possiblity of writes beyond the end of object.

To prevent this, we adjust the size of the fence to only encompass
the area that makes up the actual tiles.  The extra space is considered
un-tiled and now behaves as if it was a linear object.

Testcase: igt/gem_tiled_fence_overflow
Reported-by: Dan Hettena &lt;danh@ghs.com&gt;
Signed-off-by: Bob Paauwe &lt;bob.j.paauwe@intel.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
[bwh: Backported to 3.2:
 - Adjust context, indentation
 - Apply to both i965_write_fence_reg() and sandybridge_write_fence_reg(),
   which have been combined into one function upstream]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Don't use memory accounting for kernel-side fence objects</title>
<updated>2015-02-20T00:49:29+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2014-12-02T11:32:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=dff2114565cb20a491ae34b5ac6a83402c3151bd'/>
<id>dff2114565cb20a491ae34b5ac6a83402c3151bd</id>
<content type='text'>
commit 1f563a6a46544602183e7493b6ef69769d3d76d9 upstream.

Kernel side fence objects are used when unbinding resources and may thus be
created as part of a memory reclaim operation. This might trigger recursive
memory reclaims and result in the kernel running out of stack space.

So a simple way out is to avoid accounting of these fence objects.
In principle this is OK since while user-space can trigger the creation of
such objects, it can't really hold on to them. However, their lifetime is
quite long, so some form of accounting should perhaps be implemented in the
future.

Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3
with low system memory settings.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1f563a6a46544602183e7493b6ef69769d3d76d9 upstream.

Kernel side fence objects are used when unbinding resources and may thus be
created as part of a memory reclaim operation. This might trigger recursive
memory reclaims and result in the kernel running out of stack space.

So a simple way out is to avoid accounting of these fence objects.
In principle this is OK since while user-space can trigger the creation of
such objects, it can't really hold on to them. However, their lifetime is
quite long, so some form of accounting should perhaps be implemented in the
future.

Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3
with low system memory settings.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm: fix DRM_IOCTL_MODE_GETFB handle-leak</title>
<updated>2015-01-01T01:27:51+00:00</updated>
<author>
<name>David Herrmann</name>
<email>dh.herrmann@gmail.com</email>
</author>
<published>2013-08-26T13:16:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=125f21f38d448ae04aae1a665147faf1263a4736'/>
<id>125f21f38d448ae04aae1a665147faf1263a4736</id>
<content type='text'>
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 &lt;mandeep.baines@gmail.com&gt;
  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 &lt;dh.herrmann@gmail.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
[bwh: Backported to 3.2:
 - drm_framebuffer_funcs::create_handle must be non-null
 - Adjust context, indentation]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;mandeep.baines@gmail.com&gt;
  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 &lt;dh.herrmann@gmail.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
[bwh: Backported to 3.2:
 - drm_framebuffer_funcs::create_handle must be non-null
 - Adjust context, indentation]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: Unlock panel even when LVDS is disabled</title>
<updated>2015-01-01T01:27:48+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2014-12-01T16:56:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bce47648977d3c846f3ade30ddd78af67f80308f'/>
<id>bce47648977d3c846f3ade30ddd78af67f80308f</id>
<content type='text'>
commit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream.

Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced in

commit c31407a3672aaebb4acddf90944a114fa5c8af7b
Author: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Date:   Thu Oct 18 21:07:01 2012 +0100

    drm/i915: Add no-lvds quirk for Supermicro X7SPA-H

Reported-by: Alexey Orishko &lt;alexey.orishko@gmail.com&gt;
Cc: Alexey Orishko &lt;alexey.orishko@gmail.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Francois Tigeot &lt;ftigeot@wolfpond.org&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Tested-by: Alexey Orishko &lt;alexey.orishko@gmail.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
[bwh: Backported to 3.2: adjust context; comment was duplicated]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream.

Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced in

commit c31407a3672aaebb4acddf90944a114fa5c8af7b
Author: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Date:   Thu Oct 18 21:07:01 2012 +0100

    drm/i915: Add no-lvds quirk for Supermicro X7SPA-H

Reported-by: Alexey Orishko &lt;alexey.orishko@gmail.com&gt;
Cc: Alexey Orishko &lt;alexey.orishko@gmail.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Francois Tigeot &lt;ftigeot@wolfpond.org&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Tested-by: Alexey Orishko &lt;alexey.orishko@gmail.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
[bwh: Backported to 3.2: adjust context; comment was duplicated]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Filter out modes those cannot be supported by the current VRAM size.</title>
<updated>2014-12-14T16:23:54+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2014-10-31T08:58:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a8f42325dfed2c10410816a48032a75984078883'/>
<id>a8f42325dfed2c10410816a48032a75984078883</id>
<content type='text'>
commit 9a72384d86b26cb8a2b25106677e1197f606668f upstream.

When screen objects are enabled, the bpp is assumed to be 32, otherwise
it is set to 16.

v2:
* Use u32 instead of u64 for assumed_bpp.
* Fixed mechanism to check for screen objects
* Limit the back buffer size to VRAM.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
[bwh: Backported to 3.2: drop changes for dev_priv-&gt;prim_bb_mem]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9a72384d86b26cb8a2b25106677e1197f606668f upstream.

When screen objects are enabled, the bpp is assumed to be 32, otherwise
it is set to 16.

v2:
* Use u32 instead of u64 for assumed_bpp.
* Fixed mechanism to check for screen objects
* Limit the back buffer size to VRAM.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
[bwh: Backported to 3.2: drop changes for dev_priv-&gt;prim_bb_mem]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: add connector quirk for fujitsu board</title>
<updated>2014-11-05T20:27:41+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2014-09-08T17:55:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=dfc9c24ea8413089d41d0dbbaa93b434dbbec0ad'/>
<id>dfc9c24ea8413089d41d0dbbaa93b434dbbec0ad</id>
<content type='text'>
commit 1952f24d0fa6292d65f886887af87ba8ac79b3ba upstream.

Vbios connector table lists non-existent VGA port.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=83184

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1952f24d0fa6292d65f886887af87ba8ac79b3ba upstream.

Vbios connector table lists non-existent VGA port.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=83184

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle</title>
<updated>2014-11-05T20:27:40+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2014-08-28T09:53:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c81ddee59127ad2900e623d8fe5e839c48e1a027'/>
<id>c81ddee59127ad2900e623d8fe5e839c48e1a027</id>
<content type='text'>
commit f01ea0c3d9db536c64d47922716d8b3b8f21d850 upstream.

The code waiting for fifo idle was incorrect and could possibly spin
forever under certain circumstances.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reported-by: Mark Sheldon &lt;markshel@vmware.com&gt;
Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Reivewed-by: Mark Sheldon &lt;markshel@vmware.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f01ea0c3d9db536c64d47922716d8b3b8f21d850 upstream.

The code waiting for fifo idle was incorrect and could possibly spin
forever under certain circumstances.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reported-by: Mark Sheldon &lt;markshel@vmware.com&gt;
Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Reivewed-by: Mark Sheldon &lt;markshel@vmware.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: Remove bogus __init annotation from DMI callbacks</title>
<updated>2014-11-05T20:27:39+00:00</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@googlemail.com</email>
</author>
<published>2014-08-27T16:41:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=323d7ad8b6e79ac5fd43a897e6197fe018d4cd79'/>
<id>323d7ad8b6e79ac5fd43a897e6197fe018d4cd79</id>
<content type='text'>
commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a upstream.

The __init annotations for the DMI callback functions are wrong as this
code can be called even after the module has been initialized, e.g. like
this:

  # echo 1 &gt; /sys/bus/pci/devices/0000:00:02.0/remove
  # modprobe i915
  # echo 1 &gt; /sys/bus/pci/rescan

The first command will remove the PCI device from the kernel's device
list so the second command won't see it right away. But as it registers
a PCI driver it'll see it on the third command. If the system happens to
match one of the DMI table entries we'll try to call a function in long
released memory and generate an Oops, at best.

Fix this by removing the bogus annotation.

Modpost should have caught that one but it ignores section reference
mismatches from the .rodata section. :/

Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT")
Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...")
Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...")
Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Duncan Laurie &lt;dlaurie@chromium.org&gt;
Cc: Jarod Wilson &lt;jarod@redhat.com&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;	# Can modpost be fixed?
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
[bwh: Backported to 3.2: drop inapplicable change in intel_crt.c]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a upstream.

The __init annotations for the DMI callback functions are wrong as this
code can be called even after the module has been initialized, e.g. like
this:

  # echo 1 &gt; /sys/bus/pci/devices/0000:00:02.0/remove
  # modprobe i915
  # echo 1 &gt; /sys/bus/pci/rescan

The first command will remove the PCI device from the kernel's device
list so the second command won't see it right away. But as it registers
a PCI driver it'll see it on the third command. If the system happens to
match one of the DMI table entries we'll try to call a function in long
released memory and generate an Oops, at best.

Fix this by removing the bogus annotation.

Modpost should have caught that one but it ignores section reference
mismatches from the .rodata section. :/

Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT")
Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...")
Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...")
Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Duncan Laurie &lt;dlaurie@chromium.org&gt;
Cc: Jarod Wilson &lt;jarod@redhat.com&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;	# Can modpost be fixed?
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
[bwh: Backported to 3.2: drop inapplicable change in intel_crt.c]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: load the lm63 driver for an lm64 thermal chip.</title>
<updated>2014-09-13T22:41:43+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2014-07-28T03:21:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9ff66a756f78228be58871aa1da6445971a338d9'/>
<id>9ff66a756f78228be58871aa1da6445971a338d9</id>
<content type='text'>
commit 5dc355325b648dc9b4cf3bea4d968de46fd59215 upstream.

Looks like the lm63 driver supports the lm64 as well.

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5dc355325b648dc9b4cf3bea4d968de46fd59215 upstream.

Looks like the lm63 driver supports the lm64 as well.

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/ttm: Fix possible stack overflow by recursive shrinker calls.</title>
<updated>2014-09-13T22:41:43+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2014-08-03T11:02:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=312b559d9e61b473b39d3dc05fe0db43c2df60fb'/>
<id>312b559d9e61b473b39d3dc05fe0db43c2df60fb</id>
<content type='text'>
commit 71336e011d1d2312bcbcaa8fcec7365024f3a95d upstream.

While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL
allocation, ttm_pool_shrink_scan() does not do it. This can result in stack
overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to
memory pressure.

  shrink_slab()
  =&gt; ttm_pool_shrink_scan()
     =&gt; ttm_page_pool_free()
        =&gt; kmalloc(GFP_KERNEL)
           =&gt; shrink_slab()
              =&gt; ttm_pool_shrink_scan()
                 =&gt; ttm_page_pool_free()
                    =&gt; kmalloc(GFP_KERNEL)

Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
[bwh: Backported to 3.2:
 - Adjust context
 - Change return value in the contended case to follow the old shrinker
   API]   
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 71336e011d1d2312bcbcaa8fcec7365024f3a95d upstream.

While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL
allocation, ttm_pool_shrink_scan() does not do it. This can result in stack
overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to
memory pressure.

  shrink_slab()
  =&gt; ttm_pool_shrink_scan()
     =&gt; ttm_page_pool_free()
        =&gt; kmalloc(GFP_KERNEL)
           =&gt; shrink_slab()
              =&gt; ttm_pool_shrink_scan()
                 =&gt; ttm_page_pool_free()
                    =&gt; kmalloc(GFP_KERNEL)

Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
[bwh: Backported to 3.2:
 - Adjust context
 - Change return value in the contended case to follow the old shrinker
   API]   
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
