Files
linux/include/linux
Muchun Song 02f4bbefca mm: kmem: add lockdep assertion to obj_cgroup_memcg
obj_cgroup_memcg() is supposed to safe to prevent the returned memory
cgroup from being freed only when the caller is holding the rcu read lock
or objcg_lock or cgroup_mutex.  It is very easy to ignore thoes conditions
when users call some upper APIs which call obj_cgroup_memcg() internally
like mem_cgroup_from_slab_obj() (See the link below).  So it is better to
add lockdep assertion to obj_cgroup_memcg() to find those issues ASAP.

Because there is no user of obj_cgroup_memcg() holding objcg_lock to make
the returned memory cgroup safe, do not add objcg_lock assertion (We
should export objcg_lock if we really want to do).  Additionally, this is
some internal implementation detail of memcg and should not be accessible
outside memcg code.

Some users like __mem_cgroup_uncharge() do not care the lifetime of the
returned memory cgroup, which just want to know if the folio is charged to
a memory cgroup, therefore, they do not need to hold the needed locks.  In
which case, introduce a new helper folio_memcg_charged() to do this. 
Compare it to folio_memcg(), it could eliminate a memory access of
objcg->memcg for kmem, actually, a really small gain.

[songmuchun@bytedance.com: fix split_page_memcg()]
  Link: https://lkml.kernel.org/r/20240819080415.44964-1-songmuchun@bytedance.com
Link: https://lore.kernel.org/all/20240718083607.42068-1-songmuchun@bytedance.com/
Link: https://lkml.kernel.org/r/20240814093415.17634-1-songmuchun@bytedance.com
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-09-01 20:26:14 -07:00
..
2024-03-19 16:11:42 +01:00
2024-05-27 13:39:51 +02:00
2024-04-24 11:06:26 -07:00
2024-04-25 20:55:49 -07:00
2024-09-01 20:25:49 -07:00
2024-05-02 20:35:57 +02:00
2024-03-11 15:37:23 -07:00
2024-04-29 16:28:07 -07:00
2024-07-03 19:29:59 -07:00
2024-07-08 01:51:05 -06:00
2024-06-24 18:29:20 +02:00
2024-04-23 09:03:37 +09:00
2024-06-11 12:57:49 -05:00
2024-03-12 23:08:29 -07:00
2024-05-27 11:08:31 +02:00
2024-04-15 16:03:24 -04:00
2024-08-12 22:03:27 +02:00
2024-05-19 14:36:17 -07:00
2024-07-03 19:29:52 -07:00
2024-05-27 16:50:03 +02:00
2024-09-01 20:26:10 -07:00
2024-06-24 22:24:56 -07:00
2024-09-01 20:26:03 -07:00
2024-07-03 19:30:23 -07:00
2024-06-05 19:19:26 -07:00
2024-05-03 10:44:42 +01:00
2024-07-10 12:14:54 -07:00
2024-07-31 09:57:18 -07:00
2024-07-08 13:47:27 -04:00
2024-06-24 22:25:02 -07:00
2024-03-26 11:07:20 -07:00
2024-06-28 09:52:05 +02:00
2024-09-01 20:26:04 -07:00
2024-03-13 12:53:53 -07:00
2024-03-13 12:53:53 -07:00
2024-07-10 17:52:47 +02:00
2024-04-02 18:03:32 -07:00
2024-03-08 12:05:10 +01:00
2024-04-03 09:59:38 +01:00
2024-04-09 10:53:44 +02:00
2024-07-02 18:59:33 -07:00
2024-05-04 18:57:21 +02:00
2024-07-10 07:59:03 +02:00
2024-04-08 11:49:02 +01:00
2024-05-06 12:05:00 +02:00
2024-04-07 02:42:36 -04:00
2024-09-01 20:25:43 -07:00
2024-08-15 22:16:14 -07:00
2024-06-24 18:16:44 +01:00
2024-04-25 20:55:48 -07:00