Re: [PATCH V3] powerpc/mm: Add radix flush all with IS=3
On 23/08/16 20:57, Aneesh Kumar K.V wrote:
> Signed-off-by: Aneesh Kumar K.V
> ---
> .../powerpc/include/asm/book3s/64/tlbflush-radix.h | 1 +
> arch/powerpc/mm/tlb-radix.c| 24
> ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
> b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
> index 65037762b120..a9e19cb2f7c5 100644
> --- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
> +++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
> @@ -41,4 +41,5 @@ extern void radix__flush_tlb_page_psize(struct mm_struct
> *mm, unsigned long vmad
> extern void radix__flush_tlb_lpid_va(unsigned long lpid, unsigned long gpa,
>unsigned long page_size);
> extern void radix__flush_tlb_lpid(unsigned long lpid);
> +extern void radix__flush_tlb_all(void);
> #endif
> diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
> index 48df05ef5231..0e49ec541ab5 100644
> --- a/arch/powerpc/mm/tlb-radix.c
> +++ b/arch/powerpc/mm/tlb-radix.c
> @@ -400,3 +400,27 @@ void radix__flush_pmd_tlb_range(struct vm_area_struct
> *vma,
> radix__flush_tlb_range_psize(vma->vm_mm, start, end, MMU_PAGE_2M);
> }
> EXPORT_SYMBOL(radix__flush_pmd_tlb_range);
> +
> +void radix__flush_tlb_all(void)
> +{
> + unsigned long rb,prs,r,rs;
> + unsigned long ric = RIC_FLUSH_ALL;
> +
> + rb = 0x3 << PPC_BITLSHIFT(53); /* IS = 3 */
> + prs = 0; /* partition scoped */
> + r = 1; /* raidx format */
^^ typo - radix
> + rs = 1 & ((1UL << 32) - 1); /* any LPID value to flush guest mappings */
> +
For RIC=2 and IS=3, I think RS is ignored.. I don't think we need to
set RS to anything other than 0, please double check
> + asm volatile("ptesync": : :"memory");
> + /*
> + * now flush guest entries by passing PRS = 1 and LPID != 0
> + */
> + asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
> + : : "r"(rb), "i"(r), "i"(1), "i"(ric), "r"(rs) : "memory");
> + /*
> + * now flush host entires by passing PRS = 0 and LPID == 0
> + */
> + asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
> + : : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(0) :
> "memory");
> + asm volatile("eieio; tlbsync; ptesync": : :"memory");
> +}
>
Otherwise looks good
Balbir Singh.
Re: [PATCH 4/6] cxlflash: Transition to application close model
> "Matthew" == Matthew R Ochs writes: Matthew> Caching the adapter file descriptor and performing a close on Matthew> behalf of an application is a poor design. This is due to the Matthew> fact that once a file descriptor in installed, it is free to be Matthew> altered without the knowledge of the cxlflash driver. This can Matthew> lead to inconsistencies between the application and Matthew> kernel. Furthermore, the nature of the former design is more Matthew> exploitable and thus should be abandoned. Matthew> To support applications performing a close on the adapter file Matthew> that is associated with a context, a new flag is introduced to Matthew> the user API to indicate to applications that they are Matthew> responsible for the close following the cleanup (detach) of a Matthew> context. The documentation is also updated to reflect this Matthew> change in behavior. Applied patches 4 through 6 to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] powerpc/ptrace: Fix cppcheck issue in gpr32_set_common/gpr32_get_common.
Hi Simon,
> The ckpt_regs usage in gpr32_set_common/gpr32_get_common()
> will lead to cppcheck error.
>
> [arch/powerpc/kernel/ptrace.c:2062]: (error) Uninitialized variable: ckpt_regs
> [arch/powerpc/kernel/ptrace.c:2130]: (error) Uninitialized variable: ckpt_regs
>
> A straightforward fix to clean it.
I'm always happy to see cppcheck warnings fixed :)
> static int gpr32_get_common(struct task_struct *target,
>const struct user_regset *regset,
>unsigned int pos, unsigned int count,
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> void *kbuf, void __user *ubuf, bool tm_active)
> +#else
> + void *kbuf, void __user *ubuf)
> +#endif
I wonder if it might be possible to avoid some of the ifdefs and general
churn by making the tm_active argument __maybe_unused rather than
ifdefing around it?
In particular, it would mean the two hunks in the function definitions
and these these two hunks at the call site would be unnecessary:
> @@ -2218,7 +2225,11 @@ static int gpr32_get(struct task_struct *target,
>unsigned int pos, unsigned int count,
>void *kbuf, void __user *ubuf)
> {
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> return gpr32_get_common(target, regset, pos, count, kbuf, ubuf, 0);
> +#else
> + return gpr32_get_common(target, regset, pos, count, kbuf, ubuf);
> +#endif
> }
>
> static int gpr32_set(struct task_struct *target,
> @@ -2226,7 +2237,11 @@ static int gpr32_set(struct task_struct *target,
>unsigned int pos, unsigned int count,
>const void *kbuf, const void __user *ubuf)
> {
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> return gpr32_set_common(target, regset, pos, count, kbuf, ubuf, 0);
> +#else
> + return gpr32_set_common(target, regset, pos, count, kbuf, ubuf);
> +#endif
> }
Apart from that, thanks for fixing this up!
Regards,
Daniel
>
> /*
> --
> 1.8.3.1
signature.asc
Description: PGP signature
Re: [PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.
Am Mittwoch, 24 August 2016, 10:50:26 schrieb Oliver O'Halloran: > On Tue, Aug 23, 2016 at 1:21 PM, Balbir Singh wrote: > >> zImage on ppc64 BE is an ELF32 file. This patch set only supports > >> loading > >> ELF files of the same class as the kernel, so a 64 bit kernel can't > >> load an ELF32 file. It would be possible to add such support, but it > >> would be a new feature. > >> > >> The distros I was able to check on ppc64 LE and BE all use vmlinux. > >> kexec-tools with kexec_load also doesn't support zImage. Do you think > >> it is important to support zImage? > > > > Well if it didn't work already, I think its low priority. Michael should > > be able to confirm this. Oliver's been trying to cleanup the zImage to > > get rid the old zImage limitation, cc'ing him > > I don't think it's ever worked so I wouldn't worry too much about > supporting it. Fixing kexec-into-zImage and fixing the 32bit wrapper > on 64bit BE kernel problem has been on my TODO list for a while, but > it's not a priority. Ok, thanks for your input. -- []'s Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.
On Tue, Aug 23, 2016 at 1:21 PM, Balbir Singh wrote: > >> zImage on ppc64 BE is an ELF32 file. This patch set only supports loading >> ELF files of the same class as the kernel, so a 64 bit kernel can't load an >> ELF32 file. It would be possible to add such support, but it would be a new >> feature. >> >> The distros I was able to check on ppc64 LE and BE all use vmlinux. >> kexec-tools with kexec_load also doesn't support zImage. Do you think it is >> important to support zImage? > > Well if it didn't work already, I think its low priority. Michael should be > able to confirm this. Oliver's been trying to cleanup the zImage to get rid > the old zImage limitation, cc'ing him I don't think it's ever worked so I wouldn't worry too much about supporting it. Fixing kexec-into-zImage and fixing the 32bit wrapper on 64bit BE kernel problem has been on my TODO list for a while, but it's not a priority. oliver
[PATCH v3 2/5] firmware: annotate thou shalt not request fw on init or probe
From: "Luis R. Rodriguez" Thou shalt not make firmware calls early on init or probe. systemd already ripped support out for the usermode helper a while ago, there are still users that require the usermode helper, however systemd's use of the usermode helper exacerbated a long lasting issue of the fact that we have many drivers that load firmware on init or probe. Independent of the usermode helper loading firmware on init or probe is a bad idea for a few reasons. When the firmware is read directly from the filesystem by the kernel, if the driver is built-in to the kernel the firmware may not yet be available, for such uses one could use initramfs and stuff the firmware inside, or one also use CONFIG_EXTRA_FIRMWARE; however not all distributions use this, as such generally one cannot count on this. There is another corner cases to consider, since we are accessing the firmware directly folks cannot expect new found firmware on a filesystem after we switch off from an initramfs with pivot_root(). Supporting such situations is possible today but fixing it for good is really complex due to the large amount of variablity in the boot up process. Instead just document the expectations properly and add a grammar rule to enable folks to check / validate / police if drivers are using the request firmware API early on init or probe. The SmPL rule used to check for the probe routine is loose and is currently defined through a regexp, that can easily be extended to any other known bus probe routine names. It also uses the new Python iteration support which allows us to backtrack from a request_firmware*() call back to a possible probe or init, iteratively. Without iteration we would only be able to get reports for callers who directly use the request_firmware*() API on the initial probe or init routine. There are 4 offenders at this time: mcgrof@ergon ~/linux-next (git::20160609)$ export COCCI=scripts/coccinelle/api/request_firmware.cocci mcgrof@ergon ~/linux-next (git::20160609)$ make coccicheck MODE=report drivers/fmc/fmc-fakedev.c: ERROR: driver call request firmware call on its init routine on line 321. drivers/fmc/fmc-write-eeprom.c: ERROR: driver call request firmware call on its probe routine on line 136. drivers/tty/serial/rp2.c: ERROR: driver call request firmware call on its probe routine on line 796. drivers/tty/serial/ucc_uart.c: ERROR: driver call request firmware call on its probe routine on line 1246. I checked and verified all these are valid reports. This list also matches the same list as in 20150805, so we have fortunately not gotten worse. Let's keep it that way and also fix these drivers. v2: changes from v1 [0]: o This now supports iteration, this extends our coverage on the report o Update documentation and commit log to accept the fate of not being able to remove the usermode helper. [0] https://lkml.kernel.org/r/1440811107-861-1-git-send-email-mcg...@do-not-panic.com Cc: Alessandro Rubini Cc: Kevin Cernekee Cc: Daniel Vetter Cc: Mimi Zohar Cc: David Woodhouse Cc: Kees Cook Cc: Dmitry Torokhov Cc: Ming Lei Cc: Jonathan Corbet Cc: Julia Lawall Cc: Gilles Muller Cc: Nicolas Palix Cc: Thierry Martinez Cc: Michal Marek Cc: co...@systeme.lip6.fr Cc: Alessandro Rubini Cc: Kevin Cernekee Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-ser...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ser...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Luis R. Rodriguez --- Documentation/firmware_class/README| 20 drivers/base/Kconfig | 2 +- .../request_firmware-avoid-init-probe-init.cocci | 130 + 3 files changed, 151 insertions(+), 1 deletion(-) create mode 100644 scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README index cafdca8b3b15..056d1cb9d365 100644 --- a/Documentation/firmware_class/README +++ b/Documentation/firmware_class/README @@ -93,6 +93,26 @@ user contexts to request firmware asynchronously, but can't be called in atomic contexts. +Requirements: += + +You should avoid at all costs requesting firmware on both init and probe paths +of your device driver. Reason for this is the complexity needed to ensure a +firmware will be available for a driver early in boot through different +build configurations. Consider built-in drivers needing firmware early, or +consider a driver assuming it will only get firmware after pivot_root(). + +Drivers that really need firmware early should use stuff the firmware in +initramfs or consider using CONFIG_EXTRA_FIRMWARE. Using initramfs is much +more portable to more distributions as not all distributions wish to enable +CONFIG_EXTRA_FIRMWARE. Should a driver require the firmware being built-in +it should depend on CONFIG_EXTRA_FIRMWARE. There is no current annotation for +requiring a firmware on init
Re: [PATCH v4 2/2] powerpc/pseries: Implement indexed-count hotplug memory remove
Quoting Sahil Mehta (2016-08-01 12:23:16)
> Indexed-count remove for memory hotplug guarantees that a contiguous block
> of lmbs beginning at a specified will be unassigned (NOT
> that lmbs will be removed). Because of Qemu's per-DIMM memory
> management, the removal of a contiguous block of memory currently
> requires a series of individual calls. Indexed-count remove reduces
> this series into a single call.
>
> Signed-off-by: Sahil Mehta
> ---
> v2: -use u32s drc_index and count instead of u32 ic[]
> in dlpar_memory
> v3: -add logic to handle invalid drc_index input
> v4: -none
>
> arch/powerpc/platforms/pseries/hotplug-memory.c | 90
> +++
> 1 file changed, 90 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
> b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 2d4ceb3..dd5eb38 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -503,6 +503,92 @@ static int dlpar_memory_remove_by_index(u32 drc_index,
> struct property *prop)
> return rc;
> }
>
> +static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index,
> +struct property *prop)
> +{
> + struct of_drconf_cell *lmbs;
> + u32 num_lmbs, *p;
> + int i, rc, start_lmb_found;
> + int lmbs_available = 0, start_index = 0, end_index;
> +
> + pr_info("Attempting to hot-remove %u LMB(s) at %x\n",
> + lmbs_to_remove, drc_index);
> +
> + if (lmbs_to_remove == 0)
> + return -EINVAL;
> +
> + p = prop->value;
> + num_lmbs = *p++;
> + lmbs = (struct of_drconf_cell *)p;
> + start_lmb_found = 0;
> +
> + /* Navigate to drc_index */
> + while (start_index < num_lmbs) {
> + if (lmbs[start_index].drc_index == drc_index) {
> + start_lmb_found = 1;
> + break;
> + }
> +
> + start_index++;
> + }
> +
> + if (!start_lmb_found)
> + return -EINVAL;
> +
> + end_index = start_index + lmbs_to_remove;
> +
> + /* Validate that there are enough LMBs to satisfy the request */
> + for (i = start_index; i < end_index; i++) {
> + if (lmbs[i].flags & DRCONF_MEM_RESERVED)
> + break;
> +
> + lmbs_available++;
> + }
> +
> + if (lmbs_available < lmbs_to_remove)
> + return -EINVAL;
> +
> + for (i = 0; i < end_index; i++) {
Shouldn't this be i = start_index? Otherwise it seems we'd attempt to
satisfy the request using LMBs outside of the requested range.
> + if (!(lmbs[i].flags & DRCONF_MEM_ASSIGNED))
> + continue;
> +
> + rc = dlpar_remove_lmb(&lmbs[i]);
> + if (rc)
> + break;
> +
> + lmbs[i].reserved = 1;
> + }
> +
> + if (rc) {
> + pr_err("Memory indexed-count-remove failed, adding any
> removed LMBs\n");
> +
> + for (i = start_index; i < end_index; i++) {
> + if (!lmbs[i].reserved)
> + continue;
> +
> + rc = dlpar_add_lmb(&lmbs[i]);
> + if (rc)
> + pr_err("Failed to add LMB, drc index %x\n",
> + be32_to_cpu(lmbs[i].drc_index));
> +
> + lmbs[i].reserved = 0;
> + }
> + rc = -EINVAL;
> + } else {
> + for (i = start_index; i < end_index; i++) {
> + if (!lmbs[i].reserved)
> + continue;
> +
> + pr_info("Memory at %llx (drc index %x) was
> hot-removed\n",
> + lmbs[i].base_addr, lmbs[i].drc_index);
> +
> + lmbs[i].reserved = 0;
> + }
> + }
> +
> + return rc;
> +}
> +
> #else
> static inline int pseries_remove_memblock(unsigned long base,
> unsigned int memblock_size)
> @@ -829,6 +915,10 @@ int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
> } else if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX) {
> drc_index = hp_elog->_drc_u.drc_index;
> rc = dlpar_memory_remove_by_index(drc_index, prop);
> + } else if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_IC) {
> + count = hp_elog->_drc_u.indexed_count[0];
> + drc_index = hp_elog->_drc_u.indexed_count[1];
> + rc = dlpar_memory_remove_by_ic(count, drc_index,
> prop);
> } else {
> rc = -EINVAL;
> }
>
> ___
> Linuxppc-dev mailing
[PATCH] powerpc: Fix build of 64 bit little endian with CONFIG_KEXEC=n
On ppc64le, builds with CONFIG_KEXEC=n fail with:
arch/powerpc/platforms/pseries/setup.c: In function
‘pseries_big_endian_exceptions’:
arch/powerpc/platforms/pseries/setup.c:403:13: error: implicit
declaration of function ‘kdump_in_progress’
[-Werror=implicit-function-declaration]
if (rc && !kdump_in_progress())
This is because pseries/setup.c includes , but
kdump_in_progress is defined in . This is a problem because
the former only includes the latter if CONFIG_KEXEC_CORE=y.
Fix by including directly, as is done in powernv/setup.c.
Fixes: d3cbff1b5a90 ("powerpc: Put exception configuration in a common place")
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/platforms/pseries/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
index 4ffcaa6f8670..a39d20e8623d 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -41,7 +41,6 @@
#include
#include
#include
-#include
#include
#include
@@ -66,6 +65,7 @@
#include
#include
#include
+#include
#include "pseries.h"
--
1.9.1
Re: [PATCH 1/1] pci: host: pci-layerscape: add missing of_node_put after calling of_parse_phandle
Hi Peter, On Fri, Aug 12, 2016 at 09:34:41AM +0800, Peter Chen wrote: > of_node_put needs to be called when the device node which is got > from of_parse_phandle has finished using. > > Cc: Minghuan Lian > Cc: Mingkai Hu > Cc: Roy Zang > Signed-off-by: Peter Chen > --- > drivers/pci/host/pci-layerscape.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/host/pci-layerscape.c > b/drivers/pci/host/pci-layerscape.c > index 114ba81..573b996 100644 > --- a/drivers/pci/host/pci-layerscape.c > +++ b/drivers/pci/host/pci-layerscape.c > @@ -173,6 +173,8 @@ static int ls_pcie_msi_host_init(struct pcie_port *pp, > return -EINVAL; > } > > + of_node_put(msi_node); > + Can you please look for and fix similar errors in other drivers in drivers/pci/host/*? For example: advk_pcie_probe() and iproc_pcie_msi_enable() call of_parse_phandle() but don't call of_node_put() in failure paths. dra7xx_pcie_init_irq_domain(), nwl_pcie_init_irq_domain(), and xilinx_pcie_init_irq_domain() call of_get_next_child() but don't call of_node_put() in failure paths. ks_pcie_get_irq_controller_info() calls of_find_node_by_name(). I think there may be others, e.g., the pci_host_bridge_msi_domain() path calls of_parse_phandle(), but I'm not sure of_node_put() is called on failure paths. When we find bugs like this, it's nice to fix one occurrence, but it's really great if we can squash similar bugs nearby so the bug isn't copied into new drivers. > return 0; > } > > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/7] perf annotate: Add cross arch annotate support
On Tue, 23 Aug 2016 11:17:16 +0900
Namhyung Kim wrote:
> On Tue, Aug 23, 2016 at 8:01 AM, Kim Phillips wrote:
> > On Fri, 19 Aug 2016 18:29:33 +0530
> > Ravi Bangoria wrote:
> >
> >> Changes in v6:
> >> - Instead of adding only those instructions defined in #ifdef __arm__,
> >> add all instructions from default table to arm table.
> > Thanks, I've gone through the list and removed all not-ARM
> > instructions, and added some missing ARM branch instructions:
>
> Can we use regex patterns instead?
Yes, that helps prevent mistakes updating instruction lists - how does
this look?:
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index b2c6cf3..52316f3 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -26,6 +26,7 @@
const char *disassembler_style;
const char *objdump_path;
static regex_t file_lineno;
+static regex_t arm_call_insn, arm_jump_insn;
static struct ins *ins__find(const char *name, const char *norm_arch);
static int disasm_line__parse(char *line, char **namep, char **rawp);
@@ -449,98 +450,7 @@ static struct ins instructions_x86[] = {
{ .name = "retq", .ops = &ret_ops, },
};
-static struct ins instructions_arm[] = {
- { .name = "add", .ops = &mov_ops, },
- { .name = "addl", .ops = &mov_ops, },
- { .name = "addq", .ops = &mov_ops, },
- { .name = "addw", .ops = &mov_ops, },
- { .name = "and", .ops = &mov_ops, },
- { .name = "b", .ops = &jump_ops, }, /* might also be a call */
- { .name = "bcc", .ops = &jump_ops, },
- { .name = "bcs", .ops = &jump_ops, },
- { .name = "beq", .ops = &jump_ops, },
- { .name = "bge", .ops = &jump_ops, },
- { .name = "bgt", .ops = &jump_ops, },
- { .name = "bhi", .ops = &jump_ops, },
- { .name = "bl",.ops = &call_ops, },
- { .name = "bls", .ops = &jump_ops, },
- { .name = "blt", .ops = &jump_ops, },
- { .name = "blx", .ops = &call_ops, },
- { .name = "bne", .ops = &jump_ops, },
- { .name = "bts", .ops = &mov_ops, },
- { .name = "call", .ops = &call_ops, },
- { .name = "callq", .ops = &call_ops, },
- { .name = "cmp", .ops = &mov_ops, },
- { .name = "cmpb", .ops = &mov_ops, },
- { .name = "cmpl", .ops = &mov_ops, },
- { .name = "cmpq", .ops = &mov_ops, },
- { .name = "cmpw", .ops = &mov_ops, },
- { .name = "cmpxch", .ops = &mov_ops, },
- { .name = "dec", .ops = &dec_ops, },
- { .name = "decl", .ops = &dec_ops, },
- { .name = "imul", .ops = &mov_ops, },
- { .name = "inc", .ops = &dec_ops, },
- { .name = "incl", .ops = &dec_ops, },
- { .name = "ja",.ops = &jump_ops, },
- { .name = "jae", .ops = &jump_ops, },
- { .name = "jb",.ops = &jump_ops, },
- { .name = "jbe", .ops = &jump_ops, },
- { .name = "jc",.ops = &jump_ops, },
- { .name = "jcxz", .ops = &jump_ops, },
- { .name = "je",.ops = &jump_ops, },
- { .name = "jecxz", .ops = &jump_ops, },
- { .name = "jg",.ops = &jump_ops, },
- { .name = "jge", .ops = &jump_ops, },
- { .name = "jl",.ops = &jump_ops, },
- { .name = "jle", .ops = &jump_ops, },
- { .name = "jmp", .ops = &jump_ops, },
- { .name = "jmpq", .ops = &jump_ops, },
- { .name = "jna", .ops = &jump_ops, },
- { .name = "jnae", .ops = &jump_ops, },
- { .name = "jnb", .ops = &jump_ops, },
- { .name = "jnbe", .ops = &jump_ops, },
- { .name = "jnc", .ops = &jump_ops, },
- { .name = "jne", .ops = &jump_ops, },
- { .name = "jng", .ops = &jump_ops, },
- { .name = "jnge", .ops = &jump_ops, },
- { .name = "jnl", .ops = &jump_ops, },
- { .name = "jnle", .ops = &jump_ops, },
- { .name = "jno", .ops = &jump_ops, },
- { .name = "jnp", .ops = &jump_ops, },
- { .name = "jns", .ops = &jump_ops, },
- { .name = "jnz", .ops = &jump_ops, },
- { .name = "jo",.ops = &jump_ops, },
- { .name = "jp",.ops = &jump_ops, },
- { .name = "jpe", .ops = &jump_ops, },
- { .name = "jpo", .ops = &jump_ops, },
- { .name = "jrcxz", .ops = &jump_ops, },
- { .name = "js",.ops = &jump_ops, },
- { .name = "jz",.ops = &jump_ops, },
- { .name = "lea", .ops = &mov_ops, },
- { .name = "lock", .ops = &lock_ops, },
- { .name = "mov", .ops = &mov_ops, },
- { .name = "movb", .ops = &mov_ops, },
- { .name = "movdqa",.ops = &mov_ops, },
- { .name = "movl", .ops = &mov_ops, },
- { .name = "movq", .ops = &mov_ops, },
- { .name = "movslq", .ops = &mov_ops, },
- { .name = "movzbl", .ops = &mov_ops, },
- { .name = "movzwl", .ops = &mov_ops, },
- { .name = "nop", .ops = &nop_op
[PATCH v2] powerpc/8xx: use SPRN_EIE and SPRN_EID to enable/disable interrupts
The 8xx has two special registers called EID (External Interrupt
Disable) and EIE (External Interrupt Enable) for clearing/setting
EE in MSR. It avoids the three instructions set mfmsr/ori/mtmsr or
mfmsr/rlwinm/mtmsr and it avoids using a general register.
We just have to write something in the special register to change MSR EE
bit. So we write r0 into the register, regardless of r0 value.
Writing to one of those two special registers also set the MSR RI bit,
but this bit is only unset during beginning of exception prolog and end
of exception epilog. When executing C-functions MSR RI is always set.
Signed-off-by: Christophe Leroy
---
v2: removed definition of SPRN_NRI which is not used. Enhanced the
commit text. Moved down the SPRN_EIE and SPRN_EID definition to
keep this patch independant of the hugepage patch I'm working on.
arch/powerpc/include/asm/hw_irq.h | 6 ++
arch/powerpc/include/asm/reg.h | 2 ++
arch/powerpc/include/asm/reg_8xx.h | 4
3 files changed, 12 insertions(+)
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index c7d82ff..7ffb392 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -155,6 +155,8 @@ static inline unsigned long arch_local_irq_save(void)
unsigned long flags = arch_local_save_flags();
#ifdef CONFIG_BOOKE
asm volatile("wrteei 0" : : : "memory");
+#elif defined(CONFIG_PPC_8xx)
+ wrtspr(SPRN_EID);
#else
SET_MSR_EE(flags & ~MSR_EE);
#endif
@@ -165,6 +167,8 @@ static inline void arch_local_irq_disable(void)
{
#ifdef CONFIG_BOOKE
asm volatile("wrteei 0" : : : "memory");
+#elif defined(CONFIG_PPC_8xx)
+ wrtspr(SPRN_EID);
#else
arch_local_irq_save();
#endif
@@ -174,6 +178,8 @@ static inline void arch_local_irq_enable(void)
{
#ifdef CONFIG_BOOKE
asm volatile("wrteei 1" : : : "memory");
+#elif defined(CONFIG_PPC_8xx)
+ wrtspr(SPRN_EIE);
#else
unsigned long msr = mfmsr();
SET_MSR_EE(msr | MSR_EE);
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index f69f40f..4bbd9be 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1246,6 +1246,8 @@ static inline void mtmsr_isync(unsigned long val)
: "r" ((unsigned long)(v)) \
: "memory")
#endif
+#define wrtspr(rn) asm volatile("mtspr " __stringify(rn) ",0" : \
+: : "memory")
extern void msr_check_and_set(unsigned long bits);
extern bool strict_msr_control;
diff --git a/arch/powerpc/include/asm/reg_8xx.h
b/arch/powerpc/include/asm/reg_8xx.h
index 94d01f8..0197e12 100644
--- a/arch/powerpc/include/asm/reg_8xx.h
+++ b/arch/powerpc/include/asm/reg_8xx.h
@@ -25,6 +25,10 @@
#define SPRN_MD_RAM0 825
#define SPRN_MD_RAM1 826
+/* Special MSR manipulation registers */
+#define SPRN_EIE 80 /* External interrupt enable (EE=1, RI=1) */
+#define SPRN_EID 81 /* External interrupt disable (EE=0, RI=1) */
+
/* Commands. Only the first few are available to the instruction cache.
*/
#defineIDC_ENABLE 0x0200 /* Cache enable */
--
2.1.0
[PATCH] powerpc/8xx: add dedicated machine check handler
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cputable.h | 1 +
arch/powerpc/kernel/cputable.c | 1 +
arch/powerpc/kernel/traps.c | 13 +
3 files changed, 15 insertions(+)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 82026b4..863b356 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -43,6 +43,7 @@ extern int machine_check_e500mc(struct pt_regs *regs);
extern int machine_check_e500(struct pt_regs *regs);
extern int machine_check_e200(struct pt_regs *regs);
extern int machine_check_47x(struct pt_regs *regs);
+extern int machine_check_8xx(struct pt_regs *regs);
extern void cpu_down_flush_e500v2(void);
extern void cpu_down_flush_e500mc(void);
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 74248ab..f7bee9e 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1229,6 +1229,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.mmu_features = MMU_FTR_TYPE_8xx,
.icache_bsize = 16,
.dcache_bsize = 16,
+ .machine_check = machine_check_8xx,
.platform = "ppc823",
},
#endif /* CONFIG_8xx */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2cb5892..37db564 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -664,6 +664,19 @@ int machine_check_e200(struct pt_regs *regs)
return 0;
}
+#elif defined(CONFIG_PPC_8xx)
+int machine_check_8xx(struct pt_regs *regs)
+{
+ unsigned long reason = get_mc_reason(regs);
+
+ printk("Machine check in kernel mode.\n");
+ printk("Caused by (from SRR1=%lx): ", reason);
+ if (reason & 0x4000)
+ printk("Fetch error at address %lx\n", regs->nip);
+ else
+ printk("Data access error at address %lx\n", regs->dar);
+ return 0;
+}
#else
int machine_check_generic(struct pt_regs *regs)
{
--
2.1.0
Re: Suspected regression?
Le 23/08/2016 à 11:20, Alessio Igor Bogani a écrit : Hi Christophe, Sorry for delay in reply I was on vacation. On 6 August 2016 at 11:29, christophe leroy wrote: Alessio, Le 05/08/2016 à 09:51, Christophe Leroy a écrit : Le 19/07/2016 à 23:52, Scott Wood a écrit : On Tue, 2016-07-19 at 12:00 +0200, Alessio Igor Bogani wrote: Hi all, I have got two boards MVME5100 (MPC7410 cpu) and MVME7100 (MPC8641D cpu) for which I use the same cross-compiler (ppc7400). I tested these against kernel HEAD to found that these don't boot anymore (PID 1 crash). Bisecting results in first offending commit: 7aef4136566b0539a1a98391181e188905e33401 Removing it from HEAD make boards boot properly again. A third system based on P2010 isn't affected at all. Is it a regression or I have made something wrong? I booted both my next branch, and Linus's master on MPC8641HPCN and didn't see this -- though possibly your RFS is doing something different. Maybe that's the difference with P2010 as well. Is there any way you can debug the cause of the crash? Or send me a minimal RFS that demonstrates the problem (ideally with debug symbols on the userspace binaries)? I got from Alessio the below information: systemd[1]: Caught , core dump failed (child 137, code=killed, status=7/BUS). systemd[1]: Freezing execution. What can generate SIGBUS ? And shouldn't we also get some KERN_ERR trace, something like "unhandled signal 7 at ." ? As far as I can see, SIGBUS is mainly generated from alignment exception. According to 7410 Reference Manual, alignment exception can happen in the following cases: * An operand of a dcbz instruction is on a page that is write-through or cache-inhibited for a virtual mode access. * An attempt to execute a dcbz instruction occurs when the cache is disabled or locked. Could try with below patch to check if the dcbz insn is causing the SIGBUS ? Unfortunately that patch doesn't solve the problem. Is there a chance that cache behavior could settled by board firmware (PPCBug on the MPC7410 board and MotLoad on the MPC8641D one)? In that case what do you suggest me to looking for? If the removal of dcbz doesn't solve the issue, I don't think it is a cache related issue. As far as I understood, your init gets a SIGBUS signal, right ? Then we must identify the reason for that sigbus. Once it has happened, do you have access to 'dmesg' at all ? If not, you should make sure the default log level on your console is high enough to capture all messages, then I recommend you to send us your complete console log from startup until init crash so that we can get a complete picture. Christophe Christophe diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S index 68f6862..3ad782a 100644 --- a/arch/powerpc/lib/checksum_32.S +++ b/arch/powerpc/lib/checksum_32.S @@ -192,7 +192,7 @@ _GLOBAL(csum_partial_copy_generic) mtctr r8 53:dcbtr3,r4 -54:dcbzr11,r6 +54:nop /* the main body of the cacheline loop */ CSUM_COPY_16_BYTES_WITHEX(0) #if L1_CACHE_BYTES >= 32 Thanks for your help! Ciao, Alessio
[PATCH V3] powerpc/mm: Add radix flush all with IS=3
Signed-off-by: Aneesh Kumar K.V
---
.../powerpc/include/asm/book3s/64/tlbflush-radix.h | 1 +
arch/powerpc/mm/tlb-radix.c| 24 ++
2 files changed, 25 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
index 65037762b120..a9e19cb2f7c5 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
@@ -41,4 +41,5 @@ extern void radix__flush_tlb_page_psize(struct mm_struct *mm,
unsigned long vmad
extern void radix__flush_tlb_lpid_va(unsigned long lpid, unsigned long gpa,
unsigned long page_size);
extern void radix__flush_tlb_lpid(unsigned long lpid);
+extern void radix__flush_tlb_all(void);
#endif
diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
index 48df05ef5231..0e49ec541ab5 100644
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@ -400,3 +400,27 @@ void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
radix__flush_tlb_range_psize(vma->vm_mm, start, end, MMU_PAGE_2M);
}
EXPORT_SYMBOL(radix__flush_pmd_tlb_range);
+
+void radix__flush_tlb_all(void)
+{
+ unsigned long rb,prs,r,rs;
+ unsigned long ric = RIC_FLUSH_ALL;
+
+ rb = 0x3 << PPC_BITLSHIFT(53); /* IS = 3 */
+ prs = 0; /* partition scoped */
+ r = 1; /* raidx format */
+ rs = 1 & ((1UL << 32) - 1); /* any LPID value to flush guest mappings */
+
+ asm volatile("ptesync": : :"memory");
+ /*
+* now flush guest entries by passing PRS = 1 and LPID != 0
+*/
+ asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
+: : "r"(rb), "i"(r), "i"(1), "i"(ric), "r"(rs) : "memory");
+ /*
+* now flush host entires by passing PRS = 0 and LPID == 0
+*/
+ asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
+: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(0) :
"memory");
+ asm volatile("eieio; tlbsync; ptesync": : :"memory");
+}
--
2.7.4
Re: Suspected regression?
Hi Christophe, Sorry for delay in reply I was on vacation. On 6 August 2016 at 11:29, christophe leroy wrote: > Alessio, > > > Le 05/08/2016 à 09:51, Christophe Leroy a écrit : >> >> >> >> Le 19/07/2016 à 23:52, Scott Wood a écrit : >>> >>> On Tue, 2016-07-19 at 12:00 +0200, Alessio Igor Bogani wrote: Hi all, I have got two boards MVME5100 (MPC7410 cpu) and MVME7100 (MPC8641D cpu) for which I use the same cross-compiler (ppc7400). I tested these against kernel HEAD to found that these don't boot anymore (PID 1 crash). Bisecting results in first offending commit: 7aef4136566b0539a1a98391181e188905e33401 Removing it from HEAD make boards boot properly again. A third system based on P2010 isn't affected at all. Is it a regression or I have made something wrong? >>> >>> >>> I booted both my next branch, and Linus's master on MPC8641HPCN and >>> didn't see >>> this -- though possibly your RFS is doing something different. Maybe >>> that's >>> the difference with P2010 as well. >>> >>> Is there any way you can debug the cause of the crash? Or send me a >>> minimal >>> RFS that demonstrates the problem (ideally with debug symbols on the >>> userspace >>> binaries)? >>> >> >> I got from Alessio the below information: >> >> systemd[1]: Caught , core dump failed (child 137, code=killed, >> status=7/BUS). >> systemd[1]: Freezing execution. >> >> >> What can generate SIGBUS ? >> And shouldn't we also get some KERN_ERR trace, something like "unhandled >> signal 7 at ." ? >> > > As far as I can see, SIGBUS is mainly generated from alignment exception. > According to 7410 Reference Manual, alignment exception can happen in the > following cases: > * An operand of a dcbz instruction is on a page that is write-through or > cache-inhibited for a virtual mode access. > * An attempt to execute a dcbz instruction occurs when the cache is disabled > or locked. > > Could try with below patch to check if the dcbz insn is causing the SIGBUS ? Unfortunately that patch doesn't solve the problem. Is there a chance that cache behavior could settled by board firmware (PPCBug on the MPC7410 board and MotLoad on the MPC8641D one)? In that case what do you suggest me to looking for? > Christophe > > diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S > index 68f6862..3ad782a 100644 > --- a/arch/powerpc/lib/checksum_32.S > +++ b/arch/powerpc/lib/checksum_32.S > @@ -192,7 +192,7 @@ _GLOBAL(csum_partial_copy_generic) > mtctr r8 > > 53:dcbtr3,r4 > -54:dcbzr11,r6 > +54:nop > /* the main body of the cacheline loop */ > CSUM_COPY_16_BYTES_WITHEX(0) > #if L1_CACHE_BYTES >= 32 Thanks for your help! Ciao, Alessio
Re: [PATCH v3] powerpc: signals: Discard transaction state from signal frames
On Tue, Aug 23, 2016 at 10:46:17AM +1000, Cyril Bur wrote: > Userspace can begin and suspend a transaction within the signal > handler which means they might enter sys_rt_sigreturn() with the > processor in suspended state. > > sys_rt_sigreturn() wants to restore process context (which may have > been in a transaction before signal delivery). To do this it must > restore TM SPRS. To achieve this, any transaction initiated within the > signal frame must be discarded in order to be able to restore TM SPRs > as TM SPRs can only be manipulated non-transactionally.. > From the PowerPC ISA: > TM Bad Thing Exception [Category: Transactional Memory] >An attempt is made to execute a mtspr targeting a TM register in >other than Non-transactional state. > > Not doing so results in a TM Bad Thing: > [12045.221359] Kernel BUG at c0050a40 [verbose debug info unavailable] > [12045.221470] Unexpected TM Bad Thing exception at c0050a40 (msr > 0x201033) > [12045.221540] Oops: Unrecoverable exception, sig: 6 [#1] > [12045.221586] SMP NR_CPUS=2048 NUMA PowerNV > [12045.221634] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE > nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 > nf_defrag_ipv4 > xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc > ebtable_filter > ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables kvm_hv > kvm > uio_pdrv_genirq ipmi_powernv uio powernv_rng ipmi_msghandler autofs4 ses > enclosure > scsi_transport_sas bnx2x ipr mdio libcrc32c > [12045.222167] CPU: 68 PID: 6178 Comm: sigreturnpanic Not tainted 4.7.0 #34 > [12045.24] task: c000fce38600 ti: c000fceb4000 task.ti: > c000fceb4000 > [12045.93] NIP: c0050a40 LR: c00163bc CTR: > > [12045.222361] REGS: c000fceb7ac0 TRAP: 0700 Not tainted (4.7.0) > [12045.222418] MSR: 900300201033 CR: > 28444280 XER: 2000 > [12045.222625] CFAR: c00163b8 SOFTE: 0 PACATMSCRATCH: 90014280f033 > GPR00: 0110b801 c000fceb7d40 c139c100 c000fce390d0 > GPR04: 90034280f033 > GPR08: b0001033 0001 > GPR12: c2926400 > GPR16: > GPR20: > GPR24: 398cadd0 398cb470 > GPR28: 90034280f033 c000fceb7ea0 0001 c000fce390d0 > [12045.223535] NIP [c0050a40] tm_restore_sprs+0xc/0x1c > [12045.223584] LR [c00163bc] tm_recheckpoint+0x5c/0xa0 > [12045.223630] Call Trace: > [12045.223655] [c000fceb7d80] [c0026e74] > sys_rt_sigreturn+0x494/0x6c0 > [12045.223738] [c000fceb7e30] [c00092e0] system_call+0x38/0x108 > [12045.223806] Instruction dump: > [12045.223841] 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 > f80304b8 > [12045.223955] 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 > 7c0123a6 4e800020 > [12045.224074] ---[ end trace cb8002ee240bae76 ]--- > > It isn't clear exactly if there is really a use case for userspace > returning with a suspended transaction, however, doing so doesn't (on > its own) constitute a bad frame. As such, this patch simply discards > the transactional state of the context calling the sigreturn and > continues. > > Reported-by: Laurent Dufour > Signed-off-by: Cyril Bur > Tested-by: Laurent Dufour > > --- > > V2: Move the code down into the #ifdef CONFIG_PPC_TRANSACTIONAL_MEM > (32 and 64 bit) > Add a small amount of text to Documentation > Adjust the commit message for clarity > > V3: Use MSR_TM_SUSPENDED() instead of MSR_TM_ACTIVE() as TM can *never* be > active in the kernel, let it do a Bad Thing if it is. > > Documentation/powerpc/transactional_memory.txt | 2 ++ > arch/powerpc/kernel/signal_32.c| 14 ++ > arch/powerpc/kernel/signal_64.c| 14 ++ > 3 files changed, 30 insertions(+) > > diff --git a/Documentation/powerpc/transactional_memory.txt > b/Documentation/powerpc/transactional_memory.txt > index ba0a2a4..e32fdbb 100644 > --- a/Documentation/powerpc/transactional_memory.txt > +++ b/Documentation/powerpc/transactional_memory.txt > @@ -167,6 +167,8 @@ signal will be rolled back anyway. > For signals taken in non-TM or suspended mode, we use the > normal/non-checkpointed stack pointer. > > +Any transaction initiated inside a sighandler and suspended on return > +from the sighandler to the kernel will get reclaimed and discarded. > > Failure cause codes used by kernel > == > diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c > index b6aa378..a7daf74 100644 > ---
