<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/ttm, branch v3.12.43</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.12.43</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.12.43'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2015-01-26T13:39:23+00:00</updated>
<entry>
<title>drm/ttm: Avoid memory allocation from shrinker functions.</title>
<updated>2015-01-26T13:39:23+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2014-11-13T13:43:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fa13c23e556c71b97d1b4e8bf0d050c0881ecce3'/>
<id>urn:sha1:fa13c23e556c71b97d1b4e8bf0d050c0881ecce3</id>
<content type='text'>
commit 881fdaa5e4cb0d68e52acab0ad4e1820e2bfffa4 upstream.

Andrew Morton wrote:
&gt; On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt; wrote:
&gt;
&gt; &gt; Andrew Morton wrote:
&gt; &gt; &gt; Poor ttm guys - this is a bit of a trap we set for them.
&gt; &gt;
&gt; &gt; Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
&gt; &gt; changed to use sc-&gt;gfp_mask rather than GFP_KERNEL.
&gt; &gt;
&gt; &gt; -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
&gt; &gt; -                       GFP_KERNEL);
&gt; &gt; +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
&gt; &gt;
&gt; &gt; But this bug is caused by sc-&gt;gfp_mask containing some flags which are not
&gt; &gt; in GFP_KERNEL, right? Then, I think
&gt; &gt;
&gt; &gt; -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
&gt; &gt; +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp &amp; GFP_KERNEL);
&gt; &gt;
&gt; &gt; would hide this bug.
&gt; &gt;
&gt; &gt; But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
&gt;
&gt; Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
&gt; Just do
&gt;
&gt; 	struct page *pages_to_free[16];
&gt;
&gt; and rework the code to free 16 pages at a time.  Easy.

Well, ttm code wants to process 512 pages at a time for performance.
Memory footprint increased by 512 * sizeof(struct page *) buffer is
only 4096 bytes. What about using static buffer like below?
----------
&gt;From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: drm/ttm: Avoid memory allocation from shrinker functions.

Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid
deadlock.") caused BUG_ON() due to sc-&gt;gfp_mask containing flags
which are not in GFP_KERNEL.

  https://bugzilla.kernel.org/show_bug.cgi?id=87891

Changing from sc-&gt;gfp_mask to (sc-&gt;gfp_mask &amp; GFP_KERNEL) would
avoid the BUG_ON(), but avoiding memory allocation from shrinker
function is better and reliable fix.

Shrinker function is already serialized by global lock, and
clean up function is called after shrinker function is unregistered.
Thus, we can use static buffer when called from shrinker function
and clean up function.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>drm/ttm: Pass GFP flags in order to avoid deadlock.</title>
<updated>2014-09-18T14:40:00+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2014-08-03T11:02:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fe4bbb9bc4d42e980d01895cb7492babdcdf55cf'/>
<id>urn:sha1:fe4bbb9bc4d42e980d01895cb7492babdcdf55cf</id>
<content type='text'>
commit a91576d7916f6cce76d30303e60e1ac47cf4a76d upstream.

Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added
deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free()
are currently doing GFP_KERNEL allocation.

But these functions did not get updated to receive gfp_t argument.
This patch explicitly passes sc-&gt;gfp_mask or GFP_KERNEL to these functions,
and removes the deadlock warning.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>drm/ttm: Fix possible stack overflow by recursive shrinker calls.</title>
<updated>2014-09-18T14:40:00+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.radix-linux.su/kernel/linux.git/commit/?id=726e09542d0526359c9066f27fcc99437558bf7e'/>
<id>urn:sha1:726e09542d0526359c9066f27fcc99437558bf7e</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;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions.</title>
<updated>2014-09-18T14:40:00+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2014-08-03T11:01:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7d042e59c04b88edff83aa2ec1d1bc81f94bfaf4'/>
<id>urn:sha1:7d042e59c04b88edff83aa2ec1d1bc81f94bfaf4</id>
<content type='text'>
commit 22e71691fd54c637800d10816bbeba9cf132d218 upstream.

I can observe that RHEL7 environment stalls with 100% CPU usage when a
certain type of memory pressure is given. While the shrinker functions
are called by shrink_slab() before the OOM killer is triggered, the stall
lasts for many minutes.

One of reasons of this stall is that
ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and
are blocked at mutex_lock(&amp;_manager-&gt;lock). GFP_KERNEL allocation with
_manager-&gt;lock held causes someone (including kswapd) to deadlock when
these functions are called due to memory pressure. This patch changes
"mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to
avoid deadlock.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>drm/ttm: Choose a pool to shrink correctly in ttm_dma_pool_shrink_scan().</title>
<updated>2014-09-18T14:39:59+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2014-08-03T11:00:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=50ac045c45d41dad0c4b38a456dcc58a64c58244'/>
<id>urn:sha1:50ac045c45d41dad0c4b38a456dcc58a64c58244</id>
<content type='text'>
commit 46c2df68f03a236b30808bba361f10900c88d95e upstream.

We can use "unsigned int" instead of "atomic_t" by updating start_pool
variable under _manager-&gt;lock. This patch will make it possible to avoid
skipping when choosing a pool to shrink in round-robin style, after next
patch changes mutex_lock(_manager-&gt;lock) to !mutex_trylock(_manager-&gt;lork).

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>drm/ttm: Fix possible division by 0 in ttm_dma_pool_shrink_scan().</title>
<updated>2014-09-18T14:39:59+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2014-08-03T10:59:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1718e957131772d5344ee58e8c804a0641061aff'/>
<id>urn:sha1:1718e957131772d5344ee58e8c804a0641061aff</id>
<content type='text'>
commit 11e504cc705e8ccb06ac93a276e11b5e8fee4d40 upstream.

list_empty(&amp;_manager-&gt;pools) being false before taking _manager-&gt;lock
does not guarantee that _manager-&gt;npools != 0 after taking _manager-&gt;lock
because _manager-&gt;npools is updated under _manager-&gt;lock.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>drm/ttm: don't oops if no invalidate_caches()</title>
<updated>2014-03-21T21:55:59+00:00</updated>
<author>
<name>Rob Clark</name>
<email>rclark@redhat.com</email>
</author>
<published>2014-03-12T14:59:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e00feda0d79196595eb0c12cd15b0b9015830190'/>
<id>urn:sha1:e00feda0d79196595eb0c12cd15b0b9015830190</id>
<content type='text'>
commit 9ef7506f7eff3fc42724269f62e30164c141661f upstream.

A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement
this function.  Yet can end up somehow with an evicted bo:

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: [&lt;          (null)&gt;]           (null)
  PGD 16e761067 PUD 16e6cf067 PMD 0
  Oops: 0010 [#1] SMP
  Modules linked in: bnep bluetooth rfkill fuse ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables sg btrfs zlib_deflate raid6_pq xor dm_queue_length iTCO_wdt iTCO_vendor_support coretemp kvm dcdbas dm_service_time microcode serio_raw pcspkr lpc_ich mfd_core i7core_edac edac_core ses enclosure ipmi_si ipmi_msghandler shpchp acpi_power_meter mperf nfsd auth_rpcgss nfs_acl lockd uinput sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sr_mod cdrom
   sd_mod usb_storage mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit lpfc drm_kms_helper ttm crc32c_intel ata_piix bfa drm ixgbe libata i2c_core mdio crc_t10dif ptp crct10dif_common pps_core scsi_transport_fc dca scsi_tgt megaraid_sas bnx2 dm_mirror dm_region_hash dm_log dm_mod
  CPU: 16 PID: 2572 Comm: X Not tainted 3.10.0-86.el7.x86_64 #1
  Hardware name: Dell Inc. PowerEdge R810/0H235N, BIOS 0.3.0 11/14/2009
  task: ffff8801799dabc0 ti: ffff88016c884000 task.ti: ffff88016c884000
  RIP: 0010:[&lt;0000000000000000&gt;]  [&lt;          (null)&gt;]           (null)
  RSP: 0018:ffff88016c885ad8  EFLAGS: 00010202
  RAX: ffffffffa04e94c0 RBX: ffff880178937a20 RCX: 0000000000000000
  RDX: 0000000000000000 RSI: 0000000000240004 RDI: ffff880178937a00
  RBP: ffff88016c885b60 R08: 00000000000171a0 R09: ffff88007cf171a0
  R10: ffffea0005842540 R11: ffffffff810487b9 R12: ffff880178937b30
  R13: ffff880178937a00 R14: ffff88016c885b78 R15: ffff880179929400
  FS:  00007f81ba2ef980(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 000000016e763000 CR4: 00000000000007e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Stack:
   ffffffffa0306fae ffff8801799295c0 0000000000260004 0000000000000001
   ffff88016c885b60 ffffffffa0307669 00ff88007cf17738 ffff88017cf17700
   ffff880178937a00 ffff880100000000 ffff880100000000 0000000079929400
  Call Trace:
   [&lt;ffffffffa0306fae&gt;] ? ttm_bo_handle_move_mem+0x54e/0x5b0 [ttm]
   [&lt;ffffffffa0307669&gt;] ? ttm_bo_mem_space+0x169/0x340 [ttm]
   [&lt;ffffffffa0307bd7&gt;] ttm_bo_move_buffer+0x117/0x130 [ttm]
   [&lt;ffffffff81130001&gt;] ? perf_event_init_context+0x141/0x220
   [&lt;ffffffffa0307cb1&gt;] ttm_bo_validate+0xc1/0x130 [ttm]
   [&lt;ffffffffa04e7377&gt;] mgag200_bo_pin+0x87/0xc0 [mgag200]
   [&lt;ffffffffa04e56c4&gt;] mga_crtc_cursor_set+0x474/0xbb0 [mgag200]
   [&lt;ffffffff811971d2&gt;] ? __mem_cgroup_commit_charge+0x152/0x3b0
   [&lt;ffffffff815c4182&gt;] ? mutex_lock+0x12/0x2f
   [&lt;ffffffffa0201433&gt;] drm_mode_cursor_common+0x123/0x170 [drm]
   [&lt;ffffffffa0205231&gt;] drm_mode_cursor_ioctl+0x41/0x50 [drm]
   [&lt;ffffffffa01f5ca2&gt;] drm_ioctl+0x502/0x630 [drm]
   [&lt;ffffffff815cbab4&gt;] ? __do_page_fault+0x1f4/0x510
   [&lt;ffffffff8101cb68&gt;] ? __restore_xstate_sig+0x218/0x4f0
   [&lt;ffffffff811b4445&gt;] do_vfs_ioctl+0x2e5/0x4d0
   [&lt;ffffffff8124488e&gt;] ? file_has_perm+0x8e/0xa0
   [&lt;ffffffff811b46b1&gt;] SyS_ioctl+0x81/0xa0
   [&lt;ffffffff815d05d9&gt;] system_call_fastpath+0x16/0x1b
  Code:  Bad RIP value.
  RIP  [&lt;          (null)&gt;]           (null)
   RSP &lt;ffff88016c885ad8&gt;
  CR2: 0000000000000000

Signed-off-by: Rob Clark &lt;rclark@redhat.com&gt;
Reviewed-by: Jérôme Glisse &lt;jglisse@redhat.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>drm/ttm: Fix accesses through vmas with only partial coverage</title>
<updated>2014-01-09T20:25:10+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2013-12-09T07:23:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=36abf88c17b1dec10590f7accb66b3d72a6df214'/>
<id>urn:sha1:36abf88c17b1dec10590f7accb66b3d72a6df214</id>
<content type='text'>
commit d386735588c3e22129c2bc6eb64fc1d37a8f805c upstream.

VMAs covering a bo but that didn't start at the same address space offset as
the bo they were mapping were incorrectly generating SEGFAULT errors in
the fault handler.

Reported-by: Joseph Dolinak &lt;kanilo2@yahoo.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/ttm: Fix ttm_bo_move_memcpy</title>
<updated>2013-12-04T19:05:50+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2013-10-30T10:29:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0200fea72f2e49d096c95845e58a242fca2bf168'/>
<id>urn:sha1:0200fea72f2e49d096c95845e58a242fca2bf168</id>
<content type='text'>
commit da95c788ef0c645378ffccb7060a0df1a33aee38 upstream.

All error paths will want to keep the mm node, so handle this at the
function exit. This fixes an ioremap failure error path.
Also add some comments to make the function a bit easier to understand.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/ttm: Handle in-memory region copies</title>
<updated>2013-12-04T19:05:42+00:00</updated>
<author>
<name>Jakob Bornecrantz</name>
<email>jakob@vmware.com</email>
</author>
<published>2013-10-30T09:46:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=032cefc6d64dee023a98a41f56b5c16487eb202b'/>
<id>urn:sha1:032cefc6d64dee023a98a41f56b5c16487eb202b</id>
<content type='text'>
commit 9a0599ddeae012a771bba5e23393fc52d8a59d89 upstream.

Fix the case where the ttm pointer may be NULL causing
a NULL pointer dereference.

Signed-off-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Signed-off-by: Thomas Hellström &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
