Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1628101
| From | Andrea Reale <ar@linux.vnet.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 4/5] Hot-remove implementation for arm64 |
| Date | 2017-04-21 12:10 +0200 |
| Message-ID | <tyDFL-4xX-1@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <tv7Cp-1vq-13@gated-at.bofh.it> <twa5c-22B-17@gated-at.bofh.it> <txG30-10r-5@gated-at.bofh.it> <txGmm-17N-15@gated-at.bofh.it> <ty0bo-5gm-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi all, thanks for taking the time to comment. Replies in-line. On Wed, Apr 19, 2017 at 08:53:13AM -0700, Laura Abbott wrote: > On 04/18/2017 11:48 AM, Ard Biesheuvel wrote: > >On 18 April 2017 at 19:21, Mark Rutland <mark.rutland@arm.com> wrote: > >>On Fri, Apr 14, 2017 at 03:01:58PM +0100, Andrea Reale wrote: [...] > >> > >> From a quick scan, I see that it's necessary to use pgtable_page_ctor() > >>for pages that will be used for userspace page tables, but it's not > >>clear to me if it's ever necessary for pages used for kernel page > >>tables. > >> > >>If it is, we appear to have a bug on arm64. > >> > >>Laura, Ard, thoughts? > >> > > > >The generic apply_to_page_range() will expect the PTE lock to be > >initialized for page table pages that are not part of init_mm. For > >arm64, that is precisely efi_mm as far as I am aware. For EFI, the > >locking is unnecessary but does no harm (the permissions are set once > >via apply_to_page_range() at boot), so I added this call when adding > >support for strict permissions in EFI rt services mappings. > > > >So I think it is appropriate for create_pgd_mapping() to be in charge > >of calling the ctor(). We simply have no destroy_pgd_mapping() > >counterpart that would be the place for the dtor() call, given that we > >never take down EFI rt services mappi > > >Whether it makes sense or not to lock/unlock in apply_to_page_range() > >is something I did not spend any brain cycles on at the time. > > > > Agreed there shouldn't be a problem right now. I do think the locking is > appropriate in apply_to_page_range given what other functions also get > locked. > > I really wish this were less asymmetrical though since it get hard > to reason about. It looks like hotplug_paging will call the ctor, > so is there an issue with calling hot-remove on memory that was once > hot-added or is that not a concern? > > Thanks, > Laura I think the confusion comes from the fact that, in hotplug_paging, we are passing pgd_pgtable_alloc as the page allocator for __create_pgd_mapping, which always calls the ctor. If I got things right (but, please, correct me if I am wrong), we don't need to get the pte_lock that the ctor gets since - in hotplug - we are adding to init_mm. Moreover, I am just realizing that calling the dtor while hot-removing might create problems when removing memory that *was not* previously hotplugged, as we are calling a dtor on something that was never ctor'ed. Is that what you were hinting at, Laura? Thanks and best regards, Andrea
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 0/5] Memory hotplug support for arm64 - complete patchset Andrea Reale <ar@linux.vnet.ibm.com> - 2017-04-11 17:00 +0200
[PATCH 5/5] Add "remove" probe driver for memory hot-remove Andrea Reale <ar@linux.vnet.ibm.com> - 2017-04-11 17:00 +0200
[PATCH 2/5] arm64: defconfig: enable MEMORY_HOTPLUG config options Andrea Reale <ar@linux.vnet.ibm.com> - 2017-04-11 17:00 +0200
[PATCH 4/5] Hot-remove implementation for arm64 Andrea Reale <ar@linux.vnet.ibm.com> - 2017-04-11 17:00 +0200
Re: [PATCH 4/5] Hot-remove implementation for arm64 Mark Rutland <mark.rutland@arm.com> - 2017-04-11 19:20 +0200
Re: [PATCH 4/5] Hot-remove implementation for arm64 Andrea Reale <ar@linux.vnet.ibm.com> - 2017-04-14 16:10 +0200
Re: [PATCH 4/5] Hot-remove implementation for arm64 Mark Rutland <mark.rutland@arm.com> - 2017-04-18 20:30 +0200
Re: [PATCH 4/5] Hot-remove implementation for arm64 Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-04-18 20:50 +0200
Re: [PATCH 4/5] Hot-remove implementation for arm64 Laura Abbott <labbott@redhat.com> - 2017-04-19 18:00 +0200
Re: [PATCH 4/5] Hot-remove implementation for arm64 Andrea Reale <ar@linux.vnet.ibm.com> - 2017-04-21 12:10 +0200
Re: [PATCH 4/5] Hot-remove implementation for arm64 Andrea Reale <ar@linux.vnet.ibm.com> - 2017-04-21 12:10 +0200
[PATCH 1/5] arm64: memory-hotplug: Add MEMORY_HOTPLUG, MEMORY_HOTREMOVE, MEMORY_PROBE Andrea Reale <ar@linux.vnet.ibm.com> - 2017-04-11 17:00 +0200
[PATCH 3/5] Memory hotplug support for arm64 platform (v2) Andrea Reale <ar@linux.vnet.ibm.com> - 2017-04-11 17:00 +0200
Re: [PATCH 3/5] Memory hotplug support for arm64 platform (v2) Mark Rutland <mark.rutland@arm.com> - 2017-04-11 18:00 +0200
Re: [PATCH 3/5] Memory hotplug support for arm64 platform (v2) Maciej Bielski <m.bielski@virtualopensystems.com> - 2017-04-24 18:50 +0200
Re: [PATCH 3/5] Memory hotplug support for arm64 platform (v2) Maciej Bielski <m.bielski@virtualopensystems.com> - 2017-04-24 19:40 +0200
csiph-web