aboutsummaryrefslogtreecommitdiff
path: root/drivers/leds/leds-dac124s085.c
diff options
context:
space:
mode:
authorDaniel Vetter2012-12-19 14:33:45 +0100
committerDaniel Vetter2012-12-20 14:56:04 +0100
commit677feac291c1ea7f0b84c6e499e858d440b96c7b (patch)
tree570836d75d31900b2647bffff73b12789f8c583b /drivers/leds/leds-dac124s085.c
parent5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 (diff)
drm/i915: optionally disable shrinker lock stealing
commit 5774506f157a91400c587b85d1ce4de56f0d32f6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Nov 21 13:04:04 2012 +0000 drm/i915: Borrow our struct_mutex for the direct reclaim added a nice trick to steal the struct_mutex lock in the shrinker if it's the current task holding it. But this also caused the requirement that every place which allocates memory needs to be careful about the gem state of objects, since the shrinker could have pulled the rug out from under it. We've usually solved this by carefully preallocating things or ensure that buffers are pinned already. But the shrinker also reaps mmap offset, so allocating those needs to be careful, too. Now that code has been factored out into some common helpers, so either we have fragile code depending upon the common helper not doing something we don't want it to do. Or we need to reimplement the mmap offset creation and so also leak implementation details into our code. Since this all results in leaky abstraction, cop out by disabling the lock borrowing trick while calling down into the helpers. That way our craziness is nicely confined to files in drm/i915. v2: Split out the change to create_mmap_offset as request by Chris Wilson. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/leds/leds-dac124s085.c')
0 files changed, 0 insertions, 0 deletions