<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote">> On Tue, Mar 21, 2017 at 5:00 PM, Stephen Rothwell <<a href="mailto:sfr@canb.auug.org.au">sfr@canb.auug.org.au</a>> wrote:</div><div class="gmail_quote">> Hi Dave,</div><div class="gmail_quote">> </div><div class="gmail_quote">> Today's linux-next merge of the drm tree got a conflict in:</div><div class="gmail_quote">> </div><div class="gmail_quote">>   drivers/gpu/drm/i915/i915_gem_shrinker.c</div><div class="gmail_quote">> </div><div class="gmail_quote">> between commit:</div><div class="gmail_quote">> </div><div class="gmail_quote">>   3d3d18f086cd ("drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)")</div><div class="gmail_quote">> </div><div class="gmail_quote">> from the drm-intel-fixes tree and commit:</div><div class="gmail_quote">> </div><div class="gmail_quote">>   519d52498156 ("drm/i915: i915_gem_shrink_all() needs an awake device")</div><div class="gmail_quote">> </div><div class="gmail_quote">> from the drm tree.</div><div class="gmail_quote">> </div><div class="gmail_quote">> I fixed it up (see below) and can carry the fix as necessary. This</div><div class="gmail_quote">> is now fixed as far as linux-next is concerned, but any non trivial</div><div class="gmail_quote">> conflicts should be mentioned to your upstream maintainer when your tree</div><div class="gmail_quote">> is submitted for merging.  You may also want to consider cooperating</div><div class="gmail_quote">> with the maintainer of the conflicting tree to minimise any particularly</div><div class="gmail_quote">> complex conflicts.</div><div class="gmail_quote">> </div><div class="gmail_quote">> --</div><div class="gmail_quote">> Cheers,</div><div class="gmail_quote">> Stephen Rothwell</div><div class="gmail_quote">> </div><div class="gmail_quote">> diff --cc drivers/gpu/drm/i915/i915_gem_shrinker.c</div><div class="gmail_quote">> index d5d2b4c6ed38,006a8b908f77..000000000000</div><div class="gmail_quote">> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c</div><div class="gmail_quote">> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c</div><div class="gmail_quote">> @@@ -263,7 -264,9 +264,9 @@@ unsigned long i915_gem_shrink_all(struc</div><div class="gmail_quote">>                                 I915_SHRINK_BOUND |</div><div class="gmail_quote">>                                 I915_SHRINK_UNBOUND |</div><div class="gmail_quote">>                                 I915_SHRINK_ACTIVE);</div><div class="gmail_quote">> +       intel_runtime_pm_put(dev_priv);</div><div class="gmail_quote">> +</div><div class="gmail_quote">>  -      rcu_barrier(); /* wait until our RCU delayed slab frees are completed */</div><div class="gmail_quote">>  +      synchronize_rcu(); /* wait for our earlier RCU delayed slab frees */</div><div class="gmail_quote"><br></div><div class="gmail_quote">Unless I am really confused, the RCU delayed slab frees are via call_rcu().</div><div class="gmail_quote">This means that synchronize_rcu() is -not- guaranteed to wait on them.</div><div class="gmail_quote">For example, CPU 0 might be making its way through a pile of callbacks,</div><div class="gmail_quote">including some RCU delayed slab free callbacks.  If there are enough</div><div class="gmail_quote">callbacks, it could take CPU 0 several grace periods to work through the</div><div class="gmail_quote">backlog.  CPU 1 might have no callbacks queued, and might execute the</div><div class="gmail_quote">above code.  Now synchronize_rcu() will wait for a grace period, but only</div><div class="gmail_quote">one, and not necessarily for CPU 0's backlog to drain.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I do not believe that the above fix is safe.</div><div class="gmail_quote"><br></div><div class="gmail_quote">>         return freed;</div><div class="gmail_quote">>   }</div><div class="gmail_quote">> </div></div></div></div>