The blamed patch attempted to do a trivial conversion of
map_mem_in_cams() by adding an extra "bool init" argument, but by
mistake, changed the way in which two call sites pass the other boolean
argument, "bool dry_run".
As a result, early_init_this_mmu() now calls map_mem_in_cams() with
dry_run=t
On Wed, 10 Nov 2021 00:29:10 +, cgel@gmail.com wrote:
> From: Ye Guojin
>
> This was found by coccicheck:
> ./sound/soc/fsl/imx-hdmi.c,209,1-7,ERROR missing put_device; call
> of_find_device_by_node on line 119, but without a corresponding object
> release within this function.
>
> [...
The irqdomain code already returns the information. Move the loop to the
legacy code.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/legacy.c | 20 +++-
drivers/pci/msi/msi.c| 19 +--
2 files changed, 20 insertions(+), 19 deletions(-)
--- a/drivers/pc
Get rid of yet another irqdomain callback and let the core code return the
already available information of how many descriptors could be allocated.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/irqdomain.c | 13 -
include/linux/msi.h |5 +
kernel/irq/msi.c
Unmapping the MSIX base mapping in the loops which allocate/free MSI
desciptors is daft and in the way of allowing runtime expansion of MSI-X
descriptors.
Store the mapping in struct pci_dev and free it after freeing the MSI-X
descriptors.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.
No users outside of that file.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/irqdomain.c |5 +++--
include/linux/msi.h |2 --
2 files changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/pci/msi/irqdomain.c
+++ b/drivers/pci/msi/irqdomain.c
@@ -79,8 +79,9 @@ static inline
Move the irqdomain specific code into it's own file.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/Makefile|1
drivers/pci/msi/irqdomain.c | 279 ++
drivers/pci/msi/legacy.c| 10 +
drivers/pci/msi/msi.c | 319 +--
Split out the non irqdomain code into its own file.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/Makefile |5 ++--
drivers/pci/msi/legacy.c | 51 +++
drivers/pci/msi/msi.c| 46 --
3 files change
These functions are required even when CONFIG_PCI_MSI is not set. Move them
to their own file.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/Makefile |3 ++-
drivers/pci/msi/msi.c| 39 ---
drivers/pci/msi/pcidev_msi.c | 43
msi.c is getting larger and really could do with a splitup. Move it into
it's own directory to prepare for that.
Signed-off-by: Thomas Gleixner
---
Documentation/driver-api/pci/pci.rst |2
drivers/pci/Makefile |3
drivers/pci/msi.c| 1532
No need to walk the descriptors and check for each one whether the entries
pointer function argument is NULL. Do it once.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -642,8 +
Get rid of the pile of unneeded includes which accumulated over time.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -7,22 +7,14 @@
* Copyright (C) 2016 Christoph
Make arch_restore_msi_irqs() return a boolean which indicates whether the
core code should restore the MSI message or not. Get rid of the indirection
in x86.
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: Christian Borntraeger
Cc: Hei
The unnamed struct sucks and is in the way of further cleanups. Stick the
PCI related MSI data into a real data structure and cleanup all users.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Cc: xen-de...@lists.xen
No point in looking up things over and over. Just look up the associated
irq data and work from there.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Wei Liu
Cc: x...@kernel.org
Cc: linux-hyp...@vger.kernel.org
---
arch/x86/hyperv/irqdomain.c | 55 +-
instead of fiddling with msi descriptors.
Signed-off-by: Thomas Gleixner
---
drivers/pci/pci-sysfs.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -62,11 +62,8 @@ static ssize_t irq_show(struct device *d
*
The core code provides the same loop code except for the MSI-X reject. Move
that to arch_setup_msi_irq() and remove the duplicated code.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
---
arch/mips/pci/msi-octeon.c | 32 +++
Last user is gone long ago.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi.c |8
include/linux/msi.h |5 -
2 files changed, 13 deletions(-)
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1253,14 +1253,6 @@ struct pci_dev *msi_desc_to_pci_dev(stru
}
EXPORT_SYMBO
There is no point to have this function public as it is set by the PCI core
anyway when a PCI/MSI irqdomain is created.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/irq-gic-v2m.c|1 -
drivers/irqchip/irq-gic-v3-its-pci-msi.c |1 -
drivers/irqchip/irq-gic-v3-mbi.c
No users and there is no need to grow them.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h | 11 ---
kernel/irq/msi.c|5 -
2 files changed, 4 insertions(+), 12 deletions(-)
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -304,7 +304,6 @@ struct msi_domain_in
Remove the kobject.h include from msi.h as it's not required and add a
sysfs.h include to the core code instead.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h |1 -
kernel/irq/msi.c|1 +
2 files changed, 1 insertion(+), 1 deletion(-)
--- a/include/linux/msi.h
+++ b/include/
This code is broken since day one. ppc4xx_setup_msi_irqs() has the
following gems:
1) The handling of the result of msi_bitmap_alloc_hwirqs() is completely
broken:
When the result is greater than or equal 0 (bitmap allocation
successful) then the loop terminates and the function
The [PCI] MSI code has gained quite some warts over time. A recent
discussion unearthed a shortcoming: the lack of support for expanding
PCI/MSI-X vectors after initialization of MSI-X.
PCI/MSI-X has no requirement to setup all vectors when MSI-X is enabled in
the device. The non-used vectors have
No point in building unused code when CONFIG_SYSFS=n.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h | 10 ++
kernel/irq/msi.c|2 ++
2 files changed, 12 insertions(+)
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -239,9 +239,19 @@ void __pci_write_msi_msg(stru
pci_irq_vector() and pci_irq_get_affinity() use the list position to find the
MSI-X descriptor at a given index. That's correct for the normal case where
the entry number is the same as the list position.
But it's wrong for cases where MSI-X was allocated with an entries array
describing sparse en
Hi Hari,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.16-rc2 next-20211126]
[cannot apply to mpe/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
All pm_power_off_prepare() users were converted to sys-off handler API.
Remove the obsolete callback.
Signed-off-by: Dmitry Osipenko
---
include/linux/pm.h | 1 -
kernel/reboot.c| 11 ---
2 files changed, 12 deletions(-)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 1d
Use devm_register_sys_off_handler() that replaces global
pm_power_off_prepare variable and allows to register multiple
power-off handlers.
Acked-by: Mark Brown
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/pfuze100-regulator.c | 38 ++
1 file changed, 14 insertion
Switch to sys-off API that replaces legacy pm_power_off callbacks.
Signed-off-by: Dmitry Osipenko
---
drivers/acpi/sleep.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index eaa47753b758..2e613fddd614
Replace legacy pm_power_off with kernel_can_power_off() helper that
is aware about chained power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/memory/emif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 762d0c0f
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/nds32/kerne
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/mips/kernel
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/ia64/kernel
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/x86/kernel/
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/sh/kernel/r
Kernel now supports chained power-off handlers. Use
register_power_off_handler() that registers power-off handlers and
do_kernel_power_off() that invokes chained power-off handlers. Legacy
pm_power_off() will be removed once all drivers will be converted to
the new power-off API.
Normally arch cod
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Michael Ellerman
Signed-off-by: Dmitry Osi
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Juergen Gross
Signed-off-by: Dmitry Osipen
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Helge Deller # parisc
Signed-off-by: Dmitr
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Catalin Marinas
Signed-off-by: Dmitry Osip
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Palmer Dabbelt
Signed-off-by: Dmitry Osipe
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Guo Ren
Signed-off-by: Dmitry Osipenko
--
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Reviewed-by: Russell King (Oracle)
Signed-off-by: Dm
SoC platforms often have multiple ways of how to perform system's
power-off and restart operations. Meanwhile today's kernel is limited to
a single option. Add combined power-off+restart handler call chain API,
which is inspired by the restart API. The new API provides both power-off
and restart fu
There is no need to annotate function prototypes with 'extern', it makes
code less readable. Remove unnecessary annotations from .
Signed-off-by: Dmitry Osipenko
---
include/linux/reboot.h | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git
Emit warning if unregister_restart_handler() fails since it never should
fail. This will ease further API development by catching mistakes early.
Signed-off-by: Dmitry Osipenko
---
kernel/reboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/reboot.c b/kernel/reboot
Add sanity check which ensures that there are no two restart handlers
registered with the same priority. Normally it's a direct sign of a
problem if two handlers use the same priority.
Signed-off-by: Dmitry Osipenko
---
kernel/reboot.c | 15 ++-
1 file changed, 14 insertions(+), 1 de
Correct s/implemenations/implementations/ in .
Signed-off-by: Dmitry Osipenko
---
include/linux/reboot.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index af907a3d68d1..7c288013a3ca 100644
--- a/include/linux/reboot.h
+++ b/
Add atomic/blocking_notifier_has_unique_priority() helpers which return
true if given handler has unique priority.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 5 +++
kernel/notifier.c| 69
2 files changed, 74 insertions(+)
diff
Add blocking_notifier_call_chain_is_empty() that returns true if call
chain is empty.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 2 ++
kernel/notifier.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include/linux/notifier.h b/include/linux/notifi
There is no need to annotate function prototypes with 'extern', it makes
code less readable. Remove unnecessary annotations from .
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/incl
Problem
---
SoC devices require power-off call chaining functionality from kernel.
We have a widely used restart chaining provided by restart notifier API,
but nothing for power-off.
Solution
Introduce new API that provides both restart and power-off call chains.
Why combine restar
Hi Christophe,
I love your patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on hnaz-mm/master linus/master v5.16-rc2 next-20211126]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
> Running code patching self-tests ...
> patch_instruction() called on invalid text address 0xe1011e58 from
> test_code_patching+0x34/0xd6c
>
> Reported-by: Sachin Sant
> Reported-by: Stephen Rothwell
> Cc: Nicholas Piggin
> Fixes: 8b8a8f0ab3f5 ("powerpc/code-patching: Improve verification
Le 09/08/2019 à 14:36, Michael Ellerman a écrit :
Chuhong Yuan writes:
Reference counters are preferred to use refcount_t instead of
atomic_t.
This is because the implementation of refcount_t can prevent
overflows and detect possible use-after-free.
So convert atomic_t ref counters to refcou
Hi Michael,
Any chance to get this series merged this cycle ?
Thanks
Christophe
Le 21/09/2021 à 17:09, Christophe Leroy a écrit :
> Today we get the following code generation for bitops like
> set or clear bit:
>
> c0009fe0: 39 40 08 00 li r10,2048
> c0009fe4: 7
On Fri, Nov 26, 2021 at 05:57:58PM +0100, Christophe Leroy wrote:
>
>
> Le 26/11/2021 à 17:54, Greg Kroah-Hartman a écrit :
> > On Fri, Nov 26, 2021 at 05:47:58PM +0100, Christophe Leroy wrote:
> > > sparse warnings: (new ones prefixed by >>)
> > > > > drivers/w1/slaves/w1_ds28e04.c:342:13: spars
sparse warnings: (new ones prefixed by >>)
>> drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: sparse: incorrect type in
>> initializer (different address spaces) @@ expected char [noderef] __user
>> *_pu_addr @@ got char *buf @@
drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: expecte
Le 26/11/2021 à 17:54, Greg Kroah-Hartman a écrit :
On Fri, Nov 26, 2021 at 05:47:58PM +0100, Christophe Leroy wrote:
sparse warnings: (new ones prefixed by >>)
drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected ch
On Fri, Nov 26, 2021 at 05:47:58PM +0100, Christophe Leroy wrote:
> sparse warnings: (new ones prefixed by >>)
> >> drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: sparse: incorrect type in
> >> initializer (different address spaces) @@ expected char [noderef]
> >> __user *_pu_addr @@ got
sparse warnings: (new ones prefixed by >>)
>> drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: sparse: incorrect type in
>> initializer (different address spaces) @@ expected char [noderef] __user
>> *_pu_addr @@ got char *buf @@
drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: expecte
Le 26/11/2021 à 16:46, Nathan Chancellor a écrit :
On Fri, Nov 26, 2021 at 02:59:29PM +0100, Arnd Bergmann wrote:
On Fri, Nov 26, 2021 at 2:43 PM Christophe Leroy
wrote:
Le 25/11/2021 à 16:44, Anders Roxell a écrit :
Can't you fix CLANG instead :) ?
Or just add an else to the IS_ENABLED(CO
On Fri, Nov 26, 2021 at 05:10:46PM +0100, Christophe Leroy wrote:
>
>
> Le 26/11/2021 à 17:00, Greg Kroah-Hartman a écrit :
> > On Fri, Nov 19, 2021 at 10:15:09AM +0100, Christophe Leroy wrote:
> > > sparse warnings: (new ones prefixed by >>)
> > > > > drivers/w1/slaves/w1_ds28e04.c:342:13: spars
Le 26/11/2021 à 17:00, Greg Kroah-Hartman a écrit :
On Fri, Nov 19, 2021 at 10:15:09AM +0100, Christophe Leroy wrote:
sparse warnings: (new ones prefixed by >>)
drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected ch
On Fri, Nov 19, 2021 at 10:15:09AM +0100, Christophe Leroy wrote:
> sparse warnings: (new ones prefixed by >>)
> >> drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: sparse: incorrect type in
> >> initializer (different address spaces) @@ expected char [noderef]
> >> __user *_pu_addr @@ got
On Fri, Nov 26, 2021 at 02:59:29PM +0100, Arnd Bergmann wrote:
> On Fri, Nov 26, 2021 at 2:43 PM Christophe Leroy
> wrote:
> > Le 25/11/2021 à 16:44, Anders Roxell a écrit :
> > Can't you fix CLANG instead :) ?
> >
> > Or just add an else to the IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) that
> > set
On Fri, Nov 26, 2021 at 2:43 PM Christophe Leroy
wrote:
> Le 25/11/2021 à 16:44, Anders Roxell a écrit :
> Can't you fix CLANG instead :) ?
>
> Or just add an else to the IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) that
> sets hstart and hend to 0 ?
That doesn't sound any less risky than duplicating
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: 2dbc3a3e8fc1ea24589150a874cd37904898286a Automatic merge of
'next' into merge (2021-11-25 21:55)
elapsed time: 1569m
configs tested: 54
configs skipped: 3
The following configs have been built su
Le 25/11/2021 à 16:44, Anders Roxell a écrit :
Clang warns:
arch/powerpc/mm/book3s64/radix_tlb.c:1191:23: error: variable 'hstart' is
uninitialized when used here [-Werror,-Wuninitialized]
__tlbiel_va_range(hstart, hend, pid,
Today we have the following IBATs allocated:
---[ Instruction Block Address Translation ]---
0: 0xc000-0xc03f 0x 4M Kernel x m
1: 0xc040-0xc05f 0x0040 2M Kernel x m
2: 0xc060-0xc06f 0x0060 1
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #40 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Would also be great if you can activate CONFIG_PTDUMP_DEBUGFS and provide the
content of /sys/kernel/debug/kernel_page_tables
--
You may reply to this email to add a comment
Excerpts from Daniel Axtens's message of November 26, 2021 4:09 pm:
> Hi,
>
>> pmd_huge is defined out to false when HUGETLB_PAGE is not configured,
>> but the vmap code still installs huge PMDs. This leads to errors
>> encountering bad PMDs when vunmapping because it is not seen as a
>> huge PTE,
Le 26/11/2021 à 11:27, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of November 26, 2021 4:34 pm:
Le 26/11/2021 à 04:22, Nicholas Piggin a écrit :
Code patching tests patch the stack and (non-module) vmalloc space now,
which falls afoul of the new address check.
The
Excerpts from Cédric Le Goater's message of November 26, 2021 5:13 pm:
> On 11/26/21 06:21, Nicholas Piggin wrote:
>> KVM does not support VAS so guests always print a useless error on boot
>>
>> vas: HCALL(398) error -2, query_type 0, result buffer 0x57f2000
>>
>> Change this to only print
We have wrong units on BAT's sizes (G instead of M, M instead of ...)
---[ Instruction Block Address Translation ]---
0: 0xc000-0xc03f 0x 4G Kernel x m
1: 0xc040-0xc05f 0x0040 2G Kernel x m
2: 0xc060-0xc06f
Excerpts from Christophe Leroy's message of November 26, 2021 4:34 pm:
>
>
> Le 26/11/2021 à 04:22, Nicholas Piggin a écrit :
>> Code patching tests patch the stack and (non-module) vmalloc space now,
>> which falls afoul of the new address check.
>>
>> The stack patching can easily be fixed, bu
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #39 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Can you retry with CONFIG_LOWMEM_SIZE=0x2800 or
CONFIG_LOWMEM_SIZE=0x2000 ?
--
You may reply to this email to add a comment.
You are receiving this mail because:
Yo
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #38 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Looks like only x86 are arm implement this vmalloc= parameter:
[chleroy@PO20335 linux-powerpc]$ git grep 'early_param("vmalloc"' arch/
arch/arm/mm/mmu.c:early_param("vmalloc"
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #37 from Christophe Leroy (christophe.le...@csgroup.eu) ---
I see no obvious reason for a 32Mb allocation to fail while you have 588612kB
free memory.
And that happens early at boot, before user processes are started so the vmap
area,
Le 26/11/2021 à 08:39, Christophe Leroy a écrit :
Commit 8b8a8f0ab3f5 ("powerpc/code-patching: Improve verification of
patchability") introduced a stricter verification of the patched
area by checking it is proper kernel text.
But as least two usages of patch_instruction() fall outside:
- Cod
Le 24/11/2021 à 15:43, Christophe Leroy a écrit :
> Looks like recent binutils (2.36 and over ?) may empty some section,
> leading to failure like:
>
> Cannot find symbol for section 11: .text.unlikely.
> kernel/kexec_file.o: failed
> make[1]: *** [scripts/Makefile.build:287: k
81 matches
Mail list logo
