linux-stable.git/drivers/gpu/drm/ttm, branch linux-3.14.y

drm/ttm: Avoid memory allocation from shrinker functions.

2015-01-27T16:18:54+00:00

commit 881fdaa5e4cb0d68e52acab0ad4e1820e2bfffa4 upstream.

Andrew Morton wrote:
> On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa  wrote:
>
> > Andrew Morton wrote:
> > > Poor ttm guys - this is a bit of a trap we set for them.
> >
> > Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
> > changed to use sc->gfp_mask rather than GFP_KERNEL.
> >
> > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> > -                       GFP_KERNEL);
> > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> >
> > But this bug is caused by sc->gfp_mask containing some flags which are not
> > in GFP_KERNEL, right? Then, I think
> >
> > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL);
> >
> > would hide this bug.
> >
> > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
>
> Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
> Just do
>
> 	struct page *pages_to_free[16];
>
> 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?
----------
>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
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->gfp_mask containing flags
which are not in GFP_KERNEL.

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

Changing from sc->gfp_mask to (sc->gfp_mask & 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 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/ttm: Pass GFP flags in order to avoid deadlock.

2014-10-05T21:52:09+00:00

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->gfp_mask or GFP_KERNEL to these functions,
and removes the deadlock warning.

Signed-off-by: Tetsuo Handa 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/ttm: Fix possible stack overflow by recursive shrinker calls.

2014-10-05T21:52:09+00:00

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()
  => ttm_pool_shrink_scan()
     => ttm_page_pool_free()
        => kmalloc(GFP_KERNEL)
           => shrink_slab()
              => ttm_pool_shrink_scan()
                 => ttm_page_pool_free()
                    => kmalloc(GFP_KERNEL)

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

Signed-off-by: Tetsuo Handa 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions.

2014-10-05T21:52:09+00:00

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(&_manager->lock). GFP_KERNEL allocation with
_manager->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 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/ttm: Choose a pool to shrink correctly in ttm_dma_pool_shrink_scan().

2014-10-05T21:52:09+00:00

commit 46c2df68f03a236b30808bba361f10900c88d95e upstream.

We can use "unsigned int" instead of "atomic_t" by updating start_pool
variable under _manager->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->lock) to !mutex_trylock(_manager->lork).

Signed-off-by: Tetsuo Handa 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/ttm: Fix possible division by 0 in ttm_dma_pool_shrink_scan().

2014-10-05T21:52:09+00:00

commit 11e504cc705e8ccb06ac93a276e11b5e8fee4d40 upstream.

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

Signed-off-by: Tetsuo Handa 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/ttm: don't oops if no invalidate_caches()

2014-03-12T18:53:51+00:00

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: [<          (null)>]           (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:[<0000000000000000>]  [<          (null)>]           (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:
   [] ? ttm_bo_handle_move_mem+0x54e/0x5b0 [ttm]
   [] ? ttm_bo_mem_space+0x169/0x340 [ttm]
   [] ttm_bo_move_buffer+0x117/0x130 [ttm]
   [] ? perf_event_init_context+0x141/0x220
   [] ttm_bo_validate+0xc1/0x130 [ttm]
   [] mgag200_bo_pin+0x87/0xc0 [mgag200]
   [] mga_crtc_cursor_set+0x474/0xbb0 [mgag200]
   [] ? __mem_cgroup_commit_charge+0x152/0x3b0
   [] ? mutex_lock+0x12/0x2f
   [] drm_mode_cursor_common+0x123/0x170 [drm]
   [] drm_mode_cursor_ioctl+0x41/0x50 [drm]
   [] drm_ioctl+0x502/0x630 [drm]
   [] ? __do_page_fault+0x1f4/0x510
   [] ? __restore_xstate_sig+0x218/0x4f0
   [] do_vfs_ioctl+0x2e5/0x4d0
   [] ? file_has_perm+0x8e/0xa0
   [] SyS_ioctl+0x81/0xa0
   [] system_call_fastpath+0x16/0x1b
  Code:  Bad RIP value.
  RIP  [<          (null)>]           (null)
   RSP 
  CR2: 0000000000000000

Signed-off-by: Rob Clark 
Reviewed-by: Jérôme Glisse 
Reviewed-by: Thomas Hellstrom 
Cc: stable@vger.kernel.org

drm/ttm: Work around performance regression with VM_PFNMAP

2014-03-12T13:07:24+00:00

A performance regression was introduced in TTM in linux 3.13 when we started using
VM_PFNMAP for shared mappings. In theory this should've been faster due to
less page book-keeping but it appears like VM_PFNMAP + x86 PAT + write-combine
is a particularly cpu-hungry combination, as seen by largely increased
cpu-usage on r200 GL video playback.

Until we've sorted out why, revert to always use VM_MIXEDMAP.
Reference: freedesktop.org bugzilla bug #75719

Reported-and-tested-by: 
Acked-by: Alex Deucher 
Signed-off-by: Thomas Hellstrom 
Cc: stable@vger.kernel.org

drm/ttm: Fix memory leak in ttm_agp_backend.c

2014-02-18T13:03:32+00:00

This patch fix a memory leak found by cppcheck.
[drivers/gpu/drm/ttm/ttm_agp_backend.c:129]:
(error) Memory leak: agp_be

Signed-off-by: Masanari Iida 
Reviewed-by: Thomas Hellstrom

drm/ttm: Don't clear page metadata of imported sg pages

2014-02-05T15:03:29+00:00

These page pointers shouldn't be visible to TTM in the first place, but
until we fix that up, don't clear the page metadata because that
will upset the exporter.

Reported-and-tested-by: Cristoph Haag 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz