* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.7-2 tag
From: pr-tracker-bot @ 2020-04-09 18:10 UTC (permalink / raw)
To: Michael Ellerman
Cc: geert+renesas, aik, linuxppc-dev, linux-kernel, npiggin, geoff,
anju, ganeshgr, msuchanek, Linus Torvalds, elfring, dan.carpenter
In-Reply-To: <87pncgkjdf.fsf@mpe.ellerman.id.au>
The pull request you sent on Thu, 09 Apr 2020 21:07:24 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.7-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e4da01d8333e500e15a674d75885a9dfcfd31e77
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
From: Minchan Kim @ 2020-04-09 17:08 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan,
Sumit Semwal, linux-arch, linux-s390, Wei Liu, Stephen Hemminger,
x86, Christoph Hellwig, Laura Abbott, Nitin Gupta, Daniel Vetter,
Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Robin Murphy,
linux-kernel, sergey.senozhatsky, iommu, Sakari Ailus,
Andrew Morton, linuxppc-dev
In-Reply-To: <20200409165030.GG20713@hirez.programming.kicks-ass.net>
On Thu, Apr 09, 2020 at 06:50:30PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote:
> > On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> > > This allows to unexport map_vm_area and unmap_kernel_range, which are
> > > rather deep internal and should not be available to modules.
> >
> > Even though I don't know how many usecase we have using zsmalloc as
> > module(I heard only once by dumb reason), it could affect existing
> > users. Thus, please include concrete explanation in the patch to
> > justify when the complain occurs.
>
> The justification is 'we can unexport functions that have no sane reason
> of being exported in the first place'.
>
> The Changelog pretty much says that.
Okay, I hope there is no affected user since this patch.
If there are someone, they need to provide sane reason why they want
to have zsmalloc as module.
Acked-by: Minchan Kim <minchan@kernel.org>
^ permalink raw reply
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
From: Peter Zijlstra @ 2020-04-09 16:50 UTC (permalink / raw)
To: Minchan Kim
Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan,
Sumit Semwal, linux-arch, linux-s390, Wei Liu, Stephen Hemminger,
x86, Christoph Hellwig, Laura Abbott, Nitin Gupta, Daniel Vetter,
Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Robin Murphy,
linux-kernel, sergey.senozhatsky, iommu, Sakari Ailus,
Andrew Morton, linuxppc-dev
In-Reply-To: <20200409160826.GC247701@google.com>
On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote:
> On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> > This allows to unexport map_vm_area and unmap_kernel_range, which are
> > rather deep internal and should not be available to modules.
>
> Even though I don't know how many usecase we have using zsmalloc as
> module(I heard only once by dumb reason), it could affect existing
> users. Thus, please include concrete explanation in the patch to
> justify when the complain occurs.
The justification is 'we can unexport functions that have no sane reason
of being exported in the first place'.
The Changelog pretty much says that.
^ permalink raw reply
* Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA
From: Mike Rapoport @ 2020-04-09 16:27 UTC (permalink / raw)
To: Michal Hocko
Cc: mmorana, Catalin Marinas, Will Deacon,
open list:MEMORY MANAGEMENT, Paul Mackerras, H. Peter Anvin,
sparclinux, Alexander Duyck, linux-s390, Baoquan He, x86,
Christian Borntraeger, Ingo Molnar, Hoan Tran, Pavel Tatashin,
lho, Vasily Gorbik, Vlastimil Babka, Heiko Carstens,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel,
Oscar Salvador, linux-kernel, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20200331142138.GL30449@dhcp22.suse.cz>
On Tue, Mar 31, 2020 at 04:21:38PM +0200, Michal Hocko wrote:
> On Tue 31-03-20 22:03:32, Baoquan He wrote:
> > Hi Michal,
> >
> > On 03/31/20 at 10:55am, Michal Hocko wrote:
> > > On Tue 31-03-20 11:14:23, Mike Rapoport wrote:
> > > > Maybe I mis-read the code, but I don't see how this could happen. In the
> > > > HAVE_MEMBLOCK_NODE_MAP=y case, free_area_init_node() calls
> > > > calculate_node_totalpages() that ensures that node->node_zones are entirely
> > > > within the node because this is checked in zone_spanned_pages_in_node().
> > >
> > > zone_spanned_pages_in_node does chech the zone boundaries are within the
> > > node boundaries. But that doesn't really tell anything about other
> > > potential zones interleaving with the physical memory range.
> > > zone->spanned_pages simply gives the physical range for the zone
> > > including holes. Interleaving nodes are essentially a hole
> > > (__absent_pages_in_range is going to skip those).
> > >
> > > That means that when free_area_init_core simply goes over the whole
> > > physical zone range including holes and that is why we need to check
> > > both for physical and logical holes (aka other nodes).
> > >
> > > The life would be so much easier if the whole thing would simply iterate
> > > over memblocks...
> >
> > The memblock iterating sounds a great idea. I tried with putting the
> > memblock iterating in the upper layer, memmap_init(), which is used for
> > boot mem only anyway. Do you think it's doable and OK? It yes, I can
> > work out a formal patch to make this simpler as you said. The draft code
> > is as below. Like this it uses the existing code and involves little change.
>
> Doing this would be a step in the right direction! I haven't checked the
> code very closely though. The below sounds way too simple to be truth I
> am afraid. First for_each_mem_pfn_range is available only for
> CONFIG_HAVE_MEMBLOCK_NODE_MAP (which is one of the reasons why I keep
> saying that I really hate that being conditional). Also I haven't really
> checked the deferred initialization path - I have a very vague
> recollection that it has been converted to the memblock api but I have
> happilly dropped all that memory.
The Baoquan's patch almost did it, at least for simple case of qemu with 2
nodes. It's only missing the adjustment to the size passed to
memmap_init_zone() as it may change because of clamping.
I've drafted something that removes HAVE_MEMBLOCK_NODE_MAP and added this
patch there [1]. For several memory configurations I could emulate with
qemu it worked.
I'm going to wait a bit to see of kbuild is happy and then I'll send the
patches.
Baoquan, I took liberty to add your SoB, hope you don't mind.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=memblock/all-have-node-map
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 138a56c0f48f..558d421f294b 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -6007,14 +6007,6 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
> > * function. They do not exist on hotplugged memory.
> > */
> > if (context == MEMMAP_EARLY) {
> > - if (!early_pfn_valid(pfn)) {
> > - pfn = next_pfn(pfn);
> > - continue;
> > - }
> > - if (!early_pfn_in_nid(pfn, nid)) {
> > - pfn++;
> > - continue;
> > - }
> > if (overlap_memmap_init(zone, &pfn))
> > continue;
> > if (defer_init(nid, pfn, end_pfn))
> > @@ -6130,9 +6122,17 @@ static void __meminit zone_init_free_lists(struct zone *zone)
> > }
> >
> > void __meminit __weak memmap_init(unsigned long size, int nid,
> > - unsigned long zone, unsigned long start_pfn)
> > + unsigned long zone, unsigned long range_start_pfn)
> > {
> > - memmap_init_zone(size, nid, zone, start_pfn, MEMMAP_EARLY, NULL);
> > + unsigned long start_pfn, end_pfn;
> > + unsigned long range_end_pfn = range_start_pfn + size;
> > + int i;
> > + for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
> > + start_pfn = clamp(start_pfn, range_start_pfn, range_end_pfn);
> > + end_pfn = clamp(end_pfn, range_start_pfn, range_end_pfn);
> > + if (end_pfn > start_pfn)
> > + memmap_init_zone(size, nid, zone, start_pfn, MEMMAP_EARLY, NULL);
> > + }
> > }
> >
> > static int zone_batchsize(struct zone *zone)
>
> --
> Michal Hocko
> SUSE Labs
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
From: Minchan Kim @ 2020-04-09 16:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan,
Sumit Semwal, linux-arch, linux-s390, Wei Liu, Stephen Hemminger,
x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Daniel Vetter,
Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Robin Murphy,
linux-kernel, sergey.senozhatsky, iommu, Sakari Ailus,
Andrew Morton, linuxppc-dev
In-Reply-To: <20200408115926.1467567-11-hch@lst.de>
On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> This allows to unexport map_vm_area and unmap_kernel_range, which are
> rather deep internal and should not be available to modules.
Even though I don't know how many usecase we have using zsmalloc as
module(I heard only once by dumb reason), it could affect existing
users. Thus, please include concrete explanation in the patch to
justify when the complain occurs.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> mm/Kconfig | 2 +-
> mm/vmalloc.c | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 36949a9425b8..614cc786b519 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -702,7 +702,7 @@ config ZSMALLOC
>
> config ZSMALLOC_PGTABLE_MAPPING
> bool "Use page table mapping to access object in zsmalloc"
> - depends on ZSMALLOC
> + depends on ZSMALLOC=y
> help
> By default, zsmalloc uses a copy-based object mapping method to
> access allocations that span two pages. However, if a particular
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 3375f9508ef6..9183fc0d365a 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2046,7 +2046,6 @@ void unmap_kernel_range(unsigned long addr, unsigned long size)
> vunmap_page_range(addr, end);
> flush_tlb_kernel_range(addr, end);
> }
> -EXPORT_SYMBOL_GPL(unmap_kernel_range);
>
> int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page **pages)
> {
> @@ -2058,7 +2057,6 @@ int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page **pages)
>
> return err > 0 ? 0 : err;
> }
> -EXPORT_SYMBOL_GPL(map_vm_area);
>
> static inline void setup_vmalloc_vm_locked(struct vm_struct *vm,
> struct vmap_area *va, unsigned long flags, const void *caller)
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING
From: Minchan Kim @ 2020-04-09 15:59 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan,
Sumit Semwal, linux-arch, linux-s390, Wei Liu, Stephen Hemminger,
x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Daniel Vetter,
Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Robin Murphy,
linux-kernel, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev
In-Reply-To: <20200408115926.1467567-10-hch@lst.de>
On Wed, Apr 08, 2020 at 01:59:07PM +0200, Christoph Hellwig wrote:
> Rename the Kconfig variable to clarify the scope.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Minchan Kim <minchan@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)
From: Michal Hocko @ 2020-04-09 15:33 UTC (permalink / raw)
To: Baoquan He
Cc: mmorana, Catalin Marinas, Heiko Carstens,
open list:MEMORY MANAGEMENT, Paul Mackerras, H. Peter Anvin,
sparclinux, Alexander Duyck, linux-s390, x86, Mike Rapoport,
Christian Borntraeger, Ingo Molnar, Hoan Tran, Pavel Tatashin,
lho, Vasily Gorbik, Vlastimil Babka, Will Deacon, Borislav Petkov,
Thomas Gleixner, linux-arm-kernel, Oscar Salvador, linux-kernel,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200409144119.GE2129@MiWiFi-R3L-srv>
On Thu 09-04-20 22:41:19, Baoquan He wrote:
> On 04/02/20 at 10:01am, Michal Hocko wrote:
> > On Wed 01-04-20 10:51:55, Mike Rapoport wrote:
> > > Hi,
> > >
> > > On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote:
> > [...]
> > > > From above information, we can remove HAVE_MEMBLOCK_NODE_MAP, and
> > > > replace it with CONFIG_NUMA. That sounds more sensible to store nid into
> > > > memblock when NUMA support is enabled.
> > >
> > > Replacing CONFIG_HAVE_MEMBLOCK_NODE_MAP with CONFIG_NUMA will work, but
> > > this will not help cleaning up the whole node/zone initialization mess and
> > > we'll be stuck with two implementations.
> >
> > Yeah, this is far from optimal.
> >
> > > The overhead of enabling HAVE_MEMBLOCK_NODE_MAP is only for init time as
> > > most architectures will anyway discard the entire memblock, so having it in
> > > a UMA arch won't be a problem. The only exception is arm that uses
> > > memblock for pfn_valid(), here we may also think about a solution to
> > > compensate the addition of nid to the memblock structures.
> >
> > Well, we can make memblock_region->nid defined only for CONFIG_NUMA.
> > memblock_get_region_node would then unconditionally return 0 on UMA.
> > Essentially the same way we do NUMA for other MM code. I only see few
> > direct usage of region->nid.
>
> Checked code again, seems HAVE_MEMBLOCK_NODE_MAP is selected directly in
> all ARCHes which support it. Means HAVE_MEMBLOCK_NODE_MAP is enabled by
> default on those ARCHes, and has no dependency on CONFIG_NUMA at all.
> E.g on x86, it just calls free_area_init_nodes() in generic code path,
> while free_area_init_nodes() is defined in CONFIG_HAVE_MEMBLOCK_NODE_MAP
> ifdeffery scope. So I tend to agree with Mike to remove
> HAVE_MEMBLOCK_NODE_MAP firstly on all ARCHes. We can check if it's worth
> only defining memblock_region->nid for CONFIG_NUMA case after
> HAVE_MEMBLOCK_NODE_MAP is removed.
This can surely go in separate patches. What I meant to say is the
region->nid is by definition 0 on !CONFIG_NUMA.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Daniel Vetter @ 2020-04-09 14:57 UTC (permalink / raw)
To: Alex Deucher
Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan,
Christoph Hellwig, open list:GENERIC INCLUDE/A..., linux-s390,
Wei Liu, Stephen Hemminger, X86 ML, Peter Zijlstra, Laura Abbott,
Nitin Gupta, Haiyang Zhang,
moderated list:DMA BUFFER SHARING FRAMEWORK, Andrew Morton,
Linux ARM, linuxppc-dev, Linux Kernel Mailing List, Minchan Kim,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Sakari Ailus, bpf, Robin Murphy
In-Reply-To: <CADnq5_MjTSm6j=_8huVQ854H6jXY5Rg36wc31QDfOpfjfscWxA@mail.gmail.com>
On Thu, Apr 9, 2020 at 4:19 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>
> On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
> > <benh@kernel.crashing.org> wrote:
> > >
> > > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > > > If this code was broken for non-coherent caches a crude powerpc hack
> > > > > isn't going to help anyone else. Remove the hack as it is the last
> > > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> > > >
> > > > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > > > layer in drm from back then isn't going to work in other places. I guess
> > > > should have at least an ack from him, in case anyone still cares about
> > > > this on ppc. Adding Ben to cc.
> > >
> > > This was due to some drivers (radeon ?) trying to use vmalloc pages for
> > > coherent DMA, which means on those 4xx powerpc's need to be non-cached.
> > >
> > > There were machines using that (440 based iirc), though I honestly
> > > can't tell if anybody still uses any of it.
> >
> > agp subsystem still seems to happily do that (vmalloc memory for
> > device access), never having been ported to dma apis (or well
> > converted to iommu drivers, which they kinda are really). So I think
> > this all still works exactly as back then, even with the kms radeon
> > drivers. Question really is whether we have users left, and I have no
> > clue about that either.
> >
> > Now if these boxes didn't ever have agp then I think we can get away
> > with deleting this, since we've already deleted the legacy radeon
> > driver. And that one used vmalloc for everything. The new kms one does
> > use the dma-api if the gpu isn't connected through agp.
>
> All radeons have a built in remapping table to handle non-AGP systems.
> On the earlier radeons it wasn't quite as performant as AGP, but it
> was always more reliable because AGP is AGP. Maybe it's time to let
> AGP go?
I'd be very much in favour of that, if we can just use the integrated
gart and drop agp fast writes wobbliness on the floor. I think the
only other modern driver using agp would be nouveau at that point.
-Daniel
>
> Alex
>
> > -Daniel
> >
> > > Cheers,
> > > Ben.
> > >
> > > > -Daniel
> > > >
> > > > >
> > > > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > > > ---
> > > > > drivers/gpu/drm/drm_scatter.c | 11 +----------
> > > > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > > > > index ca520028b2cb..f4e6184d1877 100644
> > > > > --- a/drivers/gpu/drm/drm_scatter.c
> > > > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > > > @@ -43,15 +43,6 @@
> > > > >
> > > > > #define DEBUG_SCATTER 0
> > > > >
> > > > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > > > -{
> > > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > > > > -#else
> > > > > - return vmalloc_32(size);
> > > > > -#endif
> > > > > -}
> > > > > -
> > > > > static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > > > {
> > > > > struct page *page;
> > > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
> > > > > return -ENOMEM;
> > > > > }
> > > > >
> > > > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > > > if (!entry->virtual) {
> > > > > kfree(entry->busaddr);
> > > > > kfree(entry->pagelist);
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v3] powerpc/fadump: fix race between pstore write and fadump crash trigger
From: Sourabh Jain @ 2020-04-09 14:54 UTC (permalink / raw)
To: mpe; +Cc: mahesh, linux-kernel, hbathini, linuxppc-dev
When we enter into fadump crash path via system reset we fail to update
the pstore.
On the system reset path we first update the pstore then we go for fadump
crash. But the problem here is when all the CPUs try to get the pstore
lock to initiate the pstore write, only one CPUs will acquire the lock
and proceed with the pstore write. Since it in NMI context CPUs that fail
to get lock do not wait for their turn to write to the pstore and simply
proceed with the next operation which is fadump crash. One of the CPU who
proceeded with fadump crash path triggers the crash and does not wait for
the CPU who gets the pstore lock to complete the pstore update.
Timeline diagram to depicts the sequence of events that leads to an
unsuccessful pstore update when we hit fadump crash path via system reset.
1 2 3 ... n CPU Threads
| | | |
| | | |
Reached to -->|--->|---->| ----------->|
system reset | | | |
path | | | |
| | | |
Try to -->|--->|---->|------------>|
acquire the | | | |
pstore lock | | | |
| | | |
| | | |
Got the -->| +->| | |<-+
pstore lock | | | | | |--> Didn't get the
| --------------------------+ lock and moving
| | | | ahead on fadump
| | | | crash path
| | | |
Begins the -->| | | |
process to | | | |<-- Got the chance to
update the | | | | trigger the crash
pstore | -> | | ... <- |
| | | | | |
| | | | | |<-- Triggers the
| | | | | | crash
| | | | | | ^
| | | | | | |
Writing to -->| | | | | | |
pstore | | | | | | |
| | |
^ |__________________| |
| CPU Relax |
| |
+-----------------------------------------+
|
v
Race: crash triggered before pstore
update completes
To avoid the race between the CPU who proceeds with the pstore and the CPU
who triggers the crash, a delay of 500 milliseconds is added on fadump
crash path to allow pstore update to complete before we trigger the crash.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
arch/powerpc/kernel/fadump.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
---
Changelog:
v1 -> v2
- crash delay has been increased to 500 milliseconds
- race happens in NMI context so updated the commit
message to convey the same.
v2 -> v3
- Evaluate trap register value with updated pt_regs pointer to
avoid NULL pointer dereference
---
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index ff0114aeba9b..1bf1e4c646ed 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -32,6 +32,16 @@
#include <asm/fadump-internal.h>
#include <asm/setup.h>
+
+/*
+ * The CPU who acquired the lock to trigger the fadump crash should
+ * wait for other CPUs to complete their tasks (for example updating
+ * pstore) before triggering the crash.
+ *
+ * The timeout is in milliseconds.
+ */
+#define CRASH_TIMEOUT 500
+
static struct fw_dump fw_dump;
static void __init fadump_reserve_crash_area(u64 base);
@@ -634,6 +644,13 @@ void crash_fadump(struct pt_regs *regs, const char *str)
fdh->online_mask = *cpu_online_mask;
+ /*
+ * If we came in via system reset, wait a while for the secondary
+ * CPUs to enter.
+ */
+ if (TRAP(&(fdh->regs)) == 0x100)
+ mdelay(CRASH_TIMEOUT);
+
fw_dump.ops->fadump_trigger(fdh, str);
}
--
2.21.1
^ permalink raw reply related
* Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)
From: Baoquan He @ 2020-04-09 14:41 UTC (permalink / raw)
To: Mike Rapoport, Michal Hocko
Cc: mmorana, Catalin Marinas, Heiko Carstens,
open list:MEMORY MANAGEMENT, Paul Mackerras, H. Peter Anvin,
sparclinux, Alexander Duyck, linux-s390, x86,
Christian Borntraeger, Ingo Molnar, Hoan Tran, Pavel Tatashin,
lho, Vasily Gorbik, Vlastimil Babka, Will Deacon, Borislav Petkov,
Thomas Gleixner, linux-arm-kernel, Oscar Salvador, linux-kernel,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200402080144.GK22681@dhcp22.suse.cz>
On 04/02/20 at 10:01am, Michal Hocko wrote:
> On Wed 01-04-20 10:51:55, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote:
> [...]
> > > From above information, we can remove HAVE_MEMBLOCK_NODE_MAP, and
> > > replace it with CONFIG_NUMA. That sounds more sensible to store nid into
> > > memblock when NUMA support is enabled.
> >
> > Replacing CONFIG_HAVE_MEMBLOCK_NODE_MAP with CONFIG_NUMA will work, but
> > this will not help cleaning up the whole node/zone initialization mess and
> > we'll be stuck with two implementations.
>
> Yeah, this is far from optimal.
>
> > The overhead of enabling HAVE_MEMBLOCK_NODE_MAP is only for init time as
> > most architectures will anyway discard the entire memblock, so having it in
> > a UMA arch won't be a problem. The only exception is arm that uses
> > memblock for pfn_valid(), here we may also think about a solution to
> > compensate the addition of nid to the memblock structures.
>
> Well, we can make memblock_region->nid defined only for CONFIG_NUMA.
> memblock_get_region_node would then unconditionally return 0 on UMA.
> Essentially the same way we do NUMA for other MM code. I only see few
> direct usage of region->nid.
Checked code again, seems HAVE_MEMBLOCK_NODE_MAP is selected directly in
all ARCHes which support it. Means HAVE_MEMBLOCK_NODE_MAP is enabled by
default on those ARCHes, and has no dependency on CONFIG_NUMA at all.
E.g on x86, it just calls free_area_init_nodes() in generic code path,
while free_area_init_nodes() is defined in CONFIG_HAVE_MEMBLOCK_NODE_MAP
ifdeffery scope. So I tend to agree with Mike to remove
HAVE_MEMBLOCK_NODE_MAP firstly on all ARCHes. We can check if it's worth
only defining memblock_region->nid for CONFIG_NUMA case after
HAVE_MEMBLOCK_NODE_MAP is removed.
config X86
def_bool y
...
select HAVE_MEMBLOCK_NODE_MAP
...
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Alex Deucher @ 2020-04-09 14:19 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan,
Christoph Hellwig, open list:GENERIC INCLUDE/A..., linux-s390,
Wei Liu, Stephen Hemminger, X86 ML, Peter Zijlstra, Laura Abbott,
Nitin Gupta, Haiyang Zhang,
moderated list:DMA BUFFER SHARING FRAMEWORK, Andrew Morton,
Linux ARM, linuxppc-dev, Linux Kernel Mailing List, Minchan Kim,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Sakari Ailus, bpf, Robin Murphy
In-Reply-To: <CAKMK7uHtkLvdsWFGiAtkzVa5mpnDvXkn3CHZQ6bgJ_enbyAc8A@mail.gmail.com>
On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > > If this code was broken for non-coherent caches a crude powerpc hack
> > > > isn't going to help anyone else. Remove the hack as it is the last
> > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> > >
> > > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > > layer in drm from back then isn't going to work in other places. I guess
> > > should have at least an ack from him, in case anyone still cares about
> > > this on ppc. Adding Ben to cc.
> >
> > This was due to some drivers (radeon ?) trying to use vmalloc pages for
> > coherent DMA, which means on those 4xx powerpc's need to be non-cached.
> >
> > There were machines using that (440 based iirc), though I honestly
> > can't tell if anybody still uses any of it.
>
> agp subsystem still seems to happily do that (vmalloc memory for
> device access), never having been ported to dma apis (or well
> converted to iommu drivers, which they kinda are really). So I think
> this all still works exactly as back then, even with the kms radeon
> drivers. Question really is whether we have users left, and I have no
> clue about that either.
>
> Now if these boxes didn't ever have agp then I think we can get away
> with deleting this, since we've already deleted the legacy radeon
> driver. And that one used vmalloc for everything. The new kms one does
> use the dma-api if the gpu isn't connected through agp.
All radeons have a built in remapping table to handle non-AGP systems.
On the earlier radeons it wasn't quite as performant as AGP, but it
was always more reliable because AGP is AGP. Maybe it's time to let
AGP go?
Alex
> -Daniel
>
> > Cheers,
> > Ben.
> >
> > > -Daniel
> > >
> > > >
> > > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > > ---
> > > > drivers/gpu/drm/drm_scatter.c | 11 +----------
> > > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > > > index ca520028b2cb..f4e6184d1877 100644
> > > > --- a/drivers/gpu/drm/drm_scatter.c
> > > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > > @@ -43,15 +43,6 @@
> > > >
> > > > #define DEBUG_SCATTER 0
> > > >
> > > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > > -{
> > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > > > -#else
> > > > - return vmalloc_32(size);
> > > > -#endif
> > > > -}
> > > > -
> > > > static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > > {
> > > > struct page *page;
> > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
> > > > return -ENOMEM;
> > > > }
> > > >
> > > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > > if (!entry->virtual) {
> > > > kfree(entry->busaddr);
> > > > kfree(entry->pagelist);
> > > > --
> > > > 2.25.1
> > > >
> > >
> > >
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: Linux-next POWER9 NULL pointer NIP since 1st Apr.
From: Steven Rostedt @ 2020-04-09 14:14 UTC (permalink / raw)
To: Qian Cai; +Cc: linuxppc-dev, LKML, Nicholas Piggin
In-Reply-To: <EA9F9A54-87BC-477A-BE8A-7D53F80C5223@lca.pw>
On Thu, 9 Apr 2020 06:06:35 -0400
Qian Cai <cai@lca.pw> wrote:
> >> I’ll go to bisect some more but it is going to take a while.
> >>
> >> $ git log --oneline 4c205c84e249..8e99cf91b99b
> >> 8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in atomic
> >> 2ab2a0924b99 tracing: Add documentation on set_ftrace_notrace_pid and set_event_notrace_pid
> >> ebed9628f5c2 selftests/ftrace: Add test to test new set_event_notrace_pid file
> >> ed8839e072b8 selftests/ftrace: Add test to test new set_ftrace_notrace_pid file
> >> 276836260301 tracing: Create set_event_notrace_pid to not trace tasks
> >
> >> b3b1e6ededa4 ftrace: Create set_ftrace_notrace_pid to not trace tasks
> >> 717e3f5ebc82 ftrace: Make function trace pid filtering a bit more exact
> >
> > If it is affecting function tracing, it is probably one of the above two
> > commits.
>
> OK, it was narrowed down to one of those messed with mcount here,
Thing is, nothing here touches mcount.
>
> 8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in atomic
Touches reading the trace buffer.
> 2ab2a0924b99 tracing: Add documentation on set_ftrace_notrace_pid and set_event_notrace_pid
Documentation.
> 6a13a0d7b4d1 ftrace/kprobe: Show the maxactive number on kprobe_events
kprobe output.
> c9b7a4a72ff6 ring-buffer/tracing: Have iterator acknowledge dropped events
Reading the buffer.
> 06e0a548bad0 tracing: Do not disable tracing when reading the trace file
Reading the buffer.
> 1039221cc278 ring-buffer: Do not disable recording when there is an iterator
Reading the buffer.
> 07b8b10ec94f ring-buffer: Make resize disable per cpu buffer instead of total buffer
Resizing the buffer.
> 153368ce1bd0 ring-buffer: Optimize rb_iter_head_event()
Reading the buffer.
> ff84c50cfb4b ring-buffer: Do not die if rb_iter_peek() fails more than thrice
Reading the buffer.
> 785888c544e0 ring-buffer: Have rb_iter_head_event() handle concurrent writer
Reading the buffer.
> 28e3fc56a471 ring-buffer: Add page_stamp to iterator for synchronization
Reading the buffer.
> bc1a72afdc4a ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance()
Reading the buffer.
> ead6ecfddea5 ring-buffer: Have ring_buffer_empty() not depend on tracing stopped
Reading the buffer.
> ff895103a84a tracing: Save off entry when peeking at next entry
Reading the buffer.
> bf2cbe044da2 tracing: Use address-of operator on section symbols
Affects trace_printk()
> bbd9d05618a6 gpu/trace: add a gpu total memory usage tracepoint
New tracepoint infrastructure (just new trace events for gpu)
> 89b74cac7834 tools/bootconfig: Show line and column in parse error
Extended command line boot config.
> 306b69dce926 bootconfig: Support O=<builddir> option
Extended command line boot config
> 5412e0b763e0 tracing: Remove unused TRACE_BUFFER bits
Removed unused enums.
> b396bfdebffc tracing: Have hwlat ts be first instance and record count of instances
Affects only the hard ware latency detector (most likely not even
configured in the kernel).
So I don't understand how any of the above commits can cause a problem.
-- Steve
^ permalink raw reply
* Re: [PATCH v1 1/2] powerpc/pseries/hotplug-memory: stop checking is_mem_section_removable()
From: piliu @ 2020-04-09 14:01 UTC (permalink / raw)
To: David Hildenbrand, Baoquan He
Cc: Michal Hocko, linux-kernel, Wei Yang, linux-mm, Paul Mackerras,
Nathan Fontenot, Andrew Morton, linuxppc-dev, Oscar Salvador
In-Reply-To: <85637e60-4d11-2b69-f2a9-1505e0342ce3@redhat.com>
On 04/09/2020 03:26 PM, David Hildenbrand wrote:
> On 09.04.20 04:59, piliu wrote:
>>
>>
>> On 04/08/2020 10:46 AM, Baoquan He wrote:
>>> Add Pingfan to CC since he usually handles ppc related bugs for RHEL.
>>>
>>> On 04/07/20 at 03:54pm, David Hildenbrand wrote:
>>>> In commit 53cdc1cb29e8 ("drivers/base/memory.c: indicate all memory
>>>> blocks as removable"), the user space interface to compute whether a memory
>>>> block can be offlined (exposed via
>>>> /sys/devices/system/memory/memoryX/removable) has effectively been
>>>> deprecated. We want to remove the leftovers of the kernel implementation.
>>>
>>> Pingfan, can you have a look at this change on PPC? Please feel free to
>>> give comments if any concern, or offer ack if it's OK to you.
>>>
>>>>
>>>> When offlining a memory block (mm/memory_hotplug.c:__offline_pages()),
>>>> we'll start by:
>>>> 1. Testing if it contains any holes, and reject if so
>>>> 2. Testing if pages belong to different zones, and reject if so
>>>> 3. Isolating the page range, checking if it contains any unmovable pages
>>>>
>>>> Using is_mem_section_removable() before trying to offline is not only racy,
>>>> it can easily result in false positives/negatives. Let's stop manually
>>>> checking is_mem_section_removable(), and let device_offline() handle it
>>>> completely instead. We can remove the racy is_mem_section_removable()
>>>> implementation next.
>>>>
>>>> We now take more locks (e.g., memory hotplug lock when offlining and the
>>>> zone lock when isolating), but maybe we should optimize that
>>>> implementation instead if this ever becomes a real problem (after all,
>>>> memory unplug is already an expensive operation). We started using
>>>> is_mem_section_removable() in commit 51925fb3c5c9 ("powerpc/pseries:
>>>> Implement memory hotplug remove in the kernel"), with the initial
>>>> hotremove support of lmbs.
>>>>
>>>> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
>>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>> Cc: Paul Mackerras <paulus@samba.org>
>>>> Cc: Michal Hocko <mhocko@suse.com>
>>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>>> Cc: Oscar Salvador <osalvador@suse.de>
>>>> Cc: Baoquan He <bhe@redhat.com>
>>>> Cc: Wei Yang <richard.weiyang@gmail.com>
>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>>> ---
>>>> .../platforms/pseries/hotplug-memory.c | 26 +++----------------
>>>> 1 file changed, 3 insertions(+), 23 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
>>>> index b2cde1732301..5ace2f9a277e 100644
>>>> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
>>>> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
>>>> @@ -337,39 +337,19 @@ static int pseries_remove_mem_node(struct device_node *np)
>>>>
>>>> static bool lmb_is_removable(struct drmem_lmb *lmb)
>>>> {
>>>> - int i, scns_per_block;
>>>> - bool rc = true;
>>>> - unsigned long pfn, block_sz;
>>>> - u64 phys_addr;
>>>> -
>>>> if (!(lmb->flags & DRCONF_MEM_ASSIGNED))
>>>> return false;
>>>>
>>>> - block_sz = memory_block_size_bytes();
>>>> - scns_per_block = block_sz / MIN_MEMORY_BLOCK_SIZE;
>>>> - phys_addr = lmb->base_addr;
>>>> -
>>>> #ifdef CONFIG_FA_DUMP
>>>> /*
>>>> * Don't hot-remove memory that falls in fadump boot memory area
>>>> * and memory that is reserved for capturing old kernel memory.
>>>> */
>>>> - if (is_fadump_memory_area(phys_addr, block_sz))
>>>> + if (is_fadump_memory_area(lmb->base_addr, memory_block_size_bytes()))
>>>> return false;
>>>> #endif
>>>> -
>>>> - for (i = 0; i < scns_per_block; i++) {
>>>> - pfn = PFN_DOWN(phys_addr);
>>>> - if (!pfn_in_present_section(pfn)) {
>>>> - phys_addr += MIN_MEMORY_BLOCK_SIZE;
>>>> - continue;
>>>> - }
>>>> -
>>>> - rc = rc && is_mem_section_removable(pfn, PAGES_PER_SECTION);
>>>> - phys_addr += MIN_MEMORY_BLOCK_SIZE;
>>>> - }
>>>> -
>>>> - return rc;
>>>> + /* device_offline() will determine if we can actually remove this lmb */
>>>> + return true;
>> So I think here swaps the check and do sequence. At least it breaks
>> dlpar_memory_remove_by_count(). It is doable to remove
>> is_mem_section_removable(), but here should be more effort to re-arrange
>> the code.
>>
>
> Thanks Pingfan,
>
> 1. "swaps the check and do sequence":
>
> Partially. Any caller of dlpar_remove_lmb() already has to deal with
> false positives. device_offline() can easily fail after
> dlpar_remove_lmb() == true. It's inherently racy.
>
> 2. "breaks dlpar_memory_remove_by_count()"
>
> Can you elaborate why it "breaks" it? It will simply try to
> offline+remove lmbs, detect that it wasn't able to offline+remove as
> much as it wanted (which could happen before as well easily), and re-add
> the already offlined+removed ones.
>
I overlooked the re-add logic. Then I think
dlpar_memory_remove_by_count() is OK with this patch.
> 3. "more effort to re-arrange the code"
>
> What would be your suggestion?
>
I had thought about merging the two loop "for_each_drmem_lmb()", and do
check inside the loop. But now it is needless.
The only concerned left is "if (lmbs_available < lmbs_to_remove)" fails
to alarm due to the weaken checking in lmb_is_removable(). Then after
heavy migration in offline_pages, we encounters this limit, and need to
re-add them back.
But I think it is a rare case plus hot-remove is also not a quite
frequent event. So it is worth to simplify the code by this patch.
Thanks for your classification.
For [1/2]
Reviewed-by: Pingfan Liu <piliu@redhat.com>
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Gerhard Pircher @ 2020-04-09 11:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Daniel Vetter, Christoph Hellwig
Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan,
Sumit Semwal, linux-arch, linux-s390, Wei Liu, Stephen Hemminger,
x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang,
linaro-mm-sig, Andrew Morton, linux-arm-kernel, linuxppc-dev,
linux-kernel, Minchan Kim, iommu, Sakari Ailus, bpf, Robin Murphy
In-Reply-To: <eb48f7b6327e482ea9911b129210c0417ab48345.camel@kernel.crashing.org>
Am 09.04.20 um 10:54 schrieb Benjamin Herrenschmidt:
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
>> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
>>> If this code was broken for non-coherent caches a crude powerpc hack
>>> isn't going to help anyone else. Remove the hack as it is the last
>>> user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
>>
>> Well Ben added this to make stuff work on ppc, ofc the home grown dma
>> layer in drm from back then isn't going to work in other places. I guess
>> should have at least an ack from him, in case anyone still cares about
>> this on ppc. Adding Ben to cc.
>
> This was due to some drivers (radeon ?) trying to use vmalloc pages for
> coherent DMA, which means on those 4xx powerpc's need to be non-cached.
>
> There were machines using that (440 based iirc), though I honestly
> can't tell if anybody still uses any of it.
The first-gen amigaone platform (6xx/book32s) uses the radeon driver
together with non-coherent DMA. However this only ever worked reliably
for DRI1.
br,
Gerhard
> Cheers,
> Ben.
>
>> -Daniel
>>
>>>
>>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>>> ---
>>> drivers/gpu/drm/drm_scatter.c | 11 +----------
>>> 1 file changed, 1 insertion(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
>>> index ca520028b2cb..f4e6184d1877 100644
>>> --- a/drivers/gpu/drm/drm_scatter.c
>>> +++ b/drivers/gpu/drm/drm_scatter.c
>>> @@ -43,15 +43,6 @@
>>>
>>> #define DEBUG_SCATTER 0
>>>
>>> -static inline void *drm_vmalloc_dma(unsigned long size)
>>> -{
>>> -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
>>> - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
>>> -#else
>>> - return vmalloc_32(size);
>>> -#endif
>>> -}
>>> -
>>> static void drm_sg_cleanup(struct drm_sg_mem * entry)
>>> {
>>> struct page *page;
>>> @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
>>> return -ENOMEM;
>>> }
>>>
>>> - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
>>> + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
>>> if (!entry->virtual) {
>>> kfree(entry->busaddr);
>>> kfree(entry->pagelist);
>>> --
>>> 2.25.1
>>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH 03/35] docs: fix broken references to text files
From: Federico Vaga @ 2020-04-09 7:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: kvm, Linux Doc Mailing List, Peter Zijlstra, Akira Yokosawa,
dri-devel, linux-unionfs, linux-mm, Harry Wei, Alex Shi,
Will Deacon, kvmarm, linux-arch, Jason Gunthorpe, Jonathan Corbet,
linux-rdma, kvm-ppc, David Airlie, Doug Ledford, Alan Stern,
linux-arm-kernel, Jade Alglave, Daniel Lustig, Julien Thierry,
Mike Leach, Andrea Parri, Daniel Vetter, Paul E. McKenney,
Suzuki K Poulose, Boqun Feng, Maarten Lankhorst, Nicholas Piggin,
Maxime Ripard, Luc Maranget, OGAWA Hirofumi, David Howells,
Mathieu Poirier, Miklos Szeredi, linux-kernel, Alexander Shishkin,
James Morse, Thomas Zimmermann, Marc Zyngier, linux-fsdevel,
Paolo Bonzini, Andrew Morton, linuxppc-dev
In-Reply-To: <2e12bf13355bd06748fed5d135fd4de3d94ad5fd.1586359676.git.mchehab+huawei@kernel.org>
On Wednesday, April 8, 2020 5:45:55 PM CEST Mauro Carvalho Chehab wrote:
> Several references got broken due to txt to ReST conversion.
>
> Several of them can be automatically fixed with:
>
> scripts/documentation-file-ref-check --fix
>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> #
> hwtracing/coresight/Kconfig Signed-off-by: Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org>
> ---
> Documentation/memory-barriers.txt | 2 +-
> Documentation/process/submit-checklist.rst | 2 +-
> .../translations/it_IT/process/submit-checklist.rst | 2 +-
Acked-by: Federico Vaga <federico.vaga@vaga.pv.it>
^ permalink raw reply
* Re: [PATCH] powerpcs: perf: consolidate perf_callchain_user_64 and perf_callchain_user_32
From: Michal Suchánek @ 2020-04-09 11:22 UTC (permalink / raw)
To: Christophe Leroy
Cc: Mark Rutland, Peter Zijlstra, Jiri Olsa, linux-kernel,
Arnaldo Carvalho de Melo, Alexander Shishkin, Ingo Molnar,
Paul Mackerras, Nicholas Piggin, Namhyung Kim, linuxppc-dev
In-Reply-To: <8786906b-edd5-e4a3-8286-33a05f39668c@c-s.fr>
On Tue, Apr 07, 2020 at 07:21:06AM +0200, Christophe Leroy wrote:
>
>
> Le 06/04/2020 à 23:00, Michal Suchanek a écrit :
> > perf_callchain_user_64 and perf_callchain_user_32 are nearly identical.
> > Consolidate into one function with thin wrappers.
> >
> > Suggested-by: Nicholas Piggin <npiggin@gmail.com>
> > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > ---
> > arch/powerpc/perf/callchain.h | 24 +++++++++++++++++++++++-
> > arch/powerpc/perf/callchain_32.c | 21 ++-------------------
> > arch/powerpc/perf/callchain_64.c | 14 ++++----------
> > 3 files changed, 29 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/powerpc/perf/callchain.h b/arch/powerpc/perf/callchain.h
> > index 7a2cb9e1181a..7540bb71cb60 100644
> > --- a/arch/powerpc/perf/callchain.h
> > +++ b/arch/powerpc/perf/callchain.h
> > @@ -2,7 +2,7 @@
> > #ifndef _POWERPC_PERF_CALLCHAIN_H
> > #define _POWERPC_PERF_CALLCHAIN_H
> > -int read_user_stack_slow(void __user *ptr, void *buf, int nb);
> > +int read_user_stack_slow(const void __user *ptr, void *buf, int nb);
>
> Does the constification of ptr has to be in this patch ?
It was in the original patch. The code is touched anyway.
> Wouldn't it be better to have it as a separate patch ?
Don't care much either way. Can resend it as separate patches.
>
> > void perf_callchain_user_64(struct perf_callchain_entry_ctx *entry,
> > struct pt_regs *regs);
> > void perf_callchain_user_32(struct perf_callchain_entry_ctx *entry,
> > @@ -16,4 +16,26 @@ static inline bool invalid_user_sp(unsigned long sp)
> > return (!sp || (sp & mask) || (sp > top));
> > }
> > +/*
> > + * On 32-bit we just access the address and let hash_page create a
> > + * HPTE if necessary, so there is no need to fall back to reading
> > + * the page tables. Since this is called at interrupt level,
> > + * do_page_fault() won't treat a DSI as a page fault.
> > + */
> > +static inline int __read_user_stack(const void __user *ptr, void *ret,
> > + size_t size)
> > +{
> > + int rc;
> > +
> > + if ((unsigned long)ptr > TASK_SIZE - size ||
> > + ((unsigned long)ptr & (size - 1)))
> > + return -EFAULT;
> > + rc = probe_user_read(ret, ptr, size);
> > +
> > + if (rc && IS_ENABLED(CONFIG_PPC64))
>
> gcc is probably smart enough to deal with it efficiently, but it would
> be more correct to test rc after checking CONFIG_PPC64.
IS_ENABLED(CONFIG_PPC64) is constant so that part of the check should be
compiled out in any case.
Thanks
Michal
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.7-2 tag
From: Michael Ellerman @ 2020-04-09 11:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: geert+renesas, aik, linux-kernel, npiggin, geoff, anju, ganeshgr,
msuchanek, linuxppc-dev, elfring, dan.carpenter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some more powerpc updates for 5.7.
The bulk of this is the series to make CONFIG_COMPAT user-selectable, it's been
around for a long time but was blocked behind the syscall-in-C series. Plus
there's also a few fixes and other minor things.
cheers
The following changes since commit c17eb4dca5a353a9dbbb8ad6934fe57af7165e91:
powerpc: Make setjmp/longjmp signature standard (2020-04-01 14:30:51 +1100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.7-2
for you to fetch changes up to 6ba4a2d3591039aea1cb45c7c42262d26351a2fa:
selftests/powerpc: Always build the tm-poison test 64-bit (2020-04-04 21:41:40 +1100)
- ------------------------------------------------------------------
powerpc updates for 5.7 #2
- A fix for a crash in machine check handling on pseries (ie. guests)
- A small series to make it possible to disable CONFIG_COMPAT, and turn it off
by default for ppc64le where it's not used.
- A few other miscellaneous fixes and small improvements.
Thanks to:
Alexey Kardashevskiy, Anju T Sudhakar, Arnd Bergmann, Christophe Leroy, Dan
Carpenter, Ganesh Goudar, Geert Uytterhoeven, Geoff Levand, Mahesh Salgaonkar,
Markus Elfring, Michal Suchanek, Nicholas Piggin, Stephen Boyd, Wen Xiong.
- ------------------------------------------------------------------
Alexey Kardashevskiy (1):
powerpc/pseries/ddw: Extend upper limit for huge DMA window for persistent memory
Anju T Sudhakar (2):
powerpc/perf: Implement a global lock to avoid races between trace, core and thread imc events.
powerpc/powernv: Re-enable imc trace-mode in kernel
Dan Carpenter (1):
powerpc/ps3: Remove an unneeded NULL check
Ganesh Goudar (1):
powerpc/pseries: Fix MCE handling on pseries
Geert Uytterhoeven (1):
powerpc/time: Replace <linux/clk-provider.h> by <linux/of_clk.h>
Geoff Levand (1):
powerpc/ps3: Set CONFIG_UEVENT_HELPER=y in ps3_defconfig
Markus Elfring (1):
powerpc/ps3: Remove duplicate error message
Michael Ellerman (2):
selftests/eeh: Skip ahci adapters
selftests/powerpc: Always build the tm-poison test 64-bit
Michal Suchanek (7):
powerpc: Add back __ARCH_WANT_SYS_LLSEEK macro
powerpc: move common register copy functions from signal_32.c to signal.c
powerpc/perf: consolidate read_user_stack_32
powerpc/perf: consolidate valid_user_sp -> invalid_user_sp
powerpc/64: make buildable without CONFIG_COMPAT
powerpc/64: Make COMPAT user-selectable disabled on littleendian by default.
powerpc/perf: split callchain.c by bitness
Nicholas Piggin (3):
powerpc/64s: Fix doorbell wakeup msgclr optimisation
Revert "powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled"
powerpc: Improve ppc_save_regs()
arch/powerpc/Kconfig | 5 +-
arch/powerpc/configs/ps3_defconfig | 2 +
arch/powerpc/include/asm/thread_info.h | 4 +-
arch/powerpc/include/asm/unistd.h | 1 +
arch/powerpc/kernel/Makefile | 5 +-
arch/powerpc/kernel/entry_64.S | 2 +
arch/powerpc/kernel/exceptions-64s.S | 19 --
arch/powerpc/kernel/irq.c | 13 +
arch/powerpc/kernel/ppc_save_regs.S | 6 +-
arch/powerpc/kernel/ptrace/Makefile | 2 +-
arch/powerpc/kernel/signal.c | 144 +++++++-
arch/powerpc/kernel/signal_32.c | 140 --------
arch/powerpc/kernel/syscall_64.c | 6 +-
arch/powerpc/kernel/time.c | 48 +--
arch/powerpc/kernel/vdso.c | 3 +-
arch/powerpc/perf/Makefile | 5 +-
arch/powerpc/perf/callchain.c | 356 +-------------------
arch/powerpc/perf/callchain.h | 19 ++
arch/powerpc/perf/callchain_32.c | 196 +++++++++++
arch/powerpc/perf/callchain_64.c | 174 ++++++++++
arch/powerpc/perf/imc-pmu.c | 173 ++++++++--
arch/powerpc/platforms/powernv/opal-imc.c | 9 +-
arch/powerpc/platforms/ps3/os-area.c | 4 +-
arch/powerpc/platforms/pseries/iommu.c | 9 +
arch/powerpc/platforms/pseries/ras.c | 11 +
drivers/ps3/sys-manager-core.c | 2 +-
fs/read_write.c | 3 +-
tools/testing/selftests/powerpc/eeh/eeh-basic.sh | 5 +
tools/testing/selftests/powerpc/tm/Makefile | 1 +
29 files changed, 766 insertions(+), 601 deletions(-)
create mode 100644 arch/powerpc/perf/callchain.h
create mode 100644 arch/powerpc/perf/callchain_32.c
create mode 100644 arch/powerpc/perf/callchain_64.c
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl6O+ZoACgkQUevqPMjh
pYBTEA/8Dkp4b60dA28iP/z6XntEIl3QT4rxAa3M89Pws6gxUw6uG5UmvjZe+lAa
IezHEfFx5cwAiXqMIT1NFF4H4QAeOZEN4bq0sIkOPXdme+75oWK4qSGdgXwdTEXr
ssW7I7LPGwMYJZUBhhHkijD0IN7nK2Tdd22Yucj2fGLX2Rzhst4302Dl7CH8SmZf
waoQZBB6PrxV1HxGv92Sb83iuhOqhgAdhwwQS50PVzSPlZH8vBW3HDMIESg9pHWT
NrNq7I8Y0mk6YUfmwWgJbVpqftXInnRjisFNQij7wBYtK8lw/vBOA5j1avqmhkNl
NJPGp5eGkC0MLfsx6qLYC+6FEcAYHfPHAlMpq6/6HvicNmEc0rrHU8dx2owb63p1
ahn57m1JOS1ndITTOWCjDXaOQC/Ho32duWmz6m+HJMD7X7cPH9ITbbKsRZzWP3Zm
5H64UEPsWDeia9c90FqjuA2xYSD4lIGUKAQ6Z73LXmUz2E8fF0/98ZniBvuFM8ce
w/Lg8edlX5Bg9n4elFsCYagHPRK5i9Tmv9Bdnw4tJ30yGPQ86ZLTmaq3ru0lky/1
mQ/Za/1wKydS3rq94Qnhag1EKUghBVgNzwtCACoONsaUHTcf9ybD6dE+riQ5J6VZ
ec3y1+QjyaQMxgJdnafIPAsQ1OH1L5wPZkr0ZKBzy+qAtACeHpE=
=9QaQ
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Linux-next POWER9 NULL pointer NIP since 1st Apr.
From: Qian Cai @ 2020-04-09 10:06 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, LKML, Nicholas Piggin
In-Reply-To: <20200407093054.3eb23e45@gandalf.local.home>
> On Apr 7, 2020, at 9:30 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Tue, 7 Apr 2020 09:01:10 -0400
> Qian Cai <cai@lca.pw> wrote:
>
>> + Steven
>>
>>> On Apr 7, 2020, at 8:42 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>>>
>>> Qian Cai <cai@lca.pw> writes:
>>>> Ever since 1st Apr, linux-next starts to trigger a NULL pointer NIP on POWER9 below using
>>>> this config,
>>>>
>>>> https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config
>>>>
>>>> It takes a while to reproduce, so before I bury myself into bisecting and just send a head-up
>>>> to see if anyone spots anything obvious.
>>>>
>>>> [ 206.744625][T13224] LTP: starting fallocate04
>>>> [ 207.601583][T27684] /dev/zero: Can't open blockdev
>>>> [ 208.674301][T27684] EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem
>>>> [ 208.680347][T27684] BUG: Unable to handle kernel instruction fetch (NULL pointer?)
>>>> [ 208.680383][T27684] Faulting instruction address: 0x00000000
>>>> [ 208.680406][T27684] Oops: Kernel access of bad area, sig: 11 [#1]
>>>> [ 208.680439][T27684] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
>>>> [ 208.680474][T27684] Modules linked in: ext4 crc16 mbcache jbd2 loop kvm_hv kvm ip_tables x_tables xfs sd_mod bnx2x ahci libahci mdio tg3 libata libphy firmware_class dm_mirror dm_region_hash dm_log dm_mod
>>>> [ 208.680576][T27684] CPU: 117 PID: 27684 Comm: fallocate04 Tainted: G W 5.6.0-next-20200401+ #288
>>>> [ 208.680614][T27684] NIP: 0000000000000000 LR: c0080000102c0048 CTR: 0000000000000000
>>>> [ 208.680657][T27684] REGS: c000200361def420 TRAP: 0400 Tainted: G W (5.6.0-next-20200401+)
>>>> [ 208.680700][T27684] MSR: 900000004280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 42022228 XER: 20040000
>>>> [ 208.680760][T27684] CFAR: c00800001032c494 IRQMASK: 0
>>>> [ 208.680760][T27684] GPR00: c0000000005ac3f8 c000200361def6b0 c00000000165c200 c00020107dae0bd0
>>>> [ 208.680760][T27684] GPR04: 0000000000000000 0000000000000400 0000000000000000 0000000000000000
>>>> [ 208.680760][T27684] GPR08: c000200361def6e8 c0080000102c0040 000000007fffffff c000000001614e80
>>>> [ 208.680760][T27684] GPR12: 0000000000000000 c000201fff671280 0000000000000000 0000000000000002
>>>> [ 208.680760][T27684] GPR16: 0000000000000002 0000000000040001 c00020030f5a1000 c00020030f5a1548
>>>> [ 208.680760][T27684] GPR20: c0000000015fbad8 c00000000168c654 c000200361def818 c0000000005b4c10
>>>> [ 208.680760][T27684] GPR24: 0000000000000000 c0080000103365b8 c00020107dae0bd0 0000000000000400
>>>> [ 208.680760][T27684] GPR28: c00000000168c3a8 0000000000000000 0000000000000000 0000000000000000
>>>> [ 208.681014][T27684] NIP [0000000000000000] 0x0
>>>> [ 208.681065][T27684] LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
>>>
>>> That LR looks like it's pointing to the return from _mcount in
>>> ext4_iomap_end(), which means we have probably crashed in ftrace
>>> somewhere.
>>>
>>> Did you have tracing enabled when you ran the test? Or does it do
>>> tracing itself?
>>
>> Yes, it run ftrace at first before running LTP to trigger it,
>>
>> https://github.com/cailca/linux-mm/blob/master/test.sh
>>
>> echo function > /sys/kernel/debug/tracing/current_tracer
>> echo nop > /sys/kernel/debug/tracing/current_tracer
>>
>> There is another crash with even non-NULL NIP, but then symbol behaves weird.
>>
>> # ./scripts/faddr2line vmlinux sysctl_net_busy_read+0x0/0x4
>> skipping sysctl_net_busy_read address at 0xc0000000016804ac due to non-function symbol of type 'D'
>>
>> [ 148.110969][T13115] LTP: starting chown04_16
>> [ 148.255048][T13380] kernel tried to execute exec-protected page (c0000000016804ac) - exploit attempt? (uid: 0)
>> [ 148.255099][T13380] BUG: Unable to handle kernel instruction fetch
>> [ 148.255122][T13380] Faulting instruction address: 0xc0000000016804ac
>> [ 148.255136][T13380] Oops: Kernel access of bad area, sig: 11 [#1]
>> [ 148.255157][T13380] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
>> [ 148.255171][T13380] Modules linked in: loop kvm_hv kvm xfs sd_mod bnx2x mdio ahci tg3 libahci libphy libata firmware_class dm_mirror dm_region_hash dm_log dm_mod
>> [ 148.255213][T13380] CPU: 45 PID: 13380 Comm: chown04_16 Tainted: G W 5.6.0+ #7
>> [ 148.255236][T13380] NIP: c0000000016804ac LR: c00800000fa60408 CTR: c0000000016804ac
>> [ 148.255250][T13380] REGS: c0000010a6fafa00 TRAP: 0400 Tainted: G W (5.6.0+)
>> [ 148.255281][T13380] MSR: 9000000010009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 84000248 XER: 20040000
>> [ 148.255310][T13380] CFAR: c00800000fa66534 IRQMASK: 0
>> [ 148.255310][T13380] GPR00: c000000000973268 c0000010a6fafc90 c000000001648200 0000000000000000
>> [ 148.255310][T13380] GPR04: c000000d8a22dc00 c0000010a6fafd30 00000000b5e98331 ffffffff00012c9f
>> [ 148.255310][T13380] GPR08: c000000d8a22dc00 0000000000000000 0000000000000000 c00000000163c520
>> [ 148.255310][T13380] GPR12: c0000000016804ac c000001ffffdad80 0000000000000000 0000000000000000
>> [ 148.255310][T13380] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 148.255310][T13380] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 148.255310][T13380] GPR24: 00007fff8f5e2e48 0000000000000000 c00800000fa6a488 c0000010a6fafd30
>> [ 148.255310][T13380] GPR28: 0000000000000000 000000007fffffff c00800000fa60400 c000000efd0c6780
>> [ 148.255494][T13380] NIP [c0000000016804ac] sysctl_net_busy_read+0x0/0x4
>> [ 148.255516][T13380] LR [c00800000fa60408] find_free_cb+0x8/0x30 [loop]
>> [ 148.255528][T13380] Call Trace:
>> [ 148.255538][T13380] [c0000010a6fafc90] [c0000000009732c0] idr_for_each+0xf0/0x170 (unreliable)
>> [ 148.255572][T13380] [c0000010a6fafd10] [c00800000fa626c4] loop_lookup.part.1+0x4c/0xb0 [loop]
>> [ 148.255597][T13380] [c0000010a6fafd50] [c00800000fa634d8] loop_control_ioctl+0x120/0x1d0 [loop]
>> [ 148.255623][T13380] [c0000010a6fafdb0] [c0000000004ddc08] ksys_ioctl+0xd8/0x130
>> [ 148.255636][T13380] [c0000010a6fafe00] [c0000000004ddc88] sys_ioctl+0x28/0x40
>> [ 148.255669][T13380] [c0000010a6fafe20] [c00000000000b378] system_call+0x5c/0x68
>> [ 148.255699][T13380] Instruction dump:
>> [ 148.255718][T13380] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
>> [ 148.255744][T13380] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
>> [ 148.255772][T13380] ---[ end trace a5894a74208c22ec ]---
>> [ 148.576663][T13380]
>> [ 149.576765][T13380] Kernel panic - not syncing: Fatal exception
>>
>> The bisect so far indicated the bad ones always have this,
>>
>> aa1a8ce53332 Merge tag 'trace-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
>>
>> I’ll go to bisect some more but it is going to take a while.
>>
>> $ git log --oneline 4c205c84e249..8e99cf91b99b
>> 8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in atomic
>> 2ab2a0924b99 tracing: Add documentation on set_ftrace_notrace_pid and set_event_notrace_pid
>> ebed9628f5c2 selftests/ftrace: Add test to test new set_event_notrace_pid file
>> ed8839e072b8 selftests/ftrace: Add test to test new set_ftrace_notrace_pid file
>> 276836260301 tracing: Create set_event_notrace_pid to not trace tasks
>
>> b3b1e6ededa4 ftrace: Create set_ftrace_notrace_pid to not trace tasks
>> 717e3f5ebc82 ftrace: Make function trace pid filtering a bit more exact
>
> If it is affecting function tracing, it is probably one of the above two
> commits.
OK, it was narrowed down to one of those messed with mcount here,
8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in atomic
2ab2a0924b99 tracing: Add documentation on set_ftrace_notrace_pid and set_event_notrace_pid
6a13a0d7b4d1 ftrace/kprobe: Show the maxactive number on kprobe_events
c9b7a4a72ff6 ring-buffer/tracing: Have iterator acknowledge dropped events
06e0a548bad0 tracing: Do not disable tracing when reading the trace file
1039221cc278 ring-buffer: Do not disable recording when there is an iterator
07b8b10ec94f ring-buffer: Make resize disable per cpu buffer instead of total buffer
153368ce1bd0 ring-buffer: Optimize rb_iter_head_event()
ff84c50cfb4b ring-buffer: Do not die if rb_iter_peek() fails more than thrice
785888c544e0 ring-buffer: Have rb_iter_head_event() handle concurrent writer
28e3fc56a471 ring-buffer: Add page_stamp to iterator for synchronization
bc1a72afdc4a ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance()
ead6ecfddea5 ring-buffer: Have ring_buffer_empty() not depend on tracing stopped
ff895103a84a tracing: Save off entry when peeking at next entry
bf2cbe044da2 tracing: Use address-of operator on section symbols
bbd9d05618a6 gpu/trace: add a gpu total memory usage tracepoint
89b74cac7834 tools/bootconfig: Show line and column in parse error
306b69dce926 bootconfig: Support O=<builddir> option
5412e0b763e0 tracing: Remove unused TRACE_BUFFER bits
b396bfdebffc tracing: Have hwlat ts be first instance and record count of instances
This time happens with another random NIP.
[ 130.866777][ T8601] LTP: starting chown04_16
[ 131.004754][ T8868] kernel tried to execute exec-protected page (c000000005add4d4) - exploit attempt? (uid: 0)
[ 131.004804][ T8868] BUG: Unable to handle kernel instruction fetch
[ 131.004827][ T8868] Faulting instruction address: 0xc000000005add4d4
[ 131.004850][ T8868] Oops: Kernel access of bad area, sig: 11 [#1]
[ 131.004862][ T8868] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
[ 131.004885][ T8868] Modules linked in: loop kvm_hv kvm ip_tables x_tables xfs sd_mod bnx2x ahci tg3 mdio libahci libphy firmware_class libata dm_mirror dm_region_hash dm_log dm_mod
[ 131.004925][ T8868] CPU: 58 PID: 8868 Comm: chown04_16 Tainted: G W 5.6.0+ #6
[ 131.004939][ T8868] NIP: c000000005add4d4 LR: c00800000fb20408 CTR: c000000005add4d4
[ 131.004962][ T8868] REGS: c000001b3c32fa00 TRAP: 0400 Tainted: G W (5.6.0+)
[ 131.004993][ T8868] MSR: 9000000010009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 84000248 XER: 20040000
[ 131.005031][ T8868] CFAR: c00800000fb26534 IRQMASK: 0
[ 131.005031][ T8868] GPR00: c00000000097c638 c000001b3c32fc90 c000000001659400 0000000000000000
[ 131.005031][ T8868] GPR04: c00000004a96b800 c000001b3c32fd30 000000000b83d6b8 ffffffff000129f4
[ 131.005031][ T8868] GPR08: c00000004a96b800 0000000000000000 0000000000000000 c00000000164d720
[ 131.005031][ T8868] GPR12: c000000005add4d4 c000001ffffd0b00 0000000000000000 0000000000000000
[ 131.005031][ T8868] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 131.005031][ T8868] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 131.005031][ T8868] GPR24: 00007fffa4982d80 0000000000000000 c00800000fb2a488 c000001b3c32fd30
[ 131.005031][ T8868] GPR28: 0000000000000000 000000007fffffff c00800000fb20400 c000000335c88790
[ 131.005202][ T8868] NIP [c000000005add4d4] net_msg_warn+0x0/0x4
[ 131.005224][ T8868] LR [c00800000fb20408] find_free_cb+0x8/0x30 [loop]
[ 131.005243][ T8868] Call Trace:
[ 131.005253][ T8868] [c000001b3c32fc90] [c00000000097c690] idr_for_each+0xf0/0x170 (unreliable)
[ 131.005278][ T8868] [c000001b3c32fd10] [c00800000fb226c4] loop_lookup.part.1+0x4c/0xb0 [loop]
[ 131.005311][ T8868] [c000001b3c32fd50] [c00800000fb234d8] loop_control_ioctl+0x120/0x1d0 [loop]
[ 131.005344][ T8868] [c000001b3c32fdb0] [c0000000004dd778] ksys_ioctl+0xd8/0x130
[ 131.005376][ T8868] [c000001b3c32fe00] [c0000000004dd7f8] sys_ioctl+0x28/0x40
[ 131.005399][ T8868] [c000001b3c32fe20] [c00000000000b378] system_call+0x5c/0x68
[ 131.005438][ T8868] Instruction dump:
[ 131.005465][ T8868] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
[ 131.005500][ T8868] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
[ 131.005527][ T8868] ---[ end trace cfaf36049cb72805 ]---
[ 131.117039][ T8868]
[ 132.117139][ T8868] Kernel panic - not syncing: Fatal exception
>>
>>
>>>
>>> cheers
>>>
>>>> [ 208.681091][T27684] Call Trace:
>>>> [ 208.681129][T27684] [c000200361def6b0] [c0000000005ac3bc] iomap_apply+0x20c/0x920 (unreliable) iomap_apply at fs/iomap/apply.c:80 (discriminator 4)
>>>> [ 208.681173][T27684] [c000200361def7f0] [c0000000005b4adc] iomap_bmap+0xfc/0x160 iomap_bmap at fs/iomap/fiemap.c:142
>>>> [ 208.681228][T27684] [c000200361def850] [c0080000102c2c1c] ext4_bmap+0xa4/0x180 [ext4] ext4_bmap at fs/ext4/inode.c:3213
>>>> [ 208.681260][T27684] [c000200361def890] [c0000000004f71fc] bmap+0x4c/0x80
>>>> [ 208.681281][T27684] [c000200361def8c0] [c00800000fdb0acc] jbd2_journal_init_inode+0x44/0x1a0 [jbd2] jbd2_journal_init_inode at fs/jbd2/journal.c:1255
>>>> [ 208.681326][T27684] [c000200361def960] [c00800001031c808] ext4_load_journal+0x440/0x860 [ext4]
>>>> [ 208.681371][T27684] [c000200361defa30] [c008000010322a14] ext4_fill_super+0x342c/0x3ab0 [ext4]
>>>> [ 208.681414][T27684] [c000200361defba0] [c0000000004cb0bc] mount_bdev+0x25c/0x290
>>>> [ 208.681478][T27684] [c000200361defc40] [c008000010310250] ext4_mount+0x28/0x50 [ext4]
>>>> [ 208.681520][T27684] [c000200361defc60] [c00000000053242c] legacy_get_tree+0x4c/0xb0
>>>> [ 208.681556][T27684] [c000200361defc90] [c0000000004c864c] vfs_get_tree+0x4c/0x130
>>>> [ 208.681593][T27684] [c000200361defd00] [c00000000050a1c8] do_mount+0xa18/0xc50
>>>> [ 208.681641][T27684] [c000200361defdd0] [c00000000050a9a8] sys_mount+0x158/0x180
>>>> [ 208.681679][T27684] [c000200361defe20] [c00000000000b3f8] system_call+0x5c/0x68
>>>> [ 208.681726][T27684] Instruction dump:
>>>> [ 208.681747][T27684] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
>>>> [ 208.681797][T27684] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
>>>> [ 208.681839][T27684] ---[ end trace 4e9e2bab7f1d4048 ]---
>>>> [ 208.802259][T27684]
>>>> [ 209.802373][T27684] Kernel panic - not syncing: Fatal exception
>>>>
>>>> [ 215.281666][T16896] LTP: starting chown04_16
>>>> [ 215.424203][T18297] BUG: Unable to handle kernel instruction fetch (NULL pointer?)
>>>> [ 215.424289][T18297] Faulting instruction address: 0x00000000
>>>> [ 215.424313][T18297] Oops: Kernel access of bad area, sig: 11 [#1]
>>>> [ 215.424341][T18297] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
>>>> [ 215.424383][T18297] Modules linked in: loop kvm_hv kvm ip_tables x_tables xfs sd_mod bnx2x mdio tg3 ahci libahci libphy libata firmware_class dm_mirror dm_region_hash dm_log dm_mod
>>>> [ 215.424459][T18297] CPU: 85 PID: 18297 Comm: chown04_16 Tainted: G W 5.6.0-next-20200405+ #3
>>>> [ 215.424489][T18297] NIP: 0000000000000000 LR: c00800000fbc0408 CTR: 0000000000000000
>>>> [ 215.424530][T18297] REGS: c000200b8606f990 TRAP: 0400 Tainted: G W (5.6.0-next-20200405+)
>>>> [ 215.424570][T18297] MSR: 9000000040009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 84000248 XER: 20040000
>>>> [ 215.424619][T18297] CFAR: c00800000fbc64f4 IRQMASK: 0
>>>> [ 215.424619][T18297] GPR00: c0000000006c2238 c000200b8606fc20 c00000000165ce00 0000000000000000
>>>> [ 215.424619][T18297] GPR04: c000201a58106400 c000200b8606fcc0 000000005f037e7d ffffffff00013bfb
>>>> [ 215.424619][T18297] GPR08: c000201a58106400 0000000000000000 0000000000000000 c000000001652ee0
>>>> [ 215.424619][T18297] GPR12: 0000000000000000 c000201fff69a600 0000000000000000 0000000000000000
>>>> [ 215.424619][T18297] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>>> [ 215.424619][T18297] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000007
>>>> [ 215.424619][T18297] GPR24: 0000000000000000 0000000000000000 c00800000fbc8688 c000200b8606fcc0
>>>> [ 215.424619][T18297] GPR28: 0000000000000000 000000007fffffff c00800000fbc0400 c00020068b8c0e70
>>>> [ 215.424914][T18297] NIP [0000000000000000] 0x0
>>>> [ 215.424953][T18297] LR [c00800000fbc0408] find_free_cb+0x8/0x30 [loop]
>>>> find_free_cb at drivers/block/loop.c:2129
>>>> [ 215.424997][T18297] Call Trace:
>>>> [ 215.425036][T18297] [c000200b8606fc20] [c0000000006c2290] idr_for_each+0xf0/0x170 (unreliable)
>>>> [ 215.425073][T18297] [c000200b8606fca0] [c00800000fbc2744] loop_lookup.part.2+0x4c/0xb0 [loop]
>>>> loop_lookup at drivers/block/loop.c:2144
>>>> [ 215.425105][T18297] [c000200b8606fce0] [c00800000fbc3558] loop_control_ioctl+0x120/0x1d0 [loop]
>>>> [ 215.425149][T18297] [c000200b8606fd40] [c0000000004eb688] ksys_ioctl+0xd8/0x130
>>>> [ 215.425190][T18297] [c000200b8606fd90] [c0000000004eb708] sys_ioctl+0x28/0x40
>>>> [ 215.425233][T18297] [c000200b8606fdb0] [c00000000003cc30] system_call_exception+0x110/0x1e0
>>>> [ 215.425274][T18297] [c000200b8606fe20] [c00000000000c9f0] system_call_common+0xf0/0x278
>>>> [ 215.425314][T18297] Instruction dump:
>>>> [ 215.425338][T18297] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
>>>> [ 215.425374][T18297] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
>>>> [ 215.425422][T18297] ---[ end trace ebed248fad431966 ]---
>>>> [ 215.642114][T18297]
>>>> [ 216.642220][T18297] Kernel panic - not syncing: Fatal exception
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Daniel Vetter @ 2020-04-09 9:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan,
Sumit Semwal, open list:GENERIC INCLUDE/A..., linux-s390, Wei Liu,
Stephen Hemminger, X86 ML, Christoph Hellwig, Peter Zijlstra,
Laura Abbott, Nitin Gupta, Haiyang Zhang,
moderated list:DMA BUFFER SHARING FRAMEWORK, bpf, Linux ARM,
Robin Murphy, Linux Kernel Mailing List, Minchan Kim,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Sakari Ailus, Andrew Morton, linuxppc-dev
In-Reply-To: <eb48f7b6327e482ea9911b129210c0417ab48345.camel@kernel.crashing.org>
On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > If this code was broken for non-coherent caches a crude powerpc hack
> > > isn't going to help anyone else. Remove the hack as it is the last
> > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> >
> > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > layer in drm from back then isn't going to work in other places. I guess
> > should have at least an ack from him, in case anyone still cares about
> > this on ppc. Adding Ben to cc.
>
> This was due to some drivers (radeon ?) trying to use vmalloc pages for
> coherent DMA, which means on those 4xx powerpc's need to be non-cached.
>
> There were machines using that (440 based iirc), though I honestly
> can't tell if anybody still uses any of it.
agp subsystem still seems to happily do that (vmalloc memory for
device access), never having been ported to dma apis (or well
converted to iommu drivers, which they kinda are really). So I think
this all still works exactly as back then, even with the kms radeon
drivers. Question really is whether we have users left, and I have no
clue about that either.
Now if these boxes didn't ever have agp then I think we can get away
with deleting this, since we've already deleted the legacy radeon
driver. And that one used vmalloc for everything. The new kms one does
use the dma-api if the gpu isn't connected through agp.
-Daniel
> Cheers,
> Ben.
>
> > -Daniel
> >
> > >
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > ---
> > > drivers/gpu/drm/drm_scatter.c | 11 +----------
> > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > > index ca520028b2cb..f4e6184d1877 100644
> > > --- a/drivers/gpu/drm/drm_scatter.c
> > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > @@ -43,15 +43,6 @@
> > >
> > > #define DEBUG_SCATTER 0
> > >
> > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > -{
> > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > > -#else
> > > - return vmalloc_32(size);
> > > -#endif
> > > -}
> > > -
> > > static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > {
> > > struct page *page;
> > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
> > > return -ENOMEM;
> > > }
> > >
> > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > if (!entry->virtual) {
> > > kfree(entry->busaddr);
> > > kfree(entry->pagelist);
> > > --
> > > 2.25.1
> > >
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v1 1/2] powerpc/pseries/hotplug-memory: stop checking is_mem_section_removable()
From: David Hildenbrand @ 2020-04-09 8:56 UTC (permalink / raw)
To: piliu, Baoquan He
Cc: Michal Hocko, linux-kernel, Wei Yang, linux-mm, Paul Mackerras,
Nathan Fontenot, Andrew Morton, linuxppc-dev, Oscar Salvador
In-Reply-To: <85637e60-4d11-2b69-f2a9-1505e0342ce3@redhat.com>
On 09.04.20 09:26, David Hildenbrand wrote:
> On 09.04.20 04:59, piliu wrote:
>>
>>
>> On 04/08/2020 10:46 AM, Baoquan He wrote:
>>> Add Pingfan to CC since he usually handles ppc related bugs for RHEL.
>>>
>>> On 04/07/20 at 03:54pm, David Hildenbrand wrote:
>>>> In commit 53cdc1cb29e8 ("drivers/base/memory.c: indicate all memory
>>>> blocks as removable"), the user space interface to compute whether a memory
>>>> block can be offlined (exposed via
>>>> /sys/devices/system/memory/memoryX/removable) has effectively been
>>>> deprecated. We want to remove the leftovers of the kernel implementation.
>>>
>>> Pingfan, can you have a look at this change on PPC? Please feel free to
>>> give comments if any concern, or offer ack if it's OK to you.
>>>
>>>>
>>>> When offlining a memory block (mm/memory_hotplug.c:__offline_pages()),
>>>> we'll start by:
>>>> 1. Testing if it contains any holes, and reject if so
>>>> 2. Testing if pages belong to different zones, and reject if so
>>>> 3. Isolating the page range, checking if it contains any unmovable pages
>>>>
>>>> Using is_mem_section_removable() before trying to offline is not only racy,
>>>> it can easily result in false positives/negatives. Let's stop manually
>>>> checking is_mem_section_removable(), and let device_offline() handle it
>>>> completely instead. We can remove the racy is_mem_section_removable()
>>>> implementation next.
>>>>
>>>> We now take more locks (e.g., memory hotplug lock when offlining and the
>>>> zone lock when isolating), but maybe we should optimize that
>>>> implementation instead if this ever becomes a real problem (after all,
>>>> memory unplug is already an expensive operation). We started using
>>>> is_mem_section_removable() in commit 51925fb3c5c9 ("powerpc/pseries:
>>>> Implement memory hotplug remove in the kernel"), with the initial
>>>> hotremove support of lmbs.
>>>>
>>>> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
>>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>> Cc: Paul Mackerras <paulus@samba.org>
>>>> Cc: Michal Hocko <mhocko@suse.com>
>>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>>> Cc: Oscar Salvador <osalvador@suse.de>
>>>> Cc: Baoquan He <bhe@redhat.com>
>>>> Cc: Wei Yang <richard.weiyang@gmail.com>
>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>>> ---
>>>> .../platforms/pseries/hotplug-memory.c | 26 +++----------------
>>>> 1 file changed, 3 insertions(+), 23 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
>>>> index b2cde1732301..5ace2f9a277e 100644
>>>> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
>>>> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
>>>> @@ -337,39 +337,19 @@ static int pseries_remove_mem_node(struct device_node *np)
>>>>
>>>> static bool lmb_is_removable(struct drmem_lmb *lmb)
>>>> {
>>>> - int i, scns_per_block;
>>>> - bool rc = true;
>>>> - unsigned long pfn, block_sz;
>>>> - u64 phys_addr;
>>>> -
>>>> if (!(lmb->flags & DRCONF_MEM_ASSIGNED))
>>>> return false;
>>>>
>>>> - block_sz = memory_block_size_bytes();
>>>> - scns_per_block = block_sz / MIN_MEMORY_BLOCK_SIZE;
>>>> - phys_addr = lmb->base_addr;
>>>> -
>>>> #ifdef CONFIG_FA_DUMP
>>>> /*
>>>> * Don't hot-remove memory that falls in fadump boot memory area
>>>> * and memory that is reserved for capturing old kernel memory.
>>>> */
>>>> - if (is_fadump_memory_area(phys_addr, block_sz))
>>>> + if (is_fadump_memory_area(lmb->base_addr, memory_block_size_bytes()))
>>>> return false;
>>>> #endif
>>>> -
>>>> - for (i = 0; i < scns_per_block; i++) {
>>>> - pfn = PFN_DOWN(phys_addr);
>>>> - if (!pfn_in_present_section(pfn)) {
>>>> - phys_addr += MIN_MEMORY_BLOCK_SIZE;
>>>> - continue;
>>>> - }
>>>> -
>>>> - rc = rc && is_mem_section_removable(pfn, PAGES_PER_SECTION);
>>>> - phys_addr += MIN_MEMORY_BLOCK_SIZE;
>>>> - }
>>>> -
>>>> - return rc;
>>>> + /* device_offline() will determine if we can actually remove this lmb */
>>>> + return true;
>> So I think here swaps the check and do sequence. At least it breaks
>> dlpar_memory_remove_by_count(). It is doable to remove
>> is_mem_section_removable(), but here should be more effort to re-arrange
>> the code.
>>
>
> Thanks Pingfan,
>
> 1. "swaps the check and do sequence":
>
> Partially. Any caller of dlpar_remove_lmb() already has to deal with
> false positives. device_offline() can easily fail after
> dlpar_remove_lmb() == true. It's inherently racy.
Sorry, s/dlpar_remove_lmb/lmb_is_removable/
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Benjamin Herrenschmidt @ 2020-04-09 8:54 UTC (permalink / raw)
To: Daniel Vetter, Christoph Hellwig
Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan,
Sumit Semwal, linux-arch, linux-s390, Wei Liu, Stephen Hemminger,
x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang,
linaro-mm-sig, bpf, linux-arm-kernel, Robin Murphy, linux-kernel,
Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev
In-Reply-To: <20200408122504.GO3456981@phenom.ffwll.local>
On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > If this code was broken for non-coherent caches a crude powerpc hack
> > isn't going to help anyone else. Remove the hack as it is the last
> > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
>
> Well Ben added this to make stuff work on ppc, ofc the home grown dma
> layer in drm from back then isn't going to work in other places. I guess
> should have at least an ack from him, in case anyone still cares about
> this on ppc. Adding Ben to cc.
This was due to some drivers (radeon ?) trying to use vmalloc pages for
coherent DMA, which means on those 4xx powerpc's need to be non-cached.
There were machines using that (440 based iirc), though I honestly
can't tell if anybody still uses any of it.
Cheers,
Ben.
> -Daniel
>
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > drivers/gpu/drm/drm_scatter.c | 11 +----------
> > 1 file changed, 1 insertion(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > index ca520028b2cb..f4e6184d1877 100644
> > --- a/drivers/gpu/drm/drm_scatter.c
> > +++ b/drivers/gpu/drm/drm_scatter.c
> > @@ -43,15 +43,6 @@
> >
> > #define DEBUG_SCATTER 0
> >
> > -static inline void *drm_vmalloc_dma(unsigned long size)
> > -{
> > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > -#else
> > - return vmalloc_32(size);
> > -#endif
> > -}
> > -
> > static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > {
> > struct page *page;
> > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
> > return -ENOMEM;
> > }
> >
> > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > if (!entry->virtual) {
> > kfree(entry->busaddr);
> > kfree(entry->pagelist);
> > --
> > 2.25.1
> >
>
>
^ permalink raw reply
* Re: [PATCH v1 1/2] powerpc/pseries/hotplug-memory: stop checking is_mem_section_removable()
From: Michal Hocko @ 2020-04-09 8:49 UTC (permalink / raw)
To: David Hildenbrand
Cc: Baoquan He, linux-kernel, Wei Yang, linux-mm, Paul Mackerras,
Nathan Fontenot, Andrew Morton, linuxppc-dev, Oscar Salvador
In-Reply-To: <0a0ed3ed-f792-f8f7-07f4-cacc2b565a95@redhat.com>
On Thu 09-04-20 10:12:20, David Hildenbrand wrote:
> On 09.04.20 09:59, Michal Hocko wrote:
> > On Thu 09-04-20 17:26:01, Michael Ellerman wrote:
> >> David Hildenbrand <david@redhat.com> writes:
> >>
> >>> In commit 53cdc1cb29e8 ("drivers/base/memory.c: indicate all memory
> >>> blocks as removable"), the user space interface to compute whether a memory
> >>> block can be offlined (exposed via
> >>> /sys/devices/system/memory/memoryX/removable) has effectively been
> >>> deprecated. We want to remove the leftovers of the kernel implementation.
> >>>
> >>> When offlining a memory block (mm/memory_hotplug.c:__offline_pages()),
> >>> we'll start by:
> >>> 1. Testing if it contains any holes, and reject if so
> >>> 2. Testing if pages belong to different zones, and reject if so
> >>> 3. Isolating the page range, checking if it contains any unmovable pages
> >>>
> >>> Using is_mem_section_removable() before trying to offline is not only racy,
> >>> it can easily result in false positives/negatives. Let's stop manually
> >>> checking is_mem_section_removable(), and let device_offline() handle it
> >>> completely instead. We can remove the racy is_mem_section_removable()
> >>> implementation next.
> >>>
> >>> We now take more locks (e.g., memory hotplug lock when offlining and the
> >>> zone lock when isolating), but maybe we should optimize that
> >>> implementation instead if this ever becomes a real problem (after all,
> >>> memory unplug is already an expensive operation). We started using
> >>> is_mem_section_removable() in commit 51925fb3c5c9 ("powerpc/pseries:
> >>> Implement memory hotplug remove in the kernel"), with the initial
> >>> hotremove support of lmbs.
> >>
> >> It's also not very pretty in dmesg.
> >>
> >> Before:
> >>
> >> pseries-hotplug-mem: Attempting to hot-add 10 LMB(s)
> >> pseries-hotplug-mem: Memory hot-add failed, removing any added LMBs
> >> dlpar: Could not handle DLPAR request "memory add count 10"
> >
> > Yeah, there is more output but isn't that useful? Or put it differently
> > what is the actual problem from having those messages in the kernel log?
> >
> > From the below you can clearly tell that there are kernel allocations
> > which prevent hot remove from happening.
> >
> > If the overall size of the debugging output is a concern then we can
> > think of a way to reduce it. E.g. once you have a couple of pages
> > reported then all others from the same block are likely not interesting
> > much.
> >
>
> IIRC, we only report one page per block already. (and stop, as we
> detected something unmovable)
You are right.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1 1/2] powerpc/pseries/hotplug-memory: stop checking is_mem_section_removable()
From: David Hildenbrand @ 2020-04-09 8:12 UTC (permalink / raw)
To: Michal Hocko, Michael Ellerman
Cc: Baoquan He, linux-kernel, Wei Yang, linux-mm, Paul Mackerras,
Nathan Fontenot, Andrew Morton, linuxppc-dev, Oscar Salvador
In-Reply-To: <20200409075927.GC18386@dhcp22.suse.cz>
On 09.04.20 09:59, Michal Hocko wrote:
> On Thu 09-04-20 17:26:01, Michael Ellerman wrote:
>> David Hildenbrand <david@redhat.com> writes:
>>
>>> In commit 53cdc1cb29e8 ("drivers/base/memory.c: indicate all memory
>>> blocks as removable"), the user space interface to compute whether a memory
>>> block can be offlined (exposed via
>>> /sys/devices/system/memory/memoryX/removable) has effectively been
>>> deprecated. We want to remove the leftovers of the kernel implementation.
>>>
>>> When offlining a memory block (mm/memory_hotplug.c:__offline_pages()),
>>> we'll start by:
>>> 1. Testing if it contains any holes, and reject if so
>>> 2. Testing if pages belong to different zones, and reject if so
>>> 3. Isolating the page range, checking if it contains any unmovable pages
>>>
>>> Using is_mem_section_removable() before trying to offline is not only racy,
>>> it can easily result in false positives/negatives. Let's stop manually
>>> checking is_mem_section_removable(), and let device_offline() handle it
>>> completely instead. We can remove the racy is_mem_section_removable()
>>> implementation next.
>>>
>>> We now take more locks (e.g., memory hotplug lock when offlining and the
>>> zone lock when isolating), but maybe we should optimize that
>>> implementation instead if this ever becomes a real problem (after all,
>>> memory unplug is already an expensive operation). We started using
>>> is_mem_section_removable() in commit 51925fb3c5c9 ("powerpc/pseries:
>>> Implement memory hotplug remove in the kernel"), with the initial
>>> hotremove support of lmbs.
>>
>> It's also not very pretty in dmesg.
>>
>> Before:
>>
>> pseries-hotplug-mem: Attempting to hot-add 10 LMB(s)
>> pseries-hotplug-mem: Memory hot-add failed, removing any added LMBs
>> dlpar: Could not handle DLPAR request "memory add count 10"
>
> Yeah, there is more output but isn't that useful? Or put it differently
> what is the actual problem from having those messages in the kernel log?
>
> From the below you can clearly tell that there are kernel allocations
> which prevent hot remove from happening.
>
> If the overall size of the debugging output is a concern then we can
> think of a way to reduce it. E.g. once you have a couple of pages
> reported then all others from the same block are likely not interesting
> much.
>
IIRC, we only report one page per block already. (and stop, as we
detected something unmovable)
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v1 1/2] powerpc/pseries/hotplug-memory: stop checking is_mem_section_removable()
From: Michal Hocko @ 2020-04-09 7:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: Baoquan He, David Hildenbrand, linux-kernel, Wei Yang, linux-mm,
Paul Mackerras, Nathan Fontenot, Andrew Morton, linuxppc-dev,
Oscar Salvador
In-Reply-To: <87sghdjf1y.fsf@mpe.ellerman.id.au>
On Thu 09-04-20 17:26:01, Michael Ellerman wrote:
> David Hildenbrand <david@redhat.com> writes:
>
> > In commit 53cdc1cb29e8 ("drivers/base/memory.c: indicate all memory
> > blocks as removable"), the user space interface to compute whether a memory
> > block can be offlined (exposed via
> > /sys/devices/system/memory/memoryX/removable) has effectively been
> > deprecated. We want to remove the leftovers of the kernel implementation.
> >
> > When offlining a memory block (mm/memory_hotplug.c:__offline_pages()),
> > we'll start by:
> > 1. Testing if it contains any holes, and reject if so
> > 2. Testing if pages belong to different zones, and reject if so
> > 3. Isolating the page range, checking if it contains any unmovable pages
> >
> > Using is_mem_section_removable() before trying to offline is not only racy,
> > it can easily result in false positives/negatives. Let's stop manually
> > checking is_mem_section_removable(), and let device_offline() handle it
> > completely instead. We can remove the racy is_mem_section_removable()
> > implementation next.
> >
> > We now take more locks (e.g., memory hotplug lock when offlining and the
> > zone lock when isolating), but maybe we should optimize that
> > implementation instead if this ever becomes a real problem (after all,
> > memory unplug is already an expensive operation). We started using
> > is_mem_section_removable() in commit 51925fb3c5c9 ("powerpc/pseries:
> > Implement memory hotplug remove in the kernel"), with the initial
> > hotremove support of lmbs.
>
> It's also not very pretty in dmesg.
>
> Before:
>
> pseries-hotplug-mem: Attempting to hot-add 10 LMB(s)
> pseries-hotplug-mem: Memory hot-add failed, removing any added LMBs
> dlpar: Could not handle DLPAR request "memory add count 10"
Yeah, there is more output but isn't that useful? Or put it differently
what is the actual problem from having those messages in the kernel log?
From the below you can clearly tell that there are kernel allocations
which prevent hot remove from happening.
If the overall size of the debugging output is a concern then we can
think of a way to reduce it. E.g. once you have a couple of pages
reported then all others from the same block are likely not interesting
much.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] papr/scm: Add bad memory ranges to nvdimm bad ranges
From: Santosh Sivaraj @ 2020-04-09 7:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ganesh Goudar, Oliver, Mahesh Salgaonkar, Aneesh Kumar K.V
In-Reply-To: <20200401074741.1562361-1-santosh@fossix.org>
[-- Attachment #1: Type: text/plain, Size: 5603 bytes --]
On Wed, Apr 1, 2020 at 1:18 PM Santosh Sivaraj <santosh@fossix.org> wrote:
> Subscribe to the MCE notification and add the physical address which
> generated a memory error to nvdimm bad range.
>
> Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
> ---
>
Any comments on this?
Thanks,
Santosh
> This patch depends on "powerpc/mce: Add MCE notification chain" [1].
>
> Unlike the previous series[2], the patch adds badblock registration only
> for
> pseries scm driver. Handling badblocks for baremetal (powernv) PMEM will
> be done
> later and if possible get the badblock handling as a common code.
>
> [1]
> https://lore.kernel.org/linuxppc-dev/20200330071219.12284-1-ganeshgr@linux.ibm.com/
> [2]
> https://lore.kernel.org/linuxppc-dev/20190820023030.18232-1-santosh@fossix.org/
>
> arch/powerpc/platforms/pseries/papr_scm.c | 96 ++++++++++++++++++++++-
> 1 file changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
> b/arch/powerpc/platforms/pseries/papr_scm.c
> index 0b4467e378e5..5012cbf4606e 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -12,6 +12,8 @@
> #include <linux/libnvdimm.h>
> #include <linux/platform_device.h>
> #include <linux/delay.h>
> +#include <linux/nd.h>
> +#include <asm/mce.h>
>
> #include <asm/plpar_wrappers.h>
>
> @@ -39,8 +41,12 @@ struct papr_scm_priv {
> struct resource res;
> struct nd_region *region;
> struct nd_interleave_set nd_set;
> + struct list_head region_list;
> };
>
> +LIST_HEAD(papr_nd_regions);
> +DEFINE_MUTEX(papr_ndr_lock);
> +
> static int drc_pmem_bind(struct papr_scm_priv *p)
> {
> unsigned long ret[PLPAR_HCALL_BUFSIZE];
> @@ -372,6 +378,10 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv
> *p)
> dev_info(dev, "Region registered with target node %d and
> online node %d",
> target_nid, online_nid);
>
> + mutex_lock(&papr_ndr_lock);
> + list_add_tail(&p->region_list, &papr_nd_regions);
> + mutex_unlock(&papr_ndr_lock);
> +
> return 0;
>
> err: nvdimm_bus_unregister(p->bus);
> @@ -379,6 +389,68 @@ err: nvdimm_bus_unregister(p->bus);
> return -ENXIO;
> }
>
> +void papr_scm_add_badblock(struct nd_region *region, struct nvdimm_bus
> *bus,
> + u64 phys_addr)
> +{
> + u64 aligned_addr = ALIGN_DOWN(phys_addr, L1_CACHE_BYTES);
> +
> + if (nvdimm_bus_add_badrange(bus, aligned_addr, L1_CACHE_BYTES)) {
> + pr_err("Bad block registration for 0x%llx failed\n",
> phys_addr);
> + return;
> + }
> +
> + pr_debug("Add memory range (0x%llx - 0x%llx) as bad range\n",
> + aligned_addr, aligned_addr + L1_CACHE_BYTES);
> +
> + nvdimm_region_notify(region, NVDIMM_REVALIDATE_POISON);
> +}
> +
> +static int handle_mce_ue(struct notifier_block *nb, unsigned long val,
> + void *data)
> +{
> + struct machine_check_event *evt = data;
> + struct papr_scm_priv *p;
> + u64 phys_addr;
> + bool found = false;
> +
> + if (evt->error_type != MCE_ERROR_TYPE_UE)
> + return NOTIFY_DONE;
> +
> + if (list_empty(&papr_nd_regions))
> + return NOTIFY_DONE;
> +
> + phys_addr = evt->u.ue_error.physical_address +
> + (evt->u.ue_error.effective_address & ~PAGE_MASK);
> +
> + if (!evt->u.ue_error.physical_address_provided ||
> + !is_zone_device_page(pfn_to_page(phys_addr >> PAGE_SHIFT)))
> + return NOTIFY_DONE;
> +
> + /* mce notifier is called from a process context, so mutex is safe
> */
> + mutex_lock(&papr_ndr_lock);
> + list_for_each_entry(p, &papr_nd_regions, region_list) {
> + struct resource res = p->res;
> +
> + if (phys_addr >= res.start && phys_addr <= res.end) {
> + found = true;
> + break;
> + }
> + }
> +
> + mutex_unlock(&papr_ndr_lock);
> +
> + if (!found)
> + return NOTIFY_DONE;
> +
> + papr_scm_add_badblock(p->region, p->bus, phys_addr);
> +
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block mce_ue_nb = {
> + .notifier_call = handle_mce_ue
> +};
> +
> static int papr_scm_probe(struct platform_device *pdev)
> {
> struct device_node *dn = pdev->dev.of_node;
> @@ -476,6 +548,10 @@ static int papr_scm_remove(struct platform_device
> *pdev)
> {
> struct papr_scm_priv *p = platform_get_drvdata(pdev);
>
> + mutex_lock(&papr_ndr_lock);
> + list_del(&(p->region_list));
> + mutex_unlock(&papr_ndr_lock);
> +
> nvdimm_bus_unregister(p->bus);
> drc_pmem_unbind(p);
> kfree(p->bus_desc.provider_name);
> @@ -498,7 +574,25 @@ static struct platform_driver papr_scm_driver = {
> },
> };
>
> -module_platform_driver(papr_scm_driver);
> +static int __init papr_scm_init(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(&papr_scm_driver);
> + if (!ret)
> + mce_register_notifier(&mce_ue_nb);
> +
> + return ret;
> +}
> +module_init(papr_scm_init);
> +
> +static void __exit papr_scm_exit(void)
> +{
> + mce_unregister_notifier(&mce_ue_nb);
> + platform_driver_unregister(&papr_scm_driver);
> +}
> +module_exit(papr_scm_exit);
> +
> MODULE_DEVICE_TABLE(of, papr_scm_match);
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("IBM Corporation");
> --
> 2.25.1
>
>
[-- Attachment #2: Type: text/html, Size: 7541 bytes --]
^ 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