* Re: [PATCH 0/1] PPC32: fix ptrace() access to FPU registers
From: Daniel Axtens @ 2019-06-17 1:19 UTC (permalink / raw)
To: Radu Rendec, linuxppc-dev; +Cc: Radu Rendec, Paul Mackerras, Oleg Nesterov
In-Reply-To: <20190610232758.19010-1-radu.rendec@gmail.com>
Radu Rendec <radu.rendec@gmail.com> writes:
> Hi Everyone,
>
> I'm following up on the ptrace() problem that I reported a few days ago.
> I believe my version of the code handles all cases correctly. While the
> problem essentially boils down to dividing the fpidx by 2 on PPC32, it
> becomes tricky when the same code must work correctly on both PPC32 and
> PPC64.
>
> One other thing that I believe was handled incorrectly in the previous
> version is the unused half of fpscr on PPC32. Note that while PT_FPSCR
> is defined as (PT_FPR0 + 2*32 + 1), making only the upper half visible,
> PT_FPR0 + 2*32 still corresponds to a possible address that userspace
> can pass. In that case, comparing fpidx to (PT_FPSCR - PT_FPR0) would
> cause an invalid access to the FPU registers array.
>
> I tested the patch on 4.9.179, but that part of the code is identical in
> recent kernels so it should work just the same.
>
> I wrote a simple test program than can be used to quickly test (on an
> x86_64 host) that all cases are handled correctly for both PPC32/PPC64.
> The code is included below.
>
> I also tested with gdbserver (test patch included below) and verified
> that it generates two ptrace() calls for each FPU register, with
> addresses between 0xc0 and 0x1bc.
Thanks for looking in to this. I can confirm your issue. What I'm
currently wondering is: what is the behaviour with a 32-bit userspace on
a 64-bit kernel? Should they also be going down the 32-bit path as far
as calculating offsets goes?
Regards,
Daniel
>
> 8<--------------- Makefile ---------------------------------------------
> .PHONY: all clean
>
> all: ptrace-fpregs-32 ptrace-fpregs-64
>
> ptrace-fpregs-32: ptrace-fpregs.c
> $(CC) -o ptrace-fpregs-32 -Wall -O2 -m32 ptrace-fpregs.c
>
> ptrace-fpregs-64: ptrace-fpregs.c
> $(CC) -o ptrace-fpregs-64 -Wall -O2 ptrace-fpregs.c
>
> clean:
> rm -f ptrace-fpregs-32 ptrace-fpregs-64
> 8<--------------- ptrace-fpregs.c --------------------------------------
> #include <stdio.h>
> #include <errno.h>
>
> #define PT_FPR0 48
>
> #ifndef __x86_64
>
> #define PT_FPR31 (PT_FPR0 + 2*31)
> #define PT_FPSCR (PT_FPR0 + 2*32 + 1)
>
> #else
>
> #define PT_FPSCR (PT_FPR0 + 32)
>
> #endif
>
> int test_access(unsigned long addr)
> {
> int ret;
>
> do {
> unsigned long index, fpidx;
>
> ret = -EIO;
>
> /* convert to index and check */
> index = addr / sizeof(long);
> if ((addr & (sizeof(long) - 1)) || (index > PT_FPSCR))
> break;
>
> if (index < PT_FPR0) {
> ret = printf("ptrace_put_reg(%lu)", index);
> break;
> }
>
> ret = 0;
> #ifndef __x86_64
> if (index == PT_FPSCR - 1) {
> /* corner case for PPC32; do nothing */
> printf("corner_case");
> break;
> }
> #endif
> if (index == PT_FPSCR) {
> printf("fpscr");
> break;
> }
>
> /*
> * FPR is always 64-bit; on PPC32, userspace does two 32-bit
> * accesses. Add bit2 to allow accessing the upper half on
> * 32-bit; on 64-bit, bit2 is always 0 (we validate it above).
> */
> fpidx = (addr - PT_FPR0 * sizeof(long)) / 8;
> printf("TS_FPR[%lu] + %lu", fpidx, addr & 4);
> break;
> } while (0);
>
> return ret;
> }
>
> int main(void)
> {
> unsigned long addr;
> int rc;
>
> for (addr = 0; addr < PT_FPSCR * sizeof(long) + 16; addr++) {
> printf("0x%04lx: ", addr);
> rc = test_access(addr);
> if (rc < 0)
> printf("!err!");
> printf("\t<%d>\n", rc);
> }
>
> return 0;
> }
> 8<--------------- gdb.patch --------------------------------------------
> --- gdb/gdbserver/linux-low.c.orig 2019-06-10 11:45:53.810882669 -0400
> +++ gdb/gdbserver/linux-low.c 2019-06-10 11:49:32.272929766 -0400
> @@ -4262,6 +4262,8 @@ store_register (struct regcache *regcach
> pid = lwpid_of (get_thread_lwp (current_inferior));
> for (i = 0; i < size; i += sizeof (PTRACE_XFER_TYPE))
> {
> + printf("writing register #%d offset %d at address %#x\n",
> + regno, i, (unsigned int)regaddr);
> errno = 0;
> ptrace (PTRACE_POKEUSER, pid,
> /* Coerce to a uintptr_t first to avoid potential gcc warning
> 8<----------------------------------------------------------------------
>
> Radu Rendec (1):
> PPC32: fix ptrace() access to FPU registers
>
> arch/powerpc/kernel/ptrace.c | 85 ++++++++++++++++++++++--------------
> 1 file changed, 52 insertions(+), 33 deletions(-)
>
> --
> 2.20.1
^ permalink raw reply
* Re: [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state
From: Daniel Axtens @ 2019-06-16 23:56 UTC (permalink / raw)
To: Nayna
Cc: linux-efi, Ard Biesheuvel, Eric Richter, Nayna Jain, linux-kernel,
Mimi Zohar, Claudio Carvalho, Matthew Garret, linuxppc-dev,
Paul Mackerras, Jeremy Kerr, linux-integrity
In-Reply-To: <b2cedb05-6373-b357-f35c-bc112c78a6fc@linux.vnet.ibm.com>
Hi Nayna,
>> I guess I also somewhat object to calling it a 'backend' if we're using
>> it as a version scheme. I think the skiboot storage backends are true
>> backends - they provide different implementations of the same
>> functionality with the same API, but this seems like you're using it to
>> indicate different functionality. It seems like we're using it as if it
>> were called OPAL_SECVAR_VERSION.
>
> We are changing how we are exposing the version to the kernel. The
> version will be exposed as device-tree entry rather than a OPAL runtime
> service. We are not tied to the name "backend", we can switch to calling
> it as "scheme" unless there is a better name.
This sounds like a good approach to me.
Kind regards,
Daniel
>
> Thanks & Regards,
> - Nayna
^ permalink raw reply
* Re: [PATCH] powerpc/booke: fix fast syscall entry on SMP
From: Michael Ellerman @ 2019-06-16 12:23 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c0ea3c32c7ed892501ddcc7a169948c305081551.1560433897.git.christophe.leroy@c-s.fr>
On Thu, 2019-06-13 at 13:52:30 UTC, Christophe Leroy wrote:
> Use r10 instead of r9 to calculate CPU offset as r9 contains
> the value from SRR1 which is used later.
>
> Fixes: 1a4b739bbb4f ("powerpc/32: implement fast entry for syscalls on BOOKE")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/e8732ffa2e096d433c3f2349b871d43ed0d39f5c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32: fix build failure on book3e with KVM
From: Michael Ellerman @ 2019-06-16 12:23 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <97664671a229a4240bfb22f69ec4743e837c2b83.1558600628.git.christophe.leroy@c-s.fr>
On Thu, 2019-05-23 at 08:39:27 UTC, Christophe Leroy wrote:
> Build failure was introduced by the commit identified below,
> due to missed macro expension leading to wrong called function's name.
>
> arch/powerpc/kernel/head_fsl_booke.o: In function `SystemCall':
> arch/powerpc/kernel/head_fsl_booke.S:416: undefined reference to `kvmppc_handler_BOOKE_INTERRUPT_SYSCALL_SPRN_SRR1'
> Makefile:1052: recipe for target 'vmlinux' failed
>
> The called function should be kvmppc_handler_8_0x01B(). This patch fixes it.
>
> Reported-by: Paul Mackerras <paulus@ozlabs.org>
> Fixes: 1a4b739bbb4f ("powerpc/32: implement fast entry for syscalls on BOOKE")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/82f6e266f8123d7938713c0e10c03aa655b3e68a
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: fix initial setup of segment registers on secondary CPU
From: Michael Ellerman @ 2019-06-16 12:23 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
erhard_f
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <be07403806abc56ec027f6d47468411876e18bb5.1560267983.git.christophe.leroy@c-s.fr>
On Tue, 2019-06-11 at 15:47:20 UTC, Christophe Leroy wrote:
> The patch referenced below moved the loading of segment registers
> out of load_up_mmu() in order to do it earlier in the boot sequence.
> However, the secondary CPU still needs it to be done when loading up
> the MMU.
>
> Reported-by: Erhard F. <erhard_f@mailbox.org>
> Fixes: 215b823707ce ("powerpc/32s: set up an early static hash table for KASAN")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/b7f8b440f3001cc1775c028f0a783786113c2ae3
cheers
^ permalink raw reply
* Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
From: Andreas Schwab @ 2019-06-16 10:13 UTC (permalink / raw)
To: christophe leroy
Cc: j.neuschaefer, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <a76f7759-a407-3d9a-0f43-654fd7ea0b1e@c-s.fr>
On Jun 16 2019, christophe leroy <christophe.leroy@c-s.fr> wrote:
> If any of registers IBATs 4 to 7 are used, could you adjust
> CONFIG_ETEXT_SHIFT so that only IBATs 0 to 3 be used, and check if
> suspend/resume works when IBATs 4 to 7 are not used ?
I forgot to remove my patch. With only 0-3 used, suspend/resume works.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
From: Andreas Schwab @ 2019-06-16 9:29 UTC (permalink / raw)
To: christophe leroy
Cc: j.neuschaefer, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <a76f7759-a407-3d9a-0f43-654fd7ea0b1e@c-s.fr>
On Jun 16 2019, christophe leroy <christophe.leroy@c-s.fr> wrote:
> If any of registers IBATs 4 to 7 are used
Nope.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
From: Andreas Schwab @ 2019-06-16 8:45 UTC (permalink / raw)
To: christophe leroy
Cc: j.neuschaefer, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1c271e47-6917-2f29-97b6-f3160ddf5117@c-s.fr>
On Jun 16 2019, christophe leroy <christophe.leroy@c-s.fr> wrote:
> Le 15/06/2019 à 14:28, Andreas Schwab a écrit :
>> On Feb 21 2019, Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>
>>> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
>>> index a000768a5cc9..6e56a6240bfa 100644
>>> --- a/arch/powerpc/mm/pgtable_32.c
>>> +++ b/arch/powerpc/mm/pgtable_32.c
>>> @@ -353,7 +353,10 @@ void mark_initmem_nx(void)
>>> unsigned long numpages = PFN_UP((unsigned long)_einittext) -
>>> PFN_DOWN((unsigned long)_sinittext);
>>> - change_page_attr(page, numpages, PAGE_KERNEL);
>>> + if (v_block_mapped((unsigned long)_stext) + 1)
>>
>> That is always true.
>>
>
> Did you boot with 'nobats' kernel parameter ?
>
> If not, that's normal to be true, it means that memory is mapped with BATs.
bool + 1 is always true.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
From: christophe leroy @ 2019-06-16 8:01 UTC (permalink / raw)
To: Andreas Schwab; +Cc: j.neuschaefer, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <877e9n9gng.fsf@igel.home>
Le 15/06/2019 à 14:28, Andreas Schwab a écrit :
> On Feb 21 2019, Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
>> index a000768a5cc9..6e56a6240bfa 100644
>> --- a/arch/powerpc/mm/pgtable_32.c
>> +++ b/arch/powerpc/mm/pgtable_32.c
>> @@ -353,7 +353,10 @@ void mark_initmem_nx(void)
>> unsigned long numpages = PFN_UP((unsigned long)_einittext) -
>> PFN_DOWN((unsigned long)_sinittext);
>>
>> - change_page_attr(page, numpages, PAGE_KERNEL);
>> + if (v_block_mapped((unsigned long)_stext) + 1)
>
> That is always true.
>
Did you boot with 'nobats' kernel parameter ?
If not, that's normal to be true, it means that memory is mapped with BATs.
When you boot with 'nobats' parameter, this should return false.
Christophe
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
From: christophe leroy @ 2019-06-16 8:20 UTC (permalink / raw)
To: Andreas Schwab; +Cc: j.neuschaefer, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <87blyz9jor.fsf@igel.home>
Le 15/06/2019 à 13:23, Andreas Schwab a écrit :
> This breaks suspend (or resume) on the iBook G4. no_console_suspend
> doesn't give any clues, the display just stays dark.
>
After a quick look at the suspend functions, I have the feeling that
those functions only store and restore BATs 0 to 3.
Could you build your kernel with CONFIG_PPC_PTDUMP and see in file
/sys/kernel/debug/powerpc/segment_registers how many IBATs registers are
used.
If any of registers IBATs 4 to 7 are used, could you adjust
CONFIG_ETEXT_SHIFT so that only IBATs 0 to 3 be used, and check if
suspend/resume works when IBATs 4 to 7 are not used ?
Thanks
Christophe
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH] powerpc/mm/32s: only use MMU to mark initmem NX if STRICT_KERNEL_RWX
From: christophe leroy @ 2019-06-16 8:06 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linux-kernel, j.neuschaefer, Paul Mackerras, linuxppc-dev
In-Reply-To: <87pnne9aqo.fsf@igel.home>
Le 15/06/2019 à 16:36, Andreas Schwab a écrit :
> On Jun 15 2019, Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>> Andreas Schwab <schwab@linux-m68k.org> a écrit :
>>
>>> If STRICT_KERNEL_RWX is disabled, never use the MMU to mark initmen
>>> nonexecutable.
>>
>> I dont understand, can you elaborate ?
>
> It breaks suspend.
Ok, but we need to explain why it breaks suspend, and again your patch
is wrong anyway because that area of memory is mapped with BATs so you
can't use change_page_attr()
>
>> This area is mapped with BATs so using change_page_attr() is pointless.
>
> There must be a reason STRICT_KERNEL_RWX is not available with
> HIBERNATE.
Yes but HIBERNATE and suspend are not the same thing. I guess HIBERNATE
is not available with STRICT_KERNEL_RWX because HIBERNATE have to write
back saved state into read-only memory as well.
Christophe
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: Re: [PATCH v3 7/9] KVM: PPC: Ultravisor: Restrict LDBAR access
From: Ram Pai @ 2019-06-16 1:10 UTC (permalink / raw)
To: Paul Mackerras
Cc: Madhavan Srinivasan, rgrimm, Michael Anderson, Claudio Carvalho,
kvm-ppc, Bharata B Rao, linuxppc-dev, Sukadev Bhattiprolu,
Thiago Bauermann, Anshuman Khandual
In-Reply-To: <20190615074334.GD24709@blackberry>
On Sat, Jun 15, 2019 at 05:43:34PM +1000, Paul Mackerras wrote:
> On Thu, Jun 06, 2019 at 02:36:12PM -0300, Claudio Carvalho wrote:
> > When the ultravisor firmware is available, it takes control over the
> > LDBAR register. In this case, thread-imc updates and save/restore
> > operations on the LDBAR register are handled by ultravisor.
> >
> > Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com>
> > Signed-off-by: Ram Pai <linuxram@us.ibm.com>
>
> Acked-by: Paul Mackerras <paulus@ozlabs.org>
>
> Just a note on the signed-off-by: it's a bit weird to have Ram's
> signoff when he is neither the author nor the sender of the patch.
> The author is assumed to be Claudio; if that is not correct then the
> patch should have a From: line at the start telling us who the author
> is, and ideally that person should have a signoff line before
> Claudio's signoff as the sender of the patch.
Ryan originally wrote this patch, which I than modified,
before Claudio further modified it to its current form.
So I think the author should be Ryan.
RP
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: fix oops in hotplug memory notifier
From: Tyrel Datwyler @ 2019-06-15 22:22 UTC (permalink / raw)
To: Nathan Lynch, Tyrel Datwyler; +Cc: linuxppc-dev
In-Reply-To: <87a7el3rk3.fsf@linux.ibm.com>
On 06/13/2019 06:05 PM, Nathan Lynch wrote:
> Nathan Lynch <nathanl@linux.ibm.com> writes:
>
>> Tyrel Datwyler <tyreld@linux.vnet.ibm.com> writes:
>>
>>> Maybe we are ok with this behavior as I haven't dug deep enough into the memory
>>> subsystem here to really understand what the memory code is updating, but it is
>>> concerning that we are doing it in some cases, but not all.
>>
>> I hope I've made a good case above that the notifier does not do any
>> useful work, and a counterpart for the v2 format isn't needed. Do you
>> agree?
>>
>> If so, I'll send a patch later to remove the notifier altogether. In the
>> near term I would still like this minimal fix to go in.
>
> Tyrel, ack?
>
Sure, lets start with simple case to fix the crash.
-Tyrel
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.2-4 tag
From: pr-tracker-bot @ 2019-06-15 17:55 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel, npiggin
In-Reply-To: <87v9x7nf9l.fsf@concordia.ellerman.id.au>
The pull request you sent on Sat, 15 Jun 2019 23:34:46 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.2-4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fa1827d7731ac24f44309ddc2ca806650912bf0e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [PATCH] powerpc/4xx/uic: clear pending interrupt after irq type/pol change
From: Christian Lamparter @ 2019-06-15 15:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thomas Gleixner, Paul Mackerras
When testing out gpio-keys with a button, a spurious
interrupt (and therefore a key press or release event)
gets triggered as soon as the driver enables the irq
line for the first time.
This patch clears any potential bogus generated interrupt
that was caused by the switching of the associated irq's
type and polarity.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
arch/powerpc/platforms/4xx/uic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/4xx/uic.c b/arch/powerpc/platforms/4xx/uic.c
index 31f12ad37a98..36fb66ce54cf 100644
--- a/arch/powerpc/platforms/4xx/uic.c
+++ b/arch/powerpc/platforms/4xx/uic.c
@@ -154,6 +154,7 @@ static int uic_set_irq_type(struct irq_data *d, unsigned int flow_type)
mtdcr(uic->dcrbase + UIC_PR, pr);
mtdcr(uic->dcrbase + UIC_TR, tr);
+ mtdcr(uic->dcrbase + UIC_SR, ~mask);
raw_spin_unlock_irqrestore(&uic->lock, flags);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] powerpc/mm/32s: only use MMU to mark initmem NX if STRICT_KERNEL_RWX
From: Andreas Schwab @ 2019-06-15 14:36 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-kernel, j.neuschaefer, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190615152559.Horde.0lTFIZALxZ-RI75z94G3jA8@messagerie.si.c-s.fr>
On Jun 15 2019, Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> Andreas Schwab <schwab@linux-m68k.org> a écrit :
>
>> If STRICT_KERNEL_RWX is disabled, never use the MMU to mark initmen
>> nonexecutable.
>
> I dont understand, can you elaborate ?
It breaks suspend.
> This area is mapped with BATs so using change_page_attr() is pointless.
There must be a reason STRICT_KERNEL_RWX is not available with
HIBERNATE.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/cacheinfo: add cacheinfo_teardown, cacheinfo_rebuild
From: Michael Ellerman @ 2019-06-15 13:36 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev
In-Reply-To: <20190612044506.16392-2-nathanl@linux.ibm.com>
On Wed, 2019-06-12 at 04:45:04 UTC, Nathan Lynch wrote:
> Allow external callers to force the cacheinfo code to release all its
> references to cache nodes, e.g. before processing device tree updates
> post-migration, and to rebuild the hierarchy afterward.
>
> CPU online/offline must be blocked by callers; enforce this.
>
> Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d4aa219a074a5abaf95a756b9f0d190b
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: fix oops in hotplug memory notifier
From: Michael Ellerman @ 2019-06-15 13:36 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev
In-Reply-To: <20190607050407.25444-1-nathanl@linux.ibm.com>
On Fri, 2019-06-07 at 05:04:07 UTC, Nathan Lynch wrote:
> During post-migration device tree updates, we can oops in
> pseries_update_drconf_memory if the source device tree has an
> ibm,dynamic-memory-v2 property and the destination has a
> ibm,dynamic_memory (v1) property. The notifier processes an "update"
> for the ibm,dynamic-memory property but it's really an add in this
> scenario. So make sure the old property object is there before
> dereferencing it.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0aa82c482ab2ece530a6f44897b63b27
cheers
^ permalink raw reply
* Re: [PATCH] ocxl: do not use C++ style comments in uapi header
From: Michael Ellerman @ 2019-06-15 13:36 UTC (permalink / raw)
To: Masahiro Yamada, Frederic Barrat, Andrew Donnellan, linuxppc-dev
Cc: Arnd Bergmann, Greg KH, Randy Dunlap, linux-kernel,
Masahiro Yamada, Joe Perches, Thomas Gleixner
In-Reply-To: <20190604111632.22479-1-yamada.masahiro@socionext.com>
On Tue, 2019-06-04 at 11:16:32 UTC, Masahiro Yamada wrote:
> Linux kernel tolerates C++ style comments these days. Actually, the
> SPDX License tags for .c files start with //.
>
> On the other hand, uapi headers are written in more strict C, where
> the C++ comment style is forbidden.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
> Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2305ff225c0b1691ec2e93f3d6990e13
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: pseries/hvconsole: fix stack overread via udbg
From: Michael Ellerman @ 2019-06-15 13:35 UTC (permalink / raw)
To: Daniel Axtens, linuxppc-dev; +Cc: Dmitry Vyukov, Daniel Axtens
In-Reply-To: <20190603065657.7986-1-dja@axtens.net>
On Mon, 2019-06-03 at 06:56:57 UTC, Daniel Axtens wrote:
> While developing kasan for 64-bit book3s, I hit the following stack
> over-read.
>
> It occurs because the hypercall to put characters onto the terminal
> takes 2 longs (128 bits/16 bytes) of characters at a time, and so
> hvc_put_chars would unconditionally copy 16 bytes from the argument
> buffer, regardless of supplied length. However, udbg_hvc_putc can
> call hvc_put_chars with a single-byte buffer, leading to the error.
>
> [ 0.001931] ================================================================== [150/819]
> [ 0.001933] BUG: KASAN: stack-out-of-bounds in hvc_put_chars+0xdc/0x110
> [ 0.001934] Read of size 8 at addr c0000000023e7a90 by task swapper/0
> [ 0.001934]
> [ 0.001935] CPU: 0 PID: 0 Comm: swapper Not tainted 5.2.0-rc2-next-20190528-02824-g048a6ab4835b #113
> [ 0.001935] Call Trace:
> [ 0.001936] [c0000000023e7790] [c000000001b4a450] dump_stack+0x104/0x154 (unreliable)
> [ 0.001937] [c0000000023e77f0] [c0000000006d3524] print_address_description+0xa0/0x30c
> [ 0.001938] [c0000000023e7880] [c0000000006d318c] __kasan_report+0x20c/0x224
> [ 0.001939] [c0000000023e7950] [c0000000006d19d8] kasan_report+0x18/0x30
> [ 0.001940] [c0000000023e7970] [c0000000006d4854] __asan_report_load8_noabort+0x24/0x40
> [ 0.001941] [c0000000023e7990] [c0000000001511ac] hvc_put_chars+0xdc/0x110
> [ 0.001942] [c0000000023e7a10] [c000000000f81cfc] hvterm_raw_put_chars+0x9c/0x110
> [ 0.001943] [c0000000023e7a50] [c000000000f82634] udbg_hvc_putc+0x154/0x200
> [ 0.001944] [c0000000023e7b10] [c000000000049c90] udbg_write+0xf0/0x240
> [ 0.001945] [c0000000023e7b70] [c0000000002e5d88] console_unlock+0x868/0xd30
> [ 0.001946] [c0000000023e7ca0] [c0000000002e6e00] register_console+0x970/0xe90
> [ 0.001947] [c0000000023e7d80] [c000000001ff1928] register_early_udbg_console+0xf8/0x114
> [ 0.001948] [c0000000023e7df0] [c000000001ff1174] setup_arch+0x108/0x790
> [ 0.001948] [c0000000023e7e90] [c000000001fe41c8] start_kernel+0x104/0x784
> [ 0.001949] [c0000000023e7f90] [c00000000000b368] start_here_common+0x1c/0x534
> [ 0.001950]
> [ 0.001950]
> [ 0.001951] Memory state around the buggy address:
> [ 0.001952] c0000000023e7980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 0.001952] c0000000023e7a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
> [ 0.001953] >c0000000023e7a80: f1 f1 01 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
> [ 0.001953] ^
> [ 0.001954] c0000000023e7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 0.001954] c0000000023e7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 0.001955] ==================================================================
>
> Document that a 16-byte buffer is requred, and provide it in udbg.
>
> CC: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/934bda59f286d0221f1a3ebab7f5156a
cheers
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.2-4 tag
From: Michael Ellerman @ 2019-06-15 13:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel, npiggin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Linus,
Please pull some more powerpc fixes for 5.2:
The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:
Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.2-4
for you to fetch changes up to c21f5a9ed85ca3e914ca11f421677ae9ae0d04b0:
powerpc/32s: fix booting with CONFIG_PPC_EARLY_DEBUG_BOOTX (2019-06-07 19:00:14 +1000)
- ------------------------------------------------------------------
powerpc fixes for 5.2 #4
One fix for a regression introduced by our 32-bit KASAN support, which broke
booting on machines with "bootx" early debugging enabled.
A fix for a bug which broke kexec on 32-bit, introduced by changes to the 32-bit
STRICT_KERNEL_RWX support in v5.1.
Finally two fixes going to stable for our THP split/collapse handling,
discovered by Nick. The first fixes random crashes and/or corruption in guests
under sufficient load.
Thanks to:
Nicholas Piggin, Christophe Leroy, Aaro Koskinen, Mathieu Malaterre.
- ------------------------------------------------------------------
Christophe Leroy (2):
powerpc: Fix kexec failure on book3s/32
powerpc/32s: fix booting with CONFIG_PPC_EARLY_DEBUG_BOOTX
Nicholas Piggin (2):
powerpc/64s: Fix THP PMD collapse serialisation
powerpc/64s: __find_linux_pte() synchronization vs pmdp_invalidate()
arch/powerpc/include/asm/book3s/64/pgtable.h | 30 ++++++++++++++++++++++++++++
arch/powerpc/include/asm/btext.h | 4 ++++
arch/powerpc/include/asm/kexec.h | 3 +++
arch/powerpc/kernel/machine_kexec_32.c | 4 +++-
arch/powerpc/kernel/prom_init.c | 1 +
arch/powerpc/kernel/prom_init_check.sh | 2 +-
arch/powerpc/mm/book3s64/pgtable.c | 3 +++
arch/powerpc/mm/pgtable.c | 16 +++++++++++++--
8 files changed, 59 insertions(+), 4 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJdBO4+AAoJEFHr6jzI4aWAsAwQAK+CK0jvw2pgZMk8/RwuPihJ
gr6pvRaiUuyyiCpWxpzHslZx0WYSg84EYaog4e3fRss6MZeTd4CxxJqAIIny2XTK
3Z6EI3GQGtA8U/+GY+whaQ5+ILdJotbPNRci+yGwc3HNZwT/4RScbmJz7E84MZv+
9gyXrKUio0RdtdZmMHtkrCbpg24QYf1+168gUlJ8H5XGy5NVXVhXwxbYcFeN4zIY
JI+exlBZwtYBJQMtR0FCvjybKk7kRdQzrrUEFM/ZmzsXQryUR7tLrwqAeLvcDc6x
CY9/fn2q7BcFRiOxeZ3AGG89NRTGdOOC1cNJ+Wqn8bIxzP/yFwTEr+lcbdpooCAs
MYyR0yoiI8Aty55lH0uTYQDbXWBZigvKDjLJzn3KN91NKnb3Yw37y5fM5e1ZYQez
bJmbcJJpQzv0YVxXpxd27QeLQtJe6B8D5y0HkpRzYifma5ItAzc1VGzp66jLRFT+
m4LmzD3TjQ61LWyxxDBjAWCHUKW7+cu++sFw0LOA2Wib5DjLjhQAu9qXN1sR5704
FXji4jULMajLMhqqMxjwTEatS46THyz2rqOtJ5/eRWOHBMBS8rHTbHRtFF20mL7x
tHtDmKCfFs2HwHOndtaWduBjiGVVwOo84o2jY0EvfaQ5nscf2XE9acVo6czpJacn
NnIsVZZ6RU/y4Q/f55T4
=Viyv
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] powerpc/mm/32s: only use MMU to mark initmem NX if STRICT_KERNEL_RWX
From: Christophe Leroy @ 2019-06-15 13:25 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linux-kernel, j.neuschaefer, Paul Mackerras, linuxppc-dev
In-Reply-To: <8736kb9fry.fsf_-_@igel.home>
Andreas Schwab <schwab@linux-m68k.org> a écrit :
> If STRICT_KERNEL_RWX is disabled, never use the MMU to mark initmen
> nonexecutable.
I dont understand, can you elaborate ?
This area is mapped with BATs so using change_page_attr() is pointless.
Christophe
>
> Also move a misplaced paren that makes the condition always true.
>
> Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
> ---
> arch/powerpc/mm/pgtable_32.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index d53188dee18f..3935dc263d65 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -360,9 +360,11 @@ void mark_initmem_nx(void)
> unsigned long numpages = PFN_UP((unsigned long)_einittext) -
> PFN_DOWN((unsigned long)_sinittext);
>
> - if (v_block_mapped((unsigned long)_stext) + 1)
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> + if (v_block_mapped((unsigned long)_stext + 1))
> mmu_mark_initmem_nx();
> else
> +#endif
> change_page_attr(page, numpages, PAGE_KERNEL);
> }
>
> --
> 2.22.0
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
^ permalink raw reply
* Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
From: Christophe Leroy @ 2019-06-15 13:22 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linux-kernel, j.neuschaefer, Paul Mackerras, linuxppc-dev
In-Reply-To: <87blyz9jor.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> a écrit :
> This breaks suspend (or resume) on the iBook G4. no_console_suspend
> doesn't give any clues, the display just stays dark.
Can you send your .config
Thanks
Christophe
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
^ permalink raw reply
* [PATCH] powerpc/mm/32s: only use MMU to mark initmem NX if STRICT_KERNEL_RWX
From: Andreas Schwab @ 2019-06-15 12:47 UTC (permalink / raw)
To: Christophe Leroy
Cc: j.neuschaefer, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1e412310cc18ea654fb2ce4c935654d8d1069f27.1550775950.git.christophe.leroy@c-s.fr>
If STRICT_KERNEL_RWX is disabled, never use the MMU to mark initmen
nonexecutable.
Also move a misplaced paren that makes the condition always true.
Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
arch/powerpc/mm/pgtable_32.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d53188dee18f..3935dc263d65 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -360,9 +360,11 @@ void mark_initmem_nx(void)
unsigned long numpages = PFN_UP((unsigned long)_einittext) -
PFN_DOWN((unsigned long)_sinittext);
- if (v_block_mapped((unsigned long)_stext) + 1)
+#ifdef CONFIG_STRICT_KERNEL_RWX
+ if (v_block_mapped((unsigned long)_stext + 1))
mmu_mark_initmem_nx();
else
+#endif
change_page_attr(page, numpages, PAGE_KERNEL);
}
--
2.22.0
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
From: Andreas Schwab @ 2019-06-15 12:28 UTC (permalink / raw)
To: Christophe Leroy
Cc: j.neuschaefer, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1e412310cc18ea654fb2ce4c935654d8d1069f27.1550775950.git.christophe.leroy@c-s.fr>
On Feb 21 2019, Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index a000768a5cc9..6e56a6240bfa 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -353,7 +353,10 @@ void mark_initmem_nx(void)
> unsigned long numpages = PFN_UP((unsigned long)_einittext) -
> PFN_DOWN((unsigned long)_sinittext);
>
> - change_page_attr(page, numpages, PAGE_KERNEL);
> + if (v_block_mapped((unsigned long)_stext) + 1)
That is always true.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
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