Files
linux/include/linux
Tejun Heo 3b7b314053 slub: make sysfs file removal asynchronous
Commit bf5eb3de38 ("slub: separate out sysfs_slab_release() from
sysfs_slab_remove()") made slub sysfs file removals synchronous to
kmem_cache shutdown.

Unfortunately, this created a possible ABBA deadlock between slab_mutex
and sysfs draining mechanism triggering the following lockdep warning.

  ======================================================
  [ INFO: possible circular locking dependency detected ]
  4.10.0-test+ #48 Not tainted
  -------------------------------------------------------
  rmmod/1211 is trying to acquire lock:
   (s_active#120){++++.+}, at: [<ffffffff81308073>] kernfs_remove+0x23/0x40

  but task is already holding lock:
   (slab_mutex){+.+.+.}, at: [<ffffffff8120f691>] kmem_cache_destroy+0x41/0x2d0

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #1 (slab_mutex){+.+.+.}:
	 lock_acquire+0xf6/0x1f0
	 __mutex_lock+0x75/0x950
	 mutex_lock_nested+0x1b/0x20
	 slab_attr_store+0x75/0xd0
	 sysfs_kf_write+0x45/0x60
	 kernfs_fop_write+0x13c/0x1c0
	 __vfs_write+0x28/0x120
	 vfs_write+0xc8/0x1e0
	 SyS_write+0x49/0xa0
	 entry_SYSCALL_64_fastpath+0x1f/0xc2

  -> #0 (s_active#120){++++.+}:
	 __lock_acquire+0x10ed/0x1260
	 lock_acquire+0xf6/0x1f0
	 __kernfs_remove+0x254/0x320
	 kernfs_remove+0x23/0x40
	 sysfs_remove_dir+0x51/0x80
	 kobject_del+0x18/0x50
	 __kmem_cache_shutdown+0x3e6/0x460
	 kmem_cache_destroy+0x1fb/0x2d0
	 kvm_exit+0x2d/0x80 [kvm]
	 vmx_exit+0x19/0xa1b [kvm_intel]
	 SyS_delete_module+0x198/0x1f0
	 entry_SYSCALL_64_fastpath+0x1f/0xc2

  other info that might help us debug this:

   Possible unsafe locking scenario:

	 CPU0                    CPU1
	 ----                    ----
    lock(slab_mutex);
				 lock(s_active#120);
				 lock(slab_mutex);
    lock(s_active#120);

   *** DEADLOCK ***

  2 locks held by rmmod/1211:
   #0:  (cpu_hotplug.dep_map){++++++}, at: [<ffffffff810a7877>] get_online_cpus+0x37/0x80
   #1:  (slab_mutex){+.+.+.}, at: [<ffffffff8120f691>] kmem_cache_destroy+0x41/0x2d0

  stack backtrace:
  CPU: 3 PID: 1211 Comm: rmmod Not tainted 4.10.0-test+ #48
  Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
  Call Trace:
   print_circular_bug+0x1be/0x210
   __lock_acquire+0x10ed/0x1260
   lock_acquire+0xf6/0x1f0
   __kernfs_remove+0x254/0x320
   kernfs_remove+0x23/0x40
   sysfs_remove_dir+0x51/0x80
   kobject_del+0x18/0x50
   __kmem_cache_shutdown+0x3e6/0x460
   kmem_cache_destroy+0x1fb/0x2d0
   kvm_exit+0x2d/0x80 [kvm]
   vmx_exit+0x19/0xa1b [kvm_intel]
   SyS_delete_module+0x198/0x1f0
   ? SyS_delete_module+0x5/0x1f0
   entry_SYSCALL_64_fastpath+0x1f/0xc2

It'd be the cleanest to deal with the issue by removing sysfs files
without holding slab_mutex before the rest of shutdown; however, given
the current code structure, it is pretty difficult to do so.

This patch punts sysfs file removal to a work item.  Before commit
bf5eb3de38, the removal was punted to a RCU delayed work item which is
executed after release.  Now, we're punting to a different work item on
shutdown which still maintains the goal removing the sysfs files earlier
when destroying kmem_caches.

Link: http://lkml.kernel.org/r/20170620204512.GI21326@htj.duckdns.org
Fixes: bf5eb3de38 ("slub: separate out sysfs_slab_release() from sysfs_slab_remove()")
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-23 16:15:55 -07:00
..
2017-04-21 10:45:01 -04:00
2016-12-22 22:58:37 -05:00
2017-04-28 18:09:59 -04:00
2017-05-01 14:09:21 -07:00
2017-02-10 15:52:24 -05:00
2017-01-25 13:17:47 -05:00
2017-04-11 14:38:43 -04:00
2017-04-26 23:54:06 -04:00
2017-03-30 09:37:20 +02:00
2016-08-11 09:41:35 -06:00
2017-05-24 12:43:30 -04:00
2017-04-18 20:41:12 +02:00
2016-12-05 19:01:16 -05:00
2016-10-28 08:48:16 -06:00
2017-04-10 17:15:02 +02:00
2017-04-27 05:13:04 -04:00
2016-12-05 19:01:16 -05:00
2017-05-25 13:44:28 -04:00
2017-05-12 15:57:15 -07:00
2016-12-25 17:21:22 +01:00
2017-03-21 10:15:47 +02:00
2017-04-05 18:11:48 +02:00
2017-02-11 20:59:41 -05:00
2016-09-14 09:18:09 -06:00
2017-05-08 17:15:12 -07:00
2017-01-05 15:01:55 -06:00
2017-05-03 15:52:10 -07:00
2016-12-12 18:55:06 -08:00
2016-12-25 17:21:23 +01:00
2017-02-24 17:46:57 -08:00
2016-09-27 12:33:47 +02:00
2016-12-06 11:05:46 +01:00
2017-06-19 21:50:20 +08:00
2017-04-24 14:30:46 -04:00
2017-01-12 16:48:26 -05:00
2016-11-16 18:32:02 -05:00
2017-04-26 13:03:04 -04:00
2016-12-06 10:17:03 +02:00
2016-10-31 16:18:30 -04:00
2016-10-14 11:36:59 -07:00
2016-09-27 21:52:00 -04:00
2017-03-07 14:01:02 -08:00
2017-05-09 16:43:23 +03:00
2017-02-13 21:44:09 -05:00
2017-03-28 08:54:48 +02:00
2017-05-03 15:52:10 -07:00
2017-05-08 17:15:12 -07:00
2017-03-26 15:09:45 +02:00
2017-01-09 16:07:38 -05:00
2016-12-26 23:53:46 -05:00
2017-03-22 12:15:15 -07:00
2017-03-09 15:42:33 +01:00
2017-01-10 18:31:55 -08:00
2017-02-10 16:34:17 +00:00
2017-05-09 16:43:22 +03:00