linux-toradex.git/drivers/gpu/drm/ttm, branch v3.14.26

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

drm/ttm: Fix TTM object open regression

2014-02-05T08:29:25+00:00

Commit drm/ttm: ttm object security fixes for render nodes introduced a
regression where, if a TTM object was opened multiple times from the same
open file, the caller would spin uninterruptibly in the kernel.

Fix this.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz