From: Mike Rapoport
The unicore32 port is removed from the kernel.
There is no point to keep stale definitions to support this architecture.
Signed-off-by: Mike Rapoport
---
MAINTAINERS | 1 -
drivers/input/serio/i8042-unicore32io.h | 70
From: Mike Rapoport
The unicore32 port is removed from the kernel.
There is no point to keep stale fbdev driver for this architecture.
Signed-off-by: Mike Rapoport
---
MAINTAINERS | 1 -
drivers/video/fbdev/Kconfig | 11 -
drivers/video/fbdev/Makefile | 1 -
drivers
From: Mike Rapoport
The unicore32 port is removed from the kernel.
There is no point to keep stale cpufreq driver for this architecture.
Signed-off-by: Mike Rapoport
---
drivers/cpufreq/Makefile | 1 -
drivers/cpufreq/unicore2-cpufreq.c | 76 --
2 files
From: Mike Rapoport
Hi,
The unicore32 port do not seem maintained for a long time now, there is no
upstream toolchain that can create unicore32 binaries and all the links to
prebuilt toolchains for unicore32 are dead. Even compilers that were
available are not supported by the kernel anymore
From: Mike Rapoport
The unicore32 port is removed from the kernel.
There is no point to keep stale PWM driver for this architecture.
Signed-off-by: Mike Rapoport
---
drivers/pwm/Kconfig| 9 ---
drivers/pwm/Makefile | 1 -
drivers/pwm/pwm-puv3.c | 150
c: Johannes Weiner
> Cc: Michal Hocko
> Cc: Minchan Kim
> Cc: Huang Ying
> Cc: Wei Yang
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport
> ---
> include/linux/swap.h | 1 -
> mm/page_alloc.c | 16 ++--
> 2 files changed, 2 insertions(
se a local variable in
> build_all_zonelists() instead and drop the local variable.
Nit: ^ global
> Cc: Andrew Morton
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Huang Ying
> Cc: Minchan Kim
> Cc: Wei Yang
> Signed-off-by: David Hildenbran
From: Mike Rapoport
Since the commit a148866489fb ("sched: Replace rq::wake_list")
task_struct and CSD_TYPE_TTWU objects can be on the same queue and this
requires that have "layout similar enough".
This assumption is broken when CONFIG_GCC_PLUGIN_RANDSTRUCT is enabled
Hi Roman,
On Mon, Jun 08, 2020 at 04:06:35PM -0700, Roman Gushchin wrote:
> This is v6 of the slab cgroup controller rework.
>
> The patchset moves the accounting from the page level to the object
> level. It allows to share slab pages between memory cgroups.
> This leads to a significant win in
On Wed, Jun 17, 2020 at 06:12:26PM -0700, Andrew Morton wrote:
> On Tue, 9 Jun 2020 14:05:33 +0200 Joerg Roedel wrote:
>
> > From: Joerg Roedel
> >
> > The functions are only used in two source files, so there is no need
> > for them to be in the global header. Move them to the new
> >
)
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Tony Luck
> Cc: Fenghua Yu
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: D
st should
> always remain in sync.
>
> Cc: Jonathan Corbet
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: Vineet Gupta
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Heiko C
From: Angelo Dureghello
After pulling 5.7.0 (linux-next merge), mcf5441x mmu boot was
hanging silently.
memblock_add() seems not appropriate, since using MAX_NUMNODES
as node id, while memblock_add_node() sets up memory for node id 0.
Signed-off-by: Angelo Dureghello
Signed-off-by: Mike
From: Mike Rapoport
Hi,
It's a followup to the Greg's [1] and Angelo's [2] reports of boot problems
caused by the recent rework of the memory initialization.
I'm resending Angelo's original patch for mcfmmu and my fix for the nommu
variant.
[1]
https://lore.kernel.org/lkml/f53e68db-ed81-6ef6
From: Mike Rapoport
The m68k nommu setup code didn't register the beginning of the physical
memory with memblock because it was anyway occupied by the kernel. However,
commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than
zone sizes") changed zones initializat
On Wed, Jun 17, 2020 at 09:21:42AM +1000, Michael Ellerman wrote:
> Andrew Morton writes:
> > On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport wrote:
> >
> >> From: Mike Rapoport
> >>
> >> The pte_update() implementation for PPC_8xx unfolds page tab
From: Mike Rapoport
The pte_update() implementation for PPC_8xx unfolds page table from the PGD
level to access a PMD entry. Since 8xx has only 2-level page table this can
be simplified with pmd_off() shortcut.
Replace explicit unfolding with pmd_off() and drop defines of pgd_index
(reduced the spam list)
On Mon, Jun 15, 2020 at 05:17:28PM +1000, Greg Ungerer wrote:
> Hi Mike,
>
> On 15/6/20 4:22 pm, Mike Rapoport wrote:
> > On Mon, Jun 15, 2020 at 01:53:42PM +1000, Greg Ungerer wrote:
> > > From: Mike Rapoport
> > > > Currently, a
Hi Greg,
On Mon, Jun 15, 2020 at 01:53:42PM +1000, Greg Ungerer wrote:
> Hi Mike,
>
> From: Mike Rapoport
> > Currently, architectures that use free_area_init() to initialize memory map
> > and node and zone structures need to calculate zone and hole sizes. We can
> &g
f-by: Kirill A. Shutemov
> Reviewed-by: Dave Hansen
> Cc: sta...@vger.kernel.org # v4.14
Reviewed-by: Mike Rapoport
> ---
> arch/x86/kernel/e820.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/e820.c b/
> mapping for such memory in the 4-level paging mode
>
> Teach KASLR to avoid memory regions above MAXMEM or truncate the region
> if the end is above MAXMEM.
>
> Signed-off-by: Kirill A. Shutemov
> Reviewed-by: Dave Hansen
> Cc: sta...@vger.kernel.org # v4.14
Reviewed-
On Tue, Jun 09, 2020 at 07:15:42AM -0700, Guenter Roeck wrote:
> On 6/9/20 5:10 AM, Joerg Roedel wrote:
> >
> I have stopped building unicore32 images since v4.19 since there is
> no available compiler that is still supported by the kernel. I am
> surprised that support for it has not been
Hi Joerg,
On Tue, Jun 09, 2020 at 02:10:56PM +0200, Joerg Roedel wrote:
> Hi Mike,
>
> On Fri, Jun 05, 2020 at 01:00:59PM +0300, Mike Rapoport wrote:
> > We already have include/asm-generic/pgalloc.h, so maybe something like
> > that patch below would fork. This is no
-off-by: Joerg Roedel
Acked-by: Mike Rapoport
> ---
> include/linux/mm.h| 45 ---
> include/linux/pgalloc-track.h | 51 +++
> lib/ioremap.c | 1 +
> mm/vmalloc.c | 1 +
>
On Fri, Jun 05, 2020 at 10:16:44AM +0200, Joerg Roedel wrote:
> On Thu, Jun 04, 2020 at 02:12:14PM -0700, Linus Torvalds wrote:
> > That said, the commentary about "why is p.._alloc_track() in such a
> > core header file, when it's only used by two special cases" is
> > probably still true
On Thu, Jun 04, 2020 at 09:44:46AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The pud_alloc_track() needs to do different checks based on whether
> __ARCH_HAS_5LEVEL_HACK is defined, like it already does in
> pud_alloc(). Otherwise it causes boot failures on PowerPC.
>
> Provide the
code, the comment /* must be last! */ is stale...
@Peter, @Thomas, can you comment please?
>From e51d50ee6f4d1f446decf91c2c67230da14ff82c Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Thu, 4 Jun 2020 12:37:03 +0300
Subject: [PATCH] softirq: don't call lockdep_hardirq_exit() twice
After com
On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote:
> On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
>
> With linux-next on sparc I too see the spinlock issue; something like:
>
> ...
> Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139
> lock: 0xf53ef350,
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> On 6/3/20 2:14 PM, Ira Weiny wrote:
> > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
> >>
> >
> > Actually it occurs to me that the patch
On Thu, Jun 04, 2020 at 12:11:32AM +0800, Miles Chen wrote:
> max_pfn is uesd to get the highest pfn in the system. Drivers like
> drivers/iommu/mtk_iommu.c checks max_pfn to see if it should enable
> its "4GB mode".
>
> This patch exports the max_pfn symbol, so we can build the driver as
> a
On Thu, May 28, 2020 at 10:15:10AM -0500, Steve Wahl wrote:
> On Thu, May 28, 2020 at 05:07:31PM +0800, Baoquan He wrote:
> > On 05/26/20 at 01:49pm, David Hildenbrand wrote:
> > > On 26.05.20 13:32, Mike Rapoport wrote:
> > > > Hello Baoquan,
> > > >
&g
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 431732651cc16caebcd334b7b7476bfe0c4a2903
Gitweb:
https://git.kernel.org/tip/431732651cc16caebcd334b7b7476bfe0c4a2903
Author:Mike Rapoport
AuthorDate:Sun, 23 Feb 2020 11:43:22 +02:00
Gentle ping...
On Sun, Feb 23, 2020 at 11:43:22AM +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The DISCONTIGMEM support was marked as deprecated in v5.2 and since there
> were no complaints about it for almost 5 releases it can be completely
> removed.
>
> Signed-
On Wed, May 27, 2020 at 08:45:33AM -0700, Dave Hansen wrote:
> On 5/26/20 4:38 AM, Mike Rapoport wrote:
> > On Tue, May 26, 2020 at 01:16:14PM +0300, Liran Alon wrote:
> >> On 26/05/2020 9:17, Mike Rapoport wrote:
> >>> On Mon, May 25, 2020 at 04:47:18PM +0300, Lir
Andrew, David,
Any comments on this?
On Sun, May 24, 2020 at 07:53:58PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> sparc32 never registered the memory occupied by the kernel image with
> memblock_add() and it only reserved this memory with meblock_reserve().
>
On Tue, May 26, 2020 at 09:18:54AM -0700, Guenter Roeck wrote:
> On 5/26/20 7:01 AM, Will Deacon wrote:
> > On Tue, May 26, 2020 at 02:26:35PM +0100, Will Deacon wrote:
> >> On Sun, May 24, 2020 at 03:32:56PM +0300, Mike Rapoport wrote:
> >>> On Thu, May 21, 2020 at 0
On Tue, May 26, 2020 at 03:01:27PM +0100, Will Deacon wrote:
> On Tue, May 26, 2020 at 02:26:35PM +0100, Will Deacon wrote:
> > On Sun, May 24, 2020 at 03:32:56PM +0300, Mike Rapoport wrote:
> > > On Thu, May 21, 2020 at 04:02:11PM -0700, Guenter Roeck wrote:
> > >
On Tue, May 26, 2020 at 01:16:14PM +0300, Liran Alon wrote:
>
> On 26/05/2020 9:17, Mike Rapoport wrote:
> > On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote:
> > > On 22/05/2020 15:51, Kirill A. Shutemov wrote:
> > >
> > Out of curiosity, do we act
Hello Baoquan,
On Tue, May 26, 2020 at 04:45:43PM +0800, Baoquan He wrote:
> On 05/22/20 at 05:20pm, Mike Rapoport wrote:
> > Hello Baoquan,
> >
> > On Fri, May 22, 2020 at 03:25:24PM +0800, Baoquan He wrote:
> > > On 05/22/20 at 03:01pm, Baoquan He wrote:
/gup: introduce pin_user_pages*() and FOLL_PIN")
> Signed-off-by: Vitaly Kuznetsov
Acked-by: Mike Rapoport
> ---
> include/linux/mm.h | 4 ++--
> mm/gup.c | 18 +-
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/incl
On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote:
>
> On 22/05/2020 15:51, Kirill A. Shutemov wrote:
>
> Furthermore, I would like to point out that just unmapping guest data from
> kernel direct-map is not sufficient to prevent all
> guest-to-guest info-leaks via a kernel memory
On Fri, May 22, 2020 at 03:52:14PM +0300, Kirill A. Shutemov wrote:
> If the protected memory feature enabled, unmap guest memory from
> kernel's direct mappings.
>
> Migration and KSM is disabled for protected memory as it would require a
> special treatment.
>
> Signed-off-by: Kirill A.
On Fri, May 22, 2020 at 03:52:05PM +0300, Kirill A. Shutemov wrote:
> The new VMA flag that indicate a VMA that is not accessible to userspace
> but usable by kernel with GUP if FOLL_KVM is specified.
>
> The FOLL_KVM is only used in the KVM code. The code has to know how to
> deal with such
On Fri, May 22, 2020 at 03:52:08PM +0300, Kirill A. Shutemov wrote:
> Wire up hypercalls for the feature and define VM_KVM_PROTECTED.
>
> Signed-off-by: Kirill A. Shutemov
> ---
> arch/x86/Kconfig | 1 +
> arch/x86/kvm/cpuid.c | 3 +++
> arch/x86/kvm/x86.c | 9 +
>
On Fri, May 22, 2020 at 03:52:04PM +0300, Kirill A. Shutemov wrote:
> New helpers copy_from_guest()/copy_to_guest() to be used if KVM memory
> protection feature is enabled.
>
> Signed-off-by: Kirill A. Shutemov
> ---
> include/linux/kvm_host.h | 4 +++
> virt/kvm/kvm_main.c | 78
On Mon, May 25, 2020 at 06:08:20PM +0300, Kirill A. Shutemov wrote:
> On Mon, May 25, 2020 at 05:59:43PM +0300, Mike Rapoport wrote:
> > On Mon, May 25, 2020 at 07:49:02AM +0300, Kirill A. Shutemov wrote:
> > > On Mon, May 11, 2020 at 10:17:21PM +0300, Kirill A. Shutemov wrote:
On Mon, May 25, 2020 at 07:49:02AM +0300, Kirill A. Shutemov wrote:
> On Mon, May 11, 2020 at 10:17:21PM +0300, Kirill A. Shutemov wrote:
> > A 5-level paging capable machine can have memory above 46-bit in the
> > physical address space. This memory is only addressable in the 5-level
> > paging
On Mon, May 25, 2020 at 08:21:58AM +0800, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://github.com/0day-ci/linux/commits/Mike-Rapoport/mm-consolidate-definitions-of-page-table-accessors/20200513-025
On Sun, May 24, 2020 at 11:16:40PM +0900, daeroro wrote:
> The range that has already been checked
> don't have to be checked in a second attempt.
The first attempts tries to find free memory in the interval [min_addr,
max_addr) and the second attempt does not care about min_addr and looks
for
From: Mike Rapoport
sparc32 never registered the memory occupied by the kernel image with
memblock_add() and it only reserved this memory with meblock_reserve().
With openbios as system firmware, the memory occupied by the kernel is
reserved in openbios and removed from mem.available. The prom
From: Mike Rapoport
This is a misprint in the page table traversal in
srmmu_inherit_prom_mappings`() function which accessed a PMD entry using
PGD rather than PUD.
Since sparc32 has only 3 page table levels, the PGD and PUD are
essentially the same and usage of __nocache_fix() removed the type
From: Mike Rapoport
The __nocache_fix(VADDR) macro is used to add an offset for pointers and
its "return type" is 'void *'.
We can do better and keep the type information with simply by casting the
return value to (__typeof__(VADDR)).
This will ".. show when those pgd/p4d/pud p
From: Mike Rapoport
Hi,
As discussed at [1] the __nocache_fix() macro in sparc's SRMMU can be made
type safe and so the compiler will yell anout misuse of pXd pointers for
which the __nocache_fix() is primarily used.
The first patch is an fix of such misuse that I've discovered after adding
On Thu, May 21, 2020 at 04:02:11PM -0700, Guenter Roeck wrote:
> On 5/20/20 12:51 PM, Mike Rapoport wrote:
> > On Wed, May 20, 2020 at 12:03:31PM -0700, Guenter Roeck wrote:
> >> On 5/20/20 10:03 AM, Mike Rapoport wrote:
> >>> On Mon, May 18, 2020 at 09:37
On Tue, Apr 28, 2020 at 06:51:26PM -0700, Matthew Wilcox wrote:
> On Wed, Apr 29, 2020 at 03:26:24AM +0300, Kirill A. Shutemov wrote:
> > On Tue, Apr 28, 2020 at 12:44:42PM -0700, Matthew Wilcox wrote:
> > > From: "Matthew Wilcox (Oracle)"
> > >
> > > Pages which are in use as page tables have
Hello Baoquan,
On Fri, May 22, 2020 at 03:25:24PM +0800, Baoquan He wrote:
> On 05/22/20 at 03:01pm, Baoquan He wrote:
> >
> > So let's add these unavailable ranges into memblock and reserve them
> > in init_unavailable_range() instead. With this change, they will be added
> > into appropriate
On Thu, May 21, 2020 at 11:52:25PM +0800, Baoquan He wrote:
> On 05/21/20 at 12:26pm, Mike Rapoport wrote:
> > > For this kind of e820 reserved range, it won't be added to memblock
> > > allocator.
> > > However, init_unavailable_mem() will initialize to add them int
On Thu, May 21, 2020 at 10:36:06AM +0100, Mel Gorman wrote:
> On Thu, May 21, 2020 at 09:44:07AM +0800, Baoquan He wrote:
> > After investigation, it turns out that this is introduced by commit of
> > linux-next: commit f6edbdb71877 ("mm: memmap_init: iterate over memblock
> > regions rather that
Hi Baoquan,
On Thu, May 21, 2020 at 09:44:07AM +0800, Baoquan He wrote:
> Qian reported that a crash happened in compaction.
> http://lkml.kernel.org/r/8c537eb7-85ee-4dcf-943e-3cc0ed0df...@lca.pw
>
V> LTP: starting swapping01 (swapping01 -i 5)
> page:eaaa refcount:1 mapcount:0
On Wed, May 20, 2020 at 12:03:31PM -0700, Guenter Roeck wrote:
> On 5/20/20 10:03 AM, Mike Rapoport wrote:
> > On Mon, May 18, 2020 at 09:37:15AM +0100, Will Deacon wrote:
> >> On Sat, May 16, 2020 at 05:07:50PM -0700, Guenter Roeck wrote:
> >>> On Sat, May 16, 202
On Mon, May 18, 2020 at 09:37:15AM +0100, Will Deacon wrote:
> On Sat, May 16, 2020 at 05:07:50PM -0700, Guenter Roeck wrote:
> > On Sat, May 16, 2020 at 05:00:50PM -0700, Guenter Roeck wrote:
> > > On Mon, May 11, 2020 at 09:41:36PM +0100, Will Deacon wrote:
> > > > Now that the page table
-set-variable]
> 300 | pud_t *pud;
> | ^~~
Here's the fix vs v5.7-rc6-mmots-2020-05-19-21-52:
>From 192848144e61e3ebacd34598386e4fa773d19ae9 Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Wed, 20 May 2020 15:39:22 +0300
Subject: [PATCH] sparc32: use PUD rather than PGD to ge
On Mon, May 18, 2020 at 11:09:46AM -0700, Guenter Roeck wrote:
> On 5/18/20 7:23 AM, Mike Rapoport wrote:
>
> Below is another set of bisect results, from next-20200518. It points to one
> of your commits. This is for microblaze (big endian) boot failures.
The microblaze
On Mon, May 18, 2020 at 02:48:18AM -0700, Guenter Roeck wrote:
> On 5/18/20 1:37 AM, Will Deacon wrote:
> > On Sat, May 16, 2020 at 05:07:50PM -0700, Guenter Roeck wrote:
> >> On Sat, May 16, 2020 at 05:00:50PM -0700, Guenter Roeck wrote:
> >>> On Mon, May 11, 2020 at 09:41:36PM +0100, Will Deacon
On Mon, May 18, 2020 at 09:37:15AM +0100, Will Deacon wrote:
> On Sat, May 16, 2020 at 05:07:50PM -0700, Guenter Roeck wrote:
> > On Sat, May 16, 2020 at 05:00:50PM -0700, Guenter Roeck wrote:
> > > On Mon, May 11, 2020 at 09:41:36PM +0100, Will Deacon wrote:
> > > > Now that the page table
On Fri, May 15, 2020 at 11:40:12AM -0700, Andrew Morton wrote:
> On Tue, 14 Apr 2020 18:34:44 +0300 Mike Rapoport wrote:
>
> > Implement primitives necessary for the 4th level folding, add walks of p4d
> > level where appropriate, replace 5level-fixup.h with pgtable-nop4
On Thu, May 14, 2020 at 10:17:57AM +0800, Bibo Mao wrote:
> From: bibo mao
>
> If there are two threads reading the same memory and tlb miss happens,
> one thread fills pte entry, the other reads new pte value during page fault
> handling. PTE value may be updated before page faul, so the
Hello Alexandre,
On Mon, May 04, 2020 at 04:57:57PM +0200, Alexandre Chartre wrote:
> This is part II of ASI RFC v4. Please refer to the cover letter of
> part I for an overview the ASI RFC.
>
>
> https://lore.kernel.org/lkml/20200504144939.11318-1-alexandre.char...@oracle.com/
>
> This part
Hi,
On Sat, Apr 18, 2020 at 09:19:36PM +0100, Dmitry Safonov wrote:
> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).
>
>
Hi Marek,
On Mon, May 11, 2020 at 08:36:41AM +0200, Marek Szyprowski wrote:
> Hi Mike,
>
> On 08.05.2020 19:42, Mike Rapoport wrote:
> > On Fri, May 08, 2020 at 08:53:27AM +0200, Marek Szyprowski wrote:
> >> On 07.05.2020 18:11, Mike Rapoport wrote:
> >>> On T
On Wed, May 06, 2020 at 05:41:40PM -0700, Anthony Yznaga wrote:
> The size of the memblock reserved array may be increased while preserved
> pages are being reserved. When this happens, preserved pages that have
> not yet been reserved are at risk for being clobbered when space for a
> larger
On Fri, May 08, 2020 at 08:53:27AM +0200, Marek Szyprowski wrote:
> Hi Mike,
>
> On 07.05.2020 18:11, Mike Rapoport wrote:
> > On Thu, May 07, 2020 at 02:16:56PM +0200, Marek Szyprowski wrote:
> >> On 14.04.2020 17:34, Mike Rapoport wrote:
> >>> From:
Hi,
On Thu, May 07, 2020 at 02:16:56PM +0200, Marek Szyprowski wrote:
> Hi
>
> On 14.04.2020 17:34, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Implement primitives necessary for the 4th level folding, add walks of p4d
> > level where appropriate,
Ho Christian,
On Mon, May 04, 2020 at 04:50:06PM +0200, Christian Borntraeger wrote:
> Mike,
> commit 51a2f644fd020d5f090044825c388444d11029d ("mm: free_area_init: allow
> defining max_zone_pfn in descending order")
> does increase the memory use on s390 (e.g. 700 MB vs.1.8 GB).
>
> Something
On Sat, May 02, 2020 at 12:16:41PM +0200, Mauro Carvalho Chehab wrote:
> Em Sat, 2 May 2020 10:41:33 +0300
> Mike Rapoport escreveu:
>
> > Hello Mauro,
> >
> > On Fri, May 01, 2020 at 05:37:51PM +0200, Mauro Carvalho Chehab wrote:
> > > There are 4 IRQ doc
Hello Mauro,
On Fri, May 01, 2020 at 05:37:55PM +0200, Mauro Carvalho Chehab wrote:
> There are a number of random documents that seem to be
> describing some aspects of the core-api. Move them to such
> directory, adding them at the core-api/index.rst file.
>
> Signed-off-by: Mauro Carvalho
Hello Mauro,
On Fri, May 01, 2020 at 05:37:51PM +0200, Mauro Carvalho Chehab wrote:
> There are 4 IRQ documentation files under Documentation/*.txt.
>
> Move them into a new directory (core-api/irq) and add a new
> index file for it.
Just curious, why IRQ docs got their subdirectory and DMA
; Add the missing __init annotations.
>
> Fixes: 4ada1e810038 ("initramfs: fix populate_initrd_image() section
> mismatch")
> Fixes: 23091e287355 ("initramfs: cleanup initrd freeing")
> Signed-off-by: Arnd Bergmann
Acked-by: Mike Rapoport
> ---
> init/init
On Wed, Oct 23, 2019 at 10:29:20AM +0300, Cyrill Gorcunov wrote:
> On Tue, Oct 22, 2019 at 09:11:04PM -0700, Andy Lutomirski wrote:
> > Trying again. It looks like I used the wrong address for Pavel.
>
> Thanks for CC Andy! I must confess I didn't dive into userfaultfd engine
> personally but
d new delta
> | free_pgd_range 546 656+110
> | p4d_clear_bad 2 20 +18
> | Total: Before=4137148, After=4137276, chg 0.00%
>
> Cc: Kirill A. Shutemov
> Signed-off-by: Vineet Gupta
Acked-by: Mike Rapoport
On October 15, 2019 2:46:59 AM GMT+02:00, Will Deacon wrote:
>On Sat, Sep 28, 2019 at 11:02:26AM +0300, Mike Rapoport wrote:
>> From: Mike Rapoport
>>
>> arm64 calls memblock_free() for the initrd area in its implementation
>of
>> free_initrd_mem(), but this call
On October 15, 2019 12:44:23 AM GMT+02:00, Andrew Morton
wrote:
>On Sun, 13 Oct 2019 00:31:01 +0300 Mike Rapoport
>wrote:
>
>> Until commit 92d12f9544b7 ("memblock: refactor internal allocation
>> functions") the maximal address for memblock allocations was force
From: Mike Rapoport
Until commit 92d12f9544b7 ("memblock: refactor internal allocation
functions") the maximal address for memblock allocations was forced to
memblock.current_limit only for the allocation functions returning virtual
address. The changes introduced by that commit moved
On Fri, Oct 04, 2019 at 10:27:27AM +0100, Russell King - ARM Linux admin wrote:
> 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:5
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 -
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 a
(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 wrote:
> >
>
> Before the patch:
>
> # cat /sys/kernel/debug/memblock/memory
>0: 0x1000..0x8fff
> # cat /sys/kernel/debug/memblock/
Hi,
Any updates on this?
On Mon, Sep 16, 2019 at 02:13:10PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The memory initialization of SGI-IP27 is already half-way to support
> SPARSEMEM. It only had free_bootmem_with_active_regions() left-overs
&
From: Mike Rapoport
arm64 calls memblock_free() for the initrd area in its implementation of
free_initrd_mem(), but this call has no actual effect that late in the boot
process. By the time initrd is freed, all the reserved memory is managed by
the page allocator and the memblock.reserved
On Fri, Sep 27, 2019 at 11:50:42AM +0530, Anshuman Khandual wrote:
>
> On 09/25/2019 10:39 AM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > arm64 calls memblock_free() for the initrd area in its implementation of
> > free_initrd_mem(), but this call
t will fall back to allocate
> small block memory base section.
>
> Signed-off-by: Yunfeng Ye
One nit below, otherwise
Reviewed-by: Mike Rapoport
> ---
> v2 -> v3:
> - use "bool exact_nid" instead of "int need_exact_nid"
> - remove the comment "
(updated CC)
Hi,
On Tue, Sep 24, 2019 at 12:52:35PM -0500, Adam Ford wrote:
> On Mon, Jan 21, 2019 at 2:05 AM Mike Rapoport wrote:
> >
> > Hi,
> >
> > v2 changes:
> > * replace some more %lu with %zu
> > * remove panics where they are not needed in
On Tue, Sep 24, 2019 at 04:09:32PM +0800, Yunfeng Ye wrote:
> sparse_buffer_init() use memblock_alloc_try_nid_raw() to allocate memory
> for page management structure, if memory allocation fails from specified
> node, it will fall back to allocate from other nodes.
>
> Normally, the page
From: Mike Rapoport
arm64 calls memblock_free() for the initrd area in its implementation of
free_initrd_mem(), but this call has no actual effect that late in the boot
process. By the time initrd is freed, all the reserved memory is managed by
the page allocator and the memblock.reserved
On Tue, Sep 24, 2019 at 02:51:01PM +0300, Kirill A. Shutemov wrote:
> On Fri, Sep 20, 2019 at 12:03:21PM +0530, Anshuman Khandual wrote:
> > This series adds a test validation for architecture exported page table
> > helpers. Patch in the series adds basic transformation tests at various
> >
From: Mike Rapoport
arm64 calls memblock_free() for the initrd area in its implementation of
free_initrd_mem(), but this call has no actual effect that late in the boot
process. By the time initrd is freed, all the reserved memory is managed by
the page allocator and the memblock.reserved
On Thu, Sep 19, 2019 at 05:03:15PM +0200, Thomas Gleixner wrote:
> On syscall entry certain work needs to be done conditionally like tracing,
> seccomp etc. This code is duplicated in all architectures.
>
> Provide a generic version.
>
> Signed-off-by: Thomas Gleixner
> ---
> arch/Kconfig
On Thu, Sep 19, 2019 at 03:14:22PM +0800, Yunfeng Ye wrote:
>
>
> On 2019/9/19 12:47, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Sep 18, 2019 at 12:22:29PM +0800, Yunfeng Ye wrote:
> >> Currently, when memblock_find_in_range_node() fail on the exact
Hi,
On Wed, Sep 18, 2019 at 12:22:29PM +0800, Yunfeng Ye wrote:
> Currently, when memblock_find_in_range_node() fail on the exact node, it
> will use %NUMA_NO_NODE to find memblock from other nodes. At present,
> the work is good, but when the large memory is insufficient and the
> small memory
(added linux-arch)
On Mon, Sep 16, 2019 at 08:23:29AM -0400, Laura Abbott wrote:
> On 9/16/19 8:21 AM, Mike Rapoport wrote:
> >From: Mike Rapoport
> >
> >arm64 calls memblock_free() for the initrd area in its implementation of
> >free_initrd_mem(), but this call has
1101 - 1200 of 2824 matches
Mail list logo
