* Re: Looking for architecture papers
From: Segher Boessenkool @ 2018-10-04 8:46 UTC (permalink / raw)
To: Raz; +Cc: linuxppc-dev
In-Reply-To: <CAPB=Z-pLCkXcsAXD5YWt5pwPzFzJrdZsdDye_bZjE0-ea-Ur6A@mail.gmail.com>
On Thu, Oct 04, 2018 at 10:41:13AM +0300, Raz wrote:
> Frankly, the more I read the more perplexed I get. For example,
> according to BOOK III-S, chapter 3,
> the MSR bits are differ from the ones described in
> arch/powerpc/include/asm/reg.h.
> Bit zero, is LE, but in the book it is 64-bit mode.
LE is bit 63, the least significant bit, value 0x0000000000000001.
SF is bit 0, the most significant bit, value 0x8000000000000000.
Some people wrongly start counting at the end, calling the least
significant bit "bit 0". That isn't its name.
Segher
^ permalink raw reply
* Re: [PATCH V3 0/2] mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region
From: Aneesh Kumar K.V @ 2018-10-04 8:34 UTC (permalink / raw)
To: akpm, Michal Hocko, Alexey Kardashevskiy, mpe
Cc: linux-mm, linuxppc-dev, linux-kernel
In-Reply-To: <20180918115839.22154-1-aneesh.kumar@linux.ibm.com>
Hi Andrew,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> ppc64 use CMA area for the allocation of guest page table (hash page table). We won't
> be able to start guest if we fail to allocate hash page table. We have observed
> hash table allocation failure because we failed to migrate pages out of CMA region
> because they were pinned. This happen when we are using VFIO. VFIO on ppc64 pins
> the entire guest RAM. If the guest RAM pages get allocated out of CMA region, we
> won't be able to migrate those pages. The pages are also pinned for the lifetime of the
> guest.
>
> Currently we support migration of non-compound pages. With THP and with the addition of
> hugetlb migration we can end up allocating compound pages from CMA region. This
> patch series add support for migrating compound pages. The first path adds the helper
> get_user_pages_cma_migrate() which pin the page making sure we migrate them out of
> CMA region before incrementing the reference count.
>
> Aneesh Kumar K.V (2):
> mm: Add get_user_pages_cma_migrate
> powerpc/mm/iommu: Allow migration of cma allocated pages during
> mm_iommu_get
>
> arch/powerpc/mm/mmu_context_iommu.c | 120 ++++++++-----------------
> include/linux/hugetlb.h | 2 +
> include/linux/migrate.h | 3 +
> mm/hugetlb.c | 4 +-
> mm/migrate.c | 132 ++++++++++++++++++++++++++++
> 5 files changed, 174 insertions(+), 87 deletions(-)
Any feedback on this.
-aneesh
^ permalink raw reply
* Re: [RFC PATCH v3 1/7] book3s/64: avoid circular header inclusion in mmu-hash.h
From: Christophe LEROY @ 2018-10-04 8:32 UTC (permalink / raw)
To: Aneesh Kumar K.V, Nicholas Piggin
Cc: linux-kernel, Paul Mackerras, aneesh.kumar, linuxppc-dev
In-Reply-To: <1516af9d-bb0b-4a2c-71f8-554a3f830281@linux.ibm.com>
Le 04/10/2018 à 10:23, Aneesh Kumar K.V a écrit :
> On 10/4/18 1:50 PM, Christophe LEROY wrote:
>>
>>
>> Le 03/10/2018 à 06:24, Nicholas Piggin a écrit :
>>> On Mon, 1 Oct 2018 12:30:19 +0000 (UTC)
>>> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>
>>>> When activating CONFIG_THREAD_INFO_IN_TASK, linux/sched.h
>>>> includes asm/current.h. This generates a circular dependency.
>>>> To avoid that, asm/processor.h shall not be included in mmu-hash.h
>>>>
>>>> In order to do that, this patch moves into a new header called
>>>> asm/task_size.h the information from asm/processor.h requires by
>>>> mmu-hash.h
>>>
>>> Doesn't look like you use this header in 32-bit code. Put task_size.h
>>> in asm/64/ maybe?
>>
>> There is no asm/64/ dir at the time being, only book3s/64/ and nohash/64/
>>
>> I'm thinking about leaving it in asm/ but renaming it task_size_user64.h
>>
>
> Quiet a lot of that is book3s 64 specifi because we have there.
>
> #if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_64K_PAGES)
> /*
> * Max value currently used:
> */
We have an #if / #else
#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_64K_PAGES)
/*
* Max value currently used:
*/
#define TASK_SIZE_USER64 TASK_SIZE_4PB
#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_128TB
#define TASK_CONTEXT_SIZE TASK_SIZE_512TB
#else
#define TASK_SIZE_USER64 TASK_SIZE_64TB
#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_64TB
/*
* We don't need to allocate extended context ids for 4K page size, because
* we limit the max effective address on this config to 64TB.
*/
#define TASK_CONTEXT_SIZE TASK_SIZE_64TB
#endif
And processor .h derives several other consts applying to both BOOK3S64
et BOOK3E64 from that.
And arch/powerpc/mm/pgtable-book3e.c has:
BUILD_BUG_ON(TASK_SIZE_USER64 > PGTABLE_RANGE);
Christophe
^ permalink raw reply
* Re: [RFC PATCH v3 1/7] book3s/64: avoid circular header inclusion in mmu-hash.h
From: Aneesh Kumar K.V @ 2018-10-04 8:23 UTC (permalink / raw)
To: Christophe LEROY, Nicholas Piggin
Cc: linux-kernel, Paul Mackerras, aneesh.kumar, linuxppc-dev
In-Reply-To: <bed3d788-6633-6eef-30ea-bdfa374e0216@c-s.fr>
On 10/4/18 1:50 PM, Christophe LEROY wrote:
>
>
> Le 03/10/2018 à 06:24, Nicholas Piggin a écrit :
>> On Mon, 1 Oct 2018 12:30:19 +0000 (UTC)
>> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>
>>> When activating CONFIG_THREAD_INFO_IN_TASK, linux/sched.h
>>> includes asm/current.h. This generates a circular dependency.
>>> To avoid that, asm/processor.h shall not be included in mmu-hash.h
>>>
>>> In order to do that, this patch moves into a new header called
>>> asm/task_size.h the information from asm/processor.h requires by
>>> mmu-hash.h
>>
>> Doesn't look like you use this header in 32-bit code. Put task_size.h
>> in asm/64/ maybe?
>
> There is no asm/64/ dir at the time being, only book3s/64/ and nohash/64/
>
> I'm thinking about leaving it in asm/ but renaming it task_size_user64.h
>
Quiet a lot of that is book3s 64 specifi because we have there.
#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_64K_PAGES)
/*
* Max value currently used:
*/
-aneesh
^ permalink raw reply
* Re: [RFC PATCH v3 1/7] book3s/64: avoid circular header inclusion in mmu-hash.h
From: Christophe LEROY @ 2018-10-04 8:20 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linux-kernel, Paul Mackerras, aneesh.kumar, linuxppc-dev
In-Reply-To: <20181003142400.490fd38a@roar.ozlabs.ibm.com>
Le 03/10/2018 à 06:24, Nicholas Piggin a écrit :
> On Mon, 1 Oct 2018 12:30:19 +0000 (UTC)
> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>> When activating CONFIG_THREAD_INFO_IN_TASK, linux/sched.h
>> includes asm/current.h. This generates a circular dependency.
>> To avoid that, asm/processor.h shall not be included in mmu-hash.h
>>
>> In order to do that, this patch moves into a new header called
>> asm/task_size.h the information from asm/processor.h requires by
>> mmu-hash.h
>
> Doesn't look like you use this header in 32-bit code. Put task_size.h
> in asm/64/ maybe?
There is no asm/64/ dir at the time being, only book3s/64/ and nohash/64/
I'm thinking about leaving it in asm/ but renaming it task_size_user64.h
Christophe
>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
>
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>> arch/powerpc/include/asm/book3s/64/mmu-hash.h | 2 +-
>> arch/powerpc/include/asm/processor.h | 34 +---------------------
>> arch/powerpc/include/asm/task_size.h | 42 +++++++++++++++++++++++++++
>> arch/powerpc/kvm/book3s_hv_hmi.c | 1 +
>> 4 files changed, 45 insertions(+), 34 deletions(-)
>> create mode 100644 arch/powerpc/include/asm/task_size.h
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> index bbeaf6adf93c..7788e35f19f0 100644
>> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> @@ -23,7 +23,7 @@
>> */
>> #include <asm/book3s/64/pgtable.h>
>> #include <asm/bug.h>
>> -#include <asm/processor.h>
>> +#include <asm/task_size.h>
>> #include <asm/cpu_has_feature.h>
>>
>> /*
>> diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
>> index 350c584ca179..353879db3e98 100644
>> --- a/arch/powerpc/include/asm/processor.h
>> +++ b/arch/powerpc/include/asm/processor.h
>> @@ -101,40 +101,8 @@ void release_thread(struct task_struct *);
>> #endif
>>
>> #ifdef CONFIG_PPC64
>> -/*
>> - * 64-bit user address space can have multiple limits
>> - * For now supported values are:
>> - */
>> -#define TASK_SIZE_64TB (0x0000400000000000UL)
>> -#define TASK_SIZE_128TB (0x0000800000000000UL)
>> -#define TASK_SIZE_512TB (0x0002000000000000UL)
>> -#define TASK_SIZE_1PB (0x0004000000000000UL)
>> -#define TASK_SIZE_2PB (0x0008000000000000UL)
>> -/*
>> - * With 52 bits in the address we can support
>> - * upto 4PB of range.
>> - */
>> -#define TASK_SIZE_4PB (0x0010000000000000UL)
>>
>> -/*
>> - * For now 512TB is only supported with book3s and 64K linux page size.
>> - */
>> -#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_64K_PAGES)
>> -/*
>> - * Max value currently used:
>> - */
>> -#define TASK_SIZE_USER64 TASK_SIZE_4PB
>> -#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_128TB
>> -#define TASK_CONTEXT_SIZE TASK_SIZE_512TB
>> -#else
>> -#define TASK_SIZE_USER64 TASK_SIZE_64TB
>> -#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_64TB
>> -/*
>> - * We don't need to allocate extended context ids for 4K page size, because
>> - * we limit the max effective address on this config to 64TB.
>> - */
>> -#define TASK_CONTEXT_SIZE TASK_SIZE_64TB
>> -#endif
>> +#include <asm/task_size.h>
>>
>> /*
>> * 32-bit user address space is 4GB - 1 page
>> diff --git a/arch/powerpc/include/asm/task_size.h b/arch/powerpc/include/asm/task_size.h
>> new file mode 100644
>> index 000000000000..ca45638617b0
>> --- /dev/null
>> +++ b/arch/powerpc/include/asm/task_size.h
>> @@ -0,0 +1,42 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _ASM_POWERPC_TASK_SIZE_H
>> +#define _ASM_POWERPC_TASK_SIZE_H
>> +
>> +#ifdef CONFIG_PPC64
>> +/*
>> + * 64-bit user address space can have multiple limits
>> + * For now supported values are:
>> + */
>> +#define TASK_SIZE_64TB (0x0000400000000000UL)
>> +#define TASK_SIZE_128TB (0x0000800000000000UL)
>> +#define TASK_SIZE_512TB (0x0002000000000000UL)
>> +#define TASK_SIZE_1PB (0x0004000000000000UL)
>> +#define TASK_SIZE_2PB (0x0008000000000000UL)
>> +/*
>> + * With 52 bits in the address we can support
>> + * upto 4PB of range.
>> + */
>> +#define TASK_SIZE_4PB (0x0010000000000000UL)
>> +
>> +/*
>> + * For now 512TB is only supported with book3s and 64K linux page size.
>> + */
>> +#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_64K_PAGES)
>> +/*
>> + * Max value currently used:
>> + */
>> +#define TASK_SIZE_USER64 TASK_SIZE_4PB
>> +#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_128TB
>> +#define TASK_CONTEXT_SIZE TASK_SIZE_512TB
>> +#else
>> +#define TASK_SIZE_USER64 TASK_SIZE_64TB
>> +#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_64TB
>> +/*
>> + * We don't need to allocate extended context ids for 4K page size, because
>> + * we limit the max effective address on this config to 64TB.
>> + */
>> +#define TASK_CONTEXT_SIZE TASK_SIZE_64TB
>> +#endif
>> +
>> +#endif /* CONFIG_PPC64 */
>> +#endif /* _ASM_POWERPC_TASK_SIZE_H */
>> diff --git a/arch/powerpc/kvm/book3s_hv_hmi.c b/arch/powerpc/kvm/book3s_hv_hmi.c
>> index e3f738eb1cac..64b5011475c7 100644
>> --- a/arch/powerpc/kvm/book3s_hv_hmi.c
>> +++ b/arch/powerpc/kvm/book3s_hv_hmi.c
>> @@ -24,6 +24,7 @@
>> #include <linux/compiler.h>
>> #include <asm/paca.h>
>> #include <asm/hmi.h>
>> +#include <asm/processor.h>
>>
>> void wait_for_subcore_guest_exit(void)
>> {
>> --
>> 2.13.3
>>
^ permalink raw reply
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: David Hildenbrand @ 2018-10-04 8:13 UTC (permalink / raw)
To: Michal Hocko
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Dave Hansen, Heiko Carstens, linux-mm, Paul Mackerras,
H. Peter Anvin, Stephen Rothwell, Rashmica Gupta, Dan Williams,
linux-s390, Michael Neuling, Stephen Hemminger, Yoshinori Sato,
linux-acpi, Ingo Molnar, xen-devel, Len Brown, Pavel Tatashin,
Rob Herring, mike.travis@hpe.com, Haiyang Zhang,
Jonathan Neuschäfer, Nicholas Piggin, Martin Schwidefsky,
Jérôme Glisse, Mike Rapoport, Borislav Petkov,
Andy Lutomirski, Boris Ostrovsky, Joonsoo Kim, Oscar Salvador,
Juergen Gross, Tony Luck, Andrew Morton, Mathieu Malaterre,
Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel, Fenghua Yu,
Mauricio Faria de Oliveira, Thomas Gleixner, Philippe Ombredanne,
Joe Perches, devel, Vitaly Kuznetsov, linuxppc-dev,
Kirill A. Shutemov
In-Reply-To: <20181004061938.GB22173@dhcp22.suse.cz>
On 04/10/2018 08:19, Michal Hocko wrote:
> On Wed 03-10-18 19:14:05, David Hildenbrand wrote:
>> On 03/10/2018 16:34, Vitaly Kuznetsov wrote:
>>> Dave Hansen <dave.hansen@linux.intel.com> writes:
>>>
>>>> On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote:
>>>>> It is more than just memmaps (e.g. forking udev process doing memory
>>>>> onlining also needs memory) but yes, the main idea is to make the
>>>>> onlining synchronous with hotplug.
>>>>
>>>> That's a good theoretical concern.
>>>>
>>>> But, is it a problem we need to solve in practice?
>>>
>>> Yes, unfortunately. It was previously discovered that when we try to
>>> hotplug tons of memory to a low memory system (this is a common scenario
>>> with VMs) we end up with OOM because for all new memory blocks we need
>>> to allocate page tables, struct pages, ... and we need memory to do
>>> that. The userspace program doing memory onlining also needs memory to
>>> run and in case it prefers to fork to handle hundreds of notfifications
>>> ... well, it may get OOMkilled before it manages to online anything.
>>>
>>> Allocating all kernel objects from the newly hotplugged blocks would
>>> definitely help to manage the situation but as I said this won't solve
>>> the 'forking udev' problem completely (it will likely remain in
>>> 'extreme' cases only. We can probably work around it by onlining with a
>>> dedicated process which doesn't do memory allocation).
>>>
>>
>> I guess the problem is even worse. We always have two phases
>>
>> 1. add memory - requires memory allocation
>> 2. online memory - might require memory allocations e.g. for slab/slub
>>
>> So if we just added memory but don't have sufficient memory to start a
>> user space process to trigger onlining, then we most likely also don't
>> have sufficient memory to online the memory right away (in some scenarios).
>>
>> We would have to allocate all new memory for 1 and 2 from the memory to
>> be onlined. I guess the latter part is less trivial.
>>
>> So while onlining the memory from the kernel might make things a little
>> more robust, we would still have the chance for OOM / onlining failing.
>
> Yes, _theoretically_. Is this a practical problem for reasonable
> configurations though? I mean, this will never be perfect and we simply
> cannot support all possible configurations. We should focus on
> reasonable subset of them. From my practical experience the vast
> majority of memory is consumed by memmaps (roughly 1.5%). That is not a
> lot but I agree that allocating that from the zone normal and off node
> is not great. Especially the second part which is noticeable for whole
> node hotplug.
>
> I have a feeling that arguing about fork not able to proceed or OOMing
> for the memory hotplug is a bit of a stretch and a sign a of
> misconfiguration.
>
Just to rephrase, I have the same opinion. Something is already messed
up if we cannot even fork anymore. We will have OOM already all over the
place before/during/after forking.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: David Hildenbrand @ 2018-10-04 8:12 UTC (permalink / raw)
To: Michal Hocko, Vitaly Kuznetsov
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Dave Hansen, Heiko Carstens, linux-mm, Paul Mackerras,
H. Peter Anvin, Stephen Rothwell, Rashmica Gupta, Dan Williams,
linux-s390, Michael Neuling, Stephen Hemminger, Yoshinori Sato,
linux-acpi, Ingo Molnar, xen-devel, Len Brown, Pavel Tatashin,
Rob Herring, mike.travis@hpe.com, Haiyang Zhang,
Jonathan Neuschäfer, Nicholas Piggin, Martin Schwidefsky,
Jérôme Glisse, Mike Rapoport, Borislav Petkov,
Andy Lutomirski, Boris Ostrovsky, Andrew Morton, Oscar Salvador,
Juergen Gross, Tony Luck, Mathieu Malaterre, Greg Kroah-Hartman,
Rafael J. Wysocki, linux-kernel, Fenghua Yu,
Mauricio Faria de Oliveira, Thomas Gleixner, Philippe Ombredanne,
Joe Perches, devel, Joonsoo Kim, linuxppc-dev, Kirill A. Shutemov
In-Reply-To: <20181003142444.GJ4714@dhcp22.suse.cz>
On 03/10/2018 16:24, Michal Hocko wrote:
> On Wed 03-10-18 15:52:24, Vitaly Kuznetsov wrote:
> [...]
>>> As David said some of the memory cannot be onlined without further steps
>>> (e.g. when it is standby as David called it) and then I fail to see how
>>> eBPF help in any way.
>>
>> and also, we can fight till the end of days here trying to come up with
>> an onlining solution which would work for everyone and eBPF would move
>> this decision to distro level.
>
> The point is that there is _no_ general onlining solution. This is
> basically policy which belongs to the userspace.
>
Vitalys point was that this policy is to be formulated by user space via
eBPF and handled by the kernel. So the work of formulating the policy
would still have to be done by user space.
I guess the only problem this would partially solve is onlining of
memory failing as we can no longer fork in user space. Just as you said,
I also think this is rather some serious misconfiguration. We will
already most probably have other applications triggering OOM already.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: Looking for architecture papers
From: Raz @ 2018-10-04 7:41 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev
In-Reply-To: <87sh1nk70y.fsf@concordia.ellerman.id.au>
Frankly, the more I read the more perplexed I get. For example,
according to BOOK III-S, chapter 3,
the MSR bits are differ from the ones described in
arch/powerpc/include/asm/reg.h.
Bit zero, is LE, but in the book it is 64-bit mode.
Would someone be kind to explain what I do not understand?
Thank you
On Wed, Oct 3, 2018 at 7:07 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Raz <raziebe@gmail.com> writes:
>
> > Hello
> >
> > I want to learn about powerpc architecture, mainly hypervisor and
> > partioning. I download the books (1,2, and 3 ) but I feel it lacks
> > a lot of information. Are there other books ?
>
> The ISA describes how the CPU works to allow you to implement a
> hypervisor, but it doesn't describe any of the HV/Kernel APIs.
>
> That's mostly covered in "LoPAPR":
>
> https://members.openpowerfoundation.org/document/dl/469
>
>
> Although that's not been updated for Power9.
>
> cheers
^ permalink raw reply
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: David Hildenbrand @ 2018-10-04 7:48 UTC (permalink / raw)
To: Dave Hansen, linux-mm
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Heiko Carstens, Pavel Tatashin, Michal Hocko, Paul Mackerras,
H. Peter Anvin, Rashmica Gupta, K. Y. Srinivasan, Boris Ostrovsky,
linux-s390, Michael Neuling, Stephen Hemminger, Yoshinori Sato,
linux-acpi, Ingo Molnar, xen-devel, Rob Herring, Len Brown,
Fenghua Yu, Stephen Rothwell, mike.travis@hpe.com, Haiyang Zhang,
Dan Williams, Jonathan Neuschäfer, Nicholas Piggin,
Joe Perches, Jérôme Glisse, Mike Rapoport,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner, Joonsoo Kim,
Oscar Salvador, Juergen Gross, Tony Luck, Mathieu Malaterre,
Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
Mauricio Faria de Oliveira, Philippe Ombredanne,
Martin Schwidefsky, devel, Andrew Morton, linuxppc-dev,
Kirill A. Shutemov
In-Reply-To: <05493150-5e4e-30bd-f772-0c6d88240030@linux.intel.com>
On 01/10/2018 18:24, Dave Hansen wrote:
>> How should a policy in user space look like when new memory gets added
>> - on s390x? Not onlining paravirtualized memory is very wrong.
>
> Because we're going to balloon it away in a moment anyway?
No, rether somebody wanted this VM to have more memory, so it should use
it - basically what HyperV or XEN also do. (in contrast to the concept
of standby memory on s390).
> > We have auto-onlining. Why isn't that being used on s390?
Do you mean the sys parameter? How would that help?
>
>
>> So the type of memory is very important here to have in user space.
>> Relying on checks like "isS390()", "isKVMGuest()" or "isHyperVGuest()"
>> to decide whether to online memory and how to online memory is wrong.
>> Only some specific memory types (which I call "normal") are to be
>> handled by user space.
>>
>> For the other ones, we exactly know what to do:
>> - standby? don't online
>
> I think you're horribly conflating the software desire for what the stae
> should be and the hardware itself.
Agreed, user space should be able to configure it.
>
>>> As for the OOM issues, that sounds like something we need to fix by
>>> refusing to do (or delaying) hot-add operations once we consume too much
>>> ZONE_NORMAL from memmap[]s rather than trying to indirectly tell
>>> userspace to hurry thing along.
>>
>> That is a moving target and doing that automatically is basically
>> impossible.
>
> Nah. We know how much metadata we've allocated. We know how much
> ZONE_NORMAL we are eating. We can *easily* add something to
> add_memory() that just sleeps until the ratio is not out-of-whack.
>
>> You can add a lot of memory to the movable zone and
>> everything is fine. Suddenly a lot of processes are started - boom.
>> MOVABLE should only every be used if you expect an unplug. And for
>> paravirtualized devices, a "typical" unplug does not exist.
>
> No, it's more complicated than that. People use MOVABLE, for instance,
> to allow more consistent huge page allocations. It's certainly not just
> hot-remove.
>
As noted in the other thread, that's a good point. We have to allow to
make a decision in user space.
I agree to your initial proposal to distinguish "standby" from
"auto-online". It would allow to have sane defaults in user space.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: David Hildenbrand @ 2018-10-04 7:40 UTC (permalink / raw)
To: Michal Hocko
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Dave Hansen, Heiko Carstens, linux-mm, Pavel Tatashin,
Paul Mackerras, H. Peter Anvin, Rashmica Gupta, K. Y. Srinivasan,
Boris Ostrovsky, linux-s390, Michael Neuling, Stephen Hemminger,
Yoshinori Sato, linux-acpi, Ingo Molnar, xen-devel, Rob Herring,
Len Brown, Fenghua Yu, Stephen Rothwell, mike.travis@hpe.com,
Haiyang Zhang, Dan Williams, Jonathan Neuschäfer,
Nicholas Piggin, Joe Perches, Jérôme Glisse,
Mike Rapoport, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
Joonsoo Kim, Oscar Salvador, Juergen Gross, Tony Luck,
Mathieu Malaterre, Greg Kroah-Hartman, Rafael J. Wysocki,
linux-kernel, Mauricio Faria de Oliveira, Philippe Ombredanne,
Martin Schwidefsky, devel, Andrew Morton, linuxppc-dev,
Kirill A. Shutemov
In-Reply-To: <20181004062811.GC22173@dhcp22.suse.cz>
On 04/10/2018 08:28, Michal Hocko wrote:
> On Wed 03-10-18 19:00:29, David Hildenbrand wrote:
> [...]
>> Let me rephrase: You state that user space has to make the decision and
>> that user should be able to set/reconfigure rules. That is perfectly fine.
>>
>> But then we should give user space access to sufficient information to
>> make a decision. This might be the type of memory as we learned (what
>> some part of this patch proposes), but maybe later more, e.g. to which
>> physical device memory belongs (e.g. to hotplug it all movable or all
>> normal) ...
>
> I am pretty sure that user knows he/she wants to use ballooning in
> HyperV or Xen, or that the memory hotplug should be used as a "RAS"
> feature to allow add and remove DIMMs for reliability. Why shouldn't we
> have a package to deploy an appropriate set of udev rules for each of
> those usecases? I am pretty sure you need some other plumbing to enable
> them anyway (e.g. RAS would require to have movable_node kernel
> parameters, ballooning a kernel module etc.).
>
> Really, one udev script to rule them all will simply never work.
>
I am on your side. We will need multiple ones. But we need sane
defaults. And a default rule will always exist. And users will expect
that the defaults somewhat match their expectation unless they really
have some special use cases.
All I am saying is, again, that if user space is to make decisions, it
should get sufficient information to make sane decision. And in my point
of view, the type of memory allows us to make these decision and to
provide a "single udev script to rule them all" with sane defaults.
I at least think the distinction between "auto-online" and "standby" is
required (what Dave suggested).
The we can make a simple rule
if (auto-online memory) {
if (virtual environment) {
"online"
} else {
"online_movable"
}
}
/* standby memory not onlined as default */
We are able to provide sane defaults.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: Michal Hocko @ 2018-10-04 6:28 UTC (permalink / raw)
To: David Hildenbrand
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Dave Hansen, Heiko Carstens, linux-mm, Pavel Tatashin,
Paul Mackerras, H. Peter Anvin, Rashmica Gupta, K. Y. Srinivasan,
Boris Ostrovsky, linux-s390, Michael Neuling, Stephen Hemminger,
Yoshinori Sato, linux-acpi, Ingo Molnar, xen-devel, Rob Herring,
Len Brown, Fenghua Yu, Stephen Rothwell, mike.travis@hpe.com,
Haiyang Zhang, Dan Williams, Jonathan Neuschäfer,
Nicholas Piggin, Joe Perches, Jérôme Glisse,
Mike Rapoport, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
Joonsoo Kim, Oscar Salvador, Juergen Gross, Tony Luck,
Mathieu Malaterre, Greg Kroah-Hartman, Rafael J. Wysocki,
linux-kernel, Mauricio Faria de Oliveira, Philippe Ombredanne,
Martin Schwidefsky, devel, Andrew Morton, linuxppc-dev,
Kirill A. Shutemov
In-Reply-To: <9fef1f7d-2d7c-03f1-00e3-5fa657eda019@redhat.com>
On Wed 03-10-18 19:00:29, David Hildenbrand wrote:
[...]
> Let me rephrase: You state that user space has to make the decision and
> that user should be able to set/reconfigure rules. That is perfectly fine.
>
> But then we should give user space access to sufficient information to
> make a decision. This might be the type of memory as we learned (what
> some part of this patch proposes), but maybe later more, e.g. to which
> physical device memory belongs (e.g. to hotplug it all movable or all
> normal) ...
I am pretty sure that user knows he/she wants to use ballooning in
HyperV or Xen, or that the memory hotplug should be used as a "RAS"
feature to allow add and remove DIMMs for reliability. Why shouldn't we
have a package to deploy an appropriate set of udev rules for each of
those usecases? I am pretty sure you need some other plumbing to enable
them anyway (e.g. RAS would require to have movable_node kernel
parameters, ballooning a kernel module etc.).
Really, one udev script to rule them all will simply never work.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH] powerpc: Add doorbell tracepoints
From: Anton Blanchard @ 2018-10-04 6:23 UTC (permalink / raw)
To: benh, paulus, mpe, npiggin, ruscur; +Cc: linuxppc-dev
When analysing sources of OS jitter, I noticed that doorbells cannot be
traced.
Signed-off-by: Anton Blanchard <anton@ozlabs.org>
---
arch/powerpc/include/asm/trace.h | 16 ++++++++++++++++
arch/powerpc/kernel/dbell.c | 3 +++
2 files changed, 19 insertions(+)
diff --git a/arch/powerpc/include/asm/trace.h b/arch/powerpc/include/asm/trace.h
index d018e8602694..2f1f8cd7b6c8 100644
--- a/arch/powerpc/include/asm/trace.h
+++ b/arch/powerpc/include/asm/trace.h
@@ -54,6 +54,22 @@ DEFINE_EVENT(ppc64_interrupt_class, timer_interrupt_exit,
TP_ARGS(regs)
);
+#ifdef CONFIG_PPC_DOORBELL
+DEFINE_EVENT(ppc64_interrupt_class, doorbell_entry,
+
+ TP_PROTO(struct pt_regs *regs),
+
+ TP_ARGS(regs)
+);
+
+DEFINE_EVENT(ppc64_interrupt_class, doorbell_exit,
+
+ TP_PROTO(struct pt_regs *regs),
+
+ TP_ARGS(regs)
+);
+#endif
+
#ifdef CONFIG_PPC_PSERIES
extern int hcall_tracepoint_regfunc(void);
extern void hcall_tracepoint_unregfunc(void);
diff --git a/arch/powerpc/kernel/dbell.c b/arch/powerpc/kernel/dbell.c
index b6fe883b1016..5ec3b3835925 100644
--- a/arch/powerpc/kernel/dbell.c
+++ b/arch/powerpc/kernel/dbell.c
@@ -18,6 +18,7 @@
#include <asm/dbell.h>
#include <asm/irq_regs.h>
#include <asm/kvm_ppc.h>
+#include <asm/trace.h>
#ifdef CONFIG_SMP
@@ -81,6 +82,7 @@ void doorbell_exception(struct pt_regs *regs)
struct pt_regs *old_regs = set_irq_regs(regs);
irq_enter();
+ trace_doorbell_entry(regs);
ppc_msgsync();
@@ -91,6 +93,7 @@ void doorbell_exception(struct pt_regs *regs)
smp_ipi_demux_relaxed(); /* already performed the barrier */
+ trace_doorbell_exit(regs);
irq_exit();
set_irq_regs(old_regs);
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: Michal Hocko @ 2018-10-04 6:19 UTC (permalink / raw)
To: David Hildenbrand
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Dave Hansen, Heiko Carstens, linux-mm, Paul Mackerras,
H. Peter Anvin, Stephen Rothwell, Rashmica Gupta, Dan Williams,
linux-s390, Michael Neuling, Stephen Hemminger, Yoshinori Sato,
linux-acpi, Ingo Molnar, xen-devel, Len Brown, Pavel Tatashin,
Rob Herring, mike.travis@hpe.com, Haiyang Zhang,
Jonathan Neuschäfer, Nicholas Piggin, Martin Schwidefsky,
Jérôme Glisse, Mike Rapoport, Borislav Petkov,
Andy Lutomirski, Boris Ostrovsky, Joonsoo Kim, Oscar Salvador,
Juergen Gross, Tony Luck, Andrew Morton, Mathieu Malaterre,
Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel, Fenghua Yu,
Mauricio Faria de Oliveira, Thomas Gleixner, Philippe Ombredanne,
Joe Perches, devel, Vitaly Kuznetsov, linuxppc-dev,
Kirill A. Shutemov
In-Reply-To: <06a35970-e478-18f8-eae6-4022925a5192@redhat.com>
On Wed 03-10-18 19:14:05, David Hildenbrand wrote:
> On 03/10/2018 16:34, Vitaly Kuznetsov wrote:
> > Dave Hansen <dave.hansen@linux.intel.com> writes:
> >
> >> On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote:
> >>> It is more than just memmaps (e.g. forking udev process doing memory
> >>> onlining also needs memory) but yes, the main idea is to make the
> >>> onlining synchronous with hotplug.
> >>
> >> That's a good theoretical concern.
> >>
> >> But, is it a problem we need to solve in practice?
> >
> > Yes, unfortunately. It was previously discovered that when we try to
> > hotplug tons of memory to a low memory system (this is a common scenario
> > with VMs) we end up with OOM because for all new memory blocks we need
> > to allocate page tables, struct pages, ... and we need memory to do
> > that. The userspace program doing memory onlining also needs memory to
> > run and in case it prefers to fork to handle hundreds of notfifications
> > ... well, it may get OOMkilled before it manages to online anything.
> >
> > Allocating all kernel objects from the newly hotplugged blocks would
> > definitely help to manage the situation but as I said this won't solve
> > the 'forking udev' problem completely (it will likely remain in
> > 'extreme' cases only. We can probably work around it by onlining with a
> > dedicated process which doesn't do memory allocation).
> >
>
> I guess the problem is even worse. We always have two phases
>
> 1. add memory - requires memory allocation
> 2. online memory - might require memory allocations e.g. for slab/slub
>
> So if we just added memory but don't have sufficient memory to start a
> user space process to trigger onlining, then we most likely also don't
> have sufficient memory to online the memory right away (in some scenarios).
>
> We would have to allocate all new memory for 1 and 2 from the memory to
> be onlined. I guess the latter part is less trivial.
>
> So while onlining the memory from the kernel might make things a little
> more robust, we would still have the chance for OOM / onlining failing.
Yes, _theoretically_. Is this a practical problem for reasonable
configurations though? I mean, this will never be perfect and we simply
cannot support all possible configurations. We should focus on
reasonable subset of them. From my practical experience the vast
majority of memory is consumed by memmaps (roughly 1.5%). That is not a
lot but I agree that allocating that from the zone normal and off node
is not great. Especially the second part which is noticeable for whole
node hotplug.
I have a feeling that arguing about fork not able to proceed or OOMing
for the memory hotplug is a bit of a stretch and a sign a of
misconfiguration.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] powerpc: Add doorbell tracepoints
From: Anton Blanchard @ 2018-10-04 6:16 UTC (permalink / raw)
To: Russell Currey; +Cc: paulus, linuxppc-dev, npiggin
In-Reply-To: <32bd00f1b50f77f7c58972d72e8459a72317204b.camel@russell.cc>
Hi Russell,
> snowpatch builds failed for this patch on all 64-bit configurations
> (ppc64e, ppc64 and ppc64le) with the following:
Thanks! Stupid bug on my part, need more quilt ref. Update to follow.
Anton
> arch/powerpc/kernel/dbell.c:85:9: error: undefined identifier
> 'trace_doorbell_entry'
> arch/powerpc/kernel/dbell.c:96:9: error: undefined identifier
> 'trace_doorbell_exit'
> ./arch/powerpc/include/asm/spinlock.h:171:9: warning: context
> imbalance in 'key_user_put' - unexpected unlock
> arch/powerpc/kernel/dbell.c: In function 'doorbell_exception':
> arch/powerpc/kernel/dbell.c:85:2: error: implicit declaration of
> function 'trace_doorbell_entry'; did you mean 'trace_irq_entry'?
> [-Werror=implicit- function-declaration]
> trace_doorbell_entry(regs);
> ^~~~~~~~~~~~~~~~~~~~
> trace_irq_entry
> arch/powerpc/kernel/dbell.c:96:2: error: implicit declaration of
> function 'trace_doorbell_exit'; did you mean 'trace_irq_exit'?
> [-Werror=implicit-function- declaration]
> trace_doorbell_exit(regs);
> ^~~~~~~~~~~~~~~~~~~
> trace_irq_exit
> cc1: all warnings being treated as errors
> scripts/Makefile.build:305: recipe for target
> 'arch/powerpc/kernel/dbell.o' failed make[1]: ***
> [arch/powerpc/kernel/dbell.o] Error 1 Makefile:1060: recipe for
> target 'arch/powerpc/kernel' failed
>
> So does something else need to check for CONFIG_PPC_DOORBELL maybe?
>
> You can see the failures here:
> http://patchwork.ozlabs.org/patch/978088/ - output in build_new.log
> (I know it's not pretty in there yet, you can search for "Error 1" to
> find the build failure)
>
> - Russell
>
>
^ permalink raw reply
* Re: [v3] powerpc: wire up memtest
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Jonathan Corbet
Cc: linuxppc-dev, linux-kernel, linux-doc
In-Reply-To: <b3ca67442a924acb9f4a3409264914ca9feaf7d5.1538148840.git.christophe.leroy@c-s.fr>
On Fri, 2018-09-28 at 15:39:20 UTC, Christophe Leroy wrote:
> Add call to early_memtest() so that kernel compiled with
> CONFIG_MEMTEST really perform memtest at startup when requested
> via 'memtest' boot parameter.
>
> Tested-by: Daniel Axtens <dja@axtens.net>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d90fe2acd9b2900790da01354dbca4
cheers
^ permalink raw reply
* Re: [1/2] powerpc/pseries: Fix DTL buffer registration
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: linuxppc-dev
In-Reply-To: <d0f92a8bcbf03087c7aa7a98d9865d5ab91a9b39.1538035689.git.naveen.n.rao@linux.vnet.ibm.com>
On Thu, 2018-09-27 at 08:10:57 UTC, "Naveen N. Rao" wrote:
> When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set, we register the DTL
> buffer for a cpu when the associated file under powerpc/dtl in debugfs
> is opened. When doing so, we need to set the size of the buffer being
> registered in the second u32 word of the buffer. This needs to be in big
> endian, but we are not doing the conversion resulting in the below error
> showing up in dmesg:
>
> dtl_start: DTL registration for cpu 0 (hw 0) failed with -4
>
> Fix this in the obvious manner.
>
> Fixes: 7c105b63bd98 ("powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option.")
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/db787af1b8a6b4be428ee2ea7d409d
cheers
^ permalink raw reply
* Re: [v5,1/2] powerpc/32: add stack protector support
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <8e81b0647fea15e533a73ad4e9063c059fdfc6df.1537987712.git.christophe.leroy@c-s.fr>
On Thu, 2018-09-27 at 07:05:53 UTC, Christophe Leroy wrote:
> This functionality was tentatively added in the past
> (commit 6533b7c16ee5 ("powerpc: Initial stack protector
> (-fstack-protector) support")) but had to be reverted
> (commit f2574030b0e3 ("powerpc: Revert the initial stack
> protector support") because of GCC implementing it differently
> whether it had been built with libc support or not.
>
> Now, GCC offers the possibility to manually set the
> stack-protector mode (global or tls) regardless of libc support.
>
> This time, the patch selects HAVE_STACKPROTECTOR only if
> -mstack-protector-guard=tls is supported by GCC.
>
> On PPC32, as register r2 points to current task_struct at
> all time, the stack_canary located inside task_struct can be
> used directly by using the following GCC options:
> -mstack-protector-guard=tls
> -mstack-protector-guard-reg=r2
> -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary))
>
> The protector is disabled for prom_init and bootx_init as
> it is too early to handle it properly.
>
> $ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT
> [ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64
> [ 134.943666]
> [ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835
> [ 134.963380] Call Trace:
> [ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable)
> [ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260
> [ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64
> [ 134.982769] [c6615e00] [ffffffff] 0xffffffff
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c3ff2a5193fa61b1b284cfb1d79628
cheers
^ permalink raw reply
* Re: powerpc/tm: Reformat comments
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: Michael Neuling; +Cc: Michael Neuling, linuxppc-dev
In-Reply-To: <20180927050515.25644-1-mikey@neuling.org>
On Thu, 2018-09-27 at 05:05:15 UTC, Michael Neuling wrote:
> The comments in this file don't conform to the coding style so take
> them to "Comment Formatting Re-Education Camp"
>
> Suggested-by: Michael "Camp Drill Sargent" Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/306b1c06172424d496656ae5b668eb
cheers
^ permalink raw reply
* Re: [1/1] powerpc/config: Enable CONFIG_PRINTK_TIME
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: Petr Vorel, linuxppc-dev; +Cc: Petr Vorel
In-Reply-To: <20180926141056.5111-1-pvorel@suse.cz>
On Wed, 2018-09-26 at 14:10:56 UTC, Petr Vorel wrote:
> for 64bit configs which use for CONFIG_LOG_BUF_SHIFT the same
> or higher value than the default (currently 17).
>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/5bd9b4445d1f02639cb5e5b151ef40
cheers
^ permalink raw reply
* Re: powerpc/64s: consolidate MCE counter increment.
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: Michal Suchanek, Benjamin Herrenschmidt, Paul Mackerras,
Murilo Opsfelder Araujo, Cyril Bur, Eric W. Biederman,
Nicholas Piggin, Michael Neuling, Anshuman Khandual,
Michal Suchanek, Haren Myneni, Mahesh Salgaonkar, Balbir Singh,
linuxppc-dev, linux-kernel
In-Reply-To: <20180926122430.13924-1-msuchanek@suse.de>
On Wed, 2018-09-26 at 12:24:30 UTC, Michal Suchanek wrote:
> The code in machine_check_exception excludes 64s hvmode when
> incrementing the MCE counter only to call opal_machine_check to
> increment it specifically for this case.
>
> Remove the exclusion and special case.
>
> Fixes: a43c1590426c ("powerpc/pseries: Flush SLB contents on SLB MCE
> errors.")
>
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8a03e81cb14712f986c5d5fa42a30f
cheers
^ permalink raw reply
* Re: powerpc: xive: Move a dereference below a NULL test
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: zhong jiang, paulus, akpm
Cc: fthain, linuxppc-dev, linux-kernel, fbarrat, npiggin
In-Reply-To: <1537963772-15309-1-git-send-email-zhongjiang@huawei.com>
On Wed, 2018-09-26 at 12:09:32 UTC, zhong jiang wrote:
> It is safe to move dereference below a NULL test.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cd5ff94577e004e0a4457e70d0ef3a
cheers
^ permalink raw reply
* Re: powerpc/powernv: Mark function as __noreturn
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: Breno Leitao, npiggin
In-Reply-To: <1537885773-18564-1-git-send-email-leitao@debian.org>
On Tue, 2018-09-25 at 14:29:33 UTC, Breno Leitao wrote:
> There is a mismatch between function pnv_platform_error_reboot() definition
> and declaration regarding function modifiers. In the declaration part, it
> contains the function attribute __noreturn, while function definition
> itself lacks it.
>
> This was reported by sparse tool as an error:
>
> arch/powerpc/platforms/powernv/opal.c:538:6: error: symbol 'pnv_platform_error_reboot' redeclared with different type (originally declared at arch/powerpc/platforms/powernv/powernv.h:11) - different modifiers
>
> I checked and the function is already being considered as being 'noreturn'
> by the compiler, thus, I understand this patch does not change any code
> being generated.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/62dea077f56728979e40a741c8a094
cheers
^ permalink raw reply
* Re: [-next] powerpc: Remove duplicated include from pci_32.c
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: YueHaibing, Benjamin Herrenschmidt, Paul Mackerras, Al Viro,
Paul Burton, Sinan Kaya, Mathieu Malaterre, Andrew Morton,
Stephen Rothwell, Mike Rapoport, Christophe Leroy
Cc: kernel-janitors, YueHaibing, linuxppc-dev, linux-kernel
In-Reply-To: <1537690328-77353-1-git-send-email-yuehaibing@huawei.com>
On Sun, 2018-09-23 at 08:12:08 UTC, YueHaibing wrote:
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/01b9870ea614518d48b6d2c787284b
cheers
^ permalink raw reply
* Re: [V3, 1/6] powerpc/mm/book3s: Update pmd_present to look at _PAGE_PRESENT bit
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus; +Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20180920180947.17893-1-aneesh.kumar@linux.ibm.com>
On Thu, 2018-09-20 at 18:09:42 UTC, "Aneesh Kumar K.V" wrote:
> With this patch we use 0x8000000000000000UL (_PAGE_PRESENT) to indicate a valid
> pgd/pud/pmd entry. We also switch the p**_present() to look at this bit.
>
> With pmd_present, we have a special case. We need to make sure we consider a
> pmd marked invalid during THP split as present. Right now we clear the
> _PAGE_PRESENT bit during a pmdp_invalidate. Inorder to consider this special
> case we add a new pte bit _PAGE_INVALID (mapped to _RPAGE_SW0). This bit is
> only used with _PAGE_PRESENT cleared. Hence we are not really losing a pte bit
> for this special case. pmd_present is also updated to look at _PAGE_INVALID.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/da7ad366b497f5fc1d4a416f168057
cheers
^ permalink raw reply
* Re: [v2] powerpc/traps: merge unrecoverable_exception() and nonrecoverable_exception()
From: Michael Ellerman @ 2018-10-04 6:14 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <86e85efc4b5a90523de6e964c5cef8858eb1177d.1537884465.git.christophe.leroy@c-s.fr>
On Tue, 2018-09-25 at 14:10:04 UTC, Christophe Leroy wrote:
> PPC32 uses nonrecoverable_exception() while PPC64 uses
> unrecoverable_exception().
>
> Both functions are doing almost the same thing.
>
> This patch removes nonrecoverable_exception()
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/51423a9c9b09352bea1c53b8324db7
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox