From: Michal Hocko <mhocko@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Logan Gunthorpe <logang@deltatee.com>,
David Hildenbrand <david@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-ia64@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-s390 <linux-s390@vger.kernel.org>,
Linux-sh <linux-sh@vger.kernel.org>,
platform-driver-x86@vger.kernel.org,
Linux MM <linux-mm@kvack.org>, Christoph Hellwig <hch@lst.de>,
Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 5/6] mm, memory_hotplug: Provide argument for the pgprot_t in arch_add_memory()
Date: Tue, 10 Dec 2019 11:04:32 +0100 [thread overview]
Message-ID: <20191210100432.GC10404@dhcp22.suse.cz> (raw)
In-Reply-To: <CAPcyv4hpXCZxV5p7WaeGgE7ceujBBa5NOz9Z8fepDHOt6zHO2A@mail.gmail.com>
On Mon 09-12-19 12:43:40, Dan Williams wrote:
> On Mon, Dec 9, 2019 at 12:24 PM Logan Gunthorpe <logang@deltatee.com> wrote:
> >
> >
> >
> > On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> > > On 09.12.19 20:13, Logan Gunthorpe wrote:
[...]
> > >> #ifdef CONFIG_MEMORY_HOTPLUG
> > >> -int arch_add_memory(int nid, u64 start, u64 size,
> > >> +int arch_add_memory(int nid, u64 start, u64 size, pgprot_t prot,
> > >> struct mhp_restrictions *restrictions)
> > >
> > > Can we fiddle that into "struct mhp_restrictions" instead?
> >
> > Yes, if that's what people want, it's pretty trivial to do. I chose not
> > to do it that way because it doesn't get passed down to add_pages() and
> > it's not really a "restriction". If I don't hear any objections, I will
> > do that for v2.
>
> +1 to storing this information alongside the altmap in that structure.
> However, I agree struct mhp_restrictions, with the MHP_MEMBLOCK_API
> flag now gone, has lost all of its "restrictions". How about dropping
> the 'flags' property and renaming the struct to 'struct
> mhp_modifiers'?
Hmm, this email somehow didn't end up in my inbox so I have missed it
before replying.
Well, mhp_modifiers makes some sense and it would reduce the API
proliferation but how do you expect the prot part to be handled?
I really do not want people to think about PAGE_KERNEL or which
protection to use because my experience tells that this will get copied
without much thinking or simply will break with some odd usecases.
So how exactly this would be used?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-12-10 10:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 19:13 [PATCH 0/6] Allow setting caching mode in arch_add_memory() for P2PDMA Logan Gunthorpe
2019-12-09 19:13 ` [PATCH 1/6] x86/mm: Thread pgprot_t through init_memory_mapping() Logan Gunthorpe
2019-12-09 19:13 ` [PATCH 2/6] x86/mm: Introduce _set_memory_prot() Logan Gunthorpe
2019-12-09 19:13 ` [PATCH 3/6] powerpc/mm: Thread pgprot_t through create_section_mapping() Logan Gunthorpe
2019-12-09 19:13 ` [PATCH 4/6] s390/mm: Thread pgprot_t through vmem_add_mapping() Logan Gunthorpe
2019-12-09 19:13 ` [PATCH 5/6] mm, memory_hotplug: Provide argument for the pgprot_t in arch_add_memory() Logan Gunthorpe
2019-12-09 19:23 ` David Hildenbrand
2019-12-09 20:24 ` Logan Gunthorpe
2019-12-09 20:41 ` Michal Hocko
2019-12-09 21:00 ` Dan Williams
2019-12-09 21:27 ` Logan Gunthorpe
2019-12-09 21:24 ` Logan Gunthorpe
2019-12-10 9:56 ` Michal Hocko
2019-12-09 20:43 ` Dan Williams
2019-12-09 20:52 ` David Hildenbrand
2019-12-10 10:04 ` Michal Hocko [this message]
2019-12-10 10:09 ` David Hildenbrand
2019-12-10 10:34 ` Michal Hocko
2019-12-10 11:25 ` David Hildenbrand
2019-12-10 23:52 ` Logan Gunthorpe
2019-12-11 8:37 ` Michal Hocko
2019-12-09 19:13 ` [PATCH 6/6] mm/memremap: Set caching mode for PCI P2PDMA memory to WC Logan Gunthorpe
2019-12-09 20:43 ` [PATCH 0/6] Allow setting caching mode in arch_add_memory() for P2PDMA Christoph Hellwig
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=20191210100432.GC10404@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=hch@lst.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=logang@deltatee.com \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.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 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).