From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Borislav Petkov <bp@alien8.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Christopher Lameter <cl@linux.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Elena Reshetova <elena.reshetova@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
James Bottomley <jejb@linux.ibm.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Matthew Wilcox <willy@infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@linux.ibm.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Peter Zijlstra <peterz@infradead.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Shuah Khan <shuah@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tycho Andersen <tycho@tycho.ws>, Will Deacon <will@kernel.org>,
linux-api@vger.kernel.org, linux-arch@vger.ker nel.org,
linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org,
x86@kernel.org
Subject: Re: [PATCH v8 2/9] mmap: make mlock_future_check() global
Date: Tue, 17 Nov 2020 17:58:29 +0200 [thread overview]
Message-ID: <20201117155829.GJ370813@kernel.org> (raw)
In-Reply-To: <d47fdd2e-a8fa-6792-ca8f-e529be76340c@redhat.com>
On Tue, Nov 17, 2020 at 04:09:39PM +0100, David Hildenbrand wrote:
> On 15.11.20 09:26, Mike Rapoport wrote:
> > On Thu, Nov 12, 2020 at 09:15:18PM +0100, David Hildenbrand wrote:
...
> > My thinking was that since secretmem does what mlock() does wrt
> > swapability, it should at least obey the same limit, i.e.
> > RLIMIT_MEMLOCK.
>
> Right, but at least currently, it behaves like any other CMA allocation
> (IIRC they are all unmovable and, therefore, not swappable). In the future,
> if pages would be movable (but not swappable), I guess it might makes more
> sense. I assume we never ever want to swap secretmem.
>
> "man getrlimit" states for RLIMIT_MEMLOCK:
>
> "This is the maximum number of bytes of memory that may be
> locked into RAM. [...] This limit affects
> mlock(2), mlockall(2), and the mmap(2) MAP_LOCKED operation.
> Since Linux 2.6.9, it also affects the shmctl(2) SHM_LOCK op‐
> eration [...]"
>
> So that place has to be updated as well I guess? Otherwise this might come
> as a surprise for users.
Sure.
> >
> > > E.g., we also don‘t
> > > account for gigantic pages - which might be allocated from CMA and are
> > > not swappable.
> > Do you mean gigantic pages in hugetlbfs?
>
> Yes
>
> > It seems to me that hugetlbfs accounting is a completely different
> > story.
>
> I'd say it is right now comparable to secretmem - which is why I though
> similar accounting would make sense.
IMHO, using RLIMIT_MEMLOCK and memcg is a more straightforward way than
a custom cgroup.
And if we'll see a need for additional mechanism, we can always add it.
> --
> Thanks,
>
> David / dhildenb
>
>
--
Sincerely yours,
Mike.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Borislav Petkov <bp@alien8.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Christopher Lameter <cl@linux.com>,
Dan Williams <dan.j.williams@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Elena Reshetova <elena.reshetova@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
James Bottomley <jejb@linux.ibm.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Matthew Wilcox <willy@infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@linux.ibm.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Peter Zijlstra <peterz@infradead.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Shuah Khan <shuah@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tycho Andersen <tycho@tycho.ws>, Will Deacon <will@kernel.org>,
linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org,
x86@kernel.org
Subject: Re: [PATCH v8 2/9] mmap: make mlock_future_check() global
Date: Tue, 17 Nov 2020 17:58:29 +0200 [thread overview]
Message-ID: <20201117155829.GJ370813@kernel.org> (raw)
In-Reply-To: <d47fdd2e-a8fa-6792-ca8f-e529be76340c@redhat.com>
On Tue, Nov 17, 2020 at 04:09:39PM +0100, David Hildenbrand wrote:
> On 15.11.20 09:26, Mike Rapoport wrote:
> > On Thu, Nov 12, 2020 at 09:15:18PM +0100, David Hildenbrand wrote:
...
> > My thinking was that since secretmem does what mlock() does wrt
> > swapability, it should at least obey the same limit, i.e.
> > RLIMIT_MEMLOCK.
>
> Right, but at least currently, it behaves like any other CMA allocation
> (IIRC they are all unmovable and, therefore, not swappable). In the future,
> if pages would be movable (but not swappable), I guess it might makes more
> sense. I assume we never ever want to swap secretmem.
>
> "man getrlimit" states for RLIMIT_MEMLOCK:
>
> "This is the maximum number of bytes of memory that may be
> locked into RAM. [...] This limit affects
> mlock(2), mlockall(2), and the mmap(2) MAP_LOCKED operation.
> Since Linux 2.6.9, it also affects the shmctl(2) SHM_LOCK op‐
> eration [...]"
>
> So that place has to be updated as well I guess? Otherwise this might come
> as a surprise for users.
Sure.
> >
> > > E.g., we also don‘t
> > > account for gigantic pages - which might be allocated from CMA and are
> > > not swappable.
> > Do you mean gigantic pages in hugetlbfs?
>
> Yes
>
> > It seems to me that hugetlbfs accounting is a completely different
> > story.
>
> I'd say it is right now comparable to secretmem - which is why I though
> similar accounting would make sense.
IMHO, using RLIMIT_MEMLOCK and memcg is a more straightforward way than
a custom cgroup.
And if we'll see a need for additional mechanism, we can always add it.
> --
> Thanks,
>
> David / dhildenb
>
>
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
"H. Peter Anvin" <hpa@zytor.com>,
Christopher Lameter <cl@linux.com>, Shuah Khan <shuah@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Elena Reshetova <elena.reshetova@intel.com>,
linux-arch@vger.kernel.org, Tycho Andersen <tycho@tycho.ws>,
linux-nvdimm@lists.01.org, Will Deacon <will@kernel.org>,
x86@kernel.org, Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
James Bottomley <jejb@linux.ibm.com>,
Borislav Petkov <bp@alien8.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>
Subject: Re: [PATCH v8 2/9] mmap: make mlock_future_check() global
Date: Tue, 17 Nov 2020 17:58:29 +0200 [thread overview]
Message-ID: <20201117155829.GJ370813@kernel.org> (raw)
In-Reply-To: <d47fdd2e-a8fa-6792-ca8f-e529be76340c@redhat.com>
On Tue, Nov 17, 2020 at 04:09:39PM +0100, David Hildenbrand wrote:
> On 15.11.20 09:26, Mike Rapoport wrote:
> > On Thu, Nov 12, 2020 at 09:15:18PM +0100, David Hildenbrand wrote:
...
> > My thinking was that since secretmem does what mlock() does wrt
> > swapability, it should at least obey the same limit, i.e.
> > RLIMIT_MEMLOCK.
>
> Right, but at least currently, it behaves like any other CMA allocation
> (IIRC they are all unmovable and, therefore, not swappable). In the future,
> if pages would be movable (but not swappable), I guess it might makes more
> sense. I assume we never ever want to swap secretmem.
>
> "man getrlimit" states for RLIMIT_MEMLOCK:
>
> "This is the maximum number of bytes of memory that may be
> locked into RAM. [...] This limit affects
> mlock(2), mlockall(2), and the mmap(2) MAP_LOCKED operation.
> Since Linux 2.6.9, it also affects the shmctl(2) SHM_LOCK op‐
> eration [...]"
>
> So that place has to be updated as well I guess? Otherwise this might come
> as a surprise for users.
Sure.
> >
> > > E.g., we also don‘t
> > > account for gigantic pages - which might be allocated from CMA and are
> > > not swappable.
> > Do you mean gigantic pages in hugetlbfs?
>
> Yes
>
> > It seems to me that hugetlbfs accounting is a completely different
> > story.
>
> I'd say it is right now comparable to secretmem - which is why I though
> similar accounting would make sense.
IMHO, using RLIMIT_MEMLOCK and memcg is a more straightforward way than
a custom cgroup.
And if we'll see a need for additional mechanism, we can always add it.
> --
> Thanks,
>
> David / dhildenb
>
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
"H. Peter Anvin" <hpa@zytor.com>,
Christopher Lameter <cl@linux.com>, Shuah Khan <shuah@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Elena Reshetova <elena.reshetova@intel.com>,
linux-arch@vger.kernel.org, Tycho Andersen <tycho@tycho.ws>,
linux-nvdimm@lists.01.org, Will Deacon <will@kernel.org>,
x86@kernel.org, Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
James Bottomley <jejb@linux.ibm.com>,
Borislav Petkov <bp@alien8.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>
Subject: Re: [PATCH v8 2/9] mmap: make mlock_future_check() global
Date: Tue, 17 Nov 2020 17:58:29 +0200 [thread overview]
Message-ID: <20201117155829.GJ370813@kernel.org> (raw)
In-Reply-To: <d47fdd2e-a8fa-6792-ca8f-e529be76340c@redhat.com>
On Tue, Nov 17, 2020 at 04:09:39PM +0100, David Hildenbrand wrote:
> On 15.11.20 09:26, Mike Rapoport wrote:
> > On Thu, Nov 12, 2020 at 09:15:18PM +0100, David Hildenbrand wrote:
...
> > My thinking was that since secretmem does what mlock() does wrt
> > swapability, it should at least obey the same limit, i.e.
> > RLIMIT_MEMLOCK.
>
> Right, but at least currently, it behaves like any other CMA allocation
> (IIRC they are all unmovable and, therefore, not swappable). In the future,
> if pages would be movable (but not swappable), I guess it might makes more
> sense. I assume we never ever want to swap secretmem.
>
> "man getrlimit" states for RLIMIT_MEMLOCK:
>
> "This is the maximum number of bytes of memory that may be
> locked into RAM. [...] This limit affects
> mlock(2), mlockall(2), and the mmap(2) MAP_LOCKED operation.
> Since Linux 2.6.9, it also affects the shmctl(2) SHM_LOCK op‐
> eration [...]"
>
> So that place has to be updated as well I guess? Otherwise this might come
> as a surprise for users.
Sure.
> >
> > > E.g., we also don‘t
> > > account for gigantic pages - which might be allocated from CMA and are
> > > not swappable.
> > Do you mean gigantic pages in hugetlbfs?
>
> Yes
>
> > It seems to me that hugetlbfs accounting is a completely different
> > story.
>
> I'd say it is right now comparable to secretmem - which is why I though
> similar accounting would make sense.
IMHO, using RLIMIT_MEMLOCK and memcg is a more straightforward way than
a custom cgroup.
And if we'll see a need for additional mechanism, we can always add it.
> --
> Thanks,
>
> David / dhildenb
>
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-17 15:58 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 15:14 [PATCH v8 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` [PATCH v8 1/9] mm: add definition of PMD_PAGE_ORDER Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` [PATCH v8 2/9] mmap: make mlock_future_check() global Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 17:17 ` David Hildenbrand
2020-11-10 17:17 ` David Hildenbrand
2020-11-10 17:17 ` David Hildenbrand
2020-11-10 17:17 ` David Hildenbrand
2020-11-10 18:06 ` Mike Rapoport
2020-11-10 18:06 ` Mike Rapoport
2020-11-10 18:06 ` Mike Rapoport
2020-11-10 18:06 ` Mike Rapoport
2020-11-12 16:22 ` David Hildenbrand
2020-11-12 16:22 ` David Hildenbrand
2020-11-12 16:22 ` David Hildenbrand
2020-11-12 16:22 ` David Hildenbrand
2020-11-12 19:08 ` Mike Rapoport
2020-11-12 19:08 ` Mike Rapoport
2020-11-12 19:08 ` Mike Rapoport
2020-11-12 19:08 ` Mike Rapoport
2020-11-12 20:15 ` David Hildenbrand
2020-11-12 20:15 ` David Hildenbrand
2020-11-12 20:15 ` David Hildenbrand
2020-11-12 20:15 ` David Hildenbrand
2020-11-15 8:26 ` Mike Rapoport
2020-11-15 8:26 ` Mike Rapoport
2020-11-15 8:26 ` Mike Rapoport
2020-11-15 8:26 ` Mike Rapoport
2020-11-17 15:09 ` David Hildenbrand
2020-11-17 15:09 ` David Hildenbrand
2020-11-17 15:09 ` David Hildenbrand
2020-11-17 15:09 ` David Hildenbrand
2020-11-17 15:58 ` Mike Rapoport [this message]
2020-11-17 15:58 ` Mike Rapoport
2020-11-17 15:58 ` Mike Rapoport
2020-11-17 15:58 ` Mike Rapoport
2020-11-10 15:14 ` [PATCH v8 3/9] set_memory: allow set_direct_map_*_noflush() for multiple pages Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-13 12:26 ` Catalin Marinas
2020-11-13 12:26 ` Catalin Marinas
2020-11-13 12:26 ` Catalin Marinas
2020-11-13 12:26 ` Catalin Marinas
2020-11-10 15:14 ` [PATCH v8 4/9] mm: introduce memfd_secret system call to create "secret" memory areas Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-13 13:58 ` Matthew Wilcox
2020-11-13 13:58 ` Matthew Wilcox
2020-11-13 13:58 ` Matthew Wilcox
2020-11-13 13:58 ` Matthew Wilcox
2020-11-15 8:53 ` Mike Rapoport
2020-11-15 8:53 ` Mike Rapoport
2020-11-15 8:53 ` Mike Rapoport
2020-11-15 8:53 ` Mike Rapoport
2020-11-13 14:06 ` Matthew Wilcox
2020-11-13 14:06 ` Matthew Wilcox
2020-11-13 14:06 ` Matthew Wilcox
2020-11-13 14:06 ` Matthew Wilcox
2020-11-15 8:45 ` Mike Rapoport
2020-11-15 8:45 ` Mike Rapoport
2020-11-15 8:45 ` Mike Rapoport
2020-11-15 8:45 ` Mike Rapoport
2020-11-10 15:14 ` [PATCH v8 5/9] secretmem: use PMD-size pages to amortize direct map fragmentation Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` [PATCH v8 6/9] secretmem: add memcg accounting Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-13 1:35 ` Andrew Morton
2020-11-13 1:35 ` Andrew Morton
2020-11-13 1:35 ` Andrew Morton
2020-11-13 1:35 ` Andrew Morton
2020-11-13 23:42 ` Roman Gushchin
2020-11-13 23:42 ` Roman Gushchin
2020-11-13 23:42 ` Roman Gushchin
2020-11-13 23:42 ` Roman Gushchin
2020-11-13 23:42 ` Roman Gushchin
2020-11-15 9:17 ` Mike Rapoport
2020-11-15 9:17 ` Mike Rapoport
2020-11-15 9:17 ` Mike Rapoport
2020-11-15 9:17 ` Mike Rapoport
2020-11-10 15:14 ` [PATCH v8 7/9] PM: hibernate: disable when there are active secretmem users Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` [PATCH v8 8/9] arch, mm: wire up memfd_secret system call were relevant Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-13 12:25 ` Catalin Marinas
2020-11-13 12:25 ` Catalin Marinas
2020-11-13 12:25 ` Catalin Marinas
2020-11-13 12:25 ` Catalin Marinas
2020-11-15 8:56 ` Mike Rapoport
2020-11-15 8:56 ` Mike Rapoport
2020-11-15 8:56 ` Mike Rapoport
2020-11-15 8:56 ` Mike Rapoport
2020-11-10 15:14 ` [PATCH v8 9/9] secretmem: test: add basic selftest for memfd_secret(2) Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-10 15:14 ` Mike Rapoport
2020-11-12 14:56 ` [PATCH v8 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Mike Rapoport
2020-11-12 14:56 ` Mike Rapoport
2020-11-12 14:56 ` Mike Rapoport
2020-11-12 14:56 ` Mike Rapoport
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=20201117155829.GJ370813@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=elena.reshetova@intel.com \
--cc=hpa@zytor.com \
--cc=jejb@linux.ibm.com \
--cc=kirill@shutemov.name \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.ker \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=mtk.manpages@gmail.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@linux.ibm.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=tycho@tycho.ws \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.