With the EEH early probe now being pseries specific there's no need for
eeh_ops->probe() to take a pci_dn. Instead, we can make it take a pci_dev
and use the probe function to map a pci_dev to an eeh_dev. This allows
the platform to implement it's own method for finding (or creating) an
eeh_dev
The eeh_ops->probe() function is called from two different contexts:
1. On pseries, where we set EEH_PROBE_MODE_DEVTREE, it's called in
eeh_add_device_early() which is supposed to run before we create
a pci_dev.
2. On PowerNV, where we set EEH_PROBE_MODE_DEV, it's called in
This check for a missing PHB has existing in various forms since the
initial PPC64 port was upstreamed in 2002. The idea seems to be that we
need to guard against creating pci-specific data structures for the non-pci
children of a PCI device tree node (e.g. USB devices). However, we only
create
The pci hotplug helper (pci_hp_add_devices()) calls
eeh_add_device_tree_early() to scan the device-tree for new PCI devices and
do the early EEH probe before the device is scanned. This early probe is a
no-op in a lot of cases because:
a) The early init is only required to satisfy a PAPR
On pseries and PowerNV pcibios_bus_add_device() calls eeh_add_device_late()
so there's no need to do a separate tree traversal to bind the eeh_dev and
pci_dev together setting up the PHB at boot. As a result we can remove
eeh_add_device_tree_late().
Reviewed-by: Sam Bobroff
Signed-off-by: Oliver
Move creating the EEH specific sysfs files into eeh_add_device_late()
rather than being open-coded all over the place. Calling the function is
generally done immediately after calling eeh_add_device_late() anyway. This
is also a correctness fix since currently the sysfs files will be added
even if
kcov instrumentation is collected the __sanitizer_cov_trace_pc hook in
kernel/kcov.c. The compiler inserts these hooks into every basic block
unless kcov is disabled for that file.
We then have a deep call-chain:
- __sanitizer_cov_trace_pc calls to check_kcov_mode()
- check_kcov_mode()
Le 06/03/2020 à 05:48, Qian Cai a écrit :
Booting a power9 server with hash MMU could trigger an undefined
behaviour because pud_offset(p4d, 0) will do,
0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
Fix it by converting pud_index() and friends to static inline
functions.
The original kernel still exists in the memory, clear it now.
Signed-off-by: Jason Yan
Cc: Scott Wood
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
---
arch/powerpc/mm/nohash/kaslr_booke.c | 4
The BSS section has already cleared out in the first pass. No need to
clear it again. This can save some time when booting with KASLR
enabled.
Signed-off-by: Jason Yan
Cc: Scott Wood
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Now we support both 32 and 64 bit KASLR for fsl booke. Add document for
64 bit part and rename kaslr-booke32.rst to kaslr-booke.rst.
Signed-off-by: Jason Yan
Cc: Scott Wood
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc:
Like the 32bit code, we introduce reloc_kernel_entry() helper to prepare
for the KASLR 64bit version. And move the C declaration of this function
out of CONFIG_PPC32 and use long instead of int for the parameter 'addr'.
Signed-off-by: Jason Yan
Cc: Scott Wood
Cc: Diana Craciun
Cc: Michael
The implementation for Freescale BookE64 is similar as BookE32. One
difference is that Freescale BookE64 set up a TLB mapping of 1G during
booting. Another difference is that ppc64 needs the kernel to be
64K-aligned. So we can randomize the kernel in this 1G mapping and make
it 64K-aligned. This
This is a try to implement KASLR for Freescale BookE64 which is based on
my earlier implementation for Freescale BookE32:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=131718=*
The implementation for Freescale BookE64 is similar as BookE32. One
difference is that Freescale
Some code refactor in kaslr_legal_offset() and kaslr_early_init(). No
functional change. This is a preparation for KASLR fsl_booke64.
Signed-off-by: Jason Yan
Cc: Scott Wood
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc:
Hi all,
Today's linux-next merge of the akpm tree got conflicts in:
arch/powerpc/mm/book3s32/mmu.c
arch/powerpc/mm/book3s32/tlb.c
arch/powerpc/mm/kasan/kasan_init_32.c
arch/powerpc/mm/mem.c
arch/powerpc/mm/nohash/40x.c
arch/powerpc/mm/pgtable_32.c
between commits:
0b1c524caaae
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
arch/powerpc/mm/pgtable_32.c
between commit:
2efc7c085f05 ("powerpc/32: drop get_pteptr()")
from the powerpc tree and patch:
"powerpc/32: drop get_pteptr()"
from the akpm tree.
I fixed it up (I just dropped the
randconfig-a001-20200305
x86_64 randconfig-a002-20200305
x86_64 randconfig-a003-20200305
i386 randconfig-a001-20200305
i386 randconfig-a002-20200305
i386 randconfig-a003-20200305
alpharandconfig-a001-20200305
m68k
randconfig-a001-20200306
riscvrandconfig-a001-20200306
alpharandconfig-a001-20200305
m68k randconfig-a001-20200305
mips randconfig-a001-20200305
nds32randconfig-a001-20200305
parisc randconfig-a001-20200305
allyesconfig
mips fuloong2e_defconfig
mips malta_kvm_defconfig
pariscallnoconfig
pariscgeneric-32bit_defconfig
pariscgeneric-64bit_defconfig
x86_64 randconfig-a001-20200305
-a001-20200305
x86_64 randconfig-a002-20200305
x86_64 randconfig-a003-20200305
i386 randconfig-a001-20200305
i386 randconfig-a002-20200305
i386 randconfig-a003-20200305
x86_64 randconfig-a001-20200306
x86_64
On 3/2/20 8:38 PM, Jiri Olsa wrote:
> On Sat, Feb 29, 2020 at 03:11:57PM +0530, Kajol Jain wrote:
>
> SNIP
>
>> #define PVR_VER(pvr)(((pvr) >> 16) & 0x) /* Version field */
>> #define PVR_REV(pvr)(((pvr) >> 0) & 0x) /* Revison field */
>>
>> +#define
> On Mar 5, 2020, at 2:22 PM, Christophe Leroy wrote:
>
>
>
> Le 05/03/2020 à 15:32, Qian Cai a écrit :
>> Booting a power9 server with hash MMU could trigger an undefined
>> behaviour because pud_offset(p4d, 0) will do,
>> 0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
>>
Booting a power9 server with hash MMU could trigger an undefined
behaviour because pud_offset(p4d, 0) will do,
0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
Fix it by converting pud_index() and friends to static inline
functions.
UBSAN: shift-out-of-bounds in
On 6/3/20 3:40 pm, Daniel Axtens wrote:
There's some special handling for CPU_FTR_HVMODE in
cpufeatures_setup_cpu() in kernel/dt_cpu_ftrs.c:
/* Initialize the base environment -- clear FSCR/HFSCR. */
hv_mode = !!(mfmsr() & MSR_HV);
if (hv_mode) {
> There's some special handling for CPU_FTR_HVMODE in
> cpufeatures_setup_cpu() in kernel/dt_cpu_ftrs.c:
>
> /* Initialize the base environment -- clear FSCR/HFSCR. */
> hv_mode = !!(mfmsr() & MSR_HV);
> if (hv_mode) {
> /* CPU_FTR_HVMODE is used early
Thanks Nick,
> Signed-off-by: Nicholas Piggin
Tested-by: Anton Blanchard
> ---
> arch/powerpc/mm/book3s64/radix_pgtable.c | 1 +
> arch/powerpc/mm/book3s64/radix_tlb.c | 7 ++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git
On Fri, Mar 6, 2020 at 9:27 AM Michael Ellerman
wrote:
>
> On Wed, 2020-02-19 at 00:04:34 UTC, Michael Ellerman wrote:
> > Some of our phony targets are not marked as such. This can lead to
> > confusing errors, eg:
> >
> > $ make clean
> > $ touch install
> > $ make install
> > make:
On Wed, 2020-03-04 at 17:53 +1100, Andrew Donnellan wrote:
> On 21/2/20 2:27 pm, Alastair D'Silva wrote:
> > +static int ioctl_controller_dump_data(struct ocxlpmem *ocxlpmem,
> > + struct ioctl_ocxl_pmem_controller_dump_data __user
> > *uarg)
> > +{
> > + struct
The VDSO exports a bitmap of valid syscalls. vdso_setup_syscall_map()
sets this up, but there are both little and big endian bugs. The issue
is with:
if (sys_call_table[i] != sys_ni_syscall)
On little endian, instead of comparing pointers to the two functions,
we compare the first two
On Fri, Feb 28, 2020 at 2:09 PM Nicholas Piggin wrote:
>
> These calls can be used by Linux to annotate BUG addresses with symbols,
> look up symbol addresses in xmon, etc.
>
> This is preferable over having Linux parse the OPAL symbol map itself,
> because OPAL's parsing code already exists for
On Fri, Mar 06, 2020 at 11:26:36AM +1100, Gustavo Romero wrote:
> Fix typos found in comments about the parameter passed
> through r5 to kvmppc_{save,restore}_tm_hv functions.
Actually "iff" is a common shorthand in some fields and not necessarily
a spelling error:
Hi Gabriel,
On 03/06/2020 01:06 PM, Gabriel Paubert wrote:
On Fri, Mar 06, 2020 at 11:26:36AM +1100, Gustavo Romero wrote:
Fix typos found in comments about the parameter passed
through r5 to kvmppc_{save,restore}_tm_hv functions.
Actually "iff" is a common shorthand in some fields and not
On Mon, Feb 24, 2020 at 10:21:00AM -0600, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced
Fix typos found in comments about the parameter passed
through r5 to kvmppc_{save,restore}_tm_hv functions.
Signed-off-by: Gustavo Romero
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
On Thu, 2020-02-20 at 11:51:37 UTC, Michael Ellerman wrote:
> current_stack_pointer(), which was called __get_SP(), used to just
> return the value in r1.
>
> But that caused problems in some cases, so it was turned into a
> function in commit bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a
>
On Wed, 2020-02-19 at 00:04:34 UTC, Michael Ellerman wrote:
> Some of our phony targets are not marked as such. This can lead to
> confusing errors, eg:
>
> $ make clean
> $ touch install
> $ make install
> make: 'install' is up to date.
> $
>
> Fix it by adding them to the PHONY
On Mon, 2020-02-17 at 09:41:35 UTC, Christophe Leroy wrote:
> On PPC32, pte_offset_map() does a kmap_atomic() in order to support
> page tables allocated in high memory, just like ARM and x86/32.
>
> But since at least 2008 and commit 8054a3428fbe ("powerpc: Remove dead
> CONFIG_HIGHPTE"), page
On Fri, 2020-02-14 at 08:06:05 UTC, Kajol Jain wrote:
> From: Madhavan Srinivasan
>
> An attempt to refactor the current sysfs.c file.
> To start with a big chuck of macro #defines and dscr
> functions are moved to start of the file. Secondly,
> HAS_ #define macros are cleanup based on CONFIG_
On Mon, 2020-02-17 at 02:48:32 UTC, Oliver O'Halloran wrote:
> Treat an empty reboot cmd string the same as a NULL string. This squashes a
> spurious unsupported reboot message that sometimes gets out when using
> xmon.
>
> Signed-off-by: Oliver O'Halloran
Series applied to powerpc next,
On Sun, 2020-02-09 at 10:58:56 UTC, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul
On Sat, 2020-02-08 at 14:09:04 UTC, Christophe JAILLET wrote:
> "couldn;t" should be "couldn't".
>
> Signed-off-by: Christophe JAILLET
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/365ad0b60d944050d61252e123e6a8b2c3950398
cheers
On Mon, 2020-02-03 at 16:47:37 UTC, Christophe Leroy wrote:
> _tlbia() is a function used only on 603/603e core, ie on CPUs which
> don't have a hash table.
>
> _tlbia() uses the tlbia macro which implements a loop of 1024 tlbie.
>
> On the 603/603e core, flushing the entire TLB requires no more
On Sat, 2020-02-01 at 08:04:31 UTC, Christophe Leroy wrote:
> When flushing any memory range, the flushing function
> flushes all TLBs.
>
> When (start) and (end - 1) are in the same memory page,
> flush that page instead.
>
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
On Fri, 2020-01-31 at 13:28:29 UTC, Michal Suchanek wrote:
>
> From: Libor Pechacek
>
> In guests without hotplugagble memory drmem structure is only zero
> initialized. Trying to manipulate DLPAR parameters results in a crash.
>
> $ echo "memory add count 1" > /sys/kernel/dlpar
> Oops: Kernel
On Fri, 2020-01-31 at 11:34:54 UTC, Christophe Leroy wrote:
> Since commit b86fb88855ea ("powerpc/32: implement fast entry for
> syscalls on non BOOKE") and commit 1a4b739bbb4f ("powerpc/32:
> implement fast entry for syscalls on BOOKE"), syscalls from
> kernel are unexpected and can have
On Thu, 2020-01-30 at 06:31:52 UTC, Oliver O'Halloran wrote:
> vio.c requires CONFIG_IBMVIO which in turn depends on PPC_PSERIES.
> In other words, this ifdef is pointless. At a guess it's a carry-over
> from pre-history.
>
> Signed-off-by: Oliver O'Halloran
Series applied to powerpc next,
On Thu, 2020-01-30 at 04:02:06 UTC, Vaibhav Jain wrote:
> Function papr_scm_ndctl() is neither exported from the module nor
> called directly from outside 'papr.c' hence should be marked 'static'.
>
> Signed-off-by: Vaibhav Jain
Applied to powerpc next, thanks.
On Wed, 2020-01-29 at 19:50:07 UTC, Christophe Leroy wrote:
> is_32bit_task() exists on both PPC64 and PPC32, no need of an ifdefery.
>
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ba32f4b02105e57627912b42e141d65d90074c64
cheers
On Wed, 2020-01-29 at 13:52:57 UTC, Srikar Dronamraju wrote:
> There is no value in unpacking associativity, if
> H_HOME_NODE_ASSOCIATIVITY hcall has returned an error.
>
> Signed-off-by: Srikar Dronamraju
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Nathan Lynch
> Cc:
On Wed, 2020-01-29 at 13:51:21 UTC, Srikar Dronamraju wrote:
> Package_id is to find out all cores that are part of the same chip. On
> PowerNV machines, package_id defaults to chip_id. However ibm,chip_id
> property is not present in device-tree of PowerVM Lpars. Hence lscpu
> output shows one
On Thu, 2020-01-09 at 08:25:25 UTC, Christophe Leroy wrote:
> At several places pmd pointer is retrieved through the same action:
>
> pmd = pmd_offset(pud_offset(pgd_offset(mm, addr), addr), addr);
>
> or
>
> pmd = pmd_offset(pud_offset(pgd_offset_k(addr), addr), addr);
>
>
On Tue, 2020-01-07 at 09:16:40 UTC, Christophe Leroy wrote:
> Since commit b86fb88855ea ("powerpc/32: implement fast entry for
> syscalls on non BOOKE") and commit 1a4b739bbb4f ("powerpc/32:
> implement fast entry for syscalls on BOOKE"), syscalls don't
> use the exception entry path anymore. It
On Mon, 2019-12-23 at 06:03:51 UTC, Alexey Kardashevskiy wrote:
> The last jump to free_exit in mm_iommu_do_alloc() happens after page
> pointers in struct mm_iommu_table_group_mem_t were already converted to
> physical addresses. Thus calling put_page() on these physical addresses
> will likely
On Wed, 2019-12-11 at 16:09:05 UTC, Sourabh Jain wrote:
> Add missing ABI documentation for existing FADump sysfs files.
>
> Signed-off-by: Sourabh Jain
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f52153ab383f04a45c38d8a7f55a4249477b20df
cheers
On Thu, 2020-03-05 at 20:32 -0300, Leonardo Bras wrote:
> I will send the matching qemu change as a reply later.
http://patchwork.ozlabs.org/patch/1249931/
signature.asc
Description: This is a digitally signed message part
On Tue, 2020-03-03 at 23:57:08 UTC, Michael Ellerman wrote:
> We received a report of strange kernel faults which turned out to be
> due to a missing KUAP disable in flush_coherent_icache() called
> from flush_icache_range().
>
> The fault looks like:
>
> Kernel attempted to access user page
On Thu, 2020-02-27 at 13:47:15 UTC, "Desnes A. Nunes do Rosario" wrote:
> PowerVM systems running compatibility mode on a few Power8 revisions are
> still vulnerable to the hardware defect that loses PMU exceptions arriving
> prior to a context switch.
>
> The software fix for this issue is
https://bugzilla.kernel.org/show_bug.cgi?id=206695
--- Comment #5 from m...@ellerman.id.au ---
bugzilla-dae...@bugzilla.kernel.org writes:
> https://bugzilla.kernel.org/show_bug.cgi?id=206695
>
> --- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
> (In reply to mpe from comment #3)
>> Can
bugzilla-dae...@bugzilla.kernel.org writes:
> https://bugzilla.kernel.org/show_bug.cgi?id=206695
>
> --- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
> (In reply to mpe from comment #3)
>> Can you try this patch?
>
> Applied your patch on top of 5.6-rc4 +
>
This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or addition of new ones.
This test covers basic page table
On Tue, 2020-03-03 at 19:04 +0100, Frederic Barrat wrote:
>
> Le 21/02/2020 à 04:27, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > This patch adds IOCTLs to allow userspace to request & fetch dumps
> > of the internal controller state.
> >
> > This is useful during debugging or
While providing guests, it's desirable to resize it's memory on demand.
By now, it's possible to do so by creating a guest with a small base
memory, hot-plugging all the rest, and using 'movable_node' kernel
command-line parameter, which puts all hot-plugged memory in
ZONE_MOVABLE, allowing it to
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
fs/sysfs/group.c
between commit:
9255782f7061 ("sysfs: Wrap __compat_only_sysfs_link_entry_to_kobj function to
change the symlink name")
from the powerpc tree and commit:
303a42769c4c ("sysfs: add
On Thu, Mar 05, 2020 at 10:08:37AM -0500, Arvind Sankar wrote:
> For security, don't display the kernel's virtual memory layout.
>
> Kees Cook points out:
> "These have been entirely removed on other architectures, so let's
> just do the same for ia32 and remove it unconditionally."
>
>
For security, don't display the kernel's virtual memory layout.
Kees Cook points out:
"These have been entirely removed on other architectures, so let's
just do the same for ia32 and remove it unconditionally."
071929dbdd86 ("arm64: Stop printing the virtual memory layout")
1c31d4e96b8c ("ARM:
On 3/4/20 12:45 PM, Rob Herring wrote:
> Well, not quite removed yet... Mauro is looking at moving this to ReST,
> but I think it would be better to trim or remove it.
>
> boot-without-of.txt is an ancient document that first outlined
> Flattened DeviceTree. The DT world has evolved a lot in the
https://bugzilla.kernel.org/show_bug.cgi?id=206695
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
(In reply to mpe from comment #3)
> Can you try this patch?
Applied your patch on top of 5.6-rc4 +
https://patchwork.ozlabs.org/patch/1248350/ and let the G5 do a few hours
compiling.
On 3/4/20 10:46 PM, Ravi Bangoria wrote:
> Hi Kim,
Hi Ravi,
> On 3/3/20 3:55 AM, Kim Phillips wrote:
>> On 3/2/20 2:21 PM, Stephane Eranian wrote:
>>> On Mon, Mar 2, 2020 at 2:13 AM Peter Zijlstra wrote:
On Mon, Mar 02, 2020 at 10:53:44AM +0530, Ravi Bangoria wrote:
> Modern
On Wed, 2020-03-04 at 10:57 +1100, Michael Ellerman wrote:
> We received a report of strange kernel faults which turned out to be
> due to a missing KUAP disable in flush_coherent_icache() called
> from flush_icache_range().
>
> The fault looks like:
>
> Kernel attempted to access user page
Le 05/03/2020 à 15:32, Qian Cai a écrit :
Booting a power9 server with hash MMU could trigger an undefined
behaviour because pud_offset(p4d, 0) will do,
0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
Fix it by converting pud_offset() and friends to static inline
functions.
Hello,
This seems to cause crash with kdump reservation 1GB quite reliably.
Thanks
Michal
On Tue, Feb 18, 2020 at 05:28:34PM +0100, Michal Suchanek wrote:
> From: Hari Bathini
>
> Sometimes, memory reservation for KDump/FADump can overlap with memory
> marked for hugepages. This overlap
On Thu, Mar 05, 2020 at 08:05:30PM +0530, Naveen N. Rao wrote:
> GCC v8 defaults to enabling -fasynchronous-unwind-tables due to
> https://gcc.gnu.org/r259298, which results in .eh_frame section being
> generated. This results in additional disk usage by the build, as well
> as the kernel modules.
On 3/5/20 4:15 PM, Ram Pai wrote:
> On Thu, Mar 05, 2020 at 10:55:45AM +1100, David Gibson wrote:
>> On Wed, Mar 04, 2020 at 04:56:09PM +0100, Cédric Le Goater wrote:
>>> [ ... ]
>>>
(1) applied the patch which shares the EQ-page with the hypervisor.
(2) set "kernel_irqchip=off"
(3)
On Thu, Mar 05, 2020 at 10:55:45AM +1100, David Gibson wrote:
> On Wed, Mar 04, 2020 at 04:56:09PM +0100, Cédric Le Goater wrote:
> > [ ... ]
> >
> > > (1) applied the patch which shares the EQ-page with the hypervisor.
> > > (2) set "kernel_irqchip=off"
> > > (3) set "ic-mode=xive"
> >
> > you
GCC v8 defaults to enabling -fasynchronous-unwind-tables due to
https://gcc.gnu.org/r259298, which results in .eh_frame section being
generated. This results in additional disk usage by the build, as well
as the kernel modules. Since the kernel has no use for this, this
section is discarded.
Add
The original commit/discussion adding -fno-dwarf2-cfi-asm refers to
R_PPC64_REL32 relocations not being handled by our module loader:
http://lkml.kernel.org/r/20090224065112.ga6...@bombadil.infradead.org
However, that is now handled thanks to commit 9f751b82b491d
("powerpc/module: Add support for
Booting a power9 server with hash MMU could trigger an undefined
behaviour because pud_offset(p4d, 0) will do,
0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
Fix it by converting pud_offset() and friends to static inline
functions.
UBSAN: shift-out-of-bounds in
Naveen N. Rao wrote:
Naveen N. Rao wrote:
Rasmus Villemoes wrote:
Can you check if the below patch works? I am yet to test this in more
detail, but would be good to know the implications for ppc32.
- Naveen
---
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index
Michael Ellerman wrote:
"Naveen N. Rao" writes:
Rasmus Villemoes wrote:
I'm building a ppc32 kernel, and noticed that after upgrading from gcc-7
to gcc-8 all object files now end up having .eh_frame section. For
vmlinux, that's not a problem, because they all get discarded in
https://bugzilla.kernel.org/show_bug.cgi?id=206695
--- Comment #3 from m...@ellerman.id.au ---
Can you try this patch?
diff --git a/drivers/macintosh/windfarm_pm112.c
b/drivers/macintosh/windfarm_pm112.c
index 4150301a89a5..a16f43a1def9 100644
--- a/drivers/macintosh/windfarm_pm112.c
+++
Can you try this patch?
diff --git a/drivers/macintosh/windfarm_pm112.c
b/drivers/macintosh/windfarm_pm112.c
index 4150301a89a5..a16f43a1def9 100644
--- a/drivers/macintosh/windfarm_pm112.c
+++ b/drivers/macintosh/windfarm_pm112.c
@@ -125,7 +125,7 @@ static int create_cpu_loop(int cpu)
{
On 3/5/20 7:50 AM, Anshuman Khandual wrote:
> There are many places where all basic VMA access flags (read, write, exec)
> are initialized or checked against as a group. One such example is during
> page fault. Existing vma_is_accessible() wrapper already creates the notion
> of VMA accessibility
[ ... ]
>> yes because you also need to share the XIVE TIMA and ESB pages mapped
>> in xive_native_esb_fault() and xive_native_tima_fault().
>
> These pages belong to the xive memory slot right? If that is the case,
> they are implicitly shared. The Ultravisor will set them up to be
> shared.
On Thu, Mar 05, 2020 at 01:34:22PM +1000, Nicholas Piggin wrote:
> Segher Boessenkool's on March 4, 2020 9:09 am:
> >> +override flavour := linux-ppc64v2
> >
> > That isn't a good name, heh. This isn't "v2" of anything... Spell out
> > the name "ELFv2"? Or as "elfv2"? It is just a name after
+ if (rc)
+ goto out;
+
+ rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
+ocxlpmem-
admin_command.data_offset + 0x28,
+OCXL_HOST_ENDIAN, >wwid[1]);
+ if (rc)
+ goto out;
+
On Thu, Mar 5, 2020 at 3:32 PM Michael Ellerman wrote:
>
> Po-Hsu Lin writes:
> > Some specific tests in powerpc can take longer than the default 45
> > seconds that added in commit 852c8cbf (selftests/kselftest/runner.sh:
> > Add 45 second timeout per test) to run, the following test result was
87 matches
Mail list logo
