Unnamed repository; edit this file 'description' to name the repository. https://gitea.privatedns.org/xavi/android_kernel_m2note/atom?h=o-8.1 2018-01-02T15:07:50+00:00 2018-01-02T15:07:50+00:00 Joe Thornber ejt@redhat.com 2014-04-03T15:16:44+00:00 urn:sha1:ae2e52bade3debb8a35c671cd40fb643bc5db6a4 When suspending a cache the policy is walked and the individual policy hints written to the metadata via sync_metadata(). This led to this lock order: policy->lock cache_metadata->root_lock When loading the cache target the policy is populated while the metadata lock is held: cache_metadata->root_lock policy->lock Fix this potential lock-inversion (ABBA) deadlock in sync_metadata() by ensuring the cache_metadata root_lock is held whilst all the hints are written, rather than being repeatedly locked while policy->lock is held (as was the case with each callout that policy_walk_mappings() made to the old save_hint() method). Found by turning on the CONFIG_PROVE_LOCKING ("Lock debugging: prove locking correctness") build option. However, it is not clear how the LOCKDEP reported paths can lead to a deadlock since the two paths, suspending a target and loading a target, never occur at the same time. But that doesn't mean the same lock-inversion couldn't have occurred elsewhere. Reported-by: Marian Csontos <mcsontos@redhat.com> Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Joe Maples <joe@frap129.org> 2016-08-15T02:19:42+00:00 Meizu OpenSource patchwork@meizu.com 2016-08-15T02:19:42+00:00 urn:sha1:d2e1446d81725c351dc73a03b397ce043fb18452