From: Mike Rapoport <rppt@linux.ibm.com> To: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>, Adam Ford <aford173@gmail.com>, Fabio Estevam <festevam@gmail.com>, Catalin Marinas <catalin.marinas@arm.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@lst.de>, The etnaviv authors <etnaviv@lists.freedesktop.org>, arm-soc <linux-arm-kernel@lists.infradead.org>, Linux Memory Management List <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH v2 00/21] Refine memblock API Date: Fri, 4 Oct 2019 20:10:07 +0300 [thread overview] Message-ID: <20191004171007.GA17825@linux.ibm.com> (raw) In-Reply-To: <bc05540f2aa46cff5d6239faab83446401ba7b5f.camel@pengutronix.de> On Fri, Oct 04, 2019 at 03:21:03PM +0200, Lucas Stach wrote: > Am Freitag, den 04.10.2019, 10:27 +0100 schrieb Russell King - ARM > Linux admin: > > On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote: > > > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux > > > admin wrote: > > > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > > > > > (trimmed the CC) > > > > > > > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > > > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport < > > > > > > rppt@linux.ibm.com> wrote: > > > > > > > > > > > > Before the patch: > > > > > > > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > > 0: 0x10000000..0x8fffffff > > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > > 0: 0x10004000..0x10007fff > > > > > > 34: 0x2fffff88..0x3fffffff > > > > > > > > > > > > > > > > > > After the patch: > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > > 0: 0x10000000..0x8fffffff > > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > > 0: 0x10004000..0x10007fff > > > > > > 36: 0x80000000..0x8fffffff > > > > > > > > > > I'm still not convinced that the memblock refactoring didn't > > > > > uncovered an > > > > > issue in etnaviv driver. > > > > > > > > > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it > > > > > fail? > > > > > > > > I think you have that the wrong way round. > > > > > > I'm relying on Adam's reports of working and non-working versions. > > > According to that etnaviv works when CMA area is at 0x80000000 and > > > does not > > > work when it is at 0x30000000. > > > > > > He also sent logs a few days ago [1], they also confirm that. > > > > > > [1] > > > https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/ > > > > Sorry, yes, you're right. Still, I've reported this same regression > > a while back, and it's never gone away. > > > > > > > BTW, the code that complained about "command buffer outside > > > > > valid memory > > > > > window" has been removed by the commit 17e4660ae3d7 > > > > > ("drm/etnaviv: > > > > > implement per-process address spaces on MMUv2"). > > > > > > > > > > Could be that recent changes to MMU management of etnaviv > > > > > resolve the > > > > > issue? > > > > > > > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > > > > hardware requires command buffers within the first 2GiB of > > > > physical > > > > RAM. > > > > > > I've mentioned that patch because it removed the check for cmdbuf > > > address > > > for MMUv1: > > > > > > @@ -785,15 +768,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) > > > PAGE_SIZE); > > > if (ret) { > > > dev_err(gpu->dev, "could not create command > > > buffer\n"); > > > - goto unmap_suballoc; > > > - } > > > - > > > - if (!(gpu->identity.minor_features1 & > > > chipMinorFeatures1_MMU_VERSION) && > > > - etnaviv_cmdbuf_get_va(&gpu->buffer, &gpu- > > > >cmdbuf_mapping) > 0x80000000) { > > > - ret = -EINVAL; > > > - dev_err(gpu->dev, > > > - "command buffer outside valid memory > > > window\n"); > > > - goto free_buffer; > > > + goto fail; > > > } > > > > > > /* Setup event management */ > > > > > > > > > I really don't know how etnaviv works, so I hoped that people who > > > understand it would help. > > > > From what I can see, removing that check is a completely insane thing > > to do, and I note that these changes are _not_ described in the > > commit > > message. The problem was known about _before_ (June 22) the patch > > was > > created (July 5). > > > > Lucas, please can you explain why removing the above check, which is > > well known to correctly trigger on various platforms to prevent > > incorrect GPU behaviour, is safe? > > It isn't. It's a pretty big oversight in this commit to remove this > check. It can't be done at the same spot in the code anymore, as we > don't have a mapping context at this time anymore, but it should have > moved into etnaviv_iommu_context_init(). I'll send a patch to fix this > up. Lucas, can you make the check use SZ_2G instead of 0x80000000 and add a comment about 2G limitation of the aperture window? > Regards, > Lucas > -- Sincerely yours, Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com> To: Lucas Stach <l.stach@pengutronix.de> Cc: Adam Ford <aford173@gmail.com>, Russell King - ARM Linux admin <linux@armlinux.org.uk>, The etnaviv authors <etnaviv@lists.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Memory Management List <linux-mm@kvack.org>, Catalin Marinas <catalin.marinas@arm.com>, Andrew Morton <akpm@linux-foundation.org>, Fabio Estevam <festevam@gmail.com>, Christoph Hellwig <hch@lst.de>, arm-soc <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 00/21] Refine memblock API Date: Fri, 4 Oct 2019 20:10:07 +0300 [thread overview] Message-ID: <20191004171007.GA17825@linux.ibm.com> (raw) In-Reply-To: <bc05540f2aa46cff5d6239faab83446401ba7b5f.camel@pengutronix.de> On Fri, Oct 04, 2019 at 03:21:03PM +0200, Lucas Stach wrote: > Am Freitag, den 04.10.2019, 10:27 +0100 schrieb Russell King - ARM > Linux admin: > > On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote: > > > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux > > > admin wrote: > > > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > > > > > (trimmed the CC) > > > > > > > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > > > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport < > > > > > > rppt@linux.ibm.com> wrote: > > > > > > > > > > > > Before the patch: > > > > > > > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > > 0: 0x10000000..0x8fffffff > > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > > 0: 0x10004000..0x10007fff > > > > > > 34: 0x2fffff88..0x3fffffff > > > > > > > > > > > > > > > > > > After the patch: > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > > 0: 0x10000000..0x8fffffff > > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > > 0: 0x10004000..0x10007fff > > > > > > 36: 0x80000000..0x8fffffff > > > > > > > > > > I'm still not convinced that the memblock refactoring didn't > > > > > uncovered an > > > > > issue in etnaviv driver. > > > > > > > > > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it > > > > > fail? > > > > > > > > I think you have that the wrong way round. > > > > > > I'm relying on Adam's reports of working and non-working versions. > > > According to that etnaviv works when CMA area is at 0x80000000 and > > > does not > > > work when it is at 0x30000000. > > > > > > He also sent logs a few days ago [1], they also confirm that. > > > > > > [1] > > > https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/ > > > > Sorry, yes, you're right. Still, I've reported this same regression > > a while back, and it's never gone away. > > > > > > > BTW, the code that complained about "command buffer outside > > > > > valid memory > > > > > window" has been removed by the commit 17e4660ae3d7 > > > > > ("drm/etnaviv: > > > > > implement per-process address spaces on MMUv2"). > > > > > > > > > > Could be that recent changes to MMU management of etnaviv > > > > > resolve the > > > > > issue? > > > > > > > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > > > > hardware requires command buffers within the first 2GiB of > > > > physical > > > > RAM. > > > > > > I've mentioned that patch because it removed the check for cmdbuf > > > address > > > for MMUv1: > > > > > > @@ -785,15 +768,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) > > > PAGE_SIZE); > > > if (ret) { > > > dev_err(gpu->dev, "could not create command > > > buffer\n"); > > > - goto unmap_suballoc; > > > - } > > > - > > > - if (!(gpu->identity.minor_features1 & > > > chipMinorFeatures1_MMU_VERSION) && > > > - etnaviv_cmdbuf_get_va(&gpu->buffer, &gpu- > > > >cmdbuf_mapping) > 0x80000000) { > > > - ret = -EINVAL; > > > - dev_err(gpu->dev, > > > - "command buffer outside valid memory > > > window\n"); > > > - goto free_buffer; > > > + goto fail; > > > } > > > > > > /* Setup event management */ > > > > > > > > > I really don't know how etnaviv works, so I hoped that people who > > > understand it would help. > > > > From what I can see, removing that check is a completely insane thing > > to do, and I note that these changes are _not_ described in the > > commit > > message. The problem was known about _before_ (June 22) the patch > > was > > created (July 5). > > > > Lucas, please can you explain why removing the above check, which is > > well known to correctly trigger on various platforms to prevent > > incorrect GPU behaviour, is safe? > > It isn't. It's a pretty big oversight in this commit to remove this > check. It can't be done at the same spot in the code anymore, as we > don't have a mapping context at this time anymore, but it should have > moved into etnaviv_iommu_context_init(). I'll send a patch to fix this > up. Lucas, can you make the check use SZ_2G instead of 0x80000000 and add a comment about 2G limitation of the aperture window? > Regards, > Lucas > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-04 17:10 UTC|newest] Thread overview: 470+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-21 8:03 [PATCH v2 00/21] Refine memblock API Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 01/21] openrisc: prefer memblock APIs returning virtual address Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,01/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 01/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` [OpenRISC] " Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` [v2,01/21] " Stafford Horne 2019-01-27 3:07 ` [PATCH v2 01/21] " Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-27 3:07 ` Stafford Horne 2019-01-21 8:03 ` [PATCH v2 02/21] powerpc: use memblock functions " Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,02/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 02/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` [OpenRISC] " Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` [v2,02/21] " Michael Ellerman 2019-01-29 9:52 ` [PATCH v2 02/21] " Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-29 9:52 ` Michael Ellerman 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 03/21] memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,03/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 03/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 04/21] memblock: drop memblock_alloc_base_nid() Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,04/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 04/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 05/21] memblock: emphasize that memblock_alloc_range() returns a physical address Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,05/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 05/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,06/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 06/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` [OpenRISC] " Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` [v2,06/21] " Catalin Marinas 2019-01-25 17:45 ` [PATCH v2 06/21] " Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 17:45 ` Catalin Marinas 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` [OpenRISC] " Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` [v2,06/21] " Mike Rapoport 2019-01-25 19:32 ` [PATCH v2 06/21] " Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-25 19:32 ` Mike Rapoport 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` [OpenRISC] " Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` [v2,06/21] " Michael Ellerman 2019-01-29 9:56 ` [PATCH v2 06/21] " Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:56 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` [OpenRISC] " Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` [v2,06/21] " Michael Ellerman 2019-01-29 9:58 ` [PATCH v2 06/21] " Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-29 9:58 ` Michael Ellerman 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 07/21] memblock: memblock_phys_alloc(): " Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,07/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 07/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 08/21] memblock: drop __memblock_alloc_base() Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,08/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 08/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 09/21] memblock: drop memblock_alloc_base() Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,09/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 09/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` [OpenRISC] " Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` [v2,09/21] " Michael Ellerman 2019-01-29 10:29 ` [PATCH v2 09/21] " Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-29 10:29 ` Michael Ellerman 2019-01-21 8:03 ` [PATCH v2 10/21] memblock: refactor internal allocation functions Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,10/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 10/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` [OpenRISC] " Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` [v2,10/21] " Michael Ellerman 2019-02-03 9:39 ` [PATCH v2 10/21] " Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 9:39 ` Michael Ellerman 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` [OpenRISC] " Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` [v2,10/21] " Mike Rapoport 2019-02-03 10:04 ` [PATCH v2 10/21] " Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 10:04 ` Mike Rapoport 2019-02-03 11:39 ` Mike Rapoport 2019-02-03 11:39 ` Mike Rapoport 2019-02-04 8:45 ` Michael Ellerman 2019-02-04 8:45 ` Michael Ellerman 2019-02-04 23:08 ` Stephen Rothwell 2019-02-04 23:08 ` Stephen Rothwell 2019-01-21 8:03 ` [PATCH v2 11/21] memblock: make memblock_find_in_range_node() and choose_memblock_flags() static Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,11/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 11/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 12/21] arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0) Mike Rapoport 2019-01-21 8:03 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` [v2,12/21] " Mike Rapoport 2019-01-21 8:03 ` [PATCH v2 12/21] " Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:03 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 13/21] arch: don't memset(0) memory returned by memblock_alloc() Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,13/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 13/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 14/21] ia64: add checks for the return value of memblock_alloc*() Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,14/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 14/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 15/21] sparc: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,15/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 15/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 16/21] mm/percpu: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,16/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 16/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 17/21] init/main: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,17/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 17/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 18/21] swiotlb: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,18/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 18/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 19/21] treewide: " Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,19/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 19/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` [OpenRISC] " Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 8:39 ` Geert Uytterhoeven 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` [OpenRISC] " Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` [v2,19/21] " Rob Herring 2019-01-21 17:18 ` [PATCH v2 19/21] " Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-21 17:18 ` Rob Herring 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` [OpenRISC] " Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` [v2,19/21] " Christophe Leroy 2019-01-31 6:07 ` [PATCH v2 19/21] " Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` [OpenRISC] " Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` [v2,19/21] " Mike Rapoport 2019-01-31 6:41 ` [PATCH v2 19/21] " Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:41 ` Mike Rapoport 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` [OpenRISC] " Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` [v2,19/21] " Christophe Leroy 2019-01-31 6:44 ` [PATCH v2 19/21] " Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 6:44 ` Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` [OpenRISC] " Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` [v2,19/21] " Christophe Leroy 2019-01-31 7:07 ` [PATCH v2 19/21] " Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` [OpenRISC] " Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` [v2,19/21] " Mike Rapoport 2019-01-31 7:14 ` [PATCH v2 19/21] " Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:14 ` Mike Rapoport 2019-01-31 7:07 ` Christophe Leroy 2019-01-31 6:07 ` Christophe Leroy 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` [OpenRISC] " Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-31 15:23 ` Max Filippov 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 20/21] memblock: memblock_alloc_try_nid: don't panic Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,20/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 20/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 21/21] memblock: drop memblock_alloc_*_nopanic() variants Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [OpenRISC] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` [v2,21/21] " Mike Rapoport 2019-01-21 8:04 ` [PATCH v2 21/21] " Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-21 8:04 ` Mike Rapoport 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` [OpenRISC] " Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` [v2,21/21] " Petr Mladek 2019-01-30 13:38 ` [PATCH v2 21/21] " Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-01-30 13:38 ` Petr Mladek 2019-09-24 17:52 ` [PATCH v2 00/21] Refine memblock API Adam Ford 2019-09-24 17:52 ` [OpenRISC] " Adam Ford 2019-09-24 17:52 ` [Xen-devel] " Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-24 17:52 ` Adam Ford 2019-09-25 6:42 ` Mike Rapoport 2019-09-25 6:42 ` Mike Rapoport 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:12 ` [OpenRISC] " Fabio Estevam 2019-09-25 12:12 ` [Xen-devel] " Fabio Estevam 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:12 ` Fabio Estevam 2019-09-25 12:17 ` Adam Ford 2019-09-25 12:17 ` [OpenRISC] " Adam Ford 2019-09-25 12:17 ` [Xen-devel] " Adam Ford 2019-09-25 12:17 ` Adam Ford 2019-09-25 12:17 ` Adam Ford 2019-09-25 12:17 ` Adam Ford 2019-09-25 15:17 ` Fabio Estevam 2019-09-25 15:17 ` [OpenRISC] " Fabio Estevam 2019-09-25 15:17 ` [Xen-devel] " Fabio Estevam 2019-09-25 15:17 ` Fabio Estevam 2019-09-25 15:17 ` Fabio Estevam 2019-09-25 15:17 ` Fabio Estevam 2019-09-26 13:09 ` Adam Ford 2019-09-26 13:09 ` [OpenRISC] " Adam Ford 2019-09-26 13:09 ` [Xen-devel] " Adam Ford 2019-09-26 13:09 ` Adam Ford 2019-09-26 13:09 ` Adam Ford 2019-09-26 13:09 ` Adam Ford 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 16:04 ` [OpenRISC] " Mike Rapoport 2019-09-26 16:04 ` [Xen-devel] " Mike Rapoport 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 16:04 ` Mike Rapoport 2019-09-26 19:35 ` Adam Ford 2019-09-26 19:35 ` [OpenRISC] " Adam Ford 2019-09-26 19:35 ` [Xen-devel] " Adam Ford 2019-09-26 19:35 ` Adam Ford 2019-09-26 19:35 ` Adam Ford 2019-09-26 19:35 ` Adam Ford 2019-09-28 7:33 ` Mike Rapoport 2019-09-28 7:33 ` [OpenRISC] " Mike Rapoport 2019-09-28 7:33 ` [Xen-devel] " Mike Rapoport 2019-09-28 7:33 ` Mike Rapoport 2019-09-28 7:33 ` Mike Rapoport 2019-09-28 7:33 ` Mike Rapoport 2019-09-29 13:33 ` Adam Ford 2019-09-29 13:33 ` [OpenRISC] " Adam Ford 2019-09-29 13:33 ` [Xen-devel] " Adam Ford 2019-09-29 13:33 ` Adam Ford 2019-09-29 13:33 ` Adam Ford 2019-09-29 13:33 ` Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 0:14 ` [OpenRISC] " Adam Ford 2019-10-02 0:14 ` [Xen-devel] " Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 0:14 ` Adam Ford 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` [OpenRISC] " Mike Rapoport 2019-10-02 7:36 ` [Xen-devel] " Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 7:36 ` Mike Rapoport 2019-10-02 11:14 ` Adam Ford 2019-10-02 11:14 ` [OpenRISC] " Adam Ford 2019-10-02 11:14 ` [Xen-devel] " Adam Ford 2019-10-02 11:14 ` Adam Ford 2019-10-02 11:14 ` Adam Ford 2019-10-02 11:14 ` Adam Ford 2019-10-03 5:34 ` Mike Rapoport 2019-10-03 5:34 ` Mike Rapoport 2019-10-03 8:49 ` Russell King - ARM Linux admin 2019-10-03 8:49 ` Russell King - ARM Linux admin 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 13:17 ` Lucas Stach 2019-10-03 13:17 ` Lucas Stach 2019-10-03 13:17 ` Lucas Stach 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:58 ` Adam Ford 2019-10-04 13:58 ` Adam Ford 2019-10-04 13:58 ` Adam Ford 2019-10-04 17:10 ` Mike Rapoport [this message] 2019-10-04 17:10 ` Mike Rapoport 2019-10-04 17:29 ` Mike Rapoport 2019-10-04 17:29 ` Mike Rapoport 2019-10-03 14:46 ` Chris Healy 2019-10-03 14:46 ` Chris Healy 2019-10-03 14:46 ` Chris Healy 2019-10-04 9:12 ` Russell King - ARM Linux admin 2019-10-04 9:12 ` Russell King - ARM Linux admin 2019-01-21 8:03 Mike Rapoport
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191004171007.GA17825@linux.ibm.com \ --to=rppt@linux.ibm.com \ --cc=aford173@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=catalin.marinas@arm.com \ --cc=etnaviv@lists.freedesktop.org \ --cc=festevam@gmail.com \ --cc=hch@lst.de \ --cc=l.stach@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux@armlinux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.