ed in
sysfs_{create,remove}_group. So I agree that they can be constified.
They also pass all the automated tests:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20220210202805.7750-4-rikard.falkeb...@gmail.com/
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
>
> Signed-off-by
Hi Greg,
> Ok, this is like the 3rd or 4th different platform-specific proposal for
> this type of functionality. I think we need to give up on
> platform-specific user/kernel apis on this (random sysfs/securityfs
> files scattered around the tree), and come up with a standard place for
> all of
the patch itself makes sense to me and I can
follow how it would fix a problem.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
Hi Ganesh,
> In realmode mce handler we use irq_work_queue() to defer
> the processing of mce events, irq_work_queue() can only
> be called when translation is enabled because it touches
> memory outside RMA, hence we enable translation before
> calling irq_work_queue and disable on return, though
Hi,
> The printk layer at the moment does not seem to have a good way to force
> flush printk messages that are created in NMI context, except in the
> panic path.
>
> NMI-context printk messages normally get to the console with irq_work,
> but that won't help if the CPU is stuck with irqs disable
Michal Suchánek writes:
> On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote:
>> Michal Suchanek writes:
>>
>> > S390 uses appended signature for kernel but implements the check
>> > separately from module loader.
>> >
>> > Support
Michal Suchanek writes:
> S390 uses appended signature for kernel but implements the check
> separately from module loader.
>
> Support for secure boot on powerpc with appended signature is planned -
> grub patches submitted upstream but not yet merged.
Power Non-Virtualised / OpenPower already
Hi Nick,
> A e5500 machine running a 32-bit kernel sometimes hangs at boot,
> seemingly going into an infinite loop of instruction storage interrupts.
> The ESR SPR has a value of 0x80 (store) when this happens, which is
> likely set by a previous store. An instruction TLB miss interrupt would
Nathan Lynch writes:
> Daniel Axtens writes:
>>> On VMs with NX encryption, compression, and/or RNG offload, these
>>> capabilities are described by nodes in the ibm,platform-facilities device
>>> tree hierarchy:
>>>
>>> $ tree -d /sys/
Hi Nathan,
Thanks for the detailed explanation.
I've not really worked with the partition migration code before I was
able to follow your logic.
> On VMs with NX encryption, compression, and/or RNG offload, these
> capabilities are described by nodes in the ibm,platform-facilities device
> tree
er O'Halloran
[dja: rebase on top of linux-next + my preceeding refactor,
move clearing the EEH_DEV_NO_HANDLER bit above the first goto so that
it is always clear in the error handler code as it was before.]
Signed-off-by: Daniel Axtens
---
arch/powerpc/kernel/eeh_driver.c | 93
The control flow of eeh_handle_normal_event is a bit tricky.
Break out one of the error handling paths - rather than be in
an else block, we'll make it part of the regular body of the
function and put a 'goto out;' in the true limb of the if.
Signed-off-by: Daniel Axtens
--
Christophe Leroy writes:
> 'func_descr_t' is redundant with 'struct ppc64_opd_entry'
So, if I understand the overall direction of the series, you're
consolidating powerpc around one single type for function descriptors,
and then you're creating a generic typedef so that generic code can
always d
le.
I grepped the latest powerpc/next for uses of 'funcaddr'. There were 5,
your patch changes all 5.
The series passes build tests and this patch has no checkpatch or other
style concerns.
On that basis:
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
> Reviewed-by: Kees Cook
>
Christophe Leroy writes:
> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
> on those three architectures because LKDTM messes up function
> descriptors with functions.
Just to nitpick, it's powerpc 64-bit using the ELFv1 ABI. [1]
The ELFv2 ABI [2] doesn't use function descripto
Hi Christophe,
> 'struct ppc64_opd_entry' doesn't belong to uapi/asm/elf.h
>
> It was initially in module_64.c and commit 2d291e902791 ("Fix compile
> failure with non modular builds") moved it into asm/elf.h
>
> But it was by mistake added outside of __KERNEL__ section,
> therefore commit c3617f7
; *
This is OK.
> * The routine is called to reset the specified PE with the
> * indicated type, either fundamental reset or hot reset.
> @@ -1513,12 +1517,12 @@ EXPORT_SYMBOL_GPL(eeh_pe_configure);
> * eeh_pe_inject_err - Injecting the specified PCI error to the indicated PE
> * @pe: the indicated PE
> * @type: error type
> - * @function: error function
> + * @func: error function
This is good.
> * @addr: address
> * @mask: address mask
> *
> * The routine is called to inject the specified PCI error, which
> - * is determined by @type and @function, to the indicated PE for
> + * is determined by @type and @func, to the indicated PE for
This is good.
When you resend, you can include:
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
> #ifdef __KERNEL__
> +/*
> + * Check if an address is part of freed initmem. After initmem is freed,
> + * memory can be allocated from it, and such allocations would then have
> + * addresses within the range [_stext, _end].
> + */
> +#ifndef arch_is_kernel_initmem_freed
> +static int arch_is_ke
initially confused about why SIAR was outside the CONFIG_PPC64
block and SDAR was inside. But it turns out that SIAR is also defined
for a 32 bit platform, so that makes sense.
I'm not an expert on how the perf subsystem works, but this all seems
consistent with the surrounding code and it se
Hi Athira,
> PERF_REG_PMU_MASK_300 and PERF_REG_PMU_MASK_31 defines the mask
> value for extended registers. Current definition of these mask values
> uses hex constant and does not use registers by name, making it less
> readable. Patch refactor the macro values in perf tools side header file
> b
Hi Vasant,
> Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
> opal notifier. But I missed to unregister the notifier during module unload
> path. This results in below call trace if you try to unload and load
> opal_prd module.
>
> Fixes: 587164cd ("powerpc/powernv: Ad
Hi Kai,
Thank you for your contribution to the powerpc kernel!
> Get rid of warning:
> arch/powerpc/kernel/eeh.c:774: warning: expecting prototype for
> eeh_set_pe_freset(). Prototype was for eeh_set_dev_freset() instead
You haven't said where this warning is from. I thought it might be from
sp
e module loader?) patches the callsite to
restore r2 after the function call? I imagine something must otherwise
things would fall apart pretty quickly...
> Fixes: c1fe190c0672 ("powerpc: Add force enable of DAWR on P9 option")
That patch seems to only affect the DA_W_R not the DA_B_R
Nicholas Piggin writes:
> The rfscv instruction does not work correctly with the fake-suspend mode
> in POWER9, which can end up with the hypervisor restoring an incorrect
> checkpoint.
If I understand correctly from commit 4bb3c7a0208f ("KVM: PPC: Book3S
HV: Work around transactional memory bug
Hi Ganesh,
> We queue an irq work for deferred processing of mce event
> in realmode mce handler, where translation is disabled.
> Queuing of the work may result in accessing memory outside
> RMO region, such access needs the translation to be enabled
> for an LPAR running with hash mmu else the k
, and simplifies the code.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
kexec_prepare()
I think you should also remove the prototype from
arch/powerpc/include/asm/kexec.h
Apart from that:
Reviewed-by: Daniel Axtens
Kind regards,
Daniel Axtens
commit 6d7f58b04d82 ("[PATCH] powerpc: Some minor cleanups to setup_32.c")
removed of_show_percpuinfo but didn't remove the prototype.
Remove it.
Fixes: 6d7f58b04d82 ("[PATCH] powerpc: Some minor cleanups to setup_32.c")
Signed-off-by: Daniel Axtens
---
arch/powerpc/
Christophe Leroy writes:
> Le 31/08/2021 à 08:17, Daniel Axtens a écrit :
>> Hi Christophe,
>>
>>> Use bcl 20,31,+4 instead of bl in order to preserve link stack.
>>>
>>> See commit c974809a26a1 ("powerpc/vdso: Avoid link stack corruption
>>
Hi Christophe,
> Use bcl 20,31,+4 instead of bl in order to preserve link stack.
>
> See commit c974809a26a1 ("powerpc/vdso: Avoid link stack corruption
> in __get_datapage()") for details.
>From my understanding of that commit message, the change helps to keep
the link stack correctly balanced w
Hi Jing,
Thanks for your patch.
The patch looks good, but looking at the output of `make coccicheck
M=arch/powerpc MODE=report`, it looks like there might be a few other
things that we might want to fix. Would it be worth trying to make the
arch/powerpc directory free from coccinelle warnings in
Hi,
> Similarly to the system call change in the previous patch, the mtmsrd to
I don't actually know what patch this was - I assume it's from a series
that has since been applied?
> enable RI can be combined with the mtmsrd to enable EE for interrupts
> which enable the latter, which tends to be
Xianting Tian writes:
> As well known, hvc backend driver(eg, virtio-console) can register its
> operations to hvc framework. The operations can contain put_chars(),
> get_chars() and so on.
>
> Some hvc backend may do dma in its operations. eg, put_chars() of
> virtio-console. But in the code of
built a
pseries_le_defconfig and boot tested it in qemu. It didn't crash on
boot or with /bin/sh and some shell commands, but I didn't exactly
stress test the VM subsystem either.
This gives me some confidence it's both good for powerpc and stable-worthy.
Overall:
Reviewed
elected anyway by virtue of PPC64->PPC_DAWR so there's no need to try
to select it again anyway.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
>
> config KVM_BOOK3S_PR_POSSIBLE
> bool
> --
> 2.26.2
Jan Stancek writes:
> gcov and kasan rely on compiler generated constructor code.
> For modules, gcc-8 with gcov enabled generates .init_array section,
> but on ppc64le it doesn't get executed. find_module_sections() never
> finds .init_array section, because module_frob_arch_sections() renames
>
Bill Wendling writes:
> The "-z notext" flag disables reporting an error if DT_TEXTREL is set on
> PPC with CONFIG=kdump:
>
> ld.lld: error: can't create dynamic relocation R_PPC64_ADDR64 against
> local symbol in readonly segment; recompile object files with -fPIC
> or pass '-Wl,-z,not
ion rules would do with a the
nr_pages > tlb*flush_ceiling comparisons, but if we are trying to flush
more than 4 billion pages we might have other, bigger problems! (Also,
if I understand the C integer rules correctly the u32 will get promoted
to an unsigned long anyway.)
All in all this seems good to me.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
> +
> --
> 2.31.1
: Balbir Singh
Reviewed-by: Christophe Leroy
Reviewed-by: Balbir Singh
Reviewed-by: Marco Elver
Reviewed-by: Andrey Konovalov
Signed-off-by: Daniel Axtens
---
include/linux/kasan.h | 6 +++---
mm/kasan/init.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include
an architecture has defined MAX_PTRS_PER_x in its arch headers.
Clean up pgtable-nop4d.h and s390's MAX_PTRS_PER_P4D definitions while
we're at it: both can just pick up the default now.
Acked-by: Andrey Konovalov
Reviewed-by: Christophe Leroy
Reviewed-by: Marco Elver
Signed-off-by:
rk in outline mode, so an arch must specify
ARCH_DISABLE_KASAN_INLINE if it requires this.
Cc: Balbir Singh
Cc: Aneesh Kumar K.V
Suggested-by: Christophe Leroy
Reviewed-by: Marco Elver
Signed-off-by: Daniel Axtens
--
Both previous RFCs for ppc64 - by 2 different people - have
needed this trick
hadow region, which we won't have
set up yet, and would crash. We can make outline mode wait for the arch to
be ready, but we can't change what the compiler inserts for inline mode.
Reviewed-by: Marco Elver
Signed-off-by: Daniel Axtens
---
lib/Kconfig.kasan | 12
1 fil
SAN_INLINE, and add an arch readiness check to
the new granule poisioning function. Thanks Marco.
Daniel Axtens (4):
kasan: allow an architecture to disable inline instrumentation
kasan: allow architectures to provide an outline readiness check
mm: define default MAX_PTRS_PER_* in include/pg
Michael Ellerman writes:
> Daniel Axtens writes:
>> Hi Christophe,
>>
>> This breaks booting a radix KVM guest with 4k pages for me:
>>
>> make pseries_le_defconfig
>> scripts/config -d CONFIG_PPC_64K_PAGES
>> scripts/config -e CONFIG_PPC_4K_PA
Hi Christophe,
This breaks booting a radix KVM guest with 4k pages for me:
make pseries_le_defconfig
scripts/config -d CONFIG_PPC_64K_PAGES
scripts/config -e CONFIG_PPC_4K_PAGES
make vmlinux
sudo qemu-system-ppc64 -enable-kvm -M pseries -m 1G -nographic -vga none -smp 4
-cpu host -kernel vmlinux
>> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
>> index 10177cc26d06..0ad615f3801d 100644
>> --- a/mm/kasan/common.c
>> +++ b/mm/kasan/common.c
>> @@ -331,6 +331,10 @@ static inline bool kasan_slab_free(struct
>> kmem_cache *cache, void *object,
>> u8 tag;
>> void *tagge
ssert(prom_strscpy_pad(longstr, "", 0) == -E2BIG);
assert(prom_strscpy_pad(longstr, "hello", 255) == 5);
assert(prom_strscpy_pad(shortstr, "hello", 5) == -E2BIG);
assert(memcmp(shortstr, "hell", 5) == 0);
assert(memcmp(longst
Hi Chris,
> + /*
> + * Choose a randomized, page-aligned address from the range:
> + * [PAGE_SIZE, DEFAULT_MAP_WINDOW - PAGE_SIZE]
> + * The lower address bound is PAGE_SIZE to avoid the zero-page.
> + * The upper address bound is DEFAULT_MAP_WINDOW - PAGE_SIZE to stay
> +
"Christopher M. Riedl" writes:
> Switching to a different mm with Hash translation causes SLB entries to
> be preloaded from the current thread_info. This reduces SLB faults, for
> example when threads share a common mm but operate on different address
> ranges.
>
> Preloading entries from the th
Daniel Axtens writes:
>> +#ifdef CONFIG_PPC64
>> +static inline bool kfence_protect_page(unsigned long addr, bool protect)
>> +{
>> +struct page *page;
>> +
>> +page = virt_to_page(addr);
>> +if (protect)
>> +
> +#ifdef CONFIG_PPC64
> +static inline bool kfence_protect_page(unsigned long addr, bool protect)
> +{
> + struct page *page;
> +
> + page = virt_to_page(addr);
> + if (protect)
> + __kernel_map_pages(page, 1, 0);
> + else
> + __kernel_map_pages(page, 1, 1
Hi Jordan and Christophe,
> --- a/arch/powerpc/mm/book3s64/hash_utils.c
> +++ b/arch/powerpc/mm/book3s64/hash_utils.c
> @@ -126,11 +126,8 @@ EXPORT_SYMBOL_GPL(mmu_slb_size);
> #ifdef CONFIG_PPC_64K_PAGES
> int mmu_ci_restrictions;
> #endif
> -#ifdef CONFIG_DEBUG_PAGEALLOC
> static u8 *linear_m
Jordan Niethe writes:
> There is support for DEBUG_PAGEALLOC on hash but not on radix.
> Add support on radix.
Somewhat off-topic but I wonder at what point we can drop the weird !PPC
condition in mm/Kconfig.debug:
config DEBUG_PAGEALLOC
bool "Debug page memory allocations"
depe
: Balbir Singh
Reviewed-by: Christophe Leroy
Reviewed-by: Balbir Singh
Reviewed-by: Marco Elver
Signed-off-by: Daniel Axtens
---
include/linux/kasan.h | 6 +++---
mm/kasan/init.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux
an architecture has defined MAX_PTRS_PER_x in its arch headers.
Clean up pgtable-nop4d.h and s390's MAX_PTRS_PER_P4D definitions while
we're at it: both can just pick up the default now.
Reviewed-by: Christophe Leroy
Reviewed-by: Marco Elver
Signed-off-by: Daniel Axtens
---
s390 was
rk in outline mode, so an arch must specify
ARCH_DISABLE_KASAN_INLINE if it requires this.
Cc: Balbir Singh
Cc: Aneesh Kumar K.V
Suggested-by: Christophe Leroy
Reviewed-by: Marco Elver
Signed-off-by: Daniel Axtens
--
Both previous RFCs for ppc64 - by 2 different people - have
needed this trick
hadow region, which we won't have
set up yet, and would crash. We can make outline mode wait for the arch to
be ready, but we can't change what the compiler inserts for inline mode.
Reviewed-by: Marco Elver
Signed-off-by: Daniel Axtens
---
lib/Kconfig.kasan | 14 ++
1 fil
ioning function. Thanks Marco.
Daniel Axtens (4):
kasan: allow an architecture to disable inline instrumentation
kasan: allow architectures to provide an outline readiness check
mm: define default MAX_PTRS_PER_* in include/pgtable.h
kasan: use MAX_PTRS_PER_* for early shadow tables
arch/s
: Balbir Singh
Reviewed-by: Christophe Leroy
Reviewed-by: Balbir Singh
Signed-off-by: Daniel Axtens
---
include/linux/kasan.h | 6 +++---
mm/kasan/init.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 768d7d342757
an architecture has defined MAX_PTRS_PER_x in its arch headers.
Clean up pgtable-nop4d.h and s390's MAX_PTRS_PER_P4D definitions while
we're at it: both can just pick up the default now.
Signed-off-by: Daniel Axtens
---
s390 was compile tested only.
---
arch/s390/include/asm/pgta
rk in outline mode, so an arch must specify
ARCH_DISABLE_KASAN_INLINE if it requires this.
Cc: Balbir Singh
Cc: Aneesh Kumar K.V
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
--
Both previous RFCs for ppc64 - by 2 different people - have
needed this trick! See:
- https://lore.kerne
hadow region, which we won't have
set up yet, and would crash. We can make outline mode wait for the arch to
be ready, but we can't change what the compiler inserts for inline mode.
Signed-off-by: Daniel Axtens
---
lib/Kconfig.kasan | 14 ++
1 file changed, 14 insert
since v12: respond to Marco's review comments - clean up the
help for ARCH_DISABLE_KASAN_INLINE, and add an arch readiness check to
the new granule poisioning function. Thanks Marco.
Daniel Axtens (4):
kasan: allow an architecture to disable inline instrumentation
kasan: allow architecture
moment, just define them in the kasan
header, and have them default to PTRS_PER_* unless overridden in arch
code.
Suggested-by: Christophe Leroy
Suggested-by: Balbir Singh
Reviewed-by: Christophe Leroy
Reviewed-by: Balbir Singh
Signed-off-by: Daniel Axtens
---
include/linux/kasan.h | 18
rk in outline mode, so an arch must specify
ARCH_DISABLE_KASAN_INLINE if it requires this.
Cc: Balbir Singh
Cc: Aneesh Kumar K.V
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
--
I discuss the justfication for this later in the series. Also,
both previous RFCs for ppc64 - by 2 diff
hadow region, which we won't have
set up yet, and would crash. We can make outline mode wait for the arch to
be ready, but we can't change what the compiler inserts for inline mode.
Signed-off-by: Daniel Axtens
---
lib/Kconfig.kasan | 14 ++
1 file changed, 14 insert
applies to next-20210611. There should be no noticeable changes to
other platforms.
Changes since v12: respond to Marco's review comments - clean up the
help for ARCH_DISABLE_KASAN_INLINE, and add an arch readiness check to
the new granule poisioning function. Thanks Marco.
Kind regards,
Daniel
Hi Marco,
>> + /* Don't touch the shadow memory if arch isn't ready */
>> + if (!kasan_arch_is_ready())
>> + return;
>> +
>
> What about kasan_poison_last_granule()? kasan_unpoison() currently
> seems to potentially trip on that.
Ah the perils of rebasing an old series! I
Hi Marco,
@@ -12,6 +12,15 @@ config HAVE_ARCH_KASAN_HW_TAGS
>> config HAVE_ARCH_KASAN_VMALLOC
>> bool
>>
>> +# Sometimes an architecture might not be able to support inline
>> instrumentation
>> +# but might be able to support outline instrumentation. This option allows
>> an
>> +# arch
y could be
used and it had to be specified at compile time. Maybe we can do better in
the future.
Cc: Aneesh Kumar K.V # ppc64 hash version
Cc: Christophe Leroy # ppc32 version
Originally-by: Balbir Singh # ppc64 out-of-line radix
version
Signed-off-by: Daniel Axtens
---
Documentation/dev-tools
kasan is already implied by the directory name, we don't need to
repeat it.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
arch/powerpc/mm/kasan/Makefile | 2 +-
arch/powerpc/mm/kasan/{kasan_init_32.c => init_32.c} | 0
2 files changed, 1 inserti
KASAN is supported on 32-bit powerpc and the docs should reflect this.
Suggested-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
Documentation/dev-tools/kasan.rst | 8 ++--
Documentation/powerpc/kasan.txt | 12
2 files changed, 18
moment, just define them in the kasan
header, and have them default to PTRS_PER_* unless overridden in arch
code.
Suggested-by: Christophe Leroy
Suggested-by: Balbir Singh
Reviewed-by: Christophe Leroy
Reviewed-by: Balbir Singh
Signed-off-by: Daniel Axtens
---
include/linux/kasan.h | 18
rk in outline mode, so an arch must specify
ARCH_DISABLE_KASAN_INLINE if it requires this.
Cc: Balbir Singh
Cc: Aneesh Kumar K.V
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
--
I discuss the justfication for this later in the series. Also,
both previous RFCs for ppc64 - by 2 diff
n', rather than 'y'.)
We also disable stack instrumentation in this case as it does things that
are functionally equivalent to inline instrumentation, namely adding
code that touches the shadow directly without going through a C helper.
Signed-off-by: Daniel Axtens
---
lib/Kconfig.
noticable changes to
other platforms.
Kind regards,
Daniel
Daniel Axtens (6):
kasan: allow an architecture to disable inline instrumentation
kasan: allow architectures to provide an outline readiness check
kasan: define and use MAX_PTRS_PER_* for early shadow tables
kasan: Document support
Hi Michael,
> The fix is simply to make the key value relative to the jump_entry
> struct in the ARCH_STATIC_BRANCH macro.
This fixes the boot issues I observed. Thank you very much!!
Tested-by: Daniel Axtens
Kind regards,
Daniel
"), commit 91e08ab0c851 ("x86/dumpstack:
Prevent KASAN false positive warnings") and commit 6e22c8366416
("tracing, kasan: Silence Kasan warning in check_stack of stack_tracer").
Cc: Naveen N. Rao
Signed-off-by: Daniel Axtens
---
v2: Use __no_sanitize_address, thanks
"Naveen N. Rao" writes:
> Daniel Axtens wrote:
>> Make our stack-walking code KASAN-safe by using READ_ONCE_NOCHECK -
>> generic code, arm64, s390 and x86 all do this for similar sorts of
>> reasons: when unwinding a stack, we might touch memory that KASAN has
&
91e08ab0c851 ("x86/dumpstack:
Prevent KASAN false positive warnings") and commit 6e22c8366416
("tracing, kasan: Silence Kasan warning in check_stack of stack_tracer").
Signed-off-by: Daniel Axtens
---
arch/powerpc/kernel/process.c | 16 +---
1 file changed, 9 insertio
Segher Boessenkool writes:
> Hi!
>
> On Fri, Apr 16, 2021 at 05:44:52PM +1000, Daniel Axtens wrote:
>> Sathvika Vasireddy writes:
>> Ok, if I've understood correctly...
>>
>> > + ra = ra & ~0x3;
>>
>> This masks off th
Hi Nick,
> While looking at -Wundef warnings, the #if CONFIG_EEH stood out as a
> possible candidate to convert to #ifdef CONFIG_EEH, but it seems that
> based on Kconfig dependencies it's not possible to build this file
> without CONFIG_EEH enabled.
This seemed odd to me, but I think you're righ
ent it
off to a fork of mpe's linux-ci repo to see if any of those builds hit
any issues: https://github.com/daxtens/linux-ci/actions
Assuming that doesn't break, this patch looks good to me:
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
Daniel Axtens writes:
> Hi Lakshmi,
>
>> On 4/15/21 12:14 PM, Lakshmi Ramasubramanian wrote:
>>
>> Sorry - missed copying device-tree and powerpc mailing lists.
>>
>>> There are a few "goto out;" statements before the local vari
a bit clearer. I think it works because a left shift of 2 is
the same as multiplying by 4, but it would be easier to follow if you
used a temporary variable for btf.
However, I do think this is still worth adding to the kernel either way,
so:
Reviewed-by: Daniel Axtens
Kind regards,
Dan
Hi Tyrel,
> The pci_bus->bridge reference may no longer be valid after
> pci_bus_remove() resulting in passing a bad value to device_unregister()
> for the associated bridge device.
>
> Store the host_bridge reference in a separate variable prior to
> pci_bus_remove().
>
The patch certainly seems
27;s no obvious macros in that file that might construct the name
of the function in a way that is hidden from grep.
All in all, I am fairly confident that the function is indeed not used.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
> -
> static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
> {
> return irq_data_get_irq_chip_data(d);
> --
> 1.8.3.1
Hi Lakshmi,
> On 4/15/21 12:14 PM, Lakshmi Ramasubramanian wrote:
>
> Sorry - missed copying device-tree and powerpc mailing lists.
>
>> There are a few "goto out;" statements before the local variable "fdt"
>> is initialized through the call to of_kexec_alloc_and_setup_fdt() in
>> elf64_load(). T
Hi,
Thanks for your contribution to the kernel!
I notice that your patch is sumbitted as an attachment. In future,
please could you submit your patch inline, rather than as an attachment?
See https://www.kernel.org/doc/html/v4.15/process/5.Posting.html
I'd recommend you use git send-email if poss
Hi Christophe,
> Which hugepd, page table entries can be at any level
> and can be of any size.
>
> Add support for them.
>
> Signed-off-by: Christophe Leroy
> ---
> mm/ptdump.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/mm/ptdump.c b/mm/ptdump.c
Hi Christophe,
> static void note_page(struct ptdump_state *pt_st, unsigned long addr, int
> level,
> - u64 val)
> + u64 val, unsigned long page_size)
Compilers can warn about unused parameters at -Wextra level. However,
reading scripts/Makefile.extrawarn it
Hi Christophe,
> Pagewalk ignores hugepd entries and walk down the tables
> as if it was traditionnal entries, leading to crazy result.
>
> Add walk_hugepd_range() and use it to walk hugepage tables.
>
> Signed-off-by: Christophe Leroy
> ---
> mm/pagewalk.c | 54 +
Hi Ravi,
> perf-hwbreak selftest opens hw-breakpoint event at multiple places for
> which it has same code repeated. Coalesce that code into a function.
>
> Signed-off-by: Ravi Bangoria
> ---
> .../selftests/powerpc/ptrace/perf-hwbreak.c | 78 +--
This doesn't simplify things v
, I don't have any specific comments about this patch. It
looks good to me, it seems to do what it says, and there are no comments
from checkpatch. It is a bit sparse in terms of comments but it is
consistent with the rest of the file so I can't really complain there :)
Reviewed-by: Daniel
Daniel Axtens writes:
It looks like the kernel test robot also reported this:
"[PATCH] powerpc/iommu/debug: fix ifnullfree.cocci warnings"
Weirdly I don't see it in patchwork.
I'm not sure which one mpe will want to take but either would do.
>> Fix the following cocci
omment
> format, i.e. '/*', to prevent kernel-doc from parsing it.
This makes sense.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
>
> Signed-off-by: Aditya Srivastava
> ---
> * Applies perfectly on next-20210319
>
> drivers/crypto/vmx/aes.c | 2 +-
>
f you have a number of similar fixes it might be helpful to do them in
a single bigger patch, but I'm not sure if coccicheck reports much else
as I don't have coccinelle installed at the moment.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
at line 19, so remove the
> duplicate one at line 23.
For this one I checked the file. Indeed there is another inttypes.h, so
this is also correct.
Again, all the automated checks pass. (although I don't think any of the
automated builds include selftests.)
So:
Reviewed-by: Daniel Axtens
ate between hugetlb and THP during page
walk"). How odd!
Anyway, all of these look good to me, and the automated checks at
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210323062916.295346-1-wanjiab...@vivo.com/
have all passed.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
Hi Daniel,
Two small nitpicks:
> This patch adds a 'last online' check in dlpar_cpu_offline() to catch
> the 'last online CPU' offline error, eturning a more informative error
^--- s/eturning/returning/;
> + /* device_offline() will ret
1 - 100 of 941 matches
Mail list logo
