[PATCH 3/3] fs/core/vmcore: Move sev_active() reference to x86 arch code

2019-07-11 Thread Thiago Jung Bauermann
Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
appear in generic kernel code because it forces non-x86 architectures to
define the sev_active() function, which doesn't make a lot of sense.

To solve this problem, add an x86 elfcorehdr_read() function to override
the generic weak implementation. To do that, it's necessary to make
read_from_oldmem() public so that it can be used outside of vmcore.c.

Signed-off-by: Thiago Jung Bauermann 
---
 arch/x86/kernel/crash_dump_64.c |  5 +
 fs/proc/vmcore.c|  8 
 include/linux/crash_dump.h  | 14 ++
 include/linux/mem_encrypt.h |  1 -
 4 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
index 22369dd5de3b..045e82e8945b 100644
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -70,3 +70,8 @@ ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char 
*buf, size_t csize,
 {
return __copy_oldmem_page(pfn, buf, csize, offset, userbuf, true);
 }
+
+ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
+{
+   return read_from_oldmem(buf, count, ppos, 0, sev_active());
+}
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 57957c91c6df..ca1f20bedd8c 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -100,9 +100,9 @@ static int pfn_is_ram(unsigned long pfn)
 }
 
 /* Reads a page from the oldmem device from given offset. */
-static ssize_t read_from_oldmem(char *buf, size_t count,
-   u64 *ppos, int userbuf,
-   bool encrypted)
+ssize_t read_from_oldmem(char *buf, size_t count,
+u64 *ppos, int userbuf,
+bool encrypted)
 {
unsigned long pfn, offset;
size_t nr_bytes;
@@ -166,7 +166,7 @@ void __weak elfcorehdr_free(unsigned long long addr)
  */
 ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
 {
-   return read_from_oldmem(buf, count, ppos, 0, sev_active());
+   return read_from_oldmem(buf, count, ppos, 0, false);
 }
 
 /*
diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index f774c5eb9e3c..4664fc1871de 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -115,4 +115,18 @@ static inline int vmcore_add_device_dump(struct 
vmcoredd_data *data)
return -EOPNOTSUPP;
 }
 #endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
+
+#ifdef CONFIG_PROC_VMCORE
+ssize_t read_from_oldmem(char *buf, size_t count,
+u64 *ppos, int userbuf,
+bool encrypted);
+#else
+static inline ssize_t read_from_oldmem(char *buf, size_t count,
+  u64 *ppos, int userbuf,
+  bool encrypted)
+{
+   return -EOPNOTSUPP;
+}
+#endif /* CONFIG_PROC_VMCORE */
+
 #endif /* LINUX_CRASHDUMP_H */
diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
index f2e399fb626b..a3747fcae466 100644
--- a/include/linux/mem_encrypt.h
+++ b/include/linux/mem_encrypt.h
@@ -21,7 +21,6 @@
 
 #else  /* !CONFIG_ARCH_HAS_MEM_ENCRYPT */
 
-static inline bool sev_active(void) { return false; }
 static inline bool mem_encrypt_active(void) { return false; }
 
 #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */


[PATCH 2/3] DMA mapping: Move SME handling to x86-specific files

2019-07-11 Thread Thiago Jung Bauermann
Secure Memory Encryption is an x86-specific feature, so it shouldn't appear
in generic kernel code.

Introduce ARCH_HAS_DMA_CHECK_MASK so that x86 can define its own
dma_check_mask() for the SME check.

In SWIOTLB code, there's no need to mention which memory encryption
feature is active. Also, other architectures will have different names so
this gets unwieldy quickly.

Signed-off-by: Thiago Jung Bauermann 
---
 arch/x86/Kconfig   |  1 +
 arch/x86/include/asm/dma-mapping.h |  7 +++
 arch/x86/include/asm/mem_encrypt.h | 10 ++
 include/linux/mem_encrypt.h| 14 +-
 kernel/dma/Kconfig |  3 +++
 kernel/dma/mapping.c   |  4 ++--
 kernel/dma/swiotlb.c   |  3 +--
 7 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7f4d28da8fe3..dbabe42e7f1c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -61,6 +61,7 @@ config X86
select ARCH_HAS_ACPI_TABLE_UPGRADE  if ACPI
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
+   select ARCH_HAS_DMA_CHECK_MASK
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FILTER_PGPROT
diff --git a/arch/x86/include/asm/dma-mapping.h 
b/arch/x86/include/asm/dma-mapping.h
index 6b15a24930e0..55e710ba95a5 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern int iommu_merge;
 extern int panic_on_overflow;
@@ -23,4 +24,10 @@ static inline const struct dma_map_ops 
*get_arch_dma_ops(struct bus_type *bus)
return dma_ops;
 }
 
+static inline void dma_check_mask(struct device *dev, u64 mask)
+{
+   if (sme_active() && (mask < (((u64)sme_get_me_mask() << 1) - 1)))
+   dev_warn(dev, "SME is active, device will require DMA bounce 
buffers\n");
+}
+
 #endif
diff --git a/arch/x86/include/asm/mem_encrypt.h 
b/arch/x86/include/asm/mem_encrypt.h
index 616f8e637bc3..e4c9e1a57d25 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -95,6 +95,16 @@ early_set_memory_encrypted(unsigned long vaddr, unsigned 
long size) { return 0;
 
 extern char __start_bss_decrypted[], __end_bss_decrypted[], 
__start_bss_decrypted_unused[];
 
+static inline bool mem_encrypt_active(void)
+{
+   return sme_me_mask;
+}
+
+static inline u64 sme_get_me_mask(void)
+{
+   return sme_me_mask;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __X86_MEM_ENCRYPT_H__ */
diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
index b310a9c18113..f2e399fb626b 100644
--- a/include/linux/mem_encrypt.h
+++ b/include/linux/mem_encrypt.h
@@ -21,23 +21,11 @@
 
 #else  /* !CONFIG_ARCH_HAS_MEM_ENCRYPT */
 
-#define sme_me_mask0ULL
-
-static inline bool sme_active(void) { return false; }
 static inline bool sev_active(void) { return false; }
+static inline bool mem_encrypt_active(void) { return false; }
 
 #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */
 
-static inline bool mem_encrypt_active(void)
-{
-   return sme_me_mask;
-}
-
-static inline u64 sme_get_me_mask(void)
-{
-   return sme_me_mask;
-}
-
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 /*
  * The __sme_set() and __sme_clr() macros are useful for adding or removing
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 9decbba255fc..34b44bfba372 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -17,6 +17,9 @@ config ARCH_DMA_ADDR_T_64BIT
 config ARCH_HAS_DMA_COHERENCE_H
bool
 
+config ARCH_HAS_DMA_CHECK_MASK
+   bool
+
 config ARCH_HAS_DMA_SET_MASK
bool
 
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index f7afdadb6770..ed46f88378d4 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -291,11 +291,11 @@ void dma_free_attrs(struct device *dev, size_t size, void 
*cpu_addr,
 }
 EXPORT_SYMBOL(dma_free_attrs);
 
+#ifndef CONFIG_ARCH_HAS_DMA_CHECK_MASK
 static inline void dma_check_mask(struct device *dev, u64 mask)
 {
-   if (sme_active() && (mask < (((u64)sme_get_me_mask() << 1) - 1)))
-   dev_warn(dev, "SME is active, device will require DMA bounce 
buffers\n");
 }
+#endif
 
 int dma_supported(struct device *dev, u64 mask)
 {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 13f0cb080a4d..67482ad6aab2 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -459,8 +459,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
panic("Can not allocate SWIOTLB buffer earlier and can't now 
provide you with the DMA bounce buffer");
 
if (mem_encrypt_active())
-   pr_warn_once("%s is active and system is using DMA bounce 
buffers\n",
-sme_active() ? "SME" : "SEV");
+   pr_warn_once("Memory encryption is active and system is using 
DMA bounce buffers\n");
 
mask = dma_get_seg_boundary(hwdev);
 


[PATCH 1/3] x86/Kconfig: Move ARCH_HAS_MEM_ENCRYPT to arch/Kconfig

2019-07-11 Thread Thiago Jung Bauermann
powerpc and s390 are going to use this feature as well, so put it in a
generic location.

Signed-off-by: Thiago Jung Bauermann 
---
 arch/Kconfig | 3 +++
 arch/x86/Kconfig | 4 +---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index c47b328eada0..4ef3499d4480 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -927,6 +927,9 @@ config LOCK_EVENT_COUNTS
  the chance of application behavior change because of timing
  differences. The counts are reported via debugfs.
 
+config ARCH_HAS_MEM_ENCRYPT
+   bool
+
 source "kernel/gcov/Kconfig"
 
 source "scripts/gcc-plugins/Kconfig"
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 12e02a8f9de7..7f4d28da8fe3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -67,6 +67,7 @@ config X86
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_KCOVif X86_64
+   select ARCH_HAS_MEM_ENCRYPT
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_PMEM_APIif X86_64
select ARCH_HAS_PTE_SPECIAL
@@ -1500,9 +1501,6 @@ config X86_CPA_STATISTICS
  helps to determine the effectiveness of preserving large and huge
  page mappings when mapping protections are changed.
 
-config ARCH_HAS_MEM_ENCRYPT
-   def_bool y
-
 config AMD_MEM_ENCRYPT
bool "AMD Secure Memory Encryption (SME) support"
depends on X86_64 && CPU_SUP_AMD


[PATCH 0/3] Remove x86-specific code from generic headers

2019-07-11 Thread Thiago Jung Bauermann
Hello,

Both powerpc¹ and s390² are adding  headers. Currently,
they have to supply definitions for functions and macros which only have a
meaning on x86: sme_me_mask, sme_active() and sev_active().

Christoph Hellwig made a suggestion to "clean up the Kconfig and generic
headers bits for memory encryption so that we don't need all this
boilerplate code", and this is what this series does.

After this patch set, this is powerpc's :

#ifndef _ASM_POWERPC_MEM_ENCRYPT_H
#define _ASM_POWERPC_MEM_ENCRYPT_H

#include 

static inline bool mem_encrypt_active(void)
{
return is_secure_guest();
}

static inline bool force_dma_unencrypted(struct device *dev)
{
return is_secure_guest();
}

int set_memory_encrypted(unsigned long addr, int numpages);
int set_memory_decrypted(unsigned long addr, int numpages);

#endif /* _ASM_POWERPC_MEM_ENCRYPT_H */

I don't have a way to test SME nor SEV, so the patches have only been build
tested. They assume the presence of the following two commits:

Commit 4eb5fec31e61 ("fs/proc/vmcore: Enable dumping of encrypted memory
when SEV was active"), which is now in Linus' master branch;

Commit e67a5ed1f86f ("dma-direct: Force unencrypted DMA under SME for
certain DMA masks"), which is in dma-mapping/for-next and comes from this
patch:

https://lore.kernel.org/linux-iommu/10b83d9ff31bca88e94da2ff34e30619eb396078.1562785123.git.thomas.lenda...@amd.com/

Thiago Jung Bauermann (3):
  x86/Kconfig: Move ARCH_HAS_MEM_ENCRYPT to arch/Kconfig
  DMA mapping: Move SME handling to x86-specific files
  fs/core/vmcore: Move sev_active() reference to x86 arch code

 arch/Kconfig   |  3 +++
 arch/x86/Kconfig   |  5 ++---
 arch/x86/include/asm/dma-mapping.h |  7 +++
 arch/x86/include/asm/mem_encrypt.h | 10 ++
 arch/x86/kernel/crash_dump_64.c|  5 +
 fs/proc/vmcore.c   |  8 
 include/linux/crash_dump.h | 14 ++
 include/linux/mem_encrypt.h| 15 +--
 kernel/dma/Kconfig |  3 +++
 kernel/dma/mapping.c   |  4 ++--
 kernel/dma/swiotlb.c   |  3 +--
 11 files changed, 52 insertions(+), 25 deletions(-)

-- 

¹ 
https://lore.kernel.org/linuxppc-dev/20190521044912.1375-12-bauer...@linux.ibm.com/
² https://lore.kernel.org/kvm/20190612111236.99538-2-pa...@linux.ibm.com/



Re: [PATCH v2] powerpc/book3s/mm: Update Oops message to print the correct translation in use

2019-07-11 Thread Christophe Leroy




Le 11/07/2019 à 16:58, Aneesh Kumar K.V a écrit :

Avoids confusion when printing Oops message like below

  Faulting instruction address: 0xc008bdb4
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV

This was because we never clear the MMU_FTR_HPTE_TABLE feature flag
even if we run with radix translation. It was discussed that we should
look at this feature flag as an indication of the capability to run
hash translation and we should not clear the flag even if we run in
radix translation. All the code paths check for radix_enabled() check and
if found true consider we are running with radix translation. Follow the
same sequence for finding the MMU translation string to be used in Oops
message.

Signed-off-by: Aneesh Kumar K.V 


Looks good.

Reviewed-by: Christophe Leroy 


---

Changes from V1:
* Don't clear the HPTE feature flag.

  arch/powerpc/kernel/traps.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 11caa0291254..b181d6860f28 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -250,15 +250,22 @@ static void oops_end(unsigned long flags, struct pt_regs 
*regs,
  }
  NOKPROBE_SYMBOL(oops_end);
  
+static char *get_mmu_str(void)

+{
+   if (early_radix_enabled())
+   return " MMU=Radix";
+   if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE))
+   return " MMU=Hash";
+   return "";
+}
+
  static int __die(const char *str, struct pt_regs *regs, long err)
  {
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
  
-	printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",

+   printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
   IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
-  PAGE_SIZE / 1024,
-  early_radix_enabled() ? " MMU=Radix" : "",
-  early_mmu_has_feature(MMU_FTR_HPTE_TABLE) ? " MMU=Hash" : "",
+  PAGE_SIZE / 1024, get_mmu_str(),
   IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
   IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
   IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",



Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

2019-07-11 Thread Al Viro
On Sun, Jul 07, 2019 at 12:57:32AM +1000, Aleksa Sarai wrote:

> @@ -1442,8 +1464,11 @@ static int follow_dotdot_rcu(struct nameidata *nd)
>   struct inode *inode = nd->inode;
>  
>   while (1) {
> - if (path_equal(>path, >root))
> + if (path_equal(>path, >root)) {
> + if (unlikely(nd->flags & LOOKUP_BENEATH))
> + return -EXDEV;

> @@ -1468,6 +1493,8 @@ static int follow_dotdot_rcu(struct nameidata *nd)
>   return -ECHILD;
>   if (>mnt == nd->path.mnt)
>   break;
> + if (unlikely(nd->flags & LOOKUP_XDEV))
> + return -EXDEV;
>   /* we know that mountpoint was pinned */
>   nd->path.dentry = mountpoint;
>   nd->path.mnt = >mnt;
> @@ -1482,6 +1509,8 @@ static int follow_dotdot_rcu(struct nameidata *nd)
>   return -ECHILD;
>   if (!mounted)
>   break;
> + if (unlikely(nd->flags & LOOKUP_XDEV))
> + return -EXDEV;

Are you sure these failure exits in follow_dotdot_rcu() won't give
suprious hard errors?

> + if (unlikely(nd->flags & LOOKUP_BENEATH)) {
> + error = dirfd_path_init(nd);
> + if (unlikely(error))
> + return ERR_PTR(error);
> + nd->root = nd->path;
> + if (!(nd->flags & LOOKUP_RCU))
> + path_get(>root);
> + }
>   if (*s == '/') {
>   if (likely(!nd->root.mnt))
>   set_root(nd);
> @@ -2350,9 +2400,11 @@ static const char *path_init(struct nameidata *nd, 
> unsigned flags)
>   s = ERR_PTR(error);
>   return s;
>   }
> - error = dirfd_path_init(nd);
> - if (unlikely(error))
> - return ERR_PTR(error);
> + if (likely(!nd->path.mnt)) {

Is that a weird way of saying "if we hadn't already called dirfd_path_init()"?


Re: [PATCH v6] cpufreq/pasemi: fix an use-after-free inpas_cpufreq_cpu_init()

2019-07-11 Thread wen.yang99
> > The cpu variable is still being used in the of_get_property() call
> > after the of_node_put() call, which may result in use-after-free.
> >
> > Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
> > Signed-off-by: Wen Yang 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Viresh Kumar 
> > Cc: Michael Ellerman 
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: linux...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> > ---
> > v6: keep the blank line and fix warning: label 'out_unmap_sdcpwr' defined 
> > but not used.
> > v5: put together the code to get, use, and release cpu device_node.
> > v4: restore the blank line.
> > v3: fix a leaked reference.
> > v2: clean up the code according to the advice of viresh.
> >
> >  drivers/cpufreq/pasemi-cpufreq.c | 26 ++
> >  1 file changed, 14 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/cpufreq/pasemi-cpufreq.c 
> > b/drivers/cpufreq/pasemi-cpufreq.c
> > index 6b1e4ab..7d557f9 100644
> > --- a/drivers/cpufreq/pasemi-cpufreq.c
> > +++ b/drivers/cpufreq/pasemi-cpufreq.c
> > @@ -131,10 +131,18 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
> > *policy)
> >  int err = -ENODEV;
> >
> >  cpu = of_get_cpu_node(policy->cpu, NULL);
> > +if (!cpu)
> > +goto out;
> >
> > +max_freqp = of_get_property(cpu, "clock-frequency", NULL);
> >  of_node_put(cpu);
> > -if (!cpu)
> > +if (!max_freqp) {
> > +err = -EINVAL;
> >  goto out;
> > +}
> > +
> > +/* we need the freq in kHz */
> > +max_freq = *max_freqp / 1000;
> >
> >  dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
> >  if (!dn)
> > @@ -171,16 +179,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
> > *policy)
> >  }
> >
> >  pr_debug("init cpufreq on CPU %d\n", policy->cpu);
> > -
> > -max_freqp = of_get_property(cpu, "clock-frequency", NULL);
> > -if (!max_freqp) {
> > -err = -EINVAL;
> > -goto out_unmap_sdcpwr;
> > -}
> > -
> > -/* we need the freq in kHz */
> > -max_freq = *max_freqp / 1000;
> > -
> >  pr_debug("max clock-frequency is at %u kHz\n", max_freq);
> >  pr_debug("initializing frequency table\n");
> >
> > @@ -196,7 +194,11 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
> > *policy)
> >  policy->cur = pas_freqs[cur_astate].frequency;
> >  ppc_proc_freq = policy->cur * 1000ul;
> >
> > -return cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
> > +err = cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
> 
> So you are trying to fix an earlier issue here with this. Should have
> been a separate patch. Over that I have just sent a patch now to make
> this routine return void.
> 
> https://lore.kernel.org/lkml/ee8cf5fb4b4a01fdf9199037ff6d835b935cfd13.1562902877.git.viresh.ku...@linaro.org/
> 
> So all you need to do is to remove the label out_unmap_sdcpwr instead.

Ok, thanks.

--
Cheers,
Wen

Re: [PATCH v9 04/10] namei: split out nd->dfd handling to dirfd_path_init

2019-07-11 Thread Al Viro
On Sun, Jul 07, 2019 at 12:57:31AM +1000, Aleksa Sarai wrote:
> Previously, path_init's handling of *at(dfd, ...) was only done once,
> but with LOOKUP_BENEATH (and LOOKUP_IN_ROOT) we have to parse the
> initial nd->path at different times (before or after absolute path
> handling) depending on whether we have been asked to scope resolution
> within a root.

>   if (*s == '/') {
> - set_root(nd);
> - if (likely(!nd_jump_root(nd)))
> - return s;
> - return ERR_PTR(-ECHILD);

> + if (likely(!nd->root.mnt))
> + set_root(nd);

How can we get there with non-NULL nd->root.mnt, when LOOKUP_ROOT case
has been already handled by that point?

> + error = nd_jump_root(nd);
> + if (unlikely(error))
> + s = ERR_PTR(error);



Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions

2019-07-11 Thread Al Viro
On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:

> @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int dfd, 
> struct filename *name)
>   p->stack = p->internal;
>   p->dfd = dfd;
>   p->name = name;
> - p->total_link_count = old ? old->total_link_count : 0;
> + p->total_link_count = 0;
> + p->acc_mode = 0;
> + p->opath_mask = FMODE_PATH_READ | FMODE_PATH_WRITE;
> + if (old) {
> + p->total_link_count = old->total_link_count;
> + p->acc_mode = old->acc_mode;
> + p->opath_mask = old->opath_mask;
> + }

Huh?  Could somebody explain why traversals of NFS4 referrals should inherit
->acc_mode and ->opath_mask?

>  static __always_inline
> -const char *get_link(struct nameidata *nd)
> +const char *get_link(struct nameidata *nd, bool trailing)
>  {
>   struct saved *last = nd->stack + nd->depth - 1;
>   struct dentry *dentry = last->link.dentry;
> @@ -1081,6 +1134,44 @@ const char *get_link(struct nameidata *nd)
>   } else {
>   res = get(dentry, inode, >done);
>   }
> + /* If we just jumped it was because of a magic-link. */
> + if (unlikely(nd->flags & LOOKUP_JUMPED)) {

That's not quite guaranteed (it is possible to bind a symlink on top
of a regular file, and you will get LOOKUP_JUMPED on the entry into
trailing_symlink() when looking the result up).  Moreover, why bother
with LOOKUP_JUMPED here?  See that
nd->last_type = LAST_BIND;
several lines prior?  That's precisely to be able to recognize those
suckers.

And _that_ would've avoided another piece of ugliness - your LOOKUP_JUMPED
kludge forces you to handle that cra^Wsclero^Wvaluable security hardening
in get_link(), instead of trailing_symlink() where you apparently want
it to be.  Simply because nd_jump_root() done later in get_link() will set
LOOKUP_JUMPED for absolute symlinks, confusing your test.

Moreover, I'm not sure that trailing_symlink() is the right place for
that either - I would be rather tempted to fold do_o_path() into
path_openat(), inline path_lookupat() there (as in
s = path_init(nd, flags);

while (!(error = link_path_walk(s, nd))
&& ((error = lookup_last(nd)) > 0)) {
s = trailing_symlink(nd);
}
if (!error)
error = complete_walk(nd);
if (!error && nd->flags & LOOKUP_DIRECTORY)
if (!d_can_lookup(nd->path.dentry))
error = -ENOTDIR;
if (!error) {
audit_inode(nd->name, nd->path.dentry, 0);
error = vfs_open(>path, file);
}
terminate_walk(nd);
- we don't need LOOKUP_DOWN there) and then we only care about the
two callers of trailing_symlink() that are in path_openat().  Which
is where you have your ->acc_mode and ->opath_mask without the need
to dump them into nameidata.  Or to bring that mess into the
things like stat(2) et.al. - it simply doesn't belong there.

In any case, this "bool trailing" is completely wrong; whether that
check belongs in trailing_symlink() or (some of) its callers, putting
it into get_link() is a mistake, forced by kludgy check for procfs-style
symlinks.


Re: [PATCH v6] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()

2019-07-11 Thread Viresh Kumar
On 12-07-19, 10:44, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
> 
> Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: Michael Ellerman 
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> v6: keep the blank line and fix warning: label 'out_unmap_sdcpwr' defined but 
> not used.
> v5: put together the code to get, use, and release cpu device_node.
> v4: restore the blank line.
> v3: fix a leaked reference.
> v2: clean up the code according to the advice of viresh.
> 
>  drivers/cpufreq/pasemi-cpufreq.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/cpufreq/pasemi-cpufreq.c 
> b/drivers/cpufreq/pasemi-cpufreq.c
> index 6b1e4ab..7d557f9 100644
> --- a/drivers/cpufreq/pasemi-cpufreq.c
> +++ b/drivers/cpufreq/pasemi-cpufreq.c
> @@ -131,10 +131,18 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
> *policy)
>   int err = -ENODEV;
>  
>   cpu = of_get_cpu_node(policy->cpu, NULL);
> + if (!cpu)
> + goto out;
>  
> + max_freqp = of_get_property(cpu, "clock-frequency", NULL);
>   of_node_put(cpu);
> - if (!cpu)
> + if (!max_freqp) {
> + err = -EINVAL;
>   goto out;
> + }
> +
> + /* we need the freq in kHz */
> + max_freq = *max_freqp / 1000;
>  
>   dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
>   if (!dn)
> @@ -171,16 +179,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
> *policy)
>   }
>  
>   pr_debug("init cpufreq on CPU %d\n", policy->cpu);
> -
> - max_freqp = of_get_property(cpu, "clock-frequency", NULL);
> - if (!max_freqp) {
> - err = -EINVAL;
> - goto out_unmap_sdcpwr;
> - }
> -
> - /* we need the freq in kHz */
> - max_freq = *max_freqp / 1000;
> -
>   pr_debug("max clock-frequency is at %u kHz\n", max_freq);
>   pr_debug("initializing frequency table\n");
>  
> @@ -196,7 +194,11 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
> *policy)
>   policy->cur = pas_freqs[cur_astate].frequency;
>   ppc_proc_freq = policy->cur * 1000ul;
>  
> - return cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
> + err = cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());

So you are trying to fix an earlier issue here with this. Should have
been a separate patch. Over that I have just sent a patch now to make
this routine return void.

https://lore.kernel.org/lkml/ee8cf5fb4b4a01fdf9199037ff6d835b935cfd13.1562902877.git.viresh.ku...@linaro.org/

So all you need to do is to remove the label out_unmap_sdcpwr instead.

> + if (err)
> + goto out_unmap_sdcpwr;
> +
> + return 0;
>  
>  out_unmap_sdcpwr:
>   iounmap(sdcpwr_mapbase);
> -- 
> 2.9.5

-- 
viresh


[PATCH] cpufreq: Make cpufreq_generic_init() return void

2019-07-11 Thread Viresh Kumar
It always returns 0 (success) and its return type should really be void.
Over that, many drivers have added error handling code based on its
return value, which is not required at all.

change its return type to void and update all the callers.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/bmips-cpufreq.c |  7 ++-
 drivers/cpufreq/cpufreq.c   |  4 +---
 drivers/cpufreq/davinci-cpufreq.c   |  3 ++-
 drivers/cpufreq/imx6q-cpufreq.c |  6 ++
 drivers/cpufreq/kirkwood-cpufreq.c  |  3 ++-
 drivers/cpufreq/loongson1-cpufreq.c |  8 +++-
 drivers/cpufreq/loongson2_cpufreq.c |  3 ++-
 drivers/cpufreq/maple-cpufreq.c |  3 ++-
 drivers/cpufreq/omap-cpufreq.c  | 15 +--
 drivers/cpufreq/pasemi-cpufreq.c|  3 ++-
 drivers/cpufreq/pmac32-cpufreq.c|  3 ++-
 drivers/cpufreq/pmac64-cpufreq.c|  3 ++-
 drivers/cpufreq/s3c2416-cpufreq.c   |  9 ++---
 drivers/cpufreq/s3c64xx-cpufreq.c   | 15 +++
 drivers/cpufreq/s5pv210-cpufreq.c   |  3 ++-
 drivers/cpufreq/sa1100-cpufreq.c|  3 ++-
 drivers/cpufreq/sa1110-cpufreq.c|  3 ++-
 drivers/cpufreq/spear-cpufreq.c |  3 ++-
 drivers/cpufreq/tegra20-cpufreq.c   |  8 +---
 include/linux/cpufreq.h |  2 +-
 20 files changed, 42 insertions(+), 65 deletions(-)

diff --git a/drivers/cpufreq/bmips-cpufreq.c b/drivers/cpufreq/bmips-cpufreq.c
index 56a4ebbf00e0..2b187d802fe3 100644
--- a/drivers/cpufreq/bmips-cpufreq.c
+++ b/drivers/cpufreq/bmips-cpufreq.c
@@ -141,11 +141,8 @@ static int bmips_cpufreq_init(struct cpufreq_policy 
*policy)
return ret;
}
 
-   ret = cpufreq_generic_init(policy, freq_table, TRANSITION_LATENCY);
-   if (ret)
-   bmips_cpufreq_exit(policy);
-   else
-   pr_info("%s: registered\n", BMIPS_CPUFREQ_NAME);
+   cpufreq_generic_init(policy, freq_table, TRANSITION_LATENCY);
+   pr_info("%s: registered\n", BMIPS_CPUFREQ_NAME);
 
return ret;
 }
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 4d6043ee7834..8dda62367816 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -159,7 +159,7 @@ EXPORT_SYMBOL_GPL(arch_set_freq_scale);
  * - set policies transition latency
  * - policy->cpus with all possible CPUs
  */
-int cpufreq_generic_init(struct cpufreq_policy *policy,
+void cpufreq_generic_init(struct cpufreq_policy *policy,
struct cpufreq_frequency_table *table,
unsigned int transition_latency)
 {
@@ -171,8 +171,6 @@ int cpufreq_generic_init(struct cpufreq_policy *policy,
 * share the clock and voltage and clock.
 */
cpumask_setall(policy->cpus);
-
-   return 0;
 }
 EXPORT_SYMBOL_GPL(cpufreq_generic_init);
 
diff --git a/drivers/cpufreq/davinci-cpufreq.c 
b/drivers/cpufreq/davinci-cpufreq.c
index 3de48ae60c29..297d23cad8b5 100644
--- a/drivers/cpufreq/davinci-cpufreq.c
+++ b/drivers/cpufreq/davinci-cpufreq.c
@@ -90,7 +90,8 @@ static int davinci_cpu_init(struct cpufreq_policy *policy)
 * Setting the latency to 2000 us to accommodate addition of drivers
 * to pre/post change notification list.
 */
-   return cpufreq_generic_init(policy, freq_table, 2000 * 1000);
+   cpufreq_generic_init(policy, freq_table, 2000 * 1000);
+   return 0;
 }
 
 static struct cpufreq_driver davinci_driver = {
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 47ccfa6b17b7..648a09a1778a 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -190,14 +190,12 @@ static int imx6q_set_target(struct cpufreq_policy 
*policy, unsigned int index)
 
 static int imx6q_cpufreq_init(struct cpufreq_policy *policy)
 {
-   int ret;
-
policy->clk = clks[ARM].clk;
-   ret = cpufreq_generic_init(policy, freq_table, transition_latency);
+   cpufreq_generic_init(policy, freq_table, transition_latency);
policy->suspend_freq = max_freq;
dev_pm_opp_of_register_em(policy->cpus);
 
-   return ret;
+   return 0;
 }
 
 static struct cpufreq_driver imx6q_cpufreq_driver = {
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
b/drivers/cpufreq/kirkwood-cpufreq.c
index 7ab564c1f7ae..cb74bdc5baaa 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -85,7 +85,8 @@ static int kirkwood_cpufreq_target(struct cpufreq_policy 
*policy,
 /* Module init and exit code */
 static int kirkwood_cpufreq_cpu_init(struct cpufreq_policy *policy)
 {
-   return cpufreq_generic_init(policy, kirkwood_freq_table, 5000);
+   cpufreq_generic_init(policy, kirkwood_freq_table, 5000);
+   return 0;
 }
 
 static struct cpufreq_driver kirkwood_cpufreq_driver = {
diff --git a/drivers/cpufreq/loongson1-cpufreq.c 
b/drivers/cpufreq/loongson1-cpufreq.c
index 21c9ce8526c0..0ea88778882a 100644
--- a/drivers/cpufreq/loongson1-cpufreq.c
+++ b/drivers/cpufreq/loongson1-cpufreq.c
@@ -81,7 +81,7 @@ static 

[PATCH 03/12] Documentation/ia64: repointer docs to Documentation/arch/ia64

2019-07-11 Thread Alex Shi
Since we move 'ia64' docs to Documentation/arch/ia64 dir,
redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Ard Biesheuvel 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-ker...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
---
 MAINTAINERS | 2 +-
 arch/ia64/kernel/efi.c  | 2 +-
 arch/ia64/kernel/fsys.S | 2 +-
 arch/ia64/mm/ioremap.c  | 2 +-
 arch/ia64/pci/pci.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c21d5464c86f..583c35cba7bc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14286,7 +14286,7 @@ SGI SN-IA64 (Altix) SERIAL CONSOLE DRIVER
 M: Pat Gefre 
 L: linux-i...@vger.kernel.org
 S: Supported
-F: Documentation/ia64/serial.txt
+F: Documentation/arch/ia64/serial.txt
 F: drivers/tty/serial/ioc?_serial.c
 F: include/linux/ioc?.h
 
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 8f106638913c..02cdc38d15e8 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -852,7 +852,7 @@ valid_phys_addr_range (phys_addr_t phys_addr, unsigned long 
size)
 * /dev/mem reads and writes use copy_to_user(), which implicitly
 * uses a granule-sized kernel identity mapping.  It's really
 * only safe to do this for regions in kern_memmap.  For more
-* details, see Documentation/ia64/aliasing.txt.
+* details, see Documentation/arch/ia64/aliasing.txt.
 */
attr = kern_mem_attribute(phys_addr, size);
if (attr & EFI_MEMORY_WB || attr & EFI_MEMORY_UC)
diff --git a/arch/ia64/kernel/fsys.S b/arch/ia64/kernel/fsys.S
index d80c99a5f55d..b493ca74890a 100644
--- a/arch/ia64/kernel/fsys.S
+++ b/arch/ia64/kernel/fsys.S
@@ -28,7 +28,7 @@
 #include 
 
 /*
- * See Documentation/ia64/fsys.txt for details on fsyscalls.
+ * See Documentation/arch/ia64/fsys.txt for details on fsyscalls.
  *
  * On entry to an fsyscall handler:
  *   r10   = 0 (i.e., defaults to "successful syscall return")
diff --git a/arch/ia64/mm/ioremap.c b/arch/ia64/mm/ioremap.c
index 5e3e7b1fdac5..989cc4df9087 100644
--- a/arch/ia64/mm/ioremap.c
+++ b/arch/ia64/mm/ioremap.c
@@ -42,7 +42,7 @@ ioremap (unsigned long phys_addr, unsigned long size)
/*
 * For things in kern_memmap, we must use the same attribute
 * as the rest of the kernel.  For more details, see
-* Documentation/ia64/aliasing.txt.
+* Documentation/arch/ia64/aliasing.txt.
 */
attr = kern_mem_attribute(phys_addr, size);
if (attr & EFI_MEMORY_WB)
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index e308196c2229..6ba87b70e30c 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -450,7 +450,7 @@ pci_mmap_legacy_page_range(struct pci_bus *bus, struct 
vm_area_struct *vma,
return -ENOSYS;
 
/*
-* Avoid attribute aliasing.  See Documentation/ia64/aliasing.txt
+* Avoid attribute aliasing.  See Documentation/arch/ia64/aliasing.txt
 * for more details.
 */
if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size))
-- 
2.19.1.856.g8858448bb



[PATCH 05/12] Documentation/s390: repointer docs to Documentation/arch/

2019-07-11 Thread Alex Shi
Since we move Documentation/s390 docs to Documentation/arch/s390
dir, redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Jonathan Corbet 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: k...@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt | 4 ++--
 Documentation/arch/s390/cds.rst | 2 +-
 Documentation/arch/s390/common_io.rst   | 2 +-
 Documentation/arch/s390/vfio-ccw.rst| 2 +-
 Documentation/driver-api/s390-drivers.rst   | 4 ++--
 MAINTAINERS | 6 +++---
 arch/s390/Kconfig   | 4 ++--
 arch/s390/include/asm/debug.h   | 4 ++--
 drivers/s390/char/zcore.c   | 2 +-
 9 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index f1c433daef6b..4ceb4691245b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -478,7 +478,7 @@
others).
 
ccw_timeout_log [S390]
-   See Documentation/s390/common_io.rst for details.
+   See Documentation/arch/s390/common_io.rst for details.
 
cgroup_disable= [KNL] Disable a particular controller
Format: {name of the controller(s) to disable}
@@ -516,7 +516,7 @@
/selinux/checkreqprot.
 
cio_ignore= [S390]
-   See Documentation/s390/common_io.rst for details.
+   See Documentation/arch/s390/common_io.rst for details.
clk_ignore_unused
[CLK]
Prevents the clock framework from automatically gating
diff --git a/Documentation/arch/s390/cds.rst b/Documentation/arch/s390/cds.rst
index 7006d8209d2e..bcad2a14244a 100644
--- a/Documentation/arch/s390/cds.rst
+++ b/Documentation/arch/s390/cds.rst
@@ -39,7 +39,7 @@ some of them are ESA/390 platform specific.
 
 Note:
   In order to write a driver for S/390, you also need to look into the 
interface
-  described in Documentation/s390/driver-model.rst.
+  described in Documentation/arch/s390/driver-model.rst.
 
 Note for porting drivers from 2.4:
 
diff --git a/Documentation/arch/s390/common_io.rst 
b/Documentation/arch/s390/common_io.rst
index 846485681ce7..6dcb40cb7145 100644
--- a/Documentation/arch/s390/common_io.rst
+++ b/Documentation/arch/s390/common_io.rst
@@ -136,5 +136,5 @@ debugfs entries
 
   The level of logging can be changed to be more or less verbose by piping to
   /sys/kernel/debug/s390dbf/cio_*/level a number between 0 and 6; see the
-  documentation on the S/390 debug feature (Documentation/s390/s390dbf.rst)
+  documentation on the S/390 debug feature 
(Documentation/arch/s390/s390dbf.rst)
   for details.
diff --git a/Documentation/arch/s390/vfio-ccw.rst 
b/Documentation/arch/s390/vfio-ccw.rst
index 1f6d0b56d53e..2e15139e9189 100644
--- a/Documentation/arch/s390/vfio-ccw.rst
+++ b/Documentation/arch/s390/vfio-ccw.rst
@@ -321,6 +321,6 @@ Reference
 1. ESA/s390 Principles of Operation manual (IBM Form. No. SA22-7832)
 2. ESA/390 Common I/O Device Commands manual (IBM Form. No. SA22-7204)
 3. https://en.wikipedia.org/wiki/Channel_I/O
-4. Documentation/s390/cds.rst
+4. Documentation/arch/s390/cds.rst
 5. Documentation/vfio.txt
 6. Documentation/vfio-mediated-device.txt
diff --git a/Documentation/driver-api/s390-drivers.rst 
b/Documentation/driver-api/s390-drivers.rst
index 5158577bc29b..8c0845c4eee7 100644
--- a/Documentation/driver-api/s390-drivers.rst
+++ b/Documentation/driver-api/s390-drivers.rst
@@ -27,7 +27,7 @@ not strictly considered I/O devices. They are considered here 
as well,
 although they are not the focus of this document.
 
 Some additional information can also be found in the kernel source under
-Documentation/s390/driver-model.rst.
+Documentation/arch/s390/driver-model.rst.
 
 The css bus
 ===
@@ -38,7 +38,7 @@ into several categories:
 * Standard I/O subchannels, for use by the system. They have a child
   device on the ccw bus and are described below.
 * I/O subchannels bound to the vfio-ccw driver. See
-  Documentation/s390/vfio-ccw.rst.
+  Documentation/arch/s390/vfio-ccw.rst.
 * Message subchannels. No Linux driver currently exists.
 * CHSC subchannels (at most one). The chsc subchannel driver can be used
   to send asynchronous chsc commands.
diff --git a/MAINTAINERS b/MAINTAINERS
index 583c35cba7bc..2c1e65c236db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13717,7 +13717,7 @@ T:  git 
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git
 S: Supported
 F: arch/s390/
 F: drivers/s390/
-F: Documentation/s390/
+F: Documentation/arch/s390/
 F: 

[PATCH 08/12] Dcumentation/powerpc: repointer docs to Documentation/arch/

2019-07-11 Thread Alex Shi
Since we move Documentation/powerpc docs to Documentation/arch/powerpc
dir, redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Sam Bobroff 
Cc: Jonathan Corbet 
Cc: "Manoj N. Kumar" 
Cc: "Matthew R. Ochs" 
Cc: Uma Krishnan 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 Documentation/PCI/pci-error-recovery.txt | 2 +-
 Documentation/arch/powerpc/cxlflash.txt  | 2 +-
 MAINTAINERS  | 8 
 arch/powerpc/kernel/exceptions-64s.S | 2 +-
 drivers/soc/fsl/qe/qe.c  | 2 +-
 drivers/tty/hvc/hvcs.c   | 2 +-
 include/soc/fsl/qe/qe.h  | 2 +-
 7 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/PCI/pci-error-recovery.txt 
b/Documentation/PCI/pci-error-recovery.txt
index 0b6bb3ef449e..339e7394ef1d 100644
--- a/Documentation/PCI/pci-error-recovery.txt
+++ b/Documentation/PCI/pci-error-recovery.txt
@@ -389,7 +389,7 @@ platforms aren't supposed to share interrupts between many 
devices
 anyway :)
 
 >>> Implementation details for the powerpc platform are discussed in
->>> the file Documentation/powerpc/eeh-pci-error-recovery.txt
+>>> the file Documentation/arch/powerpc/eeh-pci-error-recovery.txt
 
 >>> As of this writing, there is a growing list of device drivers with
 >>> patches implementing error recovery. Not all of these patches are in
diff --git a/Documentation/arch/powerpc/cxlflash.txt 
b/Documentation/arch/powerpc/cxlflash.txt
index a64bdaa0a1cf..479cdb9a44f4 100644
--- a/Documentation/arch/powerpc/cxlflash.txt
+++ b/Documentation/arch/powerpc/cxlflash.txt
@@ -28,7 +28,7 @@ Introduction
 responsible for the initialization of the adapter, setting up the
 special path for user space access, and performing error recovery. It
 communicates directly the Flash Accelerator Functional Unit (AFU)
-as described in Documentation/powerpc/cxl.txt.
+as described in Documentation/arch/powerpc/cxl.txt.
 
 The cxlflash driver supports two, mutually exclusive, modes of
 operation at the device (LUN) level:
diff --git a/MAINTAINERS b/MAINTAINERS
index e1aad1b8224c..7a245d3f02fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4420,7 +4420,7 @@ F:arch/powerpc/platforms/powernv/pci-cxl.c
 F: drivers/misc/cxl/
 F: include/misc/cxl*
 F: include/uapi/misc/cxl.h
-F: Documentation/powerpc/cxl.txt
+F: Documentation/arch/powerpc/cxl.txt
 F: Documentation/ABI/testing/sysfs-class-cxl
 
 CXLFLASH (IBM Coherent Accelerator Processor Interface CAPI Flash) SCSI DRIVER
@@ -4431,7 +4431,7 @@ L:linux-s...@vger.kernel.org
 S: Supported
 F: drivers/scsi/cxlflash/
 F: include/uapi/scsi/cxlflash_ioctl.h
-F: Documentation/powerpc/cxlflash.txt
+F: Documentation/arch/powerpc/cxlflash.txt
 
 CYBERPRO FB DRIVER
 M: Russell King 
@@ -9101,7 +9101,7 @@ F:Documentation/ABI/stable/sysfs-firmware-opal-*
 F: Documentation/devicetree/bindings/powerpc/
 F: Documentation/devicetree/bindings/rtc/rtc-opal.txt
 F: Documentation/devicetree/bindings/i2c/i2c-opal.txt
-F: Documentation/powerpc/
+F: Documentation/arch/powerpc/
 F: arch/powerpc/
 F: drivers/char/tpm/tpm_ibmvtpm*
 F: drivers/crypto/nx/
@@ -12235,7 +12235,7 @@ F:  Documentation/PCI/pci-error-recovery.txt
 F: drivers/pci/pcie/aer.c
 F: drivers/pci/pcie/dpc.c
 F: drivers/pci/pcie/err.c
-F: Documentation/powerpc/eeh-pci-error-recovery.txt
+F: Documentation/arch/powerpc/eeh-pci-error-recovery.txt
 F: arch/powerpc/kernel/eeh*.c
 F: arch/powerpc/platforms/*/eeh*.c
 F: arch/powerpc/include/*/eeh*.h
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 73ba246ca11d..5fa2a348a28e 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -910,7 +910,7 @@ EXC_COMMON(trap_0b_common, 0xb00, unknown_exception)
  *
  * Call convention:
  *
- * syscall register convention is in Documentation/powerpc/syscall64-abi.txt
+ * syscall register convention is in 
Documentation/arch/powerpc/syscall64-abi.txt
  *
  * For hypercalls, the register convention is as follows:
  * r0 volatile
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 62c6ba17991a..c83467942b70 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -419,7 +419,7 @@ static void qe_upload_microcode(const void *base,
 /*
  * Upload a microcode to the I-RAM at a specific address.
  *
- * See Documentation/powerpc/qe_firmware.txt for information on QE microcode
+ * See Documentation/arch/powerpc/qe_firmware.txt for information on QE 
microcode
  * uploading.
  *
  * Currently, only version 1 is supported, so the 'version' field must be
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index cb4db1b3ca3c..5a1c76055117 100644
--- a/drivers/tty/hvc/hvcs.c
+++ b/drivers/tty/hvc/hvcs.c
@@ -47,7 +47,7 @@
  * using the 

[PATCH 04/12] Documentation/m68k: repointer docs to Documentation/arch/

2019-07-11 Thread Alex Shi
Since we move Documentation/m68k docs to Documentation/arch/m68k
dir, redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Jonathan Corbet 
Cc: Will Deacon 
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.rst 
b/Documentation/admin-guide/kernel-parameters.rst
index 5d29ba5ad88c..dc283dcffae8 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -118,7 +118,7 @@ parameter is applicable::
LOOPLoopback device support is enabled.
M68kM68k architecture is enabled.
These options have more detailed description inside of
-   Documentation/m68k/kernel-options.txt.
+   Documentation/arch/m68k/kernel-options.txt.
MDA MDA console support is enabled.
MIPSMIPS architecture is enabled.
MOUSE   Appropriate mouse support is enabled.
-- 
2.19.1.856.g8858448bb



[PATCH 11/12] Documentation/x86: repointer docs to Documentation/arch/

2019-07-11 Thread Alex Shi
Since we move Documentation/x86 docs to Documentation/arch/x86
dir, redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Jonathan Corbet 
Cc: Tony Luck 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Peter Zijlstra 
Cc: Changbin Du 
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: platform-driver-...@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Cc: linux-security-mod...@vger.kernel.org
---
 Documentation/admin-guide/hw-vuln/mds.rst|  2 +-
 Documentation/admin-guide/kernel-parameters.rst  |  6 +++---
 Documentation/admin-guide/kernel-parameters.txt  |  8 
 Documentation/admin-guide/ras.rst|  2 +-
 Documentation/arch/x86/x86_64/5level-paging.rst  |  2 +-
 Documentation/arch/x86/x86_64/boot-options.rst   |  4 ++--
 .../arch/x86/x86_64/fake-numa-for-cpusets.rst|  2 +-
 Documentation/devicetree/booting-without-of.txt  |  2 +-
 Documentation/sysctl/kernel.txt  |  4 ++--
 MAINTAINERS  |  4 ++--
 arch/arm/Kconfig |  2 +-
 arch/x86/Kconfig | 12 ++--
 arch/x86/Kconfig.debug   |  2 +-
 arch/x86/boot/header.S   |  2 +-
 arch/x86/entry/entry_64.S|  2 +-
 arch/x86/include/asm/bootparam_utils.h   |  2 +-
 arch/x86/include/asm/page_64_types.h |  2 +-
 arch/x86/include/asm/pgtable_64_types.h  |  2 +-
 arch/x86/kernel/cpu/microcode/amd.c  |  2 +-
 arch/x86/kernel/kexec-bzimage64.c|  2 +-
 arch/x86/kernel/pci-dma.c|  2 +-
 arch/x86/mm/tlb.c|  2 +-
 arch/x86/platform/pvh/enlighten.c|  2 +-
 drivers/vhost/vhost.c|  2 +-
 security/Kconfig |  2 +-
 tools/include/linux/err.h|  2 +-
 tools/objtool/Documentation/stack-validation.txt |  4 ++--
 27 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/Documentation/admin-guide/hw-vuln/mds.rst 
b/Documentation/admin-guide/hw-vuln/mds.rst
index e3a796c0d3a2..303228380fdc 100644
--- a/Documentation/admin-guide/hw-vuln/mds.rst
+++ b/Documentation/admin-guide/hw-vuln/mds.rst
@@ -58,7 +58,7 @@ Because the buffers are potentially shared between 
Hyper-Threads cross
 Hyper-Thread attacks are possible.
 
 Deeper technical information is available in the MDS specific x86
-architecture section: :ref:`Documentation/x86/mds.rst `.
+architecture section: :ref:`Documentation/arch/x86/mds.rst `.
 
 
 Attack scenarios
diff --git a/Documentation/admin-guide/kernel-parameters.rst 
b/Documentation/admin-guide/kernel-parameters.rst
index dc283dcffae8..7c32484811c8 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -167,7 +167,7 @@ parameter is applicable::
X86-32  X86-32, aka i386 architecture is enabled.
X86-64  X86-64 architecture is enabled.
More X86-64 boot options can be found in
-   Documentation/x86/x86_64/boot-options.rst.
+   Documentation/arch/x86/x86_64/boot-options.rst.
X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
X86_UV  SGI UV support is enabled.
XEN Xen support is enabled
@@ -181,10 +181,10 @@ In addition, the following text indicates that the 
option::
 Parameters denoted with BOOT are actually interpreted by the boot
 loader, and have no meaning to the kernel directly.
 Do not modify the syntax of boot loader parameters without extreme
-need or coordination with .
+need or coordination with .
 
 There are also arch-specific kernel-parameters not documented here.
-See for example .
+See for example .
 
 Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
 a trailing = on the name of any parameter states that that parameter will
diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 4ceb4691245b..d9eb5895ea9e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -963,7 +963,7 @@
for details.
 
nompx   [X86] Disables Intel Memory Protection Extensions.
-   See Documentation/x86/intel_mpx.rst for more
+   See Documentation/arch/x86/intel_mpx.rst for more
information about the feature.
 
nopku   [X86] Disable Memory Protection Keys CPU feature found
@@ -2380,7 +2380,7 @@
 
mce [X86-32] Machine Check Exception
 
-   mce=option  

[PATCH 10/12] Documentation/sparc: repointer docs to Documentation/arch/

2019-07-11 Thread Alex Shi
Since we move Documentation/sparc docs to Documentation/arch/sparc
dir, redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/sbus/char/oradax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/sbus/char/oradax.c b/drivers/sbus/char/oradax.c
index 8af216287a84..c7db146a1dd5 100644
--- a/drivers/sbus/char/oradax.c
+++ b/drivers/sbus/char/oradax.c
@@ -18,7 +18,7 @@
  * the recommended way for applications to use the coprocessor, and
  * the driver interface is not intended for general use.
  *
- * See Documentation/sparc/oradax/oracle-dax.rst for more details.
+ * See Documentation/arch/sparc/oradax/oracle-dax.rst for more details.
  */
 
 #include 
-- 
2.19.1.856.g8858448bb



[PATCH 06/12] Documentation/mips: repointer docs to Documentation/arch/

2019-07-11 Thread Alex Shi
Since we move Documentation/mips docs to Documentation/arch/mips
dir, redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Mauro Carvalho Chehab 
Cc: "David S. Miller" 
Cc: linux-ker...@vger.kernel.org
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2c1e65c236db..03a8c687f87f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10554,7 +10554,7 @@ T:  git 
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git
 Q: http://patchwork.linux-mips.org/project/linux-mips/list/
 S: Supported
 F: Documentation/devicetree/bindings/mips/
-F: Documentation/mips/
+F: Documentation/arch/mips/
 F: arch/mips/
 F: drivers/platform/mips/
 
-- 
2.19.1.856.g8858448bb



[PATCH 01/12] Documentation: move architectures together

2019-07-11 Thread Alex Shi
There are many different archs in Documentation/ dir, it's better to
move them together in 'Documentation/arch' which follows from kernel source.

Signed-off-by: Alex Shi 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
 Documentation/{ => arch}/arm/Booting | 0
 Documentation/{ => arch}/arm/IXP4xx  | 0
 Documentation/{ => arch}/arm/Interrupts  | 0
 Documentation/{ => arch}/arm/Marvell/README  | 0
 Documentation/{ => arch}/arm/Microchip/README| 0
 Documentation/{ => arch}/arm/Netwinder   | 0
 Documentation/{ => arch}/arm/OMAP/DSS| 0
 Documentation/{ => arch}/arm/OMAP/README | 0
 Documentation/{ => arch}/arm/OMAP/omap_pm| 0
 Documentation/{ => arch}/arm/Porting | 0
 Documentation/{ => arch}/arm/README  | 0
 Documentation/{ => arch}/arm/SA1100/ADSBitsy | 0
 Documentation/{ => arch}/arm/SA1100/Assabet  | 0
 Documentation/{ => arch}/arm/SA1100/Brutus   | 0
 Documentation/{ => arch}/arm/SA1100/CERF | 0
 Documentation/{ => arch}/arm/SA1100/FreeBird | 0
 Documentation/{ => arch}/arm/SA1100/GraphicsClient   | 0
 Documentation/{ => arch}/arm/SA1100/GraphicsMaster   | 0
 Documentation/{ => arch}/arm/SA1100/HUW_WEBPANEL | 0
 Documentation/{ => arch}/arm/SA1100/Itsy | 0
 Documentation/{ => arch}/arm/SA1100/LART | 0
 Documentation/{ => arch}/arm/SA1100/PLEB | 0
 Documentation/{ => arch}/arm/SA1100/Pangolin | 0
 Documentation/{ => arch}/arm/SA1100/Tifon| 0
 Documentation/{ => arch}/arm/SA1100/Yopy | 0
 Documentation/{ => arch}/arm/SA1100/empeg| 0
 Documentation/{ => arch}/arm/SA1100/nanoEngine   | 0
 Documentation/{ => arch}/arm/SA1100/serial_UART  | 0
 Documentation/{ => arch}/arm/SH-Mobile/.gitignore| 0
 Documentation/{ => arch}/arm/SPEAr/overview.txt  | 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/CPUfreq.txt | 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/EB2410ITX.txt   | 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/GPIO.txt| 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/H1940.txt   | 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/NAND.txt| 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/Overview.txt| 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/S3C2412.txt | 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/S3C2413.txt | 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/SMDK2440.txt| 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/Suspend.txt | 0
 Documentation/{ => arch}/arm/Samsung-S3C24XX/USB-Host.txt| 0
 Documentation/{ => arch}/arm/Samsung/Bootloader-interface.txt| 0
 Documentation/{ => arch}/arm/Samsung/GPIO.txt| 0
 Documentation/{ => arch}/arm/Samsung/Overview.txt| 0
 Documentation/{ => arch}/arm/Samsung/clksrc-change-registers.awk | 0
 Documentation/{ => arch}/arm/Setup   | 0
 Documentation/{ => arch}/arm/VFP/release-notes.txt   | 0
 Documentation/{ => arch}/arm/cluster-pm-race-avoidance.txt   | 0
 Documentation/{ => arch}/arm/firmware.txt| 0
 Documentation/{ => arch}/arm/kernel_mode_neon.txt| 0
 Documentation/{ => arch}/arm/kernel_user_helpers.txt | 0
 Documentation/{ => arch}/arm/keystone/Overview.txt   | 0
 Documentation/{ => arch}/arm/keystone/knav-qmss.txt  | 0
 Documentation/{ => arch}/arm/mem_alignment   | 0
 Documentation/{ => arch}/arm/memory.txt  | 0
 Documentation/{ => arch}/arm/nwfpe/NOTES | 0
 Documentation/{ => arch}/arm/nwfpe/README| 0
 Documentation/{ => arch}/arm/nwfpe/README.FPE| 0
 Documentation/{ => arch}/arm/nwfpe/TODO  | 0
 Documentation/{ => arch}/arm/pxa/mfp.txt | 0
 Documentation/{ => arch}/arm/sti/overview.txt| 0
 

[PATCH 12/12] Documentation/xtensa: repointer docs to Documentation/arch/

2019-07-11 Thread Alex Shi
Since we move Documentation/xtensa docs to Documentation/arch/xtensa
dir, redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: linux-xte...@linux-xtensa.org
Cc: linux-ker...@vger.kernel.org
---
 arch/xtensa/include/asm/initialize_mmu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/xtensa/include/asm/initialize_mmu.h 
b/arch/xtensa/include/asm/initialize_mmu.h
index 323d05789159..499fe4847490 100644
--- a/arch/xtensa/include/asm/initialize_mmu.h
+++ b/arch/xtensa/include/asm/initialize_mmu.h
@@ -42,7 +42,7 @@
 #if XCHAL_HAVE_S32C1I && (XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0)
 /*
  * We Have Atomic Operation Control (ATOMCTL) Register; Initialize it.
- * For details see Documentation/xtensa/atomctl.txt
+ * For details see Documentation/arch/xtensa/atomctl.txt
  */
 #if XCHAL_DCACHE_IS_COHERENT
movia3, 0x25/* For SMP/MX -- internal for writeback,
-- 
2.19.1.856.g8858448bb



[PATCH 02/12] Documentation/arm: repointer docs to Documentation/arch/arm

2019-07-11 Thread Alex Shi
Since we move 'arm/arm64' docs to Documentation/arch/{arm,arm64} dir,
redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Jonathan Corbet 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
---
 Documentation/arch/arm/Samsung-S3C24XX/GPIO.txt|  2 +-
 .../arch/arm/Samsung-S3C24XX/Overview.txt  |  6 +++---
 Documentation/arch/arm/Samsung/GPIO.txt|  2 +-
 Documentation/arch/arm/Samsung/Overview.txt|  4 ++--
 Documentation/devicetree/bindings/arm/xen.txt  |  2 +-
 Documentation/devicetree/booting-without-of.txt|  4 ++--
 Documentation/translations/zh_CN/arm/Booting   |  4 ++--
 .../translations/zh_CN/arm/kernel_user_helpers.txt |  4 ++--
 MAINTAINERS|  6 +++---
 arch/arm/Kconfig   |  2 +-
 arch/arm/common/mcpm_entry.c   |  2 +-
 arch/arm/common/mcpm_head.S|  2 +-
 arch/arm/common/vlock.S|  2 +-
 arch/arm/include/asm/setup.h   |  2 +-
 arch/arm/include/uapi/asm/setup.h  |  2 +-
 arch/arm/kernel/entry-armv.S   |  2 +-
 arch/arm/mach-exynos/common.h  |  2 +-
 arch/arm/mach-ixp4xx/Kconfig   | 14 +++---
 arch/arm/mach-s3c24xx/pm.c |  2 +-
 arch/arm/mach-sti/Kconfig  |  2 +-
 arch/arm/mm/Kconfig|  4 ++--
 arch/arm/plat-samsung/Kconfig  |  6 +++---
 arch/arm/tools/mach-types  |  2 +-
 arch/arm64/Kconfig |  2 +-
 arch/arm64/kernel/kuser32.S|  2 +-
 arch/mips/bmips/setup.c|  2 +-
 drivers/crypto/sunxi-ss/sun4i-ss-cipher.c  |  2 +-
 drivers/crypto/sunxi-ss/sun4i-ss-core.c|  2 +-
 drivers/crypto/sunxi-ss/sun4i-ss-hash.c|  2 +-
 drivers/crypto/sunxi-ss/sun4i-ss.h |  2 +-
 drivers/input/touchscreen/sun4i-ts.c   |  2 +-
 drivers/tty/serial/Kconfig |  2 +-
 32 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/Documentation/arch/arm/Samsung-S3C24XX/GPIO.txt 
b/Documentation/arch/arm/Samsung-S3C24XX/GPIO.txt
index e8f918b96123..542a95cd82e7 100644
--- a/Documentation/arch/arm/Samsung-S3C24XX/GPIO.txt
+++ b/Documentation/arch/arm/Samsung-S3C24XX/GPIO.txt
@@ -12,7 +12,7 @@ Introduction
   of the s3c2410 GPIO system, please read the Samsung provided
   data-sheet/users manual to find out the complete list.
 
-  See Documentation/arm/Samsung/GPIO.txt for the core implementation.
+  See Documentation/arch/arm/Samsung/GPIO.txt for the core implementation.
 
 
 GPIOLIB
diff --git a/Documentation/arch/arm/Samsung-S3C24XX/Overview.txt 
b/Documentation/arch/arm/Samsung-S3C24XX/Overview.txt
index 00d3c3141e21..8d84a1c6216d 100644
--- a/Documentation/arch/arm/Samsung-S3C24XX/Overview.txt
+++ b/Documentation/arch/arm/Samsung-S3C24XX/Overview.txt
@@ -182,7 +182,7 @@ NAND
   controller. If there are any problems the latest linux-mtd
   code can be found from http://www.linux-mtd.infradead.org/
 
-  For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
+  For more information see Documentation/arch/arm/Samsung-S3C24XX/NAND.txt
 
 
 SD/MMC
@@ -221,8 +221,8 @@ GPIO
   As of v2.6.34, the move towards using gpiolib support is almost
   complete, and very little of the old calls are left.
 
-  See Documentation/arm/Samsung-S3C24XX/GPIO.txt for the S3C24XX specific
-  support and Documentation/arm/Samsung/GPIO.txt for the core Samsung
+  See Documentation/arch/arm/Samsung-S3C24XX/GPIO.txt for the S3C24XX specific
+  support and Documentation/arch/arm/Samsung/GPIO.txt for the core Samsung
   implementation.
 
 
diff --git a/Documentation/arch/arm/Samsung/GPIO.txt 
b/Documentation/arch/arm/Samsung/GPIO.txt
index 795adfd88081..e693603f38af 100644
--- a/Documentation/arch/arm/Samsung/GPIO.txt
+++ b/Documentation/arch/arm/Samsung/GPIO.txt
@@ -11,7 +11,7 @@ specific calls provided alongside the drivers/gpio core.
 S3C24XX (Legacy)
 
 
-See Documentation/arm/Samsung-S3C24XX/GPIO.txt for more information
+See Documentation/arch/arm/Samsung-S3C24XX/GPIO.txt for more information
 about these devices. Their implementation has been brought into line
 with the core samsung implementation described in this document.
 
diff --git a/Documentation/arch/arm/Samsung/Overview.txt 
b/Documentation/arch/arm/Samsung/Overview.txt
index 8f7309bad460..93091054a215 100644
--- a/Documentation/arch/arm/Samsung/Overview.txt
+++ b/Documentation/arch/arm/Samsung/Overview.txt
@@ -11,7 +11,7 @@ Introduction
 
   The currently 

[PATCH 09/12] Dcumentation/sh: repointer docs to Documentation/arch/

2019-07-11 Thread Alex Shi
Since we move Documentation/sh docs to Documentation/arch/sh
dir, redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
 Documentation/conf.py | 2 +-
 MAINTAINERS   | 2 +-
 arch/sh/Kconfig.cpu   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 3b2397bcb565..8bbe421c1d97 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -402,7 +402,7 @@ latex_documents = [
  'The kernel development community', 'manual'),
 ('security/index', 'security.tex', 'The kernel security subsystem manual',
  'The kernel development community', 'manual'),
-('sh/index', 'sh.tex', 'SuperH architecture implementation manual',
+('arch/sh/index', 'sh.tex', 'SuperH architecture implementation manual',
  'The kernel development community', 'manual'),
 ('sound/index', 'sound.tex', 'Linux Sound Subsystem Documentation',
  'The kernel development community', 'manual'),
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a245d3f02fd..84448d5838b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15169,7 +15169,7 @@ M:  Rich Felker 
 L: linux...@vger.kernel.org
 Q: http://patchwork.kernel.org/project/linux-sh/list/
 S: Maintained
-F: Documentation/sh/
+F: Documentation/arch/sh/
 F: arch/sh/
 F: drivers/sh/
 
diff --git a/arch/sh/Kconfig.cpu b/arch/sh/Kconfig.cpu
index 4a4edc7e03d4..fdc8b565241b 100644
--- a/arch/sh/Kconfig.cpu
+++ b/arch/sh/Kconfig.cpu
@@ -94,7 +94,7 @@ config CPU_HAS_SR_RB
  that are lacking this bit must have another method in place for
  accomplishing what is taken care of by the banked registers.
 
- See  for further
+ See  for further
  information on SR.RB and register banking in the kernel in general.
 
 config CPU_HAS_PTEAEX
-- 
2.19.1.856.g8858448bb



[PATCH 07/12] Documentation/parisc: repointer docs to Documentation/arch/

2019-07-11 Thread Alex Shi
Since we move Documentation/parisc docs to Documentation/arch/parisc
dir, redirect the doc pointer to them.

Signed-off-by: Alex Shi 
Cc: Mauro Carvalho Chehab 
Cc: linux-ker...@vger.kernel.org
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 03a8c687f87f..e1aad1b8224c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12000,7 +12000,7 @@ T:  git 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6.git
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
 S: Maintained
 F: arch/parisc/
-F: Documentation/parisc/
+F: Documentation/arch/parisc/
 F: drivers/parisc/
 F: drivers/char/agp/parisc-agp.c
 F: drivers/input/serio/gscps2.c
-- 
2.19.1.856.g8858448bb



[PATCH v6] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()

2019-07-11 Thread Wen Yang
The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.

Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang 
Cc: "Rafael J. Wysocki" 
Cc: Viresh Kumar 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
v6: keep the blank line and fix warning: label 'out_unmap_sdcpwr' defined but 
not used.
v5: put together the code to get, use, and release cpu device_node.
v4: restore the blank line.
v3: fix a leaked reference.
v2: clean up the code according to the advice of viresh.

 drivers/cpufreq/pasemi-cpufreq.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 6b1e4ab..7d557f9 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -131,10 +131,18 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
int err = -ENODEV;
 
cpu = of_get_cpu_node(policy->cpu, NULL);
+   if (!cpu)
+   goto out;
 
+   max_freqp = of_get_property(cpu, "clock-frequency", NULL);
of_node_put(cpu);
-   if (!cpu)
+   if (!max_freqp) {
+   err = -EINVAL;
goto out;
+   }
+
+   /* we need the freq in kHz */
+   max_freq = *max_freqp / 1000;
 
dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
if (!dn)
@@ -171,16 +179,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
}
 
pr_debug("init cpufreq on CPU %d\n", policy->cpu);
-
-   max_freqp = of_get_property(cpu, "clock-frequency", NULL);
-   if (!max_freqp) {
-   err = -EINVAL;
-   goto out_unmap_sdcpwr;
-   }
-
-   /* we need the freq in kHz */
-   max_freq = *max_freqp / 1000;
-
pr_debug("max clock-frequency is at %u kHz\n", max_freq);
pr_debug("initializing frequency table\n");
 
@@ -196,7 +194,11 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
policy->cur = pas_freqs[cur_astate].frequency;
ppc_proc_freq = policy->cur * 1000ul;
 
-   return cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
+   err = cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
+   if (err)
+   goto out_unmap_sdcpwr;
+
+   return 0;
 
 out_unmap_sdcpwr:
iounmap(sdcpwr_mapbase);
-- 
2.9.5



Re: [PATCH v2 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

2019-07-11 Thread Matthew Wilcox
On Thu, Jul 11, 2019 at 11:25:44PM +, Hoan Tran OS wrote:
> In NUMA layout which nodes have memory ranges that span across other nodes,
> the mm driver can detect the memory node id incorrectly.
> 
> For example, with layout below
> Node 0 address:    
> Node 1 address:    
> 
> Note:
>  - Memory from low to high
>  - 0/1: Node id
>  - x: Invalid memory of a node
> 
> When mm probes the memory map, without CONFIG_NODES_SPAN_OTHER_NODES
> config, mm only checks the memory validity but not the node id.
> Because of that, Node 1 also detects the memory from node 0 as below
> when it scans from the start address to the end address of node 1.
> 
> Node 0 address:    
> Node 1 address:    
> 
> This layout could occur on any architecture. This patch enables
> CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA to fix this issue.

How do you know it could occur on any architecture?  Surely you should
just enable this for the architecture where you've noticed the problem.


[Bug 204125] FTBFS on ppc64 big endian and gcc9 because of -mcall-aixdesc and missing __linux__

2019-07-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=204125

--- Comment #7 from Daniel Kolesa (li...@octaforge.org) ---
Btw, turns out an ELFv2 BE kernel requires little to no changes, these two
commits produce a working kernel:

https://github.com/smaeul/linux/commit/7a9d26b7be68c21fd1be524ee4bf797d7b8c3c37
https://github.com/smaeul/linux/commit/c972894da682eff8905d9dbc7efd1bd0f1051bbf

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH v4 7/8] KVM: PPC: Ultravisor: Enter a secure guest

2019-07-11 Thread Nicholas Piggin
Claudio Carvalho's on June 29, 2019 6:08 am:
> From: Sukadev Bhattiprolu 
> 
> To enter a secure guest, we have to go through the ultravisor, therefore
> we do a ucall when we are entering a secure guest.
> 
> This change is needed for any sort of entry to the secure guest from the
> hypervisor, whether it is a return from an hcall, a return from a
> hypervisor interrupt, or the first time that a secure guest vCPU is run.
> 
> If we are returning from an hcall, the results are already in the
> appropriate registers R3:12, except for R3, R6 and R7. R3 has the status
> of the reflected hcall, therefore we move it to R0 for the ultravisor and
> set R3 to the UV_RETURN ucall number. R6,7 were used as temporary
> registers, hence we restore them.
> 
> Have fast_guest_return check the kvm_arch.secure_guest field so that a
> new CPU enters UV when started (in response to a RTAS start-cpu call).
> 
> Thanks to input from Paul Mackerras, Ram Pai and Mike Anderson.
> 
> Signed-off-by: Sukadev Bhattiprolu 
> [ Pass SRR1 in r11 for UV_RETURN, fix kvmppc_msr_interrupt to preserve
>   the MSR_S bit ]
> Signed-off-by: Paul Mackerras 
> [ Fix UV_RETURN ucall number and arch.secure_guest check ]
> Signed-off-by: Ram Pai 
> [ Save the actual R3 in R0 for the ultravisor and use R3 for the
>   UV_RETURN ucall number. Update commit message and ret_to_ultra comment ]
> Signed-off-by: Claudio Carvalho 
> ---
>  arch/powerpc/include/asm/kvm_host.h   |  1 +
>  arch/powerpc/include/asm/ultravisor-api.h |  1 +
>  arch/powerpc/kernel/asm-offsets.c |  1 +
>  arch/powerpc/kvm/book3s_hv_rmhandlers.S   | 40 +++
>  4 files changed, 37 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/kvm_host.h 
> b/arch/powerpc/include/asm/kvm_host.h
> index 013c76a0a03e..184becb62ea4 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -294,6 +294,7 @@ struct kvm_arch {
>   cpumask_t cpu_in_guest;
>   u8 radix;
>   u8 fwnmi_enabled;
> + u8 secure_guest;
>   bool threads_indep;
>   bool nested_enable;
>   pgd_t *pgtable;
> diff --git a/arch/powerpc/include/asm/ultravisor-api.h 
> b/arch/powerpc/include/asm/ultravisor-api.h
> index 141940771add..7c4d0b4ced12 100644
> --- a/arch/powerpc/include/asm/ultravisor-api.h
> +++ b/arch/powerpc/include/asm/ultravisor-api.h
> @@ -19,5 +19,6 @@
>  
>  /* opcodes */
>  #define UV_WRITE_PATE0xF104
> +#define UV_RETURN0xF11C
>  
>  #endif /* _ASM_POWERPC_ULTRAVISOR_API_H */
> diff --git a/arch/powerpc/kernel/asm-offsets.c 
> b/arch/powerpc/kernel/asm-offsets.c
> index 8e02444e9d3d..44742724513e 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -508,6 +508,7 @@ int main(void)
>   OFFSET(KVM_VRMA_SLB_V, kvm, arch.vrma_slb_v);
>   OFFSET(KVM_RADIX, kvm, arch.radix);
>   OFFSET(KVM_FWNMI, kvm, arch.fwnmi_enabled);
> + OFFSET(KVM_SECURE_GUEST, kvm, arch.secure_guest);
>   OFFSET(VCPU_DSISR, kvm_vcpu, arch.shregs.dsisr);
>   OFFSET(VCPU_DAR, kvm_vcpu, arch.shregs.dar);
>   OFFSET(VCPU_VPA, kvm_vcpu, arch.vpa.pinned_addr);
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index cffb365d9d02..89813ca987c2 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* Sign-extend HDEC if not on POWER9 */
>  #define EXTEND_HDEC(reg) \
> @@ -1092,16 +1093,12 @@ BEGIN_FTR_SECTION
>  END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>  
>   ld  r5, VCPU_LR(r4)
> - ld  r6, VCPU_CR(r4)
>   mtlrr5
> - mtcrr6
>  
>   ld  r1, VCPU_GPR(R1)(r4)
>   ld  r2, VCPU_GPR(R2)(r4)
>   ld  r3, VCPU_GPR(R3)(r4)
>   ld  r5, VCPU_GPR(R5)(r4)
> - ld  r6, VCPU_GPR(R6)(r4)
> - ld  r7, VCPU_GPR(R7)(r4)
>   ld  r8, VCPU_GPR(R8)(r4)
>   ld  r9, VCPU_GPR(R9)(r4)
>   ld  r10, VCPU_GPR(R10)(r4)

Just to try to be less arbitrary about things, could you use regs
adjacent to r4? Generally good because then it has a chance to get
our loads paired up (which may not help some CPUs).

Thanks,
Nick


[Bug 204125] FTBFS on ppc64 big endian and gcc9 because of -mcall-aixdesc and missing __linux__

2019-07-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=204125

--- Comment #6 from Daniel Kolesa (li...@octaforge.org) ---
This appears to be the actual reason why the kernel fails to link without
-mcall-aixdesc:

 specifically it's the -mcall-aixdesc that's problematic. but removing
it breaks recordmcount.pl, because nm is looking in the wrong section for
symbols
 so it fails to recognize static symbols and the kernel fails to link
 (quick hack is to update the local-symbol regex from "t" to "d" in
recordmcount.pl)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH v4 3/8] KVM: PPC: Ultravisor: Add generic ultravisor call handler

2019-07-11 Thread Nicholas Piggin
Claudio Carvalho's on June 29, 2019 6:08 am:
> From: Ram Pai 
> 
> Add the ucall() function, which can be used to make ultravisor calls
> with varied number of in and out arguments. Ultravisor calls can be made
> from the host or guests.
> 
> This copies the implementation of plpar_hcall().
> 
> Signed-off-by: Ram Pai 
> [ Change ucall.S to not save CR, rename and move headers, build ucall.S
>   if CONFIG_PPC_POWERNV set, use R3 for the ucall number and add some
>   comments in the code ]
> Signed-off-by: Claudio Carvalho 
> ---
>  arch/powerpc/include/asm/ultravisor-api.h | 20 +++
>  arch/powerpc/include/asm/ultravisor.h | 20 +++
>  arch/powerpc/kernel/Makefile  |  2 +-
>  arch/powerpc/kernel/ucall.S   | 30 +++
>  arch/powerpc/kernel/ultravisor.c  |  4 +++
>  5 files changed, 75 insertions(+), 1 deletion(-)
>  create mode 100644 arch/powerpc/include/asm/ultravisor-api.h
>  create mode 100644 arch/powerpc/kernel/ucall.S
> 
> diff --git a/arch/powerpc/include/asm/ultravisor-api.h 
> b/arch/powerpc/include/asm/ultravisor-api.h
> new file mode 100644
> index ..49e766adabc7
> --- /dev/null
> +++ b/arch/powerpc/include/asm/ultravisor-api.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Ultravisor API.
> + *
> + * Copyright 2019, IBM Corporation.
> + *
> + */
> +#ifndef _ASM_POWERPC_ULTRAVISOR_API_H
> +#define _ASM_POWERPC_ULTRAVISOR_API_H
> +
> +#include 
> +
> +/* Return codes */
> +#define U_NOT_AVAILABLE  H_NOT_AVAILABLE
> +#define U_SUCCESSH_SUCCESS
> +#define U_FUNCTION   H_FUNCTION
> +#define U_PARAMETER  H_PARAMETER
> +
> +#endif /* _ASM_POWERPC_ULTRAVISOR_API_H */
> +
> diff --git a/arch/powerpc/include/asm/ultravisor.h 
> b/arch/powerpc/include/asm/ultravisor.h
> index e5009b0d84ea..a78a2dacfd0b 100644
> --- a/arch/powerpc/include/asm/ultravisor.h
> +++ b/arch/powerpc/include/asm/ultravisor.h
> @@ -8,8 +8,28 @@
>  #ifndef _ASM_POWERPC_ULTRAVISOR_H
>  #define _ASM_POWERPC_ULTRAVISOR_H
>  
> +#include 
> +
> +#if !defined(__ASSEMBLY__)
> +
>  /* Internal functions */
>  extern int early_init_dt_scan_ultravisor(unsigned long node, const char 
> *uname,
>int depth, void *data);
>  
> +/* API functions */
> +#define UCALL_BUFSIZE 4
> +/**
> + * ucall: Make a powerpc ultravisor call.
> + * @opcode: The ultravisor call to make.
> + * @retbuf: Buffer to store up to 4 return arguments in.
> + *
> + * This call supports up to 6 arguments and 4 return arguments. Use
> + * UCALL_BUFSIZE to size the return argument buffer.
> + */
> +#if defined(CONFIG_PPC_POWERNV)
> +long ucall(unsigned long opcode, unsigned long *retbuf, ...);
> +#endif
> +
> +#endif /* !__ASSEMBLY__ */
> +
>  #endif   /* _ASM_POWERPC_ULTRAVISOR_H */
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index f0caa302c8c0..f28baccc0a79 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -154,7 +154,7 @@ endif
>  
>  obj-$(CONFIG_EPAPR_PARAVIRT) += epapr_paravirt.o epapr_hcalls.o
>  obj-$(CONFIG_KVM_GUEST)  += kvm.o kvm_emul.o
> -obj-$(CONFIG_PPC_POWERNV)+= ultravisor.o
> +obj-$(CONFIG_PPC_POWERNV)+= ultravisor.o ucall.o
>  
>  # Disable GCOV, KCOV & sanitizers in odd or sensitive code
>  GCOV_PROFILE_prom_init.o := n
> diff --git a/arch/powerpc/kernel/ucall.S b/arch/powerpc/kernel/ucall.S
> new file mode 100644
> index ..1678f6eb7230
> --- /dev/null
> +++ b/arch/powerpc/kernel/ucall.S
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Generic code to perform an ultravisor call.
> + *
> + * Copyright 2019, IBM Corporation.
> + *
> + */
> +#include 
> +
> +/*
> + * This function is based on the plpar_hcall()

A better comment might be to specify calling convention.

> + */
> +_GLOBAL_TOC(ucall)
> + std r4,STK_PARAM(R4)(r1)/* Save ret buffer */
> + mr  r4,r5
> + mr  r5,r6
> + mr  r6,r7
> + mr  r7,r8
> + mr  r8,r9
> + mr  r9,r10

I guess this is fine, is there any particular reason that you made
the call convention this way rather than leaving regs in place and
r4 is a scratch?

> +
> + sc 2/* Invoke the ultravisor */
> +
> + ld  r12,STK_PARAM(R4)(r1)
> + std r4,  0(r12)
> + std r5,  8(r12)
> + std r6, 16(r12)
> + std r7, 24(r12)
> +



Re: [PATCH v4 1/8] KVM: PPC: Ultravisor: Introduce the MSR_S bit

2019-07-11 Thread Nicholas Piggin
Michael Ellerman's on July 11, 2019 10:57 pm:
> Claudio Carvalho  writes:
>> From: Sukadev Bhattiprolu 
>>
>> The ultravisor processor mode is introduced in POWER platforms that
>> supports the Protected Execution Facility (PEF). Ultravisor is higher
>> privileged than hypervisor mode.
>>
>> In PEF enabled platforms, the MSR_S bit is used to indicate if the
>> thread is in secure state. With the MSR_S bit, the privilege state of
>> the thread is now determined by MSR_S, MSR_HV and MSR_PR, as follows:
>>
>> S   HV  PR
>> ---
>> 0   x   1   problem
>> 1   0   1   problem
>> x   x   0   privileged
>> x   1   0   hypervisor
>> 1   1   0   ultravisor
>> 1   1   1   reserved
> 
> What are you trying to express with the 'x' value?
> 
> I guess you mean it as "either" or "don't care" - but then you have
> cases where it could only have one value, such as hypervisor. I think it
> would be clearer if you spelled it out more explicitly.
> 
>> The hypervisor doesn't (and can't) run with the MSR_S bit set, but a
>> secure guest and the ultravisor firmware do.
> 
> I know you're trying to be helpful, but this comment is really just
> confusing to someone who doesn't have all the documentation.
> 
> I'd really like to see something in Documentation/powerpc describing at
> least the outline of how the system works. I'm pretty sure most of that
> is public, so even if it's mostly a list of references to other
> documentations or presentations that would be fine. But I'm not really
> happy with a whole new processor mode appearing with zero documentation
> in the tree.
> 
>> Signed-off-by: Sukadev Bhattiprolu 
>> Signed-off-by: Ram Pai 
>> [ Update the commit message ]
> 
> It's normal to prefix these comments with your handle to make it clear
> who is saying it.
> 
>> Signed-off-by: Claudio Carvalho 
>> ---
>>  arch/powerpc/include/asm/reg.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
>> index 10caa145f98b..39b4c0a519f5 100644
>> --- a/arch/powerpc/include/asm/reg.h
>> +++ b/arch/powerpc/include/asm/reg.h
>> @@ -38,6 +38,7 @@
>>  #define MSR_TM_LG   32  /* Trans Mem Available */
>>  #define MSR_VEC_LG  25  /* Enable AltiVec */
>>  #define MSR_VSX_LG  23  /* Enable VSX */
>> +#define MSR_S_LG22  /* Secure VM bit */
> 
> I don't think that's the best description, because it's also the
> Ultravisor bit when MSR[HV] = 1.
> 
> So "Secure state" as you have below would be better IMO.

Ooops I see Michael covered everything I wrote, sorry for the noise
I missed the thread.

Thanks,
Nick



Re: [PATCH v4 1/8] KVM: PPC: Ultravisor: Introduce the MSR_S bit

2019-07-11 Thread Nicholas Piggin
Claudio Carvalho's on June 29, 2019 6:08 am:
> From: Sukadev Bhattiprolu 
> 
> The ultravisor processor mode is introduced in POWER platforms that
> supports the Protected Execution Facility (PEF). Ultravisor is higher
> privileged than hypervisor mode.
> 
> In PEF enabled platforms, the MSR_S bit is used to indicate if the
> thread is in secure state. With the MSR_S bit, the privilege state of
> the thread is now determined by MSR_S, MSR_HV and MSR_PR, as follows:
> 
> S   HV  PR
> ---
> 0   x   1   problem
> 1   0   1   problem
> x   x   0   privileged
> x   1   0   hypervisor
> 1   1   0   ultravisor
> 1   1   1   reserved

What does this table mean? I thought 'x' meant either, but in that
case there are several states that can apply to the same
combination of bits.

Would it be clearer to rearrange the table so the columns are the HV
and PR bits we know and love, plus the effect of S=1 on each of them?

  HV  PR  S=0 S=1
  -
  0   0   privileged  privileged (secure guest kernel)
  0   1   problem problem (secure guest userspace)
  1   0   hypervisor  ultravisor
  1   1   problem reserved

Is that accurate?


> 
> The hypervisor doesn't (and can't) run with the MSR_S bit set, but a
> secure guest and the ultravisor firmware do.
> 
> Signed-off-by: Sukadev Bhattiprolu 
> Signed-off-by: Ram Pai 
> [ Update the commit message ]
> Signed-off-by: Claudio Carvalho 
> ---
>  arch/powerpc/include/asm/reg.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 10caa145f98b..39b4c0a519f5 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -38,6 +38,7 @@
>  #define MSR_TM_LG32  /* Trans Mem Available */
>  #define MSR_VEC_LG   25  /* Enable AltiVec */
>  #define MSR_VSX_LG   23  /* Enable VSX */
> +#define MSR_S_LG 22  /* Secure VM bit */
>  #define MSR_POW_LG   18  /* Enable Power Management */
>  #define MSR_WE_LG18  /* Wait State Enable */
>  #define MSR_TGPR_LG  17  /* TLB Update registers in use */
> @@ -71,11 +72,13 @@
>  #define MSR_SF   __MASK(MSR_SF_LG)   /* Enable 64 bit mode */
>  #define MSR_ISF  __MASK(MSR_ISF_LG)  /* Interrupt 64b mode 
> valid on 630 */
>  #define MSR_HV   __MASK(MSR_HV_LG)   /* Hypervisor state */
> +#define MSR_S__MASK(MSR_S_LG)/* Secure state */

This is a real nitpick, but why two different comments for the bit 
number and the mask?



Re: [PATCH v2] powerpc/book3s/mm: Update Oops message to print the correct translation in use

2019-07-11 Thread Nicholas Piggin
Aneesh Kumar K.V's on July 12, 2019 12:58 am:
> Avoids confusion when printing Oops message like below
> 
>  Faulting instruction address: 0xc008bdb4
>  Oops: Kernel access of bad area, sig: 11 [#1]
>  LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
> 
> This was because we never clear the MMU_FTR_HPTE_TABLE feature flag
> even if we run with radix translation. It was discussed that we should
> look at this feature flag as an indication of the capability to run
> hash translation and we should not clear the flag even if we run in
> radix translation. All the code paths check for radix_enabled() check and
> if found true consider we are running with radix translation. Follow the
> same sequence for finding the MMU translation string to be used in Oops
> message.
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
> 
> Changes from V1:
> * Don't clear the HPTE feature flag.

Thanks,

Acked-by: Nicholas Piggin 

> 
>  arch/powerpc/kernel/traps.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 11caa0291254..b181d6860f28 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -250,15 +250,22 @@ static void oops_end(unsigned long flags, struct 
> pt_regs *regs,
>  }
>  NOKPROBE_SYMBOL(oops_end);
>  
> +static char *get_mmu_str(void)
> +{
> + if (early_radix_enabled())
> + return " MMU=Radix";
> + if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE))
> + return " MMU=Hash";
> + return "";
> +}
> +
>  static int __die(const char *str, struct pt_regs *regs, long err)
>  {
>   printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
>  
> - printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
> + printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
>  IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
> -PAGE_SIZE / 1024,
> -early_radix_enabled() ? " MMU=Radix" : "",
> -early_mmu_has_feature(MMU_FTR_HPTE_TABLE) ? " MMU=Hash" : "",
> +PAGE_SIZE / 1024, get_mmu_str(),
>  IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
>  IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
>  IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
> -- 
> 2.21.0
> 
> 


[PATCH v2 5/5] s390: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES

2019-07-11 Thread Hoan Tran OS
Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled
by default with NUMA.

Signed-off-by: Hoan Tran 
---
 arch/s390/Kconfig | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 109243f..788a8e9 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -438,14 +438,6 @@ config HOTPLUG_CPU
  can be controlled through /sys/devices/system/cpu/cpu#.
  Say N if you want to disable CPU hotplug.
 
-# Some NUMA nodes have memory ranges that span
-# other nodes. Even though a pfn is valid and
-# between a node's start and end pfns, it may not
-# reside on that node. See memmap_init_zone()
-# for details. <- They meant memory holes!
-config NODES_SPAN_OTHER_NODES
-   def_bool NUMA
-
 config NUMA
bool "NUMA support"
depends on SMP && SCHED_TOPOLOGY
-- 
2.7.4



[PATCH v2 4/5] sparc: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES

2019-07-11 Thread Hoan Tran OS
Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled
by default with NUMA.

Signed-off-by: Hoan Tran 
---
 arch/sparc/Kconfig | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 26ab6f5..13449ea 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -291,15 +291,6 @@ config NODES_SHIFT
  Specify the maximum number of NUMA Nodes available on the target
  system.  Increases memory reserved to accommodate various tables.
 
-# Some NUMA nodes have memory ranges that span
-# other nodes.  Even though a pfn is valid and
-# between a node's start and end pfns, it may not
-# reside on that node.  See memmap_init_zone()
-# for details.
-config NODES_SPAN_OTHER_NODES
-   def_bool y
-   depends on NEED_MULTIPLE_NODES
-
 config ARCH_SELECT_MEMORY_MODEL
def_bool y if SPARC64
 
-- 
2.7.4



[PATCH v2 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES

2019-07-11 Thread Hoan Tran OS
Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled
by default with NUMA.

Signed-off-by: Hoan Tran 
---
 arch/x86/Kconfig | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2bbbd4d..fa9318c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1567,15 +1567,6 @@ config X86_64_ACPI_NUMA
---help---
  Enable ACPI SRAT based node topology detection.
 
-# Some NUMA nodes have memory ranges that span
-# other nodes.  Even though a pfn is valid and
-# between a node's start and end pfns, it may not
-# reside on that node.  See memmap_init_zone()
-# for details.
-config NODES_SPAN_OTHER_NODES
-   def_bool y
-   depends on X86_64_ACPI_NUMA
-
 config NUMA_EMU
bool "NUMA emulation"
depends on NUMA
-- 
2.7.4



[PATCH v2 2/5] powerpc: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES

2019-07-11 Thread Hoan Tran OS
Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled by
default with NUMA.

Signed-off-by: Hoan Tran 
---
 arch/powerpc/Kconfig | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c1c636..bdde8bc 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -629,15 +629,6 @@ config ARCH_MEMORY_PROBE
def_bool y
depends on MEMORY_HOTPLUG
 
-# Some NUMA nodes have memory ranges that span
-# other nodes.  Even though a pfn is valid and
-# between a node's start and end pfns, it may not
-# reside on that node.  See memmap_init_zone()
-# for details.
-config NODES_SPAN_OTHER_NODES
-   def_bool y
-   depends on NEED_MULTIPLE_NODES
-
 config STDBINUTILS
bool "Using standard binutils settings"
depends on 44x
-- 
2.7.4



[PATCH v2 1/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

2019-07-11 Thread Hoan Tran OS
In NUMA layout which nodes have memory ranges that span across other nodes,
the mm driver can detect the memory node id incorrectly.

For example, with layout below
Node 0 address:    
Node 1 address:    

Note:
 - Memory from low to high
 - 0/1: Node id
 - x: Invalid memory of a node

When mm probes the memory map, without CONFIG_NODES_SPAN_OTHER_NODES
config, mm only checks the memory validity but not the node id.
Because of that, Node 1 also detects the memory from node 0 as below
when it scans from the start address to the end address of node 1.

Node 0 address:    
Node 1 address:    

This layout could occur on any architecture. This patch enables
CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA to fix this issue.

Signed-off-by: Hoan Tran 
---
 mm/page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d66bc8a..6335505 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1413,7 +1413,7 @@ int __meminit early_pfn_to_nid(unsigned long pfn)
 }
 #endif
 
-#ifdef CONFIG_NODES_SPAN_OTHER_NODES
+#ifdef CONFIG_NUMA
 /* Only safe to use early in boot when initialisation is single-threaded */
 static inline bool __meminit early_pfn_in_nid(unsigned long pfn, int node)
 {
-- 
2.7.4



[PATCH v2 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

2019-07-11 Thread Hoan Tran OS
In NUMA layout which nodes have memory ranges that span across other nodes,
the mm driver can detect the memory node id incorrectly.

For example, with layout below
Node 0 address:    
Node 1 address:    

Note:
 - Memory from low to high
 - 0/1: Node id
 - x: Invalid memory of a node

When mm probes the memory map, without CONFIG_NODES_SPAN_OTHER_NODES
config, mm only checks the memory validity but not the node id.
Because of that, Node 1 also detects the memory from node 0 as below
when it scans from the start address to the end address of node 1.

Node 0 address:    
Node 1 address:    

This layout could occur on any architecture. This patch enables
CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA to fix this issue.

V2:
 * Revise the patch description

Hoan Tran (5):
  mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA
  powerpc: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES
  x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES
  sparc: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES
  s390: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES

 arch/powerpc/Kconfig | 9 -
 arch/s390/Kconfig| 8 
 arch/sparc/Kconfig   | 9 -
 arch/x86/Kconfig | 9 -
 mm/page_alloc.c  | 2 +-
 5 files changed, 1 insertion(+), 36 deletions(-)

-- 
2.7.4



Re: [PATCH] mm/kprobes: Add generic kprobe_fault_handler() fallback definition

2019-07-11 Thread Masami Hiramatsu
Hi Anshuman,

On Mon, 8 Jul 2019 09:03:13 +0530
Anshuman Khandual  wrote:

> >> Architectures like parisc enable CONFIG_KROBES without having a definition
> >> for kprobe_fault_handler() which results in a build failure.
> > 
> > Hmm, as far as I can see, kprobe_fault_handler() is closed inside each arch
> > specific code. The reason why include/linux/kprobes.h defines
> > dummy inline function is only for !CONFIG_KPROBES case.
> 
> IIRC Andrew mentioned [1] that we should remove this stub from the generic 
> kprobes
> header because this is very much architecture specific. As we see in this 
> proposed
> patch, except x86 there is no other current user which actually calls this 
> from
> some where when CONFIG_KPROBES is not enabled.
> 
> [1] https://www.spinics.net/lists/linux-mm/msg182649.html

Ah, OK. I saw another branch. Also, this is a bugfix patch against
commit 4dd635bce90e ("mm, kprobes: generalize and rename notify_page_fault() as
 kprobe_page_fault()"), please add Fixes: tag on it.

In this case, we should just add a prototype of kprobe_fault_handler() in
include/linux/kprobes.h, and maybe add a stub of kprobe_fault_handler()
as a weak function, something like below.

int __weak kprobe_fault_handler(struct pt_regs *regs, int trapnr)
{
/*
 * Each architecture which uses kprobe_page_fault() must define
 * a fault handler to handle page fault in kprobe correctly.
 */
WARN_ON_ONCE(1);
return 0;
}

> >> Arch needs to
> >> provide kprobe_fault_handler() as it is platform specific and cannot have
> >> a generic working alternative. But in the event when platform lacks such a
> >> definition there needs to be a fallback.
> > 
> > Wait, indeed that each arch need to implement it, but that is for calling
> > kprobe->fault_handler() as user expected.
> > Hmm, why not fixing those architecture implementations?
> 
> After the recent change which introduced a generic kprobe_page_fault() every
> architecture enabling CONFIG_KPROBES must have a kprobe_fault_handler() which
> was not the case earlier.

As far as I can see, gcc complains it because there is no prototype of
kprobe_fault_handler(). Actually no need to define empty kprobe_fault_handler()
on each arch. If we have a prototype, but no actual function, gcc stops the
error unless the arch depending code uses it. So actually, we don't need above
__weak function.

> Architectures like parisc which does enable KPROBES but
> never used (kprobe_page_fault or kprobe->fault_handler) 
> kprobe_fault_handler() now
> needs one as well.

(Hmm, it sounds like the kprobes porting is incomplete on parisc...)

> I am not sure and will probably require inputs from arch parsic
> folks whether it at all needs one. We dont have a stub or fallback definition 
> for
> kprobe_fault_handler() when CONFIG_KPROBES is enabled just to prevent a build
> failure in such cases.

Yeah, that is a bug, and fixed by adding a prototype, not introducing new macro.

> 
> In such a situation it might be better defining a stub symbol fallback than 
> to try
> to implement one definition which the architecture previously never needed or 
> used.
> AFAICS there is no generic MM callers for kprobe_fault_handler() as well 
> which would
> have made it mandatory for parisc to define a real one.
> 
> > 
> >> This adds a stub kprobe_fault_handler() definition which not only prevents
> >> a build failure but also makes sure that kprobe_page_fault() if called will
> >> always return negative in absence of a sane platform specific alternative.
> > 
> > I don't like introducing this complicated macro only for avoiding (not 
> > fixing)
> > build error. To fix that, kprobes on parisc should implement 
> > kprobe_fault_handler
> > correctly (and call kprobe->fault_handler).
> 
> As I mentioned before parsic might not need a real one. But you are right this
> complicated (if perceived as such) change can be just avoided at least for the
> build failure problem by just defining a stub definition 
> kprobe_fault_handler()
> for arch parsic when CONFIG_KPROBES is enabled. But this patch does some more
> and solves the kprobe_fault_handler() symbol dependency in a more generic way 
> and
> forces kprobe_page_fault() to fail in absence a real arch 
> kprobe_fault_handler().
> Is not it worth solving in this way ?
> 
> > 
> > BTW, even if you need such generic stub, please use a weak function instead
> > of macros for every arch headers.
> 
> There is a bit problem with that. The existing definitions are with different
> signatures and an weak function will need them to be exact same for override
> requiring more code changes. Hence choose to go with a macro in each header.
> 
> arch/arc/include/asm/kprobes.h:int kprobe_fault_handler(struct pt_regs *regs, 
> unsigned long cause);
> arch/arm/include/asm/kprobes.h:int kprobe_fault_handler(struct pt_regs *regs, 
> unsigned int fsr);
> arch/arm64/include/asm/kprobes.h:int kprobe_fault_handler(struct pt_regs 
> *regs, 

Re: [PATCH v3] tpm: tpm_ibm_vtpm: Fix unallocated banks

2019-07-11 Thread Jarkko Sakkinen
On Thu, Jul 11, 2019 at 11:28:24PM +0300, Jarkko Sakkinen wrote:
> On Thu, Jul 11, 2019 at 12:13:35PM -0400, Nayna Jain wrote:
> > The nr_allocated_banks and allocated banks are initialized as part of
> > tpm_chip_register. Currently, this is done as part of auto startup
> > function. However, some drivers, like the ibm vtpm driver, do not run
> > auto startup during initialization. This results in uninitialized memory
> > issue and causes a kernel panic during boot.
> > 
> > This patch moves the pcr allocation outside the auto startup function
> > into tpm_chip_register. This ensures that allocated banks are initialized
> > in any case.
> > 
> > Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with
> > PCR read")
> > Reported-by: Michal Suchanek 
> > Signed-off-by: Nayna Jain 
> > Reviewed-by: Mimi Zohar 
> > Tested-by: Sachin Sant 
> > Tested-by: Michal Suchánek 
> 
> Reviewed-by: Jarkko Sakkinen 

Thanks a lot! It is applied now.

/Jarkko


Re: [PATCH] treewide: Rename rcu_dereference_raw_notrace to _check

2019-07-11 Thread Joel Fernandes
On Thu, Jul 11, 2019 at 4:45 PM Joel Fernandes (Google)
 wrote:
>
> The rcu_dereference_raw_notrace() API name is confusing.
> It is equivalent to rcu_dereference_raw() except that it also does
> sparse pointer checking.
>
> There are only a few users of rcu_dereference_raw_notrace(). This
> patches renames all of them to be rcu_dereference_raw_check with the
> "check" indicating sparse checking.
>
> Signed-off-by: Joel Fernandes (Google) 

There also these _notrace things but I am Ok with leaving them alone for now:
hash_for_each_possible_rcu_notrace
hlist_for_each_entry_rcu_notrace

- Joel


[PATCH] treewide: Rename rcu_dereference_raw_notrace to _check

2019-07-11 Thread Joel Fernandes (Google)
The rcu_dereference_raw_notrace() API name is confusing.
It is equivalent to rcu_dereference_raw() except that it also does
sparse pointer checking.

There are only a few users of rcu_dereference_raw_notrace(). This
patches renames all of them to be rcu_dereference_raw_check with the
"check" indicating sparse checking.

Signed-off-by: Joel Fernandes (Google) 

---
Previous discussion is here:
https://lore.kernel.org/linuxppc-dev/20190528200014.gv28...@linux.ibm.com/T/

 Documentation/RCU/Design/Requirements/Requirements.html | 2 +-
 arch/powerpc/include/asm/kvm_book3s_64.h| 2 +-
 include/linux/rculist.h | 4 ++--
 include/linux/rcupdate.h| 2 +-
 kernel/trace/ftrace_internal.h  | 8 
 kernel/trace/trace.c| 4 ++--
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
b/Documentation/RCU/Design/Requirements/Requirements.html
index f04c467e55c5..467251f7fef6 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -2514,7 +2514,7 @@ disabled across the entire RCU read-side critical section.
 
 It is possible to use tracing on RCU code, but tracing itself
 uses RCU.
-For this reason, rcu_dereference_raw_notrace()
+For this reason, rcu_dereference_raw_check()
 is provided for use by tracing, which avoids the destructive
 recursion that could otherwise ensue.
 This API is also used by virtualization in some architectures,
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h 
b/arch/powerpc/include/asm/kvm_book3s_64.h
index 21b1ed5df888..53388a311967 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -546,7 +546,7 @@ static inline void note_hpte_modification(struct kvm *kvm,
  */
 static inline struct kvm_memslots *kvm_memslots_raw(struct kvm *kvm)
 {
-   return rcu_dereference_raw_notrace(kvm->memslots[0]);
+   return rcu_dereference_raw_check(kvm->memslots[0]);
 }
 
 extern void kvmppc_mmu_debugfs_init(struct kvm *kvm);
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index e91ec9ddcd30..10aab1d2d471 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -642,10 +642,10 @@ static inline void hlist_add_behind_rcu(struct hlist_node 
*n,
  * not do any RCU debugging or tracing.
  */
 #define hlist_for_each_entry_rcu_notrace(pos, head, member)
\
-   for (pos = hlist_entry_safe 
(rcu_dereference_raw_notrace(hlist_first_rcu(head)),\
+   for (pos = hlist_entry_safe 
(rcu_dereference_raw_check(hlist_first_rcu(head)),\
typeof(*(pos)), member);\
pos;\
-   pos = 
hlist_entry_safe(rcu_dereference_raw_notrace(hlist_next_rcu(\
+   pos = 
hlist_entry_safe(rcu_dereference_raw_check(hlist_next_rcu(\
&(pos)->member)), typeof(*(pos)), member))
 
 /**
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 0c9b92799abc..e5161e377ad4 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -478,7 +478,7 @@ do {
  \
  * The no-tracing version of rcu_dereference_raw() must not call
  * rcu_read_lock_held().
  */
-#define rcu_dereference_raw_notrace(p) __rcu_dereference_check((p), 1, __rcu)
+#define rcu_dereference_raw_check(p) __rcu_dereference_check((p), 1, __rcu)
 
 /**
  * rcu_dereference_protected() - fetch RCU pointer when updates prevented
diff --git a/kernel/trace/ftrace_internal.h b/kernel/trace/ftrace_internal.h
index 0515a2096f90..0456e0a3dab1 100644
--- a/kernel/trace/ftrace_internal.h
+++ b/kernel/trace/ftrace_internal.h
@@ -6,22 +6,22 @@
 
 /*
  * Traverse the ftrace_global_list, invoking all entries.  The reason that we
- * can use rcu_dereference_raw_notrace() is that elements removed from this 
list
+ * can use rcu_dereference_raw_check() is that elements removed from this list
  * are simply leaked, so there is no need to interact with a grace-period
- * mechanism.  The rcu_dereference_raw_notrace() calls are needed to handle
+ * mechanism.  The rcu_dereference_raw_check() calls are needed to handle
  * concurrent insertions into the ftrace_global_list.
  *
  * Silly Alpha and silly pointer-speculation compiler optimizations!
  */
 #define do_for_each_ftrace_op(op, list)\
-   op = rcu_dereference_raw_notrace(list); \
+   op = rcu_dereference_raw_check(list);   \
do
 
 /*
  * Optimized for just a single item in the list (as that is the normal case).
  */
 #define while_for_each_ftrace_op(op)   \
-   while (likely(op = 

Re: [PATCH v3] tpm: tpm_ibm_vtpm: Fix unallocated banks

2019-07-11 Thread Jarkko Sakkinen
On Thu, Jul 11, 2019 at 12:13:35PM -0400, Nayna Jain wrote:
> The nr_allocated_banks and allocated banks are initialized as part of
> tpm_chip_register. Currently, this is done as part of auto startup
> function. However, some drivers, like the ibm vtpm driver, do not run
> auto startup during initialization. This results in uninitialized memory
> issue and causes a kernel panic during boot.
> 
> This patch moves the pcr allocation outside the auto startup function
> into tpm_chip_register. This ensures that allocated banks are initialized
> in any case.
> 
> Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with
> PCR read")
> Reported-by: Michal Suchanek 
> Signed-off-by: Nayna Jain 
> Reviewed-by: Mimi Zohar 
> Tested-by: Sachin Sant 
> Tested-by: Michal Suchánek 

Reviewed-by: Jarkko Sakkinen 

/Jarkko


Re: [PATCH v2] tpm: tpm_ibm_vtpm: Fix unallocated banks

2019-07-11 Thread Nayna

Hi Jarkko,


On 07/09/2019 12:38 PM, Jarkko Sakkinen wrote:

On Mon, Jul 08, 2019 at 03:43:04PM -0700, Christoph Hellwig wrote:

On Mon, Jul 08, 2019 at 06:24:04PM -0400, Mimi Zohar wrote:

static int tpm_get_pcr_allocation(struct tpm_chip *chip)
{
int rc;

rc = (chip->flags & TPM_CHIP_FLAG_TPM2) ?
 tpm2_get_pcr_allocation(chip) :
 tpm1_get_pcr_allocation(chip);
return rc > 0 ? -ENODEV : rc;
}

This addresses the issue that Stefan also pointed out. You have to
deal with the TPM error codes.

Hm, in the past I was told by Christoph not to use the ternary
operator.  Have things changed?  Other than removing the comment, the
only other difference is the return.

In the end it is a matter of personal preference, but I find the
quote version above using the ternary horribly obsfucated.

I fully agree that the return statement is an obsfucated mess and
not a good place at all for using ternary operator.


I have posted the v3 version that includes the suggested corrections by 
you and Stefan. Sorry for some delay.


Michal and Sachin, I would appreciate if you can test the v3 version, 
please ?


Thanks & Regards,
 - Nayna



Re: [PATCH V4 2/2] ASoC: fsl_esai: recover the channel swap after xrun

2019-07-11 Thread Nicolin Chen
On Thu, Jul 11, 2019 at 06:49:46PM +0800, shengjiu.w...@nxp.com wrote:
> From: Shengjiu Wang 
> 
> There is chip errata ERR008000, the reference doc is
> (https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf),
> 
> The issue is "While using ESAI transmit or receive and
> an underrun/overrun happens, channel swap may occur.
> The only recovery mechanism is to reset the ESAI."
> 
> This issue exist in imx3/imx5/imx6(partial) series.
> 
> In this commit add a tasklet to handle reset of ESAI
> after xrun happens to recover the channel swap.
> 
> Signed-off-by: Shengjiu Wang 

Acked-by: Nicolin Chen 

Thanks

> ---
>  sound/soc/fsl/fsl_esai.c | 74 
>  1 file changed, 74 insertions(+)
> 
> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> index ab460d6d7432..4ce8ac769244 100644
> --- a/sound/soc/fsl/fsl_esai.c
> +++ b/sound/soc/fsl/fsl_esai.c
> @@ -32,6 +32,7 @@
>   * @extalclk: esai clock source to derive HCK, SCK and FS
>   * @fsysclk: system clock source to derive HCK, SCK and FS
>   * @spbaclk: SPBA clock (optional, depending on SoC design)
> + * @task: tasklet to handle the reset operation
>   * @fifo_depth: depth of tx/rx FIFO
>   * @slot_width: width of each DAI slot
>   * @slots: number of slots
> @@ -42,6 +43,7 @@
>   * @sck_div: if using PSR/PM dividers for SCKx clock
>   * @slave_mode: if fully using DAI slave mode
>   * @synchronous: if using tx/rx synchronous mode
> + * @reset_at_xrun: flags for enable reset operaton
>   * @name: driver name
>   */
>  struct fsl_esai {
> @@ -53,6 +55,7 @@ struct fsl_esai {
>   struct clk *extalclk;
>   struct clk *fsysclk;
>   struct clk *spbaclk;
> + struct tasklet_struct task;
>   u32 fifo_depth;
>   u32 slot_width;
>   u32 slots;
> @@ -65,6 +68,7 @@ struct fsl_esai {
>   bool sck_div[2];
>   bool slave_mode;
>   bool synchronous;
> + bool reset_at_xrun;
>   char name[32];
>  };
>  
> @@ -73,8 +77,16 @@ static irqreturn_t esai_isr(int irq, void *devid)
>   struct fsl_esai *esai_priv = (struct fsl_esai *)devid;
>   struct platform_device *pdev = esai_priv->pdev;
>   u32 esr;
> + u32 saisr;
>  
>   regmap_read(esai_priv->regmap, REG_ESAI_ESR, );
> + regmap_read(esai_priv->regmap, REG_ESAI_SAISR, );
> +
> + if ((saisr & (ESAI_SAISR_TUE | ESAI_SAISR_ROE)) &&
> + esai_priv->reset_at_xrun) {
> + dev_dbg(>dev, "reset module for xrun\n");
> + tasklet_schedule(_priv->task);
> + }
>  
>   if (esr & ESAI_ESR_TINIT_MASK)
>   dev_dbg(>dev, "isr: Transmission Initialized\n");
> @@ -635,10 +647,17 @@ static void fsl_esai_trigger_start(struct fsl_esai 
> *esai_priv, bool tx)
>  ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(mask));
>   regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
>  ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(mask));
> +
> + /* Enable Exception interrupt */
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
> +ESAI_xCR_xEIE_MASK, ESAI_xCR_xEIE);
>  }
>  
>  static void fsl_esai_trigger_stop(struct fsl_esai *esai_priv, bool tx)
>  {
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
> +ESAI_xCR_xEIE_MASK, 0);
> +
>   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
>  tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK, 0);
>   regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
> @@ -653,6 +672,51 @@ static void fsl_esai_trigger_stop(struct fsl_esai 
> *esai_priv, bool tx)
>  ESAI_xFCR_xFR, 0);
>  }
>  
> +static void fsl_esai_hw_reset(unsigned long arg)
> +{
> + struct fsl_esai *esai_priv = (struct fsl_esai *)arg;
> + bool tx = true, rx = false, enabled[2];
> + u32 tfcr, rfcr;
> +
> + /* Save the registers */
> + regmap_read(esai_priv->regmap, REG_ESAI_TFCR, );
> + regmap_read(esai_priv->regmap, REG_ESAI_RFCR, );
> + enabled[tx] = tfcr & ESAI_xFCR_xFEN;
> + enabled[rx] = rfcr & ESAI_xFCR_xFEN;
> +
> + /* Stop the tx & rx */
> + fsl_esai_trigger_stop(esai_priv, tx);
> + fsl_esai_trigger_stop(esai_priv, rx);
> +
> + /* Reset the esai, and ignore return value */
> + fsl_esai_hw_init(esai_priv);
> +
> + /* Enforce ESAI personal resets for both TX and RX */
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> +ESAI_xCR_xPR_MASK, ESAI_xCR_xPR);
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
> +ESAI_xCR_xPR_MASK, ESAI_xCR_xPR);
> +
> + /* Restore registers by regcache_sync, and ignore return value */
> + fsl_esai_register_restore(esai_priv);
> +
> + /* Remove ESAI personal resets by configuring PCRC and PRRC also */
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> +ESAI_xCR_xPR_MASK, 0);
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
> +  

[PATCH v3] tpm: tpm_ibm_vtpm: Fix unallocated banks

2019-07-11 Thread Nayna Jain
The nr_allocated_banks and allocated banks are initialized as part of
tpm_chip_register. Currently, this is done as part of auto startup
function. However, some drivers, like the ibm vtpm driver, do not run
auto startup during initialization. This results in uninitialized memory
issue and causes a kernel panic during boot.

This patch moves the pcr allocation outside the auto startup function
into tpm_chip_register. This ensures that allocated banks are initialized
in any case.

Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with
PCR read")
Reported-by: Michal Suchanek 
Signed-off-by: Nayna Jain 
Reviewed-by: Mimi Zohar 
Tested-by: Sachin Sant 
Tested-by: Michal Suchánek 
---
Changelog:
v3:
* Includes Stefan's feedback correctly:
  * Fixed handling of rc > 0 error
* Includes Jarkko's feedback related to comment and the function.

v2:
* Includes Jarkko's feedbacks
  * fixes the function name to tpm_get_pcr_allocation()
  * adds new function tpm1_get_pcr_allocation()
  * updates patch summary line
  * fixes alignment
  * adds Reported-by: Michal Suchanek 
* Includes Stefan's feedbacks
  * Fixes overwriting of return code
  * Fixes misplacing of tpm_chip_stop()
* Adds Reviewed-by, Tested-by

 drivers/char/tpm/tpm-chip.c | 20 
 drivers/char/tpm/tpm.h  |  2 ++
 drivers/char/tpm/tpm1-cmd.c | 36 
 drivers/char/tpm/tpm2-cmd.c |  6 +-
 4 files changed, 47 insertions(+), 17 deletions(-)

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 8804c9e916fd..5a0396d6560d 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -550,6 +550,20 @@ static int tpm_add_hwrng(struct tpm_chip *chip)
return hwrng_register(>hwrng);
 }
 
+static int tpm_get_pcr_allocation(struct tpm_chip *chip)
+{
+   int rc;
+
+   rc = (chip->flags & TPM_CHIP_FLAG_TPM2) ?
+tpm2_get_pcr_allocation(chip) :
+tpm1_get_pcr_allocation(chip);
+
+   if (rc > 0)
+   return -ENODEV;
+
+   return rc;
+}
+
 /*
  * tpm_chip_register() - create a character device for the TPM chip
  * @chip: TPM chip to use.
@@ -569,6 +583,12 @@ int tpm_chip_register(struct tpm_chip *chip)
if (rc)
return rc;
rc = tpm_auto_startup(chip);
+   if (rc) {
+   tpm_chip_stop(chip);
+   return rc;
+   }
+
+   rc = tpm_get_pcr_allocation(chip);
tpm_chip_stop(chip);
if (rc)
return rc;
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 2cce072f25b5..d571df3694c3 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -399,6 +399,7 @@ int tpm1_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 
*res_buf);
 ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
const char *desc, size_t min_cap_length);
 int tpm1_get_random(struct tpm_chip *chip, u8 *out, size_t max);
+int tpm1_get_pcr_allocation(struct tpm_chip *chip);
 unsigned long tpm_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
 int tpm_pm_suspend(struct device *dev);
 int tpm_pm_resume(struct device *dev);
@@ -454,6 +455,7 @@ int tpm2_unseal_trusted(struct tpm_chip *chip,
 ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,
u32 *value, const char *desc);
 
+ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
 int tpm2_auto_startup(struct tpm_chip *chip);
 void tpm2_shutdown(struct tpm_chip *chip, u16 shutdown_type);
 unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 85dcf2654d11..260a3917f0fe 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -696,18 +696,6 @@ int tpm1_auto_startup(struct tpm_chip *chip)
goto out;
}
 
-   chip->allocated_banks = kcalloc(1, sizeof(*chip->allocated_banks),
-   GFP_KERNEL);
-   if (!chip->allocated_banks) {
-   rc = -ENOMEM;
-   goto out;
-   }
-
-   chip->allocated_banks[0].alg_id = TPM_ALG_SHA1;
-   chip->allocated_banks[0].digest_size = hash_digest_size[HASH_ALGO_SHA1];
-   chip->allocated_banks[0].crypto_id = HASH_ALGO_SHA1;
-   chip->nr_allocated_banks = 1;
-
return rc;
 out:
if (rc > 0)
@@ -776,3 +764,27 @@ int tpm1_pm_suspend(struct tpm_chip *chip, u32 
tpm_suspend_pcr)
return rc;
 }
 
+/**
+ * tpm1_get_pcr_allocation() - initialize the allocated bank
+ * @chip: TPM chip to use.
+ *
+ * The function initializes the SHA1 allocated bank to extend PCR
+ *
+ * Return:
+ * * 0 on success,
+ * * < 0 on error.
+ */
+int tpm1_get_pcr_allocation(struct tpm_chip *chip)
+{
+   chip->allocated_banks = kcalloc(1, sizeof(*chip->allocated_banks),
+   GFP_KERNEL);
+   if (!chip->allocated_banks)
+  

[PATCH v2] powerpc/book3s/mm: Update Oops message to print the correct translation in use

2019-07-11 Thread Aneesh Kumar K.V
Avoids confusion when printing Oops message like below

 Faulting instruction address: 0xc008bdb4
 Oops: Kernel access of bad area, sig: 11 [#1]
 LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV

This was because we never clear the MMU_FTR_HPTE_TABLE feature flag
even if we run with radix translation. It was discussed that we should
look at this feature flag as an indication of the capability to run
hash translation and we should not clear the flag even if we run in
radix translation. All the code paths check for radix_enabled() check and
if found true consider we are running with radix translation. Follow the
same sequence for finding the MMU translation string to be used in Oops
message.

Signed-off-by: Aneesh Kumar K.V 
---

Changes from V1:
* Don't clear the HPTE feature flag.

 arch/powerpc/kernel/traps.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 11caa0291254..b181d6860f28 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -250,15 +250,22 @@ static void oops_end(unsigned long flags, struct pt_regs 
*regs,
 }
 NOKPROBE_SYMBOL(oops_end);
 
+static char *get_mmu_str(void)
+{
+   if (early_radix_enabled())
+   return " MMU=Radix";
+   if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE))
+   return " MMU=Hash";
+   return "";
+}
+
 static int __die(const char *str, struct pt_regs *regs, long err)
 {
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
 
-   printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
+   printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
   IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
-  PAGE_SIZE / 1024,
-  early_radix_enabled() ? " MMU=Radix" : "",
-  early_mmu_has_feature(MMU_FTR_HPTE_TABLE) ? " MMU=Hash" : "",
+  PAGE_SIZE / 1024, get_mmu_str(),
   IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
   IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
   IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
-- 
2.21.0



[PATCH] powerpc/nvdimm: Pick the nearby online node if the device node is not online

2019-07-11 Thread Aneesh Kumar K.V
This is similar to what ACPI does. Nvdimm layer doesn't bring the SCM device
numa node online. Hence we need to make sure we always use an online node
as ndr_desc.numa_node. Otherwise this result in kernel crashes. The target
node is used by dax/kmem and that will bring up the numa node online correctly.

Without this patch, we do hit kernel crash as below because we try to access
uninitialized NODE_DATA in different code paths.

cpu 0x0: Vector: 300 (Data Access) at [c000fac53170]
pc: c04bbc50: ___slab_alloc+0x120/0xca0
lr: c04bc834: __slab_alloc+0x64/0xc0
sp: c000fac53400
   msr: 82009033
   dar: 73e8
 dsisr: 8
  current = 0xc000fabb6d80
  paca= 0xc387   irqmask: 0x03   irq_happened: 0x01
pid   = 7, comm = kworker/u16:0
Linux version 5.2.0-06234-g76bd729b2644 (kvaneesh@ltc-boston123) (gcc version 
7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #135 SMP Thu Jul 11 05:36:30 CDT 2019
enter ? for help
[link register   ] c04bc834 __slab_alloc+0x64/0xc0
[c000fac53400] c000fac53480 (unreliable)
[c000fac53500] c04bc818 __slab_alloc+0x48/0xc0
[c000fac53560] c04c30a0 __kmalloc_node_track_caller+0x3c0/0x6b0
[c000fac535d0] c0cfafe4 devm_kmalloc+0x74/0xc0
[c000fac53600] c0d69434 nd_region_activate+0x144/0x560
[c000fac536d0] c0d6b19c nd_region_probe+0x17c/0x370
[c000fac537b0] c0d6349c nvdimm_bus_probe+0x10c/0x230
[c000fac53840] c0cf3cc4 really_probe+0x254/0x4e0
[c000fac538d0] c0cf429c driver_probe_device+0x16c/0x1e0
[c000fac53950] c0cf0b44 bus_for_each_drv+0x94/0x130
[c000fac539b0] c0cf392c __device_attach+0xdc/0x200
[c000fac53a50] c0cf231c bus_probe_device+0x4c/0xf0
[c000fac53a90] c0ced268 device_add+0x528/0x810
[c000fac53b60] c0d62a58 nd_async_device_register+0x28/0xa0
[c000fac53bd0] c01ccb8c async_run_entry_fn+0xcc/0x1f0
[c000fac53c50] c01bcd9c process_one_work+0x46c/0x860
[c000fac53d20] c01bd4f4 worker_thread+0x364/0x5f0
[c000fac53db0] c01c7260 kthread+0x1b0/0x1c0
[c000fac53e20] c000b954 ret_from_kernel_thread+0x5c/0x68

With the patch we get

 # numactl -H
available: 2 nodes (0-1)
node 0 cpus:
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 
25 26 27 28 29 30 31
node 1 size: 130865 MB
node 1 free: 129130 MB
node distances:
node   0   1
  0:  10  20
  1:  20  10
 # cat /sys/bus/nd/devices/region0/numa_node
0
 # dmesg | grep papr_scm
[   91.332305] papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Region 
registered with target node 2 and online node 0

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/platforms/pseries/papr_scm.c | 30 +--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
b/arch/powerpc/platforms/pseries/papr_scm.c
index c8ec670ee924..4abb0ecda30a 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -255,12 +255,32 @@ static const struct attribute_group 
*papr_scm_dimm_groups[] = {
NULL,
 };
 
+static inline int papr_scm_node(int node)
+{
+   int min_dist = INT_MAX, dist;
+   int nid, min_node;
+
+   if (node_online(node))
+   return node;
+
+   min_node = first_online_node;
+   for_each_online_node(nid) {
+   dist = node_distance(node, nid);
+   if (dist < min_dist) {
+   min_dist = dist;
+   min_node = nid;
+   }
+   }
+   return min_node;
+}
+
 static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
 {
struct device *dev = >pdev->dev;
struct nd_mapping_desc mapping;
struct nd_region_desc ndr_desc;
unsigned long dimm_flags;
+   int target_nid, online_nid;
 
p->bus_desc.ndctl = papr_scm_ndctl;
p->bus_desc.module = THIS_MODULE;
@@ -299,8 +319,11 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
 
memset(_desc, 0, sizeof(ndr_desc));
ndr_desc.attr_groups = region_attr_groups;
-   ndr_desc.numa_node = dev_to_node(>pdev->dev);
-   ndr_desc.target_node = ndr_desc.numa_node;
+   target_nid = dev_to_node(>pdev->dev);
+   online_nid = papr_scm_node(target_nid);
+   set_dev_node(>pdev->dev, online_nid);
+   ndr_desc.numa_node = online_nid;
+   ndr_desc.target_node = target_nid;
ndr_desc.res = >res;
ndr_desc.of_node = p->dn;
ndr_desc.provider_data = p;
@@ -318,6 +341,9 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
ndr_desc.res, p->dn);
goto err;
}
+   if (target_nid != online_nid)
+   dev_info(dev, "Region registered with target node %d and online 
node %d",
+

Re: Coccinelle: Checking of_node_put() calls with SmPL

2019-07-11 Thread Tyrel Datwyler
On 07/10/2019 11:35 PM, wen.yan...@zte.com.cn wrote:
>>> we developed a coccinelle script to detect such problems.
>>
>> Would you find the implementation of the function “dt_init_idle_driver”
>> suspicious according to discussed source code search patterns?
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpuidle/dt_idle_states.c?id=e9a83bd2322035ed9d7dcf35753d3f984d76c6a5#n208
>> https://elixir.bootlin.com/linux/v5.2/source/drivers/cpuidle/dt_idle_states.c#L208
>>
>>
>>> This script is still being improved.
>>
>> Will corresponding software development challenges become more interesting?
> 
> Hello Markus,
> This is the simplified code pattern for it:
> 
> 172 for (i = 0; ; i++) {

This loop can only be exited on a break.

> 173 state_node = of_parse_phandle(...); ---> Obtain here
> ...
> 177 match_id = of_match_node(matches, state_node);
> 178 if (!match_id) {
> 179 err = -ENODEV;  
> 180 break; --->  Jump out of 
> the loop without releasing it
> 181 }
> 182 
> 183 if (!of_device_is_available(state_node)) {
> 184 of_node_put(state_node);
> 185 continue;--->  Release the 
> object references within a loop
> 186 }
> ...
> 208 of_node_put(state_node);  -->  Release the object 
> references within a loop

This is required at the end of every loop or continue to free the reference.
Only a break will exit the loop where we hit the below of_node_put().

> 209 }
> 210 
> 211 of_node_put(state_node);   -->There may be double free 
> here.

None of the break conditions call of_node_put(), so it needs to be called here.

-Tyrel

> 
> This code pattern is very interesting and the coccinelle software should also 
> recognize this pattern.
> 
> Regards,
> Wen
> 



[PATCH -next] powerpc/powernv/ioda: using kfree_rcu() to simplify the code

2019-07-11 Thread YueHaibing
The callback function of call_rcu() just calls a kfree(), so we
can use kfree_rcu() instead of call_rcu() + callback function.

Signed-off-by: YueHaibing 
---
 arch/powerpc/platforms/powernv/pci-ioda-tce.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c 
b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index e28f03e..05f80b1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -332,14 +332,6 @@ long pnv_pci_ioda2_table_alloc_pages(int nid, __u64 
bus_offset,
return -ENOMEM;
 }
 
-static void pnv_iommu_table_group_link_free(struct rcu_head *head)
-{
-   struct iommu_table_group_link *tgl = container_of(head,
-   struct iommu_table_group_link, rcu);
-
-   kfree(tgl);
-}
-
 void pnv_pci_unlink_table_and_group(struct iommu_table *tbl,
struct iommu_table_group *table_group)
 {
@@ -355,7 +347,7 @@ void pnv_pci_unlink_table_and_group(struct iommu_table *tbl,
list_for_each_entry_rcu(tgl, >it_group_list, next) {
if (tgl->table_group == table_group) {
list_del_rcu(>next);
-   call_rcu(>rcu, pnv_iommu_table_group_link_free);
+   kfree_rcu(tgl, rcu);
found = true;
break;
}
-- 
2.7.4




Re: [PATCH v4 8/8] KVM: PPC: Ultravisor: Check for MSR_S during hv_reset_msr

2019-07-11 Thread Michael Ellerman
Claudio Carvalho  writes:
> From: Michael Anderson 
>
>  - Check for MSR_S so that kvmppc_set_msr will include it. Prior to this
>change return to guest would not have the S bit set.

That sounds like it would be bad?

Please spell out what the practical impact of the patch is, ie.
somewhere on the spectrum from "without this patch everything catches
fire", to "this is not a bug but makes things clearer because ..."

cheers

>  - Patch based on comment from Paul Mackerras 
>
> Signed-off-by: Michael Anderson 
> Signed-off-by: Claudio Carvalho 
> Acked-by: Paul Mackerras 
> ---
>  arch/powerpc/kvm/book3s_64_mmu_hv.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
> b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index ab3d484c5e2e..ab62a66f9b4e 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -295,6 +295,7 @@ static void kvmppc_mmu_book3s_64_hv_reset_msr(struct 
> kvm_vcpu *vcpu)
>   msr |= MSR_TS_S;
>   else
>   msr |= vcpu->arch.shregs.msr & MSR_TS_MASK;
> + msr |= vcpu->arch.shregs.msr & MSR_S;
>   kvmppc_set_msr(vcpu, msr);
>  }
>  
> -- 
> 2.20.1


Re: [PATCH v4 7/8] KVM: PPC: Ultravisor: Enter a secure guest

2019-07-11 Thread Michael Ellerman
Claudio Carvalho  writes:
> From: Sukadev Bhattiprolu 
>
> To enter a secure guest, we have to go through the ultravisor, therefore
> we do a ucall when we are entering a secure guest.
>
> This change is needed for any sort of entry to the secure guest from the
> hypervisor, whether it is a return from an hcall, a return from a
> hypervisor interrupt, or the first time that a secure guest vCPU is run.
>
> If we are returning from an hcall, the results are already in the
> appropriate registers R3:12, except for R3, R6 and R7. R3 has the status
> of the reflected hcall, therefore we move it to R0 for the ultravisor and
> set R3 to the UV_RETURN ucall number. R6,7 were used as temporary
> registers, hence we restore them.

This is another case where some documentation would help people to
review the code.

> Have fast_guest_return check the kvm_arch.secure_guest field so that a
> new CPU enters UV when started (in response to a RTAS start-cpu call).
>
> Thanks to input from Paul Mackerras, Ram Pai and Mike Anderson.
>
> Signed-off-by: Sukadev Bhattiprolu 
> [ Pass SRR1 in r11 for UV_RETURN, fix kvmppc_msr_interrupt to preserve
>   the MSR_S bit ]
> Signed-off-by: Paul Mackerras 
> [ Fix UV_RETURN ucall number and arch.secure_guest check ]
> Signed-off-by: Ram Pai 
> [ Save the actual R3 in R0 for the ultravisor and use R3 for the
>   UV_RETURN ucall number. Update commit message and ret_to_ultra comment ]
> Signed-off-by: Claudio Carvalho 
> ---
>  arch/powerpc/include/asm/kvm_host.h   |  1 +
>  arch/powerpc/include/asm/ultravisor-api.h |  1 +
>  arch/powerpc/kernel/asm-offsets.c |  1 +
>  arch/powerpc/kvm/book3s_hv_rmhandlers.S   | 40 +++
>  4 files changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index cffb365d9d02..89813ca987c2 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* Sign-extend HDEC if not on POWER9 */
>  #define EXTEND_HDEC(reg) \
> @@ -1092,16 +1093,12 @@ BEGIN_FTR_SECTION
>  END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>  
>   ld  r5, VCPU_LR(r4)
> - ld  r6, VCPU_CR(r4)
>   mtlrr5
> - mtcrr6
>  
>   ld  r1, VCPU_GPR(R1)(r4)
>   ld  r2, VCPU_GPR(R2)(r4)
>   ld  r3, VCPU_GPR(R3)(r4)
>   ld  r5, VCPU_GPR(R5)(r4)
> - ld  r6, VCPU_GPR(R6)(r4)
> - ld  r7, VCPU_GPR(R7)(r4)
>   ld  r8, VCPU_GPR(R8)(r4)
>   ld  r9, VCPU_GPR(R9)(r4)
>   ld  r10, VCPU_GPR(R10)(r4)
> @@ -1119,10 +1116,38 @@ BEGIN_FTR_SECTION
>   mtspr   SPRN_HDSISR, r0
>  END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
>  
> + ld  r6, VCPU_KVM(r4)
> + lbz r7, KVM_SECURE_GUEST(r6)
> + cmpdi   r7, 0

You could hoist the load of r6 and r7 to here?

> + bne ret_to_ultra
> +
> + lwz r6, VCPU_CR(r4)
> + mtcrr6
> +
> + ld  r7, VCPU_GPR(R7)(r4)
> + ld  r6, VCPU_GPR(R6)(r4)
>   ld  r0, VCPU_GPR(R0)(r4)
>   ld  r4, VCPU_GPR(R4)(r4)
>   HRFI_TO_GUEST
>   b   .
> +/*
> + * We are entering a secure guest, so we have to invoke the ultravisor to do
> + * that. If we are returning from a hcall, the results are already in the
> + * appropriate registers R3:12, except for R3, R6 and R7. R3 has the status 
> of
> + * the reflected hcall, therefore we move it to R0 for the ultravisor and set
> + * R3 to the UV_RETURN ucall number. R6,7 were used as temporary registers
> + * above, hence we restore them.
> + */
> +ret_to_ultra:
> + lwz r6, VCPU_CR(r4)
> + mtcrr6
> + mfspr   r11, SPRN_SRR1
> + mr  r0, r3
> + LOAD_REG_IMMEDIATE(r3, UV_RETURN)

Worth open coding to save three instructions?

> + ld  r7, VCPU_GPR(R7)(r4)
> + ld  r6, VCPU_GPR(R6)(r4)
> + ld  r4, VCPU_GPR(R4)(r4)
> + sc  2
>  
>  /*
>   * Enter the guest on a P9 or later system where we have exactly
> @@ -3318,13 +3343,16 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX)
>   *   r0 is used as a scratch register
>   */
>  kvmppc_msr_interrupt:
> + andis.  r0, r11, MSR_S@h
>   rldicl  r0, r11, 64 - MSR_TS_S_LG, 62
> - cmpwi   r0, 2 /* Check if we are in transactional state..  */
> + cmpwi   cr1, r0, 2 /* Check if we are in transactional state..  */
>   ld  r11, VCPU_INTR_MSR(r9)
> - bne 1f
> + bne cr1, 1f
>   /* ... if transactional, change to suspended */
>   li  r0, 1
>  1:   rldimi  r11, r0, MSR_TS_S_LG, 63 - MSR_TS_T_LG
> + beqlr
> + orisr11, r11, MSR_S@h   /* preserve MSR_S bit setting */
>   blr

I don't see this part mentioned in the change log?

It's also pretty subtle, a comment might be helpful.

cheers


Re: [PATCH v4 6/8] KVM: PPC: Ultravisor: Restrict LDBAR access

2019-07-11 Thread Michael Ellerman
Claudio Carvalho  writes:
> 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.

Please roll up the replies to Alexey's question about LDBAR into the
change log.

> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index f9b2620fbecd..cffb365d9d02 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -375,8 +375,10 @@ BEGIN_FTR_SECTION
>   mtspr   SPRN_RPR, r0
>   ld  r0, KVM_SPLIT_PMMAR(r6)
>   mtspr   SPRN_PMMAR, r0
> +BEGIN_FW_FTR_SECTION_NESTED(70)
>   ld  r0, KVM_SPLIT_LDBAR(r6)
>   mtspr   SPRN_LDBAR, r0
> +END_FW_FTR_SECTION_NESTED(FW_FEATURE_ULTRAVISOR, 0, 70)

That's in Power8 code isn't it? Which will never have an ultravisor.

> diff --git a/arch/powerpc/platforms/powernv/opal-imc.c 
> b/arch/powerpc/platforms/powernv/opal-imc.c
> index 1b6932890a73..5fe2d4526cbc 100644
> --- a/arch/powerpc/platforms/powernv/opal-imc.c
> +++ b/arch/powerpc/platforms/powernv/opal-imc.c
> @@ -254,6 +254,10 @@ static int opal_imc_counters_probe(struct 
> platform_device *pdev)
>   bool core_imc_reg = false, thread_imc_reg = false;
>   u32 type;
>  
> + /* Disable IMC devices, when Ultravisor is enabled. */
> + if (firmware_has_feature(FW_FEATURE_ULTRAVISOR))
> + return -EACCES;

I don't mind taking this change. But at the same time should the IMC
stuff just be omitted from the device tree when we're in ultravisor mode?

cheers


Re: [PATCH v4 4/8] KVM: PPC: Ultravisor: Use UV_WRITE_PATE ucall to register a PATE

2019-07-11 Thread Michael Ellerman
Claudio Carvalho  writes:
> From: Michael Anderson 
>
> When running under an ultravisor, the ultravisor controls the real
> partition table and has it in secure memory where the hypervisor can't
> access it, and therefore we (the HV) have to do a ucall whenever we want
> to update an entry.
>
> The HV still keeps a copy of its view of the partition table in normal
> memory so that the nest MMU can access it.
>
> Both partition tables will have PATE entries for HV and normal virtual

Can you expand novel acronyms on their first usage please, ie. PATE.

> machines.
>
> Suggested-by: Ryan Grimm 

"Suggested" implies this is optional, but it's not :)

I'm not sure exactly what Ryan's input was, but feel free to make up a
better tag :)

> Signed-off-by: Michael Anderson 
> Signed-off-by: Madhavan Srinivasan 
> Signed-off-by: Ram Pai 
> [ Write the pate in HV's table before doing that in UV's ]
> Signed-off-by: Claudio Carvalho 
> ---
>  arch/powerpc/include/asm/ultravisor-api.h |  5 +++-
>  arch/powerpc/include/asm/ultravisor.h | 14 ++
>  arch/powerpc/mm/book3s64/hash_utils.c |  3 +-
>  arch/powerpc/mm/book3s64/pgtable.c| 34 +--
>  arch/powerpc/mm/book3s64/radix_pgtable.c  |  9 --
>  5 files changed, 57 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ultravisor-api.h 
> b/arch/powerpc/include/asm/ultravisor-api.h
> index 49e766adabc7..141940771add 100644
> --- a/arch/powerpc/include/asm/ultravisor-api.h
> +++ b/arch/powerpc/include/asm/ultravisor-api.h
> @@ -15,6 +15,9 @@
>  #define U_SUCCESSH_SUCCESS
>  #define U_FUNCTION   H_FUNCTION
>  #define U_PARAMETER  H_PARAMETER
> +#define U_PERMISSION H_PERMISSION
>  
> -#endif /* _ASM_POWERPC_ULTRAVISOR_API_H */

What happened there? Just a diff artifact?

> +/* opcodes */
> +#define UV_WRITE_PATE0xF104
>  
> +#endif /* _ASM_POWERPC_ULTRAVISOR_API_H */
> diff --git a/arch/powerpc/include/asm/ultravisor.h 
> b/arch/powerpc/include/asm/ultravisor.h
> index a78a2dacfd0b..996c1efd6c6d 100644
> --- a/arch/powerpc/include/asm/ultravisor.h
> +++ b/arch/powerpc/include/asm/ultravisor.h
> @@ -12,6 +12,8 @@
>  
>  #if !defined(__ASSEMBLY__)
>  
> +#include 
> +
>  /* Internal functions */
>  extern int early_init_dt_scan_ultravisor(unsigned long node, const char 
> *uname,
>int depth, void *data);
> @@ -28,8 +30,20 @@ extern int early_init_dt_scan_ultravisor(unsigned long 
> node, const char *uname,
>   */
>  #if defined(CONFIG_PPC_POWERNV)
>  long ucall(unsigned long opcode, unsigned long *retbuf, ...);
> +#else
> +static long ucall(unsigned long opcode, unsigned long *retbuf, ...)
  ^
  inline

> +{
> + return U_NOT_AVAILABLE;
> +}
>  #endif

That should have been in the previous patch.

> +static inline int uv_register_pate(u64 lpid, u64 dw0, u64 dw1)
> +{
> + unsigned long retbuf[UCALL_BUFSIZE];
> +
> + return ucall(UV_WRITE_PATE, retbuf, lpid, dw0, dw1);

You probably want a ucall_norets().

> +}
> +
>  #endif /* !__ASSEMBLY__ */
>  
>  #endif   /* _ASM_POWERPC_ULTRAVISOR_H */
> diff --git a/arch/powerpc/mm/book3s64/hash_utils.c 
> b/arch/powerpc/mm/book3s64/hash_utils.c
> index 1ff451892d7f..220a4e133240 100644
> --- a/arch/powerpc/mm/book3s64/hash_utils.c
> +++ b/arch/powerpc/mm/book3s64/hash_utils.c
> @@ -1080,9 +1080,10 @@ void hash__early_init_mmu_secondary(void)
>  
>   if (!cpu_has_feature(CPU_FTR_ARCH_300))
>   mtspr(SPRN_SDR1, _SDR1);
> - else
> + else if (!firmware_has_feature(FW_FEATURE_ULTRAVISOR))
>   mtspr(SPRN_PTCR,
> __pa(partition_tb) | (PATB_SIZE_SHIFT - 12));

Needs a comment for the else case.

>   }
>   /* Initialize SLB */
>   slb_initialize();
> diff --git a/arch/powerpc/mm/book3s64/pgtable.c 
> b/arch/powerpc/mm/book3s64/pgtable.c
> index ad3dd977c22d..224c5c7c2e3d 100644
> --- a/arch/powerpc/mm/book3s64/pgtable.c
> +++ b/arch/powerpc/mm/book3s64/pgtable.c
> @@ -16,6 +16,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -206,12 +208,25 @@ void __init mmu_partition_table_init(void)
>* 64 K size.
>*/
>   ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
> - mtspr(SPRN_PTCR, ptcr);
> + /*
> +  * If ultravisor is available, it is responsible for creating and
> +  * managing partition table
> +  */

But we just created the partition table?!

This comment and the one below would probably make more sense if they
were merged and appeared further up, where we allocate the partition
table.
  
> + if (!firmware_has_feature(FW_FEATURE_ULTRAVISOR))
> + mtspr(SPRN_PTCR, ptcr);
> +
> + /*
> +  * Since nestMMU cannot access secure memory. Create
> +  * and manage our own partition table. This table

But we just said the 

Re: [PATCH v4 2/8] powerpc: Introduce FW_FEATURE_ULTRAVISOR

2019-07-11 Thread Michael Ellerman
Claudio Carvalho  writes:
> diff --git a/arch/powerpc/include/asm/ultravisor.h 
> b/arch/powerpc/include/asm/ultravisor.h
> new file mode 100644
> index ..e5009b0d84ea
> --- /dev/null
> +++ b/arch/powerpc/include/asm/ultravisor.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Ultravisor definitions
> + *
> + * Copyright 2019, IBM Corporation.
> + *
> + */
> +#ifndef _ASM_POWERPC_ULTRAVISOR_H
> +#define _ASM_POWERPC_ULTRAVISOR_H
> +
> +/* Internal functions */
> +extern int early_init_dt_scan_ultravisor(unsigned long node, const char 
> *uname,
> +  int depth, void *data);

Please don't use extern in new headers.

> diff --git a/arch/powerpc/kernel/ultravisor.c 
> b/arch/powerpc/kernel/ultravisor.c
> new file mode 100644
> index ..dc6021f63c97
> --- /dev/null
> +++ b/arch/powerpc/kernel/ultravisor.c

Is there a reason this (and other later files) aren't in platforms/powernv ?

> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Ultravisor high level interfaces
> + *
> + * Copyright 2019, IBM Corporation.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +int __init early_init_dt_scan_ultravisor(unsigned long node, const char 
> *uname,
> +  int depth, void *data)
> +{
> + if (depth != 1 || strcmp(uname, "ibm,ultravisor") != 0)
> + return 0;

I know you're following the example of OPAL, but this is not the best
way to search for the ultravisor node.

It makes the location and name of the node part of the ABI, when there's
no need for it to be.

If instead you just scan the tree for a node that is *compatible* with
"ibm,ultravisor" (or whatever compatible string) then the node can be
placed any where in the tree and have any name, which gives us the most
flexibility in future to change the location of the device tree node.

cheers


Re: [PATCH v4 3/8] KVM: PPC: Ultravisor: Add generic ultravisor call handler

2019-07-11 Thread Michael Ellerman
Claudio Carvalho  writes:
> From: Ram Pai 
>
> Add the ucall() function, which can be used to make ultravisor calls
> with varied number of in and out arguments. Ultravisor calls can be made
> from the host or guests.
>
> This copies the implementation of plpar_hcall().

.. with quite a few changes?

This is one of the things I'd like to see in a Documentation file, so
that people can review the implementation vs the specification.

> Signed-off-by: Ram Pai 
> [ Change ucall.S to not save CR, rename and move headers, build ucall.S
>   if CONFIG_PPC_POWERNV set, use R3 for the ucall number and add some
>   comments in the code ]

Why are we not saving CR? See previous comment about Documentation :)

> Signed-off-by: Claudio Carvalho 
> ---
>  arch/powerpc/include/asm/ultravisor-api.h | 20 +++
>  arch/powerpc/include/asm/ultravisor.h | 20 +++
>  arch/powerpc/kernel/Makefile  |  2 +-
>  arch/powerpc/kernel/ucall.S   | 30 +++
>  arch/powerpc/kernel/ultravisor.c  |  4 +++
>  5 files changed, 75 insertions(+), 1 deletion(-)
>  create mode 100644 arch/powerpc/include/asm/ultravisor-api.h
>  create mode 100644 arch/powerpc/kernel/ucall.S
>
> diff --git a/arch/powerpc/include/asm/ultravisor-api.h 
> b/arch/powerpc/include/asm/ultravisor-api.h
> new file mode 100644
> index ..49e766adabc7
> --- /dev/null
> +++ b/arch/powerpc/include/asm/ultravisor-api.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Ultravisor API.
> + *
> + * Copyright 2019, IBM Corporation.
> + *
> + */
> +#ifndef _ASM_POWERPC_ULTRAVISOR_API_H
> +#define _ASM_POWERPC_ULTRAVISOR_API_H
> +
> +#include 
> +
> +/* Return codes */
> +#define U_NOT_AVAILABLE  H_NOT_AVAILABLE
> +#define U_SUCCESSH_SUCCESS
> +#define U_FUNCTION   H_FUNCTION
> +#define U_PARAMETER  H_PARAMETER

Is there any benefit in redefining these?

> diff --git a/arch/powerpc/include/asm/ultravisor.h 
> b/arch/powerpc/include/asm/ultravisor.h
> index e5009b0d84ea..a78a2dacfd0b 100644
> --- a/arch/powerpc/include/asm/ultravisor.h
> +++ b/arch/powerpc/include/asm/ultravisor.h
> @@ -8,8 +8,28 @@
>  #ifndef _ASM_POWERPC_ULTRAVISOR_H
>  #define _ASM_POWERPC_ULTRAVISOR_H
>  
> +#include 
> +
> +#if !defined(__ASSEMBLY__)

Just #ifndef is fine.

>  /* Internal functions */

How is it internal?

>  extern int early_init_dt_scan_ultravisor(unsigned long node, const char 
> *uname,
>int depth, void *data);
>  
> +/* API functions */
> +#define UCALL_BUFSIZE 4

Please don't copy this design from the hcall code, it has led to bugs in
the past.

See my (still unmerged) attempt to fix this for the hcall case:
  https://patchwork.ozlabs.org/patch/683577/

Basically instead of asking callers nicely to define a certain sized
buffer, and them forgetting, define a proper type that has the right size.

> +/**
> + * ucall: Make a powerpc ultravisor call.
> + * @opcode: The ultravisor call to make.
> + * @retbuf: Buffer to store up to 4 return arguments in.
> + *
> + * This call supports up to 6 arguments and 4 return arguments. Use
> + * UCALL_BUFSIZE to size the return argument buffer.
> + */
> +#if defined(CONFIG_PPC_POWERNV)

#ifdef

> +long ucall(unsigned long opcode, unsigned long *retbuf, ...);
> +#endif
> +
> +#endif /* !__ASSEMBLY__ */
> +
>  #endif   /* _ASM_POWERPC_ULTRAVISOR_H */
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index f0caa302c8c0..f28baccc0a79 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -154,7 +154,7 @@ endif
>  
>  obj-$(CONFIG_EPAPR_PARAVIRT) += epapr_paravirt.o epapr_hcalls.o
>  obj-$(CONFIG_KVM_GUEST)  += kvm.o kvm_emul.o
> -obj-$(CONFIG_PPC_POWERNV)+= ultravisor.o
> +obj-$(CONFIG_PPC_POWERNV)+= ultravisor.o ucall.o

Same comment about being platforms/powernv ?
> 
> diff --git a/arch/powerpc/kernel/ucall.S b/arch/powerpc/kernel/ucall.S
> new file mode 100644
> index ..1678f6eb7230
> --- /dev/null
> +++ b/arch/powerpc/kernel/ucall.S
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Generic code to perform an ultravisor call.
> + *
> + * Copyright 2019, IBM Corporation.
> + *
> + */
> +#include 
> +
> +/*
> + * This function is based on the plpar_hcall()

I don't think it meaningfully is any more.

> + */
> +_GLOBAL_TOC(ucall)

You don't need the TOC setup here (unless a later patch does?).

> + std r4,STK_PARAM(R4)(r1)/* Save ret buffer */
> + mr  r4,r5
> + mr  r5,r6
> + mr  r6,r7
> + mr  r7,r8
> + mr  r8,r9
> + mr  r9,r10

Below you space the arguments, here you don't. Pick one or the other please.

> +
> + sc 2/* Invoke the ultravisor */
> +
> + ld  r12,STK_PARAM(R4)(r1)
> + std r4,  0(r12)
> + std r5,  8(r12)
> + std r6, 16(r12)

Re: [PATCH v4 1/8] KVM: PPC: Ultravisor: Introduce the MSR_S bit

2019-07-11 Thread Michael Ellerman
Claudio Carvalho  writes:
> From: Sukadev Bhattiprolu 
>
> The ultravisor processor mode is introduced in POWER platforms that
> supports the Protected Execution Facility (PEF). Ultravisor is higher
> privileged than hypervisor mode.
>
> In PEF enabled platforms, the MSR_S bit is used to indicate if the
> thread is in secure state. With the MSR_S bit, the privilege state of
> the thread is now determined by MSR_S, MSR_HV and MSR_PR, as follows:
>
> S   HV  PR
> ---
> 0   x   1   problem
> 1   0   1   problem
> x   x   0   privileged
> x   1   0   hypervisor
> 1   1   0   ultravisor
> 1   1   1   reserved

What are you trying to express with the 'x' value?

I guess you mean it as "either" or "don't care" - but then you have
cases where it could only have one value, such as hypervisor. I think it
would be clearer if you spelled it out more explicitly.

> The hypervisor doesn't (and can't) run with the MSR_S bit set, but a
> secure guest and the ultravisor firmware do.

I know you're trying to be helpful, but this comment is really just
confusing to someone who doesn't have all the documentation.

I'd really like to see something in Documentation/powerpc describing at
least the outline of how the system works. I'm pretty sure most of that
is public, so even if it's mostly a list of references to other
documentations or presentations that would be fine. But I'm not really
happy with a whole new processor mode appearing with zero documentation
in the tree.

> Signed-off-by: Sukadev Bhattiprolu 
> Signed-off-by: Ram Pai 
> [ Update the commit message ]

It's normal to prefix these comments with your handle to make it clear
who is saying it.

> Signed-off-by: Claudio Carvalho 
> ---
>  arch/powerpc/include/asm/reg.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 10caa145f98b..39b4c0a519f5 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -38,6 +38,7 @@
>  #define MSR_TM_LG32  /* Trans Mem Available */
>  #define MSR_VEC_LG   25  /* Enable AltiVec */
>  #define MSR_VSX_LG   23  /* Enable VSX */
> +#define MSR_S_LG 22  /* Secure VM bit */

I don't think that's the best description, because it's also the
Ultravisor bit when MSR[HV] = 1.

So "Secure state" as you have below would be better IMO.

cheers

>  #define MSR_POW_LG   18  /* Enable Power Management */
>  #define MSR_WE_LG18  /* Wait State Enable */
>  #define MSR_TGPR_LG  17  /* TLB Update registers in use */
> @@ -71,11 +72,13 @@
>  #define MSR_SF   __MASK(MSR_SF_LG)   /* Enable 64 bit mode */
>  #define MSR_ISF  __MASK(MSR_ISF_LG)  /* Interrupt 64b mode 
> valid on 630 */
>  #define MSR_HV   __MASK(MSR_HV_LG)   /* Hypervisor state */
> +#define MSR_S__MASK(MSR_S_LG)/* Secure state */
>  #else
>  /* so tests for these bits fail on 32-bit */
>  #define MSR_SF   0
>  #define MSR_ISF  0
>  #define MSR_HV   0
> +#define MSR_S0
>  #endif
>  
>  /*
> -- 
> 2.20.1


Re: [PATCH v3 5/7] kexec_elf: remove elf_addr_to_cpu macro

2019-07-11 Thread Michael Ellerman
Sven Schnelle  writes:
> On Wed, Jul 10, 2019 at 05:09:29PM +0200, Christophe Leroy wrote:
>> Le 10/07/2019 à 16:29, Sven Schnelle a écrit :
>> > It had only one definition, so just use the function directly.
>> 
>> It had only one definition because it was for ppc64 only.
>> But as far as I understand (at least from the name of the new file), you
>> want it to be generic, don't you ? Therefore I get on 32 bits it would be
>> elf32_to_cpu().
>
> That brings up the question whether we need those endianess conversions. I 
> would
> assume that the ELF file has always the same endianess as the running kernel. 
> So
> i think we could just drop them. What do you think?

We should be able to kexec from big to little endian or vice versa, so
they are necessary.

cheers


[PATCH V4 1/2] ASoC: fsl_esai: Wrap some operations to be functions

2019-07-11 Thread shengjiu . wang
From: Shengjiu Wang 

Extract the operation to be functions, to improve the
readability.

In this patch, fsl_esai_hw_init, fsl_esai_register_restore,
fsl_esai_trigger_start and fsl_esai_trigger_stop are
extracted.

Signed-off-by: Shengjiu Wang 
Acked-by: Nicolin Chen 
---
 sound/soc/fsl/fsl_esai.c | 192 ---
 1 file changed, 119 insertions(+), 73 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 10d2210c91ef..ab460d6d7432 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -35,6 +35,7 @@
  * @fifo_depth: depth of tx/rx FIFO
  * @slot_width: width of each DAI slot
  * @slots: number of slots
+ * @channels: channel num for tx or rx
  * @hck_rate: clock rate of desired HCKx clock
  * @sck_rate: clock rate of desired SCKx clock
  * @hck_dir: the direction of HCKx pads
@@ -57,6 +58,7 @@ struct fsl_esai {
u32 slots;
u32 tx_mask;
u32 rx_mask;
+   u32 channels[2];
u32 hck_rate[2];
u32 sck_rate[2];
bool hck_dir[2];
@@ -543,64 +545,132 @@ static int fsl_esai_hw_params(struct snd_pcm_substream 
*substream,
return 0;
 }
 
-static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
-   struct snd_soc_dai *dai)
+static int fsl_esai_hw_init(struct fsl_esai *esai_priv)
 {
-   struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
-   bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
-   u8 i, channels = substream->runtime->channels;
+   struct platform_device *pdev = esai_priv->pdev;
+   int ret;
+
+   /* Reset ESAI unit */
+   ret = regmap_update_bits(esai_priv->regmap, REG_ESAI_ECR,
+ESAI_ECR_ESAIEN_MASK | ESAI_ECR_ERST_MASK,
+ESAI_ECR_ESAIEN | ESAI_ECR_ERST);
+   if (ret) {
+   dev_err(>dev, "failed to reset ESAI: %d\n", ret);
+   return ret;
+   }
+
+   /*
+* We need to enable ESAI so as to access some of its registers.
+* Otherwise, we would fail to dump regmap from user space.
+*/
+   ret = regmap_update_bits(esai_priv->regmap, REG_ESAI_ECR,
+ESAI_ECR_ESAIEN_MASK | ESAI_ECR_ERST_MASK,
+ESAI_ECR_ESAIEN);
+   if (ret) {
+   dev_err(>dev, "failed to enable ESAI: %d\n", ret);
+   return ret;
+   }
+
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_PRRC,
+  ESAI_PRRC_PDC_MASK, 0);
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_PCRC,
+  ESAI_PCRC_PC_MASK, 0);
+
+   return 0;
+}
+
+static int fsl_esai_register_restore(struct fsl_esai *esai_priv)
+{
+   int ret;
+
+   /* FIFO reset for safety */
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_TFCR,
+  ESAI_xFCR_xFR, ESAI_xFCR_xFR);
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_RFCR,
+  ESAI_xFCR_xFR, ESAI_xFCR_xFR);
+
+   regcache_mark_dirty(esai_priv->regmap);
+   ret = regcache_sync(esai_priv->regmap);
+   if (ret)
+   return ret;
+
+   /* FIFO reset done */
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_TFCR, ESAI_xFCR_xFR, 0);
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_RFCR, ESAI_xFCR_xFR, 0);
+
+   return 0;
+}
+
+static void fsl_esai_trigger_start(struct fsl_esai *esai_priv, bool tx)
+{
+   u8 i, channels = esai_priv->channels[tx];
u32 pins = DIV_ROUND_UP(channels, esai_priv->slots);
u32 mask;
 
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx),
+  ESAI_xFCR_xFEN_MASK, ESAI_xFCR_xFEN);
+
+   /* Write initial words reqiured by ESAI as normal procedure */
+   for (i = 0; tx && i < channels; i++)
+   regmap_write(esai_priv->regmap, REG_ESAI_ETDR, 0x0);
+
+   /*
+* When set the TE/RE in the end of enablement flow, there
+* will be channel swap issue for multi data line case.
+* In order to workaround this issue, we switch the bit
+* enablement sequence to below sequence
+* 1) clear the xSMB & xSMA: which is done in probe and
+*   stop state.
+* 2) set TE/RE
+* 3) set xSMB
+* 4) set xSMA:  xSMA is the last one in this flow, which
+*   will trigger esai to start.
+*/
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
+  tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK,
+  tx ? ESAI_xCR_TE(pins) : ESAI_xCR_RE(pins));
+   mask = tx ? esai_priv->tx_mask : esai_priv->rx_mask;
+
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
+  ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(mask));
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
+ 

[PATCH V4 2/2] ASoC: fsl_esai: recover the channel swap after xrun

2019-07-11 Thread shengjiu . wang
From: Shengjiu Wang 

There is chip errata ERR008000, the reference doc is
(https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf),

The issue is "While using ESAI transmit or receive and
an underrun/overrun happens, channel swap may occur.
The only recovery mechanism is to reset the ESAI."

This issue exist in imx3/imx5/imx6(partial) series.

In this commit add a tasklet to handle reset of ESAI
after xrun happens to recover the channel swap.

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/fsl_esai.c | 74 
 1 file changed, 74 insertions(+)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index ab460d6d7432..4ce8ac769244 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -32,6 +32,7 @@
  * @extalclk: esai clock source to derive HCK, SCK and FS
  * @fsysclk: system clock source to derive HCK, SCK and FS
  * @spbaclk: SPBA clock (optional, depending on SoC design)
+ * @task: tasklet to handle the reset operation
  * @fifo_depth: depth of tx/rx FIFO
  * @slot_width: width of each DAI slot
  * @slots: number of slots
@@ -42,6 +43,7 @@
  * @sck_div: if using PSR/PM dividers for SCKx clock
  * @slave_mode: if fully using DAI slave mode
  * @synchronous: if using tx/rx synchronous mode
+ * @reset_at_xrun: flags for enable reset operaton
  * @name: driver name
  */
 struct fsl_esai {
@@ -53,6 +55,7 @@ struct fsl_esai {
struct clk *extalclk;
struct clk *fsysclk;
struct clk *spbaclk;
+   struct tasklet_struct task;
u32 fifo_depth;
u32 slot_width;
u32 slots;
@@ -65,6 +68,7 @@ struct fsl_esai {
bool sck_div[2];
bool slave_mode;
bool synchronous;
+   bool reset_at_xrun;
char name[32];
 };
 
@@ -73,8 +77,16 @@ static irqreturn_t esai_isr(int irq, void *devid)
struct fsl_esai *esai_priv = (struct fsl_esai *)devid;
struct platform_device *pdev = esai_priv->pdev;
u32 esr;
+   u32 saisr;
 
regmap_read(esai_priv->regmap, REG_ESAI_ESR, );
+   regmap_read(esai_priv->regmap, REG_ESAI_SAISR, );
+
+   if ((saisr & (ESAI_SAISR_TUE | ESAI_SAISR_ROE)) &&
+   esai_priv->reset_at_xrun) {
+   dev_dbg(>dev, "reset module for xrun\n");
+   tasklet_schedule(_priv->task);
+   }
 
if (esr & ESAI_ESR_TINIT_MASK)
dev_dbg(>dev, "isr: Transmission Initialized\n");
@@ -635,10 +647,17 @@ static void fsl_esai_trigger_start(struct fsl_esai 
*esai_priv, bool tx)
   ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(mask));
regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
   ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(mask));
+
+   /* Enable Exception interrupt */
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
+  ESAI_xCR_xEIE_MASK, ESAI_xCR_xEIE);
 }
 
 static void fsl_esai_trigger_stop(struct fsl_esai *esai_priv, bool tx)
 {
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
+  ESAI_xCR_xEIE_MASK, 0);
+
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
   tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK, 0);
regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
@@ -653,6 +672,51 @@ static void fsl_esai_trigger_stop(struct fsl_esai 
*esai_priv, bool tx)
   ESAI_xFCR_xFR, 0);
 }
 
+static void fsl_esai_hw_reset(unsigned long arg)
+{
+   struct fsl_esai *esai_priv = (struct fsl_esai *)arg;
+   bool tx = true, rx = false, enabled[2];
+   u32 tfcr, rfcr;
+
+   /* Save the registers */
+   regmap_read(esai_priv->regmap, REG_ESAI_TFCR, );
+   regmap_read(esai_priv->regmap, REG_ESAI_RFCR, );
+   enabled[tx] = tfcr & ESAI_xFCR_xFEN;
+   enabled[rx] = rfcr & ESAI_xFCR_xFEN;
+
+   /* Stop the tx & rx */
+   fsl_esai_trigger_stop(esai_priv, tx);
+   fsl_esai_trigger_stop(esai_priv, rx);
+
+   /* Reset the esai, and ignore return value */
+   fsl_esai_hw_init(esai_priv);
+
+   /* Enforce ESAI personal resets for both TX and RX */
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
+  ESAI_xCR_xPR_MASK, ESAI_xCR_xPR);
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
+  ESAI_xCR_xPR_MASK, ESAI_xCR_xPR);
+
+   /* Restore registers by regcache_sync, and ignore return value */
+   fsl_esai_register_restore(esai_priv);
+
+   /* Remove ESAI personal resets by configuring PCRC and PRRC also */
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
+  ESAI_xCR_xPR_MASK, 0);
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
+  ESAI_xCR_xPR_MASK, 0);
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_PRRC,
+  ESAI_PRRC_PDC_MASK, ESAI_PRRC_PDC(ESAI_GPIO));
+   regmap_update_bits(esai_priv->regmap, 

[PATCH V4 0/2] recover the channel swap after xrun

2019-07-11 Thread shengjiu . wang
From: Shengjiu Wang 

recover the channel swap after xrun

Shengjiu Wang (2):
  ASoC: fsl_esai: Wrap some operations to be functions
  ASoC: fsl_esai: recover the channel swap after xrun

 sound/soc/fsl/fsl_esai.c | 266 ---
 1 file changed, 193 insertions(+), 73 deletions(-)

Changes in v4
-add more comments and remove read saisr

Changes in V3
- update code sytle.

Changes in v2
- add one patch for wrap operations to functions.
- fix some coding style issue

-- 
2.21.0



Re: [PATCH] mm/kprobes: Add generic kprobe_fault_handler() fallback definition

2019-07-11 Thread Anshuman Khandual



On 07/05/2019 11:00 AM, Anshuman Khandual wrote:
> Architectures like parisc enable CONFIG_KROBES without having a definition
> for kprobe_fault_handler() which results in a build failure. Arch needs to
> provide kprobe_fault_handler() as it is platform specific and cannot have
> a generic working alternative. But in the event when platform lacks such a
> definition there needs to be a fallback.
> 
> This adds a stub kprobe_fault_handler() definition which not only prevents
> a build failure but also makes sure that kprobe_page_fault() if called will
> always return negative in absence of a sane platform specific alternative.
> 
> While here wrap kprobe_page_fault() in CONFIG_KPROBES. This enables stud
> definitions for generic kporbe_fault_handler() and kprobes_built_in() can
> just be dropped. Only on x86 it needs to be added back locally as it gets
> used in a !CONFIG_KPROBES function do_general_protection().
> 
> Cc: Vineet Gupta 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Tony Luck 
> Cc: Fenghua Yu 
> Cc: Ralf Baechle 
> Cc: Paul Burton 
> Cc: James Hogan 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Heiko Carstens 
> Cc: Vasily Gorbik 
> Cc: Christian Borntraeger 
> Cc: Yoshinori Sato 
> Cc: Rich Felker 
> Cc: "David S. Miller" 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Borislav Petkov 
> Cc: "H. Peter Anvin" 
> Cc: "Naveen N. Rao" 
> Cc: Anil S Keshavamurthy 
> Cc: Masami Hiramatsu 
> Cc: Allison Randal 
> Cc: Greg Kroah-Hartman 
> Cc: Enrico Weigelt 
> Cc: Richard Fontana 
> Cc: Kate Stewart 
> Cc: Mark Rutland 
> Cc: Andrew Morton 
> Cc: Guenter Roeck 
> Cc: x...@kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-i...@vger.kernel.org
> Cc: linux-m...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: sparcli...@vger.kernel.org
> 
> Signed-off-by: Anshuman Khandual 
> ---

Any updates or suggestions on this patch ? Currently there is a build failure on
parisc architecture due to the lack of a kprobe_fault_handler() definition when
CONFIG_KPROBES is enabled and this build failure needs to be fixed.

This patch solves the build problem. But otherwise I am also happy to just 
define
a stub definition for kprobe_fault_handler() on parisc arch when CONFIG_KPROBES
is enabled, which will avoid the build failure. Please suggest.


Re: [v5 5/6] powerpc/mce: Handle UE event for memcpy_mcsafe

2019-07-11 Thread Nicholas Piggin
Santosh Sivaraj's on July 9, 2019 10:15 pm:
> If we take a UE on one of the instructions with a fixup entry, set nip
> to continue execution at the fixup entry. Stop processing the event
> further or print it.

So... what happens if we take a machine check while we happen to be
executing some other kernel operation with a fixup entry?

Or the other way around, what happens if memcpy_mcsafe takes a page
fault for some reason (e.g., kernel bug it tries to access unmapped
memory).

Thanks,
Nick



Re: [v5 3/6] powerpc/memcpy: Add memcpy_mcsafe for pmem

2019-07-11 Thread Nicholas Piggin
Santosh Sivaraj's on July 9, 2019 10:15 pm:
> From: Balbir Singh 
> 
> The pmem infrastructure uses memcpy_mcsafe in the pmem layer so as to
> convert machine check exceptions into a return value on failure in case
> a machine check exception is encountered during the memcpy. The return
> value is the number of bytes remaining to be copied.
> 
> This patch largely borrows from the copyuser_power7 logic and does not add
> the VMX optimizations, largely to keep the patch simple. If needed those
> optimizations can be folded in.

Shouldn't this patch go after the exception table stuff now if you
squashed them together?

Thanks,
Nick


Re: [v5 4/6] extable: Add function to search only kernel exception table

2019-07-11 Thread Nicholas Piggin
Santosh Sivaraj's on July 9, 2019 10:15 pm:
> In real mode, the search_exception tables cannot be called because
> it also searches the module exception tables if entry is not found
> in the kernel exception tables.

This is a patch for generic kernel code, it may not go through
powerpc tree and someone doing git blame or something won't have
any idea what this changelog means.

Can you re-word this and just say something like, "certain architecture
$specific operating modes (e.g., in powerpc machine check handler that
is unable to access vmalloc memory)."

> 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Nicholas Piggin 
> Signed-off-by: Santosh Sivaraj 
> ---
>  include/linux/extable.h |  2 ++
>  kernel/extable.c| 16 +---
>  2 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/extable.h b/include/linux/extable.h
> index 41c5b3a25f67..0c2819ba67f0 100644
> --- a/include/linux/extable.h
> +++ b/include/linux/extable.h
> @@ -19,6 +19,8 @@ void trim_init_extable(struct module *m);
>  
>  /* Given an address, look for it in the exception tables */
>  const struct exception_table_entry *search_exception_tables(unsigned long 
> add);
> +const struct
> +exception_table_entry *search_kernel_exception_table(unsigned long addr);
>  
>  #ifdef CONFIG_MODULES
>  /* For extable.c to search modules' exception tables. */
> diff --git a/kernel/extable.c b/kernel/extable.c
> index e23cce6e6092..6d544cb79fff 100644
> --- a/kernel/extable.c
> +++ b/kernel/extable.c
> @@ -40,13 +40,23 @@ void __init sort_main_extable(void)
>   }
>  }
>  
> -/* Given an address, look for it in the exception tables. */
> +/* For the given address, look for it in the kernel exception table */

Nitpick, no reason to vary the structure of the comment.

Code wise it looks fine, so with the comments and changelog fixed,

Reviewed-by: Nicholas Piggin 

> +const
> +struct exception_table_entry *search_kernel_exception_table(unsigned long 
> addr)
> +{
> + return search_extable(__start___ex_table,
> +   __stop___ex_table - __start___ex_table, addr);
> +}
> +
> +/*
> + * Given an address, look for it in the kernel and the module exception
> + * tables.
> + */
>  const struct exception_table_entry *search_exception_tables(unsigned long 
> addr)
>  {
>   const struct exception_table_entry *e;
>  
> - e = search_extable(__start___ex_table,
> -__stop___ex_table - __start___ex_table, addr);
> + e = search_kernel_exception_table(addr);
>   if (!e)
>   e = search_module_extables(addr);
>   return e;
> -- 
> 2.20.1
> 
> 


Re: [v5 2/6] powerpc/mce: Fix MCE handling for huge pages

2019-07-11 Thread Nicholas Piggin
Santosh Sivaraj's on July 9, 2019 10:15 pm:
> From: Balbir Singh 
> 
> The current code would fail on huge pages addresses, since the shift
> would be incorrect. Use the correct page shift value returned by
> __find_linux_pte() to get the correct pfn. The code is more generic
> and can handle both regular and compound pages.
> 
> Fixes: ba41e1e1ccb9 ("powerpc/mce: Hookup derror (load/store) UE errors")
> 
> Signed-off-by: Balbir Singh 
> [ar...@linux.ibm.com: Fixup pseries_do_memory_failure()]
> Signed-off-by: Reza Arbab 
> Signed-off-by: Santosh Sivaraj 
> ---
>  arch/powerpc/include/asm/mce.h   |  3 ++-
>  arch/powerpc/kernel/mce_power.c  | 26 --
>  arch/powerpc/platforms/pseries/ras.c |  6 --
>  3 files changed, 22 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
> index a4c6a74ad2fb..94888a7025b3 100644
> --- a/arch/powerpc/include/asm/mce.h
> +++ b/arch/powerpc/include/asm/mce.h
> @@ -209,7 +209,8 @@ extern void release_mce_event(void);
>  extern void machine_check_queue_event(void);
>  extern void machine_check_print_event_info(struct machine_check_event *evt,
>  bool user_mode, bool in_guest);
> -unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr);
> +unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr,
> +   unsigned int *shift);
>  #ifdef CONFIG_PPC_BOOK3S_64
>  void flush_and_reload_slb(void);
>  #endif /* CONFIG_PPC_BOOK3S_64 */
> diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
> index e39536aad30d..04666c0b40a8 100644
> --- a/arch/powerpc/kernel/mce_power.c
> +++ b/arch/powerpc/kernel/mce_power.c
> @@ -23,7 +23,8 @@
>   * Convert an address related to an mm to a PFN. NOTE: we are in real
>   * mode, we could potentially race with page table updates.
>   */
> -unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
> +unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr,
> +   unsigned int *shift)
>  {
>   pte_t *ptep;
>   unsigned long flags;
> @@ -36,13 +37,15 @@ unsigned long addr_to_pfn(struct pt_regs *regs, unsigned 
> long addr)
>  
>   local_irq_save(flags);
>   if (mm == current->mm)
> - ptep = find_current_mm_pte(mm->pgd, addr, NULL, NULL);
> + ptep = find_current_mm_pte(mm->pgd, addr, NULL, shift);
>   else
> - ptep = find_init_mm_pte(addr, NULL);
> + ptep = find_init_mm_pte(addr, shift);
>   local_irq_restore(flags);
>   if (!ptep || pte_special(*ptep))
>   return ULONG_MAX;
> - return pte_pfn(*ptep);
> + if (!*shift)
> + *shift = PAGE_SHIFT;
> + return (pte_val(*ptep) & PTE_RPN_MASK) >> *shift;
>  }
>  
>  /* flush SLBs and reload */

Ah, the comment I made earlier to this patch I think missed some detail.

But what we should do here is return the pfn (which is always units
of PAGE_SIZE). So you have to adjust by the lower part of the address
here, rather than returning shift which is unnecessary.

Possibly even better is to just return the real address, which is
what all callers seem to want anyway.

> @@ -358,15 +361,16 @@ static int mce_find_instr_ea_and_pfn(struct pt_regs 
> *regs, uint64_t *addr,
>   unsigned long pfn, instr_addr;
>   struct instruction_op op;
>   struct pt_regs tmp = *regs;
> + unsigned int shift;
>  
> - pfn = addr_to_pfn(regs, regs->nip);
> + pfn = addr_to_pfn(regs, regs->nip, );
>   if (pfn != ULONG_MAX) {
> - instr_addr = (pfn << PAGE_SHIFT) + (regs->nip & ~PAGE_MASK);
> + instr_addr = (pfn << shift) + (regs->nip & ((1 << shift) - 1));

This wants the exact real address.

>   instr = *(unsigned int *)(instr_addr);
>   if (!analyse_instr(, , instr)) {
> - pfn = addr_to_pfn(regs, op.ea);
> + pfn = addr_to_pfn(regs, op.ea, );
>   *addr = op.ea;
> - *phys_addr = (pfn << PAGE_SHIFT);
> + *phys_addr = (pfn << shift);
>   return 0;
>   }

I'm not sure this is really what we want. You do really want the
PAGE_SIZE pfn here. Say you have a failure in the nth small page
of a large page mapping, this gives the physical address of the
start of the large page, so memory failure will fail out the 0th
small page won't it?

>   /*
> @@ -442,12 +446,14 @@ static int mce_handle_ierror(struct pt_regs *regs,
>   if (mce_err->sync_error &&
>   table[i].error_type == MCE_ERROR_TYPE_UE) {
>   unsigned long pfn;
> + unsigned int shift;
>  
>   if (get_paca()->in_mce < MAX_MCE_DEPTH) {
> - pfn = addr_to_pfn(regs, regs->nip);
> + 

Re: Coccinelle: Checking of_node_put() calls with SmPL

2019-07-11 Thread Markus Elfring
> In my experience, when you start looking at these of_node_put things,
> all sorts of strange things appear...

How much will this situation influence the achievement of further improvements
also for your software?

Regards,
Markus


Re: Coccinelle: Checking of_node_put() calls with SmPL

2019-07-11 Thread Markus Elfring
> 180 break; --->  Jump out of 
> the loop without releasing it

The device node reference is released behind this for loop.


> 183 if (!of_device_is_available(state_node)) {
> 184 of_node_put(state_node);

This function call was added by the commit “cpuidle: dt: Add missing 
'of_node_put()'”
on 2017-06-12.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/cpuidle/dt_idle_states.c?id=b2cdd8e1b54849477a32d820acc2e87828a38f3d


> 185 continue;--->  Release the 
> object references within a loop

I became curious on the applicability of an other coding style
(for a software refactoring) at this place.
How do you think about to achieve the same effect by using a goto statement
instead of two statements in such an if branch?


> 208 of_node_put(state_node);  -->  Release the object 
> references within a loop
> 209 }
> 210
> 211 of_node_put(state_node);   -->There may be double free 
> here.

This information points a recurring challenge out for safe source code analysis.
How would you like to exclude the detection of false positives finally?


> This code pattern is very interesting

Thanks that you think also in this direction.


> and the coccinelle software should also recognize this pattern.

There are some open issues to consider for available analysis tools.
How will corresponding details be clarified then?

Regards,
Markus


Re: [PATCH] powerpc/eeh: Handle hugepages in ioremap space

2019-07-11 Thread Sachin Sant


> On 10-Jul-2019, at 8:35 PM, Oliver O'Halloran  wrote:
> 
> In commit 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap
> space") support for using hugepages in the vmalloc and ioremap areas was
> enabled for radix. Unfortunately this broke EEH MMIO error checking.
> 
> Detection works by inserting a hook which checks the results of the
> ioreadXX() set of functions.  When a read returns a 0xFFs response we
> need to check for an error which we do by mapping the (virtual) MMIO
> address back to a physical address, then mapping physical address to a
> PCI device via an interval tree.
> 
> When translating virt -> phys we currently assume the ioremap space is
> only populated by PAGE_SIZE mappings. If a hugepage mapping is found we
> emit a WARN_ON(), but otherwise handles the check as though a normal
> page was found. In pathalogical cases such as copying a buffer
> containing a lot of 0xFFs from BAR memory this can result in the system
> not booting because it's too busy printing WARN_ON()s.
> 
> There's no real reason to assume huge pages can't be present and we're
> prefectly capable of handling them, so do that.
> 
> Cc: Nicholas Piggin 
> Fixes: 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap space")
> Reported-by: Sachin Sant 
> Signed-off-by: Oliver O'Halloran 

Tested-by: Sachin Sant 

Thanks
-Sachin



Re: Coccinelle: Checking of_node_put() calls with SmPL

2019-07-11 Thread Julia Lawall


On Thu, 11 Jul 2019, wen.yan...@zte.com.cn wrote:

> > > we developed a coccinelle script to detect such problems.
> >
> > Would you find the implementation of the function “dt_init_idle_driver”
> > suspicious according to discussed source code search patterns?
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpuidle/dt_idle_states.c?id=e9a83bd2322035ed9d7dcf35753d3f984d76c6a5#n208
> > https://elixir.bootlin.com/linux/v5.2/source/drivers/cpuidle/dt_idle_states.c#L208
> >
> >
> > > This script is still being improved.
> >
> > Will corresponding software development challenges become more interesting?
>
> Hello Markus,
> This is the simplified code pattern for it:
>
> 172 for (i = 0; ; i++) {
> 173 state_node = of_parse_phandle(...); ---> Obtain here
> ...
> 177 match_id = of_match_node(matches, state_node);
> 178 if (!match_id) {
> 179 err = -ENODEV;
> 180 break; --->  Jump out of 
> the loop without releasing it
> 181 }
> 182
> 183 if (!of_device_is_available(state_node)) {
> 184 of_node_put(state_node);
> 185 continue;--->  Release the 
> object references within a loop
> 186 }
> ...
> 208 of_node_put(state_node);  -->  Release the object 
> references within a loop
> 209 }
> 210
> 211 of_node_put(state_node);   -->There may be double free 
> here.
>
> This code pattern is very interesting and the coccinelle software should also 
> recognize this pattern.

In my experience, when you start looking at these of_node_put things, all
sorts of strange things appear...

julia

Re: Coccinelle: Checking of_node_put() calls with SmPL

2019-07-11 Thread wen.yang99
> > we developed a coccinelle script to detect such problems.
> 
> Would you find the implementation of the function “dt_init_idle_driver”
> suspicious according to discussed source code search patterns?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpuidle/dt_idle_states.c?id=e9a83bd2322035ed9d7dcf35753d3f984d76c6a5#n208
> https://elixir.bootlin.com/linux/v5.2/source/drivers/cpuidle/dt_idle_states.c#L208
> 
> 
> > This script is still being improved.
> 
> Will corresponding software development challenges become more interesting?

Hello Markus,
This is the simplified code pattern for it:

172 for (i = 0; ; i++) {
173 state_node = of_parse_phandle(...); ---> Obtain here
...
177 match_id = of_match_node(matches, state_node);
178 if (!match_id) {
179 err = -ENODEV;  
180 break; --->  Jump out of 
the loop without releasing it
181 }
182 
183 if (!of_device_is_available(state_node)) {
184 of_node_put(state_node);
185 continue;--->  Release the 
object references within a loop
186 }
...
208 of_node_put(state_node);  -->  Release the object 
references within a loop
209 }
210 
211 of_node_put(state_node);   -->There may be double free here.

This code pattern is very interesting and the coccinelle software should also 
recognize this pattern.

Regards,
Wen

Re: [PATCH V3 2/2] ASoC: fsl_esai: recover the channel swap after xrun

2019-07-11 Thread S.j. Wang


> 
> Hi Shengjiu,
> 
> Mostly looks good to me, just some small comments.
> 
> On Mon, Jul 08, 2019 at 02:38:52PM +0800, shengjiu.w...@nxp.com wrote:
> 
> > +static void fsl_esai_hw_reset(unsigned long arg) {
> > + struct fsl_esai *esai_priv = (struct fsl_esai *)arg;
> > + u32 saisr, tfcr, rfcr;
> > + bool tx = true, rx = false, enabled[2];
> 
> Could we swap the lines of u32 and bool? It'd look better.
> 
> > + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> > +ESAI_xCR_xPR_MASK, ESAI_xCR_xPR);
> > + regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
> > +ESAI_xCR_xPR_MASK, ESAI_xCR_xPR);
> 
> Let's add a line of comments for these two:
> /* Enforce ESAI personal resets for both TX and RX */
> 
> > + /*
> > +  * Restore registers by regcache_sync, and ignore
> > +  * return value
> > +  */
> 
> Could fit into single-line?
> 
> > + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> > +ESAI_xCR_xPR_MASK, 0);
> > + regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
> > +ESAI_xCR_xPR_MASK, 0);
> > +
> > + regmap_update_bits(esai_priv->regmap, REG_ESAI_PRRC,
> > +ESAI_PRRC_PDC_MASK, ESAI_PRRC_PDC(ESAI_GPIO));
> > + regmap_update_bits(esai_priv->regmap, REG_ESAI_PCRC,
> > +ESAI_PCRC_PC_MASK, ESAI_PCRC_PC(ESAI_GPIO));
> 
> Could remove the blank line and add a line of comments:
> /* Remove ESAI personal resets by configuring PCRC and PRRC also */
> 
> Btw, I still feel this personal reset can be stuffed into one of the wrapper
> functions. But let's keep this simple for now.
> 
> > + regmap_read(esai_priv->regmap, REG_ESAI_SAISR, );
> 
> Why do we read saisr here? All its bits would get cleared by the hardware
> reset. If it's a must to clear again, we should add a line of comments to
> emphasize it.

This line can be removed. 

Best regards
Wang Shengjiu