* Re: Linux kernel: powerpc: RTAS calls can be used to compromise kernel integrity
From: Andrew Donnellan @ 2020-11-23 14:41 UTC (permalink / raw)
To: oss-security, linuxppc-dev
In-Reply-To: <09cb1e1e-c71b-83a3-4c04-4e47e7c85342@linux.ibm.com>
On 9/10/20 12:20 pm, Andrew Donnellan wrote:
> The Linux kernel for powerpc has an issue with the Run-Time Abstraction
> Services (RTAS) interface, allowing root (or CAP_SYS_ADMIN users) in a
> VM to overwrite some parts of memory, including kernel memory.
>
> This issue impacts guests running on top of PowerVM or KVM hypervisors
> (pseries platform), and does *not* impact bare-metal machines (powernv
> platform).
CVE-2020-27777 has been assigned.
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH v2 04/19] powerpc/perf: move perf irq/nmi handling details into traps.c
From: Athira Rajeev @ 2020-11-23 17:54 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20201111094410.3038123-5-npiggin@gmail.com>
> On 11-Nov-2020, at 3:13 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> This is required in order to allow more significant differences between
> NMI type interrupt handlers and regular asynchronous handlers.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kernel/traps.c | 31 +++++++++++++++++++++++++++-
> arch/powerpc/perf/core-book3s.c | 35 ++------------------------------
> arch/powerpc/perf/core-fsl-emb.c | 25 -----------------------
> 3 files changed, 32 insertions(+), 59 deletions(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 902fcbd1a778..7dda72eb97cc 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -1919,11 +1919,40 @@ void vsx_unavailable_tm(struct pt_regs *regs)
> }
> #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
>
> -void performance_monitor_exception(struct pt_regs *regs)
> +static void performance_monitor_exception_nmi(struct pt_regs *regs)
> +{
> + nmi_enter();
> +
> + __this_cpu_inc(irq_stat.pmu_irqs);
> +
> + perf_irq(regs);
> +
> + nmi_exit();
> +}
> +
> +static void performance_monitor_exception_async(struct pt_regs *regs)
> {
> + irq_enter();
> +
> __this_cpu_inc(irq_stat.pmu_irqs);
>
> perf_irq(regs);
> +
> + irq_exit();
> +}
> +
> +void performance_monitor_exception(struct pt_regs *regs)
> +{
> + /*
> + * On 64-bit, if perf interrupts hit in a local_irq_disable
> + * (soft-masked) region, we consider them as NMIs. This is required to
> + * prevent hash faults on user addresses when reading callchains (and
> + * looks better from an irq tracing perspective).
> + */
> + if (IS_ENABLED(CONFIG_PPC64) && unlikely(arch_irq_disabled_regs(regs)))
> + performance_monitor_exception_nmi(regs);
> + else
> + performance_monitor_exception_async(regs);
> }
>
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 08643cba1494..9fd8cae09218 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -109,10 +109,6 @@ static inline void perf_read_regs(struct pt_regs *regs)
> {
> regs->result = 0;
> }
> -static inline int perf_intr_is_nmi(struct pt_regs *regs)
> -{
> - return 0;
> -}
>
> static inline int siar_valid(struct pt_regs *regs)
> {
> @@ -328,15 +324,6 @@ static inline void perf_read_regs(struct pt_regs *regs)
> regs->result = use_siar;
> }
>
> -/*
> - * If interrupts were soft-disabled when a PMU interrupt occurs, treat
> - * it as an NMI.
> - */
> -static inline int perf_intr_is_nmi(struct pt_regs *regs)
> -{
> - return (regs->softe & IRQS_DISABLED);
> -}
> -
Hi Nick,
arch_irq_disabled_regs checks the regs->softe value, if it has IRQS_DISABLED set.
Core-book3s is also using same logic in perf_intr_is_nmi to check if it is an NMI. With the
changes in this patch, if I understood correctly, we will do the irq/nmi handling in traps.c
rather than doing it in the PMI interrupt handler. But can you please help to understand
better on what is the perf weirdness (sometimes NMI, sometimes not) mentioned in the cover
letter that we are fixing with this change ?
Thanks
Athira
> /*
> * On processors like P7+ that have the SIAR-Valid bit, marked instructions
> * must be sampled only if the SIAR-valid bit is set.
> @@ -2224,7 +2211,6 @@ static void __perf_event_interrupt(struct pt_regs *regs)
> struct perf_event *event;
> unsigned long val[8];
> int found, active;
> - int nmi;
>
> if (cpuhw->n_limited)
> freeze_limited_counters(cpuhw, mfspr(SPRN_PMC5),
> @@ -2232,18 +2218,6 @@ static void __perf_event_interrupt(struct pt_regs *regs)
>
> perf_read_regs(regs);
>
> - /*
> - * If perf interrupts hit in a local_irq_disable (soft-masked) region,
> - * we consider them as NMIs. This is required to prevent hash faults on
> - * user addresses when reading callchains. See the NMI test in
> - * do_hash_page.
> - */
> - nmi = perf_intr_is_nmi(regs);
> - if (nmi)
> - nmi_enter();
> - else
> - irq_enter();
> -
> /* Read all the PMCs since we'll need them a bunch of times */
> for (i = 0; i < ppmu->n_counter; ++i)
> val[i] = read_pmc(i + 1);
> @@ -2289,8 +2263,8 @@ static void __perf_event_interrupt(struct pt_regs *regs)
> }
> }
> }
> - if (!found && !nmi && printk_ratelimit())
> - printk(KERN_WARNING "Can't find PMC that caused IRQ\n");
> + if (unlikely(!found) && !arch_irq_disabled_regs(regs))
> + printk_ratelimited(KERN_WARNING "Can't find PMC that caused IRQ\n");
>
> /*
> * Reset MMCR0 to its normal value. This will set PMXE and
> @@ -2300,11 +2274,6 @@ static void __perf_event_interrupt(struct pt_regs *regs)
> * we get back out of this interrupt.
> */
> write_mmcr0(cpuhw, cpuhw->mmcr.mmcr0);
> -
> - if (nmi)
> - nmi_exit();
> - else
> - irq_exit();
> }
>
> static void perf_event_interrupt(struct pt_regs *regs)
> diff --git a/arch/powerpc/perf/core-fsl-emb.c b/arch/powerpc/perf/core-fsl-emb.c
> index e0e7e276bfd2..ee721f420a7b 100644
> --- a/arch/powerpc/perf/core-fsl-emb.c
> +++ b/arch/powerpc/perf/core-fsl-emb.c
> @@ -31,19 +31,6 @@ static atomic_t num_events;
> /* Used to avoid races in calling reserve/release_pmc_hardware */
> static DEFINE_MUTEX(pmc_reserve_mutex);
>
> -/*
> - * If interrupts were soft-disabled when a PMU interrupt occurs, treat
> - * it as an NMI.
> - */
> -static inline int perf_intr_is_nmi(struct pt_regs *regs)
> -{
> -#ifdef __powerpc64__
> - return (regs->softe & IRQS_DISABLED);
> -#else
> - return 0;
> -#endif
> -}
> -
> static void perf_event_interrupt(struct pt_regs *regs);
>
> /*
> @@ -659,13 +646,6 @@ static void perf_event_interrupt(struct pt_regs *regs)
> struct perf_event *event;
> unsigned long val;
> int found = 0;
> - int nmi;
> -
> - nmi = perf_intr_is_nmi(regs);
> - if (nmi)
> - nmi_enter();
> - else
> - irq_enter();
>
> for (i = 0; i < ppmu->n_counter; ++i) {
> event = cpuhw->event[i];
> @@ -690,11 +670,6 @@ static void perf_event_interrupt(struct pt_regs *regs)
> mtmsr(mfmsr() | MSR_PMM);
> mtpmr(PMRN_PMGC0, PMGC0_PMIE | PMGC0_FCECE);
> isync();
> -
> - if (nmi)
> - nmi_exit();
> - else
> - irq_exit();
> }
>
> void hw_perf_event_setup(int cpu)
> --
> 2.23.0
>
^ permalink raw reply
* Re: [PATCH v3 2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too
From: Oleg Nesterov @ 2020-11-23 18:01 UTC (permalink / raw)
To: Christophe Leroy
Cc: Christophe Leroy, Madhavan Srinivasan, linuxppc-dev,
Nicholas Piggin, linux-kernel, Paul Mackerras, Al Viro,
Aneesh Kumar K.V, Jan Kratochvil
In-Reply-To: <20201119224347.GC5138@redhat.com>
Christophe, et al,
So what?
Are you going to push your change or should I re-send 1-2 without
whitespace cleanups?
On 11/19, Oleg Nesterov wrote:
>
> On 11/19, Christophe Leroy wrote:
> >
> > I think the following should work, and not require the first patch (compile
> > tested only).
> >
> > --- a/arch/powerpc/kernel/ptrace/ptrace-view.c
> > +++ b/arch/powerpc/kernel/ptrace/ptrace-view.c
> > @@ -234,9 +234,21 @@ static int gpr_get(struct task_struct *target, const
> > struct user_regset *regset,
> > BUILD_BUG_ON(offsetof(struct pt_regs, orig_gpr3) !=
> > offsetof(struct pt_regs, msr) + sizeof(long));
> >
> > +#ifdef CONFIG_PPC64
> > + membuf_write(&to, &target->thread.regs->orig_gpr3,
> > + offsetof(struct pt_regs, softe) - offsetof(struct pt_regs,
> > orig_gpr3));
> > + membuf_store(&to, 1UL);
> > +
> > + BUILD_BUG_ON(offsetof(struct pt_regs, trap) !=
> > + offsetof(struct pt_regs, softe) + sizeof(long));
> > +
> > + membuf_write(&to, &target->thread.regs->trap,
> > + sizeof(struct user_pt_regs) - offsetof(struct pt_regs, trap));
> > +#else
> > membuf_write(&to, &target->thread.regs->orig_gpr3,
> > sizeof(struct user_pt_regs) -
> > offsetof(struct pt_regs, orig_gpr3));
> > +#endif
> > return membuf_zero(&to, ELF_NGREG * sizeof(unsigned long) -
> > sizeof(struct user_pt_regs));
> > }
>
> Probably yes.
>
> This mirrors the previous patch I sent (https://lore.kernel.org/lkml/20190917143753.GA12300@redhat.com/)
> and this is exactly what I tried to avoid, we can make a simpler fix now.
>
> But let me repeat, I agree with any fix even if imp my version simplifies the code, just
> commit this change and lets forget this problem.
>
> Oleg.
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Bill Wendling @ 2020-11-23 19:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <20201123063432.GG2672@gate.crashing.org>
What Segher said. :-) Also, if you reverse the comparison, you'll get
a build error.
On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Mon, Nov 23, 2020 at 04:44:56PM +1100, Michael Ellerman wrote:
> > If I hard code:
> >
> > .org . - (1);
> >
> > It fails as expected.
> >
> > But if I hard code:
> >
> > .org . - (1 > 0);
> >
> > It builds?
>
> "true" (as a result of a comparison) in as is -1, not 1.
>
>
> Segher
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Bill Wendling @ 2020-11-23 19:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <CAGG=3QVjSAwU+ebvH=Lk5YVMxW7=ThvkJXGPw+95nYxxuurMig@mail.gmail.com>
After looking at this, I suspect that the correct change should be:
.org . + ((label##4b-label##3b) > (label##2b-label##1b));
I'm sorry about that. I can submit another version of the patch.
-bw
On Mon, Nov 23, 2020 at 11:43 AM Bill Wendling <morbo@google.com> wrote:
>
> What Segher said. :-) Also, if you reverse the comparison, you'll get
> a build error.
>
> On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Mon, Nov 23, 2020 at 04:44:56PM +1100, Michael Ellerman wrote:
> > > If I hard code:
> > >
> > > .org . - (1);
> > >
> > > It fails as expected.
> > >
> > > But if I hard code:
> > >
> > > .org . - (1 > 0);
> > >
> > > It builds?
> >
> > "true" (as a result of a comparison) in as is -1, not 1.
> >
> >
> > Segher
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Segher Boessenkool @ 2020-11-23 19:56 UTC (permalink / raw)
To: Bill Wendling; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <CAGG=3QVjSAwU+ebvH=Lk5YVMxW7=ThvkJXGPw+95nYxxuurMig@mail.gmail.com>
(Please don't top-post.)
> On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > "true" (as a result of a comparison) in as is -1, not 1.
On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote:
> What Segher said. :-) Also, if you reverse the comparison, you'll get
> a build error.
But that means your patch is the wrong way around?
- .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
- .error "Feature section else case larger than body"; \
- .endif; \
+ .org . - ((label##4b-label##3b) > (label##2b-label##1b)); \
It should be a + in that last line, not a -. Was this tested?
Segher
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Bill Wendling @ 2020-11-23 20:01 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <20201123195622.GI2672@gate.crashing.org>
On Mon, Nov 23, 2020 at 11:58 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> > On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > > "true" (as a result of a comparison) in as is -1, not 1.
>
> On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote:
> > What Segher said. :-) Also, if you reverse the comparison, you'll get
> > a build error.
>
> But that means your patch is the wrong way around?
>
> - .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
> - .error "Feature section else case larger than body"; \
> - .endif; \
> + .org . - ((label##4b-label##3b) > (label##2b-label##1b)); \
>
> It should be a + in that last line, not a -.
I said so in a follow up email.
> Was this tested?
>
Please don't be insulting. Anyone can make an error.
-bw
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Segher Boessenkool @ 2020-11-23 20:08 UTC (permalink / raw)
To: Bill Wendling; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <CAGG=3QXR=Yfh8PNa4m-kQLTBP4YKD8OGm_6fSUgeasQ1ar9b2g@mail.gmail.com>
On Mon, Nov 23, 2020 at 12:01:01PM -0800, Bill Wendling wrote:
> On Mon, Nov 23, 2020 at 11:58 AM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > > On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> > > <segher@kernel.crashing.org> wrote:
> > > > "true" (as a result of a comparison) in as is -1, not 1.
> >
> > On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote:
> > > What Segher said. :-) Also, if you reverse the comparison, you'll get
> > > a build error.
> >
> > But that means your patch is the wrong way around?
> >
> > - .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
> > - .error "Feature section else case larger than body"; \
> > - .endif; \
> > + .org . - ((label##4b-label##3b) > (label##2b-label##1b)); \
> >
> > It should be a + in that last line, not a -.
>
> I said so in a follow up email.
Yeah, and that arrived a second after I pressed "send" :-)
> > Was this tested?
> >
> Please don't be insulting. Anyone can make an error.
Absolutely, but it is just a question. It seems you could improve that
testing! It helps you yourself most of all ;-)
Segher
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Bill Wendling @ 2020-11-23 20:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <20201123200846.GJ2672@gate.crashing.org>
On Mon, Nov 23, 2020 at 12:10 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Mon, Nov 23, 2020 at 12:01:01PM -0800, Bill Wendling wrote:
> > On Mon, Nov 23, 2020 at 11:58 AM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > > > On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> > > > <segher@kernel.crashing.org> wrote:
> > > > > "true" (as a result of a comparison) in as is -1, not 1.
> > >
> > > On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote:
> > > > What Segher said. :-) Also, if you reverse the comparison, you'll get
> > > > a build error.
> > >
> > > But that means your patch is the wrong way around?
> > >
> > > - .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
> > > - .error "Feature section else case larger than body"; \
> > > - .endif; \
> > > + .org . - ((label##4b-label##3b) > (label##2b-label##1b)); \
> > >
> > > It should be a + in that last line, not a -.
> >
> > I said so in a follow up email.
>
> Yeah, and that arrived a second after I pressed "send" :-)
>
Michael, I apologize for the churn with these patches. I believe the
policy is to resend the match as "v4", correct?
I ran tests with the change above. It compiled with no error. If I
switch the labels around to ".org . + ((label##2b-label##1b) >
(label##4b-label##3b))", then it fails as expected.
-bw
^ permalink raw reply
* Re: linux-next: build failure in Linus' tree
From: Michael Ellerman @ 2020-11-23 23:39 UTC (permalink / raw)
To: Michael Ellerman, Stephen Rothwell, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Nicholas Piggin, Daniel Axtens
In-Reply-To: <20201123184016.693fe464@canb.auug.org.au>
On Mon, 23 Nov 2020 18:40:16 +1100, Stephen Rothwell wrote:
> After merging most of the trees, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/kup.h:18,
> from arch/powerpc/include/asm/uaccess.h:9,
> from include/linux/uaccess.h:11,
> from include/linux/sched/task.h:11,
> from include/linux/sched/signal.h:9,
> from include/linux/rcuwait.h:6,
> from include/linux/percpu-rwsem.h:7,
> from include/linux/fs.h:33,
> from include/linux/compat.h:17,
> from arch/powerpc/kernel/asm-offsets.c:14:
> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: data definition has no type or storage class
> 66 | DECLARE_STATIC_KEY_FALSE(uaccess_flush_key);
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: error: type defaults to 'int' in declaration of 'DECLARE_STATIC_KEY_FALSE' [-Werror=implicit-int]
> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: parameter names (without types) in function declaration
> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'prevent_user_access':
> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:6: error: implicit declaration of function 'static_branch_unlikely' [-Werror=implicit-function-declaration]
> 180 | if (static_branch_unlikely(&uaccess_flush_key))
> | ^~~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: error: 'uaccess_flush_key' undeclared (first use in this function)
> 180 | if (static_branch_unlikely(&uaccess_flush_key))
> | ^~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: note: each undeclared identifier is reported only once for each function it appears in
> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'prevent_user_access_return':
> arch/powerpc/include/asm/book3s/64/kup-radix.h:189:30: error: 'uaccess_flush_key' undeclared (first use in this function)
> 189 | if (static_branch_unlikely(&uaccess_flush_key))
> | ^~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'restore_user_access':
> arch/powerpc/include/asm/book3s/64/kup-radix.h:198:30: error: 'uaccess_flush_key' undeclared (first use in this function)
> 198 | if (static_branch_unlikely(&uaccess_flush_key) && flags == AMR_KUAP_BLOCKED)
> | ^~~~~~~~~~~~~~~~~
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/64s: Fix allnoconfig build since uaccess flush
https://git.kernel.org/powerpc/c/b6b79dd53082db11070b4368d85dd6699ff0b063
cheers
^ permalink raw reply
* Re: linux-next: build failure in Linus' tree
From: Daniel Axtens @ 2020-11-24 0:23 UTC (permalink / raw)
To: Michael Ellerman, Michael Ellerman, Stephen Rothwell, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Nicholas Piggin
In-Reply-To: <160617472873.1817800.16473753588453276266.b4-ty@ellerman.id.au>
Thanks sfr and mpe.
> Applied to powerpc/fixes.
>
> [1/1] powerpc/64s: Fix allnoconfig build since uaccess flush
> https://git.kernel.org/powerpc/c/b6b79dd53082db11070b4368d85dd6699ff0b063
We also needed a similar fix for stable, which has also been applied.
I guess I should build some sort of build process that tests a whole
range of configs. I did test a few but clearly not enough. Is there a
known list that I should be using? Something from kisskb?
Kind regards,
Daniel
Michael Ellerman <patch-notifications@ellerman.id.au> writes:
> On Mon, 23 Nov 2020 18:40:16 +1100, Stephen Rothwell wrote:
>> After merging most of the trees, today's linux-next build (powerpc64
>> allnoconfig) failed like this:
>>
>> In file included from arch/powerpc/include/asm/kup.h:18,
>> from arch/powerpc/include/asm/uaccess.h:9,
>> from include/linux/uaccess.h:11,
>> from include/linux/sched/task.h:11,
>> from include/linux/sched/signal.h:9,
>> from include/linux/rcuwait.h:6,
>> from include/linux/percpu-rwsem.h:7,
>> from include/linux/fs.h:33,
>> from include/linux/compat.h:17,
>> from arch/powerpc/kernel/asm-offsets.c:14:
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: data definition has no type or storage class
>> 66 | DECLARE_STATIC_KEY_FALSE(uaccess_flush_key);
>> | ^~~~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: error: type defaults to 'int' in declaration of 'DECLARE_STATIC_KEY_FALSE' [-Werror=implicit-int]
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: parameter names (without types) in function declaration
>> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'prevent_user_access':
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:6: error: implicit declaration of function 'static_branch_unlikely' [-Werror=implicit-function-declaration]
>> 180 | if (static_branch_unlikely(&uaccess_flush_key))
>> | ^~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: error: 'uaccess_flush_key' undeclared (first use in this function)
>> 180 | if (static_branch_unlikely(&uaccess_flush_key))
>> | ^~~~~~~~~~~~~~~~~
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: note: each undeclared identifier is reported only once for each function it appears in
>> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'prevent_user_access_return':
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:189:30: error: 'uaccess_flush_key' undeclared (first use in this function)
>> 189 | if (static_branch_unlikely(&uaccess_flush_key))
>> | ^~~~~~~~~~~~~~~~~
>> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'restore_user_access':
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:198:30: error: 'uaccess_flush_key' undeclared (first use in this function)
>> 198 | if (static_branch_unlikely(&uaccess_flush_key) && flags == AMR_KUAP_BLOCKED)
>> | ^~~~~~~~~~~~~~~~~
>>
>> [...]
>
^ permalink raw reply
* Re: [PATCH 00/25] Rid W=1 warnings in SoC
From: Li Yang @ 2020-11-24 0:44 UTC (permalink / raw)
To: Lee Jones
Cc: Heiko Stuebner, Roy Pledge, Liam Girdwood, Scott Wood,
Thierry Reding, Qiang Zhao, linux-samsung-soc, Rafael J. Wysocki,
YueHaibing, Sandeep Nair, Krzysztof Kozlowski, Jonathan Hunter,
linux-rockchip, act, Andy Gross, bcm-kernel-feedback-list,
Cyril Chemparathy, linux-arm-msm, Florian Fainelli,
Santosh Shilimkar, linux-tegra, Bjorn Andersson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Software, Inc, Dave Gerlach, Doug Anderson, lkml, Ben Dooks,
Mark Brown, Dan Malek, Vitaly Bordug, linuxppc-dev
In-Reply-To: <20201103152838.1290217-1-lee.jones@linaro.org>
On Tue, Nov 3, 2020 at 9:29 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> Lee Jones (25):
> soc: fsl: dpio: qbman-portal: Fix a bunch of kernel-doc misdemeanours
> soc: fsl: qe: qe_common: Fix misnamed function attribute 'addr'
> soc: fsl: qbman: qman: Remove unused variable 'dequeue_wq'
The above are applied for next. Thanks.
Regards,
Leo
>
> drivers/soc/bcm/brcmstb/pm/pm-arm.c | 2 +
> drivers/soc/fsl/dpio/qbman-portal.c | 18 +++++--
> drivers/soc/fsl/qbman/qman.c | 8 +--
> drivers/soc/fsl/qe/qe_common.c | 2 +-
> drivers/soc/qcom/kryo-l2-accessors.c | 2 +-
> drivers/soc/qcom/llcc-qcom.c | 2 +-
> drivers/soc/qcom/qcom-geni-se.c | 5 +-
> drivers/soc/qcom/qcom_aoss.c | 4 +-
> drivers/soc/qcom/rpmh.c | 2 +-
> drivers/soc/qcom/rpmhpd.c | 3 ++
> drivers/soc/qcom/smem.c | 3 +-
> drivers/soc/qcom/smp2p.c | 3 +-
> drivers/soc/qcom/smsm.c | 4 +-
> drivers/soc/qcom/wcnss_ctrl.c | 8 +--
> drivers/soc/rockchip/io-domain.c | 3 --
> drivers/soc/samsung/s3c-pm-check.c | 2 +-
> drivers/soc/tegra/fuse/speedo-tegra124.c | 7 ++-
> drivers/soc/tegra/fuse/speedo-tegra210.c | 8 +--
> drivers/soc/ti/k3-ringacc.c | 1 +
> drivers/soc/ti/knav_dma.c | 2 +-
> drivers/soc/ti/knav_qmss_queue.c | 62 ++++++++++++------------
> drivers/soc/ti/pm33xx.c | 4 +-
> drivers/soc/ti/wkup_m3_ipc.c | 8 ++-
> 23 files changed, 86 insertions(+), 77 deletions(-)
>
> Cc: act <dmalek@jlc.net>
> Cc: Andy Gross <agross@kernel.org>
> Cc: bcm-kernel-feedback-list@broadcom.com
> Cc: Ben Dooks <ben@simtec.co.uk>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Cyril Chemparathy <cyril@ti.com>
> Cc: Dan Malek <dan@embeddedalley.com>
> Cc: Dave Gerlach <d-gerlach@ti.com>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-rockchip@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-tegra@vger.kernel.org
> Cc: Li Yang <leoyang.li@nxp.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Qiang Zhao <qiang.zhao@nxp.com>
> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> Cc: Roy Pledge <Roy.Pledge@nxp.com>
> Cc: Sandeep Nair <sandeep_n@ti.com>
> Cc: Santosh Shilimkar <ssantosh@kernel.org>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: "Software, Inc" <source@mvista.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
> Cc: YueHaibing <yuehaibing@huawei.com>
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 25/25] soc: fsl: qbman: qman: Remove unused variable 'dequeue_wq'
From: Li Yang @ 2020-11-24 0:49 UTC (permalink / raw)
To: Roy Pledge
Cc: linuxppc-dev, Lee Jones, YueHaibing, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20201103152838.1290217-26-lee.jones@linaro.org>
Hi Roy,
On Tue, Nov 3, 2020 at 9:31 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/soc/fsl/qbman/qman.c: In function ‘qman_shutdown_fq’:
> drivers/soc/fsl/qbman/qman.c:2700:8: warning: variable ‘dequeue_wq’ set but not used [-Wunused-but-set-variable]
>
> Cc: Li Yang <leoyang.li@nxp.com>
> Cc: YueHaibing <yuehaibing@huawei.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/soc/fsl/qbman/qman.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
> index 9888a70618730..62b182c3a8b04 100644
> --- a/drivers/soc/fsl/qbman/qman.c
> +++ b/drivers/soc/fsl/qbman/qman.c
> @@ -2622,7 +2622,7 @@ int qman_shutdown_fq(u32 fqid)
> union qm_mc_command *mcc;
> union qm_mc_result *mcr;
> int orl_empty, drain = 0, ret = 0;
> - u32 channel, wq, res;
> + u32 channel, res;
> u8 state;
>
> p = get_affine_portal();
> @@ -2655,7 +2655,7 @@ int qman_shutdown_fq(u32 fqid)
> DPAA_ASSERT((mcr->verb & QM_MCR_VERB_MASK) == QM_MCR_VERB_QUERYFQ);
> /* Need to store these since the MCR gets reused */
> channel = qm_fqd_get_chan(&mcr->queryfq.fqd);
> - wq = qm_fqd_get_wq(&mcr->queryfq.fqd);
> + qm_fqd_get_wq(&mcr->queryfq.fqd);
This probably is not needed also.
>
> if (channel < qm_channel_pool1) {
> channel_portal = get_portal_for_channel(channel);
> @@ -2697,7 +2697,6 @@ int qman_shutdown_fq(u32 fqid)
> * to dequeue from the channel the FQ is scheduled on
> */
> int found_fqrn = 0;
> - u16 dequeue_wq = 0;
>
> /* Flag that we need to drain FQ */
> drain = 1;
> @@ -2705,11 +2704,8 @@ int qman_shutdown_fq(u32 fqid)
> if (channel >= qm_channel_pool1 &&
> channel < qm_channel_pool1 + 15) {
> /* Pool channel, enable the bit in the portal */
> - dequeue_wq = (channel -
> - qm_channel_pool1 + 1)<<4 | wq;
> } else if (channel < qm_channel_pool1) {
> /* Dedicated channel */
> - dequeue_wq = wq;
With these gone, these if statements seem to be redundant. Can you
propose an additional patch to further cleanup the code here? Thanks.
> } else {
> dev_err(dev, "Can't recover FQ 0x%x, ch: 0x%x",
> fqid, channel);
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v3 2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too
From: Michael Ellerman @ 2020-11-24 0:53 UTC (permalink / raw)
To: Oleg Nesterov, Christophe Leroy
Cc: Christophe Leroy, Madhavan Srinivasan, linuxppc-dev,
Nicholas Piggin, linux-kernel, Paul Mackerras, Al Viro,
Aneesh Kumar K.V, Jan Kratochvil
In-Reply-To: <20201123180142.GB20279@redhat.com>
Oleg Nesterov <oleg@redhat.com> writes:
> Christophe, et al,
>
> So what?
>
> Are you going to push your change or should I re-send 1-2 without
> whitespace cleanups?
I'll take your 1 & 2 and fixup the whitespace issues when applying.
cheers
> On 11/19, Oleg Nesterov wrote:
>>
>> On 11/19, Christophe Leroy wrote:
>> >
>> > I think the following should work, and not require the first patch (compile
>> > tested only).
>> >
>> > --- a/arch/powerpc/kernel/ptrace/ptrace-view.c
>> > +++ b/arch/powerpc/kernel/ptrace/ptrace-view.c
>> > @@ -234,9 +234,21 @@ static int gpr_get(struct task_struct *target, const
>> > struct user_regset *regset,
>> > BUILD_BUG_ON(offsetof(struct pt_regs, orig_gpr3) !=
>> > offsetof(struct pt_regs, msr) + sizeof(long));
>> >
>> > +#ifdef CONFIG_PPC64
>> > + membuf_write(&to, &target->thread.regs->orig_gpr3,
>> > + offsetof(struct pt_regs, softe) - offsetof(struct pt_regs,
>> > orig_gpr3));
>> > + membuf_store(&to, 1UL);
>> > +
>> > + BUILD_BUG_ON(offsetof(struct pt_regs, trap) !=
>> > + offsetof(struct pt_regs, softe) + sizeof(long));
>> > +
>> > + membuf_write(&to, &target->thread.regs->trap,
>> > + sizeof(struct user_pt_regs) - offsetof(struct pt_regs, trap));
>> > +#else
>> > membuf_write(&to, &target->thread.regs->orig_gpr3,
>> > sizeof(struct user_pt_regs) -
>> > offsetof(struct pt_regs, orig_gpr3));
>> > +#endif
>> > return membuf_zero(&to, ELF_NGREG * sizeof(unsigned long) -
>> > sizeof(struct user_pt_regs));
>> > }
>>
>> Probably yes.
>>
>> This mirrors the previous patch I sent (https://lore.kernel.org/lkml/20190917143753.GA12300@redhat.com/)
>> and this is exactly what I tried to avoid, we can make a simpler fix now.
>>
>> But let me repeat, I agree with any fix even if imp my version simplifies the code, just
>> commit this change and lets forget this problem.
>>
>> Oleg.
^ permalink raw reply
* Re: [PATCH v3] soc: fsl: dpio: Get the cpumask through cpumask_of(cpu)
From: Li Yang @ 2020-11-24 1:25 UTC (permalink / raw)
To: Yi Wang
Cc: jiang.xuexin, Hao Si, Roy Pledge, lkml, Lin Chen, xue.zhihong,
linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20201020021832.36846-1-wang.yi59@zte.com.cn>
On Mon, Oct 19, 2020 at 9:15 PM Yi Wang <wang.yi59@zte.com.cn> wrote:
>
> From: Hao Si <si.hao@zte.com.cn>
>
> The local variable 'cpumask_t mask' is in the stack memory, and its address
> is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
> But the memory area where this variable is located is at risk of being
> modified.
>
> During LTP testing, the following error was generated:
>
> Unable to handle kernel paging request at virtual address ffff000012e9b790
> Mem abort info:
> ESR = 0x96000007
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x00000007
> CM = 0, WnR = 0
> swapper pgtable: 4k pages, 48-bit VAs, pgdp = 0000000075ac5e07
> [ffff000012e9b790] pgd=00000027dbffe003, pud=00000027dbffd003,
> pmd=00000027b6d61003, pte=0000000000000000
> Internal error: Oops: 96000007 [#1] PREEMPT SMP
> Modules linked in: xt_conntrack
> Process read_all (pid: 20171, stack limit = 0x0000000044ea4095)
> CPU: 14 PID: 20171 Comm: read_all Tainted: G B W
> Hardware name: NXP Layerscape LX2160ARDB (DT)
> pstate: 80000085 (Nzcv daIf -PAN -UAO)
> pc : irq_affinity_hint_proc_show+0x54/0xb0
> lr : irq_affinity_hint_proc_show+0x4c/0xb0
> sp : ffff00001138bc10
> x29: ffff00001138bc10 x28: 0000ffffd131d1e0
> x27: 00000000007000c0 x26: ffff8025b9480dc0
> x25: ffff8025b9480da8 x24: 00000000000003ff
> x23: ffff8027334f8300 x22: ffff80272e97d000
> x21: ffff80272e97d0b0 x20: ffff8025b9480d80
> x19: ffff000009a49000 x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000000
> x15: 0000000000000000 x14: 0000000000000000
> x13: 0000000000000000 x12: 0000000000000040
> x11: 0000000000000000 x10: ffff802735b79b88
> x9 : 0000000000000000 x8 : 0000000000000000
> x7 : ffff000009a49848 x6 : 0000000000000003
> x5 : 0000000000000000 x4 : ffff000008157d6c
> x3 : ffff00001138bc10 x2 : ffff000012e9b790
> x1 : 0000000000000000 x0 : 0000000000000000
> Call trace:
> irq_affinity_hint_proc_show+0x54/0xb0
> seq_read+0x1b0/0x440
> proc_reg_read+0x80/0xd8
> __vfs_read+0x60/0x178
> vfs_read+0x94/0x150
> ksys_read+0x74/0xf0
> __arm64_sys_read+0x24/0x30
> el0_svc_common.constprop.0+0xd8/0x1a0
> el0_svc_handler+0x34/0x88
> el0_svc+0x10/0x14
> Code: f9001bbf 943e0732 f94066c2 b4000062 (f9400041)
> ---[ end trace b495bdcb0b3b732b ]---
> Kernel panic - not syncing: Fatal exception
> SMP: stopping secondary CPUs
> SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15
> Kernel Offset: disabled
> CPU features: 0x0,21006008
> Memory Limit: none
> ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Fix it by using 'cpumask_of(cpu)' to get the cpumask.
>
> Signed-off-by: Hao Si <si.hao@zte.com.cn>
> Signed-off-by: Lin Chen <chen.lin5@zte.com.cn>
> Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Applied for fix. Thanks.
> ---
> v3: Use cpumask_of(cpu) to get the pre-defined cpumask in the static
> cpu_bit_bitmap array.
> v2: Place 'cpumask_t mask' in the driver's private data and while at it,
> rename it to cpu_mask.
>
> drivers/soc/fsl/dpio/dpio-driver.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
> index 7b642c3..7f397b4 100644
> --- a/drivers/soc/fsl/dpio/dpio-driver.c
> +++ b/drivers/soc/fsl/dpio/dpio-driver.c
> @@ -95,7 +95,6 @@ static int register_dpio_irq_handlers(struct fsl_mc_device *dpio_dev, int cpu)
> {
> int error;
> struct fsl_mc_device_irq *irq;
> - cpumask_t mask;
>
> irq = dpio_dev->irqs[0];
> error = devm_request_irq(&dpio_dev->dev,
> @@ -112,9 +111,7 @@ static int register_dpio_irq_handlers(struct fsl_mc_device *dpio_dev, int cpu)
> }
>
> /* set the affinity hint */
> - cpumask_clear(&mask);
> - cpumask_set_cpu(cpu, &mask);
> - if (irq_set_affinity_hint(irq->msi_desc->irq, &mask))
> + if (irq_set_affinity_hint(irq->msi_desc->irq, cpumask_of(cpu)))
> dev_err(&dpio_dev->dev,
> "irq_set_affinity failed irq %d cpu %d\n",
> irq->msi_desc->irq, cpu);
> --
> 2.15.2
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 7c94b5d4e9d328a69d43a11d7e3dfd7a6d762cb6
From: kernel test robot @ 2020-11-24 2:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 7c94b5d4e9d328a69d43a11d7e3dfd7a6d762cb6 Automatic merge of 'fixes' into merge (2020-11-23 23:32)
elapsed time: 789m
configs tested: 145
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm zeus_defconfig
powerpc bluestone_defconfig
sh apsh4a3a_defconfig
arm mvebu_v7_defconfig
sh magicpanelr2_defconfig
arm nhk8815_defconfig
xtensa generic_kc705_defconfig
arm tct_hammer_defconfig
arm vexpress_defconfig
powerpc canyonlands_defconfig
powerpc kilauea_defconfig
mips sb1250_swarm_defconfig
xtensa virt_defconfig
sh r7780mp_defconfig
arm netwinder_defconfig
xtensa defconfig
arm u300_defconfig
powerpc xes_mpc85xx_defconfig
powerpc mpc832x_rdb_defconfig
arm pleb_defconfig
mips allyesconfig
arm keystone_defconfig
mips ip32_defconfig
sh se7724_defconfig
csky alldefconfig
arm dove_defconfig
m68k sun3_defconfig
sh rts7751r2dplus_defconfig
sh rsk7203_defconfig
arm gemini_defconfig
arm s5pv210_defconfig
sparc64 alldefconfig
powerpc akebono_defconfig
arm s3c6400_defconfig
sparc alldefconfig
sh se7721_defconfig
mips gcw0_defconfig
mips fuloong2e_defconfig
powerpc lite5200b_defconfig
mips ath79_defconfig
nds32 alldefconfig
arm cm_x300_defconfig
arm shmobile_defconfig
mips jmr3927_defconfig
ia64 gensparse_defconfig
arm hackkit_defconfig
mips ar7_defconfig
arm realview_defconfig
arm footbridge_defconfig
arm mainstone_defconfig
arm assabet_defconfig
arm colibri_pxa270_defconfig
arm davinci_all_defconfig
sh se7750_defconfig
arc haps_hs_smp_defconfig
mips mtx1_defconfig
arc defconfig
sh urquell_defconfig
sh sdk7780_defconfig
alpha defconfig
sh ecovec24_defconfig
powerpc arches_defconfig
powerpc currituck_defconfig
arm pxa168_defconfig
mips vocore2_defconfig
powerpc pq2fads_defconfig
powerpc socrates_defconfig
mips db1xxx_defconfig
arc alldefconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm mps2_defconfig
c6x evmc6474_defconfig
arm spear3xx_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
i386 randconfig-a005-20201123
i386 randconfig-a001-20201123
i386 randconfig-a006-20201123
x86_64 randconfig-a015-20201123
x86_64 randconfig-a011-20201123
x86_64 randconfig-a014-20201123
x86_64 randconfig-a016-20201123
x86_64 randconfig-a012-20201123
x86_64 randconfig-a013-20201123
i386 randconfig-a012-20201123
i386 randconfig-a013-20201123
i386 randconfig-a011-20201123
i386 randconfig-a016-20201123
i386 randconfig-a014-20201123
i386 randconfig-a015-20201123
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20201123
x86_64 randconfig-a003-20201123
x86_64 randconfig-a004-20201123
x86_64 randconfig-a005-20201123
x86_64 randconfig-a002-20201123
x86_64 randconfig-a001-20201123
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS c250581fcf84c34cbaf5b535512b60a5e96970f6
From: kernel test robot @ 2020-11-24 2:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: c250581fcf84c34cbaf5b535512b60a5e96970f6 powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32
elapsed time: 5500m
configs tested: 212
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arc haps_hs_smp_defconfig
mips db1xxx_defconfig
mips malta_kvm_defconfig
m68k sun3x_defconfig
s390 defconfig
mips cavium_octeon_defconfig
powerpc ge_imp3a_defconfig
powerpc xes_mpc85xx_defconfig
sh sdk7786_defconfig
arm pxa168_defconfig
arm zeus_defconfig
powerpc bluestone_defconfig
sh apsh4a3a_defconfig
arm mvebu_v7_defconfig
sh magicpanelr2_defconfig
arm nhk8815_defconfig
xtensa generic_kc705_defconfig
arm tct_hammer_defconfig
arm vexpress_defconfig
powerpc canyonlands_defconfig
powerpc kilauea_defconfig
mips sb1250_swarm_defconfig
arc nsimosci_hs_smp_defconfig
arm u8500_defconfig
powerpc tqm8555_defconfig
c6x evmc6472_defconfig
arm hackkit_defconfig
sh sh7724_generic_defconfig
powerpc obs600_defconfig
powerpc mpc512x_defconfig
arm h3600_defconfig
arm cerfcube_defconfig
sh sh7757lcr_defconfig
sh rsk7201_defconfig
arm alldefconfig
mips allyesconfig
arm keystone_defconfig
mips ip32_defconfig
arm u300_defconfig
arm palmz72_defconfig
mips ath25_defconfig
powerpc tqm8xx_defconfig
m68k mvme16x_defconfig
powerpc storcenter_defconfig
powerpc acadia_defconfig
mips vocore2_defconfig
sh rsk7269_defconfig
parisc alldefconfig
mips pic32mzda_defconfig
arm xcep_defconfig
sh se7343_defconfig
sh dreamcast_defconfig
sh se7724_defconfig
csky alldefconfig
arm dove_defconfig
m68k sun3_defconfig
sh rts7751r2dplus_defconfig
sh rsk7203_defconfig
arm gemini_defconfig
arm s5pv210_defconfig
sparc64 alldefconfig
arm aspeed_g4_defconfig
arm shmobile_defconfig
c6x defconfig
arc alldefconfig
arm ep93xx_defconfig
alpha defconfig
ia64 zx1_defconfig
ia64 gensparse_defconfig
sh hp6xx_defconfig
mips ip27_defconfig
powerpc mvme5100_defconfig
arm colibri_pxa270_defconfig
nds32 allnoconfig
powerpc allnoconfig
mips jmr3927_defconfig
xtensa iss_defconfig
nds32 alldefconfig
arm cm_x300_defconfig
arm davinci_all_defconfig
powerpc mpc8540_ads_defconfig
powerpc arches_defconfig
mips maltaup_defconfig
powerpc tqm8540_defconfig
powerpc akebono_defconfig
arm realview_defconfig
arm footbridge_defconfig
sh se7721_defconfig
powerpc powernv_defconfig
sh se7751_defconfig
mips loongson1b_defconfig
arm tango4_defconfig
xtensa nommu_kc705_defconfig
arm moxart_defconfig
sh sdk7780_defconfig
riscv rv32_defconfig
mips decstation_defconfig
arm mvebu_v5_defconfig
powerpc pcm030_defconfig
arm magician_defconfig
um kunit_defconfig
powerpc ppa8548_defconfig
mips lemote2f_defconfig
mips ar7_defconfig
sparc sparc64_defconfig
arc defconfig
sh urquell_defconfig
sh ecovec24_defconfig
powerpc pq2fads_defconfig
powerpc socrates_defconfig
arm corgi_defconfig
powerpc ppc64_defconfig
powerpc taishan_defconfig
mips ci20_defconfig
arc nsimosci_hs_defconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm mps2_defconfig
c6x evmc6474_defconfig
arm spear3xx_defconfig
mips rb532_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a006-20201120
x86_64 randconfig-a003-20201120
x86_64 randconfig-a004-20201120
x86_64 randconfig-a005-20201120
x86_64 randconfig-a001-20201120
x86_64 randconfig-a002-20201120
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
i386 randconfig-a005-20201123
i386 randconfig-a001-20201123
i386 randconfig-a006-20201123
i386 randconfig-a004-20201120
i386 randconfig-a003-20201120
i386 randconfig-a002-20201120
i386 randconfig-a005-20201120
i386 randconfig-a001-20201120
i386 randconfig-a006-20201120
x86_64 randconfig-a015-20201123
x86_64 randconfig-a011-20201123
x86_64 randconfig-a014-20201123
x86_64 randconfig-a016-20201123
x86_64 randconfig-a012-20201123
x86_64 randconfig-a013-20201123
i386 randconfig-a012-20201120
i386 randconfig-a013-20201120
i386 randconfig-a011-20201120
i386 randconfig-a016-20201120
i386 randconfig-a014-20201120
i386 randconfig-a015-20201120
i386 randconfig-a012-20201123
i386 randconfig-a013-20201123
i386 randconfig-a011-20201123
i386 randconfig-a016-20201123
i386 randconfig-a014-20201123
i386 randconfig-a015-20201123
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20201123
x86_64 randconfig-a003-20201123
x86_64 randconfig-a004-20201123
x86_64 randconfig-a005-20201123
x86_64 randconfig-a002-20201123
x86_64 randconfig-a001-20201123
x86_64 randconfig-a015-20201120
x86_64 randconfig-a011-20201120
x86_64 randconfig-a014-20201120
x86_64 randconfig-a016-20201120
x86_64 randconfig-a012-20201120
x86_64 randconfig-a013-20201120
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS b6b79dd53082db11070b4368d85dd6699ff0b063
From: kernel test robot @ 2020-11-24 2:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: b6b79dd53082db11070b4368d85dd6699ff0b063 powerpc/64s: Fix allnoconfig build since uaccess flush
elapsed time: 794m
configs tested: 198
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc pcm030_defconfig
arm s3c6400_defconfig
sh sh7763rdp_defconfig
powerpc warp_defconfig
arm ezx_defconfig
arm zeus_defconfig
powerpc bluestone_defconfig
sh apsh4a3a_defconfig
arm mvebu_v7_defconfig
sh magicpanelr2_defconfig
arm nhk8815_defconfig
arc nsimosci_hs_smp_defconfig
arm u8500_defconfig
powerpc tqm8555_defconfig
c6x evmc6472_defconfig
m68k amcore_defconfig
arm milbeaut_m10v_defconfig
powerpc tqm8540_defconfig
powerpc pmac32_defconfig
openrisc simple_smp_defconfig
sh defconfig
arm eseries_pxa_defconfig
arm tct_hammer_defconfig
powerpc mpc8560_ads_defconfig
arm s5pv210_defconfig
xtensa virt_defconfig
sh r7780mp_defconfig
arm netwinder_defconfig
xtensa defconfig
arm u300_defconfig
arm mainstone_defconfig
arm moxart_defconfig
openrisc alldefconfig
ia64 defconfig
arm mvebu_v5_defconfig
powerpc makalu_defconfig
powerpc xes_mpc85xx_defconfig
powerpc mpc832x_rdb_defconfig
arm pleb_defconfig
mips allyesconfig
arm keystone_defconfig
mips ip32_defconfig
powerpc tqm8xx_defconfig
m68k mvme16x_defconfig
powerpc storcenter_defconfig
powerpc acadia_defconfig
powerpc mpc512x_defconfig
mips vocore2_defconfig
sh se7724_defconfig
csky alldefconfig
arm dove_defconfig
m68k sun3_defconfig
sh rts7751r2dplus_defconfig
sh rsk7203_defconfig
arm gemini_defconfig
sparc64 alldefconfig
powerpc akebono_defconfig
sparc alldefconfig
sh se7721_defconfig
arm aspeed_g4_defconfig
arm shmobile_defconfig
arm h3600_defconfig
c6x defconfig
arc alldefconfig
powerpc ep88xc_defconfig
mips bigsur_defconfig
powerpc pseries_defconfig
arm tegra_defconfig
powerpc kmeter1_defconfig
mips decstation_r4k_defconfig
mips ip27_defconfig
powerpc mvme5100_defconfig
arm colibri_pxa270_defconfig
nds32 allnoconfig
powerpc allnoconfig
sh landisk_defconfig
mips mtx1_defconfig
mips nlm_xlr_defconfig
xtensa common_defconfig
mips maltaaprp_defconfig
nds32 alldefconfig
arm cm_x300_defconfig
mips jmr3927_defconfig
ia64 gensparse_defconfig
arm hackkit_defconfig
mips ar7_defconfig
arm realview_defconfig
arm footbridge_defconfig
powerpc powernv_defconfig
sh se7751_defconfig
mips loongson1b_defconfig
arm tango4_defconfig
xtensa nommu_kc705_defconfig
arm davinci_all_defconfig
sh se7750_defconfig
arc haps_hs_smp_defconfig
mips decstation_defconfig
m68k allmodconfig
arm xcep_defconfig
powerpc kilauea_defconfig
powerpc mpc8540_ads_defconfig
arm magician_defconfig
mips lemote2f_defconfig
arc defconfig
sh urquell_defconfig
sh sdk7780_defconfig
alpha defconfig
sh ecovec24_defconfig
powerpc arches_defconfig
powerpc currituck_defconfig
arm pxa168_defconfig
arm omap2plus_defconfig
sh rsk7269_defconfig
powerpc katmai_defconfig
arm exynos_defconfig
powerpc pq2fads_defconfig
powerpc socrates_defconfig
mips db1xxx_defconfig
arm corgi_defconfig
powerpc ppc64_defconfig
powerpc taishan_defconfig
mips ci20_defconfig
arc nsimosci_hs_defconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm mps2_defconfig
c6x evmc6474_defconfig
arm spear3xx_defconfig
xtensa generic_kc705_defconfig
mips rb532_defconfig
powerpc canyonlands_defconfig
ia64 allmodconfig
ia64 allyesconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
i386 randconfig-a005-20201123
i386 randconfig-a001-20201123
i386 randconfig-a006-20201123
x86_64 randconfig-a015-20201123
x86_64 randconfig-a011-20201123
x86_64 randconfig-a014-20201123
x86_64 randconfig-a016-20201123
x86_64 randconfig-a012-20201123
x86_64 randconfig-a013-20201123
i386 randconfig-a012-20201123
i386 randconfig-a013-20201123
i386 randconfig-a011-20201123
i386 randconfig-a016-20201123
i386 randconfig-a014-20201123
i386 randconfig-a015-20201123
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20201123
x86_64 randconfig-a003-20201123
x86_64 randconfig-a004-20201123
x86_64 randconfig-a005-20201123
x86_64 randconfig-a002-20201123
x86_64 randconfig-a001-20201123
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH V2] powerpc/perf: Fix crash with is_sier_available when pmu is not set
From: Athira Rajeev @ 2020-11-24 2:40 UTC (permalink / raw)
To: mpe; +Cc: sachinp, maddy, linuxppc-dev
On systems without any specific PMU driver support registered, running
'perf record' with —intr-regs will crash ( perf record -I <workload> ).
The relevant portion from crash logs and Call Trace:
Unable to handle kernel paging request for data at address 0x00000068
Faulting instruction address: 0xc00000000013eb18
Oops: Kernel access of bad area, sig: 11 [#1]
CPU: 2 PID: 13435 Comm: kill Kdump: loaded Not tainted 4.18.0-193.el8.ppc64le #1
NIP: c00000000013eb18 LR: c000000000139f2c CTR: c000000000393d80
REGS: c0000004a07ab4f0 TRAP: 0300 Not tainted (4.18.0-193.el8.ppc64le)
NIP [c00000000013eb18] is_sier_available+0x18/0x30
LR [c000000000139f2c] perf_reg_value+0x6c/0xb0
Call Trace:
[c0000004a07ab770] [c0000004a07ab7c8] 0xc0000004a07ab7c8 (unreliable)
[c0000004a07ab7a0] [c0000000003aa77c] perf_output_sample+0x60c/0xac0
[c0000004a07ab840] [c0000000003ab3f0] perf_event_output_forward+0x70/0xb0
[c0000004a07ab8c0] [c00000000039e208] __perf_event_overflow+0x88/0x1a0
[c0000004a07ab910] [c00000000039e42c] perf_swevent_hrtimer+0x10c/0x1d0
[c0000004a07abc50] [c000000000228b9c] __hrtimer_run_queues+0x17c/0x480
[c0000004a07abcf0] [c00000000022aaf4] hrtimer_interrupt+0x144/0x520
[c0000004a07abdd0] [c00000000002a864] timer_interrupt+0x104/0x2f0
[c0000004a07abe30] [c0000000000091c4] decrementer_common+0x114/0x120
When perf record session is started with "-I" option, capturing registers
on each sample calls is_sier_available() to check for the
SIER (Sample Instruction Event Register) availability in the platform.
This function in core-book3s accesses 'ppmu->flags'. If a platform specific
PMU driver is not registered, ppmu is set to NULL and accessing its
members results in a crash. Fix the crash by returning false in
is_sier_available() if ppmu is not set.
Fixes: 333804dc3b7a ("powerpc/perf: Update perf_regs structure to include SIER")
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
---
Changes in v2:
- Corrected the commit message as suggested by
Michael Ellerman.
arch/powerpc/perf/core-book3s.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 08643cb..1de4770 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -137,6 +137,9 @@ static void pmao_restore_workaround(bool ebb) { }
bool is_sier_available(void)
{
+ if (!ppmu)
+ return false;
+
if (ppmu->flags & PPMU_HAS_SIER)
return true;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Michael Ellerman @ 2020-11-24 3:43 UTC (permalink / raw)
To: Bill Wendling, Segher Boessenkool; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <CAGG=3QUeXTU+8jqw40W_rhatsHCRiuTboL3enz9bpt_jaJC3TA@mail.gmail.com>
Bill Wendling <morbo@google.com> writes:
> On Mon, Nov 23, 2020 at 12:10 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
>> On Mon, Nov 23, 2020 at 12:01:01PM -0800, Bill Wendling wrote:
>> > On Mon, Nov 23, 2020 at 11:58 AM Segher Boessenkool
>> > <segher@kernel.crashing.org> wrote:
>> > > > On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
>> > > > <segher@kernel.crashing.org> wrote:
>> > > > > "true" (as a result of a comparison) in as is -1, not 1.
>> > >
>> > > On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote:
>> > > > What Segher said. :-) Also, if you reverse the comparison, you'll get
>> > > > a build error.
>> > >
>> > > But that means your patch is the wrong way around?
>> > >
>> > > - .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
>> > > - .error "Feature section else case larger than body"; \
>> > > - .endif; \
>> > > + .org . - ((label##4b-label##3b) > (label##2b-label##1b)); \
>> > >
>> > > It should be a + in that last line, not a -.
>> >
>> > I said so in a follow up email.
>>
>> Yeah, and that arrived a second after I pressed "send" :-)
>>
> Michael, I apologize for the churn with these patches. I believe the
> policy is to resend the match as "v4", correct?
>
> I ran tests with the change above. It compiled with no error. If I
> switch the labels around to ".org . + ((label##2b-label##1b) >
> (label##4b-label##3b))", then it fails as expected.
I wanted to retain the nicer error reporting for gcc builds, so I did it
like this:
diff --git a/arch/powerpc/include/asm/feature-fixups.h b/arch/powerpc/include/asm/feature-fixups.h
index b0af97add751..c4ad33074df5 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -36,6 +36,24 @@ label##2: \
.align 2; \
label##3:
+
+#ifndef CONFIG_CC_IS_CLANG
+#define CHECK_ALT_SIZE(else_size, body_size) \
+ .ifgt (else_size) - (body_size); \
+ .error "Feature section else case larger than body"; \
+ .endif;
+#else
+/*
+ * If we use the ifgt syntax above, clang's assembler complains about the
+ * expression being non-absolute when the code appears in an inline assembly
+ * statement.
+ * As a workaround use an .org directive that has no effect if the else case
+ * instructions are smaller than the body, but fails otherwise.
+ */
+#define CHECK_ALT_SIZE(else_size, body_size) \
+ .org . + ((else_size) > (body_size));
+#endif
+
#define MAKE_FTR_SECTION_ENTRY(msk, val, label, sect) \
label##4: \
.popsection; \
@@ -48,9 +66,7 @@ label##5: \
FTR_ENTRY_OFFSET label##2b-label##5b; \
FTR_ENTRY_OFFSET label##3b-label##5b; \
FTR_ENTRY_OFFSET label##4b-label##5b; \
- .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
- .error "Feature section else case larger than body"; \
- .endif; \
+ CHECK_ALT_SIZE((label##4b-label##3b), (label##2b-label##1b)); \
.popsection;
I've pushed a branch with all your patches applied to:
https://github.com/linuxppc/linux/commits/next-test
Are you able to give that a quick test? It builds clean with clang for
me, but we must be using different versions of clang because my branch
already builds clean for me even without your patches.
cheers
^ permalink raw reply related
* Re: [PATCH 1/3] ibmvfc: byte swap login_buf.resp values in attribute show functions
From: Martin K. Petersen @ 2020-11-24 3:58 UTC (permalink / raw)
To: james.bottomley, Tyrel Datwyler
Cc: brking, linuxppc-dev, linux-kernel, Martin K . Petersen,
linux-scsi
In-Reply-To: <20201117185031.129939-1-tyreld@linux.ibm.com>
On Tue, 17 Nov 2020 12:50:29 -0600, Tyrel Datwyler wrote:
> Both ibmvfc_show_host_(capabilities|npiv_version) functions retrieve
> values from vhost->login_buf.resp buffer. This is the MAD response
> buffer from the VIOS and as such any multi-byte non-string values are in
> big endian format.
>
> Byte swap these values to host cpu endian format for better human
> readability.
Applied to 5.11/scsi-queue, thanks!
[1/3] scsi: ibmvfc: Byte swap login_buf.resp values in attribute show functions
https://git.kernel.org/mkp/scsi/c/61bdb4eec8d1
[2/3] scsi: ibmvfc: Remove trailing semicolon
https://git.kernel.org/mkp/scsi/c/4e0716199ab6
[3/3] scsi: ibmvfc: Use correlation token to tag commands
https://git.kernel.org/mkp/scsi/c/2aa0102c6688
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH 1/3] perf/core: Flush PMU internal buffers for per-CPU events
From: Namhyung Kim @ 2020-11-24 4:51 UTC (permalink / raw)
To: Michael Ellerman
Cc: Ian Rogers, Andi Kleen, Peter Zijlstra, linuxppc-dev,
linux-kernel, Stephane Eranian, Paul Mackerras,
Arnaldo Carvalho de Melo, Jiri Olsa, Ingo Molnar, Gabriel Marin,
Liang, Kan
In-Reply-To: <87a6v81gou.fsf@mpe.ellerman.id.au>
Hello,
On Mon, Nov 23, 2020 at 8:00 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Namhyung Kim <namhyung@kernel.org> writes:
> > Hi Peter and Kan,
> >
> > (Adding PPC folks)
> >
> > On Tue, Nov 17, 2020 at 2:01 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >>
> >> Hello,
> >>
> >> On Thu, Nov 12, 2020 at 4:54 AM Liang, Kan <kan.liang@linux.intel.com> wrote:
> >> >
> >> >
> >> >
> >> > On 11/11/2020 11:25 AM, Peter Zijlstra wrote:
> >> > > On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
> >> > >
> >> > >> - When the large PEBS was introduced (9c964efa4330), the sched_task() should
> >> > >> be invoked to flush the PEBS buffer in each context switch. However, The
> >> > >> perf_sched_events in account_event() is not updated accordingly. The
> >> > >> perf_event_task_sched_* never be invoked for a pure per-CPU context. Only
> >> > >> per-task event works.
> >> > >> At that time, the perf_pmu_sched_task() is outside of
> >> > >> perf_event_context_sched_in/out. It means that perf has to double
> >> > >> perf_pmu_disable() for per-task event.
> >> > >
> >> > >> - The patch 1 tries to fix broken per-CPU events. The CPU context cannot be
> >> > >> retrieved from the task->perf_event_ctxp. So it has to be tracked in the
> >> > >> sched_cb_list. Yes, the code is very similar to the original codes, but it
> >> > >> is actually the new code for per-CPU events. The optimization for per-task
> >> > >> events is still kept.
> >> > >> For the case, which has both a CPU context and a task context, yes, the
> >> > >> __perf_pmu_sched_task() in this patch is not invoked. Because the
> >> > >> sched_task() only need to be invoked once in a context switch. The
> >> > >> sched_task() will be eventually invoked in the task context.
> >> > >
> >> > > The thing is; your first two patches rely on PERF_ATTACH_SCHED_CB and
> >> > > only set that for large pebs. Are you sure the other users (Intel LBR
> >> > > and PowerPC BHRB) don't need it?
> >> >
> >> > I didn't set it for LBR, because the perf_sched_events is always enabled
> >> > for LBR. But, yes, we should explicitly set the PERF_ATTACH_SCHED_CB
> >> > for LBR.
> >> >
> >> > if (has_branch_stack(event))
> >> > inc = true;
> >> >
> >> > >
> >> > > If they indeed do not require the pmu::sched_task() callback for CPU
> >> > > events, then I still think the whole perf_sched_cb_{inc,dec}() interface
> >> >
> >> > No, LBR requires the pmu::sched_task() callback for CPU events.
> >> >
> >> > Now, The LBR registers have to be reset in sched in even for CPU events.
> >> >
> >> > To fix the shorter LBR callstack issue for CPU events, we also need to
> >> > save/restore LBRs in pmu::sched_task().
> >> > https://lore.kernel.org/lkml/1578495789-95006-4-git-send-email-kan.liang@linux.intel.com/
> >> >
> >> > > is confusing at best.
> >> > >
> >> > > Can't we do something like this instead?
> >> > >
> >> > I think the below patch may have two issues.
> >> > - PERF_ATTACH_SCHED_CB is required for LBR (maybe PowerPC BHRB as well) now.
> >> > - We may disable the large PEBS later if not all PEBS events support
> >> > large PEBS. The PMU need a way to notify the generic code to decrease
> >> > the nr_sched_task.
> >>
> >> Any updates on this? I've reviewed and tested Kan's patches
> >> and they all look good.
> >>
> >> Maybe we can talk to PPC folks to confirm the BHRB case?
> >
> > Can we move this forward? I saw patch 3/3 also adds PERF_ATTACH_SCHED_CB
> > for PowerPC too. But it'd be nice if ppc folks can confirm the change.
>
> Sorry I've read the whole thread, but I'm still not entirely sure I
> understand the question.
Thanks for your time and sorry about not being clear enough.
We found per-cpu events are not calling pmu::sched_task()
on context switches. So PERF_ATTACH_SCHED_CB was
added to indicate the core logic that it needs to invoke the
callback.
The patch 3/3 added the flag to PPC (for BHRB) with other
changes (I think it should be split like in the patch 2/3) and
want to get ACKs from the PPC folks.
Thanks,
Namhyung
^ permalink raw reply
* Re: [PATCH 1/3] perf/core: Flush PMU internal buffers for per-CPU events
From: Madhavan Srinivasan @ 2020-11-24 5:42 UTC (permalink / raw)
To: Namhyung Kim, Michael Ellerman
Cc: Ian Rogers, Andi Kleen, Peter Zijlstra, Jiri Olsa, linux-kernel,
Stephane Eranian, Paul Mackerras, Arnaldo Carvalho de Melo,
linuxppc-dev, Ingo Molnar, Gabriel Marin, Liang, Kan
In-Reply-To: <CAM9d7cg8kYMyPHQK_rhEiYQaSddqqt93=pLVNKJm8Y6F=if9ow@mail.gmail.com>
On 11/24/20 10:21 AM, Namhyung Kim wrote:
> Hello,
>
> On Mon, Nov 23, 2020 at 8:00 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Namhyung Kim <namhyung@kernel.org> writes:
>>> Hi Peter and Kan,
>>>
>>> (Adding PPC folks)
>>>
>>> On Tue, Nov 17, 2020 at 2:01 PM Namhyung Kim <namhyung@kernel.org> wrote:
>>>> Hello,
>>>>
>>>> On Thu, Nov 12, 2020 at 4:54 AM Liang, Kan <kan.liang@linux.intel.com> wrote:
>>>>>
>>>>>
>>>>> On 11/11/2020 11:25 AM, Peter Zijlstra wrote:
>>>>>> On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
>>>>>>
>>>>>>> - When the large PEBS was introduced (9c964efa4330), the sched_task() should
>>>>>>> be invoked to flush the PEBS buffer in each context switch. However, The
>>>>>>> perf_sched_events in account_event() is not updated accordingly. The
>>>>>>> perf_event_task_sched_* never be invoked for a pure per-CPU context. Only
>>>>>>> per-task event works.
>>>>>>> At that time, the perf_pmu_sched_task() is outside of
>>>>>>> perf_event_context_sched_in/out. It means that perf has to double
>>>>>>> perf_pmu_disable() for per-task event.
>>>>>>> - The patch 1 tries to fix broken per-CPU events. The CPU context cannot be
>>>>>>> retrieved from the task->perf_event_ctxp. So it has to be tracked in the
>>>>>>> sched_cb_list. Yes, the code is very similar to the original codes, but it
>>>>>>> is actually the new code for per-CPU events. The optimization for per-task
>>>>>>> events is still kept.
>>>>>>> For the case, which has both a CPU context and a task context, yes, the
>>>>>>> __perf_pmu_sched_task() in this patch is not invoked. Because the
>>>>>>> sched_task() only need to be invoked once in a context switch. The
>>>>>>> sched_task() will be eventually invoked in the task context.
>>>>>> The thing is; your first two patches rely on PERF_ATTACH_SCHED_CB and
>>>>>> only set that for large pebs. Are you sure the other users (Intel LBR
>>>>>> and PowerPC BHRB) don't need it?
>>>>> I didn't set it for LBR, because the perf_sched_events is always enabled
>>>>> for LBR. But, yes, we should explicitly set the PERF_ATTACH_SCHED_CB
>>>>> for LBR.
>>>>>
>>>>> if (has_branch_stack(event))
>>>>> inc = true;
>>>>>
>>>>>> If they indeed do not require the pmu::sched_task() callback for CPU
>>>>>> events, then I still think the whole perf_sched_cb_{inc,dec}() interface
>>>>> No, LBR requires the pmu::sched_task() callback for CPU events.
>>>>>
>>>>> Now, The LBR registers have to be reset in sched in even for CPU events.
>>>>>
>>>>> To fix the shorter LBR callstack issue for CPU events, we also need to
>>>>> save/restore LBRs in pmu::sched_task().
>>>>> https://lore.kernel.org/lkml/1578495789-95006-4-git-send-email-kan.liang@linux.intel.com/
>>>>>
>>>>>> is confusing at best.
>>>>>>
>>>>>> Can't we do something like this instead?
>>>>>>
>>>>> I think the below patch may have two issues.
>>>>> - PERF_ATTACH_SCHED_CB is required for LBR (maybe PowerPC BHRB as well) now.
>>>>> - We may disable the large PEBS later if not all PEBS events support
>>>>> large PEBS. The PMU need a way to notify the generic code to decrease
>>>>> the nr_sched_task.
>>>> Any updates on this? I've reviewed and tested Kan's patches
>>>> and they all look good.
>>>>
>>>> Maybe we can talk to PPC folks to confirm the BHRB case?
>>> Can we move this forward? I saw patch 3/3 also adds PERF_ATTACH_SCHED_CB
>>> for PowerPC too. But it'd be nice if ppc folks can confirm the change.
>> Sorry I've read the whole thread, but I'm still not entirely sure I
>> understand the question.
> Thanks for your time and sorry about not being clear enough.
>
> We found per-cpu events are not calling pmu::sched_task()
> on context switches. So PERF_ATTACH_SCHED_CB was
> added to indicate the core logic that it needs to invoke the
> callback.
>
> The patch 3/3 added the flag to PPC (for BHRB) with other
> changes (I think it should be split like in the patch 2/3) and
> want to get ACKs from the PPC folks.
Sorry for delay.
I guess first it will be better to split the ppc change to a separate patch,
secondly, we are missing the changes needed in the power_pmu_bhrb_disable()
where perf_sched_cb_dec() needs the "state" to be included.
Maddy
>
> Thanks,
> Namhyung
^ permalink raw reply
* Re: [PATCH v3 0/6] ibmvfc: Protocol definition updates and new targetWWPN Support
From: Martin K. Petersen @ 2020-11-24 3:58 UTC (permalink / raw)
To: james.bottomley, Tyrel Datwyler
Cc: brking, linuxppc-dev, linux-kernel, Martin K . Petersen,
linux-scsi
In-Reply-To: <20201118011104.296999-1-tyreld@linux.ibm.com>
On Tue, 17 Nov 2020 19:10:58 -0600, Tyrel Datwyler wrote:
> Several Management Datagrams (MADs) have been reversioned to add a targetWWPN
> field that is intended to better identify a target over in place of the scsi_id.
> This patchset adds the new protocol definitions and implements support for using
> the new targetWWPN field and exposing the capability to the VIOS. This
> targetWWPN support is a prerequisuite for upcoming channelization/MQ support.
>
> changes in v3:
> * addressed field naming consistency in Patches 2 & 5 in response to [brking]
> * fixed commit log typos
> * fixed bad rebase of Patch 4 such that it now compiles
>
> [...]
Applied to 5.11/scsi-queue, thanks!
[1/6] scsi: ibmvfc: Deduplicate common ibmvfc_cmd init code
https://git.kernel.org/mkp/scsi/c/fad74a1be2db
[2/6] scsi: ibmvfc: Add new fields for version 2 of several MADs
https://git.kernel.org/mkp/scsi/c/c16b8a6d8af1
[3/6] scsi: ibmvfc: Add helper for testing capability flags
https://git.kernel.org/mkp/scsi/c/a318c2b71cce
[4/6] scsi: ibmvfc: Add FC payload retrieval routines for versioned vfcFrames
https://git.kernel.org/mkp/scsi/c/5a9d16f71c26
[5/6] scsi: ibmvfc: Add support for target_wwpn field in v2 MADs and vfcFrame
https://git.kernel.org/mkp/scsi/c/ebc7c74bd2dc
[6/6] scsi: ibmvfc: Advertise client support for targetWWPN using v2 commands
https://git.kernel.org/mkp/scsi/c/e4af87b7079e
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* [PATCH kernel v4 2/8] genirq/irqdomain: Clean legacy IRQ allocation
From: Alexey Kardashevskiy @ 2020-11-24 6:17 UTC (permalink / raw)
To: linux-kernel
Cc: Alexey Kardashevskiy, Marc Zyngier, x86, linux-gpio,
Oliver O'Halloran, Cédric Le Goater, Frederic Barrat,
Thomas Gleixner, Michal Suchánek, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20201124061720.86766-1-aik@ozlabs.ru>
There are 10 users of __irq_domain_alloc_irqs() and only one - IOAPIC -
passes realloc==true. There is no obvious reason for handling this
specific case in the generic code.
This splits out __irq_domain_alloc_irqs_data() to make it clear what
IOAPIC does and makes __irq_domain_alloc_irqs() cleaner.
This should cause no behavioral change.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
include/linux/irqdomain.h | 3 ++
arch/x86/kernel/apic/io_apic.c | 13 +++--
kernel/irq/irqdomain.c | 89 ++++++++++++++++++++--------------
3 files changed, 65 insertions(+), 40 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 71535e87109f..6cc37bba9951 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -470,6 +470,9 @@ static inline struct irq_domain *irq_domain_add_hierarchy(struct irq_domain *par
ops, host_data);
}
+extern int __irq_domain_alloc_irqs_data(struct irq_domain *domain, int virq,
+ unsigned int nr_irqs, int node, void *arg,
+ const struct irq_affinity_desc *affinity);
extern int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
unsigned int nr_irqs, int node, void *arg,
bool realloc,
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 7b3c7e0d4a09..df9c0ab3a119 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -970,9 +970,14 @@ static int alloc_irq_from_domain(struct irq_domain *domain, int ioapic, u32 gsi,
return -1;
}
- return __irq_domain_alloc_irqs(domain, irq, 1,
- ioapic_alloc_attr_node(info),
- info, legacy, NULL);
+ if (irq == -1 || !legacy)
+ return __irq_domain_alloc_irqs(domain, irq, 1,
+ ioapic_alloc_attr_node(info),
+ info, false, NULL);
+
+ return __irq_domain_alloc_irqs_data(domain, irq, 1,
+ ioapic_alloc_attr_node(info),
+ info, NULL);
}
/*
@@ -1006,7 +1011,7 @@ static int alloc_isa_irq_from_domain(struct irq_domain *domain,
return -ENOMEM;
} else {
info->flags |= X86_IRQ_ALLOC_LEGACY;
- irq = __irq_domain_alloc_irqs(domain, irq, 1, node, info, true,
+ irq = __irq_domain_alloc_irqs_data(domain, irq, 1, node, info,
NULL);
if (irq >= 0) {
irq_data = irq_domain_get_irq_data(domain, irq);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index cf8b374b892d..ca5c78366c85 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1386,6 +1386,51 @@ int irq_domain_alloc_irqs_hierarchy(struct irq_domain *domain,
return domain->ops->alloc(domain, irq_base, nr_irqs, arg);
}
+int __irq_domain_alloc_irqs_data(struct irq_domain *domain, int virq,
+ unsigned int nr_irqs, int node, void *arg,
+ const struct irq_affinity_desc *affinity)
+{
+ int i, ret;
+
+ if (domain == NULL) {
+ domain = irq_default_domain;
+ if (WARN(!domain, "domain is NULL; cannot allocate IRQ\n"))
+ return -EINVAL;
+ }
+
+ if (irq_domain_alloc_irq_data(domain, virq, nr_irqs)) {
+ pr_debug("cannot allocate memory for IRQ%d\n", virq);
+ ret = -ENOMEM;
+ goto out_free_irq_data;
+ }
+
+ mutex_lock(&irq_domain_mutex);
+ ret = irq_domain_alloc_irqs_hierarchy(domain, virq, nr_irqs, arg);
+ if (ret < 0) {
+ mutex_unlock(&irq_domain_mutex);
+ goto out_free_irq_data;
+ }
+
+ for (i = 0; i < nr_irqs; i++) {
+ ret = irq_domain_trim_hierarchy(virq + i);
+ if (ret) {
+ mutex_unlock(&irq_domain_mutex);
+ goto out_free_irq_data;
+ }
+ }
+
+ for (i = 0; i < nr_irqs; i++) {
+ irq_domain_insert_irq(virq + i);
+ }
+ mutex_unlock(&irq_domain_mutex);
+
+ return virq;
+
+out_free_irq_data:
+ irq_domain_free_irq_data(virq, nr_irqs);
+ return ret;
+}
+
/**
* __irq_domain_alloc_irqs - Allocate IRQs from domain
* @domain: domain to allocate from
@@ -1412,7 +1457,7 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
unsigned int nr_irqs, int node, void *arg,
bool realloc, const struct irq_affinity_desc *affinity)
{
- int i, ret, virq;
+ int ret, virq;
if (domain == NULL) {
domain = irq_default_domain;
@@ -1420,47 +1465,19 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
return -EINVAL;
}
- if (realloc && irq_base >= 0) {
- virq = irq_base;
- } else {
- virq = irq_domain_alloc_descs(irq_base, nr_irqs, 0, node,
- affinity);
- if (virq < 0) {
- pr_debug("cannot allocate IRQ(base %d, count %d)\n",
- irq_base, nr_irqs);
- return virq;
- }
+ virq = irq_domain_alloc_descs(irq_base, nr_irqs, 0, node, affinity);
+ if (virq < 0) {
+ pr_debug("cannot allocate IRQ(base %d, count %d)\n",
+ irq_base, nr_irqs);
+ return virq;
}
- if (irq_domain_alloc_irq_data(domain, virq, nr_irqs)) {
- pr_debug("cannot allocate memory for IRQ%d\n", virq);
- ret = -ENOMEM;
+ ret = __irq_domain_alloc_irqs_data(domain, virq, nr_irqs, node, arg, affinity);
+ if (ret <= 0)
goto out_free_desc;
- }
-
- mutex_lock(&irq_domain_mutex);
- ret = irq_domain_alloc_irqs_hierarchy(domain, virq, nr_irqs, arg);
- if (ret < 0) {
- mutex_unlock(&irq_domain_mutex);
- goto out_free_irq_data;
- }
-
- for (i = 0; i < nr_irqs; i++) {
- ret = irq_domain_trim_hierarchy(virq + i);
- if (ret) {
- mutex_unlock(&irq_domain_mutex);
- goto out_free_irq_data;
- }
- }
-
- for (i = 0; i < nr_irqs; i++)
- irq_domain_insert_irq(virq + i);
- mutex_unlock(&irq_domain_mutex);
return virq;
-out_free_irq_data:
- irq_domain_free_irq_data(virq, nr_irqs);
out_free_desc:
irq_free_descs(virq, nr_irqs);
return ret;
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox