linux-kernel - Re: [PATCH bpf-next v5 01/34] mm: memcontrol: use helpers to read page's memcg data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201113002610.GB2934489@carbon.dhcp.thefacebook.com>
Date:   Thu, 12 Nov 2020 16:26:10 -0800
From:   Roman Gushchin <guro@...com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
CC:     <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        <netdev@...r.kernel.org>, Andrii Nakryiko <andrii@...nel.org>,
        Shakeel Butt <shakeelb@...gle.com>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>, <kernel-team@...com>,
        Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH bpf-next v5 01/34] mm: memcontrol: use helpers to read
 page's memcg data

On Fri, Nov 13, 2020 at 09:56:32AM +1100, Stephen Rothwell wrote:
> Hi Roman,
> 
> On Thu, 12 Nov 2020 14:15:10 -0800 Roman Gushchin <guro@...com> wrote:
> >
> > 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.
> >
> .....
> > 
> > To make sure nobody uses a direct access, struct page's
> > mem_cgroup/obj_cgroups is converted to unsigned long memcg_data.
> > 
> > Link: https://lkml.kernel.org/r/20201027001657.3398190-1-guro@fb.com
> > Link: https://lkml.kernel.org/r/20201027001657.3398190-2-guro@fb.com
> > Signed-off-by: Roman Gushchin <guro@...com>
> > Acked-by: Johannes Weiner <hannes@...xchg.org>
> > Reviewed-by: Shakeel Butt <shakeelb@...gle.com>
> > Acked-by: Michal Hocko <mhocko@...e.com>
> > Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> > Signed-off-by: Stephen Rothwell <sfr@...b.auug.org.au>
> 
> What is going on here?  You are taking patches from linux-next and
> submitting them to another maintainer?  Why?

Hi Stephen!

These patches are not intended to be merged through the bpf tree.
They are included into the patchset to make bpf selftests pass and for
informational purposes.
It's written in the cover letter.

> 
> You should not do that from Andrew's tree as it changes/rebases every
> so often ... and you should not have my SOB on there as it is only
> there because that patch is in linux-next i.e. I in the submission
> chain to linux-next - if the patch is to go via some other tree, then
> my SOB should not be there.  (The same may be true for Andrew's SOB.)
> In general you cannot add someone else's SOB to one of your patch
> submissions.

I'm sorry for the confusion.

Maybe I had to just list their titles in the cover letter. Idk what's
the best option for such cross-subsystem dependencies.

Thanks!