Re: [PATCH v4 23/26] RFC: KVM: powerpc: Move processor compatibility check to hardware setup
On Fri, Sep 09, 2022 at 05:55:14AM +,
Christophe Leroy wrote:
>
>
> Le 09/09/2022 à 01:25, isaku.yamah...@intel.com a écrit :
> > [Vous ne recevez pas souvent de courriers de isaku.yamah...@intel.com.
> > Découvrez pourquoi ceci est important à
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > From: Isaku Yamahata
> >
> > Move processor compatibility check from kvm_arch_processor_compat() into
> > kvm_arch_hardware_setup(). The check does model name comparison with a
> > global variable, cur_cpu_spec. There is no point to check it at run time
> > on all processors.
> >
> > Suggested-by: Sean Christopherson
> > Signed-off-by: Isaku Yamahata
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: Fabiano Rosas
> > ---
> > arch/powerpc/kvm/powerpc.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> > index 7b56d6ccfdfb..7e3a6659f107 100644
> > --- a/arch/powerpc/kvm/powerpc.c
> > +++ b/arch/powerpc/kvm/powerpc.c
> > @@ -444,12 +444,21 @@ int kvm_arch_hardware_enable(void)
> >
> > int kvm_arch_hardware_setup(void *opaque)
> > {
> > - return 0;
> > + /*
> > +* kvmppc_core_check_processor_compat() checks the global variable.
> > +* No point to check on all processors or at runtime.
> > +* arch/powerpc/kvm/book3s.c: return 0
> > +* arch/powerpc/kvm/e500.c: strcmp(cur_cpu_spec->cpu_name, "e500v2")
> > +* arch/powerpc/kvm/e500mc.c: strcmp(cur_cpu_spec->cpu_name,
> > "e500mc")
> > +*strcmp(cur_cpu_spec->cpu_name,
> > "e5500")
> > +*strcmp(cur_cpu_spec->cpu_name,
> > "e6500")
> > +*/
>
> This explanation shouldn't be in the code. The content of other file may
> change in the future, the files may be renamed or deleted, new files may
> be added. And there is no added value with that comment.
>
> That detailed explanation should go in the commit message.
Ok, will move the comment into the commit message.
--
Isaku Yamahata
[powerpc:next-test] BUILD SUCCESS 71a92e99c47900cc164620948b3863382cec4f1a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: 71a92e99c47900cc164620948b3863382cec4f1a powerpc/powernv: add missing of_node_put() in opal_export_attrs() elapsed time: 875m configs tested: 100 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: um i386_defconfig um x86_64_defconfig x86_64 defconfig x86_64 rhel-8.3 m68k allmodconfig powerpc allnoconfig powerpc allmodconfig arc allyesconfig mips allyesconfig x86_64 allyesconfig alphaallyesconfig m68k allyesconfig sh allmodconfig arc randconfig-r043-20220907 i386defconfig x86_64 rhel-8.3-func x86_64 rhel-8.3-kunit x86_64rhel-8.3-kselftests x86_64randconfig-a013 x86_64 rhel-8.3-kvm x86_64randconfig-a011 x86_64 rhel-8.3-syz x86_64randconfig-a015 i386 randconfig-a001 x86_64randconfig-a004 i386 randconfig-a003 x86_64randconfig-a002 arm defconfig x86_64randconfig-a006 i386 randconfig-a005 arm64allyesconfig arm allyesconfig i386 randconfig-a014 i386 randconfig-a012 i386 randconfig-a016 i386 allyesconfig sh espt_defconfig riscv nommu_k210_sdcard_defconfig armmps2_defconfig csky allnoconfig alpha allnoconfig arc allnoconfig riscv allnoconfig powerpc ppc40x_defconfig arm axm55xx_defconfig mips db1xxx_defconfig armzeus_defconfig parisc defconfig sh sh7710voipgw_defconfig armkeystone_defconfig x86_64 alldefconfig xtensaxip_kc705_defconfig mipsmaltaup_xpa_defconfig mips maltasmvp_defconfig i386 randconfig-c001 m68km5407c3_defconfig nios2 3c120_defconfig loongarch defconfig loongarch allnoconfig arm cm_x300_defconfig powerpcklondike_defconfig arm badge4_defconfig mips fuloong2e_defconfig s390 zfcpdump_defconfig mipsbcm47xx_defconfig armpleb_defconfig riscv defconfig nios2 10m50_defconfig powerpc mpc837x_rdb_defconfig arc alldefconfig sh ul2_defconfig arm sunxi_defconfig arm exynos_defconfig sh secureedge5410_defconfig arm lubbock_defconfig sh rsk7264_defconfig ia64 allmodconfig clang tested configs: hexagon randconfig-r041-20220907 s390 randconfig-r044-20220907 hexagon randconfig-r045-20220907 riscvrandconfig-r042-20220907 x86_64randconfig-a012 x86_64randconfig-a016 x86_64randconfig-a014 x86_64randconfig-a001 i386 randconfig-a004 i386 randconfig-a002 x86_64randconfig-a003 x86_64randconfig-a005 i386 randconfig-a006 i386 randconfig-a013 i386 randconfig-a011 i386 randconfig-a015 riscvrandconfig-r042-20220909 hexagon randconfig-r041-20220909 hexagon randconfig-r045-20220909 s390 randconfig-r044-20220909 x86_64randconfig-k001 hexagon randconfig-r041-20220908 hexagon
[powerpc:next] BUILD SUCCESS 78c73c80fd860d5b3471d8eaa2778a105a56f6ab
randconfig-a001 hexagon randconfig-r041-20220908 hexagon randconfig-r045-20220908 x86_64randconfig-a003 riscvrandconfig-r042-20220909 hexagon randconfig-r041-20220909 hexagon randconfig-r045-20220909 s390 randconfig-r044-20220909 x86_64randconfig-k001 powerpc allmodconfig powerpc tqm8540_defconfig powerpc ppc44x_defconfig riscvrandconfig-r042-20220907 hexagon randconfig-r041-20220907 hexagon randconfig-r045-20220907 s390 randconfig-r044-20220907 -- 0-DAY CI Kernel Test Service https://01.org/lkp
[powerpc:fixes-test] BUILD SUCCESS a66de5283e16602b74658289360505ceeb308c90
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test branch HEAD: a66de5283e16602b74658289360505ceeb308c90 powerpc/pseries: Fix plpks crash on non-pseries elapsed time: 723m configs tested: 105 configs skipped: 115 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: powerpc allnoconfig powerpc allmodconfig um x86_64_defconfig um i386_defconfig i386 allyesconfig i386defconfig x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 mips allyesconfig sh allmodconfig m68k allyesconfig m68k allmodconfig alphaallyesconfig x86_64 rhel-8.3-kvm x86_64 rhel-8.3-func x86_64 rhel-8.3-syz x86_64rhel-8.3-kselftests x86_64 rhel-8.3-kunit i386 randconfig-a012 i386 randconfig-a014 arcvdk_hs38_smp_defconfig sh microdev_defconfig m68k m5475evb_defconfig powerpc mpc834x_itx_defconfig powerpc tqm8548_defconfig x86_64randconfig-a006 csky allnoconfig arm64allyesconfig arm allyesconfig loongarch defconfig x86_64randconfig-a004 x86_64randconfig-a013 x86_64randconfig-a015 arc allyesconfig sh shx3_defconfig xtensa defconfig s390 zfcpdump_defconfig mipsbcm47xx_defconfig riscv defconfig nios2 10m50_defconfig powerpc mpc837x_rdb_defconfig arm sunxi_defconfig shdreamcast_defconfig armzeus_defconfig riscvrandconfig-r042-20220908 arc randconfig-r043-20220907 arc randconfig-r043-20220908 s390 randconfig-r044-20220908 arm defconfig shsh7763rdp_defconfig xtensa allyesconfig powerpc tqm8541_defconfig powerpc holly_defconfig i386 randconfig-a016 x86_64randconfig-a002 sh espt_defconfig riscv nommu_k210_sdcard_defconfig armmps2_defconfig alpha allnoconfig arc allnoconfig riscv allnoconfig armclps711x_defconfig sh ecovec24_defconfig riscvallmodconfig powerpc ppc40x_defconfig arm axm55xx_defconfig mips db1xxx_defconfig parisc defconfig sh sh7710voipgw_defconfig armkeystone_defconfig x86_64 alldefconfig xtensaxip_kc705_defconfig mipsmaltaup_xpa_defconfig mips maltasmvp_defconfig i386 randconfig-c001 x86_64randconfig-a011 m68km5407c3_defconfig nios2 3c120_defconfig loongarch allnoconfig arm cm_x300_defconfig powerpcklondike_defconfig arm badge4_defconfig clang tested configs: riscvrandconfig-r042-20220909 hexagon randconfig-r041-20220909 hexagon randconfig-r045-20220909 s390 randconfig-r044-20220909 i386 randconfig-a002 i386 randconfig-a006 i386 randconfig-a004 powerpc allmodconfig powerpc tqm8540_defconfig powerpc ppc44x_defconfig x86_64randconfig-a012 x86_64randconfig-a014 x86_64randconfig-a016 riscvrandconfig-r042-20220907 hexagon randconfig-r041-20220907 hexagon randconfig-r045-20220907 s390 randconfig-r044
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-6.0-5 tag
The pull request you sent on Fri, 09 Sep 2022 22:36:24 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-6.0-5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2fc1171d34deff70bf3a8338adab8ce46138aae3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn}
Hi,
Here's a preview of what I'm planning to discuss at the LPC toolchains
microconference. Feel free to start the discussion early :-)
This is a proposal for some new minor GCC/Clang features which would
help objtool greatly.
Background
--
Objtool is a kernel-specific tool which reverse engineers the control
flow graph (CFG) of compiled objects. It then performs various
validations, annotations, and modifications, mostly with the goal of
improving robustness and security of the kernel.
Objtool features which use the CFG include include:
validation/generation of unwinding metadata; validation of Intel SMAP
rules; and validation of kernel "noinstr" rules (preventing compiler
instrumentation in certain critical sections).
In general it's not feasible for the traditional toolchain to do any of
this work, because the kernel has a lot of "blind spots" which the
toolchain doesn't have visibility to, notably asm and inline asm.
Manual .cfi annotations are very difficult to maintain and even more
difficult to ensure correctness. Also, due to kernel live patching, the
kernel relies on 100% correctness of unwinding metadata, whereas the
toolchain treats it as a best effort.
Challenges
--
Reverse engineering the control flow graph is mostly quite
straightforward, with two notable exceptions:
1) Jump tables (e.g., switch statements):
Depending on the architecture, it's somewhere between difficult and
impossible to reliabily identify which indirect jumps correspond to
jump tables, and what are their corresponding intra-function jump
destinations.
2) Noreturn functions:
There's no reliable way to determine which functions are designated
by the compiler to be noreturn (either explictly via function
attribute, or implicitly via a static function which is a wrapper
around a noreturn function.) This information is needed because the
code after the call to such a function is optimized out as
unreachable and objtool has no way of knowing that.
Proposal
Add the following new compiler flags which create non-allocatable ELF
sections which "annotate" control flow:
(Note this is purely hypothetical, intended for starting a discussion.
I'm not a compiler person and I haven't written any compiler code.)
1) -fannotate-jump-table
Create an .annotate.jump_table section which is an array of the
following variable-length structure:
struct annotate_jump_table {
void *indirect_jmp;
long num_targets;
void *targets[];
};
For example, given the following switch statement code:
.Lswitch_jmp:
// %rax is .Lcase_1 or .Lcase_2
jmp %rax
.Lcase_1:
...
.Lcase_2:
...
Add the following code:
.pushsection .annotate.jump_table
// indirect JMP address
.quad .Lswitch_jmp
// num jump targets
.quad 2
// indirect JMP target addresses
.quad .Lcase_1
.quad .Lcase_2
.popsection
2) -fannotate-noreturn
Create an .annotate.noreturn section which is an array of pointers to
noreturn functions (both explicit/implicit and defined/undefined).
For example, given the following three noreturn functions:
// explicit noreturn:
__attribute__((__noreturn__)) void func1(void)
{
exit(1);
}
// explicit noreturn (extern):
extern __attribute__((__noreturn__)) void func2(void);
// implicit noreturn:
static void func3(void)
{
// call noreturn function
func2();
}
Add the following code:
.pushsection .annotate.noreturn
.quad func1
.quad func2
.quad func3
.popsection
Alternatives
Another idea which has been floated in the past is for objtool to read
DWARF (or .eh_frame) to help it figure out the control flow. That
hasn't been tried yet, but would be considerably more difficult and
fragile IMO.
--
Josh
[PATCH] ppc64/kdump: Limit kdump base to 512MB
Since commit e641eb03ab2b0 ("powerpc: Fix up the kdump base cap to
128M") memory for kdump kernel has been reserved at an offset of
128MB. This held up well for a long time before running into boot
failure on LPARs having a lot of cores. Commit 7c5ed82b800d8
("powerpc: Set crashkernel offset to mid of RMA region") fixed this
boot failure by moving the offset to mid of RMA region. Limit this
offset to 512MB to avoid running into boot failures, during kdump
kernel boot, due RTAS or other allocation restrictions.
Signed-off-by: Hari Bathini
---
arch/powerpc/kexec/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
index cf84bfe9e27e..c2cbfcf81cea 100644
--- a/arch/powerpc/kexec/core.c
+++ b/arch/powerpc/kexec/core.c
@@ -136,7 +136,7 @@ void __init reserve_crashkernel(void)
#ifdef CONFIG_PPC64
/*
* On the LPAR platform place the crash kernel to mid of
-* RMA size (512MB or more) to ensure the crash kernel
+* RMA size (max. of 512MB) to ensure the crash kernel
* gets enough space to place itself and some stack to be
* in the first segment. At the same time normal kernel
* also get enough space to allocate memory for essential
@@ -144,7 +144,7 @@ void __init reserve_crashkernel(void)
* kernel starts at 128MB offset on other platforms.
*/
if (firmware_has_feature(FW_FEATURE_LPAR))
- crashk_res.start = ppc64_rma_size / 2;
+ crashk_res.start = min(0x2000ULL, (ppc64_rma_size /
2));
else
crashk_res.start = min(0x800ULL, (ppc64_rma_size /
2));
#else
--
2.37.3
Re: [RFC PATCH RESEND 28/28] kernel/fork: throttle call_rcu() calls in vm_area_free
Le 09/09/2022 à 18:02, Suren Baghdasaryan a écrit :
> On Fri, Sep 9, 2022 at 8:19 AM Laurent Dufour wrote:
>>
>> Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
>>> call_rcu() can take a long time when callback offloading is enabled.
>>> Its use in the vm_area_free can cause regressions in the exit path when
>>> multiple VMAs are being freed. To minimize that impact, place VMAs into
>>> a list and free them in groups using one call_rcu() call per group.
>>>
>>> Signed-off-by: Suren Baghdasaryan
>>> ---
>>> include/linux/mm.h | 1 +
>>> include/linux/mm_types.h | 11 ++-
>>> kernel/fork.c| 68 +++-
>>> mm/init-mm.c | 3 ++
>>> mm/mmap.c| 1 +
>>> 5 files changed, 75 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index a3cbaa7b9119..81dff694ac14 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -249,6 +249,7 @@ void setup_initial_init_mm(void *start_code, void
>>> *end_code,
>>> struct vm_area_struct *vm_area_alloc(struct mm_struct *);
>>> struct vm_area_struct *vm_area_dup(struct vm_area_struct *);
>>> void vm_area_free(struct vm_area_struct *);
>>> +void drain_free_vmas(struct mm_struct *mm);
>>>
>>> #ifndef CONFIG_MMU
>>> extern struct rb_root nommu_region_tree;
>>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>>> index 36562e702baf..6f3effc493b1 100644
>>> --- a/include/linux/mm_types.h
>>> +++ b/include/linux/mm_types.h
>>> @@ -412,7 +412,11 @@ struct vm_area_struct {
>>> struct vm_area_struct *vm_next, *vm_prev;
>>> };
>>> #ifdef CONFIG_PER_VMA_LOCK
>>> - struct rcu_head vm_rcu; /* Used for deferred freeing. */
>>> + struct {
>>> + struct list_head vm_free_list;
>>> + /* Used for deferred freeing. */
>>> + struct rcu_head vm_rcu;
>>> + };
>>> #endif
>>> };
>>>
>>> @@ -573,6 +577,11 @@ struct mm_struct {
>>> */
>>> #ifdef CONFIG_PER_VMA_LOCK
>>> int mm_lock_seq;
>>> + struct {
>>> + struct list_head head;
>>> + spinlock_t lock;
>>> + int size;
>>> + } vma_free_list;
>>> #endif
>>>
>>>
>>> diff --git a/kernel/fork.c b/kernel/fork.c
>>> index b443ba3a247a..7c88710aed72 100644
>>> --- a/kernel/fork.c
>>> +++ b/kernel/fork.c
>>> @@ -483,26 +483,75 @@ struct vm_area_struct *vm_area_dup(struct
>>> vm_area_struct *orig)
>>> }
>>>
>>> #ifdef CONFIG_PER_VMA_LOCK
>>> -static void __vm_area_free(struct rcu_head *head)
>>> +static inline void __vm_area_free(struct vm_area_struct *vma)
>>> {
>>> - struct vm_area_struct *vma = container_of(head, struct vm_area_struct,
>>> - vm_rcu);
>>> /* The vma should either have no lock holders or be write-locked. */
>>> vma_assert_no_reader(vma);
>>> kmem_cache_free(vm_area_cachep, vma);
>>> }
>>> -#endif
>>> +
>>> +static void vma_free_rcu_callback(struct rcu_head *head)
>>> +{
>>> + struct vm_area_struct *first_vma;
>>> + struct vm_area_struct *vma, *vma2;
>>> +
>>> + first_vma = container_of(head, struct vm_area_struct, vm_rcu);
>>> + list_for_each_entry_safe(vma, vma2, &first_vma->vm_free_list,
>>> vm_free_list)
>>
>> Is that safe to walk the list against concurrent calls to
>> list_splice_init(), or list_add()?
>
> I think it is. drain_free_vmas() moves the to-be-destroyed and already
> isolated VMAs from mm->vma_free_list into to_destroy list and then
> passes that list to vma_free_rcu_callback(). At this point the list of
> VMAs passed to vma_free_rcu_callback() is not accessible either from
> mm (VMAs were isolated before vm_area_free() was called) or from
> drain_free_vmas() since they were already removed from
> mm->vma_free_list. Does that make sense?
Got it!
Thanks for the explanation.
>
>>
>>> + __vm_area_free(vma);
>>> + __vm_area_free(first_vma);
>>> +}
>>> +
>>> +void drain_free_vmas(struct mm_struct *mm)
>>> +{
>>> + struct vm_area_struct *first_vma;
>>> + LIST_HEAD(to_destroy);
>>> +
>>> + spin_lock(&mm->vma_free_list.lock);
>>> + list_splice_init(&mm->vma_free_list.head, &to_destroy);
>>> + mm->vma_free_list.size = 0;
>>> + spin_unlock(&mm->vma_free_list.lock);
>>> +
>>> + if (list_empty(&to_destroy))
>>> + return;
>>> +
>>> + first_vma = list_first_entry(&to_destroy, struct vm_area_struct,
>>> vm_free_list);
>>> + /* Remove the head which is allocated on the stack */
>>> + list_del(&to_destroy);
>>> +
>>> + call_rcu(&first_vma->vm_rcu, vma_free_rcu_callback);
>>> +}
>>> +
>>> +#define VM_AREA_FREE_LIST_MAX32
>>> +
>>> +void vm_area_free(struct vm_area_struct *vma)
>>> +{
>>> + struct mm_struct *mm = vma->vm_mm;
>>> +
Re: [RFC PATCH RESEND 10/28] mm/mmap: mark VMAs as locked in vma_adjust
Le 09/09/2022 à 02:51, Suren Baghdasaryan a écrit :
> On Tue, Sep 6, 2022 at 8:35 AM Laurent Dufour wrote:
>>
>> Le 01/09/2022 à 19:34, Suren Baghdasaryan a écrit :
>>> vma_adjust modifies a VMA and possibly its neighbors. Mark them as locked
>>> before making the modifications.
>>>
>>> Signed-off-by: Suren Baghdasaryan
>>> ---
>>> mm/mmap.c | 11 ++-
>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/mmap.c b/mm/mmap.c
>>> index f89c9b058105..ed58cf0689b2 100644
>>> --- a/mm/mmap.c
>>> +++ b/mm/mmap.c
>>> @@ -710,6 +710,10 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned
>>> long start,
>>> long adjust_next = 0;
>>> int remove_next = 0;
>>>
>>> + vma_mark_locked(vma);
>>> + if (next)
>>> + vma_mark_locked(next);
>>> +
>>
>> I was wondering if the VMAs insert and expand should be locked too.
>>
>> For expand, I can't see any valid reason, but for insert, I'm puzzled.
>> I would think that it is better to lock the VMA to be inserted but I can't
>> really justify that.
>>
>> It may be nice to detail why this is not need to lock insert and expand here.
>
> 'expand' is always locked before it's passed to __vma_adjust() by
> vma_merge(). It has to be locked before we decide "Can it merge with
> the predecessor?" here
> https://elixir.bootlin.com/linux/latest/source/mm/mmap.c#L1201 because
> a change in VMA can affect that decision. I spent many hours tracking
> the issue caused by not locking the VMA before making this decision.
> It might be good to add a comment about this...
>
> AFAIKT 'insert' is only used by __split_vma() and it's always a brand
> new VMA which is not yet linked into mm->mmap. Any reason
> __vma_adjust() should lock it?
No, I think that's good this way.
>
>>
>>> if (next && !insert) {
>>> struct vm_area_struct *exporter = NULL, *importer = NULL;
>>>
>>> @@ -754,8 +758,11 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned
>>> long start,
>>>* If next doesn't have anon_vma, import from vma
>>> after
>>>* next, if the vma overlaps with it.
>>>*/
>>> - if (remove_next == 2 && !next->anon_vma)
>>> + if (remove_next == 2 && !next->anon_vma) {
>>> exporter = next->vm_next;
>>> + if (exporter)
>>> + vma_mark_locked(exporter);
>>> + }
>>>
>>> } else if (end > next->vm_start) {
>>> /*
>>> @@ -931,6 +938,8 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned
>>> long start,
>>>* "vma->vm_next" gap must be updated.
>>>*/
>>> next = vma->vm_next;
>>> + if (next)
>>> + vma_mark_locked(next);
>>> } else {
>>> /*
>>>* For the scope of the comment "next" and
>>
>> --
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kernel-team+unsubscr...@android.com.
>>
Re: [RFC PATCH RESEND 28/28] kernel/fork: throttle call_rcu() calls in vm_area_free
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> call_rcu() can take a long time when callback offloading is enabled.
> Its use in the vm_area_free can cause regressions in the exit path when
> multiple VMAs are being freed. To minimize that impact, place VMAs into
> a list and free them in groups using one call_rcu() call per group.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> include/linux/mm.h | 1 +
> include/linux/mm_types.h | 11 ++-
> kernel/fork.c| 68 +++-
> mm/init-mm.c | 3 ++
> mm/mmap.c| 1 +
> 5 files changed, 75 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index a3cbaa7b9119..81dff694ac14 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -249,6 +249,7 @@ void setup_initial_init_mm(void *start_code, void
> *end_code,
> struct vm_area_struct *vm_area_alloc(struct mm_struct *);
> struct vm_area_struct *vm_area_dup(struct vm_area_struct *);
> void vm_area_free(struct vm_area_struct *);
> +void drain_free_vmas(struct mm_struct *mm);
>
> #ifndef CONFIG_MMU
> extern struct rb_root nommu_region_tree;
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 36562e702baf..6f3effc493b1 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -412,7 +412,11 @@ struct vm_area_struct {
> struct vm_area_struct *vm_next, *vm_prev;
> };
> #ifdef CONFIG_PER_VMA_LOCK
> - struct rcu_head vm_rcu; /* Used for deferred freeing. */
> + struct {
> + struct list_head vm_free_list;
> + /* Used for deferred freeing. */
> + struct rcu_head vm_rcu;
> + };
> #endif
> };
>
> @@ -573,6 +577,11 @@ struct mm_struct {
> */
> #ifdef CONFIG_PER_VMA_LOCK
> int mm_lock_seq;
> + struct {
> + struct list_head head;
> + spinlock_t lock;
> + int size;
> + } vma_free_list;
> #endif
>
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index b443ba3a247a..7c88710aed72 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -483,26 +483,75 @@ struct vm_area_struct *vm_area_dup(struct
> vm_area_struct *orig)
> }
>
> #ifdef CONFIG_PER_VMA_LOCK
> -static void __vm_area_free(struct rcu_head *head)
> +static inline void __vm_area_free(struct vm_area_struct *vma)
> {
> - struct vm_area_struct *vma = container_of(head, struct vm_area_struct,
> - vm_rcu);
> /* The vma should either have no lock holders or be write-locked. */
> vma_assert_no_reader(vma);
> kmem_cache_free(vm_area_cachep, vma);
> }
> -#endif
> +
> +static void vma_free_rcu_callback(struct rcu_head *head)
> +{
> + struct vm_area_struct *first_vma;
> + struct vm_area_struct *vma, *vma2;
> +
> + first_vma = container_of(head, struct vm_area_struct, vm_rcu);
> + list_for_each_entry_safe(vma, vma2, &first_vma->vm_free_list,
> vm_free_list)
Is that safe to walk the list against concurrent calls to
list_splice_init(), or list_add()?
> + __vm_area_free(vma);
> + __vm_area_free(first_vma);
> +}
> +
> +void drain_free_vmas(struct mm_struct *mm)
> +{
> + struct vm_area_struct *first_vma;
> + LIST_HEAD(to_destroy);
> +
> + spin_lock(&mm->vma_free_list.lock);
> + list_splice_init(&mm->vma_free_list.head, &to_destroy);
> + mm->vma_free_list.size = 0;
> + spin_unlock(&mm->vma_free_list.lock);
> +
> + if (list_empty(&to_destroy))
> + return;
> +
> + first_vma = list_first_entry(&to_destroy, struct vm_area_struct,
> vm_free_list);
> + /* Remove the head which is allocated on the stack */
> + list_del(&to_destroy);
> +
> + call_rcu(&first_vma->vm_rcu, vma_free_rcu_callback);
> +}
> +
> +#define VM_AREA_FREE_LIST_MAX32
> +
> +void vm_area_free(struct vm_area_struct *vma)
> +{
> + struct mm_struct *mm = vma->vm_mm;
> + bool drain;
> +
> + free_anon_vma_name(vma);
> +
> + spin_lock(&mm->vma_free_list.lock);
> + list_add(&vma->vm_free_list, &mm->vma_free_list.head);
> + mm->vma_free_list.size++;
> + drain = mm->vma_free_list.size > VM_AREA_FREE_LIST_MAX;
> + spin_unlock(&mm->vma_free_list.lock);
> +
> + if (drain)
> + drain_free_vmas(mm);
> +}
> +
> +#else /* CONFIG_PER_VMA_LOCK */
> +
> +void drain_free_vmas(struct mm_struct *mm) {}
>
> void vm_area_free(struct vm_area_struct *vma)
> {
> free_anon_vma_name(vma);
> -#ifdef CONFIG_PER_VMA_LOCK
> - call_rcu(&vma->vm_rcu, __vm_area_free);
> -#else
> kmem_cache_free(vm_area_cachep, vma);
> -#endif
> }
>
> +#endif /* CONFIG_PER_VMA_LOCK */
> +
> static void account_kernel_stack(struct task_struct *tsk, int account)
> {
> if (IS_
Re: [PATCH v5 0/8] phy: Add support for Lynx 10G SerDes
Hi Vinod/Kishon, On 9/2/22 5:37 PM, Sean Anderson wrote: > This adds support for the Lynx 10G SerDes found on the QorIQ T-series > and Layerscape series. Due to limited time and hardware, only support > for the LS1046ARDB is added in this initial series. There is a sketch > for LS1088ARDB support, but it is incomplete. > > Dynamic reconfiguration does not work. That is, the configuration must > match what is set in the RCW. From my testing, SerDes register settings > appear identical. The issue appears to be between the PCS and the MAC. > The link itself comes up at both ends, and a mac loopback succeeds. > However, a PCS loopback results in dropped packets. Perhaps there is > some undocumented register in the PCS? > > I suspect this driver is around 95% complete, but, unfortunately, I no > longer have time to investigate this further. > > Changes in v5: > - Update commit description > - Dual id header > - Remove references to PHY_INTERFACE_MODE_1000BASEKX to allow this > series to be applied directly to linux/master. > - Add fsl,lynx-10g.h to MAINTAINERS > > Changes in v4: > - Add 2500BASE-X and 10GBASE-R phy types > - Use subnodes to describe lane configuration, instead of describing > PCCRs. This is the same style used by phy-cadence-sierra et al. > - Add ids for Lynx 10g PLLs > - Rework all debug statements to remove use of __func__. Additional > information has been provided as necessary. > - Consider alternative parent rates in round_rate and not in set_rate. > Trying to modify out parent's rate in set_rate will deadlock. > - Explicitly perform a stop/reset sequence in set_rate. This way we > always ensure that the PLL is properly stopped. > - Set the power-down bit when disabling the PLL. We can do this now that > enable/disable aren't abused during the set rate sequence. > - Fix typos in QSGMII_OFFSET and XFI_OFFSET > - Rename LNmTECR0_TEQ_TYPE_PRE to LNmTECR0_TEQ_TYPE_POST to better > reflect its function (adding post-cursor equalization). > - Use of_clk_hw_onecell_get instead of a custom function. > - Return struct clks from lynx_clks_init instead of embedding lynx_clk > in lynx_priv. > - Rework PCCR helper functions; T-series SoCs differ from Layerscape SoCs > primarily in the layout and offset of the PCCRs. This will help bring a > cleaner abstraction layer. The caps have been removed, since this handles > the > only current usage. > - Convert to use new binding format. As a result of this, we no longer need to > have protocols for PCIe or SATA. Additionally, modes now live in lynx_group > instead of lynx_priv. > - Remove teq from lynx_proto_params, since it can be determined from > preq_ratio/postq_ratio. > - Fix an early return from lynx_set_mode not releasing serdes->lock. > - Rename lynx_priv.conf to .cfg, since I kept mistyping it. > > Changes in v3: > - Manually expand yaml references > - Add mode configuration to device tree > - Rename remaining references to QorIQ SerDes to Lynx 10G > - Fix PLL enable sequence by waiting for our reset request to be cleared > before continuing. Do the same for the lock, even though it isn't as > critical. Because we will delay for 1.5ms on average, use prepare > instead of enable so we can sleep. > - Document the status of each protocol > - Fix offset of several bitfields in RECR0 > - Take into account PLLRST_B, SDRST_B, and SDEN when considering whether > a PLL is "enabled." > - Only power off unused lanes. > - Split mode lane mask into first/last lane (like group) > - Read modes from device tree > - Use caps to determine whether KX/KR are supported > - Move modes to lynx_priv > - Ensure that the protocol controller is not already in-use when we try > to configure a new mode. This should only occur if the device tree is > misconfigured (e.g. when QSGMII is selected on two lanes but there is > only one QSGMII controller). > - Split PLL drivers off into their own file > - Add clock for "ext_dly" instead of writing the bit directly (and > racing with any clock code). > - Use kasprintf instead of open-coding the snprintf dance > - Support 1000BASE-KX in lynx_lookup_proto. This still requires PCS > support, so nothing is truly "enabled" yet. > - Describe modes in device tree > - ls1088a: Add serdes bindings > > Changes in v2: > - Rename to fsl,lynx-10g.yaml > - Refer to the device in the documentation, rather than the binding > - Move compatible first > - Document phy cells in the description > - Allow a value of 1 for phy-cells. This allows for compatibility with > the similar (but according to Ioana Ciornei different enough) lynx-28g > binding. > - Remove minItems > - Use list for clock-names > - Fix example binding having too many cells in regs > - Add #clock-cells. This will allow using assigned-clocks* to configure > the PLLs. > - Document the structure of the compatible strings > - Rename driver to Lynx 10G (etc.) > - Fix not clearing group->pll after disabling it > - Support 1 and 2 phy-cells
Re: [RFC PATCH RESEND 21/28] mm: introduce find_and_lock_anon_vma to be used from arch-specific code
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> Introduce find_and_lock_anon_vma function to lookup and lock an anonymous
> VMA during page fault handling. When VMA is not found, can't be locked
> or changes after being locked, the function returns NULL. The lookup is
> performed under RCU protection to prevent the found VMA from being
> destroyed before the VMA lock is acquired. VMA lock statistics are
> updated according to the results.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> include/linux/mm.h | 3 +++
> mm/memory.c| 45 +
> 2 files changed, 48 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 7c3190eaabd7..a3cbaa7b9119 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -684,6 +684,9 @@ static inline void vma_assert_no_reader(struct
> vm_area_struct *vma)
> vma);
> }
>
> +struct vm_area_struct *find_and_lock_anon_vma(struct mm_struct *mm,
> + unsigned long address);
> +
> #else /* CONFIG_PER_VMA_LOCK */
>
> static inline void vma_init_lock(struct vm_area_struct *vma) {}
> diff --git a/mm/memory.c b/mm/memory.c
> index 29d2f49f922a..bf557f7056de 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -5183,6 +5183,51 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *vma,
> unsigned long address,
> }
> EXPORT_SYMBOL_GPL(handle_mm_fault);
>
> +#ifdef CONFIG_PER_VMA_LOCK
> +static inline struct vm_area_struct *find_vma_under_rcu(struct mm_struct *mm,
> + unsigned long address)
> +{
> + struct vm_area_struct *vma = __find_vma(mm, address);
> +
> + if (!vma || vma->vm_start > address)
> + return NULL;
> +
> + if (!vma_is_anonymous(vma))
> + return NULL;
> +
It looks to me more natural to first check that the VMA is part of the RB
tree before try read locking it.
> + if (!vma_read_trylock(vma)) {
> + count_vm_vma_lock_event(VMA_LOCK_ABORT);
> + return NULL;
> + }
> +
> + /* Check if the VMA got isolated after we found it */
> + if (RB_EMPTY_NODE(&vma->vm_rb)) {
> + vma_read_unlock(vma);
> + count_vm_vma_lock_event(VMA_LOCK_MISS);
> + return NULL;
> + }
> +
> + return vma;
> +}
> +
> +/*
> + * Lookup and lock and anonymous VMA. Returned VMA is guaranteed to be stable
> + * and not isolated. If the VMA is not found of is being modified the
> function
> + * returns NULL.
> + */
> +struct vm_area_struct *find_and_lock_anon_vma(struct mm_struct *mm,
> + unsigned long address)
> +{
> + struct vm_area_struct *vma;
> +
> + rcu_read_lock();
> + vma = find_vma_under_rcu(mm, address);
> + rcu_read_unlock();
> +
> + return vma;
> +}
> +#endif /* CONFIG_PER_VMA_LOCK */
> +
> #ifndef __PAGETABLE_P4D_FOLDED
> /*
> * Allocate p4d page table.
Re: [RFC PATCH RESEND 20/28] mm: introduce per-VMA lock statistics
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> Add a new CONFIG_PER_VMA_LOCK_STATS config option to dump extra
> statistics about handling page fault under VMA lock.
>
Why not making this a default when per VMA lock are enabled?
> Signed-off-by: Suren Baghdasaryan
> ---
> include/linux/vm_event_item.h | 6 ++
> include/linux/vmstat.h| 6 ++
> mm/Kconfig.debug | 8
> mm/vmstat.c | 6 ++
> 4 files changed, 26 insertions(+)
>
> diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
> index f3fc36cd2276..a325783ed05d 100644
> --- a/include/linux/vm_event_item.h
> +++ b/include/linux/vm_event_item.h
> @@ -150,6 +150,12 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
> #ifdef CONFIG_X86
> DIRECT_MAP_LEVEL2_SPLIT,
> DIRECT_MAP_LEVEL3_SPLIT,
> +#endif
> +#ifdef CONFIG_PER_VMA_LOCK_STATS
> + VMA_LOCK_SUCCESS,
> + VMA_LOCK_ABORT,
> + VMA_LOCK_RETRY,
> + VMA_LOCK_MISS,
> #endif
> NR_VM_EVENT_ITEMS
> };
> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
> index bfe38869498d..0c2611899cfc 100644
> --- a/include/linux/vmstat.h
> +++ b/include/linux/vmstat.h
> @@ -131,6 +131,12 @@ static inline void vm_events_fold_cpu(int cpu)
> #define count_vm_vmacache_event(x) do {} while (0)
> #endif
>
> +#ifdef CONFIG_PER_VMA_LOCK_STATS
> +#define count_vm_vma_lock_event(x) count_vm_event(x)
> +#else
> +#define count_vm_vma_lock_event(x) do {} while (0)
> +#endif
> +
> #define __count_zid_vm_events(item, zid, delta) \
> __count_vm_events(item##_NORMAL - ZONE_NORMAL + zid, delta)
>
> diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> index ce8dded36de9..075642763a03 100644
> --- a/mm/Kconfig.debug
> +++ b/mm/Kconfig.debug
> @@ -207,3 +207,11 @@ config PTDUMP_DEBUGFS
> kernel.
>
> If in doubt, say N.
> +
> +
> +config PER_VMA_LOCK_STATS
> + bool "Statistics for per-vma locks"
> + depends on PER_VMA_LOCK
> + help
> + Statistics for per-vma locks.
> + If in doubt, say N.
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index 90af9a8572f5..3f3804c846a6 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -1411,6 +1411,12 @@ const char * const vmstat_text[] = {
> "direct_map_level2_splits",
> "direct_map_level3_splits",
> #endif
> +#ifdef CONFIG_PER_VMA_LOCK_STATS
> + "vma_lock_success",
> + "vma_lock_abort",
> + "vma_lock_retry",
> + "vma_lock_miss",
> +#endif
> #endif /* CONFIG_VM_EVENT_COUNTERS || CONFIG_MEMCG */
> };
> #endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA || CONFIG_MEMCG */
Re: [RFC PATCH RESEND 19/28] mm: disallow do_swap_page to handle page faults under VMA lock
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> Due to the possibility of do_swap_page dropping mmap_lock, abort fault
> handling under VMA lock and retry holding mmap_lock. This can be handled
> more gracefully in the future.
>
> Signed-off-by: Suren Baghdasaryan
Reviewed-by: Laurent Dufour
> ---
> mm/memory.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 9ac9944e8c62..29d2f49f922a 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3738,6 +3738,11 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> vm_fault_t ret = 0;
> void *shadow = NULL;
>
> + if (vmf->flags & FAULT_FLAG_VMA_LOCK) {
> + ret = VM_FAULT_RETRY;
> + goto out;
> + }
> +
> if (!pte_unmap_same(vmf))
> goto out;
>
Re: [RFC PATCH RESEND 18/28] mm: add FAULT_FLAG_VMA_LOCK flag
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> Add a new flag to distinguish page faults handled under protection of
> per-vma lock.
>
> Signed-off-by: Suren Baghdasaryan
FWIW,
Reviewed-by: Laurent Dufour
> ---
> include/linux/mm.h | 3 ++-
> include/linux/mm_types.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 0d9c1563c354..7c3190eaabd7 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -466,7 +466,8 @@ static inline bool fault_flag_allow_retry_first(enum
> fault_flag flags)
> { FAULT_FLAG_USER, "USER" }, \
> { FAULT_FLAG_REMOTE,"REMOTE" }, \
> { FAULT_FLAG_INSTRUCTION, "INSTRUCTION" }, \
> - { FAULT_FLAG_INTERRUPTIBLE, "INTERRUPTIBLE" }
> + { FAULT_FLAG_INTERRUPTIBLE, "INTERRUPTIBLE" }, \
> + { FAULT_FLAG_VMA_LOCK, "VMA_LOCK" }
>
> /*
> * vm_fault is filled by the pagefault handler and passed to the vma's
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6a03f59c1e78..36562e702baf 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -886,6 +886,7 @@ enum fault_flag {
> FAULT_FLAG_INTERRUPTIBLE = 1 << 9,
> FAULT_FLAG_UNSHARE =1 << 10,
> FAULT_FLAG_ORIG_PTE_VALID = 1 << 11,
> + FAULT_FLAG_VMA_LOCK = 1 << 12,
> };
>
> typedef unsigned int __bitwise zap_flags_t;
[PATCH] powerpc/time: avoid programming DEC at the start of the timer interrupt
Setting DEC to maximum at the start of the timer interrupt is not
necessary and can be avoided for performance when MSR[EE] is not
enabled during the handler as explained in commit 0faf20a1ad16
("powerpc/64s/interrupt: Don't enable MSR[EE] in irq handlers unless
perf is in use"), where this change was first attempted.
The idea is that the timer interrupt runs with MSR[EE]=0, and at the end
of the interrupt DEC is programmed to the next timer interval, so there
is no need to clear the decrementer exception before then.
When the above commit was merged, that was not quite true. The low res
timer subsystem had some cases in the oneshot timer code where if the
tick was to be stopped and no timers active, the clock device would not
get the ->set_state_oneshot_stopped() call, so DEC would not get
reprogrammed, and this would hang taking continual timer interrupts.
So this was reverted in commit d2b9be1f4af5 ("powerpc/time: Always set
decrementer in timer_interrupt()"), which was a partial revert of the
above commit.
Commit 62c1256d5447 ("timers/nohz: Switch to ONESHOT_STOPPED in the
low-res handler when the tick is stopped") was later merged to fix this
missing case in the timer subsystem, so now the behaviour can be
restored.
Signed-off-by: Nicholas Piggin
---
Try this again. This boots fine with CONFIG_HIGH_RES_TIMERS=n.
Reverting 62c1256d5447 with this patch applied causes the
infinite timer hang to reappear, which confirms test is doing
something useful.
Thanks,
Nick
arch/powerpc/kernel/time.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 587adcc12860..328129f19a2e 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -614,22 +614,23 @@ DEFINE_INTERRUPT_HANDLER_ASYNC(timer_interrupt)
return;
}
- /*
-* Ensure a positive value is written to the decrementer, or
-* else some CPUs will continue to take decrementer exceptions.
-* When the PPC_WATCHDOG (decrementer based) is configured,
-* keep this at most 31 bits, which is about 4 seconds on most
-* systems, which gives the watchdog a chance of catching timer
-* interrupt hard lockups.
-*/
- if (IS_ENABLED(CONFIG_PPC_WATCHDOG))
- set_dec(0x7fff);
- else
- set_dec(decrementer_max);
-
/* Conditionally hard-enable interrupts. */
- if (should_hard_irq_enable())
+ if (should_hard_irq_enable()) {
+ /*
+* Ensure a positive value is written to the decrementer, or
+* else some CPUs will continue to take decrementer exceptions.
+* When the PPC_WATCHDOG (decrementer based) is configured,
+* keep this at most 31 bits, which is about 4 seconds on most
+* systems, which gives the watchdog a chance of catching timer
+* interrupt hard lockups.
+*/
+ if (IS_ENABLED(CONFIG_PPC_WATCHDOG))
+ set_dec(0x7fff);
+ else
+ set_dec(decrementer_max);
+
do_hard_irq_enable();
+ }
#if defined(CONFIG_PPC32) && defined(CONFIG_PPC_PMAC)
if (atomic_read(&ppc_n_lost_interrupts) != 0)
--
2.37.2
Re: [RFC PATCH RESEND 17/28] mm/mmap: prevent pagefault handler from racing with mmu_notifier registration
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> Pagefault handlers might need to fire MMU notifications while a new
> notifier is being registered. Modify mm_take_all_locks to mark all VMAs
> as locked and prevent this race with fault handlers that would hold VMA
> locks.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> mm/mmap.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index b31cc97c2803..1edfcd384f5e 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3538,6 +3538,7 @@ static void vm_lock_mapping(struct mm_struct *mm,
> struct address_space *mapping)
> * hugetlb mapping);
> * - all i_mmap_rwsem locks;
> * - all anon_vma->rwseml
> + * - all vmas marked locked
IIRC, the anon_vma may be locked during the page fault handling, and this
happens after the VMA is read lock. I think the same applies to
i_mmap_rwsem lock.
Thus, the VMA should be marked locked first.
> *
> * We can take all locks within these types randomly because the VM code
> * doesn't nest them and we protected from parallel mm_take_all_locks() by
> @@ -3579,6 +3580,7 @@ int mm_take_all_locks(struct mm_struct *mm)
> if (vma->anon_vma)
> list_for_each_entry(avc, &vma->anon_vma_chain, same_vma)
> vm_lock_anon_vma(mm, avc->anon_vma);
> + vma_mark_locked(vma);
> }
>
> return 0;
> @@ -3636,6 +3638,7 @@ void mm_drop_all_locks(struct mm_struct *mm)
> mmap_assert_write_locked(mm);
> BUG_ON(!mutex_is_locked(&mm_all_locks_mutex));
>
> + vma_mark_unlocked_all(mm);
> for (vma = mm->mmap; vma; vma = vma->vm_next) {
> if (vma->anon_vma)
> list_for_each_entry(avc, &vma->anon_vma_chain, same_vma)
Re: [PATCH] Revert "powerpc/rtas: Implement reentrant rtas call"
Hi Leonardo,
(restoring the list to the cc, hope that's ok)
Leonardo Brás writes:
> On Wed, 2022-09-07 at 17:01 -0500, Nathan Lynch wrote:
>> At the time this was submitted by Leonardo, I confirmed -- or thought
>> I had confirmed -- with PowerVM partition firmware development that
>> the following RTAS functions:
>>
>> - ibm,get-xive
>> - ibm,int-off
>> - ibm,int-on
>> - ibm,set-xive
>>
>> were safe to call on multiple CPUs simultaneously, not only with
>> respect to themselves as indicated by PAPR, but with arbitrary other
>> RTAS calls:
>>
>> https://lore.kernel.org/linuxppc-dev/875zcy2v8o@linux.ibm.com/
>>
>> Recent discussion with firmware development makes it clear that this
>> is not true, and that the code in commit b664db8e3f97 ("powerpc/rtas:
>> Implement reentrant rtas call") is unsafe, likely explaining several
>> strange bugs we've seen in internal testing involving DLPAR and
>> LPM. These scenarios use ibm,configure-connector, whose internal state
>> can be corrupted by the concurrent use of the "reentrant" functions,
>> leading to symptoms like endless busy statuses from RTAS.
>
> Oh, does not it means PowerVM is not compliant to the PAPR specs?
No, it means the premise of commit b664db8e3f97 ("powerpc/rtas:
Implement reentrant rtas call") change is incorrect. The "reentrant"
property described in the spec applies only to the individual RTAS
functions. The OS can invoke (for example) ibm,set-xive on multiple CPUs
simultaneously, but it must adhere to the more general requirement to
serialize with other RTAS functions.
I don't claim that this is a useful property, at least not for
Linux. Maybe other OSes are better able to exploit it.
I apologize for my role in the confusion here. When reviewing the
original change, I talked to firmware development about the reentrant
property and how we wanted to use it. I've since reviewed that
conversation and concluded that I didn't communicate clearly, and that I
interpreted their responses too eagerly.
In the future, when we (pseries Linux developers at IBM) want to go
beyond the language of the spec, we probably should initiate an
architecture change to make the PAPR eventually align with our
implementation choices.
> I mentioned this in the original Commit, and it's still true to the last
> LoPAR:
>
> ###
> For "ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive".
>
> On LoPAPR Version 1.1 (March 24, 2016), from 7.3.10.1 to 7.3.10.4,
> items 2 and 3 say:
>
> 2 - For the PowerPC External Interrupt option: The * call must be
> reentrant to the number of processors on the platform.
> 3 - For the PowerPC External Interrupt option: The * argument call
> buffer for each simultaneous call must be physically unique.
>
> ###
>
> Other than that, IIRC, this change was used to avoid issues that were
> happening
> on kdump/kexec:
> If another thread was holding the rtas lock, kdump/kexec would get stuck
> waiting
> for the lock forever and never finish the process, often causing a bug
> reproduction's kdump to not get collected.
>
> Is there any other fix for the above bug?
Not that I'm aware of, but if this is a common failure mode for kdump,
then perhaps rtas_call() or related code should be made to ignore the
lock in the crash path, as a more general mitigation.
Then again, maybe it's not that urgent? Only XICS mode guests are
potentially affected. Do we even have this problem with
firmware-assisted dumps on PowerVM?
> Or is that a bug which is acceptable to have back, compared to the new
> one?
It was not acceptable to regress existing functions (DLPAR, LPM) in
exchange for making the crash path more robust. Reverting the change is
the correct tradeoff, unfortunately.
Re: [RFC PATCH RESEND 16/28] kernel/fork: assert no VMA readers during its destruction
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> Assert there are no holders of VMA lock for reading when it is about to be
> destroyed.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> include/linux/mm.h | 8
> kernel/fork.c | 2 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index dc72be923e5b..0d9c1563c354 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -676,6 +676,13 @@ static inline void vma_assert_write_locked(struct
> vm_area_struct *vma, int pos)
> VM_BUG_ON_VMA(vma->vm_lock_seq != READ_ONCE(vma->vm_mm->mm_lock_seq),
> vma);
> }
>
> +static inline void vma_assert_no_reader(struct vm_area_struct *vma)
> +{
> + VM_BUG_ON_VMA(rwsem_is_locked(&vma->lock) &&
> + vma->vm_lock_seq != READ_ONCE(vma->vm_mm->mm_lock_seq),
> + vma);
> +}
> +
> #else /* CONFIG_PER_VMA_LOCK */
>
> static inline void vma_init_lock(struct vm_area_struct *vma) {}
> @@ -685,6 +692,7 @@ static inline bool vma_read_trylock(struct vm_area_struct
> *vma)
> static inline void vma_read_unlock(struct vm_area_struct *vma) {}
> static inline void vma_assert_locked(struct vm_area_struct *vma) {}
> static inline void vma_assert_write_locked(struct vm_area_struct *vma, int
> pos) {}
> +static inline void vma_assert_no_reader(struct vm_area_struct *vma) {}
>
> #endif /* CONFIG_PER_VMA_LOCK */
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 1872ad549fed..b443ba3a247a 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -487,6 +487,8 @@ static void __vm_area_free(struct rcu_head *head)
> {
> struct vm_area_struct *vma = container_of(head, struct vm_area_struct,
> vm_rcu);
> + /* The vma should either have no lock holders or be write-locked. */
> + vma_assert_no_reader(vma);
I'm wondering if this can be hit in the case the thread freeing a VMA is
preempted before incrementing the mm ref count, like this:
VMA is about to be freed
write lock VMA
free vma -> call_rcu
..
<--- thread preempted
rcu handler runs
rcu calls __vm_area_free() <<
unlock mmap_lock and increase the mm seq count
> kmem_cache_free(vm_area_cachep, vma);
> }
> #endif
Re: [RFC PATCH RESEND 15/28] mm/mmap: mark adjacent VMAs as locked if they can grow into unmapped area
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> While unmapping VMAs, adjacent VMAs might be able to grow into the area
> being unmapped. In such cases mark adjacent VMAs as locked to prevent
> this growth.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> mm/mmap.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index b0d78bdc0de0..b31cc97c2803 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2680,10 +2680,14 @@ detach_vmas_to_be_unmapped(struct mm_struct *mm,
> struct vm_area_struct *vma,
>* VM_GROWSUP VMA. Such VMAs can change their size under
>* down_read(mmap_lock) and collide with the VMA we are about to unmap.
>*/
> - if (vma && (vma->vm_flags & VM_GROWSDOWN))
> + if (vma && (vma->vm_flags & VM_GROWSDOWN)) {
> + vma_mark_locked(vma);
> return false;
> - if (prev && (prev->vm_flags & VM_GROWSUP))
> + }
> + if (prev && (prev->vm_flags & VM_GROWSUP)) {
> + vma_mark_locked(prev);
> return false;
> + }
> return true;
> }
>
That looks right to be.
But, in addition to that, like the previous patch, all the VMAs to be
detached from the tree in the loop above, should be marked locked just
before calling vm_rb_erase().
Re: [RFC PATCH RESEND 14/28] mm: mark VMAs as locked before isolating them
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> Mark VMAs as locked before isolating them and clear their tree node so
> that isolated VMAs are easily identifiable. In the later patches page
> fault handlers will try locking the found VMA and will check whether
> the VMA was isolated. Locking VMAs before isolating them ensures that
> page fault handlers don't operate on isolated VMAs.
Found another place where the VMA should probably mark locked:
*** drivers/gpu/drm/drm_vma_manager.c:
drm_vma_node_revoke[338] rb_erase(&entry->vm_rb, &node->vm_files);
There are 2 others entries in nommu.c but I guess this is not supported,
isn't it?
> Signed-off-by: Suren Baghdasaryan
> ---
> mm/mmap.c | 2 ++
> mm/nommu.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 094678b4434b..b0d78bdc0de0 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -421,12 +421,14 @@ static inline void vma_rb_insert(struct vm_area_struct
> *vma,
>
> static void __vma_rb_erase(struct vm_area_struct *vma, struct rb_root *root)
> {
> + vma_mark_locked(vma);
> /*
>* Note rb_erase_augmented is a fairly large inline function,
>* so make sure we instantiate it only once with our desired
>* augmented rbtree callbacks.
>*/
> rb_erase_augmented(&vma->vm_rb, root, &vma_gap_callbacks);
> + RB_CLEAR_NODE(&vma->vm_rb);
> }
>
> static __always_inline void vma_rb_erase_ignore(struct vm_area_struct *vma,
> diff --git a/mm/nommu.c b/mm/nommu.c
> index e819cbc21b39..ff9933e57501 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -622,6 +622,7 @@ static void delete_vma_from_mm(struct vm_area_struct *vma)
> struct mm_struct *mm = vma->vm_mm;
> struct task_struct *curr = current;
>
> + vma_mark_locked(vma);
> mm->map_count--;
> for (i = 0; i < VMACACHE_SIZE; i++) {
> /* if the vma is cached, invalidate the entire cache */
> @@ -644,6 +645,7 @@ static void delete_vma_from_mm(struct vm_area_struct *vma)
>
> /* remove from the MM's tree and list */
> rb_erase(&vma->vm_rb, &mm->mm_rb);
> + RB_CLEAR_NODE(&vma->vm_rb);
>
> __vma_unlink_list(mm, vma);
> }
Re: [RFC PATCH RESEND 07/28] kernel/fork: mark VMAs as locked before copying pages during fork
Le 09/09/2022 à 01:57, Suren Baghdasaryan a écrit :
> On Tue, Sep 6, 2022 at 7:38 AM Laurent Dufour wrote:
>>
>> Le 01/09/2022 à 19:34, Suren Baghdasaryan a écrit :
>>> Protect VMAs from concurrent page fault handler while performing
>>> copy_page_range for VMAs having VM_WIPEONFORK flag set.
>>
>> I'm wondering why is that necessary.
>> The copied mm is write locked, and the destination one is not reachable.
>> If any other readers are using the VMA, this is only for page fault handling.
>
> Correct, this is done to prevent page faulting in the VMA being
> duplicated. I assume we want to prevent the pages in that VMA from
> changing when we are calling copy_page_range(). Am I wrong?
If a page is faulted while copy_page_range() is in progress, the page may
not be backed on the child side (PTE lock should protect the copy, isn't it).
Is that a real problem? It will be backed later if accessed on the child side.
Maybe the per process pages accounting could be incorrect...
>
>> I should have miss something because I can't see any need to mark the lock
>> VMA here.
>>
>>> Signed-off-by: Suren Baghdasaryan
>>> ---
>>> kernel/fork.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/fork.c b/kernel/fork.c
>>> index bfab31ecd11e..1872ad549fed 100644
>>> --- a/kernel/fork.c
>>> +++ b/kernel/fork.c
>>> @@ -709,8 +709,10 @@ static __latent_entropy int dup_mmap(struct mm_struct
>>> *mm,
>>> rb_parent = &tmp->vm_rb;
>>>
>>> mm->map_count++;
>>> - if (!(tmp->vm_flags & VM_WIPEONFORK))
>>> + if (!(tmp->vm_flags & VM_WIPEONFORK)) {
>>> + vma_mark_locked(mpnt);
>>> retval = copy_page_range(tmp, mpnt);
>>> + }
>>>
>>> if (tmp->vm_ops && tmp->vm_ops->open)
>>> tmp->vm_ops->open(tmp);
>>
Re: [PATCH v1 02/19] powerpc/64e: Tie PPC_BOOK3E_64 to PPC_E500MC
Christophe Leroy writes: > Le 09/09/2022 à 07:50, Michael Ellerman a écrit : >> Hi Christophe, >> >> Thanks for trying to clean up this tangled mess. >> >> Christophe Leroy writes: >>> The only 64-bit Book3E CPUs we support is the e500mc. >> >> AFAIK the e500mc is 32-bit? > > Yes it seems. > >> >> We support e5500 and e6500 which are 64-bit Book3E. >> >> They're derivatives of the e500mc AIUI. >> >> So CONFIG_PPC_E500MC actually means e500mc *and later derivatives*. >> >> You can see that with eg: >> >> config SPE_POSSIBLE >> def_bool y >> depends on E500 && !PPC_E500MC >> >> Because e500mc dropped SPE, and so therefore e5500 and e6500 don't have >> it either. >> >> And eg: >> >> #ifdef CONFIG_PPC_E500MC >> _GLOBAL(__setup_cpu_e6500) >> mflrr6 >> >> >>> However our Kconfig allows configurating a kernel that has 64-bit >>> Book3E support, but no e500mc support enabled. Such a kernel >>> would never boot, it doesn't know about any CPUs. >> >> That is true. >> >>> To fix this, force e500mc to be selected whenever we are >>> building a 64-bit Book3E kernel. >> >> I think that's a reasonable fix, just it's important to differentiate >> between CONFIG_PPC_E500MC (the symbol) and e500mc (the CPU). > > Ok, I'll see how I can make it more explicit. > >> >>> And add a test to detect futur situations where cpu_specs is empty. >> future >>> >>> Signed-off-by: Christophe Leroy >>> --- >>> arch/powerpc/kernel/cputable.c | 2 ++ >>> arch/powerpc/platforms/Kconfig.cputype | 2 ++ >>> 2 files changed, 4 insertions(+) >>> >> .. >>> diff --git a/arch/powerpc/platforms/Kconfig.cputype >>> b/arch/powerpc/platforms/Kconfig.cputype >>> index 5185d942b455..19fd95a06352 100644 >>> --- a/arch/powerpc/platforms/Kconfig.cputype >>> +++ b/arch/powerpc/platforms/Kconfig.cputype >>> @@ -108,6 +108,8 @@ config PPC_BOOK3S_64 >>> config PPC_BOOK3E_64 >>> bool "Embedded processors" >>> select PPC_FSL_BOOK3E >>> + select E500 >>> + select PPC_E500MC >>> select PPC_FPU # Make it a choice ? >>> select PPC_SMP_MUXED_IPI >>> select PPC_DOORBELL >> >> I think that makes the select of PPC_E500MC below redundant: >> >> config PPC_QEMU_E500 >> bool "QEMU generic e500 platform" >> select DEFAULT_UIMAGE >> select E500 >> select PPC_E500MC if PPC64 > > That's handled in [v1,10/19] powerpc: Remove redundant selection of > E500 and E500MC. Should I reorder patches ? No that's fine the way it is, I hadn't looked at patch 10 when I replied. cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-6.0-5 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull another powerpc fix for 6.0: The following changes since commit 6cf07810e9ef8535d60160d13bf0fd05f2af38e7: powerpc/papr_scm: Ensure rc is always initialized in papr_scm_pmu_register() (2022-09-02 18:55:11 +1000) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.0-5 for you to fetch changes up to a66de5283e16602b74658289360505ceeb308c90: powerpc/pseries: Fix plpks crash on non-pseries (2022-09-08 10:45:57 +1000) - -- powerpc fixes for 6.0 #5 - Fix crashes on bare metal due to the new plkps driver trying to probe and call the hypervisor on non-pseries machines. Thanks to: Nathan Chancellor, Dan Horák. - -- Michael Ellerman (1): powerpc/pseries: Fix plpks crash on non-pseries arch/powerpc/platforms/pseries/plpks.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmMbMlsACgkQUevqPMjh pYDiuQ//YmIsWEcmoHw68cNBVxousox6fuzlAtAjUKPXuIk5ftZqEJV65CoPfp9/ MzQnW+BeLJ1ubMnkHxO5/ZNSly7t428EdvmO3fApOmrwbiUSTBhZKd4i7tmlgpoG qH9PtCekYjm9MHTBg1ksEvZiozQccw0QrXyNoZiaLSsw7nxRUvS2yDQlITHaiA8m a1HopFZiriouQDlVcm/0ubGCxhOEzB6HtTpiNsT0jrULN/w08Ffjc8auMLycfIJR 53XlfEP3ICd3+LzK0GYlp+IkPkPdJ0ZgWx+bpcq9ZvptYA0S0dW/tDKq4oqguKOu jk/WwU4ohbmamR/qWIdd+dwcMwQqaoW10Xa0uxthLSsS2d3x1gMU1rSjjQca4Xkq Bbm3hxWhTZwyYBQEhLPVlUoEzGCLY6JvXwnObypeTNcbGs8l548OIbnXaKT3FEps pvjLpzwI8hSljXSovXa1hY1h/ywZnFrSTb0KGtDhZ13zuv0Strhr2UJCndmPadFJ K48aQiDPQmcqXEwCgyEp5TmZhK7hZJlAFAJse/GvLdJTSuHUrszqoqG3pu4GQCWH Pryw1sMuyWqv/PgTYuoi1PJGn4BA4igCxqISuFnfsUZV+R9r1my+jzIcVkYkfXCm LOSE1azP2JS8bq9zQKfHYnuldM5As7dz6aNETouSOXqvQtpXMIA= =4YFO -END PGP SIGNATURE-
Re: [PATCH] powerpc/xive: fix repeated words in comments
On Wed, 31 Aug 2022 08:47:06 +0800, Jilin Yuan wrote: > Delete the redundant word 'set'. > > Applied to powerpc/next. [1/1] powerpc/xive: fix repeated words in comments https://git.kernel.org/powerpc/c/9b135eef0787813ad073aaeb9ff80ab57bc63e69 cheers
Re: [PATCH] powerpc/vas: fix repeated words in comments
On Wed, 31 Aug 2022 08:49:14 +0800, Jilin Yuan wrote: > Delete the redundant word 'the'. > > Applied to powerpc/next. [1/1] powerpc/vas: fix repeated words in comments https://git.kernel.org/powerpc/c/0d4bb5e45aa698f2f357b1424b842bebe13b1c8b cheers
Re: [PATCH v2] powerpc: embedded6xx: Fix refcount leak bugs
On Sat, 18 Jun 2022 12:10:42 +0800, Liang He wrote: > In xx_init_xx(), of_find_node_by_type() will return a node pointer > with refcount incremented. We should use of_node_put() when it is > not used anymore. > > Applied to powerpc/next. [1/1] powerpc: embedded6xx: Fix refcount leak bugs https://git.kernel.org/powerpc/c/6b2d17d514b105ecf486bdf011c444978e633085 cheers
Re: [PATCH] powerpc/mobility: fix repeated words in comments
On Wed, 31 Aug 2022 08:51:09 +0800, Jilin Yuan wrote: > Delete the redundant word 'the'. > > Applied to powerpc/next. [1/1] powerpc/mobility: fix repeated words in comments https://git.kernel.org/powerpc/c/4c73cadcdc64b53248bca85baa8a19e7384701ec cheers
Re: [PATCH] powerpc: sysdev: fsl_msi: Add missing of_node_put() for of_parse_phandle()
On Mon, 4 Jul 2022 22:52:33 +0800, Liang He wrote: > In fsl_setup_msi_irqs(), we should use of_node_put() for the > refernece 'np' returned by of_parse_phandle() which increases > the refcount. > > Applied to powerpc/next. [1/1] powerpc: sysdev: fsl_msi: Add missing of_node_put() for of_parse_phandle() https://git.kernel.org/powerpc/c/def435c04ee984a5f9ed2711b2bfe946936c6a21 cheers
Re: [PATCH v5] powerpc:85xx: Add missing of_node_put() in sgy_cst1000
On Fri, 17 Jun 2022 18:50:11 +0800, Liang He wrote: > In gpio_halt_probe(), of_find_matching_node() will return a node > pointer with refcount incremented. We should use of_node_put() in > fail path or when it is not used anymore. > > Applied to powerpc/next. [1/1] powerpc:85xx: Add missing of_node_put() in sgy_cst1000 https://git.kernel.org/powerpc/c/14b9e26c6c9a845c005087b9653459623a7d029b cheers
Re: [PATCH v3] powerpc/powernv: Fix refcount leak bugs
On Mon, 20 Jun 2022 21:25:53 +0800, Liang He wrote: > In these driver init functions, there are two kinds of errors: > > (1) missing of_put_node() for of_find_compatible_node()'s returned > pointer (refcount incremented) in fail path or when it is not > used anymore. > (2) missing of_put_node() for 'for_each_xxx' loop's break > > [...] Applied to powerpc/next. [1/1] powerpc/powernv: Fix refcount leak bugs https://git.kernel.org/powerpc/c/605c27f3802038e4623b6fd1bbfa021e1f65b5c4 cheers
Re: [PATCH v2] powerpc/sysdev: Fix refcount leak bugs
On Mon, 20 Jun 2022 21:02:21 +0800, Liang He wrote: > We need add corresponding of_node_put() to keep refcount balance > in sysdev. > > Applied to powerpc/next. [1/1] powerpc/sysdev: Fix refcount leak bugs https://git.kernel.org/powerpc/c/3d31adc47edb6d0cef122a41fba1b639db5d1c37 cheers
Re: [PATCH v2 1/2] powerpc: cell: cbe_regs: Fix refcount bugs
On Fri, 1 Jul 2022 22:49:48 +0800, Liang He wrote: > There are several bugs as following: > > (1) In cbe_get_be_node(), we should hold the reference returned by > of_find_xxx and of_get_xxx OF APIs and use it to call of_node_put > (2) In cbe_fill_regs_map(), we should same as above > (3) In cbe_regs_init(), during the iteration of for_each_node_by_type(), > the refcount of 'cpu' will be automatically increased and decreased. > However, there is a reference escaped out into 'map->cpu_node' and > we should properly handle it. > > [...] Applied to powerpc/next. [1/2] powerpc: cell: cbe_regs: Fix refcount bugs https://git.kernel.org/powerpc/c/ad4b323693abd221798a6479105d22c79605aa0f [2/2] powerpc: cell: iommu: Hold reference returned by of_find_node_by_name() https://git.kernel.org/powerpc/c/f4f8320b01677b467c768c43c1e1d10383a0e30d cheers
Re: [PATCH] powerpc/pseries: Hold reference and fix refcount leak bugs
On Tue, 21 Jun 2022 19:17:01 +0800, Liang He wrote: > In pseries_cpuhp_cache_use_count() and pseries_cpuhp_detach_nodes(), > we need carefully hold the reference returned by > of_find_next_cache_node() and use it to call of_node_put() to keep > refcount balance. > > Applied to powerpc/next. [1/1] powerpc/pseries: Hold reference and fix refcount leak bugs https://git.kernel.org/powerpc/c/6ec4836fa15a0ff02e3a382ad6b1920c728a8c95 cheers
Re: [PATCH] powerpc/powermac: Fix refcount leak bug
On Mon, 20 Jun 2022 23:05:18 +0800, Liang He wrote: > In smp_core99_setup(), we need to add of_node_put() to keep refcount > balance. > > Applied to powerpc/next. [1/1] powerpc/powermac: Fix refcount leak bug https://git.kernel.org/powerpc/c/a3a4c10aef88a80ba1b230a7bf63ea381cc5116e cheers
Re: [PATCH] powerpc: pseries: Fix refcount bug in ibmebus
On Sun, 19 Jun 2022 15:40:16 +0800, Liang He wrote: > In ibmebus_match_path(), we should use of_node_put() to keep > refcount balance. > > Applied to powerpc/next. [1/1] powerpc: pseries: Fix refcount bug in ibmebus https://git.kernel.org/powerpc/c/1c754b49c002a965004b6a96d158f7ce554eb977 cheers
Re: [PATCH] powerpc/powermac/udbg_scc: Fix refcount leak bug in udbg_scc_init()
On Sat, 16 Jul 2022 15:43:44 +0800, Liang He wrote: > During the iteration of for_each_child_of_node(), we need to call > of_node_put() for the old references stored in to 'ch_def' and 'ch_a' > as their refcounters have been increased in last iteration. > > Applied to powerpc/next. [1/1] powerpc/powermac/udbg_scc: Fix refcount leak bug in udbg_scc_init() https://git.kernel.org/powerpc/c/2378bf144b841df548161af49bf1ff393dc60d44 cheers
Re: [PATCH] powerpc/powermac/pfunc_base: Fix refcount leak bug in macio_gpio_init_one()
On Sat, 16 Jul 2022 15:31:11 +0800, Liang He wrote: > We should call of_node_put() for the reference 'gparent' escaped > out of the for_each_child_of_node() as it has increased the refcount. > > Applied to powerpc/next. [1/1] powerpc/powermac/pfunc_base: Fix refcount leak bug in macio_gpio_init_one() https://git.kernel.org/powerpc/c/11373c933db20f8b6fd2cad27712e683ac9785f0 cheers
Re: [PATCH] powerpc/powermac/low_i2c: Fix refcount leak bug in kw_i2c_probe()
On Sat, 16 Jul 2022 15:07:58 +0800, Liang He wrote: > We should call of_node_put() for the reference 'parent' returned by > of_get_parent() which has increased the refcount. > > Applied to powerpc/next. [1/1] powerpc/powermac/low_i2c: Fix refcount leak bug in kw_i2c_probe() https://git.kernel.org/powerpc/c/b3d6637bcc5d17caec56a76f6e430dcf444ef80e cheers
Re: [PATCH] powerpc: kernel: pci_dn: Add missing of_node_put() for of_get_xx API
On Fri, 1 Jul 2022 21:17:50 +0800, Liang He wrote: > In pci_add_device_node_info(), we should use of_node_put() for the > reference 'parent' returned by of_get_parent() to keep refcount > balance. > > Applied to powerpc/next. [1/1] powerpc: kernel: pci_dn: Add missing of_node_put() for of_get_xx API https://git.kernel.org/powerpc/c/110a1fcb6c4d55144d8179983a475f17a1d6f832 cheers
Re: [PATCH] powerpc/powermac/feature: Fix refcount leak bug
On Sat, 16 Jul 2022 14:54:12 +0800, Liang He wrote: > In probe_one_macio(), we should call of_node_put() for the refernece > 'node' escaped out of the for_each_node_by_name() which has increased > its refcount. While the 'node' will finally escaped into a global > reference, we should still call of_node_put() in fail path which will > stop global reference creation. > > > [...] Applied to powerpc/next. [1/1] powerpc/powermac/feature: Fix refcount leak bug https://git.kernel.org/powerpc/c/d36337ce950ce8c57a8e4f61593f923cceaf0dd7 cheers
Re: [PATCH] powerpc: kernel: Fix refcount bug in legacy_serial.c
On Sun, 19 Jun 2022 15:08:11 +0800, Liang He wrote: > In find_legacy_serial_ports(), of_find_node_by_path() will return > a node pointer with refcount incremented. We should use of_node_put() > when it is not used anymore. > > Applied to powerpc/next. [1/1] powerpc: kernel: Fix refcount bug in legacy_serial.c https://git.kernel.org/powerpc/c/d1aa2564f23b66ded10d870e7859e92075a3 cheers
Re: [PATCH] powerpc: platforms: 52xx: Fix refcount leak in media5200.c
On Thu, 16 Jun 2022 22:40:07 +0800, Liang He wrote: > In media5200_init_irq(), of_find_compatible_node() will return a > node pointer with refcount incremented. We should use of_node_put() > in fail path or when it is not used anymore. > > Don't worry about 'fpga_np==NULL' as of_node_put() can correctly > handle it. > > [...] Applied to powerpc/next. [1/1] powerpc: platforms: 52xx: Fix refcount leak in media5200.c https://git.kernel.org/powerpc/c/593d7b89c6a2bf7aea2324c94f10ef3c21308418 cheers
Re: [PATCH] powerpc: perf: Fix refcount leak bug in imc-pmu.c
On Sat, 18 Jun 2022 15:13:53 +0800, Liang He wrote: > In update_events_in_group(), of_find_node_by_phandle() will return > a node pointer with refcount incremented. We should use of_node_put() > in fail path or when it is not used anymore. > > Applied to powerpc/next. [1/1] powerpc: perf: Fix refcount leak bug in imc-pmu.c https://git.kernel.org/powerpc/c/0dd8d2c8066e672244975c171816fdd9dae87721 cheers
Re: [PATCH] powerpc: maple: Fix refcount leak bug in time.c
On Fri, 17 Jun 2022 20:40:45 +0800, Liang He wrote: > In maple_get_boot_time(), of_find_compatible_node() will return > a node pointer with refcount incremented. We should use of_node_put() > in fail path or when it is not used anymore. > > Applied to powerpc/next. [1/1] powerpc: maple: Fix refcount leak bug in time.c https://git.kernel.org/powerpc/c/23b1481898ee8704394cead67eae2634003f7ca8 cheers
Re: [PATCH] powerpc: kernel: pci-common: Fix refcount bug for 'phb->dn'
On Sat, 2 Jul 2022 10:29:36 +0800, Liang He wrote: > In pcibios_alloc_controller(), 'phb' is allocated and escaped into > global 'hose_list'. So we should call of_node_get() when a new reference > created into 'phb->dn'. And when phb is freed, we should call > of_node_put() on it. > > NOTE: This function is called in the iteration of for_each_xx in > chrp_find_bridges() function. If there is no of_node_get(), the object > maybe prematurely freed. > > [...] Applied to powerpc/next. [1/1] powerpc: kernel: pci-common: Fix refcount bug for 'phb->dn' https://git.kernel.org/powerpc/c/ce63c44b63cdae892107717ba10fdb6fb4fc6cdb cheers
Re: [PATCH] powerpc/fsl_pci: Remove of_node_put() when reference escaped out
On Wed, 20 Jul 2022 20:45:57 +0800, Liang He wrote: > In fsl_pci_assign_primary(), we should remove the of_node_put() > when breaking out of the for_each_matching_node() as the 'np' > is escaped out by global 'fsl_pci_primary'. > > Applied to powerpc/next. [1/1] powerpc/fsl_pci: Remove of_node_put() when reference escaped out https://git.kernel.org/powerpc/c/afa6a472a3d2a8dd477b285eeb67b3593546647b cheers
Re: [PATCH] powerpc/embedded6xx/ls_uart: Add missing of_node_put()
On Mon, 20 Jun 2022 14:59:04 +0800, Liang He wrote: > In ls_uarts_init(), we need to add a of_node_put() to keep refcount > balance. > > Applied to powerpc/next. [1/1] powerpc/embedded6xx/ls_uart: Add missing of_node_put() https://git.kernel.org/powerpc/c/cd772e659da0ad67f19f022f65449e14ebcf1284 cheers
Re: [PATCH] powerpc/cell: Fix refcount leak bugs
On Sun, 19 Jun 2022 15:23:35 +0800, Liang He wrote: > We should use of_node_put() for of_find_node_by_path() and > of_find_node_by_phandle() to keep refcount balance. > > Applied to powerpc/next. [1/1] powerpc/cell: Fix refcount leak bugs https://git.kernel.org/powerpc/c/d9e1c6104d87d4027133b28f5ccab8f999830acd cheers
Re: [PATCH] powerpc: 8xx: Fix refcount leak bug in tqm8xx_setup
On Sat, 18 Jun 2022 10:49:30 +0800, Liang He wrote: > In init_ioports(), of_find_node_by_name() will return a node pointer > with refcount incremented. We should use of_node_put() when it is not > used anymore. > > Applied to powerpc/next. [1/1] powerpc: 8xx: Fix refcount leak bug in tqm8xx_setup https://git.kernel.org/powerpc/c/edc17890ae8ee475b566079bea2e9ba83fec021d cheers
Re: [PATCH] powerpc: 85xx: Fix refcount bugs in ge_imp3a_pci_assign_primary()
On Fri, 1 Jul 2022 22:01:19 +0800, Liang He wrote: > for_each_node_by_type() will automatically increase and decrease > the refcount during the iteration. However, there is a reference > escaped into global 'fsl_pci_primary' and we need to handle it. > > Applied to powerpc/next. [1/1] powerpc: 85xx: Fix refcount bugs in ge_imp3a_pci_assign_primary() https://git.kernel.org/powerpc/c/a8b89c10e6052027061a447ff7436642310c8f20 cheers
Re: [PATCH] powerpc/83xx: Hold the reference returned by of_find_compatible_node
On Tue, 21 Jun 2022 16:09:32 +0800, Liang He wrote: > In mpc832x_spi_init(), we should hold the reference returned by > of_find_compatible_node() and use it to call of_node_put() for > refcount balance. > > Applied to powerpc/next. [1/1] powerpc/83xx: Hold the reference returned by of_find_compatible_node https://git.kernel.org/powerpc/c/24156df00dbbc673d9b2d31a336c3aba537d2c60 cheers
Re: [PATCH] powerpc/512x: Hold the reference returned by of_find_compatible_node
On Tue, 21 Jun 2022 16:03:49 +0800, Liang He wrote: > In mpc5121_clk_provide_migration_support(), we need to hold the > reference returned by of_find_compatible_node() and use it to call > of_node_put for refcount balance. > > Applied to powerpc/next. [1/1] powerpc/512x: Hold the reference returned by of_find_compatible_node https://git.kernel.org/powerpc/c/cc0dd82c18559184e009bef8d0353d008013a813 cheers
Re: [PATCH] powerpc: 44x: Add of_node_put() when break out from for_each
On Fri, 1 Jul 2022 21:31:26 +0800, Liang He wrote: > In ppc47x_init_irq(), we need to call of_node_put() when there is > a break during the iteration of for_each_node_with_property() which > will automatically increase and decrease the refcount. > > Applied to powerpc/next. [1/1] powerpc: 44x: Add of_node_put() when break out from for_each https://git.kernel.org/powerpc/c/9d86f0919544d8e422be2a1d562de1d6052d cheers
Re: [PATCH] macintosh: Add missing of_node_get() in do_attach()
On Wed, 22 Jun 2022 14:16:52 +0800, Liang He wrote: > We need a of_node_get() for of_find_compatible_node() to keep refcount > balance. > > Applied to powerpc/next. [1/1] macintosh: Add missing of_node_get() in do_attach() https://git.kernel.org/powerpc/c/d208d8c2cde513b94ae3b8b97663656079004555 cheers
Re: [PATCH] arch: powerpc: platforms: 85xx: Fix refcount leak bug in ksi8560.c
On Thu, 16 Jun 2022 21:29:22 +0800, Liang He wrote: > In ksi8560_setup_arch(), of_find_compatible_node() will return a > node pointer with refcount incremented. We should use of_node_put() > when it is not used anymore. > > Applied to powerpc/next. [1/1] arch: powerpc: platforms: 85xx: Fix refcount leak bug in ksi8560.c https://git.kernel.org/powerpc/c/64e696af167f612cd1ecba89edfeb2353ca59947 cheers
Re: [PATCH] arch: powerpc: platforms: 512x: Add missing of_node_put()
On Wed, 15 Jun 2022 22:37:03 +0800, Liang He wrote: > In mpc5121_clk_init(), of_find_compatible_node() will return a > node pointer with refcount incremented. We should use of_node_put() > when it is not used anymore. > > Applied to powerpc/next. [1/1] arch: powerpc: platforms: 512x: Add missing of_node_put() https://git.kernel.org/powerpc/c/06f48f5cb5df2299f5e4b42e9dda1858bf172bcb cheers
Re: [PATCH] powerpc/pasemi: Use strscpy instead of strlcpy
On Sat, 27 Aug 2022 16:39:46 +1000, Russell Currey wrote: > find_i2c_driver() contained the last usage of strlcpy() in arch/powerpc. > The return value was used to check if strlen(src) >= n, for which > strscpy() returns -E2BIG. > > Applied to powerpc/next. [1/1] powerpc/pasemi: Use strscpy instead of strlcpy https://git.kernel.org/powerpc/c/245685495bff35062a394f5cdbd32b237dc596a5 cheers
Re: [PATCH v2 0/4] powerpc: stolen time accounting for VIRT_CPU_ACCOUNTING_GEN
On Fri, 2 Sep 2022 18:53:12 +1000, Nicholas Piggin wrote: > pseries provides stolen time accounting when VIRT_CPU_ACCOUNTING_NATIVE > is selected, but not when VIRT_CPU_ACCOUNTING_GEN is. We like GEN > because it's less code in arch/powerpc, allows full nohz, and distros > have moved to it, so this series adds stolen time accounting for GEN, > and moves our pseries configs over to it. > > Thanks, > Nick > > [...] Applied to powerpc/next. [1/4] powerpc/pseries: Add wait interval counter definitions to struct lppaca https://git.kernel.org/powerpc/c/a8933c8d55c37f4d5eb617b4bdb72bb88681 [2/4] powerpc/pseries: Implement CONFIG_PARAVIRT_TIME_ACCOUNTING https://git.kernel.org/powerpc/c/0e8a63132800dd8ae5fcb19113f79bea43ea18d9 [3/4] powerpc/64: Remove PPC64 special case for cputime accounting default https://git.kernel.org/powerpc/c/02382aff72357727f9eee5107fd32c6cd070f1d6 [4/4] powerpc/pseries: Move dtl scanning and steal time accounting to pseries platform https://git.kernel.org/powerpc/c/6ba5aa541aaa079c0ca888f7fe564b2035d5ca0a cheers
Re: [PATCH] powerpc/math_emu/efp: Include module.h
On Wed, 31 Aug 2022 08:20:15 -0700, Nathan Chancellor wrote: > When building with a recent version of clang, there are a couple of > errors around the call to module_init(): > > arch/powerpc/math-emu/math_efp.c:927:1: error: type specifier missing, > defaults to 'int'; ISO C99 and later do not support implicit int > [-Wimplicit-int] > module_init(spe_mathemu_init); > ^ > int > arch/powerpc/math-emu/math_efp.c:927:13: error: a parameter list without > types is only allowed in a function definition > module_init(spe_mathemu_init); > ^ > 2 errors generated. > > [...] Applied to powerpc/next. [1/1] powerpc/math_emu/efp: Include module.h https://git.kernel.org/powerpc/c/cfe0d370e0788625ce0df3239aad07a2506c1796 cheers
Re: [PATCH] selftests/powerpc: Skip 4PB test on 4K PAGE_SIZE systems
On Thu, 1 Sep 2022 12:02:15 +1000, Michael Ellerman wrote: > Systems using the hash MMU with a 4K page size don't support 4PB address > space, so skip the test because the bug it tests for can't be triggered. > > Applied to powerpc/next. [1/1] selftests/powerpc: Skip 4PB test on 4K PAGE_SIZE systems https://git.kernel.org/powerpc/c/501fe299826ead2cfa2046b5c244e36de254ec6a cheers
Re: [PATCH] powerpc/configs: Properly enable PAPR_SCM in pseries_defconfig
On Thu, 1 Sep 2022 11:42:53 +1000, Michael Ellerman wrote: > My commit to add PAPR_SCM to pseries_defconfig failed to add the > required dependencies, meaning the driver doesn't get built. > > Add the required LIBNVDIMM=m. > > Applied to powerpc/next. [1/1] powerpc/configs: Properly enable PAPR_SCM in pseries_defconfig https://git.kernel.org/powerpc/c/aa398d88aea4ec863bd7aea35d5035a37096dc59 cheers
Re: [PATCH 1/3] powerpc/32: Drop a stale comment about reservation of gigantic pages
On Wed, 31 Aug 2022 11:32:07 +0200, Christophe Leroy wrote:
> A comment about the reservation of gigantic pages was left in MMU_init()
> after commit 79cc38ded1e1 ("powerpc/mm/hugetlb: Add support for
> reserving gigantic huge pages via kernel command line")
>
> Remove it.
>
>
> [...]
Applied to powerpc/next.
[1/3] powerpc/32: Drop a stale comment about reservation of gigantic pages
https://git.kernel.org/powerpc/c/fc06755e25628ce215e9f75c1207250242dadf42
[2/3] powerpc/32: Allow fragmented physical memory
https://git.kernel.org/powerpc/c/b0e0d68b1c52cb2c46e513011fdd53815cffefb7
[3/3] powerpc/32: Remove wii_memory_fixups()
https://git.kernel.org/powerpc/c/0115953dcebe8858ba3d9997ba48328ebdca593f
cheers
Re: [PATCH v2] powerpc/vdso: link with -z noexecstack
On Fri, 2 Sep 2022 17:25:24 +0200, Christophe Leroy wrote: > With recent binutils, the following warning appears: > > VDSO32L arch/powerpc/kernel/vdso/vdso32.so.dbg > /opt/gcc-12.2.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/12.2.0/../../../../powerpc64-linux/bin/ld: > warning: arch/powerpc/kernel/vdso/getcpu-32.o: missing .note.GNU-stack > section implies executable stack > /opt/gcc-12.2.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/12.2.0/../../../../powerpc64-linux/bin/ld: > NOTE: This behaviour is deprecated and will be removed in a future version > of the linker > > To avoid that, explicitely tell the linker we don't > want executable stack. > > [...] Applied to powerpc/next. [1/1] powerpc/vdso: link with -z noexecstack https://git.kernel.org/powerpc/c/1d53c0192b15f42129a3dbbbfa05637bcf781a3e cheers
Re: [PATCH v2 1/2] powerpc/math_emu/efp: Include module.h
On Fri, 2 Sep 2022 18:00:08 +0200, Christophe Leroy wrote: > From: Nathan Chancellor > > When building with a recent version of clang, there are a couple of > errors around the call to module_init(): > > arch/powerpc/math-emu/math_efp.c:927:1: error: type specifier missing, > defaults to 'int'; ISO C99 and later do not support implicit int > [-Wimplicit-int] > module_init(spe_mathemu_init); > ^ > int > arch/powerpc/math-emu/math_efp.c:927:13: error: a parameter list without > types is only allowed in a function definition > module_init(spe_mathemu_init); > ^ > 2 errors generated. > > [...] Applied to powerpc/next. [1/2] powerpc/math_emu/efp: Include module.h https://git.kernel.org/powerpc/c/cfe0d370e0788625ce0df3239aad07a2506c1796 [2/2] powerpc/math-emu: Remove -w build flag and fix warnings https://git.kernel.org/powerpc/c/7245fc5bb7a966852d5bd7779d1f5855530b461a cheers
Re: [PATCH] powerpc/math-emu: Inhibit W=1 warnings
On Wed, 7 Sep 2022 08:12:54 +0200, Christophe Leroy wrote: > When building with W=1 you get: > > arch/powerpc/math-emu/fre.c:6:5: error: no previous prototype for 'fre' > [-Werror=missing-prototypes] > arch/powerpc/math-emu/fsqrt.c:11:1: error: no previous prototype for > 'fsqrt' [-Werror=missing-prototypes] > arch/powerpc/math-emu/fsqrts.c:12:1: error: no previous prototype for > 'fsqrts' [-Werror=missing-prototypes] > > [...] Applied to powerpc/next. [1/1] powerpc/math-emu: Inhibit W=1 warnings https://git.kernel.org/powerpc/c/78c73c80fd860d5b3471d8eaa2778a105a56f6ab cheers
Re: [PATCH v2] powerpc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency
On Fri, Sep 9, 2022, at 1:19 PM, Christophe Leroy wrote:
> Le 09/09/2022 à 13:09, Arnd Bergmann a écrit :
>> On Fri, Sep 9, 2022, at 11:03 AM, Lukas Bulwahn wrote:
>>
>> I don't see a single powerpc machine that creates a
>> name="pata_platform" platform_device. I suspect this was
>> only needed bwfore 2007 commit 9cd55be4d223 ("[POWERPC] pasemi:
>> Move electra-ide to pata_of_platform"), so the "|| PPC"
>> bit should just get removed without adding the HAVE_PATA_PLATFORM
>> bit.
>
> But that was added in 2008 by commit 61f7162117d4 ("libata:
> pata_of_platform: OF-Platform PATA device driver")
Ah, I see. In that case, I think we should probably just always
allow PATA_OF_PLATFORM to be enabled regardless of
HAVE_PATA_PLATFORM, something like
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 1c9f4fb2595d..c93d97455744 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -1102,8 +1102,7 @@ config PATA_PCMCIA
If unsure, say N.
config PATA_PLATFORM
- tristate "Generic platform device PATA support"
- depends on EXPERT || PPC || HAVE_PATA_PLATFORM
+ tristate "Generic platform device PATA support" if EXPERT ||
HAVE_PATA_PLATFORM
help
This option enables support for generic directly connected ATA
devices commonly found on embedded systems.
@@ -1112,7 +,8 @@ config PATA_PLATFORM
config PATA_OF_PLATFORM
tristate "OpenFirmware platform device PATA support"
- depends on PATA_PLATFORM && OF
+ depends on OF
+ select PATA_PLATFORM
help
This option enables support for generic directly connected ATA
devices commonly found on embedded systems with OpenFirmware
and then also drop the "select HAVE_PATA_PLATFORM" from
arm64 and arm/versatile.
Or we can go one step further, and either split out the
'pata_platform_driver' into a separate file from
'__pata_platform_probe', or merge pata_of_platform.c
back into pata_platform.c.
Arnd
Re: [PATCH v2] powerpc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency
Le 09/09/2022 à 13:09, Arnd Bergmann a écrit :
> On Fri, Sep 9, 2022, at 11:03 AM, Lukas Bulwahn wrote:
>> Commit cc18e0fea790 ("LIBATA: Add HAVE_PATA_PLATFORM to select
>> PATA_PLATFORM driver") introduces config HAVE_PATA_PLATFORM, and expects
>> that all architectures simply select this config when the architecture
>> supports using the PATA_PLATFORM driver.
>>
>> This is properly implemented already for all architectures except for the
>> powerpc architecture. Implement this for powerpc now.
>>
>> Adjust the config of the powerpc architecture to use the config
>> HAVE_PATA_PLATFORM and simplify the config PATA_PLATFORM to not mention
>> any specific architecture anymore.
>>
>> Signed-off-by: Lukas Bulwahn
>> ---
>> arch/powerpc/Kconfig | 1 +
>> drivers/ata/Kconfig | 2 +-
>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 39d71d7701bd..2575e21b6e6b 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -237,6 +237,7 @@ config PPC
>> select HAVE_MOD_ARCH_SPECIFIC
>> select HAVE_NMI if PERF_EVENTS || (PPC64 &&
>> PPC_BOOK3S)
>> select HAVE_OPTPROBES
>> +select HAVE_PATA_PLATFORM
>> select HAVE_PERF_EVENTS
>> select HAVE_PERF_EVENTS_NMI if PPC64
>> select HAVE_PERF_REGS
>
> I don't see a single powerpc machine that creates a
> name="pata_platform" platform_device. I suspect this was
> only needed bwfore 2007 commit 9cd55be4d223 ("[POWERPC] pasemi:
> Move electra-ide to pata_of_platform"), so the "|| PPC"
> bit should just get removed without adding the HAVE_PATA_PLATFORM
> bit.
But that was added in 2008 by commit 61f7162117d4 ("libata:
pata_of_platform: OF-Platform PATA device driver")
Re: [PATCH v2] powerpc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency
On Fri, Sep 9, 2022, at 11:03 AM, Lukas Bulwahn wrote:
> Commit cc18e0fea790 ("LIBATA: Add HAVE_PATA_PLATFORM to select
> PATA_PLATFORM driver") introduces config HAVE_PATA_PLATFORM, and expects
> that all architectures simply select this config when the architecture
> supports using the PATA_PLATFORM driver.
>
> This is properly implemented already for all architectures except for the
> powerpc architecture. Implement this for powerpc now.
>
> Adjust the config of the powerpc architecture to use the config
> HAVE_PATA_PLATFORM and simplify the config PATA_PLATFORM to not mention
> any specific architecture anymore.
>
> Signed-off-by: Lukas Bulwahn
> ---
> arch/powerpc/Kconfig | 1 +
> drivers/ata/Kconfig | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 39d71d7701bd..2575e21b6e6b 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -237,6 +237,7 @@ config PPC
> select HAVE_MOD_ARCH_SPECIFIC
> select HAVE_NMI if PERF_EVENTS || (PPC64 &&
> PPC_BOOK3S)
> select HAVE_OPTPROBES
> + select HAVE_PATA_PLATFORM
> select HAVE_PERF_EVENTS
> select HAVE_PERF_EVENTS_NMI if PPC64
> select HAVE_PERF_REGS
I don't see a single powerpc machine that creates a
name="pata_platform" platform_device. I suspect this was
only needed bwfore 2007 commit 9cd55be4d223 ("[POWERPC] pasemi:
Move electra-ide to pata_of_platform"), so the "|| PPC"
bit should just get removed without adding the HAVE_PATA_PLATFORM
bit.
Arnd
Re: [PATCH v2] powerpc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency
On Fri, Sep 9, 2022 at 1:09 PM Arnd Bergmann wrote:
>
> On Fri, Sep 9, 2022, at 11:03 AM, Lukas Bulwahn wrote:
> > Commit cc18e0fea790 ("LIBATA: Add HAVE_PATA_PLATFORM to select
> > PATA_PLATFORM driver") introduces config HAVE_PATA_PLATFORM, and expects
> > that all architectures simply select this config when the architecture
> > supports using the PATA_PLATFORM driver.
> >
> > This is properly implemented already for all architectures except for the
> > powerpc architecture. Implement this for powerpc now.
> >
> > Adjust the config of the powerpc architecture to use the config
> > HAVE_PATA_PLATFORM and simplify the config PATA_PLATFORM to not mention
> > any specific architecture anymore.
> >
> > Signed-off-by: Lukas Bulwahn
> > ---
> > arch/powerpc/Kconfig | 1 +
> > drivers/ata/Kconfig | 2 +-
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 39d71d7701bd..2575e21b6e6b 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -237,6 +237,7 @@ config PPC
> > select HAVE_MOD_ARCH_SPECIFIC
> > select HAVE_NMI if PERF_EVENTS || (PPC64 &&
> > PPC_BOOK3S)
> > select HAVE_OPTPROBES
> > + select HAVE_PATA_PLATFORM
> > select HAVE_PERF_EVENTS
> > select HAVE_PERF_EVENTS_NMI if PPC64
> > select HAVE_PERF_REGS
>
> I don't see a single powerpc machine that creates a
> name="pata_platform" platform_device. I suspect this was
> only needed bwfore 2007 commit 9cd55be4d223 ("[POWERPC] pasemi:
> Move electra-ide to pata_of_platform"), so the "|| PPC"
> bit should just get removed without adding the HAVE_PATA_PLATFORM
> bit.
>
Thanks for your investigation. I will send a corresponding patch v3.
Lukas
Re: [PATCH] powerpc/pseries: Fix plpks crash on non-pseries
On Wed, 7 Sep 2022 16:50:38 +1000, Michael Ellerman wrote: > As reported[1] by Nathan, the recently added plpks driver will crash if > it's built into the kernel and booted on a non-pseries machine, eg > powernv: > > kernel BUG at arch/powerpc/kernel/syscall.c:39! > Oops: Exception in kernel mode, sig: 5 [#1] > LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV > ... > NIP system_call_exception+0x90/0x3d0 > LR system_call_common+0xec/0x250 > Call Trace: > 0xc35c3e10 (unreliable) > system_call_common+0xec/0x250 > --- interrupt: c00 at plpar_hcall+0x38/0x60 > NIP: c00e4300 LR: c202945c CTR: > REGS: c35c3e80 TRAP: 0c00 Not tainted (6.0.0-rc4) > MSR: 92009033 CR: 28000284 XER: > > ... > NIP plpar_hcall+0x38/0x60 > LR pseries_plpks_init+0x64/0x23c > --- interrupt: c00 > > [...] Applied to powerpc/fixes. [1/1] powerpc/pseries: Fix plpks crash on non-pseries https://git.kernel.org/powerpc/c/a66de5283e16602b74658289360505ceeb308c90 cheers
Re: [RFC PATCH RESEND 13/28] mm: conditionally mark VMA as locked in free_pgtables and unmap_page_range
Le 01/09/2022 à 19:35, Suren Baghdasaryan a écrit :
> free_pgtables and unmap_page_range functions can be called with mmap_lock
> held for write (e.g. in mmap_region), held for read (e.g in
> madvise_pageout) or not held at all (e.g in madvise_remove might
> drop mmap_lock before calling vfs_fallocate, which ends up calling
> unmap_page_range).
> Provide free_pgtables and unmap_page_range with additional argument
> indicating whether to mark the VMA as locked or not based on the usage.
> The parameter is set based on whether mmap_lock is held in write mode
> during the call. This ensures no change in behavior between mmap_lock
> and per-vma locks.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> include/linux/mm.h | 2 +-
> mm/internal.h | 4 ++--
> mm/memory.c| 32 +---
> mm/mmap.c | 17 +
> mm/oom_kill.c | 3 ++-
> 5 files changed, 35 insertions(+), 23 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 476bf936c5f0..dc72be923e5b 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1874,7 +1874,7 @@ void zap_vma_ptes(struct vm_area_struct *vma, unsigned
> long address,
> void zap_page_range(struct vm_area_struct *vma, unsigned long address,
> unsigned long size);
> void unmap_vmas(struct mmu_gather *tlb, struct vm_area_struct *start_vma,
> - unsigned long start, unsigned long end);
> + unsigned long start, unsigned long end, bool lock_vma);
>
> struct mmu_notifier_range;
>
> diff --git a/mm/internal.h b/mm/internal.h
> index 785409805ed7..e6c0f999e0cb 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -85,14 +85,14 @@ bool __folio_end_writeback(struct folio *folio);
> void deactivate_file_folio(struct folio *folio);
>
> void free_pgtables(struct mmu_gather *tlb, struct vm_area_struct *start_vma,
> - unsigned long floor, unsigned long ceiling);
> + unsigned long floor, unsigned long ceiling, bool lock_vma);
> void pmd_install(struct mm_struct *mm, pmd_t *pmd, pgtable_t *pte);
>
> struct zap_details;
> void unmap_page_range(struct mmu_gather *tlb,
>struct vm_area_struct *vma,
>unsigned long addr, unsigned long end,
> - struct zap_details *details);
> + struct zap_details *details, bool lock_vma);
>
> void page_cache_ra_order(struct readahead_control *, struct file_ra_state *,
> unsigned int order);
> diff --git a/mm/memory.c b/mm/memory.c
> index 4ba73f5aa8bb..9ac9944e8c62 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -403,7 +403,7 @@ void free_pgd_range(struct mmu_gather *tlb,
> }
>
> void free_pgtables(struct mmu_gather *tlb, struct vm_area_struct *vma,
> - unsigned long floor, unsigned long ceiling)
> + unsigned long floor, unsigned long ceiling, bool lock_vma)
> {
> while (vma) {
> struct vm_area_struct *next = vma->vm_next;
> @@ -413,6 +413,8 @@ void free_pgtables(struct mmu_gather *tlb, struct
> vm_area_struct *vma,
>* Hide vma from rmap and truncate_pagecache before freeing
>* pgtables
>*/
> + if (lock_vma)
> + vma_mark_locked(vma);
> unlink_anon_vmas(vma);
> unlink_file_vma(vma);
>
> @@ -427,6 +429,8 @@ void free_pgtables(struct mmu_gather *tlb, struct
> vm_area_struct *vma,
> && !is_vm_hugetlb_page(next)) {
> vma = next;
> next = vma->vm_next;
> + if (lock_vma)
> + vma_mark_locked(vma);
> unlink_anon_vmas(vma);
> unlink_file_vma(vma);
> }
> @@ -1631,12 +1635,16 @@ static inline unsigned long zap_p4d_range(struct
> mmu_gather *tlb,
> void unmap_page_range(struct mmu_gather *tlb,
>struct vm_area_struct *vma,
>unsigned long addr, unsigned long end,
> - struct zap_details *details)
> + struct zap_details *details,
> + bool lock_vma)
> {
> pgd_t *pgd;
> unsigned long next;
>
> BUG_ON(addr >= end);
> + if (lock_vma)
> + vma_mark_locked(vma);
I'm wondering if that is really needed here.
The following processing is only dealing with the page table entries.
Today, if that could be called without holding the mmap_lock, that should
be safe to not mark the VMA locked (indeed the VMA itself is not impacted).
Thus unmap_single_vma() below no need to be touched, and its callers.
In the case a locking is required, I think there is a real potential issue
in the current kernel.
> +
> tlb_start_vma(tlb, vma);
> pgd = pg
Re: [PATCH 6/6] init/Kconfig: remove confusing config EMBEDDED
> > init/Kconfig | 8 > > 1 file changed, 8 deletions(-) > > > > diff --git a/init/Kconfig b/init/Kconfig > > index 9e3fd79b089c..d7429e0b8cae 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -1818,14 +1818,6 @@ config DEBUG_RSEQ > > > > If unsure, say N. > > > > -config EMBEDDED > > - bool "Embedded system" > > - select EXPERT > > - help > > - This option should be enabled if compiling the kernel for > > - an embedded system so certain expert options are available > > - for configuration. > > - > > config HAVE_PERF_EVENTS > > bool > > help > > That's fine, but what happens to existing defconfigs then ? > > $ git grep -w CONFIG_EMBEDDED arch/powerpc/ > arch/powerpc/configs/40x/klondike_defconfig:CONFIG_EMBEDDED=y > arch/powerpc/configs/44x/fsp2_defconfig:CONFIG_EMBEDDED=y > arch/powerpc/configs/52xx/tqm5200_defconfig:CONFIG_EMBEDDED=y > arch/powerpc/configs/mgcoge_defconfig:CONFIG_EMBEDDED=y > arch/powerpc/configs/microwatt_defconfig:CONFIG_EMBEDDED=y > arch/powerpc/configs/ps3_defconfig:CONFIG_EMBEDDED=y > > They need to get converted to selecting CONFIG_EXPERT instead. > > And that needs to be done before you remove CONFIG_EMBEDDED. > Agree. Let us get the first five patches included. Then adjust the configs for all architectures and then delete the CONFIG_EMBEDDED. Lukas
Re: [PATCH] ppc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency
On Fri, Sep 9, 2022 at 11:04 AM Lukas Bulwahn wrote:
>
> Commit cc18e0fea790 ("LIBATA: Add HAVE_PATA_PLATFORM to select
> PATA_PLATFORM driver") introduces config HAVE_PATA_PLATFORM, and expects
> that all architectures simply select this config when the architecture
> supports using the PATA_PLATFORM driver.
>
> This is properly implemented already for all architectures except for the
> powerpc architecture. Implement this for powerpc now.
>
> Adjust the config of the powerpc architecture to use the config
> HAVE_PATA_PLATFORM and simplify the config PATA_PLATFORM to not mention
> any specific architecture anymore.
>
> Signed-off-by: Lukas Bulwahn
Please ignore this patch and pick:
https://lore.kernel.org/linuxppc-dev/20220909090343.21886-1-lukas.bulw...@gmail.com/
Lukas
> ---
> arch/powerpc/Kconfig | 1 +
> drivers/ata/Kconfig | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 39d71d7701bd..2575e21b6e6b 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -237,6 +237,7 @@ config PPC
> select HAVE_MOD_ARCH_SPECIFIC
> select HAVE_NMI if PERF_EVENTS || (PPC64 &&
> PPC_BOOK3S)
> select HAVE_OPTPROBES
> + select HAVE_PATA_PLATFORM
> select HAVE_PERF_EVENTS
> select HAVE_PERF_EVENTS_NMI if PPC64
> select HAVE_PERF_REGS
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index 1c9f4fb2595d..ed3547165528 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -1103,7 +1103,7 @@ config PATA_PCMCIA
>
> config PATA_PLATFORM
> tristate "Generic platform device PATA support"
> - depends on EXPERT || PPC || HAVE_PATA_PLATFORM
> + depends on EXPERT || HAVE_PATA_PLATFORM
> help
> This option enables support for generic directly connected ATA
> devices commonly found on embedded systems.
> --
> 2.17.1
>
Re: [PATCH] ppc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency
On Fri, Sep 9, 2022 at 10:55 AM Lukas Bulwahn wrote:
>
> Commit cc18e0fea790 ("LIBATA: Add HAVE_PATA_PLATFORM to select
> PATA_PLATFORM driver") introduces config HAVE_PATA_PLATFORM, and expects
> that all architectures simply select this config when the architecture
> supports using the PATA_PLATFORM driver.
>
> This is properly implemented already for all architectures except for the
> powerpc architecture. Implement this for powerpc now.
>
> Adjust the config of the powerpc architecture to use the config
> HAVE_PATA_PLATFORM and simplify the config PATA_PLATFORM to not mention
> any specific architecture anymore.
>
> Signed-off-by: Lukas Bulwahn
Please ignore this patch and pick:
https://lore.kernel.org/linuxppc-dev/20220909090343.21886-1-lukas.bulw...@gmail.com/
Lukas
> ---
> arch/powerpc/Kconfig | 1 +
> drivers/ata/Kconfig | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 39d71d7701bd..2575e21b6e6b 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -237,6 +237,7 @@ config PPC
> select HAVE_MOD_ARCH_SPECIFIC
> select HAVE_NMI if PERF_EVENTS || (PPC64 &&
> PPC_BOOK3S)
> select HAVE_OPTPROBES
> + select HAVE_PATA_PLATFORM
> select HAVE_PERF_EVENTS
> select HAVE_PERF_EVENTS_NMI if PPC64
> select HAVE_PERF_REGS
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index 1c9f4fb2595d..ed3547165528 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -1103,7 +1103,7 @@ config PATA_PCMCIA
>
> config PATA_PLATFORM
> tristate "Generic platform device PATA support"
> - depends on EXPERT || PPC || HAVE_PATA_PLATFORM
> + depends on EXPERT || HAVE_PATA_PLATFORM
> help
> This option enables support for generic directly connected ATA
> devices commonly found on embedded systems.
> --
> 2.17.1
>
Re: [PATCH linux-next] crypto: nx - Remove the unneeded result variable
On Fri, Sep 02, 2022 at 07:30:55AM +, cgel@gmail.com wrote: > From: ye xingchen > > Return the value set_msg_len() directly instead of storing it in another > redundant variable. > > Reported-by: Zeal Robot > Signed-off-by: ye xingchen > --- > drivers/crypto/nx/nx-aes-ccm.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 6/6] init/Kconfig: remove confusing config EMBEDDED
+ linuxppc-dev
Le 08/09/2022 à 12:43, Lukas Bulwahn a écrit :
> Commit 6a108a14fa35 ("kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT")
> introduces CONFIG_EXPERT to carry the previous intent of CONFIG_EMBEDDED
> and just gives that intent a much better name. That has been clearly a good
> and long overdue renaming, and it is clearly an improvement to the kernel
> build configuration that has shown to help managing the kernel build
> configuration in the last decade.
>
> However, rather than bravely and radically just deleting CONFIG_EMBEDDED,
> this commit gives CONFIG_EMBEDDED a new intended semantics, but keeps it
> open for future contributors to implement that intended semantics:
>
> A new CONFIG_EMBEDDED option is added that automatically selects
> CONFIG_EXPERT when enabled and can be used in the future to isolate
> options that should only be considered for embedded systems (RISC
> architectures, SLOB, etc).
>
> Since then, this CONFIG_EMBEDDED implicitly had two purposes:
>
>- It can make even more options visible beyond what CONFIG_EXPERT makes
> visible. In other words, it may introduce another level of enabling the
> visibility of configuration options: always visible, visible with
> CONFIG_EXPERT and visible with CONFIG_EMBEDDED.
>
>- Set certain default values of some configurations differently,
> following the assumption that configuring a kernel build for an
> embedded system generally starts with a different set of default values
> compared to kernel builds for all other kind of systems.
>
> Considering the first purpose, at the point in time where CONFIG_EMBEDDED
> was renamed to CONFIG_EXPERT, CONFIG_EXPERT already made 130 more options
> become visible throughout all different menus for the kernel configuration.
> Over the last decade, this has gradually increased, so that currently, with
> CONFIG_EXPERT, roughly 170 more options become visible throughout all
> different menus for the kernel configuration. In comparison, currently with
> CONFIG_EMBEDDED enabled, just seven more options are visible, one in x86,
> one in arm, and five for the ChipIdea Highspeed Dual Role Controller.
>
> As the numbers suggest, these two levels of enabling the visibility of even
> more configuration options---beyond what CONFIG_EXPERT enables---never
> evolved to a good solution in the last decade. In other words, this
> additional level of visibility of configuration option with CONFIG_EMBEDDED
> compared to CONFIG_EXPERT has since its introduction never become really
> valuable. It requires quite some investigation to actually understand what
> is additionally visible and it does not differ significantly in complexity
> compared to just enabling CONFIG_EXPERT. This CONFIG_EMBEDDED---or any
> other config to show more detailed options beyond CONFIG_EXPERT---is
> unlikely to be valuable unless somebody puts significant effort in
> identifying how such visibility options can be properly split and creating
> clear criteria, when some config option is visible with CONFIG_EXPERT and
> when some config option is visible only with some further option enabled
> beyond CONFIG_EXPERT, such as CONFIG_EMBEDDED attempted to do. For now, it
> is much more reasonable to simply make those additional seven options that
> visible with CONFIG_EMBEDDED, visible with CONFIG_EXPERT, and then remove
> CONFIG_EMBEDDED. If anyone spends significant effort in structuring the
> visibility of config options, they may re-introduce suitable new config
> options simply as they see fit.
>
> Hence, all uses of CONFIG_EMBEDDED have been replaced with CONFIG_EXPERT.
>
> Considering the second purpose, note that already probably arguing that a
> kernel build for an embedded system would choose some values differently is
> already tricky: the set of embedded systems with Linux kernels is already
> quite diverse. Many embedded system have powerful CPUs and it would not be
> clear that all embedded systems just optimize towards one specific aspect,
> e.g., a smaller kernel image size. So, it is unclear if starting with "one
> set of default configuration" that is induced by CONFIG_EMBEDDED is a good
> offer for developers configuring their kernels.
>
> Also, the differences of needed user-space features in an embedded system
> compared to a non-embedded system are probably difficult or even impossible
> to name in some generic way.
>
> So it is not surprising that in the last decade hardly anyone has
> contributed changes to make something default differently in case of
> CONFIG_EMBEDDED=y.
>
> In v6.0-rc4, SECRETMEM is the only config switched off if
> CONFIG_EMBEDDED=y. That one use was removed as well, SECRETMEM was made
> configurable at build time by experts using menuconfig instead.
>
> As there are no further uses of CONFIG_EMBEDDED and CONFIG_EMBEDDED never
> lived up to its intended purpose defined above, simply delete this
> confusing CONFIG_EMBEDDED.
>
> Signe
[PATCH] ppc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency
Commit cc18e0fea790 ("LIBATA: Add HAVE_PATA_PLATFORM to select
PATA_PLATFORM driver") introduces config HAVE_PATA_PLATFORM, and expects
that all architectures simply select this config when the architecture
supports using the PATA_PLATFORM driver.
This is properly implemented already for all architectures except for the
powerpc architecture. Implement this for powerpc now.
Adjust the config of the powerpc architecture to use the config
HAVE_PATA_PLATFORM and simplify the config PATA_PLATFORM to not mention
any specific architecture anymore.
Signed-off-by: Lukas Bulwahn
---
arch/powerpc/Kconfig | 1 +
drivers/ata/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 39d71d7701bd..2575e21b6e6b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -237,6 +237,7 @@ config PPC
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI if PERF_EVENTS || (PPC64 &&
PPC_BOOK3S)
select HAVE_OPTPROBES
+ select HAVE_PATA_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
select HAVE_PERF_REGS
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 1c9f4fb2595d..ed3547165528 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -1103,7 +1103,7 @@ config PATA_PCMCIA
config PATA_PLATFORM
tristate "Generic platform device PATA support"
- depends on EXPERT || PPC || HAVE_PATA_PLATFORM
+ depends on EXPERT || HAVE_PATA_PLATFORM
help
This option enables support for generic directly connected ATA
devices commonly found on embedded systems.
--
2.17.1
[PATCH v2] powerpc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency
Commit cc18e0fea790 ("LIBATA: Add HAVE_PATA_PLATFORM to select
PATA_PLATFORM driver") introduces config HAVE_PATA_PLATFORM, and expects
that all architectures simply select this config when the architecture
supports using the PATA_PLATFORM driver.
This is properly implemented already for all architectures except for the
powerpc architecture. Implement this for powerpc now.
Adjust the config of the powerpc architecture to use the config
HAVE_PATA_PLATFORM and simplify the config PATA_PLATFORM to not mention
any specific architecture anymore.
Signed-off-by: Lukas Bulwahn
---
arch/powerpc/Kconfig | 1 +
drivers/ata/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 39d71d7701bd..2575e21b6e6b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -237,6 +237,7 @@ config PPC
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI if PERF_EVENTS || (PPC64 &&
PPC_BOOK3S)
select HAVE_OPTPROBES
+ select HAVE_PATA_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
select HAVE_PERF_REGS
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 1c9f4fb2595d..ed3547165528 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -1103,7 +1103,7 @@ config PATA_PCMCIA
config PATA_PLATFORM
tristate "Generic platform device PATA support"
- depends on EXPERT || PPC || HAVE_PATA_PLATFORM
+ depends on EXPERT || HAVE_PATA_PLATFORM
help
This option enables support for generic directly connected ATA
devices commonly found on embedded systems.
--
2.17.1
[PATCH] ppc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency
Commit cc18e0fea790 ("LIBATA: Add HAVE_PATA_PLATFORM to select
PATA_PLATFORM driver") introduces config HAVE_PATA_PLATFORM, and expects
that all architectures simply select this config when the architecture
supports using the PATA_PLATFORM driver.
This is properly implemented already for all architectures except for the
powerpc architecture. Implement this for powerpc now.
Adjust the config of the powerpc architecture to use the config
HAVE_PATA_PLATFORM and simplify the config PATA_PLATFORM to not mention
any specific architecture anymore.
Signed-off-by: Lukas Bulwahn
---
arch/powerpc/Kconfig | 1 +
drivers/ata/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 39d71d7701bd..2575e21b6e6b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -237,6 +237,7 @@ config PPC
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI if PERF_EVENTS || (PPC64 &&
PPC_BOOK3S)
select HAVE_OPTPROBES
+ select HAVE_PATA_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
select HAVE_PERF_REGS
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 1c9f4fb2595d..ed3547165528 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -1103,7 +1103,7 @@ config PATA_PCMCIA
config PATA_PLATFORM
tristate "Generic platform device PATA support"
- depends on EXPERT || PPC || HAVE_PATA_PLATFORM
+ depends on EXPERT || HAVE_PATA_PLATFORM
help
This option enables support for generic directly connected ATA
devices commonly found on embedded systems.
--
2.17.1
