Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • L linux-coresight-backports
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • linux-arm
  • linux-coresight-backports
  • Repository
Switch branch/tag
  • linux-coresight-backports
  • mm
  • slab_common.c
Find file BlameHistoryPermalink
  • Shakeel Butt's avatar
    mm: fix race between kmem_cache destroy, create and deactivate · 92ee383f
    Shakeel Butt authored Jun 14, 2018
    The memcg kmem cache creation and deactivation (SLUB only) is
    asynchronous.  If a root kmem cache is destroyed whose memcg cache is in
    the process of creation or deactivation, the kernel may crash.
    
    Example of one such crash:
    	general protection fault: 0000 [#1] SMP PTI
    	CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp
    	...
    	Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn
    	RIP: 0010:has_cpu_slab
    	...
    	Call Trace:
    	? on_each_cpu_cond
    	__kmem_cache_shrink
    	kmemcg_cache_deact_after_rcu
    	kmemcg_deactivate_workfn
    	process_one_work
    	worker_thread
    	kthread
    	ret_from_fork+0x35/0x40
    
    To fix this race, on root kmem cache destruction, mark the cache as
    dying and flush the workqueue used for memcg kmem cache creation and
    deactivation.  SLUB's memcg kmem cache deactivation also includes RCU
    callback and thus make sure all previous registered RCU callbacks have
    completed as well.
    
    [shakeelb@google.com: handle the RCU callbacks for SLUB deactivation]
      Link: http://lkml.kernel.org/r/20180611192951.195727-1-shakeelb@google.com
    [shakeelb@google.com: add more documentation, rename fields for readability]
      Link: http://lkml.kernel.org/r/20180522201336.196994-1-shakeelb@google.com
    [akpm@linux-foundation.org: fix build, per Shakeel]
    [shakeelb@google.com: v3.  Instead of refcount, flush the workqueue]
      Link: http://lkml.kernel.org/r/20180530001204.183758-1-shakeelb@google.com
    Link: http://lkml.kernel.org/r/20180521174116.171846-1-shakeelb@google.com
    
    
    Signed-off-by: default avatarShakeel Butt <shakeelb@google.com>
    Acked-by: default avatarVladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Greg Thelen <gthelen@google.com>
    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>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Tejun Heo <tj@kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    92ee383f