LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH printk v2 2/5] printk: remove safe buffers
From: John Ogness @ 2021-03-31  7:59 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sergey Senozhatsky, Alexey Kardashevskiy, Paul Mackerras,
	Tiezhu Yang, Rafael Aquini, Aneesh Kumar K.V, Peter Zijlstra,
	Yue Hu, Jordan Niethe, Kees Cook, Paul E. McKenney,
	Alistair Popple, Guilherme G. Piccoli, Nicholas Piggin,
	Steven Rostedt, Thomas Gleixner, kexec, linux-kernel,
	Sergey Senozhatsky, Eric Biederman, Andrew Morton, linuxppc-dev
In-Reply-To: <20210330153512.1182-3-john.ogness@linutronix.de>

On 2021-03-30, John Ogness <john.ogness@linutronix.de> wrote:
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index e971c0a9ec9e..f090d6a1b39e 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1772,16 +1759,21 @@ static struct task_struct *console_owner;
>  static bool console_waiter;
>  
>  /**
> - * console_lock_spinning_enable - mark beginning of code where another
> + * console_lock_spinning_enable_irqsave - mark beginning of code where another
>   *	thread might safely busy wait
>   *
>   * This basically converts console_lock into a spinlock. This marks
>   * the section where the console_lock owner can not sleep, because
>   * there may be a waiter spinning (like a spinlock). Also it must be
>   * ready to hand over the lock at the end of the section.
> + *
> + * This disables interrupts because the hand over to a waiter must not be
> + * interrupted until the hand over is completed (@console_waiter is cleared).
>   */
> -static void console_lock_spinning_enable(void)
> +static void console_lock_spinning_enable_irqsave(unsigned long *flags)

I missed the prototype change for the !CONFIG_PRINTK case, resulting in:

linux/kernel/printk/printk.c:2707:3: error: implicit declaration of function ‘console_lock_spinning_enable_irqsave’; did you mean ‘console_lock_spinning_enable’? [-Werror=implicit-function-declaration]
   console_lock_spinning_enable_irqsave(&flags);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   console_lock_spinning_enable

Will be fixed for v3.

(I have now officially added !CONFIG_PRINTK to my CI tests.)

John Ogness

^ permalink raw reply

* Re: [PATCH v4 11/46] KVM: PPC: Book3S HV: Ensure MSR[HV] is always clear in guest MSR
From: Paul Mackerras @ 2021-03-31  4:58 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20210323010305.1045293-12-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:30AM +1000, Nicholas Piggin wrote:
> Rather than clear the HV bit from the MSR at guest entry, make it clear
> that the hypervisor does not allow the guest to set the bit.
> 
> The HV clear is kept in guest entry for now, but a future patch will
> warn if it's not present.

Will warn if it *is* present, surely?

> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Acked-by: Paul Mackerras <paulus@ozlabs.org>

^ permalink raw reply

* Re: [PATCH v4 10/46] KVM: PPC: Book3S HV: Ensure MSR[ME] is always set in guest MSR
From: Paul Mackerras @ 2021-03-31  4:56 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: Fabiano Rosas, linuxppc-dev, kvm-ppc, Daniel Axtens
In-Reply-To: <20210323010305.1045293-11-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:29AM +1000, Nicholas Piggin wrote:
> Rather than add the ME bit to the MSR at guest entry, make it clear
> that the hypervisor does not allow the guest to clear the bit.
> 
> The ME set is kept in guest entry for now, but a future patch will
> warn if it's not present.
> 
> Reviewed-by: Daniel Axtens <dja@axtens.net>
> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Acked-by: Paul Mackerras <paulus@ozlabs.org>

^ permalink raw reply

* Re: [PATCH v4 09/46] powerpc/64s: remove KVM SKIP test from instruction breakpoint handler
From: Paul Mackerras @ 2021-03-31  4:54 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: Fabiano Rosas, linuxppc-dev, kvm-ppc, Daniel Axtens
In-Reply-To: <20210323010305.1045293-10-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:28AM +1000, Nicholas Piggin wrote:
> The code being executed in KVM_GUEST_MODE_SKIP is hypervisor code with
> MSR[IR]=0, so the faults of concern are the d-side ones caused by access
> to guest context by the hypervisor.
> 
> Instruction breakpoint interrupts are not a concern here. It's unlikely
> any good would come of causing breaks in this code, but skipping the
> instruction that caused it won't help matters (e.g., skip the mtmsr that
> sets MSR[DR]=0 or clears KVM_GUEST_MODE_SKIP).
> 
> Reviewed-by: Daniel Axtens <dja@axtens.net>
> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

It might be worth noting in the commit message that the 0x1300
interrupt was dropped from the architecture a long time ago and is not
generated by P7, P8, P9 or P10.

Acked-by: Paul Mackerras <paulus@ozlabs.org>

^ permalink raw reply

* Re: [PATCH v4 08/46] powerpc/64s: Remove KVM handler support from CBE_RAS interrupts
From: Paul Mackerras @ 2021-03-31  4:41 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: linuxppc-dev, kvm-ppc, Fabiano Rosas
In-Reply-To: <20210323010305.1045293-9-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:27AM +1000, Nicholas Piggin wrote:
> Cell does not support KVM.
> 
> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Acked-by: Paul Mackerras <paulus@ozlabs.org>

^ permalink raw reply

* Re: [PATCH v4 07/46] KVM: PPC: Book3S HV: Fix CONFIG_SPAPR_TCE_IOMMU=n default hcalls
From: Paul Mackerras @ 2021-03-31  4:39 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: linuxppc-dev, kvm-ppc, Daniel Axtens
In-Reply-To: <20210323010305.1045293-8-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:26AM +1000, Nicholas Piggin wrote:
> This config option causes the warning in init_default_hcalls to fire
> because the TCE handlers are in the default hcall list but not
> implemented.
> 
> Reviewed-by: Daniel Axtens <dja@axtens.net>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Acked-by: Paul Mackerras <paulus@ozlabs.org>

^ permalink raw reply

* Re: [PATCH v4 05/46] KVM: PPC: Book3S HV: Remove redundant mtspr PSPB
From: Paul Mackerras @ 2021-03-31  4:35 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: Daniel Axtens, linuxppc-dev, kvm-ppc, Fabiano Rosas
In-Reply-To: <20210323010305.1045293-6-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:24AM +1000, Nicholas Piggin wrote:
> This SPR is set to 0 twice when exiting the guest.
> 
> Suggested-by: Fabiano Rosas <farosas@linux.ibm.com>
> Reviewed-by: Daniel Axtens <dja@axtens.net>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Acked-by: Paul Mackerras <paulus@ozlabs.org>

^ permalink raw reply

* Re: [PATCH v4 06/46] KVM: PPC: Book3S HV: remove unused kvmppc_h_protect argument
From: Paul Mackerras @ 2021-03-31  4:38 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: linuxppc-dev, kvm-ppc, Daniel Axtens
In-Reply-To: <20210323010305.1045293-7-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:25AM +1000, Nicholas Piggin wrote:
> The va argument is not used in the function or set by its asm caller,
> so remove it to be safe.
> 
> Reviewed-by: Daniel Axtens <dja@axtens.net>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Acked-by: Paul Mackerras <paulus@ozlabs.org>

^ permalink raw reply

* Re: [PATCH] powerpc/pseries: Only register vio drivers if vio bus exists
From: Michael Ellerman @ 2021-03-31  4:38 UTC (permalink / raw)
  To: Paul Menzel; +Cc: linuxppc-dev
In-Reply-To: <37664153-c31e-bd20-71b4-9afa049dc60a@molgen.mpg.de>

Paul Menzel <pmenzel@molgen.mpg.de> writes:
> Am 16.03.21 um 02:09 schrieb Michael Ellerman:
>> The vio bus is a fake bus, which we use on pseries LPARs (guests) to
>> discover devices provided by the hypervisor. There's no need or sense
>> in creating the vio bus on bare metal systems.
>> 
>> Which is why commit 4336b9337824 ("powerpc/pseries: Make vio and
>> ibmebus initcalls pseries specific") made the initialisation of the
>> vio bus only happen in LPARs.
>> 
>> However as a result of that commit we now see errors at boot on bare
>> metal systems:
>> 
>>    Driver 'hvc_console' was unable to register with bus_type 'vio' because the bus was not initialized.
>>    Driver 'tpm_ibmvtpm' was unable to register with bus_type 'vio' because the bus was not initialized.
>> 
>> This happens because those drivers are built-in, and are calling
>> vio_register_driver(). It in turn calls driver_register() with a
>> reference to vio_bus_type, but we haven't registered vio_bus_type with
>> the driver core.
>> 
>> Fix it by also guarding vio_register_driver() with a check to see if
>> we are on pseries.
>> 
>> Fixes: 4336b9337824 ("powerpc/pseries: Make vio and ibmebus initcalls pseries specific")
>> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> ---
>>   arch/powerpc/platforms/pseries/vio.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>> 
>> diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
>> index 9cb4fc839fd5..429053d0402a 100644
>> --- a/arch/powerpc/platforms/pseries/vio.c
>> +++ b/arch/powerpc/platforms/pseries/vio.c
>> @@ -1285,6 +1285,10 @@ static int vio_bus_remove(struct device *dev)
>>   int __vio_register_driver(struct vio_driver *viodrv, struct module *owner,
>>   			  const char *mod_name)
>>   {
>> +	// vio_bus_type is only initialised for pseries
>> +	if (!machine_is(pseries))
>> +		return -ENODEV;
>> +
>>   	pr_debug("%s: driver %s registering\n", __func__, viodrv->name);
>>   
>>   	/* fill in 'struct driver' fields */
>
> Thank you. The errors are gone now.
>
> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # IBM S822L (POWER8)
>
> As it fixes a commit from Linux 5.8, should it be tagged for the stable 
> releases, or is it going to be picked up automatically due to the Fixes tag?

It's not what I'd describe as a bad bug, so I'm not that inclined to
tag it for stable.

But given it has a Fixes tag, and is quite small, the bots will probably
backport it automatically.

cheers

^ permalink raw reply

* Re: [PATCH v4 04/46] KVM: PPC: Book3S HV: Prevent radix guests from setting LPCR[TC]
From: Paul Mackerras @ 2021-03-31  4:34 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20210323010305.1045293-5-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:23AM +1000, Nicholas Piggin wrote:
> This bit only applies to hash partitions.
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
>  arch/powerpc/kvm/book3s_hv.c        | 6 ++++++
>  arch/powerpc/kvm/book3s_hv_nested.c | 3 +--
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index c5de7e3f22b6..1ffb0902e779 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1645,6 +1645,12 @@ static int kvm_arch_vcpu_ioctl_set_sregs_hv(struct kvm_vcpu *vcpu,
>   */
>  unsigned long kvmppc_filter_lpcr_hv(struct kvmppc_vcore *vc, unsigned long lpcr)
>  {
> +	struct kvm *kvm = vc->kvm;
> +
> +	/* LPCR_TC only applies to HPT guests */
> +	if (kvm_is_radix(kvm))
> +		lpcr &= ~LPCR_TC;

I'm not sure I see any benefit from this, and it is a little extra
complexity.

>  	/* On POWER8 and above, userspace can modify AIL */
>  	if (!cpu_has_feature(CPU_FTR_ARCH_207S))
>  		lpcr &= ~LPCR_AIL;
> diff --git a/arch/powerpc/kvm/book3s_hv_nested.c b/arch/powerpc/kvm/book3s_hv_nested.c
> index f7b441b3eb17..851e3f527eb2 100644
> --- a/arch/powerpc/kvm/book3s_hv_nested.c
> +++ b/arch/powerpc/kvm/book3s_hv_nested.c
> @@ -140,8 +140,7 @@ static void sanitise_hv_regs(struct kvm_vcpu *vcpu, struct hv_guest_state *hr)
>  	/*
>  	 * Don't let L1 change LPCR bits for the L2 except these:
>  	 */
> -	mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD |
> -		LPCR_LPES | LPCR_MER;
> +	mask = LPCR_DPFD | LPCR_ILE | LPCR_AIL | LPCR_LD | LPCR_LPES | LPCR_MER;

Doesn't this make it completely impossible to set TC for any guest?

Paul.

^ permalink raw reply

* Re: [PATCH v4 03/46] KVM: PPC: Book3S HV: Disallow LPCR[AIL] to be set to 1 or 2
From: Paul Mackerras @ 2021-03-31  4:28 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: linuxppc-dev, kvm-ppc, Fabiano Rosas
In-Reply-To: <20210323010305.1045293-4-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:22AM +1000, Nicholas Piggin wrote:
> These are already disallowed by H_SET_MODE from the guest, also disallow
> these by updating LPCR directly.
> 
> AIL modes can affect the host interrupt behaviour while the guest LPCR
> value is set, so filter it here too.
> 
> Suggested-by: Fabiano Rosas <farosas@linux.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Acked-by: Paul Mackerras <paulus@ozlabs.org>

^ permalink raw reply

* Re: [PATCH v4 02/46] KVM: PPC: Book3S HV: Add a function to filter guest LPCR bits
From: Paul Mackerras @ 2021-03-31  4:08 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20210323010305.1045293-3-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:21AM +1000, Nicholas Piggin wrote:
> Guest LPCR depends on hardware type, and future changes will add
> restrictions based on errata and guest MMU mode. Move this logic
> to a common function and use it for the cases where the guest
> wants to update its LPCR (or the LPCR of a nested guest).

[snip]

> @@ -4641,8 +4662,9 @@ void kvmppc_update_lpcr(struct kvm *kvm, unsigned long lpcr, unsigned long mask)
>  		struct kvmppc_vcore *vc = kvm->arch.vcores[i];
>  		if (!vc)
>  			continue;
> +
>  		spin_lock(&vc->lock);
> -		vc->lpcr = (vc->lpcr & ~mask) | lpcr;
> +		vc->lpcr = kvmppc_filter_lpcr_hv(vc, (vc->lpcr & ~mask) | lpcr);

This change seems unnecessary, since kvmppc_update_lpcr is called only
to update MMU configuration bits, not as a result of any action by
userspace or a nested hypervisor.  It's also beyond the scope of what
was mentioned in the commit message.

Paul.

^ permalink raw reply

* Re: [PATCH v4 01/46] KVM: PPC: Book3S HV: Nested move LPCR sanitising to sanitise_hv_regs
From: Paul Mackerras @ 2021-03-31  2:47 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20210323010305.1045293-2-npiggin@gmail.com>

On Tue, Mar 23, 2021 at 11:02:20AM +1000, Nicholas Piggin wrote:
> This will get a bit more complicated in future patches. Move it
> into the helper function.

This does change L1-visible behaviour, because now the L1 hypervisor
can see the LPCR bits that L0 is using, whereas previously it couldn't
(and that was deliberate).  I can't point to a specific scenario where
that is a real problem, but nevertheless it worries me.  And the
behaviour change should have been mentioned in the commit message at
least.

Paul.

^ permalink raw reply

* Re: [PATCH] cxl: Fix couple of spellings
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: linuxppc-dev, gregkh, Bhaskar Chowdhury, arnd, fbarrat,
	linux-kernel, ajd
  Cc: rdunlap
In-Reply-To: <20210322023307.168754-1-unixbhaskar@gmail.com>

On Mon, 22 Mar 2021 08:03:07 +0530, Bhaskar Chowdhury wrote:
> s/filesytem/filesystem/
> s/symantics/semantics/

Applied to powerpc/next.

[1/1] cxl: Fix couple of spellings
      https://git.kernel.org/powerpc/c/e23ecdf9fd87c547a3ac55bcebaf7df28df2fab0

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/xive: use true and false for bool variable
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: mpe, Yang Li; +Cc: paulus, linuxppc-dev, linux-kernel
In-Reply-To: <1615793096-83758-1-git-send-email-yang.lee@linux.alibaba.com>

On Mon, 15 Mar 2021 15:24:56 +0800, Yang Li wrote:
> fixed the following coccicheck:
> ./arch/powerpc/sysdev/xive/spapr.c:552:8-9: WARNING: return of 0/1 in
> function 'xive_spapr_match' with return type bool

Applied to powerpc/next.

[1/1] powerpc/xive: use true and false for bool variable
      https://git.kernel.org/powerpc/c/9214cf0f48cac3c6aa86f34e14969b5eccb72fad

cheers

^ permalink raw reply

* Re: [PATCH] powerpc: mm: book3s64: Fix a typo in the file mmu_context.c
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: npiggin, linuxppc-dev, Bhaskar Chowdhury, mpe, benh, aneesh.kumar,
	linux-kernel, paulus
  Cc: rdunlap
In-Reply-To: <20210312112537.4585-1-unixbhaskar@gmail.com>

On Fri, 12 Mar 2021 16:55:37 +0530, Bhaskar Chowdhury wrote:
> s/detalis/details/

Applied to powerpc/next.

[1/1] powerpc: mm: book3s64: Fix a typo in the file mmu_context.c
      https://git.kernel.org/powerpc/c/7a7d744ffe87ae10ab98004d1a6ca1f691af58e1

cheers

^ permalink raw reply

* Re: [PATCH] powerpc: kernel: Trivial typo fix in the file kgdb.c
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: linuxppc-dev, Bhaskar Chowdhury, mpe, jniethe5, benh, alistair,
	linux-kernel, paulus
  Cc: rdunlap
In-Reply-To: <20210317090413.120891-1-unixbhaskar@gmail.com>

On Wed, 17 Mar 2021 14:34:13 +0530, Bhaskar Chowdhury wrote:
> s/procesing/processing/

Applied to powerpc/next.

[1/1] powerpc: kernel: Trivial typo fix in the file kgdb.c
      https://git.kernel.org/powerpc/c/89f7d2927ae16ea470d29234447763826e40c6cf

cheers

^ permalink raw reply

* Re: [PATCH] powerpc: kernel: Trivial spelling fixes throughout the file head_fsl_booke.S
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: linuxppc-dev, Bhaskar Chowdhury, rppt, mpe, christophe.leroy,
	benh, linux-kernel, oss, paulus, akpm
  Cc: rdunlap
In-Reply-To: <20210314220436.3417083-1-unixbhaskar@gmail.com>

On Mon, 15 Mar 2021 03:34:36 +0530, Bhaskar Chowdhury wrote:
> Trivial spelling fixes throughout the file.

Applied to powerpc/next.

[1/1] powerpc: kernel: Trivial spelling fixes throughout the file head_fsl_booke.S
      https://git.kernel.org/powerpc/c/f239873fcd953557ba9a9781d10ca95c0594e2b3

cheers

^ permalink raw reply

* Re: [PATCH] arch: powerpc: kernel: Change droping to dropping in the file traps.c
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: npiggin, linuxppc-dev, Bhaskar Chowdhury, mikey, mpe, jniethe5,
	christophe.leroy, benh, alistair, linux-kernel, paulus
  Cc: rdunlap
In-Reply-To: <20210224075547.763063-1-unixbhaskar@gmail.com>

On Wed, 24 Feb 2021 13:25:47 +0530, Bhaskar Chowdhury wrote:
> s/droping/dropping/

Applied to powerpc/next.

[1/1] arch: powerpc: kernel: Change droping to dropping in the file traps.c
      https://git.kernel.org/powerpc/c/5c4a4802b9ac8c1acdf2250fad3f8f2d6254f9c7

cheers

^ permalink raw reply

* Re: [PATCH v5] powerpc/uprobes: Validation for prefixed instruction
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: mpe, Ravi Bangoria
  Cc: jniethe5, oleg, rostedt, linux-kernel, paulus, sandipan,
	naveen.n.rao, linuxppc-dev
In-Reply-To: <20210311091538.368590-1-ravi.bangoria@linux.ibm.com>

On Thu, 11 Mar 2021 14:45:38 +0530, Ravi Bangoria wrote:
> As per ISA 3.1, prefixed instruction should not cross 64-byte
> boundary. So don't allow Uprobe on such prefixed instruction.
> 
> There are two ways probed instruction is changed in mapped pages.
> First, when Uprobe is activated, it searches for all the relevant
> pages and replace instruction in them. In this case, if that probe
> is on the 64-byte unaligned prefixed instruction, error out
> directly. Second, when Uprobe is already active and user maps a
> relevant page via mmap(), instruction is replaced via mmap() code
> path. But because Uprobe is invalid, entire mmap() operation can
> not be stopped. In this case just print an error and continue.

Applied to powerpc/next.

[1/1] powerpc/uprobes: Validation for prefixed instruction
      https://git.kernel.org/powerpc/c/d943bc742a6aabc578b6b62a713ceedf8bf16623

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/64s: Fix hash fault to use TRAP accessor
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20210316105205.407767-1-npiggin@gmail.com>

On Tue, 16 Mar 2021 20:52:05 +1000, Nicholas Piggin wrote:
> Hash faults use the trap vector to decide whether this is an
> instruction or data fault. This should use the TRAP accessor
> rather than open access regs->trap.
> 
> This won't cause a problem at the moment because 64s only uses
> trap flags for system call interrupts (the norestart flag), but
> that could change if any other trap flags get used in future.

Applied to powerpc/next.

[1/1] powerpc/64s: Fix hash fault to use TRAP accessor
      https://git.kernel.org/powerpc/c/1479e3d3b7559133b0a107772b5841e9c2cad450

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/prom: Mark identical_pvr_fixup as __init
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: Michael Ellerman, Nathan Chancellor
  Cc: Paul Mackerras, linuxppc-dev, linux-kernel, clang-built-linux
In-Reply-To: <20210302200829.2680663-1-nathan@kernel.org>

On Tue, 2 Mar 2021 13:08:29 -0700, Nathan Chancellor wrote:
> If identical_pvr_fixup() is not inlined, there are two modpost warnings:
> 
> WARNING: modpost: vmlinux.o(.text+0x54e8): Section mismatch in reference
> from the function identical_pvr_fixup() to the function
> .init.text:of_get_flat_dt_prop()
> The function identical_pvr_fixup() references
> the function __init of_get_flat_dt_prop().
> This is often because identical_pvr_fixup lacks a __init
> annotation or the annotation of of_get_flat_dt_prop is wrong.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/prom: Mark identical_pvr_fixup as __init
      https://git.kernel.org/powerpc/c/1ef1dd9c7ed27b080445e1576e8a05957e0e4dfc

cheers

^ permalink raw reply

* Re: [PATCH] selftests: powerpc: unmark non-kernel-doc comments
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: linux-kernel, Randy Dunlap; +Cc: linuxppc-dev
In-Reply-To: <20210325200820.16594-1-rdunlap@infradead.org>

On Thu, 25 Mar 2021 13:08:20 -0700, Randy Dunlap wrote:
> Drop the 'beginning of kernel-doc' notation markers (/**)
> in places that are not in kernel-doc format.

Applied to powerpc/next.

[1/1] selftests: powerpc: unmark non-kernel-doc comments
      https://git.kernel.org/powerpc/c/dfc4ae3372182a168146745def03d877f31fcf2f

cheers

^ permalink raw reply

* Re: [PATCH v2] selftests/powerpc: Fix L1D flushing tests for Power10
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: Russell Currey, linuxppc-dev; +Cc: dja
In-Reply-To: <20210223070227.2916871-1-ruscur@russell.cc>

On Tue, 23 Feb 2021 17:02:27 +1000, Russell Currey wrote:
> The rfi_flush and entry_flush selftests work by using the PM_LD_MISS_L1
> perf event to count L1D misses.  The value of this event has changed
> over time:
> 
> - Power7 uses 0x400f0
> - Power8 and Power9 use both 0x400f0 and 0x3e054
> - Power10 uses only 0x3e054
> 
> [...]

Applied to powerpc/next.

[1/1] selftests/powerpc: Fix L1D flushing tests for Power10
      https://git.kernel.org/powerpc/c/3a72c94ebfb1f171eba0715998010678a09ec796

cheers

^ permalink raw reply

* Re: [PATCH v7] powerpc/irq: Inline call_do_irq() and call_do_softirq()
From: Michael Ellerman @ 2021-03-31  1:09 UTC (permalink / raw)
  To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20210320122227.345427-1-mpe@ellerman.id.au>

On Sat, 20 Mar 2021 23:22:27 +1100, Michael Ellerman wrote:
> call_do_irq() and call_do_softirq() are simple enough to be
> worth inlining.
> 
> Inlining them avoids an mflr/mtlr pair plus a save/reload on stack. It
> also allows GCC to keep the saved ksp_limit in an nonvolatile reg.
> 
> This is inspired from S390 arch. Several other arches do more or
> less the same. The way sparc arch does seems odd thought.

Applied to powerpc/next.

[1/1] powerpc/irq: Inline call_do_irq() and call_do_softirq()
      https://git.kernel.org/powerpc/c/48cf12d88969bd4238b8769767eb476970319d93

cheers

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox