* Re: Build regressions/improvements in v4.17-rc1
From: Geert Uytterhoeven @ 2018-08-08 12:26 UTC (permalink / raw)
To: Michael Ellerman
Cc: Andrew Morton, Linux Kernel Mailing List, Dan Williams,
linuxppc-dev, Nicholas Piggin
In-Reply-To: <87lg9hb12y.fsf@concordia.ellerman.id.au>
On Wed, Aug 8, 2018 at 12:32 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Also I haven't been seeing this in my local builds because I have:
>
> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y
>
> So I guess we need to work out why that's interfering with section
> mismatch analysis.
One other common case of missing section mismatch warnings is when some
versions of the compiler inline the called function, while other versions don't.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC 0/4] Virtio uses DMA API for all devices
From: Christoph Hellwig @ 2018-08-08 12:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christoph Hellwig, Michael S. Tsirkin, Will Deacon,
Anshuman Khandual, virtualization, linux-kernel, linuxppc-dev,
aik, robh, joe, elfring, david, jasowang, mpe, linuxram, haren,
paulus, srikar, robin.murphy, jean-philippe.brucker, marc.zyngier
In-Reply-To: <4b596883892b5cb5560bef26fcd249e7107173ac.camel@kernel.crashing.org>
On Wed, Aug 08, 2018 at 08:07:49PM +1000, Benjamin Herrenschmidt wrote:
> Qemu virtio bypasses that iommu when the VIRTIO_F_IOMMU_PLATFORM flag
> is not set (default) but there's nothing in the device-tree to tell the
> guest about this since it's a violation of our pseries architecture, so
> we just rely on Linux virtio "knowing" that it happens. It's a bit
> yucky but that's now history...
That is ugly as hell, but it is how virtio works everywhere, so nothing
special so far.
> Essentially pseries "architecturally" does not have the concept of not
> having an iommu in the way and qemu violates that architecture today.
>
> (Remember it comes from pHyp, our priorietary HV, which we are somewhat
> mimmicing here).
It shouldnt be too hard to have a dt property that communicates this,
should it?
> So if we always set VIRTIO_F_IOMMU_PLATFORM, it *will* force all virtio
> through that iommu and performance will suffer (esp vhost I suspect),
> especially since adding/removing translations in the iommu is a
> hypercall.
Well, we'd nee to make sure that for this particular bus we skip the
actualy iommu.
> > It would not be the same effect. The problem with that is that you must
> > now assumes that your qemu knows that for example you might be passing
> > a dma offset if the bus otherwise requires it.
>
> I would assume that arch_virtio_wants_dma_ops() only returns true when
> no such offsets are involved, at least in our case that would be what
> happens.
That would work, but we're really piling hacĸs ontop of hacks here.
> > Or in other words:
> > you potentially break the contract between qemu and the guest of always
> > passing down physical addresses. If we explicitly change that contract
> > through using a flag that says you pass bus address everything is fine.
>
> For us a "bus address" is behind the iommu so that's what
> VIRTIO_F_IOMMU_PLATFORM does already. We don't have the concept of a
> bus address that is different. I suppose it's an ARMism to have DMA
> offsets that are separate from iommus ?
No, a lot of platforms support a bus address that has an offset from
the physical address. including a lot of power platforms:
arch/powerpc/kernel/pci-common.c: set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
arch/powerpc/platforms/cell/iommu.c: set_dma_offset(dev, cell_dma_nommu_offset);
arch/powerpc/platforms/cell/iommu.c: set_dma_offset(dev, addr);
arch/powerpc/platforms/powernv/pci-ioda.c: set_dma_offset(&pdev->dev, pe->tce_bypass_base);
arch/powerpc/platforms/powernv/pci-ioda.c: set_dma_offset(&pdev->dev, (1ULL << 32));
arch/powerpc/platforms/powernv/pci-ioda.c: set_dma_offset(&dev->dev, pe->tce_bypass_base);
arch/powerpc/platforms/pseries/iommu.c: set_dma_offset(dev, dma_offset);
arch/powerpc/sysdev/dart_iommu.c: set_dma_offset(&dev->dev, DART_U4_BYPASS_BASE);
arch/powerpc/sysdev/fsl_pci.c: set_dma_offset(dev, pci64_dma_offset);
to make things worse some platforms (at least on arm/arm64/mips/x86) can
also require additional banking where it isn't even a single linear map
but multiples windows.
^ permalink raw reply
* Re: Build regressions/improvements in v4.17-rc1
From: Michael Ellerman @ 2018-08-08 13:16 UTC (permalink / raw)
To: Andrew Morton, Geert Uytterhoeven
Cc: Linux Kernel Mailing List, Dan Williams, linuxppc-dev,
npiggin@gmail.com
In-Reply-To: <87lg9hb12y.fsf@concordia.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Andrew Morton <akpm@linux-foundation.org> writes:
>> On Mon, 6 Aug 2018 12:39:21 +0200 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>
>>> CC Dan, Michael, AKPM, powerpc
>>>
>>> On Mon, Apr 16, 2018 at 3:10 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> > Below is the list of build error/warning regressions/improvements in
>>> > v4.17-rc1[1] compared to v4.16[2].
>>>
>>> I'd like to point your attention to:
>>>
>>> > + warning: vmlinux.o(.text+0x376518): Section mismatch in reference from the function .devm_memremap_pages() to the function .meminit.text:.arch_add_memory(): => N/A
>>> > + warning: vmlinux.o(.text+0x376d64): Section mismatch in reference from the function .devm_memremap_pages_release() to the function .meminit.text:.arch_remove_memory(): => N/A
>>
>> hm. Dan isn't around at present so we're on our own with this one.
>>
>> x86 doesn't put arch_add_memory and arch_remove_memory into __meminit.
>> x86 does
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>> int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
>> bool want_memblock)
>> {
>> ...
>>
>>
>> So I guess powerpc should do that as well?
>
> But we only recently added it to fix a section mismatch warning:
>
> WARNING: vmlinux.o(.text+0x6da88): Section mismatch in reference from the function .arch_add_memory() to the function .meminit.text:.create_section_mapping()
> The function .arch_add_memory() references
> the function __meminit .create_section_mapping().
> This is often because .arch_add_memory lacks a __meminit
> annotation or the annotation of .create_section_mapping is wrong.
>
>
> I think the problem is that the section mismatch logic isn't able to
> cope with __meminit's changing semantics.
>
> When CONFIG_MEMORY_HOTPLUG=y references from .text to .meminit.text
> should be allowed, because they're just folded in together in the linker
> script.
>
> When CONFIG_MEMORY_HOTPLUG=n references from .text to .meminit.text
> should NOT be allowed, because .meminit.text becomes .init.text and will
> be freed.
>
> I don't see anything in the section mismatch logic to cope with that
> difference.
>
> It looks like __meminit is saving us about 1K on powerpc, so I'm
> strongly inclined to just remove it entirely from arch/powerpc.
Gah that doesn't work.
Our arch routines call things in mm/ that are __meminit, so we have to
mark our code __meminit too, otherwise we get a section mismatch
warning.
cheers
^ permalink raw reply
* [PATCH] powerpc/mm: Fix address space layout randomization (ASLR)
From: Christophe Leroy @ 2018-08-08 13:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linux-kernel, linuxppc-dev
Today, when stack size is set to unlimited (ulimit -s unlimited),
mmap() doesn't randomise the stack address returned by mmap()
This patch fixes it by applying the random factor on
TASK_UNMAPPED_BASE when setting mm->mmap_base
Link: https://github.com/linuxppc/linux/issues/59
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/mmap.c | 4 ++--
arch/powerpc/mm/slice.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/mmap.c b/arch/powerpc/mm/mmap.c
index b24ce40acd47..07de04c4fb56 100644
--- a/arch/powerpc/mm/mmap.c
+++ b/arch/powerpc/mm/mmap.c
@@ -201,7 +201,7 @@ static void radix__arch_pick_mmap_layout(struct mm_struct *mm,
struct rlimit *rlim_stack)
{
if (mmap_is_legacy(rlim_stack)) {
- mm->mmap_base = TASK_UNMAPPED_BASE;
+ mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
mm->get_unmapped_area = radix__arch_get_unmapped_area;
} else {
mm->mmap_base = mmap_base(random_factor, rlim_stack);
@@ -233,7 +233,7 @@ void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
* bit is set, or if the expected stack growth is unlimited:
*/
if (mmap_is_legacy(rlim_stack)) {
- mm->mmap_base = TASK_UNMAPPED_BASE;
+ mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
mm->get_unmapped_area = arch_get_unmapped_area;
} else {
mm->mmap_base = mmap_base(random_factor, rlim_stack);
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 205fe557ca10..cc1af565b813 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -329,7 +329,7 @@ static unsigned long slice_find_area_bottomup(struct mm_struct *mm,
info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
info.align_offset = 0;
- addr = TASK_UNMAPPED_BASE;
+ addr = mm->mmap_base;
/*
* Check till the allow max value for this mmap request
*/
--
2.13.3
^ permalink raw reply related
* Re: [RFC 0/4] Virtio uses DMA API for all devices
From: Benjamin Herrenschmidt @ 2018-08-08 13:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Michael S. Tsirkin, Will Deacon, Anshuman Khandual,
virtualization, linux-kernel, linuxppc-dev, aik, robh, joe,
elfring, david, jasowang, mpe, linuxram, haren, paulus, srikar,
robin.murphy, jean-philippe.brucker, marc.zyngier
In-Reply-To: <20180808123036.GA2525@infradead.org>
On Wed, 2018-08-08 at 05:30 -0700, Christoph Hellwig wrote:
> On Wed, Aug 08, 2018 at 08:07:49PM +1000, Benjamin Herrenschmidt wrote:
> > Qemu virtio bypasses that iommu when the VIRTIO_F_IOMMU_PLATFORM flag
> > is not set (default) but there's nothing in the device-tree to tell the
> > guest about this since it's a violation of our pseries architecture, so
> > we just rely on Linux virtio "knowing" that it happens. It's a bit
> > yucky but that's now history...
>
> That is ugly as hell, but it is how virtio works everywhere, so nothing
> special so far.
Yup.
> > Essentially pseries "architecturally" does not have the concept of not
> > having an iommu in the way and qemu violates that architecture today.
> >
> > (Remember it comes from pHyp, our priorietary HV, which we are somewhat
> > mimmicing here).
>
> It shouldnt be too hard to have a dt property that communicates this,
> should it?
We could invent something I suppose. The additional problem then (yeah
I know ... what a mess) is that qemu doesn't create the DT for PCI
devices, the firmware (SLOF) inside the guest does using normal PCI
probing.
That said, that FW could know about all the virtio vendor/device IDs,
check the VIRTIO_F_IOMMU_PLATFORM and set that property accordingly...
messy but doable. It's not a bus property (see my other reply below as
this could complicate things with your bus mask).
But we are drifting from the problem at hand :-) You propose we do set
VIRTIO_F_IOMMU_PLATFORM so we aren't in the above case, and the bypass
stuff works, so no need to touch it.
See my recap at the end of the email to make sure I understand fully
what you suggest.
> > So if we always set VIRTIO_F_IOMMU_PLATFORM, it *will* force all virtio
> > through that iommu and performance will suffer (esp vhost I suspect),
> > especially since adding/removing translations in the iommu is a
> > hypercall.
> Well, we'd nee to make sure that for this particular bus we skip the
> actualy iommu.
It's not a bus property. Qemu will happily mix up everything on the
same bus, that includes emulated devices that go through the emulated
iommu, real VFIO devices that go through an actual HW iommu and virtio
that bypasses everything.
This makes things tricky in general (not just in my powerpc secure VM
case) since, at least on powerpc but I suppose elsewhere too, iommu
related properties tend to be per "bus" while here, qemu will mix and
match.
But again, I think we are drifting away from the topic, see below
> > > It would not be the same effect. The problem with that is that you must
> > > now assumes that your qemu knows that for example you might be passing
> > > a dma offset if the bus otherwise requires it.
> >
> > I would assume that arch_virtio_wants_dma_ops() only returns true when
> > no such offsets are involved, at least in our case that would be what
> > happens.
>
> That would work, but we're really piling hacĸs ontop of hacks here.
Sort-of :-) At least none of what we are discussing now involves
touching the dma_ops themselves so we are not in the way of your big
cleanup operation here. But yeah, let's continue discussing your other
solution below.
> > > Or in other words:
> > > you potentially break the contract between qemu and the guest of always
> > > passing down physical addresses. If we explicitly change that contract
> > > through using a flag that says you pass bus address everything is fine.
> >
> > For us a "bus address" is behind the iommu so that's what
> > VIRTIO_F_IOMMU_PLATFORM does already. We don't have the concept of a
> > bus address that is different. I suppose it's an ARMism to have DMA
> > offsets that are separate from iommus ?
>
> No, a lot of platforms support a bus address that has an offset from
> the physical address. including a lot of power platforms:
Ok, just talking past each other :-) For all the powerpc ones, these
*do* go through the iommu, which is what I meant. It's just a window of
the iommu that provides some kind of direct mapping of memory.
For pseries, there is no such thing however. What we do to avoid
constant map/unmap of iommu PTEs in pseries guests is that we use
hypercalls to create a 64-bit window and populate all its PTEs with an
identity mapping. But that's not as efficient as a real bypass.
There are good historical reasons for that, since pseries is a guest
platform, its memory is never really where the guest thinks it is, so
you always need an iommu to remap. Even for virtual devices, since for
most of them, in the "IBM" pHyp model, the "peer" is actually another
partition, so the virtual iommu handles translating accross the two
partitions.
Same goes with cell in HW, no real bypass, just the iommu being
confiured with very large pages and a fixed mapping.
powernv has a separate physical window that can be configured as a real
bypass though, so does the U4 DART. Not sure about the FSL one.
But yeah, your point stands, this is just implementation details.
> arch/powerpc/kernel/pci-common.c: set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
> arch/powerpc/platforms/cell/iommu.c: set_dma_offset(dev, cell_dma_nommu_offset);
> arch/powerpc/platforms/cell/iommu.c: set_dma_offset(dev, addr);
> arch/powerpc/platforms/powernv/pci-ioda.c: set_dma_offset(&pdev->dev, pe->tce_bypass_base);
> arch/powerpc/platforms/powernv/pci-ioda.c: set_dma_offset(&pdev->dev, (1ULL << 32));
> arch/powerpc/platforms/powernv/pci-ioda.c: set_dma_offset(&dev->dev, pe->tce_bypass_base);
> arch/powerpc/platforms/pseries/iommu.c: set_dma_offset(dev, dma_offset);
> arch/powerpc/sysdev/dart_iommu.c: set_dma_offset(&dev->dev, DART_U4_BYPASS_BASE);
> arch/powerpc/sysdev/fsl_pci.c: set_dma_offset(dev, pci64_dma_offset);
>
> to make things worse some platforms (at least on arm/arm64/mips/x86) can
> also require additional banking where it isn't even a single linear map
> but multiples windows.
Sure, but all of this is just the configuration of the iommu. But I
think we agree here, and your point remains valid, indeed my proposed
hack:
> if ((flags & VIRTIO_F_IOMMU_PLATFORM) || arch_virtio_wants_dma_ops())
Will only work if the IOMMU and non-IOMMU path are completely equivalent.
We can provide that guarantee for our secure VM case, but not generally so if
we were to go down the route of a quirk in virtio, it might be better to
make it painfully obvious that it's specific to that one case with a different
kind of turd:
- if (xen_domain())
+ if (xen_domain() || pseries_secure_vm())
return true;
So to summarize, and make sure I'm not missing something, the two approaches
at hand are either:
1- The above, which is a one liner and contained in the guest, so that's nice, but
also means another turd in virtio which isn't ...
2- We force pseries to always set VIRTIO_F_IOMMU_PLATFORM, but with the current
architecture on our side that will force virtio to always go through an emulated
iommu, as pseries doesn't have the concept of a real bypass window, and thus will
impact performance for both secure and non-secure VMs.
3- Invent a property that can be put in selected PCI device tree nodes that
indicates that for that device specifically, the iommu can be bypassed, along with
a hypercall to turn that bypass on/off. Virtio would then use VIRTIO_F_IOMMU_PLATFORM
but its DT nodes would also have that property and Linux would notice it and turn
bypass on.
The resulting properties of those options are:
1- Is what I want because it's the simplest, provides the best performance now,
and works without code changes to qemu or non-secure Linux. However it does
add a tiny turd to virtio which is annoying.
2- This works but it puts the iommu in the way always, thus reducing virtio performance
accross the board for pseries unless we only do that for secure VMs but that is
difficult (as discussed earlier).
3- This would recover the performance lost in -2-, however it requires qemu *and*
guest changes. Specifically, existing guests (RHEL 7 etc...) would get the
performance hit of -2- unless modified to call that 'enable bypass' call, which
isn't great.
So imho we have to chose one of 3 not-great solutions here... Unless I missed
something in your ideas of course.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/pseries: Wait for completion of hotplug events during PRRN handling
From: Michael Ellerman @ 2018-08-08 13:38 UTC (permalink / raw)
To: John Allen, nfont; +Cc: linuxppc-dev
In-Reply-To: <20180807192628.uf3nycnagabjs55o@p50.austin.ibm.com>
John Allen <jallen@linux.ibm.com> writes:
> On Wed, Aug 01, 2018 at 11:16:22PM +1000, Michael Ellerman wrote:
>>John Allen <jallen@linux.ibm.com> writes:
>>> On Mon, Jul 23, 2018 at 11:41:24PM +1000, Michael Ellerman wrote:
>>>>John Allen <jallen@linux.ibm.com> writes:
>>>>
>>>>> While handling PRRN events, the time to handle the actual hotplug events
>>>>> dwarfs the time it takes to perform the device tree updates and queue the
>>>>> hotplug events. In the case that PRRN events are being queued continuously,
>>>>> hotplug events have been observed to be queued faster than the kernel can
>>>>> actually handle them. This patch avoids the problem by waiting for a
>>>>> hotplug request to complete before queueing more hotplug events.
>>
>>Have you tested this patch in isolation, ie. not with patch 1?
>
> While I was away on vacation, I believe a build was tested with just
> this patch and not the first and it has been running with no problems.
> However, I think they've had problems recreating the problem in general
> so it may just be that the environment is not setup properly to recreate
> the issue.
Yes I asked Haren to test it :)
>From memory there were some warnings still about the work queue being
blocked for long periods, but they weren't fatal.
>>>>So do we need the hotplug work queue at all? Can we just call
>>>>handle_dlpar_errorlog() directly?
>>>>
>>>>Or are we using the work queue to serialise things? And if so would a
>>>>mutex be better?
>>>
>>> Right, the workqueue is meant to serialize all hotplug events and it
>>> gets used for more than just PRRN events. I believe the motivation for
>>> using the workqueue over a mutex is that KVM guests initiate hotplug
>>> events through the hotplug interrupt and can queue fairly large requests
>>> meaning that in this scenario, waiting for a lock would block interrupts
>>> for a while.
>>
>>OK, but that just means that path needs to schedule work to run later.
>>
>>> Using the workqueue allows us to serialize hotplug events
>>> from different sources in the same way without worrying about the
>>> context in which the event is generated.
>>
>>A lock would be so much simpler.
>>
>>It looks like we have three callers of queue_hotplug_event(), the dlpar
>>code, the mobility code and the ras interrupt.
>>
>>The dlpar code already waits synchronously:
>>
>> init_completion(&hotplug_done);
>> queue_hotplug_event(hp_elog, &hotplug_done, &rc);
>> wait_for_completion(&hotplug_done);
>>
>>You're changing mobility to do the same (this patch), leaving only the
>>ras interrupt that actually queues work and returns.
>>
>>
>>So it really seems like a mutex would do the trick, and the ras
>>interrupt would be the only case that needs to schedule work for later.
>
> I think you may be right, but I would need some feedback from Nathan
> Fontenot before I redesign the queue. He's been thinking about that
> design for longer than I have and may know something that I don't
> regarding the reason we're using a workqueue rather than a mutex.
> Given that the bug this is meant to address is pretty high priority,
> would you consider the wait_for_completion an acceptable stopgap while a
> more substantial redesign of this code is discussed?
Yeah that would be OK.
cheers
^ permalink raw reply
* Re: Several suspected memory leaks
From: Michael Ellerman @ 2018-08-08 13:45 UTC (permalink / raw)
To: Catalin Marinas, Benjamin Herrenschmidt
Cc: pmenzel, Paul Mackerras, linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <CAHkRjk7aYtMJXmQ_zuV7B12JiCkLfg3-8x+ayTD2DU9gDwi8Hw@mail.gmail.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> On Wed, 11 Jul 2018 at 00:40, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Tue, 2018-07-10 at 17:17 +0200, Paul Menzel wrote:
>> > On a the IBM S822LC (8335-GTA) with Ubuntu 18.04 I built Linux master
>> > =E2=80=93 4.18-rc4+, commit 092150a2 (Merge branch 'for-linus'
>> > of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid) =E2=80=93 =
with
>> > kmemleak. Several issues are found.
>>
>> Some of these are completely uninteresting though and look like
>> kmemleak bugs to me :-)
>>
>> > [<00000000bc285bbf>] __pud_alloc+0x80/0x270
>> > [<0000000007135d64>] hash__map_kernel_page+0x30c/0x4d0
>> > [<0000000071677858>] __ioremap_at+0x108/0x140
>> > [<000000000023e921>] __ioremap_caller+0x130/0x180
>> > [<000000009dbc3923>] icp_native_init_one_node+0x5cc/0x760
>> > [<0000000015f3168a>] icp_native_init+0x70/0x13c
>> > [<00000000655550ed>] xics_init+0x38/0x1ac
>> > [<0000000088dbf9d1>] pnv_init_IRQ+0x30/0x5c
>>
>> This is the interrupt controller mapping its registers, why on earth
>> would that be considered a leak ? kmemleak needs to learn to ignore
>> kernel page tables allocations.
>
> Indeed, that's just a false positive for powerpc. Kmemleak ignores
> page allocations and most architectures use __get_free_pages() for the
> page table. In this particular case, the powerpc code uses
> kmem_cache_alloc() and that's tracked by kmemleak. Since the pgd
> stores the __pa(pud), kmemleak doesn't detect this pointer and reports
> it as a leak. To work around this, you can pass SLAB_NOLEAKTRACE to
> kmem_cache_create() in pgtable_cache_add()
Ah thanks, I didn't know we could do it that way.
I did this instead which seems to work:
https://git.kernel.org/torvalds/c/a984506c542e
cheers
^ permalink raw reply
* Re: is there still any need PPC checking for "chosen@0"?
From: Michael Ellerman @ 2018-08-08 13:58 UTC (permalink / raw)
To: Robert P. J. Day, Linux PPC Mailing List, paulus
In-Reply-To: <alpine.LFD.2.21.1808061234580.25636@localhost.localdomain>
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
> given that there are no .dts files in the current kernel code base
> that define the node name "/chosen@0" instead of the proper "/chosen",
A good portion of PPC machines get their device tree from firmware, not
from a dts that's in the kernel tree, so that's not a good indication.
> is there any need for arch/powerpc/boot/oflib.c to still make this
> test:
>
> chosen = of_finddevice("/chosen");
> if (chosen == (phandle) -1) {
> chosen = of_finddevice("/chosen@0"); <--- this
> if (chosen == (phandle) -1) {
> printf("no chosen\n");
> return 0;
> }
> }
>
> are there still PPC machines that require the recognition of
> "/chosen@0"?
It was added by Paul in:
66a45dd3620e ("powerpc: Make COFF zImages for old 32-bit powermacs")
So presumably there's an old powermac somewhere that needs it.
Given it's basically 2 extra lines of code I'd be inclined to leave it
alone.
cheers
^ permalink raw reply
* Re: [PATCH v02] powerpc/mobility: Fix node detach/rename problem
From: Michael Ellerman @ 2018-08-08 14:02 UTC (permalink / raw)
To: Michael Bringmann, linuxppc-dev
Cc: Nathan Fontenot, Michael Bringmann, Thomas Falcon, Tyrel Datwyler,
John Allen
In-Reply-To: <b3f658d9-efc5-e532-e8d4-162494b88194@linux.vnet.ibm.com>
Michael Bringmann <mwb@linux.vnet.ibm.com> writes:
> diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
> index e245a88..efc9442 100644
> --- a/arch/powerpc/platforms/pseries/mobility.c
> +++ b/arch/powerpc/platforms/pseries/mobility.c
> @@ -22,6 +22,9 @@
> #include <asm/rtas.h>
> #include "pseries.h"
>
> +extern int of_free_phandle_cache(void);
> +extern void of_populate_phandle_cache(void);
We don't do that, they should be in a header.
But that's a minor problem given that the patch doesn't compile, because
both those functions are static.
Presumably you have a hack in your tree to make them non-static?
Please try and compile your patches in a clean tree before sending.
cheers
^ permalink raw reply
* Re: [PATCH v5 0/8] powerpc/fsl: Speculation barrier for NXP PowerPC Book3E
From: Michael Ellerman @ 2018-08-08 14:03 UTC (permalink / raw)
To: Diana Madalina Craciun, linuxppc-dev@ozlabs.org
Cc: oss@buserror.net, Leo Li, Bharat Bhushan
In-Reply-To: <VI1PR0401MB2463CD1A5B37947DAC5FB33DFF200@VI1PR0401MB2463.eurprd04.prod.outlook.com>
Diana Madalina Craciun <diana.craciun@nxp.com> writes:
> Hi Michael,
>
> Sorry for the late answer, I was out of the office last week.
>
> It looks fine to me, I have tested the patches on NXP PowerPC Book 3E
> platforms and it worked well.
Thanks.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Make unrecoverable SLB miss less confusing
From: Michael Ellerman @ 2018-08-08 14:18 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, anton, paulus
In-Reply-To: <20180801121111.308ff705@roar.ozlabs.ibm.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> On Thu, 26 Jul 2018 23:01:51 +1000
> Michael Ellerman <mpe@ellerman.id.au> wrote:
>
>> If we take an SLB miss while MSR[RI]=0 we can't recover and have to
>> oops. Currently this is reported by faking up a 0x4100 exception, eg:
>>
>> Unrecoverable exception 4100 at 0
>> Oops: Unrecoverable exception, sig: 6 [#1]
>> ...
>> CPU: 0 PID: 1262 Comm: sh Not tainted 4.18.0-rc3-gcc-7.3.1-00098-g7fc2229fb2ab-dirty #9
>> NIP: 0000000000000000 LR: c00000000000b9e4 CTR: 00007fff8bb971b0
>> REGS: c0000000ee02bbb0 TRAP: 4100
>> ...
>> LR [c00000000000b9e4] system_call+0x5c/0x70
>>
>> The 0x4100 value was chosen back in 2004 as part of the fix for the
>> "mega bug" - "ppc64: Fix SLB reload bug". Back then it was obvious
>> that 0x4100 was not a real trap value, as the highest actual trap was
>> less than 0x2000.
>>
>> Since then however the architecture has changed and now we have
>> "virtual mode" or "relon" exceptions, in which exceptions can be
>> delivered with the MMU on starting at 0x4000.
>>
>> At a glance 0x4100 looks like a virtual mode 0x100 exception, aka
>> system reset exception. A close reading of the architecture will show
>> that system reset exceptions can't be delivered in virtual mode, and
>> so 0x4100 is not a valid trap number. But that's not immediately
>> obvious. There's also nothing about 0x4100 that suggests SLB miss.
>>
>> So to make things a bit less confusing switch to a fake but unique and
>> hopefully more helpful numbering. For data SLB misses we report a
>> 0x390 trap and for instruction we report 0x490. Compared to 0x380 and
>> 0x480 for the actual data & instruction SLB exceptions.
>>
>> Also add a C handler that prints a more explicit message. The end
>> result is something like:
>>
>> Oops: Unrecoverable SLB miss (MSR[RI]=0), sig: 6 [#3]
>
> This is all good, but allow me to nitpick. Our unrecoverable
> exception messages (and other messages, but those) are becoming a bit
> ad-hoc and messy.
>
> It would be nice to go the other way eventually and consolidate them
> into one. Would be nice to have a common function that takes regs and
> returns the string of the corresponding exception name that makes
> these more readable.
Yeah that's true, though some of them aren't simply a mapping from the
trap number, eg. the kernel bad stack one.
But in general our whole oops output, regs, stack trace etc. could use a
revamp.
I've been thinking of making the trap number more prominent and
providing a text description, because apparently not everyone knows the
trap numbers by heart :)
>> ...
>> CPU: 0 PID: 1262 Comm: sh Not tainted 4.18.0-rc3-gcc-7.3.1-00098-g7fc2229fb2ab-dirty #9
>> NIP: 0000000000000000 LR: c00000000000b9e4 CTR: 0000000000000000
>> REGS: c0000000f19a3bb0 TRAP: 0490
>
> Unless I'm mistaken, the fake trap number was only because the code
> couldn't distinguish between 380 and 480. Now that you do, I think you
> can just use them directly rather than 390/490.
Hmm. I always thought it was there so that you could differentiate the
unrecoverable miss vs a normal miss using the trap number.
But maybe that's a bit superfluous given we're printing "unrecoverable
slb miss".
cheers
^ permalink raw reply
* Re: powerpc/powernv/opal: Use standard interrupts property when available
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev; +Cc: Stewart Smith
In-Reply-To: <1523344570.11062.65.camel@kernel.crashing.org>
On Tue, 2018-04-10 at 07:16:10 UTC, Benjamin Herrenschmidt wrote:
> For (bad) historical reasons, OPAL used to create a non-standard pair of
> properties "opal-interrupts" and "opal-interrupts-names" for representing
> the list of interrupts it wants Linux to request on its behalf.
>
> Among other issues, the opal-interrupts doesn't have a way to carry the
> type of interrupts, and they were assumed to be all level sensitive.
>
> This is wrong on some recent systems where some of them are edge sensitive
> causing warnings in the XIVE code and possible misbehaviours if they need
> to be retriggered (typically the NPU2 TCE error interrupts).
>
> This makes Linux switch to using the standard "interrupts" and
> "interrupt-names" properties instead when they are available, using standard
> of_irq helpers, which can carry all the desired type information.
>
> Newer versions of OPAL will generate those properties in addition to the
> legacy ones.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/77b5f703dcc859915f0f20d92bc538
cheers
^ permalink raw reply
* Re: [2/3] powerpc/xive: Remove now useless pr_debug statements
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <20180411051801.30194-2-benh@kernel.crashing.org>
On Wed, 2018-04-11 at 05:18:00 UTC, Benjamin Herrenschmidt wrote:
> Those overly verbose statement in the setup of the pool VP
> aren't particularly useful (esp. considering we don't actually
> use the pool, we configure it bcs HW requires it only). So
> remove them which improves the code readability.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/dbc5740247961d6b060737620520dc
cheers
^ permalink raw reply
* Re: [3/3] powerpc/xive: Remove xive_kexec_teardown_cpu()
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <20180411051801.30194-3-benh@kernel.crashing.org>
On Wed, 2018-04-11 at 05:18:01 UTC, Benjamin Herrenschmidt wrote:
> It's identical to xive_teardown_cpu() so just use the latter
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e27e0a94651e30912443e88642e698
cheers
^ permalink raw reply
* Re: powerpc/perf: Remove sched_task function defined for thread-imc
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Anju T Sudhakar; +Cc: maddy, linuxppc-dev, anju
In-Reply-To: <1526628925-31075-1-git-send-email-anju@linux.vnet.ibm.com>
On Fri, 2018-05-18 at 07:35:25 UTC, Anju T Sudhakar wrote:
> Call trace observed while running perf-fuzzer:
>
> [ 329.228068] CPU: 43 PID: 9088 Comm: perf_fuzzer Not tainted 4.13.0-32-generic #35~lp1746225
> [ 329.228070] task: c000003f776ac900 task.stack: c000003f77728000
> [ 329.228071] NIP: c000000000299b70 LR: c0000000002a4534 CTR: c00000000029bb80
> [ 329.228073] REGS: c000003f7772b760 TRAP: 0700 Not tainted (4.13.0-32-generic)
> [ 329.228073] MSR: 900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>
> [ 329.228079] CR: 24008822 XER: 00000000
> [ 329.228080] CFAR: c000000000299a70 SOFTE: 0
> GPR00: c0000000002a4534 c000003f7772b9e0 c000000001606200 c000003fef858908
> GPR04: c000003f776ac900 0000000000000001 ffffffffffffffff 0000003fee730000
> GPR08: 0000000000000000 0000000000000000 c0000000011220d8 0000000000000002
> GPR12: c00000000029bb80 c000000007a3d900 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 c000003f776ad090 c000000000c71354
> GPR24: c000003fef716780 0000003fee730000 c000003fe69d4200 c000003f776ad330
> GPR28: c0000000011220d8 0000000000000001 c0000000014c6108 c000003fef858900
> [ 329.228098] NIP [c000000000299b70] perf_pmu_sched_task+0x170/0x180
> [ 329.228100] LR [c0000000002a4534] __perf_event_task_sched_in+0xc4/0x230
> [ 329.228101] Call Trace:
> [ 329.228102] [c000003f7772b9e0] [c0000000002a0678] perf_iterate_sb+0x158/0x2a0 (unreliable)
> [ 329.228105] [c000003f7772ba30] [c0000000002a4534] __perf_event_task_sched_in+0xc4/0x230
> [ 329.228107] [c000003f7772bab0] [c0000000001396dc] finish_task_switch+0x21c/0x310
> [ 329.228109] [c000003f7772bb60] [c000000000c71354] __schedule+0x304/0xb80
> [ 329.228111] [c000003f7772bc40] [c000000000c71c10] schedule+0x40/0xc0
> [ 329.228113] [c000003f7772bc60] [c0000000001033f4] do_wait+0x254/0x2e0
> [ 329.228115] [c000003f7772bcd0] [c000000000104ac0] kernel_wait4+0xa0/0x1a0
> [ 329.228117] [c000003f7772bd70] [c000000000104c24] SyS_wait4+0x64/0xc0
> [ 329.228121] [c000003f7772be30] [c00000000000b184] system_call+0x58/0x6c
> [ 329.228121] Instruction dump:
> [ 329.228123] 3beafea0 7faa4800 409eff18 e8010060 eb610028 ebc10040 7c0803a6 38210050
> [ 329.228127] eb81ffe0 eba1ffe8 ebe1fff8 4e800020 <0fe00000> 4bffffbc 60000000 60420000
> [ 329.228131] ---[ end trace 8c46856d314c1811 ]---
> [ 375.755943] hrtimer: interrupt took 31601 ns
>
>
> The context switch call-backs for thread-imc are defined in sched_task function.
> So when thread-imc events are grouped with software pmu events,
> perf_pmu_sched_task hits the WARN_ON_ONCE condition, since software PMUs are
> assumed not to have a sched_task defined.
>
> Patch to move the thread_imc enable/disable opal call back from sched_task to
> event_[add/del] function
>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> Tested-by: Joel Stanley <joel@jms.id.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7ccc4fe5ff9e3a134e863beed0dba1
cheers
^ permalink raw reply
* Re: [1/3] powerpc: make CPU selection logic generic in Makefile
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <273f8ed3e980b9385c6e1b31e17f890ea08ce33c.1528365638.git.christophe.leroy@c-s.fr>
On Thu, 2018-06-07 at 10:10:18 UTC, Christophe Leroy wrote:
> At the time being, when adding a new CPU for selection, both
> Kconfig.cputype and Makefile have to be modified.
>
> This patch moves into Kconfig.cputype the name of the CPU to me
> passed to the -mcpu= argument.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cc62d20ce4ca4fe73a09d571144b29
cheers
^ permalink raw reply
* Re: [V3,1/2] powerpc/powernv: Export opal_check_token symbol
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Haren Myneni; +Cc: linuxppc-dev, herbert, stewart, linux-crypto
In-Reply-To: <1528874937.14408.2.camel@hbabu-laptop>
On Wed, 2018-06-13 at 07:28:57 UTC, Haren Myneni wrote:
> Export opal_check_token symbol for modules to check the availability
> of OPAL calls before using them.
>
> Signed-off-by: Haren Myneni <haren@us.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6e708000ec2c93c2bde6a46aa2d6c3
cheers
^ permalink raw reply
* Re: [V3, 2/2] crypto/nx: Initialize 842 high and normal RxFIFO control registers
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Haren Myneni; +Cc: linuxppc-dev, herbert, stewart, linux-crypto
In-Reply-To: <1528875160.14408.6.camel@hbabu-laptop>
On Wed, 2018-06-13 at 07:32:40 UTC, Haren Myneni wrote:
> NX increments readOffset by FIFO size in receive FIFO control register
> when CRB is read. But the index in RxFIFO has to match with the
> corresponding entry in FIFO maintained by VAS in kernel. Otherwise NX
> may be processing incorrect CRBs and can cause CRB timeout.
>
> VAS FIFO offset is 0 when the receive window is opened during
> initialization. When the module is reloaded or in kexec boot, readOffset
> in FIFO control register may not match with VAS entry. This patch adds
> nx_coproc_init OPAL call to reset readOffset and queued entries in FIFO
> control register for both high and normal FIFOs.
>
> Signed-off-by: Haren Myneni <haren@us.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/656ecc16e8fc2ab44b3d70e3fcc197
cheers
^ permalink raw reply
* Re: [v6, 1/8] powerpc/pseries: Avoid using the size greater than RTAS_ERROR_LOG_MAX.
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Mahesh J Salgaonkar, linuxppc-dev
Cc: Laurent Dufour, Michal Suchanek, Aneesh Kumar K.V,
Nicholas Piggin
In-Reply-To: <153072701775.29016.13501175476729182702.stgit@jupiter.in.ibm.com>
On Wed, 2018-07-04 at 17:57:02 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> The global mce data buffer that used to copy rtas error log is of 2048
> (RTAS_ERROR_LOG_MAX) bytes in size. Before the copy we read
> extended_log_length from rtas error log header, then use max of
> extended_log_length and RTAS_ERROR_LOG_MAX as a size of data to be copied.
> Ideally the platform (phyp) will never send extended error log with
> size > 2048. But if that happens, then we have a risk of buffer overrun
> and corruption. Fix this by using min_t instead.
>
> Fixes: d368514c3097 ("powerpc: Fix corruption when grabbing FWNMI data")
> Reported-by: Michal Suchanek <msuchanek@suse.com>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/74e96bf44f430cf7a01de19ba6cf49
cheers
^ permalink raw reply
* Re: [v6, 2/8] powerpc/pseries: Defer the logging of rtas error to irq work queue.
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Mahesh J Salgaonkar, linuxppc-dev
Cc: Michal Suchanek, Nicholas Piggin, stable, Laurent Dufour,
Aneesh Kumar K.V
In-Reply-To: <153072702900.29016.3698488484610157863.stgit@jupiter.in.ibm.com>
On Wed, 2018-07-04 at 17:57:21 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> rtas_log_buf is a buffer to hold RTAS event data that are communicated
> to kernel by hypervisor. This buffer is then used to pass RTAS event
> data to user through proc fs. This buffer is allocated from vmalloc
> (non-linear mapping) area.
>
> On Machine check interrupt, register r3 points to RTAS extended event
> log passed by hypervisor that contains the MCE event. The pseries
> machine check handler then logs this error into rtas_log_buf. The
> rtas_log_buf is a vmalloc-ed (non-linear) buffer we end up taking up a
> page fault (vector 0x300) while accessing it. Since machine check
> interrupt handler runs in NMI context we can not afford to take any
> page fault. Page faults are not honored in NMI context and causes
> kernel panic. Apart from that, as Nick pointed out, pSeries_log_error()
> also takes a spin_lock while logging error which is not safe in NMI
> context. It may endup in deadlock if we get another MCE before releasing
> the lock. Fix this by deferring the logging of rtas error to irq work queue.
>
> Current implementation uses two different buffers to hold rtas error log
> depending on whether extended log is provided or not. This makes bit
> difficult to identify which buffer has valid data that needs to logged
> later in irq work. Simplify this using single buffer, one per paca, and
> copy rtas log to it irrespective of whether extended log is provided or
> not. Allocate this buffer below RMA region so that it can be accessed
> in real mode mce handler.
>
> Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable interrupt")
> Cc: stable@vger.kernel.org
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/94675cceacaec27a30eefb142c4c59
cheers
^ permalink raw reply
* Re: powerpc/platforms/85xx: fix t1042rdb_diu.c build errors & warning
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Randy Dunlap, PowerPC; +Cc: Scott Wood, Paul Mackerras
In-Reply-To: <25463c4f-4901-b86f-2002-6c65c9ee9fd2@infradead.org>
On Sun, 2018-07-15 at 17:34:46 UTC, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix build errors and warnings in t1042rdb_diu.c by adding header files
> and MODULE_LICENSE().
>
> ../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: data definition has no type or storage class
> early_initcall(t1042rdb_diu_init);
> ../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: error: type defaults to 'int' in declaration of 'early_initcall' [-Werror=implicit-int]
> ../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: parameter names (without types) in function declaration
>
> and
> WARNING: modpost: missing MODULE_LICENSE() in arch/powerpc/platforms/85xx/t1042rdb_diu.o
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@lists.ozlabs.org
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f5daf77a55ef0e695cc90c440ed650
cheers
^ permalink raw reply
* Re: [1/5] powerpc/asm: Add a patch_site macro & helpers for patching instructions
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180723150756.11108-1-mpe@ellerman.id.au>
On Mon, 2018-07-23 at 15:07:52 UTC, Michael Ellerman wrote:
> Add a macro and some helper C functions for patching single asm
> instructions.
>
> The gas macro means we can do something like:
>
> 1: nop
> patch_site 1b, patch__foo
>
> Which is less visually distracting than defining a GLOBAL symbol at 1,
> and also doesn't pollute the symbol table which can confuse eg. perf.
>
> These are obviously similar to our existing feature sections, but are
> not automatically patched based on CPU/MMU features, rather they are
> designed to be manually patched by C code at some arbitrary point.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/06d0bbc6d0f56dacac3a79900e9a9a
cheers
^ permalink raw reply
* Re: powerpc: Add a checkpatch wrapper with our preferred settings
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180724140346.10575-1-mpe@ellerman.id.au>
On Tue, 2018-07-24 at 14:03:46 UTC, Michael Ellerman wrote:
> This makes it easy to run checkpatch with settings that we have agreed
> on (bwhahahahah).
>
> Usage is eg:
>
> $ ./arch/powerpc/tools/checkpatch.sh -g origin/master..
>
> To check all commits since origin/master.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Russell Currey <ruscur@russell.cc>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/7cd129b4b5370030a5c0b8031a54b2
cheers
^ permalink raw reply
* Re: powerpc/64s/radix: tlb do not flush on page size when fullmm
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180725135806.29648-1-npiggin@gmail.com>
On Wed, 2018-07-25 at 13:58:06 UTC, Nicholas Piggin wrote:
> When the mm is being torn down there will be a full PID flush so
> there is no need to flush the TLB on page size changes.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/5a6099346c41792f1ba23aea6f74ad
cheers
^ permalink raw reply
* Re: powerpc/64s: free page table caches at exit_mmap time
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180725095428.22561-1-npiggin@gmail.com>
On Wed, 2018-07-25 at 09:54:28 UTC, Nicholas Piggin wrote:
> The kernel page table caches are tied to init_mm, so there is no
> more need for them after userspace is finished.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/34c604d27590fdc9a2c944be8c50ae
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