From: Greg Kroah-Hartman Date: Wed, 12 Apr 2017 13:02:08 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.10.11~20 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=cb5a50865a09a6a505c1f247a8fff7cd9aff2bf8;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch drm-i915-stop-using-rp_down_ei-on-baytrail.patch orangefs-dan-carpenter-influenced-cleanups.patch orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch orangefs-fix-memory-leak-of-string-new-on-exit-path.patch --- diff --git a/queue-4.9/drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch b/queue-4.9/drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch new file mode 100644 index 00000000000..dc3441b97a5 --- /dev/null +++ b/queue-4.9/drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch @@ -0,0 +1,274 @@ +From 3d3d18f086cdda72ee18a454db70ca72c6e3246c Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Tue, 21 Mar 2017 14:45:31 +0000 +Subject: drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker) + +From: Chris Wilson + +commit 3d3d18f086cdda72ee18a454db70ca72c6e3246c upstream. + +The rcu_barrier() takes the cpu_hotplug mutex which itself is not +reclaim-safe, and so rcu_barrier() is illegal from inside the shrinker. + +[ 309.661373] ========================================================= +[ 309.661376] [ INFO: possible irq lock inversion dependency detected ] +[ 309.661380] 4.11.0-rc1-CI-CI_DRM_2333+ #1 Tainted: G W +[ 309.661383] --------------------------------------------------------- +[ 309.661386] gem_exec_gttfil/6435 just changed the state of lock: +[ 309.661389] (rcu_preempt_state.barrier_mutex){+.+.-.}, at: [] _rcu_barrier+0x31/0x160 +[ 309.661399] but this lock took another, RECLAIM_FS-unsafe lock in the past: +[ 309.661402] (cpu_hotplug.lock){+.+.+.} +[ 309.661404] + + and interrupts could create inverse lock ordering between them. + +[ 309.661410] + other info that might help us debug this: +[ 309.661414] Possible interrupt unsafe locking scenario: + +[ 309.661417] CPU0 CPU1 +[ 309.661419] ---- ---- +[ 309.661421] lock(cpu_hotplug.lock); +[ 309.661425] local_irq_disable(); +[ 309.661432] lock(rcu_preempt_state.barrier_mutex); +[ 309.661441] lock(cpu_hotplug.lock); +[ 309.661446] +[ 309.661448] lock(rcu_preempt_state.barrier_mutex); +[ 309.661453] + *** DEADLOCK *** + +[ 309.661460] 4 locks held by gem_exec_gttfil/6435: +[ 309.661464] #0: (sb_writers#10){.+.+.+}, at: [] vfs_write+0x17d/0x1f0 +[ 309.661475] #1: (debugfs_srcu){......}, at: [] debugfs_use_file_start+0x41/0xa0 +[ 309.661486] #2: (&attr->mutex){+.+.+.}, at: [] simple_attr_write+0x37/0xe0 +[ 309.661495] #3: (&dev->struct_mutex){+.+.+.}, at: [] i915_drop_caches_set+0x3a/0x150 [i915] +[ 309.661540] + the shortest dependencies between 2nd lock and 1st lock: +[ 309.661547] -> (cpu_hotplug.lock){+.+.+.} ops: 829 { +[ 309.661553] HARDIRQ-ON-W at: +[ 309.661560] __lock_acquire+0x5e5/0x1b50 +[ 309.661565] lock_acquire+0xc9/0x220 +[ 309.661572] __mutex_lock+0x6e/0x990 +[ 309.661576] mutex_lock_nested+0x16/0x20 +[ 309.661583] get_online_cpus+0x61/0x80 +[ 309.661590] kmem_cache_create+0x25/0x1d0 +[ 309.661596] debug_objects_mem_init+0x30/0x249 +[ 309.661602] start_kernel+0x341/0x3fe +[ 309.661607] x86_64_start_reservations+0x2a/0x2c +[ 309.661612] x86_64_start_kernel+0x173/0x186 +[ 309.661619] verify_cpu+0x0/0xfc +[ 309.661622] SOFTIRQ-ON-W at: +[ 309.661627] __lock_acquire+0x611/0x1b50 +[ 309.661632] lock_acquire+0xc9/0x220 +[ 309.661636] __mutex_lock+0x6e/0x990 +[ 309.661641] mutex_lock_nested+0x16/0x20 +[ 309.661646] get_online_cpus+0x61/0x80 +[ 309.661650] kmem_cache_create+0x25/0x1d0 +[ 309.661655] debug_objects_mem_init+0x30/0x249 +[ 309.661660] start_kernel+0x341/0x3fe +[ 309.661664] x86_64_start_reservations+0x2a/0x2c +[ 309.661669] x86_64_start_kernel+0x173/0x186 +[ 309.661674] verify_cpu+0x0/0xfc +[ 309.661677] RECLAIM_FS-ON-W at: +[ 309.661682] mark_held_locks+0x6f/0xa0 +[ 309.661687] lockdep_trace_alloc+0xb3/0x100 +[ 309.661693] kmem_cache_alloc_trace+0x31/0x2e0 +[ 309.661699] __smpboot_create_thread.part.1+0x27/0xe0 +[ 309.661704] smpboot_create_threads+0x61/0x90 +[ 309.661709] cpuhp_invoke_callback+0x9c/0x8a0 +[ 309.661713] cpuhp_up_callbacks+0x31/0xb0 +[ 309.661718] _cpu_up+0x7a/0xc0 +[ 309.661723] do_cpu_up+0x5f/0x80 +[ 309.661727] cpu_up+0xe/0x10 +[ 309.661734] smp_init+0x71/0xb3 +[ 309.661738] kernel_init_freeable+0x94/0x19e +[ 309.661743] kernel_init+0x9/0xf0 +[ 309.661748] ret_from_fork+0x2e/0x40 +[ 309.661752] INITIAL USE at: +[ 309.661757] __lock_acquire+0x234/0x1b50 +[ 309.661761] lock_acquire+0xc9/0x220 +[ 309.661766] __mutex_lock+0x6e/0x990 +[ 309.661771] mutex_lock_nested+0x16/0x20 +[ 309.661775] get_online_cpus+0x61/0x80 +[ 309.661780] __cpuhp_setup_state+0x44/0x170 +[ 309.661785] page_alloc_init+0x23/0x3a +[ 309.661790] start_kernel+0x124/0x3fe +[ 309.661794] x86_64_start_reservations+0x2a/0x2c +[ 309.661799] x86_64_start_kernel+0x173/0x186 +[ 309.661804] verify_cpu+0x0/0xfc +[ 309.661807] } +[ 309.661813] ... key at: [] cpu_hotplug+0xb0/0x100 +[ 309.661817] ... acquired at: +[ 309.661821] lock_acquire+0xc9/0x220 +[ 309.661825] __mutex_lock+0x6e/0x990 +[ 309.661829] mutex_lock_nested+0x16/0x20 +[ 309.661833] get_online_cpus+0x61/0x80 +[ 309.661837] _rcu_barrier+0x9f/0x160 +[ 309.661841] rcu_barrier+0x10/0x20 +[ 309.661847] netdev_run_todo+0x5f/0x310 +[ 309.661852] rtnl_unlock+0x9/0x10 +[ 309.661856] default_device_exit_batch+0x133/0x150 +[ 309.661862] ops_exit_list.isra.0+0x4d/0x60 +[ 309.661866] cleanup_net+0x1d8/0x2c0 +[ 309.661872] process_one_work+0x1f4/0x6d0 +[ 309.661876] worker_thread+0x49/0x4a0 +[ 309.661881] kthread+0x107/0x140 +[ 309.661884] ret_from_fork+0x2e/0x40 + +[ 309.661890] -> (rcu_preempt_state.barrier_mutex){+.+.-.} ops: 179 { +[ 309.661896] HARDIRQ-ON-W at: +[ 309.661901] __lock_acquire+0x5e5/0x1b50 +[ 309.661905] lock_acquire+0xc9/0x220 +[ 309.661910] __mutex_lock+0x6e/0x990 +[ 309.661914] mutex_lock_nested+0x16/0x20 +[ 309.661919] _rcu_barrier+0x31/0x160 +[ 309.661923] rcu_barrier+0x10/0x20 +[ 309.661928] netdev_run_todo+0x5f/0x310 +[ 309.661932] rtnl_unlock+0x9/0x10 +[ 309.661936] default_device_exit_batch+0x133/0x150 +[ 309.661941] ops_exit_list.isra.0+0x4d/0x60 +[ 309.661946] cleanup_net+0x1d8/0x2c0 +[ 309.661951] process_one_work+0x1f4/0x6d0 +[ 309.661955] worker_thread+0x49/0x4a0 +[ 309.661960] kthread+0x107/0x140 +[ 309.661964] ret_from_fork+0x2e/0x40 +[ 309.661968] SOFTIRQ-ON-W at: +[ 309.661972] __lock_acquire+0x611/0x1b50 +[ 309.661977] lock_acquire+0xc9/0x220 +[ 309.661981] __mutex_lock+0x6e/0x990 +[ 309.661986] mutex_lock_nested+0x16/0x20 +[ 309.661990] _rcu_barrier+0x31/0x160 +[ 309.661995] rcu_barrier+0x10/0x20 +[ 309.661999] netdev_run_todo+0x5f/0x310 +[ 309.662003] rtnl_unlock+0x9/0x10 +[ 309.662008] default_device_exit_batch+0x133/0x150 +[ 309.662013] ops_exit_list.isra.0+0x4d/0x60 +[ 309.662017] cleanup_net+0x1d8/0x2c0 +[ 309.662022] process_one_work+0x1f4/0x6d0 +[ 309.662027] worker_thread+0x49/0x4a0 +[ 309.662031] kthread+0x107/0x140 +[ 309.662035] ret_from_fork+0x2e/0x40 +[ 309.662039] IN-RECLAIM_FS-W at: +[ 309.662043] __lock_acquire+0x638/0x1b50 +[ 309.662048] lock_acquire+0xc9/0x220 +[ 309.662053] __mutex_lock+0x6e/0x990 +[ 309.662058] mutex_lock_nested+0x16/0x20 +[ 309.662062] _rcu_barrier+0x31/0x160 +[ 309.662067] rcu_barrier+0x10/0x20 +[ 309.662089] i915_gem_shrink_all+0x33/0x40 [i915] +[ 309.662109] i915_drop_caches_set+0x141/0x150 [i915] +[ 309.662114] simple_attr_write+0xc7/0xe0 +[ 309.662119] full_proxy_write+0x4f/0x70 +[ 309.662124] __vfs_write+0x23/0x120 +[ 309.662128] vfs_write+0xc6/0x1f0 +[ 309.662133] SyS_write+0x44/0xb0 +[ 309.662138] entry_SYSCALL_64_fastpath+0x1c/0xb1 +[ 309.662142] INITIAL USE at: +[ 309.662147] __lock_acquire+0x234/0x1b50 +[ 309.662151] lock_acquire+0xc9/0x220 +[ 309.662156] __mutex_lock+0x6e/0x990 +[ 309.662160] mutex_lock_nested+0x16/0x20 +[ 309.662165] _rcu_barrier+0x31/0x160 +[ 309.662169] rcu_barrier+0x10/0x20 +[ 309.662174] netdev_run_todo+0x5f/0x310 +[ 309.662178] rtnl_unlock+0x9/0x10 +[ 309.662183] default_device_exit_batch+0x133/0x150 +[ 309.662188] ops_exit_list.isra.0+0x4d/0x60 +[ 309.662192] cleanup_net+0x1d8/0x2c0 +[ 309.662197] process_one_work+0x1f4/0x6d0 +[ 309.662202] worker_thread+0x49/0x4a0 +[ 309.662206] kthread+0x107/0x140 +[ 309.662210] ret_from_fork+0x2e/0x40 +[ 309.662214] } +[ 309.662220] ... key at: [] rcu_preempt_state+0x508/0x780 +[ 309.662225] ... acquired at: +[ 309.662229] check_usage_forwards+0x12b/0x130 +[ 309.662233] mark_lock+0x360/0x6f0 +[ 309.662237] __lock_acquire+0x638/0x1b50 +[ 309.662241] lock_acquire+0xc9/0x220 +[ 309.662245] __mutex_lock+0x6e/0x990 +[ 309.662249] mutex_lock_nested+0x16/0x20 +[ 309.662253] _rcu_barrier+0x31/0x160 +[ 309.662257] rcu_barrier+0x10/0x20 +[ 309.662279] i915_gem_shrink_all+0x33/0x40 [i915] +[ 309.662298] i915_drop_caches_set+0x141/0x150 [i915] +[ 309.662303] simple_attr_write+0xc7/0xe0 +[ 309.662307] full_proxy_write+0x4f/0x70 +[ 309.662311] __vfs_write+0x23/0x120 +[ 309.662315] vfs_write+0xc6/0x1f0 +[ 309.662319] SyS_write+0x44/0xb0 +[ 309.662323] entry_SYSCALL_64_fastpath+0x1c/0xb1 + +[ 309.662329] + stack backtrace: +[ 309.662335] CPU: 1 PID: 6435 Comm: gem_exec_gttfil Tainted: G W 4.11.0-rc1-CI-CI_DRM_2333+ #1 +[ 309.662342] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 +[ 309.662348] Call Trace: +[ 309.662354] dump_stack+0x67/0x92 +[ 309.662359] print_irq_inversion_bug.part.19+0x1a4/0x1b0 +[ 309.662365] check_usage_forwards+0x12b/0x130 +[ 309.662369] mark_lock+0x360/0x6f0 +[ 309.662374] ? print_shortest_lock_dependencies+0x1a0/0x1a0 +[ 309.662379] __lock_acquire+0x638/0x1b50 +[ 309.662383] ? __mutex_unlock_slowpath+0x3e/0x2e0 +[ 309.662388] ? trace_hardirqs_on+0xd/0x10 +[ 309.662392] ? _rcu_barrier+0x31/0x160 +[ 309.662396] lock_acquire+0xc9/0x220 +[ 309.662400] ? _rcu_barrier+0x31/0x160 +[ 309.662404] ? _rcu_barrier+0x31/0x160 +[ 309.662409] __mutex_lock+0x6e/0x990 +[ 309.662412] ? _rcu_barrier+0x31/0x160 +[ 309.662416] ? _rcu_barrier+0x31/0x160 +[ 309.662421] ? synchronize_rcu_expedited+0x35/0xb0 +[ 309.662426] ? _raw_spin_unlock_irqrestore+0x52/0x60 +[ 309.662434] mutex_lock_nested+0x16/0x20 +[ 309.662438] _rcu_barrier+0x31/0x160 +[ 309.662442] rcu_barrier+0x10/0x20 +[ 309.662464] i915_gem_shrink_all+0x33/0x40 [i915] +[ 309.662484] i915_drop_caches_set+0x141/0x150 [i915] +[ 309.662489] simple_attr_write+0xc7/0xe0 +[ 309.662494] full_proxy_write+0x4f/0x70 +[ 309.662498] __vfs_write+0x23/0x120 +[ 309.662503] ? rcu_read_lock_sched_held+0x75/0x80 +[ 309.662507] ? rcu_sync_lockdep_assert+0x2a/0x50 +[ 309.662512] ? __sb_start_write+0x102/0x210 +[ 309.662516] ? vfs_write+0x17d/0x1f0 +[ 309.662520] vfs_write+0xc6/0x1f0 +[ 309.662524] ? trace_hardirqs_on_caller+0xe7/0x200 +[ 309.662529] SyS_write+0x44/0xb0 +[ 309.662533] entry_SYSCALL_64_fastpath+0x1c/0xb1 +[ 309.662537] RIP: 0033:0x7f507eac24a0 +[ 309.662541] RSP: 002b:00007fffda8720e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 +[ 309.662548] RAX: ffffffffffffffda RBX: ffffffff81482bd3 RCX: 00007f507eac24a0 +[ 309.662552] RDX: 0000000000000005 RSI: 00007fffda8720f0 RDI: 0000000000000005 +[ 309.662557] RBP: ffffc9000048bf88 R08: 0000000000000000 R09: 000000000000002c +[ 309.662561] R10: 0000000000000014 R11: 0000000000000246 R12: 00007fffda872230 +[ 309.662566] R13: 00007fffda872228 R14: 0000000000000201 R15: 00007fffda8720f0 +[ 309.662572] ? __this_cpu_preempt_check+0x13/0x20 + +Fixes: 0eafec6d3244 ("drm/i915: Enable lockless lookup of request tracking via RCU") +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100192 +Signed-off-by: Chris Wilson +Cc: Daniel Vetter +Link: http://patchwork.freedesktop.org/patch/msgid/20170314115019.18127-1-chris@chris-wilson.co.uk +Reviewed-by: Daniel Vetter +(cherry picked from commit bd784b7cc41af7a19cfb705fa6d800e511c4ab02) +Signed-off-by: Jani Nikula +Link: http://patchwork.freedesktop.org/patch/msgid/20170321144531.12344-1-chris@chris-wilson.co.uk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c ++++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c +@@ -233,7 +233,7 @@ unsigned long i915_gem_shrink_all(struct + I915_SHRINK_BOUND | + I915_SHRINK_UNBOUND | + I915_SHRINK_ACTIVE); +- rcu_barrier(); /* wait until our RCU delayed slab frees are completed */ ++ synchronize_rcu(); /* wait for our earlier RCU delayed slab frees */ + + return freed; + } diff --git a/queue-4.9/drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch b/queue-4.9/drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch new file mode 100644 index 00000000000..58f29a6d5e0 --- /dev/null +++ b/queue-4.9/drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch @@ -0,0 +1,174 @@ +From 0f5418e564ac6452b9086295646e602a9addc4bf Mon Sep 17 00:00:00 2001 +From: Kenneth Graunke +Date: Mon, 13 Mar 2017 17:04:33 +0000 +Subject: drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. + +From: Kenneth Graunke + +commit 0f5418e564ac6452b9086295646e602a9addc4bf upstream. + +This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 +(indicating the optional feature is not supported), and makes execbuf +always return -EINVAL if the flags are used. + +Apparently, no userspace ever shipped which used this optional feature: +I checked the git history of Mesa, xf86-video-intel, libva, and Beignet, +and there were zero commits showing a use of these flags. Kernel commit +72bfa19c8deb4 apparently introduced the feature prematurely. According +to Chris, the intention was to use this in cairo-drm, but "the use was +broken for gen6", so I don't think it ever happened. + +'relative_constants_mode' has always been tracked per-device, but this +has actually been wrong ever since hardware contexts were introduced, as +the INSTPM register is saved (and automatically restored) as part of the +render ring context. The software per-device value could therefore get +out of sync with the hardware per-context value. This meant that using +them is actually unsafe: a client which tried to use them could damage +the state of other clients, causing the GPU to interpret their BO +offsets as absolute pointers, leading to bogus memory reads. + +These flags were also never ported to execlist mode, making them no-ops +on Gen9+ (which requires execlists), and Gen8 in the default mode. + +On Gen8+, userspace can write these registers directly, achieving the +same effect. On Gen6-7.5, it likely makes sense to extend the command +parser to support them. I don't think anyone wants this on Gen4-5. + +Based on a patch by Dave Gordon. + +v3: Return -ENODEV for the getparam, as this is what we do for other + obsolete features. Suggested by Chris Wilson. + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448 +Signed-off-by: Kenneth Graunke +Reviewed-by: Joonas Lahtinen +Reviewed-by: Chris Wilson +Link: http://patchwork.freedesktop.org/patch/msgid/20170215093446.21291-1-kenneth@whitecape.org +Acked-by: Daniel Vetter +Signed-off-by: Chris Wilson +Link: http://patchwork.freedesktop.org/patch/msgid/20170313170433.26843-1-chris@chris-wilson.co.uk +(cherry picked from commit ef0f411f51475f4eebf9fc1b19a85be698af19ff) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_drv.c | 4 -- + drivers/gpu/drm/i915/i915_drv.h | 2 - + drivers/gpu/drm/i915/i915_gem.c | 2 - + drivers/gpu/drm/i915/i915_gem_execbuffer.c | 52 +---------------------------- + 4 files changed, 3 insertions(+), 57 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_drv.c ++++ b/drivers/gpu/drm/i915/i915_drv.c +@@ -240,6 +240,7 @@ static int i915_getparam(struct drm_devi + case I915_PARAM_IRQ_ACTIVE: + case I915_PARAM_ALLOW_BATCHBUFFER: + case I915_PARAM_LAST_DISPATCH: ++ case I915_PARAM_HAS_EXEC_CONSTANTS: + /* Reject all old ums/dri params. */ + return -ENODEV; + case I915_PARAM_CHIPSET_ID: +@@ -266,9 +267,6 @@ static int i915_getparam(struct drm_devi + case I915_PARAM_HAS_BSD2: + value = intel_engine_initialized(&dev_priv->engine[VCS2]); + break; +- case I915_PARAM_HAS_EXEC_CONSTANTS: +- value = INTEL_GEN(dev_priv) >= 4; +- break; + case I915_PARAM_HAS_LLC: + value = HAS_LLC(dev_priv); + break; +--- a/drivers/gpu/drm/i915/i915_drv.h ++++ b/drivers/gpu/drm/i915/i915_drv.h +@@ -1751,8 +1751,6 @@ struct drm_i915_private { + + const struct intel_device_info info; + +- int relative_constants_mode; +- + void __iomem *regs; + + struct intel_uncore uncore; +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -4587,8 +4587,6 @@ i915_gem_load_init(struct drm_device *de + init_waitqueue_head(&dev_priv->gpu_error.wait_queue); + init_waitqueue_head(&dev_priv->gpu_error.reset_queue); + +- dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL; +- + init_waitqueue_head(&dev_priv->pending_flip_queue); + + dev_priv->mm.interruptible = true; +--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c ++++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c +@@ -1454,10 +1454,7 @@ execbuf_submit(struct i915_execbuffer_pa + struct drm_i915_gem_execbuffer2 *args, + struct list_head *vmas) + { +- struct drm_i915_private *dev_priv = params->request->i915; + u64 exec_start, exec_len; +- int instp_mode; +- u32 instp_mask; + int ret; + + ret = i915_gem_execbuffer_move_to_gpu(params->request, vmas); +@@ -1468,56 +1465,11 @@ execbuf_submit(struct i915_execbuffer_pa + if (ret) + return ret; + +- instp_mode = args->flags & I915_EXEC_CONSTANTS_MASK; +- instp_mask = I915_EXEC_CONSTANTS_MASK; +- switch (instp_mode) { +- case I915_EXEC_CONSTANTS_REL_GENERAL: +- case I915_EXEC_CONSTANTS_ABSOLUTE: +- case I915_EXEC_CONSTANTS_REL_SURFACE: +- if (instp_mode != 0 && params->engine->id != RCS) { +- DRM_DEBUG("non-0 rel constants mode on non-RCS\n"); +- return -EINVAL; +- } +- +- if (instp_mode != dev_priv->relative_constants_mode) { +- if (INTEL_INFO(dev_priv)->gen < 4) { +- DRM_DEBUG("no rel constants on pre-gen4\n"); +- return -EINVAL; +- } +- +- if (INTEL_INFO(dev_priv)->gen > 5 && +- instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) { +- DRM_DEBUG("rel surface constants mode invalid on gen5+\n"); +- return -EINVAL; +- } +- +- /* The HW changed the meaning on this bit on gen6 */ +- if (INTEL_INFO(dev_priv)->gen >= 6) +- instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE; +- } +- break; +- default: +- DRM_DEBUG("execbuf with unknown constants: %d\n", instp_mode); ++ if (args->flags & I915_EXEC_CONSTANTS_MASK) { ++ DRM_DEBUG("I915_EXEC_CONSTANTS_* unsupported\n"); + return -EINVAL; + } + +- if (params->engine->id == RCS && +- instp_mode != dev_priv->relative_constants_mode) { +- struct intel_ring *ring = params->request->ring; +- +- ret = intel_ring_begin(params->request, 4); +- if (ret) +- return ret; +- +- intel_ring_emit(ring, MI_NOOP); +- intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1)); +- intel_ring_emit_reg(ring, INSTPM); +- intel_ring_emit(ring, instp_mask << 16 | instp_mode); +- intel_ring_advance(ring); +- +- dev_priv->relative_constants_mode = instp_mode; +- } +- + if (args->flags & I915_EXEC_GEN7_SOL_RESET) { + ret = i915_reset_gen7_sol_offsets(params->request); + if (ret) diff --git a/queue-4.9/drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch b/queue-4.9/drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch new file mode 100644 index 00000000000..0ab111ad175 --- /dev/null +++ b/queue-4.9/drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch @@ -0,0 +1,141 @@ +From 35a3abfd198e6c69a6644784bb09a2d951fc6b21 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Mon, 13 Mar 2017 17:02:31 +0000 +Subject: drm/i915: Only enable hotplug interrupts if the display interrupts are enabled +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Chris Wilson + +commit 35a3abfd198e6c69a6644784bb09a2d951fc6b21 upstream. + +In order to prevent accessing the hpd registers outside of the display +power wells, we should refrain from writing to the registers before the +display interrupts are enabled. + +[ 4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915] +[ 4.740155] Unclaimed read from register 0x1e1110 +[ 4.740168] Modules linked in: i915(+) intel_gtt drm_kms_helper prime_numbers +[ 4.740190] CPU: 1 PID: 221 Comm: systemd-udevd Not tainted 4.10.0-rc6+ #384 +[ 4.740203] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 +[ 4.740220] Call Trace: +[ 4.740236] dump_stack+0x4d/0x6f +[ 4.740251] __warn+0xc1/0xe0 +[ 4.740265] warn_slowpath_fmt+0x4a/0x50 +[ 4.740281] ? insert_work+0x77/0xc0 +[ 4.740355] ? fwtable_write32+0x90/0x130 [i915] +[ 4.740431] __unclaimed_reg_debug+0x44/0x50 [i915] +[ 4.740507] fwtable_read32+0xd8/0x130 [i915] +[ 4.740575] i915_hpd_irq_setup+0xa5/0x100 [i915] +[ 4.740649] intel_hpd_init+0x68/0x80 [i915] +[ 4.740716] i915_driver_load+0xe19/0x1380 [i915] +[ 4.740784] i915_pci_probe+0x32/0x90 [i915] +[ 4.740799] pci_device_probe+0x8b/0xf0 +[ 4.740815] driver_probe_device+0x2b6/0x450 +[ 4.740828] __driver_attach+0xda/0xe0 +[ 4.740841] ? driver_probe_device+0x450/0x450 +[ 4.740853] bus_for_each_dev+0x5b/0x90 +[ 4.740865] driver_attach+0x19/0x20 +[ 4.740878] bus_add_driver+0x166/0x260 +[ 4.740892] driver_register+0x5b/0xd0 +[ 4.740906] ? 0xffffffffa0166000 +[ 4.740920] __pci_register_driver+0x47/0x50 +[ 4.740985] i915_init+0x5c/0x5e [i915] +[ 4.740999] do_one_initcall+0x3e/0x160 +[ 4.741015] ? __vunmap+0x7c/0xc0 +[ 4.741029] ? kmem_cache_alloc+0xcf/0x120 +[ 4.741045] do_init_module+0x55/0x1c4 +[ 4.741060] load_module+0x1f3f/0x25b0 +[ 4.741073] ? __symbol_put+0x40/0x40 +[ 4.741086] ? kernel_read_file+0x100/0x190 +[ 4.741100] SYSC_finit_module+0xbc/0xf0 +[ 4.741112] SyS_finit_module+0x9/0x10 +[ 4.741125] entry_SYSCALL_64_fastpath+0x17/0x98 +[ 4.741135] RIP: 0033:0x7f8559a140f9 +[ 4.741145] RSP: 002b:00007fff7509a3e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 +[ 4.741161] RAX: ffffffffffffffda RBX: 00007f855aba02d1 RCX: 00007f8559a140f9 +[ 4.741172] RDX: 0000000000000000 RSI: 000055b6db0914f0 RDI: 0000000000000011 +[ 4.741183] RBP: 0000000000020000 R08: 0000000000000000 R09: 000000000000000e +[ 4.741193] R10: 0000000000000011 R11: 0000000000000246 R12: 000055b6db0854d0 +[ 4.741204] R13: 000055b6db091150 R14: 0000000000000000 R15: 000055b6db035924 + +v2: Set dev_priv->display_irqs_enabled to true for all platforms other +than vlv/chv that manually control the display power domain. + +Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd") +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97798 +Suggested-by: Ville Syrjälä +Signed-off-by: Chris Wilson +Cc: Lyude +Cc: Daniel Vetter +Cc: Ville Syrjälä +Cc: Hans de Goede +Reviewed-by: Ville Syrjälä +Link: http://patchwork.freedesktop.org/patch/msgid/20170215131547.5064-1-chris@chris-wilson.co.uk +Link: http://patchwork.freedesktop.org/patch/msgid/20170313170231.18633-1-chris@chris-wilson.co.uk +(cherry picked from commit 262fd485ac6b476479f41f00bb104f6a1766ae66) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_irq.c | 10 ++++++++++ + drivers/gpu/drm/i915/intel_hotplug.c | 14 ++++++++------ + 2 files changed, 18 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_irq.c ++++ b/drivers/gpu/drm/i915/i915_irq.c +@@ -4531,6 +4531,16 @@ void intel_irq_init(struct drm_i915_priv + if (!IS_GEN2(dev_priv)) + dev->vblank_disable_immediate = true; + ++ /* Most platforms treat the display irq block as an always-on ++ * power domain. vlv/chv can disable it at runtime and need ++ * special care to avoid writing any of the display block registers ++ * outside of the power domain. We defer setting up the display irqs ++ * in this case to the runtime pm. ++ */ ++ dev_priv->display_irqs_enabled = true; ++ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) ++ dev_priv->display_irqs_enabled = false; ++ + dev->driver->get_vblank_timestamp = i915_get_vblank_timestamp; + dev->driver->get_scanout_position = i915_get_crtc_scanoutpos; + +--- a/drivers/gpu/drm/i915/intel_hotplug.c ++++ b/drivers/gpu/drm/i915/intel_hotplug.c +@@ -219,7 +219,7 @@ static void intel_hpd_irq_storm_reenable + } + } + } +- if (dev_priv->display.hpd_irq_setup) ++ if (dev_priv->display_irqs_enabled && dev_priv->display.hpd_irq_setup) + dev_priv->display.hpd_irq_setup(dev_priv); + spin_unlock_irq(&dev_priv->irq_lock); + +@@ -425,7 +425,7 @@ void intel_hpd_irq_handler(struct drm_i9 + } + } + +- if (storm_detected) ++ if (storm_detected && dev_priv->display_irqs_enabled) + dev_priv->display.hpd_irq_setup(dev_priv); + spin_unlock(&dev_priv->irq_lock); + +@@ -471,10 +471,12 @@ void intel_hpd_init(struct drm_i915_priv + * Interrupt setup is already guaranteed to be single-threaded, this is + * just to make the assert_spin_locked checks happy. + */ +- spin_lock_irq(&dev_priv->irq_lock); +- if (dev_priv->display.hpd_irq_setup) +- dev_priv->display.hpd_irq_setup(dev_priv); +- spin_unlock_irq(&dev_priv->irq_lock); ++ if (dev_priv->display_irqs_enabled && dev_priv->display.hpd_irq_setup) { ++ spin_lock_irq(&dev_priv->irq_lock); ++ if (dev_priv->display_irqs_enabled) ++ dev_priv->display.hpd_irq_setup(dev_priv); ++ spin_unlock_irq(&dev_priv->irq_lock); ++ } + } + + static void i915_hpd_poll_init_work(struct work_struct *work) diff --git a/queue-4.9/drm-i915-stop-using-rp_down_ei-on-baytrail.patch b/queue-4.9/drm-i915-stop-using-rp_down_ei-on-baytrail.patch new file mode 100644 index 00000000000..74304b64adf --- /dev/null +++ b/queue-4.9/drm-i915-stop-using-rp_down_ei-on-baytrail.patch @@ -0,0 +1,177 @@ +From 8f68d591d4765b2e1ce9d916ac7bc5583285c4ad Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Mon, 13 Mar 2017 17:06:17 +0000 +Subject: drm/i915: Stop using RP_DOWN_EI on Baytrail + +From: Chris Wilson + +commit 8f68d591d4765b2e1ce9d916ac7bc5583285c4ad upstream. + +On Baytrail, we manually calculate busyness over the evaluation interval +to avoid issues with miscaluations with RC6 enabled. However, it turns +out that the DOWN_EI interrupt generator is completely bust - it +operates in two modes, continuous or never. Neither of which are +conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just +compute everything from the UP_EI which does seem to correspond to the +desired interval. + +v2: Fixup gen6_rps_pm_mask() as well +v3: Inline vlv_c0_above() to combine the now identical elapsed +calculation for up/down and simplify the threshold testing + +Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail") +Signed-off-by: Chris Wilson +Cc: Mika Kuoppala +Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-1-chris@chris-wilson.co.uk +Reviewed-by: Mika Kuoppala +Link: http://patchwork.freedesktop.org/patch/msgid/20170313170617.31564-1-chris@chris-wilson.co.uk +(cherry picked from commit e0e8c7cb6eb68e9256de2d8cbeb481d3701c05ac) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_drv.h | 2 - + drivers/gpu/drm/i915/i915_irq.c | 73 +++++++++++++++------------------------- + drivers/gpu/drm/i915/intel_pm.c | 5 +- + 3 files changed, 32 insertions(+), 48 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_drv.h ++++ b/drivers/gpu/drm/i915/i915_drv.h +@@ -1225,7 +1225,7 @@ struct intel_gen6_power_mgmt { + unsigned boosts; + + /* manual wa residency calculations */ +- struct intel_rps_ei up_ei, down_ei; ++ struct intel_rps_ei ei; + + /* + * Protects RPS/RC6 register access and PCU communication. +--- a/drivers/gpu/drm/i915/i915_irq.c ++++ b/drivers/gpu/drm/i915/i915_irq.c +@@ -990,68 +990,51 @@ static void vlv_c0_read(struct drm_i915_ + ei->media_c0 = I915_READ(VLV_MEDIA_C0_COUNT); + } + +-static bool vlv_c0_above(struct drm_i915_private *dev_priv, +- const struct intel_rps_ei *old, +- const struct intel_rps_ei *now, +- int threshold) +-{ +- u64 time, c0; +- unsigned int mul = 100; +- +- if (old->cz_clock == 0) +- return false; +- +- if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH) +- mul <<= 8; +- +- time = now->cz_clock - old->cz_clock; +- time *= threshold * dev_priv->czclk_freq; +- +- /* Workload can be split between render + media, e.g. SwapBuffers +- * being blitted in X after being rendered in mesa. To account for +- * this we need to combine both engines into our activity counter. +- */ +- c0 = now->render_c0 - old->render_c0; +- c0 += now->media_c0 - old->media_c0; +- c0 *= mul * VLV_CZ_CLOCK_TO_MILLI_SEC; +- +- return c0 >= time; +-} +- + void gen6_rps_reset_ei(struct drm_i915_private *dev_priv) + { +- vlv_c0_read(dev_priv, &dev_priv->rps.down_ei); +- dev_priv->rps.up_ei = dev_priv->rps.down_ei; ++ memset(&dev_priv->rps.ei, 0, sizeof(dev_priv->rps.ei)); + } + + static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir) + { ++ const struct intel_rps_ei *prev = &dev_priv->rps.ei; + struct intel_rps_ei now; + u32 events = 0; + +- if ((pm_iir & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED)) == 0) ++ if ((pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) == 0) + return 0; + + vlv_c0_read(dev_priv, &now); + if (now.cz_clock == 0) + return 0; + +- if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) { +- if (!vlv_c0_above(dev_priv, +- &dev_priv->rps.down_ei, &now, +- dev_priv->rps.down_threshold)) +- events |= GEN6_PM_RP_DOWN_THRESHOLD; +- dev_priv->rps.down_ei = now; +- } ++ if (prev->cz_clock) { ++ u64 time, c0; ++ unsigned int mul; ++ ++ mul = VLV_CZ_CLOCK_TO_MILLI_SEC * 100; /* scale to threshold% */ ++ if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH) ++ mul <<= 8; ++ ++ time = now.cz_clock - prev->cz_clock; ++ time *= dev_priv->czclk_freq; ++ ++ /* Workload can be split between render + media, ++ * e.g. SwapBuffers being blitted in X after being rendered in ++ * mesa. To account for this we need to combine both engines ++ * into our activity counter. ++ */ ++ c0 = now.render_c0 - prev->render_c0; ++ c0 += now.media_c0 - prev->media_c0; ++ c0 *= mul; + +- if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) { +- if (vlv_c0_above(dev_priv, +- &dev_priv->rps.up_ei, &now, +- dev_priv->rps.up_threshold)) +- events |= GEN6_PM_RP_UP_THRESHOLD; +- dev_priv->rps.up_ei = now; ++ if (c0 > time * dev_priv->rps.up_threshold) ++ events = GEN6_PM_RP_UP_THRESHOLD; ++ else if (c0 < time * dev_priv->rps.down_threshold) ++ events = GEN6_PM_RP_DOWN_THRESHOLD; + } + ++ dev_priv->rps.ei = now; + return events; + } + +@@ -4490,7 +4473,7 @@ void intel_irq_init(struct drm_i915_priv + /* Let's track the enabled rps events */ + if (IS_VALLEYVIEW(dev_priv)) + /* WaGsvRC0ResidencyMethod:vlv */ +- dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; ++ dev_priv->pm_rps_events = GEN6_PM_RP_UP_EI_EXPIRED; + else + dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4940,8 +4940,9 @@ static u32 gen6_rps_pm_mask(struct drm_i + { + u32 mask = 0; + ++ /* We use UP_EI_EXPIRED interupts for both up/down in manual mode */ + if (val > dev_priv->rps.min_freq_softlimit) +- mask |= GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_DOWN_THRESHOLD | GEN6_PM_RP_DOWN_TIMEOUT; ++ mask |= GEN6_PM_RP_UP_EI_EXPIRED | GEN6_PM_RP_DOWN_THRESHOLD | GEN6_PM_RP_DOWN_TIMEOUT; + if (val < dev_priv->rps.max_freq_softlimit) + mask |= GEN6_PM_RP_UP_EI_EXPIRED | GEN6_PM_RP_UP_THRESHOLD; + +@@ -5041,7 +5042,7 @@ void gen6_rps_busy(struct drm_i915_priva + { + mutex_lock(&dev_priv->rps.hw_lock); + if (dev_priv->rps.enabled) { +- if (dev_priv->pm_rps_events & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED)) ++ if (dev_priv->pm_rps_events & GEN6_PM_RP_UP_EI_EXPIRED) + gen6_rps_reset_ei(dev_priv); + I915_WRITE(GEN6_PMINTRMSK, + gen6_rps_pm_mask(dev_priv, dev_priv->rps.cur_freq)); diff --git a/queue-4.9/orangefs-dan-carpenter-influenced-cleanups.patch b/queue-4.9/orangefs-dan-carpenter-influenced-cleanups.patch new file mode 100644 index 00000000000..b2ae1d86506 --- /dev/null +++ b/queue-4.9/orangefs-dan-carpenter-influenced-cleanups.patch @@ -0,0 +1,89 @@ +From 05973c2efb40122f2a9ecde2d065f7ea5068d024 Mon Sep 17 00:00:00 2001 +From: Mike Marshall +Date: Thu, 9 Feb 2017 14:38:50 -0500 +Subject: orangefs: Dan Carpenter influenced cleanups... + +From: Mike Marshall + +commit 05973c2efb40122f2a9ecde2d065f7ea5068d024 upstream. + +This patch is simlar to one Dan Carpenter sent me, cleans +up some return codes and whitespace errors. There was one +place where he thought inserting an error message into +the ring buffer might be too chatty, I hope I convinced him +othewise. As a consolation I changed a truly chatty +error message in another location into a debug message, +system-admins had already yelled at me about that one... + +Signed-off-by: Mike Marshall +Signed-off-by: Greg Kroah-Hartman + +--- + fs/orangefs/devorangefs-req.c | 5 +++-- + fs/orangefs/orangefs-debugfs.c | 15 ++++++++------- + 2 files changed, 11 insertions(+), 9 deletions(-) + +--- a/fs/orangefs/devorangefs-req.c ++++ b/fs/orangefs/devorangefs-req.c +@@ -402,8 +402,9 @@ static ssize_t orangefs_devreq_write_ite + /* remove the op from the in progress hash table */ + op = orangefs_devreq_remove_op(head.tag); + if (!op) { +- gossip_err("WARNING: No one's waiting for tag %llu\n", +- llu(head.tag)); ++ gossip_debug(GOSSIP_DEV_DEBUG, ++ "%s: No one's waiting for tag %llu\n", ++ __func__, llu(head.tag)); + return ret; + } + +--- a/fs/orangefs/orangefs-debugfs.c ++++ b/fs/orangefs/orangefs-debugfs.c +@@ -965,13 +965,13 @@ int orangefs_debugfs_new_client_string(v + int ret; + + ret = copy_from_user(&client_debug_array_string, +- (void __user *)arg, +- ORANGEFS_MAX_DEBUG_STRING_LEN); ++ (void __user *)arg, ++ ORANGEFS_MAX_DEBUG_STRING_LEN); + + if (ret != 0) { + pr_info("%s: CLIENT_STRING: copy_from_user failed\n", + __func__); +- return -EIO; ++ return -EFAULT; + } + + /* +@@ -986,17 +986,18 @@ int orangefs_debugfs_new_client_string(v + */ + client_debug_array_string[ORANGEFS_MAX_DEBUG_STRING_LEN - 1] = + '\0'; +- ++ + pr_info("%s: client debug array string has been received.\n", + __func__); + + if (!help_string_initialized) { + + /* Build a proper debug help string. */ +- if (orangefs_prepare_debugfs_help_string(0)) { ++ ret = orangefs_prepare_debugfs_help_string(0); ++ if (ret) { + gossip_err("%s: no debug help string \n", + __func__); +- return -EIO; ++ return ret; + } + + } +@@ -1009,7 +1010,7 @@ int orangefs_debugfs_new_client_string(v + + help_string_initialized++; + +- return ret; ++ return 0; + } + + int orangefs_debugfs_new_debug(void __user *arg) diff --git a/queue-4.9/orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch b/queue-4.9/orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch new file mode 100644 index 00000000000..a6248c2fe4b --- /dev/null +++ b/queue-4.9/orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch @@ -0,0 +1,38 @@ +From eb68d0324dc4d88ab0d6159bdcd98c247a3a8954 Mon Sep 17 00:00:00 2001 +From: Mike Marshall +Date: Tue, 7 Feb 2017 12:41:02 -0500 +Subject: orangefs: fix buffer size mis-match between kernel space and user space. + +From: Mike Marshall + +commit eb68d0324dc4d88ab0d6159bdcd98c247a3a8954 upstream. + +The deamon through which the kernel module communicates with the userspace +part of Orangefs, the "client-core", sends initialization data to the +kernel module with ioctl. The initialization data was built by the +client-core in a 2k buffer and copy_from_user'd into a 1k buffer +in the kernel module. When more than 1k of initialization data needed +to be sent, some was lost, reducing the usability of the control by which +debug levels are set. This patch sets the kernel side buffer to 2K to +match the userspace side... + +Signed-off-by: Mike Marshall +Signed-off-by: Martin Brandenburg +Signed-off-by: Greg Kroah-Hartman + +--- + fs/orangefs/orangefs-dev-proto.h | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/fs/orangefs/orangefs-dev-proto.h ++++ b/fs/orangefs/orangefs-dev-proto.h +@@ -50,8 +50,7 @@ + * Misc constants. Please retain them as multiples of 8! + * Otherwise 32-64 bit interactions will be messed up :) + */ +-#define ORANGEFS_MAX_DEBUG_STRING_LEN 0x00000400 +-#define ORANGEFS_MAX_DEBUG_ARRAY_LEN 0x00000800 ++#define ORANGEFS_MAX_DEBUG_STRING_LEN 0x00000800 + + /* + * The maximum number of directory entries in a single request is 96. diff --git a/queue-4.9/orangefs-fix-memory-leak-of-string-new-on-exit-path.patch b/queue-4.9/orangefs-fix-memory-leak-of-string-new-on-exit-path.patch new file mode 100644 index 00000000000..27a80a08fd5 --- /dev/null +++ b/queue-4.9/orangefs-fix-memory-leak-of-string-new-on-exit-path.patch @@ -0,0 +1,37 @@ +From 4defb5f912a0ba60e07e91a4b62634814cd99b7f Mon Sep 17 00:00:00 2001 +From: Colin Ian King +Date: Fri, 2 Dec 2016 15:18:06 +0000 +Subject: orangefs: fix memory leak of string 'new' on exit path + +From: Colin Ian King + +commit 4defb5f912a0ba60e07e91a4b62634814cd99b7f upstream. + +allocates string 'new' is not free'd on the exit path when +cdm_element_count <= 0. Fix this by kfree'ing it. + +Fixes CoverityScan CID#1375923 "Resource Leak" + +Signed-off-by: Colin Ian King +Signed-off-by: Mike Marshall +Signed-off-by: Martin Brandenburg +Signed-off-by: Greg Kroah-Hartman + +--- + fs/orangefs/orangefs-debugfs.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/orangefs/orangefs-debugfs.c ++++ b/fs/orangefs/orangefs-debugfs.c +@@ -671,8 +671,10 @@ int orangefs_prepare_debugfs_help_string + */ + cdm_element_count = + orangefs_prepare_cdm_array(client_debug_array_string); +- if (cdm_element_count <= 0) ++ if (cdm_element_count <= 0) { ++ kfree(new); + goto out; ++ } + + for (i = 0; i < cdm_element_count; i++) { + strlcat(new, "\t", string_size); diff --git a/queue-4.9/series b/queue-4.9/series index d1cdfd99721..01e8b567b38 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -1,3 +1,10 @@ drm-i915-gen9-increase-pcode-request-timeout-to-50ms.patch drm-i915-nuke-debug-messages-from-the-pipe-update-critical-section.patch drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch +drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch +drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch +drm-i915-stop-using-rp_down_ei-on-baytrail.patch +drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch +orangefs-fix-memory-leak-of-string-new-on-exit-path.patch +orangefs-dan-carpenter-influenced-cleanups.patch +orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch