linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Chen Huang <chenhuang5@huawei.com>
Cc: Roman Gushchin <guro@fb.com>,
	Muchun Song <songmuchun@bytedance.com>,
	Wang Hai <wanghai38@huawei.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	stable@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>,
	Alexei Starovoitov <ast@kernel.org>
Subject: Re: [PATCH 5.10.y 01/11] mm: memcontrol: Use helpers to read page's memcg data
Date: Mon, 16 Aug 2021 10:34:22 +0200	[thread overview]
Message-ID: <YRojDsTAjSnw0jIh@kroah.com> (raw)
In-Reply-To: <20210816072147.3481782-2-chenhuang5@huawei.com>

On Mon, Aug 16, 2021 at 07:21:37AM +0000, Chen Huang wrote:
> From: Roman Gushchin <guro@fb.com>

What is the git commit id of this patch in Linus's tree?

> 
> Patch series "mm: allow mapping accounted kernel pages to userspace", v6.
> 
> Currently a non-slab kernel page which has been charged to a memory cgroup
> can't be mapped to userspace.  The underlying reason is simple: PageKmemcg
> flag is defined as a page type (like buddy, offline, etc), so it takes a
> bit from a page->mapped counter.  Pages with a type set can't be mapped to
> userspace.
> 
> But in general the kmemcg flag has nothing to do with mapping to
> userspace.  It only means that the page has been accounted by the page
> allocator, so it has to be properly uncharged on release.
> 
> Some bpf maps are mapping the vmalloc-based memory to userspace, and their
> memory can't be accounted because of this implementation detail.
> 
> This patchset removes this limitation by moving the PageKmemcg flag into
> one of the free bits of the page->mem_cgroup pointer.  Also it formalizes
> accesses to the page->mem_cgroup and page->obj_cgroups using new helpers,
> adds several checks and removes a couple of obsolete functions.  As the
> result the code became more robust with fewer open-coded bit tricks.
> 
> This patch (of 4):
> 
> Currently there are many open-coded reads of the page->mem_cgroup pointer,
> as well as a couple of read helpers, which are barely used.
> 
> It creates an obstacle on a way to reuse some bits of the pointer for
> storing additional bits of information.  In fact, we already do this for
> slab pages, where the last bit indicates that a pointer has an attached
> vector of objcg pointers instead of a regular memcg pointer.
> 
> This commits uses 2 existing helpers and introduces a new helper to
> converts all read sides to calls of these helpers:
>   struct mem_cgroup *page_memcg(struct page *page);
>   struct mem_cgroup *page_memcg_rcu(struct page *page);
>   struct mem_cgroup *page_memcg_check(struct page *page);
> 
> page_memcg_check() is intended to be used in cases when the page can be a
> slab page and have a memcg pointer pointing at objcg vector.  It does
> check the lowest bit, and if set, returns NULL.  page_memcg() contains a
> VM_BUG_ON_PAGE() check for the page not being a slab page.
> 
> To make sure nobody uses a direct access, struct page's
> mem_cgroup/obj_cgroups is converted to unsigned long memcg_data.
> 
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> Reviewed-by: Shakeel Butt <shakeelb@google.com>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Link: https://lkml.kernel.org/r/20201027001657.3398190-1-guro@fb.com
> Link: https://lkml.kernel.org/r/20201027001657.3398190-2-guro@fb.com
> Link: https://lore.kernel.org/bpf/20201201215900.3569844-2-guro@fb.com
> 
> Conflicts:
> 	mm/memcontrol.c

The "Conflicts:" lines should be removed.

Please fix up the patch series and resubmit.  But note, this seems
really intrusive, are you sure these are all needed?

What UIO driver are you using that is showing problems like this?

thanks,

greg k-h


  reply	other threads:[~2021-08-16  8:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16  7:21 [PATCH 5.10.y 00/11] mm: memcontrol: fix nullptr in __mod_lruvec_page_state() Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 01/11] mm: memcontrol: Use helpers to read page's memcg data Chen Huang
2021-08-16  8:34   ` Greg Kroah-Hartman [this message]
2021-08-16 13:21     ` Chen Huang
2021-08-16 13:35       ` Greg Kroah-Hartman
2021-08-17  1:45         ` Chen Huang
2021-08-17  6:14           ` Greg Kroah-Hartman
2021-08-19 11:43             ` Chen Huang
2021-08-19 14:55               ` Greg Kroah-Hartman
2021-08-18  2:02       ` Roman Gushchin
2021-08-16  7:21 ` [PATCH 5.10.y 02/11] mm: memcontrol/slab: Use helpers to access slab page's memcg_data Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 03/11] mm: Introduce page memcg flags Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 04/11] mm: Convert page kmemcg type to a page memcg flag Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 05/11] mm: memcontrol: introduce obj_cgroup_{un}charge_pages Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 06/11] mm: memcontrol: directly access page->memcg_data in mm/page_alloc.c Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 07/11] mm: memcontrol: change ug->dummy_page only if memcg changed Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 08/11] mm: memcontrol: use obj_cgroup APIs to charge kmem pages Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 09/11] mm: memcontrol: inline __memcg_kmem_{un}charge() into obj_cgroup_{un}charge_pages() Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 10/11] mm: memcontrol: move PageMemcgKmem to the scope of CONFIG_MEMCG_KMEM Chen Huang
2021-08-16  7:21 ` [PATCH 5.10.y 11/11] mm/memcg: fix NULL pointer dereference in memcg_slab_free_hook() Chen Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YRojDsTAjSnw0jIh@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=chenhuang5@huawei.com \
    --cc=guro@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=songmuchun@bytedance.com \
    --cc=stable@vger.kernel.org \
    --cc=wanghai38@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).