[PATCH REBASE v4 01/14] mm, fs: Move randomize_stack_top from fs to mm

[Alexandre Ghiti]

This preparatory commit moves this function so that further introduction
of generic topdown mmap layout is contained only in mm/util.c.

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Christoph Hellwig 
Acked-by: Kees Cook 
---
 fs/binfmt_elf.c| 20 
 include/linux/mm.h |  2 ++
 mm/util.c  | 22 ++
 3 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d4e11b2e04f6..cec3b4146440 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -670,26 +670,6 @@ static unsigned long load_elf_interp(struct elfhdr 
*interp_elf_ex,
  * libraries.  There is no binary dependent code anywhere else.
  */
 
-#ifndef STACK_RND_MASK
-#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))/* 8MB of VA */
-#endif
-
-static unsigned long randomize_stack_top(unsigned long stack_top)
-{
-   unsigned long random_variable = 0;
-
-   if (current->flags & PF_RANDOMIZE) {
-   random_variable = get_random_long();
-   random_variable &= STACK_RND_MASK;
-   random_variable <<= PAGE_SHIFT;
-   }
-#ifdef CONFIG_STACK_GROWSUP
-   return PAGE_ALIGN(stack_top) + random_variable;
-#else
-   return PAGE_ALIGN(stack_top) - random_variable;
-#endif
-}
-
 static int load_elf_binary(struct linux_binprm *bprm)
 {
struct file *interpreter = NULL; /* to shut gcc up */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0334ca97c584..ae0e5d241eb8 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2351,6 +2351,8 @@ extern int install_special_mapping(struct mm_struct *mm,
   unsigned long addr, unsigned long len,
   unsigned long flags, struct page **pages);
 
+unsigned long randomize_stack_top(unsigned long stack_top);
+
 extern unsigned long get_unmapped_area(struct file *, unsigned long, unsigned 
long, unsigned long, unsigned long);
 
 extern unsigned long mmap_region(struct file *file, unsigned long addr,
diff --git a/mm/util.c b/mm/util.c
index e6351a80f248..15a4fb0f5473 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -293,6 +295,26 @@ int vma_is_stack_for_current(struct vm_area_struct *vma)
return (vma->vm_start <= KSTK_ESP(t) && vma->vm_end >= KSTK_ESP(t));
 }
 
+#ifndef STACK_RND_MASK
+#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12)) /* 8MB of VA */
+#endif
+
+unsigned long randomize_stack_top(unsigned long stack_top)
+{
+   unsigned long random_variable = 0;
+
+   if (current->flags & PF_RANDOMIZE) {
+   random_variable = get_random_long();
+   random_variable &= STACK_RND_MASK;
+   random_variable <<= PAGE_SHIFT;
+   }
+#ifdef CONFIG_STACK_GROWSUP
+   return PAGE_ALIGN(stack_top) + random_variable;
+#else
+   return PAGE_ALIGN(stack_top) - random_variable;
+#endif
+}
+
 #if defined(CONFIG_MMU) && !defined(HAVE_ARCH_PICK_MMAP_LAYOUT)
 void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
 {
-- 
2.20.1

[PATCH] ASoC: cs4271: Fix a typo in the CS4171_NR_RATIOS

[Christophe JAILLET]

This should be CS4271_NR_RATIOS.
Fix it and use it.

Signed-off-by: Christophe JAILLET 
---
 sound/soc/codecs/cs4271.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c
index 1d03a1348162..04b86a51e055 100644
--- a/sound/soc/codecs/cs4271.c
+++ b/sound/soc/codecs/cs4271.c
@@ -334,7 +334,7 @@ static struct cs4271_clk_cfg cs4271_clk_tab[] = {
{0, CS4271_MODE1_MODE_4X, 256,  CS4271_MODE1_DIV_2},
 };
 
-#define CS4171_NR_RATIOS ARRAY_SIZE(cs4271_clk_tab)
+#define CS4271_NR_RATIOS ARRAY_SIZE(cs4271_clk_tab)
 
 static int cs4271_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
@@ -383,13 +383,13 @@ static int cs4271_hw_params(struct snd_pcm_substream 
*substream,
val = CS4271_MODE1_MODE_4X;
 
ratio = cs4271->mclk / cs4271->rate;
-   for (i = 0; i < CS4171_NR_RATIOS; i++)
+   for (i = 0; i < CS4271_NR_RATIOS; i++)
if ((cs4271_clk_tab[i].master == cs4271->master) &&
(cs4271_clk_tab[i].speed_mode == val) &&
(cs4271_clk_tab[i].ratio == ratio))
break;
 
-   if (i == CS4171_NR_RATIOS) {
+   if (i == CS4271_NR_RATIOS) {
dev_err(component->dev, "Invalid sample rate\n");
return -EINVAL;
}
-- 
2.20.1

[PATCH REBASE v4 02/14] arm64: Make use of is_compat_task instead of hardcoding this test

[Alexandre Ghiti]

Each architecture has its own way to determine if a task is a compat task,
by using is_compat_task in arch_mmap_rnd, it allows more genericity and
then it prepares its moving to mm/.

Signed-off-by: Alexandre Ghiti 
Acked-by: Catalin Marinas 
Acked-by: Kees Cook 
Reviewed-by: Christoph Hellwig 
---
 arch/arm64/mm/mmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index b050641b5139..bb0140afed66 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -43,7 +43,7 @@ unsigned long arch_mmap_rnd(void)
unsigned long rnd;
 
 #ifdef CONFIG_COMPAT
-   if (test_thread_flag(TIF_32BIT))
+   if (is_compat_task())
rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
else
 #endif
-- 
2.20.1

[PATCH REBASE v4 03/14] arm64: Consider stack randomization for mmap base only when necessary

[Alexandre Ghiti]

Do not offset mmap base address because of stack randomization if
current task does not want randomization.
Note that x86 already implements this behaviour.

Signed-off-by: Alexandre Ghiti 
Acked-by: Catalin Marinas 
Acked-by: Kees Cook 
Reviewed-by: Christoph Hellwig 
---
 arch/arm64/mm/mmap.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index bb0140afed66..e4acaead67de 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -54,7 +54,11 @@ unsigned long arch_mmap_rnd(void)
 static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
 {
unsigned long gap = rlim_stack->rlim_cur;
-   unsigned long pad = (STACK_RND_MASK << PAGE_SHIFT) + stack_guard_gap;
+   unsigned long pad = stack_guard_gap;
+
+   /* Account for stack randomization if necessary */
+   if (current->flags & PF_RANDOMIZE)
+   pad += (STACK_RND_MASK << PAGE_SHIFT);
 
/* Values close to RLIM_INFINITY can overflow. */
if (gap + pad > gap)
-- 
2.20.1

[PATCH REBASE v4 04/14] arm64, mm: Move generic mmap layout functions to mm

[Alexandre Ghiti]

arm64 handles top-down mmap layout in a way that can be easily reused
by other architectures, so make it available in mm.
It then introduces a new config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
that can be set by other architectures to benefit from those functions.
Note that this new config depends on MMU being enabled, if selected
without MMU support, a warning will be thrown.

Suggested-by: Christoph Hellwig 
Signed-off-by: Alexandre Ghiti 
Acked-by: Catalin Marinas 
Acked-by: Kees Cook 
Reviewed-by: Christoph Hellwig 
---
 arch/Kconfig   | 10 
 arch/arm64/Kconfig |  1 +
 arch/arm64/include/asm/processor.h |  2 -
 arch/arm64/mm/mmap.c   | 76 -
 kernel/sysctl.c|  6 ++-
 mm/util.c  | 78 +-
 6 files changed, 92 insertions(+), 81 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index a7b57dd42c26..a0bb6fa4d381 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -696,6 +696,16 @@ config HAVE_ARCH_COMPAT_MMAP_BASES
  and vice-versa 32-bit applications to call 64-bit mmap().
  Required for applications doing different bitness syscalls.
 
+# This allows to use a set of generic functions to determine mmap base
+# address by giving priority to top-down scheme only if the process
+# is not in legacy mode (compat task, unlimited stack size or
+# sysctl_legacy_va_layout).
+# Architecture that selects this option can provide its own version of:
+# - STACK_RND_MASK
+config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
+   bool
+   depends on MMU
+
 config HAVE_COPY_THREAD_TLS
bool
help
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..14a194e63458 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -72,6 +72,7 @@ config ARM64
select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 5 || CC_IS_CLANG
select ARCH_SUPPORTS_NUMA_BALANCING
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION if COMPAT
+   select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
select ARCH_WANT_FRAME_POINTERS
select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES 
&& !ARM64_VA_BITS_36)
select ARCH_HAS_UBSAN_SANITIZE_ALL
diff --git a/arch/arm64/include/asm/processor.h 
b/arch/arm64/include/asm/processor.h
index fd5b1a4efc70..7b8d448363f7 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -271,8 +271,6 @@ static inline void spin_lock_prefetch(const void *ptr)
 "nop") : : "p" (ptr));
 }
 
-#define HAVE_ARCH_PICK_MMAP_LAYOUT
-
 #endif
 
 extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index e4acaead67de..3028bacbc4e9 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -20,82 +20,6 @@
 
 #include 
 
-/*
- * Leave enough space between the mmap area and the stack to honour ulimit in
- * the face of randomisation.
- */
-#define MIN_GAP (SZ_128M)
-#define MAX_GAP(STACK_TOP/6*5)
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
-   if (current->personality & ADDR_COMPAT_LAYOUT)
-   return 1;
-
-   if (rlim_stack->rlim_cur == RLIM_INFINITY)
-   return 1;
-
-   return sysctl_legacy_va_layout;
-}
-
-unsigned long arch_mmap_rnd(void)
-{
-   unsigned long rnd;
-
-#ifdef CONFIG_COMPAT
-   if (is_compat_task())
-   rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
-   else
-#endif
-   rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-   return rnd << PAGE_SHIFT;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
-   unsigned long gap = rlim_stack->rlim_cur;
-   unsigned long pad = stack_guard_gap;
-
-   /* Account for stack randomization if necessary */
-   if (current->flags & PF_RANDOMIZE)
-   pad += (STACK_RND_MASK << PAGE_SHIFT);
-
-   /* Values close to RLIM_INFINITY can overflow. */
-   if (gap + pad > gap)
-   gap += pad;
-
-   if (gap < MIN_GAP)
-   gap = MIN_GAP;
-   else if (gap > MAX_GAP)
-   gap = MAX_GAP;
-
-   return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
-/*
- * This function, called very early during the creation of a new process VM
- * image, sets up which VM layout function to use:
- */
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
-   unsigned long random_factor = 0UL;
-
-   if (current->flags & PF_RANDOMIZE)
-   random_factor = arch_mmap_rnd();
-
-   /*
-* Fall back to the standard layout if the personality bit is set, or
-* if the expected stack growth is unlimited:
-*/
-   if (mmap_is_legacy(rlim_stack)) {
-   mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
-   mm->get_unmapped_area = 

[PATCH REBASE v4 05/14] arm64, mm: Make randomization selected by generic topdown mmap layout

[Alexandre Ghiti]

This commits selects ARCH_HAS_ELF_RANDOMIZE when an arch uses the generic
topdown mmap layout functions so that this security feature is on by
default.
Note that this commit also removes the possibility for arm64 to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.

Signed-off-by: Alexandre Ghiti 
Acked-by: Catalin Marinas 
Acked-by: Kees Cook 
Reviewed-by: Christoph Hellwig 
---
 arch/Kconfig|  1 +
 arch/arm64/Kconfig  |  1 -
 arch/arm64/kernel/process.c |  8 
 mm/util.c   | 11 +--
 4 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index a0bb6fa4d381..d4c1f0551dfe 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -705,6 +705,7 @@ config HAVE_ARCH_COMPAT_MMAP_BASES
 config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
bool
depends on MMU
+   select ARCH_HAS_ELF_RANDOMIZE
 
 config HAVE_COPY_THREAD_TLS
bool
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 14a194e63458..399f595ef852 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -16,7 +16,6 @@ config ARM64
select ARCH_HAS_DMA_MMAP_PGPROT
select ARCH_HAS_DMA_PREP_COHERENT
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-   select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6a869d9f304f..3f59d0d1632e 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -524,14 +524,6 @@ unsigned long arch_align_stack(unsigned long sp)
return sp & ~0xf;
 }
 
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
-   if (is_compat_task())
-   return randomize_page(mm->brk, SZ_32M);
-   else
-   return randomize_page(mm->brk, SZ_1G);
-}
-
 /*
  * Called from setup_new_exec() after (COMPAT_)SET_PERSONALITY.
  */
diff --git a/mm/util.c b/mm/util.c
index 0781e5575cb3..16f1e56e2996 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -321,7 +321,15 @@ unsigned long randomize_stack_top(unsigned long stack_top)
 }
 
 #ifdef CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
-#ifdef CONFIG_ARCH_HAS_ELF_RANDOMIZE
+unsigned long arch_randomize_brk(struct mm_struct *mm)
+{
+   /* Is the current task 32bit ? */
+   if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task())
+   return randomize_page(mm->brk, SZ_32M);
+
+   return randomize_page(mm->brk, SZ_1G);
+}
+
 unsigned long arch_mmap_rnd(void)
 {
unsigned long rnd;
@@ -335,7 +343,6 @@ unsigned long arch_mmap_rnd(void)
 
return rnd << PAGE_SHIFT;
 }
-#endif /* CONFIG_ARCH_HAS_ELF_RANDOMIZE */
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
 {
-- 
2.20.1

[PATCH net-next v2 0/8] Use dev_get_drvdata where possible

[Chuhong Yuan]

These patches use dev_get_drvdata instead of
using to_pci_dev + pci_get_drvdata to make
code simpler where possible.

Changelog:

v1 -> v2:
- Change pci_set_drvdata to dev_set_drvdata
  to keep consistency.

Chuhong Yuan (8):
  net: 3com: 3c59x: Use dev_get_drvdata
  net: atheros: Use dev_get_drvdata
  net: broadcom: Use dev_get_drvdata
  e1000e: Use dev_get_drvdata where possible
  fm10k: Use dev_get_drvdata
  i40e: Use dev_get_drvdata
  igb: Use dev_get_drvdata where possible
  net: jme: Use dev_get_drvdata

 drivers/net/ethernet/3com/3c59x.c   |  8 +++-
 drivers/net/ethernet/atheros/alx/main.c |  8 +++-
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 10 --
 drivers/net/ethernet/atheros/atlx/atl1.c|  8 +++-
 drivers/net/ethernet/broadcom/bnx2.c|  8 +++-
 drivers/net/ethernet/broadcom/bnxt/bnxt.c   |  8 +++-
 drivers/net/ethernet/broadcom/tg3.c |  8 +++-
 drivers/net/ethernet/intel/e1000e/netdev.c  |  9 -
 drivers/net/ethernet/intel/fm10k/fm10k_pci.c|  6 +++---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 10 --
 drivers/net/ethernet/intel/igb/igb_main.c   |  5 ++---
 drivers/net/ethernet/jme.c  |  8 +++-
 12 files changed, 38 insertions(+), 58 deletions(-)

-- 
2.20.1

[PATCH net-next v2 3/8] net: broadcom: Use dev_get_drvdata

[Chuhong Yuan]

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Change pci_set_drvdata to dev_set_drvdata
to keep consistency.

 drivers/net/ethernet/broadcom/bnx2.c  | 8 +++-
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 +++-
 drivers/net/ethernet/broadcom/tg3.c   | 8 +++-
 3 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2.c 
b/drivers/net/ethernet/broadcom/bnx2.c
index dfdd14eadd57..da538a7bac14 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -8586,7 +8586,7 @@ bnx2_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
bp = netdev_priv(dev);
 
-   pci_set_drvdata(pdev, dev);
+   dev_set_drvdata(>dev, dev);
 
/*
 * In-flight DMA from 1st kernel could continue going in kdump kernel.
@@ -8673,8 +8673,7 @@ bnx2_remove_one(struct pci_dev *pdev)
 static int
 bnx2_suspend(struct device *device)
 {
-   struct pci_dev *pdev = to_pci_dev(device);
-   struct net_device *dev = pci_get_drvdata(pdev);
+   struct net_device *dev = dev_get_drvdata(device);
struct bnx2 *bp = netdev_priv(dev);
 
if (netif_running(dev)) {
@@ -8693,8 +8692,7 @@ bnx2_suspend(struct device *device)
 static int
 bnx2_resume(struct device *device)
 {
-   struct pci_dev *pdev = to_pci_dev(device);
-   struct net_device *dev = pci_get_drvdata(pdev);
+   struct net_device *dev = dev_get_drvdata(device);
struct bnx2 *bp = netdev_priv(dev);
 
if (!netif_running(dev))
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 7134d2c3eb1c..956015acd97f 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -10662,7 +10662,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
dev->netdev_ops = _netdev_ops;
dev->watchdog_timeo = BNXT_TX_TIMEOUT;
dev->ethtool_ops = _ethtool_ops;
-   pci_set_drvdata(pdev, dev);
+   dev_set_drvdata(>dev, dev);
 
rc = bnxt_alloc_hwrm_resources(bp);
if (rc)
@@ -10920,8 +10920,7 @@ static void bnxt_shutdown(struct pci_dev *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int bnxt_suspend(struct device *device)
 {
-   struct pci_dev *pdev = to_pci_dev(device);
-   struct net_device *dev = pci_get_drvdata(pdev);
+   struct net_device *dev = dev_get_drvdata(device);
struct bnxt *bp = netdev_priv(dev);
int rc = 0;
 
@@ -10937,8 +10936,7 @@ static int bnxt_suspend(struct device *device)
 
 static int bnxt_resume(struct device *device)
 {
-   struct pci_dev *pdev = to_pci_dev(device);
-   struct net_device *dev = pci_get_drvdata(pdev);
+   struct net_device *dev = dev_get_drvdata(device);
struct bnxt *bp = netdev_priv(dev);
int rc = 0;
 
diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 4c404d2213f9..282031dc89b3 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -17918,7 +17918,7 @@ static int tg3_init_one(struct pci_dev *pdev,
 
tg3_init_coal(tp);
 
-   pci_set_drvdata(pdev, dev);
+   dev_set_drvdata(>dev, dev);
 
if (tg3_asic_rev(tp) == ASIC_REV_5719 ||
tg3_asic_rev(tp) == ASIC_REV_5720 ||
@@ -18041,8 +18041,7 @@ static void tg3_remove_one(struct pci_dev *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int tg3_suspend(struct device *device)
 {
-   struct pci_dev *pdev = to_pci_dev(device);
-   struct net_device *dev = pci_get_drvdata(pdev);
+   struct net_device *dev = dev_get_drvdata(device);
struct tg3 *tp = netdev_priv(dev);
int err = 0;
 
@@ -18098,8 +18097,7 @@ static int tg3_suspend(struct device *device)
 
 static int tg3_resume(struct device *device)
 {
-   struct pci_dev *pdev = to_pci_dev(device);
-   struct net_device *dev = pci_get_drvdata(pdev);
+   struct net_device *dev = dev_get_drvdata(device);
struct tg3 *tp = netdev_priv(dev);
int err = 0;
 
-- 
2.20.1

[PATCH net-next v2 1/8] net: 3com: 3c59x: Use dev_get_drvdata

[Chuhong Yuan]

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Change pci_set_drvdata to dev_set_drvdata
to keep consistency.

 drivers/net/ethernet/3com/3c59x.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/3com/3c59x.c 
b/drivers/net/ethernet/3com/3c59x.c
index 147051404194..a0960c05833d 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -847,8 +847,7 @@ static void poll_vortex(struct net_device *dev)
 
 static int vortex_suspend(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *ndev = pci_get_drvdata(pdev);
+   struct net_device *ndev = dev_get_drvdata(dev);
 
if (!ndev || !netif_running(ndev))
return 0;
@@ -861,8 +860,7 @@ static int vortex_suspend(struct device *dev)
 
 static int vortex_resume(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *ndev = pci_get_drvdata(pdev);
+   struct net_device *ndev = dev_get_drvdata(dev);
int err;
 
if (!ndev || !netif_running(ndev))
@@ -1222,7 +1220,7 @@ static int vortex_probe1(struct device *gendev, void 
__iomem *ioaddr, int irq,
/* if we are a PCI driver, we store info in pdev->driver_data
 * instead of a module list */
if (pdev)
-   pci_set_drvdata(pdev, dev);
+   dev_set_drvdata(>dev, dev);
if (edev)
eisa_set_drvdata(edev, dev);
 
-- 
2.20.1

[PATCH net-next v2 2/8] net: atheros: Use dev_get_drvdata

[Chuhong Yuan]

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Change pci_set_drvdata to dev_set_drvdata
to keep consistency.

 drivers/net/ethernet/atheros/alx/main.c |  8 +++-
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 10 --
 drivers/net/ethernet/atheros/atlx/atl1.c|  8 +++-
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index e3538ba7d0e7..73a20b106892 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1749,7 +1749,7 @@ static int alx_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
alx->msg_enable = NETIF_MSG_LINK | NETIF_MSG_HW | NETIF_MSG_IFUP |
  NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR | NETIF_MSG_WOL;
hw = >hw;
-   pci_set_drvdata(pdev, alx);
+   dev_set_drvdata(>dev, alx);
 
hw->hw_addr = pci_ioremap_bar(pdev, 0);
if (!hw->hw_addr) {
@@ -1879,8 +1879,7 @@ static void alx_remove(struct pci_dev *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int alx_suspend(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct alx_priv *alx = pci_get_drvdata(pdev);
+   struct alx_priv *alx = dev_get_drvdata(dev);
 
if (!netif_running(alx->dev))
return 0;
@@ -1891,8 +1890,7 @@ static int alx_suspend(struct device *dev)
 
 static int alx_resume(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct alx_priv *alx = pci_get_drvdata(pdev);
+   struct alx_priv *alx = dev_get_drvdata(dev);
struct alx_hw *hw = >hw;
int err;
 
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c 
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index be7f9cebb675..16481eb5c422 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -2422,8 +2422,7 @@ static int atl1c_close(struct net_device *netdev)
 
 static int atl1c_suspend(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *netdev = pci_get_drvdata(pdev);
+   struct net_device *netdev = dev_get_drvdata(dev);
struct atl1c_adapter *adapter = netdev_priv(netdev);
struct atl1c_hw *hw = >hw;
u32 wufc = adapter->wol;
@@ -2437,7 +2436,7 @@ static int atl1c_suspend(struct device *dev)
 
if (wufc)
if (atl1c_phy_to_ps_link(hw) != 0)
-   dev_dbg(>dev, "phy power saving failed");
+   dev_dbg(dev, "phy power saving failed");
 
atl1c_power_saving(hw, wufc);
 
@@ -2447,8 +2446,7 @@ static int atl1c_suspend(struct device *dev)
 #ifdef CONFIG_PM_SLEEP
 static int atl1c_resume(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *netdev = pci_get_drvdata(pdev);
+   struct net_device *netdev = dev_get_drvdata(dev);
struct atl1c_adapter *adapter = netdev_priv(netdev);
 
AT_WRITE_REG(>hw, REG_WOL_CTRL, 0);
@@ -2503,7 +2501,7 @@ static const struct net_device_ops atl1c_netdev_ops = {
 static int atl1c_init_netdev(struct net_device *netdev, struct pci_dev *pdev)
 {
SET_NETDEV_DEV(netdev, >dev);
-   pci_set_drvdata(pdev, netdev);
+   dev_set_drvdata(>dev, netdev);
 
netdev->netdev_ops = _netdev_ops;
netdev->watchdog_timeo = AT_TX_WATCHDOG;
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c 
b/drivers/net/ethernet/atheros/atlx/atl1.c
index b5c6dc914720..8b9df5f8795b 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -2754,8 +2754,7 @@ static int atl1_close(struct net_device *netdev)
 #ifdef CONFIG_PM_SLEEP
 static int atl1_suspend(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *netdev = pci_get_drvdata(pdev);
+   struct net_device *netdev = dev_get_drvdata(dev);
struct atl1_adapter *adapter = netdev_priv(netdev);
struct atl1_hw *hw = >hw;
u32 ctrl = 0;
@@ -2780,7 +2779,7 @@ static int atl1_suspend(struct device *dev)
val = atl1_get_speed_and_duplex(hw, , );
if (val) {
if (netif_msg_ifdown(adapter))
-   dev_printk(KERN_DEBUG, >dev,
+   dev_printk(KERN_DEBUG, dev,
"error getting speed/duplex\n");
goto disable_wol;
}
@@ -2837,8 +2836,7 @@ static int atl1_suspend(struct device *dev)
 
 static int atl1_resume(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *netdev = pci_get_drvdata(pdev);
+   struct net_device *netdev = dev_get_drvdata(dev);
struct atl1_adapter *adapter = 

[PATCH REBASE v4 06/14] arm: Properly account for stack randomization and stack guard gap

[Alexandre Ghiti]

This commit takes care of stack randomization and stack guard gap when
computing mmap base address and checks if the task asked for randomization.
This fixes the problem uncovered and not fixed for arm here:
https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
---
 arch/arm/mm/mmap.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index f866870db749..bff3d00bda5b 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -18,8 +18,9 @@
 (((pgoff)<> (PAGE_SHIFT - 12))
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
 {
@@ -35,6 +36,15 @@ static int mmap_is_legacy(struct rlimit *rlim_stack)
 static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
 {
unsigned long gap = rlim_stack->rlim_cur;
+   unsigned long pad = stack_guard_gap;
+
+   /* Account for stack randomization if necessary */
+   if (current->flags & PF_RANDOMIZE)
+   pad += (STACK_RND_MASK << PAGE_SHIFT);
+
+   /* Values close to RLIM_INFINITY can overflow. */
+   if (gap + pad > gap)
+   gap += pad;
 
if (gap < MIN_GAP)
gap = MIN_GAP;
-- 
2.20.1

[PATCH net-next v2 5/8] fm10k: Use dev_get_drvdata

[Chuhong Yuan]

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Change pci_set_drvdata to dev_set_drvdata
to keep consistency.

 drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c 
b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
index e49fb51d3613..b4aa49b53c61 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -2144,7 +2144,7 @@ static int fm10k_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
SET_NETDEV_DEV(netdev, >dev);
 
interface = netdev_priv(netdev);
-   pci_set_drvdata(pdev, interface);
+   dev_set_drvdata(>dev, interface);
 
interface->netdev = netdev;
interface->pdev = pdev;
@@ -2352,7 +2352,7 @@ static int fm10k_handle_resume(struct fm10k_intfc 
*interface)
  **/
 static int __maybe_unused fm10k_resume(struct device *dev)
 {
-   struct fm10k_intfc *interface = pci_get_drvdata(to_pci_dev(dev));
+   struct fm10k_intfc *interface = dev_get_drvdata(dev);
struct net_device *netdev = interface->netdev;
struct fm10k_hw *hw = >hw;
int err;
@@ -2379,7 +2379,7 @@ static int __maybe_unused fm10k_resume(struct device *dev)
  **/
 static int __maybe_unused fm10k_suspend(struct device *dev)
 {
-   struct fm10k_intfc *interface = pci_get_drvdata(to_pci_dev(dev));
+   struct fm10k_intfc *interface = dev_get_drvdata(dev);
struct net_device *netdev = interface->netdev;
 
netif_device_detach(netdev);
-- 
2.20.1

[PATCH net-next v2 4/8] e1000e: Use dev_get_drvdata where possible

[Chuhong Yuan]

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Change pci_set_drvdata to dev_set_drvdata
to keep consistency.

 drivers/net/ethernet/intel/e1000e/netdev.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index e4baa13b3cda..ad203a2a64c4 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6297,7 +6297,7 @@ static void e1000e_flush_lpic(struct pci_dev *pdev)
 
 static int e1000e_pm_freeze(struct device *dev)
 {
-   struct net_device *netdev = pci_get_drvdata(to_pci_dev(dev));
+   struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
 
netif_device_detach(netdev);
@@ -6630,7 +6630,7 @@ static int __e1000_resume(struct pci_dev *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int e1000e_pm_thaw(struct device *dev)
 {
-   struct net_device *netdev = pci_get_drvdata(to_pci_dev(dev));
+   struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
 
e1000e_set_interrupt_capability(adapter);
@@ -6679,8 +6679,7 @@ static int e1000e_pm_resume(struct device *dev)
 
 static int e1000e_pm_runtime_idle(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *netdev = pci_get_drvdata(pdev);
+   struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
u16 eee_lp;
 
@@ -7105,7 +7104,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
netdev->irq = pdev->irq;
 
-   pci_set_drvdata(pdev, netdev);
+   dev_set_drvdata(>dev, netdev);
adapter = netdev_priv(netdev);
hw = >hw;
adapter->netdev = netdev;
-- 
2.20.1

[PATCH net-next v2 8/8] net: jme: Use dev_get_drvdata

[Chuhong Yuan]

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Change pci_set_drvdata to dev_set_drvdata
to keep consistency.

 drivers/net/ethernet/jme.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index 0b668357db4d..6815bd18a477 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -3000,7 +3000,7 @@ jme_init_one(struct pci_dev *pdev,
netdev->max_mtu = MAX_ETHERNET_JUMBO_PACKET_SIZE - ETH_HLEN;
 
SET_NETDEV_DEV(netdev, >dev);
-   pci_set_drvdata(pdev, netdev);
+   dev_set_drvdata(>dev, netdev);
 
/*
 * init adapter info
@@ -3193,8 +3193,7 @@ jme_shutdown(struct pci_dev *pdev)
 static int
 jme_suspend(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *netdev = pci_get_drvdata(pdev);
+   struct net_device *netdev = dev_get_drvdata(dev);
struct jme_adapter *jme = netdev_priv(netdev);
 
if (!netif_running(netdev))
@@ -3236,8 +3235,7 @@ jme_suspend(struct device *dev)
 static int
 jme_resume(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *netdev = pci_get_drvdata(pdev);
+   struct net_device *netdev = dev_get_drvdata(dev);
struct jme_adapter *jme = netdev_priv(netdev);
 
if (!netif_running(netdev))
-- 
2.20.1

[PATCH REBASE v4 07/14] arm: Use STACK_TOP when computing mmap base address

[Alexandre Ghiti]

mmap base address must be computed wrt stack top address, using TASK_SIZE
is wrong since STACK_TOP and TASK_SIZE are not equivalent.

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
---
 arch/arm/mm/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index bff3d00bda5b..0b94b674aa91 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -19,7 +19,7 @@
 
 /* gap between mmap and stack */
 #define MIN_GAP(128*1024*1024UL)
-#define MAX_GAP((TASK_SIZE)/6*5)
+#define MAX_GAP((STACK_TOP)/6*5)
 #define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
@@ -51,7 +51,7 @@ static unsigned long mmap_base(unsigned long rnd, struct 
rlimit *rlim_stack)
else if (gap > MAX_GAP)
gap = MAX_GAP;
 
-   return PAGE_ALIGN(TASK_SIZE - gap - rnd);
+   return PAGE_ALIGN(STACK_TOP - gap - rnd);
 }
 
 /*
-- 
2.20.1

[PATCH net-next v2 7/8] igb: Use dev_get_drvdata where possible

[Chuhong Yuan]

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Change pci_set_drvdata to dev_set_drvdata
to keep consistency.

 drivers/net/ethernet/intel/igb/igb_main.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c 
b/drivers/net/ethernet/intel/igb/igb_main.c
index b4df3e319467..ed301428c0ce 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3048,7 +3048,7 @@ static int igb_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
SET_NETDEV_DEV(netdev, >dev);
 
-   pci_set_drvdata(pdev, netdev);
+   dev_set_drvdata(>dev, netdev);
adapter = netdev_priv(netdev);
adapter->netdev = netdev;
adapter->pdev = pdev;
@@ -8879,8 +8879,7 @@ static int __maybe_unused igb_resume(struct device *dev)
 
 static int __maybe_unused igb_runtime_idle(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *netdev = pci_get_drvdata(pdev);
+   struct net_device *netdev = dev_get_drvdata(dev);
struct igb_adapter *adapter = netdev_priv(netdev);
 
if (!igb_has_link(adapter))
-- 
2.20.1

[PATCH net-next v2 6/8] i40e: Use dev_get_drvdata

[Chuhong Yuan]

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Change pci_set_drvdata to dev_set_drvdata
to keep consistency.

 drivers/net/ethernet/intel/i40e/i40e_main.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 9ebbe3da61bb..a83198a0ba51 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -14938,7 +14938,7 @@ static int i40e_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
if (is_valid_ether_addr(hw->mac.port_addr))
pf->hw_features |= I40E_HW_PORT_ID_VALID;
 
-   pci_set_drvdata(pdev, pf);
+   dev_set_drvdata(>dev, pf);
pci_save_state(pdev);
 
dev_info(>dev,
@@ -15605,8 +15605,7 @@ static void i40e_shutdown(struct pci_dev *pdev)
  **/
 static int __maybe_unused i40e_suspend(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct i40e_pf *pf = pci_get_drvdata(pdev);
+   struct i40e_pf *pf = dev_get_drvdata(dev);
struct i40e_hw *hw = >hw;
 
/* If we're already suspended, then there is nothing to do */
@@ -15656,8 +15655,7 @@ static int __maybe_unused i40e_suspend(struct device 
*dev)
  **/
 static int __maybe_unused i40e_resume(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct i40e_pf *pf = pci_get_drvdata(pdev);
+   struct i40e_pf *pf = dev_get_drvdata(dev);
int err;
 
/* If we're not suspended, then there is nothing to do */
@@ -15674,7 +15672,7 @@ static int __maybe_unused i40e_resume(struct device 
*dev)
 */
err = i40e_restore_interrupt_scheme(pf);
if (err) {
-   dev_err(>dev, "Cannot restore interrupt scheme: %d\n",
+   dev_err(dev, "Cannot restore interrupt scheme: %d\n",
err);
}
 
-- 
2.20.1

[PATCH REBASE v4 08/14] arm: Use generic mmap top-down layout and brk randomization

[Alexandre Ghiti]

arm uses a top-down mmap layout by default that exactly fits the generic
functions, so get rid of arch specific code and use the generic version
by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
As ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT selects ARCH_HAS_ELF_RANDOMIZE,
use the generic version of arch_randomize_brk since it also fits.
Note that this commit also removes the possibility for arm to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.
Note that it is safe to remove STACK_RND_MASK since it matches the default
value.

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
---
 arch/arm/Kconfig |  2 +-
 arch/arm/include/asm/processor.h |  2 --
 arch/arm/kernel/process.c|  5 ---
 arch/arm/mm/mmap.c   | 62 
 4 files changed, 1 insertion(+), 70 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..81b08b027e4e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,7 +7,6 @@ config ARM
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
-   select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
select ARCH_HAS_KCOV
@@ -30,6 +29,7 @@ config ARM
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF
+   select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select BUILDTIME_EXTABLE_SORT if MMU
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 20c2f42454b8..614bf829e454 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -140,8 +140,6 @@ static inline void prefetchw(const void *ptr)
 #endif
 #endif
 
-#define HAVE_ARCH_PICK_MMAP_LAYOUT
-
 #endif
 
 #endif /* __ASM_ARM_PROCESSOR_H */
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index f934a6739fc0..9485acc520a4 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -319,11 +319,6 @@ unsigned long get_wchan(struct task_struct *p)
return 0;
 }
 
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
-   return randomize_page(mm->brk, 0x0200);
-}
-
 #ifdef CONFIG_MMU
 #ifdef CONFIG_KUSER_HELPERS
 /*
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 0b94b674aa91..b8d912ac9e61 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -17,43 +17,6 @@
addr)+SHMLBA-1)&~(SHMLBA-1)) +  \
 (((pgoff)<> (PAGE_SHIFT - 12))
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
-   if (current->personality & ADDR_COMPAT_LAYOUT)
-   return 1;
-
-   if (rlim_stack->rlim_cur == RLIM_INFINITY)
-   return 1;
-
-   return sysctl_legacy_va_layout;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
-   unsigned long gap = rlim_stack->rlim_cur;
-   unsigned long pad = stack_guard_gap;
-
-   /* Account for stack randomization if necessary */
-   if (current->flags & PF_RANDOMIZE)
-   pad += (STACK_RND_MASK << PAGE_SHIFT);
-
-   /* Values close to RLIM_INFINITY can overflow. */
-   if (gap + pad > gap)
-   gap += pad;
-
-   if (gap < MIN_GAP)
-   gap = MIN_GAP;
-   else if (gap > MAX_GAP)
-   gap = MAX_GAP;
-
-   return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
 /*
  * We need to ensure that shared mappings are correctly aligned to
  * avoid aliasing issues with VIPT caches.  We need to ensure that
@@ -181,31 +144,6 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
unsigned long addr0,
return addr;
 }
 
-unsigned long arch_mmap_rnd(void)
-{
-   unsigned long rnd;
-
-   rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-
-   return rnd << PAGE_SHIFT;
-}
-
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
-   unsigned long random_factor = 0UL;
-
-   if (current->flags & PF_RANDOMIZE)
-   random_factor = arch_mmap_rnd();
-
-   if (mmap_is_legacy(rlim_stack)) {
-   mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
-   mm->get_unmapped_area = arch_get_unmapped_area;
-   } else {
-   mm->mmap_base = mmap_base(random_factor, rlim_stack);
-   mm->get_unmapped_area = arch_get_unmapped_area_topdown;
-   }
-}
-
 /*
  * You really shouldn't be using read() or write() on /dev/mem.  This
  * might go away in the future.
-- 
2.20.1

[PATCH REBASE v4 09/14] mips: Properly account for stack randomization and stack guard gap

[Alexandre Ghiti]

This commit takes care of stack randomization and stack guard gap when
computing mmap base address and checks if the task asked for randomization.
This fixes the problem uncovered and not fixed for arm here:
https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
Acked-by: Paul Burton 
---
 arch/mips/mm/mmap.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index d79f2b432318..f5c778113384 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -21,8 +21,9 @@ unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches 
*/
 EXPORT_SYMBOL(shm_align_mask);
 
 /* gap between mmap and stack */
-#define MIN_GAP (128*1024*1024UL)
-#define MAX_GAP ((TASK_SIZE)/6*5)
+#define MIN_GAP(128*1024*1024UL)
+#define MAX_GAP((TASK_SIZE)/6*5)
+#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
 {
@@ -38,6 +39,15 @@ static int mmap_is_legacy(struct rlimit *rlim_stack)
 static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
 {
unsigned long gap = rlim_stack->rlim_cur;
+   unsigned long pad = stack_guard_gap;
+
+   /* Account for stack randomization if necessary */
+   if (current->flags & PF_RANDOMIZE)
+   pad += (STACK_RND_MASK << PAGE_SHIFT);
+
+   /* Values close to RLIM_INFINITY can overflow. */
+   if (gap + pad > gap)
+   gap += pad;
 
if (gap < MIN_GAP)
gap = MIN_GAP;
-- 
2.20.1

[PATCH v3] drivers: net: xgene: Remove acpi_has_method() calls

[Kelsey Skunberg]

acpi_evaluate_object will already return an error if the needed method
does not exist. Remove unnecessary acpi_has_method() calls and check the
returned acpi_status for failure instead.

Signed-off-by: Kelsey Skunberg 
---
Changes in v2:
- Fixed white space warnings and errors

Changes in v3:
- Resolved build errors caused by missing bracket

 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c| 9 -
 drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c | 9 +
 drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c | 9 -
 3 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 61a465097cb8..79924efd4ab7 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -694,6 +694,7 @@ bool xgene_ring_mgr_init(struct xgene_enet_pdata *p)
 static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
 {
struct device *dev = >pdev->dev;
+   acpi_status status;
 
if (!xgene_ring_mgr_init(pdata))
return -ENODEV;
@@ -712,11 +713,9 @@ static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
udelay(5);
} else {
 #ifdef CONFIG_ACPI
-   if (acpi_has_method(ACPI_HANDLE(>pdev->dev), "_RST")) {
-   acpi_evaluate_object(ACPI_HANDLE(>pdev->dev),
-"_RST", NULL, NULL);
-   } else if (acpi_has_method(ACPI_HANDLE(>pdev->dev),
-"_INI")) {
+   status = acpi_evaluate_object(ACPI_HANDLE(>pdev->dev),
+ "_RST", NULL, NULL);
+   if (ACPI_FAILURE(status)) {
acpi_evaluate_object(ACPI_HANDLE(>pdev->dev),
 "_INI", NULL, NULL);
}
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
index 6453fc2ebb1f..3b3dc5b25b29 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
@@ -437,6 +437,7 @@ static void xgene_sgmac_tx_disable(struct xgene_enet_pdata 
*p)
 static int xgene_enet_reset(struct xgene_enet_pdata *p)
 {
struct device *dev = >pdev->dev;
+   acpi_status status;
 
if (!xgene_ring_mgr_init(p))
return -ENODEV;
@@ -460,12 +461,12 @@ static int xgene_enet_reset(struct xgene_enet_pdata *p)
}
} else {
 #ifdef CONFIG_ACPI
-   if (acpi_has_method(ACPI_HANDLE(>pdev->dev), "_RST"))
-   acpi_evaluate_object(ACPI_HANDLE(>pdev->dev),
-"_RST", NULL, NULL);
-   else if (acpi_has_method(ACPI_HANDLE(>pdev->dev), "_INI"))
+   status = acpi_evaluate_object(ACPI_HANDLE(>pdev->dev),
+ "_RST", NULL, NULL);
+   if (ACPI_FAILURE(status)) {
acpi_evaluate_object(ACPI_HANDLE(>pdev->dev),
 "_INI", NULL, NULL);
+   }
 #endif
}
 
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c
index 133eb91c542e..78584089d76d 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c
@@ -380,6 +380,7 @@ static void xgene_xgmac_tx_disable(struct xgene_enet_pdata 
*pdata)
 static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
 {
struct device *dev = >pdev->dev;
+   acpi_status status;
 
if (!xgene_ring_mgr_init(pdata))
return -ENODEV;
@@ -393,11 +394,9 @@ static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
udelay(5);
} else {
 #ifdef CONFIG_ACPI
-   if (acpi_has_method(ACPI_HANDLE(>pdev->dev), "_RST")) {
-   acpi_evaluate_object(ACPI_HANDLE(>pdev->dev),
-"_RST", NULL, NULL);
-   } else if (acpi_has_method(ACPI_HANDLE(>pdev->dev),
-  "_INI")) {
+   status = acpi_evaluate_object(ACPI_HANDLE(>pdev->dev),
+ "_RST", NULL, NULL);
+   if (ACPI_FAILURE(status)) {
acpi_evaluate_object(ACPI_HANDLE(>pdev->dev),
 "_INI", NULL, NULL);
}
-- 
2.20.1

[PATCH REBASE v4 10/14] mips: Use STACK_TOP when computing mmap base address

[Alexandre Ghiti]

mmap base address must be computed wrt stack top address, using TASK_SIZE
is wrong since STACK_TOP and TASK_SIZE are not equivalent.

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
Acked-by: Paul Burton 
---
 arch/mips/mm/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index f5c778113384..a7e84b2e71d7 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -22,7 +22,7 @@ EXPORT_SYMBOL(shm_align_mask);
 
 /* gap between mmap and stack */
 #define MIN_GAP(128*1024*1024UL)
-#define MAX_GAP((TASK_SIZE)/6*5)
+#define MAX_GAP((STACK_TOP)/6*5)
 #define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
@@ -54,7 +54,7 @@ static unsigned long mmap_base(unsigned long rnd, struct 
rlimit *rlim_stack)
else if (gap > MAX_GAP)
gap = MAX_GAP;
 
-   return PAGE_ALIGN(TASK_SIZE - gap - rnd);
+   return PAGE_ALIGN(STACK_TOP - gap - rnd);
 }
 
 #define COLOUR_ALIGN(addr, pgoff)  \
-- 
2.20.1

[PATCH REBASE v4 11/14] mips: Adjust brk randomization offset to fit generic version

[Alexandre Ghiti]

This commit simply bumps up to 32MB and 1GB the random offset
of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively.

Suggested-by: Kees Cook 
Signed-off-by: Alexandre Ghiti 
Reviewed-by: Kees Cook 
---
 arch/mips/mm/mmap.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index a7e84b2e71d7..faa5aa615389 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned long shm_align_mask = PAGE_SIZE - 1;  /* Sane caches */
 EXPORT_SYMBOL(shm_align_mask);
@@ -189,11 +190,11 @@ static inline unsigned long brk_rnd(void)
unsigned long rnd = get_random_long();
 
rnd = rnd << PAGE_SHIFT;
-   /* 8MB for 32bit, 256MB for 64bit */
+   /* 32MB for 32bit, 1GB for 64bit */
if (TASK_IS_32BIT_ADDR)
-   rnd = rnd & 0x7ful;
+   rnd = rnd & SZ_32M;
else
-   rnd = rnd & 0xffful;
+   rnd = rnd & SZ_1G;
 
return rnd;
 }
-- 
2.20.1

[PATCH REBASE v4 12/14] mips: Replace arch specific way to determine 32bit task with generic version

[Alexandre Ghiti]

Mips uses TASK_IS_32BIT_ADDR to determine if a task is 32bit, but
this define is mips specific and other arches do not have it: instead,
use !IS_ENABLED(CONFIG_64BIT) || is_compat_task() condition.

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Kees Cook 
---
 arch/mips/mm/mmap.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index faa5aa615389..d4eafbb82789 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned long shm_align_mask = PAGE_SIZE - 1;  /* Sane caches */
 EXPORT_SYMBOL(shm_align_mask);
@@ -191,7 +192,7 @@ static inline unsigned long brk_rnd(void)
 
rnd = rnd << PAGE_SHIFT;
/* 32MB for 32bit, 1GB for 64bit */
-   if (TASK_IS_32BIT_ADDR)
+   if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task())
rnd = rnd & SZ_32M;
else
rnd = rnd & SZ_1G;
-- 
2.20.1

Re: [PATCH v2] RDMA/hns: Fix build error for hip08

[Yuehaibing]

Pls drop this, this cannot fix the issue.

On 2019/7/24 11:40, YueHaibing wrote:
> If INFINIBAND_HNS_HIP08 is selected and HNS3 is m,
> but INFINIBAND_HNS is y, building fails:
> 
> drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function `hns_roce_hw_v2_exit':
> hns_roce_hw_v2.c:(.exit.text+0xd): undefined reference to 
> `hnae3_unregister_client'
> drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function `hns_roce_hw_v2_init':
> hns_roce_hw_v2.c:(.init.text+0xd): undefined reference to 
> `hnae3_register_client'
> 
> Reported-by: Hulk Robot 
> Suggested-by: Leon Romanovsky 
> Fixes: dd74282df573 ("RDMA/hns: Initialize the PCI device for hip08 RoCE")
> Signed-off-by: YueHaibing 
> ---
> v2: select HNS3 to fix this
> ---
>  drivers/infiniband/hw/hns/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/infiniband/hw/hns/Kconfig 
> b/drivers/infiniband/hw/hns/Kconfig
> index 8bf847b..b9dfac0 100644
> --- a/drivers/infiniband/hw/hns/Kconfig
> +++ b/drivers/infiniband/hw/hns/Kconfig
> @@ -22,7 +22,8 @@ config INFINIBAND_HNS_HIP06
>  
>  config INFINIBAND_HNS_HIP08
>   bool "Hisilicon Hip08 Family RoCE support"
> - depends on INFINIBAND_HNS && PCI && HNS3
> + depends on INFINIBAND_HNS && PCI
> + select HNS3
>   ---help---
> RoCE driver support for Hisilicon RoCE engine in Hisilicon Hip08 SoC.
> The RoCE engine is a PCI device.
> 

[PATCH REBASE v4 13/14] mips: Use generic mmap top-down layout and brk randomization

[Alexandre Ghiti]

mips uses a top-down layout by default that exactly fits the generic
functions, so get rid of arch specific code and use the generic version
by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
As ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT selects ARCH_HAS_ELF_RANDOMIZE,
use the generic version of arch_randomize_brk since it also fits.
Note that this commit also removes the possibility for mips to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Kees Cook 
---
 arch/mips/Kconfig |  2 +-
 arch/mips/include/asm/processor.h |  5 --
 arch/mips/mm/mmap.c   | 96 ---
 3 files changed, 1 insertion(+), 102 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d50fafd7bf3a..4e85d7d2cf1a 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -5,7 +5,6 @@ config MIPS
select ARCH_32BIT_OFF_T if !64BIT
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
select ARCH_CLOCKSOURCE_DATA
-   select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_UPROBES
@@ -13,6 +12,7 @@ config MIPS
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
+   select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
diff --git a/arch/mips/include/asm/processor.h 
b/arch/mips/include/asm/processor.h
index aca909bd7841..fba18d4a9190 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -29,11 +29,6 @@
 
 extern unsigned int vced_count, vcei_count;
 
-/*
- * MIPS does have an arch_pick_mmap_layout()
- */
-#define HAVE_ARCH_PICK_MMAP_LAYOUT 1
-
 #ifdef CONFIG_32BIT
 #ifdef CONFIG_KVM_GUEST
 /* User space process size is limited to 1GB in KVM Guest Mode */
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index d4eafbb82789..00fe90c6db3e 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -16,49 +16,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 
 unsigned long shm_align_mask = PAGE_SIZE - 1;  /* Sane caches */
 EXPORT_SYMBOL(shm_align_mask);
 
-/* gap between mmap and stack */
-#define MIN_GAP(128*1024*1024UL)
-#define MAX_GAP((STACK_TOP)/6*5)
-#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
-   if (current->personality & ADDR_COMPAT_LAYOUT)
-   return 1;
-
-   if (rlim_stack->rlim_cur == RLIM_INFINITY)
-   return 1;
-
-   return sysctl_legacy_va_layout;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
-   unsigned long gap = rlim_stack->rlim_cur;
-   unsigned long pad = stack_guard_gap;
-
-   /* Account for stack randomization if necessary */
-   if (current->flags & PF_RANDOMIZE)
-   pad += (STACK_RND_MASK << PAGE_SHIFT);
-
-   /* Values close to RLIM_INFINITY can overflow. */
-   if (gap + pad > gap)
-   gap += pad;
-
-   if (gap < MIN_GAP)
-   gap = MIN_GAP;
-   else if (gap > MAX_GAP)
-   gap = MAX_GAP;
-
-   return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
 #define COLOUR_ALIGN(addr, pgoff)  \
addr) + shm_align_mask) & ~shm_align_mask) +\
 (((pgoff) << PAGE_SHIFT) & shm_align_mask))
@@ -156,63 +117,6 @@ unsigned long arch_get_unmapped_area_topdown(struct file 
*filp,
addr0, len, pgoff, flags, DOWN);
 }
 
-unsigned long arch_mmap_rnd(void)
-{
-   unsigned long rnd;
-
-#ifdef CONFIG_COMPAT
-   if (TASK_IS_32BIT_ADDR)
-   rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
-   else
-#endif /* CONFIG_COMPAT */
-   rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-
-   return rnd << PAGE_SHIFT;
-}
-
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
-   unsigned long random_factor = 0UL;
-
-   if (current->flags & PF_RANDOMIZE)
-   random_factor = arch_mmap_rnd();
-
-   if (mmap_is_legacy(rlim_stack)) {
-   mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
-   mm->get_unmapped_area = arch_get_unmapped_area;
-   } else {
-   mm->mmap_base = mmap_base(random_factor, rlim_stack);
-   mm->get_unmapped_area = arch_get_unmapped_area_topdown;
-   }
-}
-
-static inline unsigned long brk_rnd(void)
-{
-   unsigned long rnd = get_random_long();
-
-   rnd = rnd << PAGE_SHIFT;
-   /* 32MB for 32bit, 1GB for 64bit */
-   if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task())
-   rnd = rnd & 

Re: [PATCH v4 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR

[Jian-Hong Pan]

Jian-Hong Pan  於 2019年7月11日 週四 下午1:28寫道：
>
> Jian-Hong Pan  於 2019年7月11日 週四 下午1:25寫道：
> >
> > Testing with RTL8822BE hardware, when available memory is low, we
> > frequently see a kernel panic and system freeze.
> >
> > First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
> >
> > rx routine starvation
> > WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822 
> > rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> > [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> >
> > Then we see a variety of different error conditions and kernel panics,
> > such as this one (trimmed):
> >
> > rtw_pci :02:00.0: pci bus timeout, check dma status
> > skbuff: skb_over_panic: text:091b6e66 len:415 put:415 
> > head:d2880c6f data:7a02b1ea tail:0x1df end:0xc0 dev:
> > [ cut here ]
> > kernel BUG at net/core/skbuff.c:105!
> > invalid opcode:  [#1] SMP NOPTI
> > RIP: 0010:skb_panic+0x43/0x45
> >
> > When skb allocation fails and the "rx routine starvation" is hit, the
> > function returns immediately without updating the RX ring. At this
> > point, the RX ring may continue referencing an old skb which was already
> > handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> > bad things happen.
> >
> > This patch allocates a new, data-sized skb first in RX ISR. After
> > copying the data in, we pass it to the upper layers. However, if skb
> > allocation fails, we effectively drop the frame. In both cases, the
> > original, full size ring skb is reused.
> >
> > In addition, to fixing the kernel crash, the RX routine should now
> > generally behave better under low memory conditions.
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> > Signed-off-by: Jian-Hong Pan 
> > Cc: 
> > ---
>
> Sorry, I forget to place the version difference here.
>
> v2:
>  - Allocate new data-sized skb and put data into it, then pass it to
>mac80211. Reuse the original skb in RX ring by DMA sync.
>  - Modify the commit message.
>  - Introduce following [PATCH v3 2/2] rtw88: pci: Use DMA sync instead
>of remapping in RX ISR.
>
> v3:
>  - Same as v2.
>
> v4:
>  - Fix comment: allocate a new skb for this frame, discard the frame
> if none available
>
> >  drivers/net/wireless/realtek/rtw88/pci.c | 49 +++-
> >  1 file changed, 22 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c 
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index cfe05ba7280d..c415f5e94fed 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, 
> > struct rtw_pci *rtwpci,
> > u32 pkt_offset;
> > u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
> > u32 buf_desc_sz = chip->rx_buf_desc_sz;
> > +   u32 new_len;
> > u8 *rx_desc;
> > dma_addr_t dma;
> >
> > @@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, 
> > struct rtw_pci *rtwpci,
> > pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
> >  pkt_stat.shift;
> >
> > -   if (pkt_stat.is_c2h) {
> > -   /* keep rx_desc, halmac needs it */
> > -   skb_put(skb, pkt_stat.pkt_len + pkt_offset);
> > +   /* allocate a new skb for this frame,
> > +* discard the frame if none available
> > +*/
> > +   new_len = pkt_stat.pkt_len + pkt_offset;
> > +   new = dev_alloc_skb(new_len);
> > +   if (WARN_ONCE(!new, "rx routine starvation\n"))
> > +   goto next_rp;
> > +
> > +   /* put the DMA data including rx_desc from phy to new skb */
> > +   skb_put_data(new, skb->data, new_len);
> >
> > -   /* pass offset for further operation */
> > -   *((u32 *)skb->cb) = pkt_offset;
> > -   skb_queue_tail(>c2h_queue, skb);
> > +   if (pkt_stat.is_c2h) {
> > +/* pass rx_desc & offset for further operation */
> > +   *((u32 *)new->cb) = pkt_offset;
> > +   skb_queue_tail(>c2h_queue, new);
> > ieee80211_queue_work(rtwdev->hw, >c2h_work);
> > } else {
> > -   /* remove rx_desc, maybe use skb_pull? */
> > -   skb_put(skb, pkt_stat.pkt_len);
> > -   skb_reserve(skb, pkt_offset);
> > -
> > -   /* alloc a smaller skb to mac80211 */
> > -   new = dev_alloc_skb(pkt_stat.pkt_len);
> > -   if (!new) {
> > -   new = skb;
> > -   } else {
> > -   skb_put_data(new, skb->data, skb->len);
> > -   

[PATCH REBASE v4 14/14] riscv: Make mmap allocation top-down by default

[Alexandre Ghiti]

In order to avoid wasting user address space by using bottom-up mmap
allocation scheme, prefer top-down scheme when possible.

Before:
root@qemuriscv64:~# cat /proc/self/maps
0001-00016000 r-xp  fe:00 6389   /bin/cat.coreutils
00016000-00017000 r--p 5000 fe:00 6389   /bin/cat.coreutils
00017000-00018000 rw-p 6000 fe:00 6389   /bin/cat.coreutils
00018000-00039000 rw-p  00:00 0  [heap]
156000-16d000 r-xp  fe:00 7193   /lib/ld-2.28.so
16d000-16e000 r--p 00016000 fe:00 7193   /lib/ld-2.28.so
16e000-16f000 rw-p 00017000 fe:00 7193   /lib/ld-2.28.so
16f000-17 rw-p  00:00 0
17-172000 r-xp  00:00 0  [vdso]
174000-176000 rw-p  00:00 0
176000-1555674000 r-xp  fe:00 7187   /lib/libc-2.28.so
1555674000-1555678000 r--p 000fd000 fe:00 7187   /lib/libc-2.28.so
1555678000-155567a000 rw-p 00101000 fe:00 7187   /lib/libc-2.28.so
155567a000-15556a rw-p  00:00 0
3fffb9-3fffbb1000 rw-p  00:00 0  [stack]

After:
root@qemuriscv64:~# cat /proc/self/maps
0001-00016000 r-xp  fe:00 6389   /bin/cat.coreutils
00016000-00017000 r--p 5000 fe:00 6389   /bin/cat.coreutils
00017000-00018000 rw-p 6000 fe:00 6389   /bin/cat.coreutils
2de81000-2dea2000 rw-p  00:00 0  [heap]
3ff7eb6000-3ff7ed8000 rw-p  00:00 0
3ff7ed8000-3ff7fd6000 r-xp  fe:00 7187   /lib/libc-2.28.so
3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187   /lib/libc-2.28.so
3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187   /lib/libc-2.28.so
3ff7fdc000-3ff7fe2000 rw-p  00:00 0
3ff7fe4000-3ff7fe6000 r-xp  00:00 0  [vdso]
3ff7fe6000-3ff7ffd000 r-xp  fe:00 7193   /lib/ld-2.28.so
3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193   /lib/ld-2.28.so
3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193   /lib/ld-2.28.so
3ff7fff000-3ff800 rw-p  00:00 0
3fff888000-3fff8a9000 rw-p  00:00 0  [stack]

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Kees Cook 
---
 arch/riscv/Kconfig | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 59a4727ecd6c..6a63973873fd 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -54,6 +54,17 @@ config RISCV
select EDAC_SUPPORT
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
+   select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
+   select HAVE_ARCH_MMAP_RND_BITS
+
+config ARCH_MMAP_RND_BITS_MIN
+   default 18
+
+# max bits determined by the following formula:
+#  VA_BITS - PAGE_SHIFT - 3
+config ARCH_MMAP_RND_BITS_MAX
+   default 33 if 64BIT # SV48 based
+   default 18
 
 config MMU
def_bool y
-- 
2.20.1

Re: + mm-oom-avoid-printk-iteration-under-rcu.patch added to -mm tree

[Michal Hocko]

Andrew,
I've had some concerns wrt. this patch - especially the additional
complexity - and I have to say I am not convinced that this is really
needed. Our past experience in this area suggests that more tricky code
leads to different corner cases. So I am really reluctant to add more
complexity without any real world reports.

On Tue 23-07-19 16:14:29, Andrew Morton wrote:
> From: Tetsuo Handa 
> Subject: mm, oom: avoid printk() iteration under RCU
> 
> Currently dump_tasks() might call printk() for many thousands times under
> RCU, which might take many minutes for slow consoles.  Therefore, split
> dump_tasks() into three stages; take a snapshot of possible OOM victim
> candidates under RCU, dump the snapshot from reschedulable context, and
> destroy the snapshot.
> 
> In a future patch, the first stage would be moved to select_bad_process()
> and the third stage would be moved to after oom_kill_process(), and will
> simplify refcount handling.
> 
> Link: 
> http://lkml.kernel.org/r/1563360901-8277-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
> Signed-off-by: Tetsuo Handa 
> Cc: Shakeel Butt 
> Cc: Michal Hocko 
> Cc: Roman Gushchin 
> Cc: David Rientjes 
> Signed-off-by: Andrew Morton 
> ---
> 
>  include/linux/sched.h |1 
>  mm/oom_kill.c |   67 +++-
>  2 files changed, 34 insertions(+), 34 deletions(-)
> 
> --- a/include/linux/sched.h~mm-oom-avoid-printk-iteration-under-rcu
> +++ a/include/linux/sched.h
> @@ -1246,6 +1246,7 @@ struct task_struct {
>  #ifdef CONFIG_MMU
>   struct task_struct  *oom_reaper_list;
>  #endif
> + struct list_headoom_victim_list;
>  #ifdef CONFIG_VMAP_STACK
>   struct vm_struct*stack_vm_area;
>  #endif
> --- a/mm/oom_kill.c~mm-oom-avoid-printk-iteration-under-rcu
> +++ a/mm/oom_kill.c
> @@ -377,36 +377,13 @@ static void select_bad_process(struct oo
>   }
>  }
>  
> -static int dump_task(struct task_struct *p, void *arg)
> -{
> - struct oom_control *oc = arg;
> - struct task_struct *task;
> -
> - if (oom_unkillable_task(p))
> - return 0;
>  
> - /* p may not have freeable memory in nodemask */
> - if (!is_memcg_oom(oc) && !oom_cpuset_eligible(p, oc))
> - return 0;
> -
> - task = find_lock_task_mm(p);
> - if (!task) {
> - /*
> -  * This is a kthread or all of p's threads have already
> -  * detached their mm's.  There's no need to report
> -  * them; they can't be oom killed anyway.
> -  */
> - return 0;
> +static int add_candidate_task(struct task_struct *p, void *arg)
> +{
> + if (!oom_unkillable_task(p)) {
> + get_task_struct(p);
> + list_add_tail(>oom_victim_list, (struct list_head *) arg);
>   }
> -
> - pr_info("[%7d] %5d %5d %8lu %8lu %8ld %8lu %5hd %s\n",
> - task->pid, from_kuid(_user_ns, task_uid(task)),
> - task->tgid, task->mm->total_vm, get_mm_rss(task->mm),
> - mm_pgtables_bytes(task->mm),
> - get_mm_counter(task->mm, MM_SWAPENTS),
> - task->signal->oom_score_adj, task->comm);
> - task_unlock(task);
> -
>   return 0;
>  }
>  
> @@ -422,19 +399,41 @@ static int dump_task(struct task_struct
>   */
>  static void dump_tasks(struct oom_control *oc)
>  {
> - pr_info("Tasks state (memory values in pages):\n");
> - pr_info("[  pid  ]   uid  tgid total_vm  rss pgtables_bytes 
> swapents oom_score_adj name\n");
> + static LIST_HEAD(list);
> + struct task_struct *p;
> + struct task_struct *t;
>  
>   if (is_memcg_oom(oc))
> - mem_cgroup_scan_tasks(oc->memcg, dump_task, oc);
> + mem_cgroup_scan_tasks(oc->memcg, add_candidate_task, );
>   else {
> - struct task_struct *p;
> -
>   rcu_read_lock();
>   for_each_process(p)
> - dump_task(p, oc);
> + add_candidate_task(p, );
>   rcu_read_unlock();
>   }
> + pr_info("Tasks state (memory values in pages):\n");
> + pr_info("[  pid  ]   uid  tgid total_vm  rss pgtables_bytes 
> swapents oom_score_adj name\n");
> + list_for_each_entry(p, , oom_victim_list) {
> + cond_resched();
> + /* p may not have freeable memory in nodemask */
> + if (!is_memcg_oom(oc) && !oom_cpuset_eligible(p, oc))
> + continue;
> + /* All of p's threads might have already detached their mm's. */
> + t = find_lock_task_mm(p);
> + if (!t)
> + continue;
> + pr_info("[%7d] %5d %5d %8lu %8lu %8ld %8lu %5hd %s\n",
> + t->pid, from_kuid(_user_ns, task_uid(t)),
> + t->tgid, t->mm->total_vm, get_mm_rss(t->mm),
> + mm_pgtables_bytes(t->mm),
> + 

KASAN: slab-out-of-bounds Read in bpf_int_jit_compile

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1760ff8460
kernel config:  https://syzkaller.appspot.com/x/.config?x=7937b718ddac333b
dashboard link: https://syzkaller.appspot.com/bug?extid=35101610ff3e83119b1b
compiler:   clang version 9.0.0 (/home/glider/llvm/clang  
80fee25776c2fb61e74c1ecb1a523375c2500b69)

syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=13c017a460
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=173f827860

The bug was bisected to:

commit 2589726d12a1b12eaaa93c7f1ea64287e383c7a5
Author: Alexei Starovoitov 
Date:   Sat Jun 15 19:12:20 2019 +

bpf: introduce bounded loops

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13df66afa0
final crash:https://syzkaller.appspot.com/x/report.txt?x=103f66afa0
console output: https://syzkaller.appspot.com/x/log.txt?x=17df66afa0

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+35101610ff3e83119...@syzkaller.appspotmail.com
Fixes: 2589726d12a1 ("bpf: introduce bounded loops")

==
BUG: KASAN: slab-out-of-bounds in do_jit /arch/x86/net/bpf_jit_comp.c:966  
[inline]
BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x4d19/0x7530  
/arch/x86/net/bpf_jit_comp.c:1132

Read of size 4 at addr 8880960cc2bc by task syz-executor607/7822

CPU: 0 PID: 7822 Comm: syz-executor607 Not tainted 5.2.0+ #37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack /lib/dump_stack.c:77 [inline]
 dump_stack+0x1d8/0x2f8 /lib/dump_stack.c:113
 print_address_description+0x75/0x5b0 /mm/kasan/report.c:351
 __kasan_report+0x14b/0x1c0 /mm/kasan/report.c:482
 kasan_report+0x26/0x50 /mm/kasan/common.c:612
 __asan_report_load4_noabort+0x14/0x20 /mm/kasan/generic_report.c:131
 do_jit /arch/x86/net/bpf_jit_comp.c:966 [inline]
 bpf_int_jit_compile+0x4d19/0x7530 /arch/x86/net/bpf_jit_comp.c:1132
 bpf_prog_select_runtime+0x756/0xa50 /kernel/bpf/core.c:1725
 bpf_prog_load /kernel/bpf/syscall.c:1702 [inline]
 __do_sys_bpf+0x7d4e/0xc0e0 /kernel/bpf/syscall.c:2849
 __se_sys_bpf /kernel/bpf/syscall.c:2808 [inline]
 __x64_sys_bpf+0x7a/0x90 /kernel/bpf/syscall.c:2808
 do_syscall_64+0xfe/0x140 /arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4402c9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7ffeb7a02c18 EFLAGS: 0246 ORIG_RAX: 0141
RAX: ffda RBX: 004002c8 RCX: 004402c9
RDX: 0046 RSI: 2180 RDI: 0005
RBP: 006ca018 R08:  R09: 
R10:  R11: 0246 R12: 00401b50
R13: 00401be0 R14:  R15: 

Allocated by task 7822:
 save_stack /mm/kasan/common.c:69 [inline]
 set_track /mm/kasan/common.c:77 [inline]
 __kasan_kmalloc+0x11c/0x1b0 /mm/kasan/common.c:487
 kasan_kmalloc+0x9/0x10 /mm/kasan/common.c:501
 kmem_cache_alloc_trace+0x215/0x2f0 /mm/slab.c:3550
 kmalloc /./include/linux/slab.h:552 [inline]
 kzalloc /./include/linux/slab.h:748 [inline]
 bpf_int_jit_compile+0x1b2/0x7530 /arch/x86/net/bpf_jit_comp.c:1092
 bpf_prog_select_runtime+0x756/0xa50 /kernel/bpf/core.c:1725
 bpf_prog_load /kernel/bpf/syscall.c:1702 [inline]
 __do_sys_bpf+0x7d4e/0xc0e0 /kernel/bpf/syscall.c:2849
 __se_sys_bpf /kernel/bpf/syscall.c:2808 [inline]
 __x64_sys_bpf+0x7a/0x90 /kernel/bpf/syscall.c:2808
 do_syscall_64+0xfe/0x140 /arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 7329:
 save_stack /mm/kasan/common.c:69 [inline]
 set_track /mm/kasan/common.c:77 [inline]
 __kasan_slab_free+0x12a/0x1e0 /mm/kasan/common.c:449
 kasan_slab_free+0xe/0x10 /mm/kasan/common.c:457
 __cache_free /mm/slab.c:3425 [inline]
 kfree+0x115/0x200 /mm/slab.c:3756
 tomoyo_path_perm+0x6cc/0x8b0 /security/tomoyo/file.c:842
 tomoyo_inode_getattr+0x1c/0x20 /security/tomoyo/tomoyo.c:129
 security_inode_getattr+0xd5/0x150 /security/security.c:1182
 vfs_getattr+0x2a/0x6d0 /fs/stat.c:115
 vfs_statx /fs/stat.c:191 [inline]
 vfs_stat /./include/linux/fs.h:3182 [inline]
 __do_sys_newstat /fs/stat.c:341 [inline]
 __se_sys_newstat+0x10c/0x210 /fs/stat.c:337
 __x64_sys_newstat+0x5b/0x70 /fs/stat.c:337
 do_syscall_64+0xfe/0x140 /arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at 8880960cc280
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 28 bytes to the right of
 32-byte region [8880960cc280, 8880960cc2a0)
The buggy address belongs to 

Re: [PATCH 2/8] ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc

[Tony Lindgren]

* Keerthy  [190724 05:50]:
> 
> On 24/07/19 12:33 AM, Suman Anna wrote:
> > + Jyri
> > 
> > On 7/23/19 6:28 AM, Tony Lindgren wrote:
> > > We currently get a warning for lcdc because of a difference
> > > with dts provided configuration compared to the legacy platform
> > > data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
> > > the platform data without configuring the modes.
> > 
> > Hi Tony,
> > While I understand that you are trying to match the DT data with the
> > existing legacy data, do you know if there was a reason why this was
> > omitted in the first place? Should we be really adding the MSTANDBY_
> > flags and fix up the DTS node accordingly? I tried looking through the
> > git log, and the initial commit itself didn't add the MSTANDBY_ flags
> > but used the SYSC_HAS_MIDLEMODE.

Yes the goal is to get rid of all errors and warnings in dmesg output
so we can spot the real issues.

> > Jyri,
> > Do you know the history?
> 
> Tony/Suman,
> 
> This patch breaks DS0 on am3.

OK thanks for testing. Let's drop this for now, sounds like there is
some midlemode configuration happening even with no flags set.

Probably the right fix is to configure the usable midlemodes instead
both for platform data and dts data and then drop the platform data.

Regards,

Tony



> > > Let's fix the warning by removing SYSC_HAS_MIDLEMODE. Note that
> > > the am335x TRM lists SYSC_HAS_MIDLEMODE, but it is unused.
> > 
> > 
> > 
> > > 
> > > Signed-off-by: Tony Lindgren 
> > > ---
> > >   arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
> > > b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > > --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > > @@ -231,7 +231,7 @@ static struct omap_hwmod am33xx_control_hwmod = {
> > >   static struct omap_hwmod_class_sysconfig lcdc_sysc = {
> > >   .rev_offs   = 0x0,
> > >   .sysc_offs  = 0x54,
> > > - .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> > > + .sysc_flags = SYSC_HAS_SIDLEMODE,
> > >   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> > >   .sysc_fields= _hwmod_sysc_type2,
> > >   };
> > > 
> > 

Re: [PATCH 07/14] PCI/P2PDMA: Add the provider's pci_dev to the dev_pgmap struct

[Christoph Hellwig]

On Mon, Jul 22, 2019 at 05:08:52PM -0600, Logan Gunthorpe wrote:
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index 143e11d2a5c3..70c262b7c731 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -168,6 +168,7 @@ int pci_p2pdma_add_resource(struct pci_dev *pdev, int 
> bar, size_t size,
>   pgmap->res.end = pgmap->res.start + size - 1;
>   pgmap->res.flags = pci_resource_flags(pdev, bar);
>   pgmap->type = MEMORY_DEVICE_PCI_P2PDMA;
> + pgmap->pci_p2pdma_provider = pdev;
>   pgmap->pci_p2pdma_bus_offset = pci_bus_address(pdev, bar) -
>   pci_resource_start(pdev, bar);

I think we need to bite the bullet and move the PCIe P2P specific
information out of struct dev_pagemap and into a pci-specific structure
that embedds struct dev_pagemap.

Re: [PATCH 11/14] PCI/P2PDMA: dma_map P2PDMA map requests that traverse the host bridge

[Christoph Hellwig]

>   struct dev_pagemap *pgmap = sg_page(sg)->pgmap;
> + struct pci_dev *client;
> + int dist;
> +
> + client = find_parent_pci_dev(dev);
> + if (WARN_ON_ONCE(!client))
> + return 0;
>  
> + dist = upstream_bridge_distance(pgmap->pci_p2pdma_provider,
> + client, NULL);

Doing this on every mapping call sounds expensive..

> + if (WARN_ON_ONCE(dist & P2PDMA_NOT_SUPPORTED))
> + return 0;
> +
> + if (dist & P2PDMA_THRU_HOST_BRIDGE)
> + return dma_map_sg_attrs(dev, sg, nents, dir, attrs);
> + else
> + return __pci_p2pdma_map_sg(pgmap, dev, sg, nents);

Can't we organize the values so that we can switch on the return
value instead of doing flag checks?

>  }
>  EXPORT_SYMBOL_GPL(pci_p2pdma_map_sg_attrs);
>  
> @@ -847,6 +861,21 @@ EXPORT_SYMBOL_GPL(pci_p2pdma_map_sg_attrs);
>  void pci_p2pdma_unmap_sg_attrs(struct device *dev, struct scatterlist *sg,
>   int nents, enum dma_data_direction dir, unsigned long attrs)
>  {
> + struct dev_pagemap *pgmap = sg_page(sg)->pgmap;
> + struct pci_dev *client;
> + int dist;
> +
> + client = find_parent_pci_dev(dev);
> + if (!client)
> + return;
> +
> + dist = upstream_bridge_distance(pgmap->pci_p2pdma_provider,
> + client, NULL);

And then we do it for every unmap again..

Re: [PATCH 14/14] PCI/P2PDMA: Introduce pci_p2pdma_[un]map_resource()

[Christoph Hellwig]

> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index baf476039396..20c834cfd2d3 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -874,6 +874,91 @@ void pci_p2pdma_unmap_sg_attrs(struct device *dev, 
> struct scatterlist *sg,
>  }
>  EXPORT_SYMBOL_GPL(pci_p2pdma_unmap_sg_attrs);
>  
> +static pci_bus_addr_t pci_p2pdma_phys_to_bus(struct pci_dev *dev,
> + phys_addr_t start, size_t size)
> +{
> + struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
> + phys_addr_t end = start + size;
> + struct resource_entry *window;
> +
> + resource_list_for_each_entry(window, >windows) {
> + if (window->res->start <= start && window->res->end >= end)
> + return start - window->offset;
> + }
> +
> + return DMA_MAPPING_ERROR;

This does once again look very expensive for something called in the
hot path.

Re: + mm-oom-avoid-printk-iteration-under-rcu.patch added to -mm tree

[Michal Hocko]

[ups, I've cut the Cc list somehow, sorry about that]

On Wed 24-07-19 08:27:27, Michal Hocko wrote:
> Andrew,
> I've had some concerns wrt. this patch - especially the additional
> complexity - and I have to say I am not convinced that this is really
> needed. Our past experience in this area suggests that more tricky code
> leads to different corner cases. So I am really reluctant to add more
> complexity without any real world reports.
> 
> On Tue 23-07-19 16:14:29, Andrew Morton wrote:
> > From: Tetsuo Handa 
> > Subject: mm, oom: avoid printk() iteration under RCU
> > 
> > Currently dump_tasks() might call printk() for many thousands times under
> > RCU, which might take many minutes for slow consoles.  Therefore, split
> > dump_tasks() into three stages; take a snapshot of possible OOM victim
> > candidates under RCU, dump the snapshot from reschedulable context, and
> > destroy the snapshot.
> > 
> > In a future patch, the first stage would be moved to select_bad_process()
> > and the third stage would be moved to after oom_kill_process(), and will
> > simplify refcount handling.
> > 
> > Link: 
> > http://lkml.kernel.org/r/1563360901-8277-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
> > Signed-off-by: Tetsuo Handa 
> > Cc: Shakeel Butt 
> > Cc: Michal Hocko 
> > Cc: Roman Gushchin 
> > Cc: David Rientjes 
> > Signed-off-by: Andrew Morton 
> > ---
> > 
> >  include/linux/sched.h |1 
> >  mm/oom_kill.c |   67 +++-
> >  2 files changed, 34 insertions(+), 34 deletions(-)
> > 
> > --- a/include/linux/sched.h~mm-oom-avoid-printk-iteration-under-rcu
> > +++ a/include/linux/sched.h
> > @@ -1246,6 +1246,7 @@ struct task_struct {
> >  #ifdef CONFIG_MMU
> > struct task_struct  *oom_reaper_list;
> >  #endif
> > +   struct list_headoom_victim_list;
> >  #ifdef CONFIG_VMAP_STACK
> > struct vm_struct*stack_vm_area;
> >  #endif
> > --- a/mm/oom_kill.c~mm-oom-avoid-printk-iteration-under-rcu
> > +++ a/mm/oom_kill.c
> > @@ -377,36 +377,13 @@ static void select_bad_process(struct oo
> > }
> >  }
> >  
> > -static int dump_task(struct task_struct *p, void *arg)
> > -{
> > -   struct oom_control *oc = arg;
> > -   struct task_struct *task;
> > -
> > -   if (oom_unkillable_task(p))
> > -   return 0;
> >  
> > -   /* p may not have freeable memory in nodemask */
> > -   if (!is_memcg_oom(oc) && !oom_cpuset_eligible(p, oc))
> > -   return 0;
> > -
> > -   task = find_lock_task_mm(p);
> > -   if (!task) {
> > -   /*
> > -* This is a kthread or all of p's threads have already
> > -* detached their mm's.  There's no need to report
> > -* them; they can't be oom killed anyway.
> > -*/
> > -   return 0;
> > +static int add_candidate_task(struct task_struct *p, void *arg)
> > +{
> > +   if (!oom_unkillable_task(p)) {
> > +   get_task_struct(p);
> > +   list_add_tail(>oom_victim_list, (struct list_head *) arg);
> > }
> > -
> > -   pr_info("[%7d] %5d %5d %8lu %8lu %8ld %8lu %5hd %s\n",
> > -   task->pid, from_kuid(_user_ns, task_uid(task)),
> > -   task->tgid, task->mm->total_vm, get_mm_rss(task->mm),
> > -   mm_pgtables_bytes(task->mm),
> > -   get_mm_counter(task->mm, MM_SWAPENTS),
> > -   task->signal->oom_score_adj, task->comm);
> > -   task_unlock(task);
> > -
> > return 0;
> >  }
> >  
> > @@ -422,19 +399,41 @@ static int dump_task(struct task_struct
> >   */
> >  static void dump_tasks(struct oom_control *oc)
> >  {
> > -   pr_info("Tasks state (memory values in pages):\n");
> > -   pr_info("[  pid  ]   uid  tgid total_vm  rss pgtables_bytes 
> > swapents oom_score_adj name\n");
> > +   static LIST_HEAD(list);
> > +   struct task_struct *p;
> > +   struct task_struct *t;
> >  
> > if (is_memcg_oom(oc))
> > -   mem_cgroup_scan_tasks(oc->memcg, dump_task, oc);
> > +   mem_cgroup_scan_tasks(oc->memcg, add_candidate_task, );
> > else {
> > -   struct task_struct *p;
> > -
> > rcu_read_lock();
> > for_each_process(p)
> > -   dump_task(p, oc);
> > +   add_candidate_task(p, );
> > rcu_read_unlock();
> > }
> > +   pr_info("Tasks state (memory values in pages):\n");
> > +   pr_info("[  pid  ]   uid  tgid total_vm  rss pgtables_bytes 
> > swapents oom_score_adj name\n");
> > +   list_for_each_entry(p, , oom_victim_list) {
> > +   cond_resched();
> > +   /* p may not have freeable memory in nodemask */
> > +   if (!is_memcg_oom(oc) && !oom_cpuset_eligible(p, oc))
> > +   continue;
> > +   /* All of p's threads might have already detached their mm's. */
> > +   t = find_lock_task_mm(p);
> > +   if (!t)
> > +   continue;
> > +   pr_info("[%7d] %5d %5d %8lu %8lu %8ld %8lu 

[PATCH] clk: imx: Remove unused function statement

[Anson . Huang]

From: Anson Huang 

imx_register_uart_clocks_hws() function is NOT implemented
at all, remove it.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
index 9995f2a..f7a389a 100644
--- a/drivers/clk/imx/clk.h
+++ b/drivers/clk/imx/clk.h
@@ -10,7 +10,6 @@ extern spinlock_t imx_ccm_lock;
 void imx_check_clocks(struct clk *clks[], unsigned int count);
 void imx_check_clk_hws(struct clk_hw *clks[], unsigned int count);
 void imx_register_uart_clocks(struct clk ** const clks[]);
-void imx_register_uart_clocks_hws(struct clk_hw ** const hws[]);
 void imx_mmdc_mask_handshake(void __iomem *ccm_base, unsigned int chn);
 void imx_unregister_clocks(struct clk *clks[], unsigned int count);
 
-- 
2.7.4

Re: [PATCH v4 2/3] treewide: Remove dev_err() usage after platform_get_irq()

[Greg Kroah-Hartman]

On Tue, Jul 23, 2019 at 11:16:23AM -0700, Stephen Boyd wrote:
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 9b2232908b65..40e4e8e03428 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -1088,7 +1088,6 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
>  
>   irq = platform_get_irq(pdev, 0);
>   if (irq < 0) {
> - dev_err(>dev, "Can't retrieve our interrupt\n");
>   return irq;
>   }
>  

Just one example here, but you really want to remove those { } now as
well.

That's in this patch a lot, so as-is, I don't think this is ok, sorry.

greg k-h

Re: Reminder: 99 open syzbot bugs in net subsystem

[Eric Dumazet]

On 7/24/19 3:38 AM, Eric Biggers wrote:
> [This email was generated by a script.  Let me know if you have any 
> suggestions
> to make it better, or if you want it re-generated with the latest status.]
> 
> Of the currently open syzbot reports against the upstream kernel, I've 
> manually
> marked 99 of them as possibly being bugs in the net subsystem.  This category
> only includes the networking bugs that I couldn't assign to a more specific
> component (bpf, xfrm, bluetooth, tls, tipc, sctp, wireless, etc.).  I've 
> listed
> these reports below, sorted by an algorithm that tries to list first the 
> reports
> most likely to be still valid, important, and actionable.
> 
> Of these 99 bugs, 17 were seen in mainline in the last week.
> 
> Of these 99 bugs, 4 were bisected to commits from the following people:
> 
>   Florian Westphal 
>   Ilya Maximets 
>   Eric Dumazet 
>   David Ahern 
> 
> If you believe a bug is no longer valid, please close the syzbot report by
> sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
> original thread, as explained at https://goo.gl/tpsmEJ#status
> 
> If you believe I misattributed a bug to the net subsystem, please let me know,
> and if possible forward the report to the correct people or mailing list.
>

Some of the bugs have been fixed already, before syzbot found them.

Why force human to be gentle to bots and actually replying to them ?

I usually simply wait that syzbot is finding the bug does not repro anymore,
but now if you send these emails, we will have even more pressure on us.

Re: [alsa-devel] [PATCH 01/10] ASoC: fsl_sai: add of_match data

[Daniel Baluta]

On Tue, Jul 23, 2019 at 8:01 PM Mark Brown  wrote:
>
> On Mon, Jul 22, 2019 at 03:48:24PM +0300, Daniel Baluta wrote:
> > From: Lucas Stach 
> >
> > New revisions of the SAI IP block have even more differences that need
> > be taken into account by the driver. To avoid sprinking compatible
> > checks all over the driver move the current differences into of_match_data.
> >
> > Signed-off-by: Lucas Stach 
> > ---
> >  sound/soc/fsl/fsl_sai.c | 22 ++
>
> You need to supply your own signoff if you're sending someone else's
> patch - see submitting-patches.rst for details on what signoffs mean and
> why they're required.

Ack. Sorry for missing this.

Re: [PATCH v12 1/5] can: m_can: Create a m_can platform framework

[Greg KH]

On Tue, Jul 23, 2019 at 10:14:14AM -0500, Dan Murphy wrote:
> Hello
> 
> On 7/10/19 7:08 AM, Dan Murphy wrote:
> > Hello
> > 
> > On 6/17/19 10:09 AM, Dan Murphy wrote:
> > > Marc
> > > 
> > > On 6/10/19 11:35 AM, Dan Murphy wrote:
> > > > Bump
> > > > 
> > > > On 6/6/19 8:16 AM, Dan Murphy wrote:
> > > > > Marc
> > > > > 
> > > > > Bump
> > > > > 
> > > > > On 5/31/19 6:51 AM, Dan Murphy wrote:
> > > > > > Marc
> > > > > > 
> > > > > > On 5/15/19 3:54 PM, Dan Murphy wrote:
> > > > > > > Marc
> > > > > > > 
> > > > > > > On 5/9/19 11:11 AM, Dan Murphy wrote:
> > > > > > > > Create a m_can platform framework that peripheral
> > > > > > > > devices can register to and use common code and register sets.
> > > > > > > > The peripheral devices may provide read/write and configuration
> > > > > > > > support of the IP.
> > > > > > > > 
> > > > > > > > Acked-by: Wolfgang Grandegger 
> > > > > > > > Signed-off-by: Dan Murphy 
> > > > > > > > ---
> > > > > > > > 
> > > > > > > > v12 - Update the m_can_read/write functions to
> > > > > > > > create a backtrace if the callback
> > > > > > > > pointer is NULL. - 
> > > > > > > > https://lore.kernel.org/patchwork/patch/1052302/
> > > > > > > > 
> > > > > > > Is this able to be merged now?
> > > > > > 
> > > > > > ping
> > > 
> > > Wondering if there is anything else we need to do?
> > > 
> > > The part has officially shipped and we had hoped to have driver
> > > support in Linux as part of the announcement.
> > > 
> > Is this being sent in a PR for 5.3?
> > 
> > Dan
> > 
> Adding Greg to this thread as I have no idea what is going on with this. 

Why me?  What am I supposed to do here?  I see no patches at all to do
anything with :(

thanks,

greg "not a miracle worker" k-h

Re: [PATCH 5/8] ARM: dts: Drop bogus ahclkr clocks for dra7 mcasp 3 to 8

[Tony Lindgren]

* Suman Anna  [190723 21:02]:
> Hi Tony,
> 
> On 7/23/19 6:28 AM, Tony Lindgren wrote:
> > The ahclkr clkctrl clock bit 28 only exists for mcasp 1 and 2 on dra7.
> > Otherwise we get the following warning on beagle-x15:
...
> > @@ -2962,9 +2958,8 @@
> > ;
> > /* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
> > clocks = <_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 0>,
> > -<_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 
> > 24>,
> > -<_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 
> > 28>;
> > -   clock-names = "fck", "ahclkx", "ahclkr";
> > +<_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 
> > 24>;
> > +   clock-names = "fck", "ahclkx";
> 
> The equivalent change to MCASP8 is missing.

Thanks for spotting it, probably should be set up the same way as
MCASP4 too looking at the TRM.

Tero, care to check the dra7 mcasp clocks we have defined?

$ grep MCASP drivers/clk/ti/clk-7xx.c
{ DRA7_IPU_MCASP1_CLKCTRL, dra7_mcasp1_bit_data, CLKF_SW_SUP, 
"ipu-clkctrl::22" },
{ DRA7_L4PER2_MCASP2_CLKCTRL, dra7_mcasp2_bit_data, CLKF_SW_SUP, 
"l4per2-clkctrl:0154:22" },
{ DRA7_L4PER2_MCASP3_CLKCTRL, dra7_mcasp3_bit_data, CLKF_SW_SUP, 
"l4per2-clkctrl:015c:22" },
{ DRA7_L4PER2_MCASP5_CLKCTRL, dra7_mcasp5_bit_data, CLKF_SW_SUP, 
"l4per2-clkctrl:016c:22" },
{ DRA7_L4PER2_MCASP8_CLKCTRL, dra7_mcasp8_bit_data, CLKF_SW_SUP, 
"l4per2-clkctrl:0184:24" },
{ DRA7_L4PER2_MCASP4_CLKCTRL, dra7_mcasp4_bit_data, CLKF_SW_SUP, 
"l4per2-clkctrl:018c:22" },
{ DRA7_L4PER2_MCASP6_CLKCTRL, dra7_mcasp6_bit_data, CLKF_SW_SUP, 
"l4per2-clkctrl:01f8:22" },
{ DRA7_L4PER2_MCASP7_CLKCTRL, dra7_mcasp7_bit_data, CLKF_SW_SUP, 
"l4per2-clkctrl:01fc:22" },

Is bit 24 above correct for MCASP8 or should it too be 22 like
adjacent MCASP4 in the TRM?

Regards,

Tony

Re: [PATCH v2 3/6] pwm: jz4740: Apply configuration atomically

[Uwe Kleine-König]

Hello Paul,

On Tue, Jul 23, 2019 at 04:46:40PM -0400, Paul Cercueil wrote:
> Le lun. 22 juil. 2019 à 15:34, Uwe =?iso-8859-1?q?Kleine-K=F6nig?=
>  a écrit :
> > On Fri, Jun 07, 2019 at 05:44:07PM +0200, Paul Cercueil wrote:
> > >  -is_enabled = jz4740_timer_is_enabled(pwm->hwpwm);
> > >  -if (is_enabled)
> > >  -jz4740_pwm_disable(chip, pwm);
> > >  +jz4740_pwm_disable(chip, pwm);
> > 
> > I assume this stops the PWM. Does this complete the currently running
> > period? How does the PWM behave then? (Does it still drive the output?
> > If so, on which level?)
> 
> Some PWM channels work in one mode "TCU1" and others work in "TCU2". The
> mode in which channels work depends on the version of the SoC.
> 
> When stopped, the pins of TCU1 channels will be driven to the inactive
> level (which depends on the polarity). It is unknown whether or not the
> currently running period is completed. We set a bit to configure for
> "abrupt shutdown", so I expect that it's not, but somebody would need
> to hook up a logic analyzer to see what's the exact behaviour with
> and without that bit.

This might be done even without a logic analyzer. Just do something
like:

pwm_apply_state(pwm, { .enabled = 1, .period = 5s })
pwm_apply_state(pwm, { .enabled = 1, .period = 5s, .duty = 5s })

and if that takes less then 5s the period is not completed.

And note that "abrupt shutdown" is a bug.

> TCU2 channels on the other hand will stop in the middle of a period,
> leaving the pin hanging at whatever level it was before the stop.
> That's the rationale behind the trick in commit 6580fd173070 ("pwm:
> jz4740: Force TCU2 channels to return to their init level").

Strange, but ok.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH] arm64: dts: meson: odroid-n2: keep SD card regulator always on

[Neil Armstrong]

Hi Anand,

On 24/07/2019 07:30, Anand Moon wrote:
> Hi All,
> 
> On Mon, 22 Jul 2019 at 12:51, Neil Armstrong  wrote:
>>
>> On 19/07/2019 21:29, Xavier Ruppen wrote:
>>> When powering off the Odroid N2, the tflash_vdd regulator is
>>> automatically turned off by the kernel. This is a problem
>>> when issuing the "reboot" command while using an SD card.
>>> The boot ROM does not power this regulator back on, blocking
>>> the reboot process at the boot ROM stage, preventing the
>>> SD card from being detected.
>>>
>>> Adding the "regulator-always-on" property fixes the problem.
>>>
>>> Signed-off-by: Xavier Ruppen 
>>> ---
>>>
>>> Here is what the boot ROM output looks like without this patch:
>>>
>>> [root@alarm ~]# reboot
>>> [...]
>>> [   24.275860] shutdown[1]: All loop devices detached.
>>> [   24.278864] shutdown[1]: Detaching DM devices.
>>> [   24.287105] kvm: exiting hardware virtualization
>>> [   24.318776] reboot: Restarting system
>>> bl31 reboot reason: 0xd
>>> bl31 reboot reason: 0x0
>>> system cmd  1.
>>> G12B:BL:6e7c85:7898ac;FEAT:E0F83180:2000;POC:F;RCY:0;
>>> EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:1;EMMC:800;
>>> NAND:81;SD?:0;SD:400;USB:8;LOOP:2;EMMC:800;NAND:81;
>>> SD?:0;SD:400;USB:8;LOOP:3; [...]
>>>
>>> Other people can be seen having this problem on the odroid
>>> forum [1].
>>>
>>> The cause of the problem was found by Martin Blumenstingl
>>> on #linux-amlogic. We may want to add his Suggested-by tag
>>> if he agrees.
>>>
>>> [1] https://forum.odroid.com/viewtopic.php?f=176=33993
>>>
>>>  arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts 
>>> b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
>>> index 81780ffcc7f0..4e916e1f71f7 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
>>> @@ -53,6 +53,7 @@
>>>
>>>   gpio = <_ao GPIOAO_8 GPIO_ACTIVE_HIGH>;
>>>   enable-active-high;
>>> + regulator-always-on;
>>>   };
>>>
>>>   tf_io: gpio-regulator-tf_io {
>>>
>>
>> Surely solves the situation, thanks !
>>
>> please add a comment on top of "regulator-always-on" to explain why we 
>> always enable it,
>> note we should always enable it in case of watchdog reboot or other 
>> uncontrolled reset,
>> this regulator must never be disabled.
>>
>> Reviewed-by: Neil Armstrong 
>>
>> Thanks,
>> Neil
>>
> 
> I am afraid this did not fix the issue I was also facing with
> Archlinux on Odroid N2 using mainline u-boot.

Seems to be a separate issue, could we start a separate thread with all your
setup (branch, git SHAa, configs, board setup, ...) for this ?

Thanks,
Neil

> Here is the log of at my end using latest mainline u-boot with Neil's patches.
> 
> [0] https://pastebin.com/HNmeY5uF
> 
> Well this issue also persist with eMMC not getting detected after reboot
> If I try to change the dts to fix the sdcard.
> 
> I am checking this should we enable regulator-boot-on option but still no 
> luck.
> 
> Best Regards
> -Anand
> 

Re: Warning seen when removing a module using irqdomain framework

[Marc Zyngier]

On Tue, 23 Jul 2019 14:52:34 -0700
pher...@codeaurora.org wrote:

Hi Prakruthi,

> Hi,
> 
> I have been working on a interrupt controller driver that uses tree
> based mapping for its domain (irq_domain_add_tree(..)).
> If I understand correctly, the clients get a mapping when they call
> platform_get_irq(..). However, after these clients are removed
> (rmmod), when I try to remove the interrupt controller driver where
> it calls irq_domain_remove(..), I hit this warning from
> kernel/kernel/irq/irqdomain.c:: irq_domain_remove(..)
> [WARN_ON(!radix_tree_empty(>revmap_tree));]-
> WARNING: CPU: 0 PID: 238 at /kernel/kernel/irq/irqdomain.c:246 
> irq_domain_remove+0x84/0x98
> 
> Also, I see that the requested IRQs by the clients are still present
> (in /proc/interrupts) even after they had been removed. Hence, I just
> wanted to know how to handle this warning. Should the client clean up
> by calling irq_dispose_mapping(..) or is it the responsibility of the
> interrupt controller driver to dispose the mappings one by one?

In general, building interrupt controller drivers as a module is a
pretty difficult thing to do in a safe manner. As you found out, this
relies on the irq_domain being "emptied" before it can be freed. There
are some other gotchas in the rest of the IRQ stack as well.

Doing that is hard. One of the reasons is that the OF subsystem will
happily allocate all the interrupts it can even if there is no driver
having requested them (see of_platform_populate). This means that you
cannot track whether a client driver is using one of the interrupt your
irqchip is in charge of. You can apply some heuristics, but they are in
general all wrong.

Fixing the OF subsystem is possible, but will break a lot of platforms
that will have to be identified and fixed one by one.  Another
possibility would be to refcount irqdescs, and make sure the irqdomain
directly holds pointers to them. Doable, but may create overhead.

To sum it up, don't build your irqchip driver as a module if you can
avoid it. If you can't, you'll have to be very careful about how the
mapping is established (make sure it is not created by
of_platform_populate), and use irq_dispose_mapping in the client
drivers.

Hope this helps,

M.
-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH 2/2] mm/hmm: make full use of walk_page_range()

[Christoph Hellwig]

On Tue, Jul 23, 2019 at 04:30:16PM -0700, Ralph Campbell wrote:
> hmm_range_snapshot() and hmm_range_fault() both call find_vma() and
> walk_page_range() in a loop. This is unnecessary duplication since
> walk_page_range() calls find_vma() in a loop already.
> Simplify hmm_range_snapshot() and hmm_range_fault() by defining a
> walk_test() callback function to filter unhandled vmas.

I like the approach a lot!

But we really need to sort out the duplication between hmm_range_fault
and hmm_range_snapshot first, as they are basically the same code.  I
have patches here:

http://git.infradead.org/users/hch/misc.git/commitdiff/a34ccd30ee8a8a3111d9e91711c12901ed7dea74

http://git.infradead.org/users/hch/misc.git/commitdiff/81f442ebac7170815af7770a1efa9c4ab662137e

That being said we don't really have any users for the snapshot mode
or non-blocking faults, and I don't see any in the immediate pipeline
either.  It might actually be a better idea to just kill that stuff off
for now until we have a user, as code without users is per definition
untested and will just bitrot and break.

> + const unsigned long device_vma = VM_IO | VM_PFNMAP | VM_MIXEDMAP;
> + struct hmm_vma_walk *hmm_vma_walk = walk->private;
> + struct hmm_range *range = hmm_vma_walk->range;
> + struct vm_area_struct *vma = walk->vma;
> +
> + /* If range is no longer valid, force retry. */
> + if (!range->valid)
> + return -EBUSY;
> +
> + if (vma->vm_flags & device_vma)

Can we just kill off this odd device_vma variable?

if (vma->vm_flags & (VM_IO | VM_PFNMAP | VM_MIXEDMAP))

and maybe add a comment on why we are skipping them (because they
don't have struct page backing I guess..)

Re: [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms

[Rasmus Villemoes]

On 23/07/2019 17.39, Joe Perches wrote:
> On Tue, 2019-07-23 at 16:37 +0200, Rasmus Villemoes wrote:
>> On 23/07/2019 15.51, Joe Perches wrote:
>>>
>>> These mechanisms verify that the dest argument is an array of
>>> char or other compatible types like u8 or s8 or equivalent.
>> Sorry, but "compatible types" has a very specific meaning in C, so
>> please don't use that word.
> 
> I think you are being overly pedantic here but
> what wording do you actually suggest?

I'd just not support anything other than char[], but if you want,
perhaps say "related types", or some other informal description.

>>  And yes, the kernel disables -Wpointer-sign,
>> so passing an u8* or s8* when strscpy() expects a char* is silently
>> accepted, but does such code exist?
> 
> u8 definitely, s8 I'm not sure.

Example (i.e. of someone passing an u8* as destination to some string
copy/formatting function)? I believe you, I'd just like to see the context.

> I don't find via grep a use of s8 foo[] = "bar";
> or "signed char foo[] = "bar";
> 
> I don't think it bad to allow it.

Your patch.

>> count is just as bad as size in terms of "the expression src might
>> contain that identifier". But there's actually no reason to even declare
>> a local variable, just use ARRAY_SIZE() directly as the third argument
>> to strscpy().
> 
> I don't care about that myself.
> It's a macro local identifier and shadowing in a macro
> is common.  I'm not a big fan of useless underscores.

shadowing is not the problem. The identifier "count" appearing in one of
the "dest" or "src" expressions is. For something that's supposed to
help eliminate bugs, such a hidden footgun seems to be a silly thing to
include. No need for some hideous triple-underscore variable, just make
the whole thing

BUILD_BUG_ON(!__same_type())
strscpy(dst, src, ARRAY_SIZE(dst))

Rasmus

Re: [Sound-open-firmware] [PATCH v2 1/5] ASoC: SOF: imx: Add i.MX8 HW support

[Daniel Baluta]

On Tue, Jul 23, 2019 at 6:18 PM Pierre-Louis Bossart
 wrote:
>
>
> > diff --git a/sound/soc/sof/imx/Makefile b/sound/soc/sof/imx/Makefile
> > new file mode 100644
> > index ..c69237971da5
> > --- /dev/null
> > +++ b/sound/soc/sof/imx/Makefile
> > @@ -0,0 +1,7 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> > +
> > +ccflags-y += -DDEBUG
>
> this should be removed or in a separate patch.

All right.

>
>
> > +struct imx8_priv {
> > + struct device *dev;
> > + struct snd_sof_dev *sdev;
> > + struct imx_dsp_ipc *dsp_ipc;
> > + struct imx_sc_ipc *sc_ipc;
>
> maybe a comment to explain what 'sc' stands for?

Sure.
>
> > +};
> > +
> > +static void imx8_get_windows(struct snd_sof_dev *sdev)
> > +{
> > + struct sof_ipc_window_elem *elem;
> > + u32 outbox_offset = 0;
> > + u32 stream_offset = 0;
> > + u32 inbox_offset = 0;
> > + u32 outbox_size = 0;
> > + u32 stream_size = 0;
> > + u32 inbox_size = 0;
> > + int i;
> > +
> > + if (!sdev->info_window) {
> > + dev_err(sdev->dev, "error: have no window info\n");
> > + return;
> > + }
> > +
> > + for (i = 0; i < sdev->info_window->num_windows; i++) {
> > + elem = >info_window->window[i];
> > +
> > + switch (elem->type) {
> > + case SOF_IPC_REGION_UPBOX:
> > + inbox_offset = elem->offset + MBOX_OFFSET;
> > + inbox_size = elem->size;
> > + snd_sof_debugfs_io_item(sdev,
> > + 
> > sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> > + + inbox_offset,
> > + elem->size, "inbox",
> > + SOF_DEBUGFS_ACCESS_D0_ONLY);
> > + break;
> > + case SOF_IPC_REGION_DOWNBOX:
> > + outbox_offset = elem->offset + MBOX_OFFSET;
> > + outbox_size = elem->size;
> > + snd_sof_debugfs_io_item(sdev,
> > + 
> > sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> > + + outbox_offset,
> > + elem->size, "outbox",
> > + SOF_DEBUGFS_ACCESS_D0_ONLY);
> > + break;
> > + case SOF_IPC_REGION_TRACE:
> > + snd_sof_debugfs_io_item(sdev,
> > + 
> > sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> > + + elem->offset + MBOX_OFFSET,
> > + elem->size, "etrace",
> > + SOF_DEBUGFS_ACCESS_D0_ONLY);
> > + break;
> > + case SOF_IPC_REGION_DEBUG:
> > + snd_sof_debugfs_io_item(sdev,
> > + 
> > sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> > + + elem->offset + MBOX_OFFSET,
> > + elem->size, "debug",
> > + SOF_DEBUGFS_ACCESS_D0_ONLY);
> > + break;
> > + case SOF_IPC_REGION_STREAM:
> > + stream_offset = elem->offset + MBOX_OFFSET;
> > + stream_size = elem->size;
> > + snd_sof_debugfs_io_item(sdev,
> > + 
> > sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> > + + stream_offset,
> > + elem->size, "stream",
> > + SOF_DEBUGFS_ACCESS_D0_ONLY);
> > + break;
> > + case SOF_IPC_REGION_REGS:
> > + snd_sof_debugfs_io_item(sdev,
> > + 
> > sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> > + + elem->offset + MBOX_OFFSET,
> > + elem->size, "regs",
> > + SOF_DEBUGFS_ACCESS_D0_ONLY);
> > + break;
> > + case SOF_IPC_REGION_EXCEPTION:
> > + sdev->dsp_oops_offset = elem->offset + MBOX_OFFSET;
> > + snd_sof_debugfs_io_item(sdev,
> > + 
> > sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> > + + elem->offset + MBOX_OFFSET,
> > + elem->size, "exception",
> > + SOF_DEBUGFS_ACCESS_D0_ONLY);
> > + break;
> > + default:
> > + dev_err(sdev->dev, "error: get illegal window 
> > info\n");
> > 

[PATCH] RDMA/hns: Fix build error

[YueHaibing]

If INFINIBAND_HNS_HIP08 is selected and HNS3 is m,
but INFINIBAND_HNS is y, building fails:

drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function `hns_roce_hw_v2_exit':
hns_roce_hw_v2.c:(.exit.text+0xd): undefined reference to 
`hnae3_unregister_client'
drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function `hns_roce_hw_v2_init':
hns_roce_hw_v2.c:(.init.text+0xd): undefined reference to 
`hnae3_register_client'

Also if INFINIBAND_HNS_HIP06 is selected and HNS_DSAF
is m, but INFINIBAND_HNS is y, building fails:

drivers/infiniband/hw/hns/hns_roce_hw_v1.o: In function `hns_roce_v1_reset':
hns_roce_hw_v1.c:(.text+0x39fa): undefined reference to `hns_dsaf_roce_reset'
hns_roce_hw_v1.c:(.text+0x3a25): undefined reference to `hns_dsaf_roce_reset'

Reported-by: Hulk Robot 
Fixes: dd74282df573 ("RDMA/hns: Initialize the PCI device for hip08 RoCE")
Fixes: 08805fdbeb2d ("RDMA/hns: Split hw v1 driver from hns roce driver")
Signed-off-by: YueHaibing 
---
 drivers/infiniband/hw/hns/Kconfig  | 6 +++---
 drivers/infiniband/hw/hns/Makefile | 8 ++--
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/infiniband/hw/hns/Kconfig 
b/drivers/infiniband/hw/hns/Kconfig
index 8bf847b..5478219 100644
--- a/drivers/infiniband/hw/hns/Kconfig
+++ b/drivers/infiniband/hw/hns/Kconfig
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config INFINIBAND_HNS
-   tristate "HNS RoCE Driver"
+   bool "HNS RoCE Driver"
depends on NET_VENDOR_HISILICON
depends on ARM64 || (COMPILE_TEST && 64BIT)
---help---
@@ -11,7 +11,7 @@ config INFINIBAND_HNS
  To compile HIP06 or HIP08 driver as module, choose M here.
 
 config INFINIBAND_HNS_HIP06
-   bool "Hisilicon Hip06 Family RoCE support"
+   tristate "Hisilicon Hip06 Family RoCE support"
depends on INFINIBAND_HNS && HNS && HNS_DSAF && HNS_ENET
---help---
  RoCE driver support for Hisilicon RoCE engine in Hisilicon Hip06 and
@@ -21,7 +21,7 @@ config INFINIBAND_HNS_HIP06
  module will be called hns-roce-hw-v1
 
 config INFINIBAND_HNS_HIP08
-   bool "Hisilicon Hip08 Family RoCE support"
+   tristate "Hisilicon Hip08 Family RoCE support"
depends on INFINIBAND_HNS && PCI && HNS3
---help---
  RoCE driver support for Hisilicon RoCE engine in Hisilicon Hip08 SoC.
diff --git a/drivers/infiniband/hw/hns/Makefile 
b/drivers/infiniband/hw/hns/Makefile
index e105945..449a2d8 100644
--- a/drivers/infiniband/hw/hns/Makefile
+++ b/drivers/infiniband/hw/hns/Makefile
@@ -9,12 +9,8 @@ hns-roce-objs := hns_roce_main.o hns_roce_cmd.o hns_roce_pd.o \
hns_roce_ah.o hns_roce_hem.o hns_roce_mr.o hns_roce_qp.o \
hns_roce_cq.o hns_roce_alloc.o hns_roce_db.o hns_roce_srq.o 
hns_roce_restrack.o
 
-ifdef CONFIG_INFINIBAND_HNS_HIP06
 hns-roce-hw-v1-objs := hns_roce_hw_v1.o $(hns-roce-objs)
-obj-$(CONFIG_INFINIBAND_HNS) += hns-roce-hw-v1.o
-endif
+obj-$(CONFIG_INFINIBAND_HNS_HIP06) += hns-roce-hw-v1.o
 
-ifdef CONFIG_INFINIBAND_HNS_HIP08
 hns-roce-hw-v2-objs := hns_roce_hw_v2.o hns_roce_hw_v2_dfx.o $(hns-roce-objs)
-obj-$(CONFIG_INFINIBAND_HNS) += hns-roce-hw-v2.o
-endif
+obj-$(CONFIG_INFINIBAND_HNS_HIP08) += hns-roce-hw-v2.o
-- 
2.7.4

Re: [PATCH v2] sys_prctl(): remove unsigned comparision with less than zero

[Cyrill Gorcunov]

On Wed, Jul 24, 2019 at 10:11:48AM +0800, Yang Xu wrote:
> Currently, when calling prctl(PR_SET_TIMERSLACK, arg2), arg2 is an
> unsigned long value, arg2 will never < 0. Negative judgment is
> meaningless, so remove it.
> 
> Fixes: 6976675d9404 ("hrtimer: create a "timer_slack" field in the task 
> struct")
> Signed-off-by: Yang Xu 
> Cc: Cyrill Gorcunov 
Acked-by: Cyrill Gorcunov 

Re: [PATCH V6 RESEND 0/3] arm64/mm: Enable memory hot remove

[Anshuman Khandual]

On 07/23/2019 04:26 PM, Mark Rutland wrote:
> Hi Anshuman,

Hello Mark,

> 
> On Mon, Jul 15, 2019 at 11:47:47AM +0530, Anshuman Khandual wrote:
>> This series enables memory hot remove on arm64 after fixing a memblock
>> removal ordering problem in generic try_remove_memory() and a possible
>> arm64 platform specific kernel page table race condition. This series
>> is based on linux-next (next-20190712).
>>
>> Concurrent vmalloc() and hot-remove conflict:
>>
>> As pointed out earlier on the v5 thread [2] there can be potential conflict
>> between concurrent vmalloc() and memory hot-remove operation. This can be
>> solved or at least avoided with some possible methods. The problem here is
>> caused by inadequate locking in vmalloc() which protects installation of a
>> page table page but not the walk or the leaf entry modification.
>>
>> Option 1: Making locking in vmalloc() adequate
>>
>> Current locking scheme protects installation of page table pages but not the
>> page table walk or leaf entry creation which can conflict with hot-remove.
>> This scheme is sufficient for now as vmalloc() works on mutually exclusive
>> ranges which can proceed concurrently only if their shared page table pages
>> can be created while inside the lock. It achieves performance improvement
>> which will be compromised if entire vmalloc() operation (even if with some
>> optimization) has to be completed under a lock.
>>
>> Option 2: Making sure hot-remove does not happen during vmalloc()
>>
>> Take mem_hotplug_lock in read mode through [get|put]_online_mems() constructs
>> for the entire duration of vmalloc(). It protects from concurrent memory hot
>> remove operation and does not add any significant overhead to other 
>> concurrent
>> vmalloc() threads. It solves the problem in right way unless we do not want 
>> to
>> extend the usage of mem_hotplug_lock in generic MM.
>>
>> Option 3: Memory hot-remove does not free (conflicting) page table pages
>>
>> Don't not free page table pages (if any) for vmemmap mappings after unmapping
>> it's virtual range. The only downside here is that some page table pages 
>> might
>> remain empty and unused until next memory hot-add operation of the same 
>> memory
>> range.
>>
>> Option 4: Dont let vmalloc and vmemmap share intermediate page table pages
>>
>> The conflict does not arise if vmalloc and vmemap range do not share kernel
>> page table pages to start with. If such placement can be ensured in platform
>> kernel virtual address layout, this problem can be successfully avoided.
>>
>> There are two generic solutions (Option 1 and 2) and two platform specific
>> solutions (Options 2 and 3). This series has decided to go with (Option 3)

s/Option 2 and 3/Option 3 and 4/

>> which requires minimum changes while self-contained inside the functionality.
> 
> ... while also leaking memory, right?

This is not a memory leak. In the worst case where an empty page table page 
could
have been freed after parts of it's kernel virtual range span's vmemmap mapping 
has
been taken down still remains attached to the higher level page table entry. 
This
empty page table page will be completely reusable during future vmalloc() 
allocations
or vmemmap mapping for newly hot added memory in overlapping memory range. It 
is just
an empty data structure sticking around which could (probably would) be reused 
later.
This problem will not scale and get worse because its part of kernel page table 
not
user process which could get multiplied. Its a small price we are paying to 
remain
safe from a vmalloc() and memory hot remove potential collisions on the kernel 
page
table. IMHO that is fair enough.

> 
> In my view, option 2 or 4 would have been preferable. Were there

I would say option 2 is the ideal solution where we make sure that each 
vmalloc()
instance is protected against concurrent memory hot remove through a read side 
lock
via [get|put]_online_mems().

Option 4 is very much platform specific and each platform has to make sure that 
they
remain compliant all the time which is not ideal. Its is also an a work around 
which
avoids the problem and does not really fix it.

> specific technical reasons to not go down either of those routes? I'm

Option 2 will require wider agreement as it involves a very critical hot-path 
vmalloc()
which can affect many workloads. IMHO Option 4 is neither optimal and not does 
it solve
the problem correctly. Like this approach it just avoids it but unlike this 
touches upon
another code area.

> not sure that minimizing changes is the right rout given that this same
> problem presumably applies to other architectures, which will need to be
> fixed.

Yes this needs to be fixed but we can get there one step at a time. vmemmap tear
down process can start freeing empty page table pages when this gets solved. But
why should it prevent entire memory hot remove functionality from being 
available.

> 
> Do we know why we aren't seeing issues on other architectures? e.g. 

Re: [PATCH] mm/memory-failure: Poison read receives SIGKILL instead of SIGBUS if mmaped more than once

[Naoya Horiguchi]

Hi Jane, Dan,

On Tue, Jul 23, 2019 at 06:34:35PM -0700, Dan Williams wrote:
> On Tue, Jul 23, 2019 at 4:49 PM Jane Chu  wrote:
> >
> > Mmap /dev/dax more than once, then read the poison location using address
> > from one of the mappings. The other mappings due to not having the page
> > mapped in will cause SIGKILLs delivered to the process. SIGKILL succeeds
> > over SIGBUS, so user process looses the opportunity to handle the UE.
> >
> > Although one may add MAP_POPULATE to mmap(2) to work around the issue,
> > MAP_POPULATE makes mapping 128GB of pmem several magnitudes slower, so
> > isn't always an option.
> >
> > Details -
> >
> > ndctl inject-error --block=10 --count=1 namespace6.0
> >
> > ./read_poison -x dax6.0 -o 5120 -m 2
> > mmaped address 0x7f5bb660
> > mmaped address 0x7f3cf360
> > doing local read at address 0x7f3cf3601400
> > Killed
> >
> > Console messages in instrumented kernel -
> >
> > mce: Uncorrected hardware memory error in user-access at edbe201400
> > Memory failure: tk->addr = 7f5bb6601000
> > Memory failure: address edbe201: call dev_pagemap_mapping_shift
> > dev_pagemap_mapping_shift: page edbe201: no PUD
> > Memory failure: tk->size_shift == 0
> > Memory failure: Unable to find user space address edbe201 in read_poison
> > Memory failure: tk->addr = 7f3cf3601000
> > Memory failure: address edbe201: call dev_pagemap_mapping_shift
> > Memory failure: tk->size_shift = 21
> > Memory failure: 0xedbe201: forcibly killing read_poison:22434 because of 
> > failure to unmap corrupted page
> >   => to deliver SIGKILL
> > Memory failure: 0xedbe201: Killing read_poison:22434 due to hardware memory 
> > corruption
> >   => to deliver SIGBUS
> >
> > Signed-off-by: Jane Chu 
> > ---
> >  mm/memory-failure.c | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index d9cc660..7038abd 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -315,7 +315,6 @@ static void add_to_kill(struct task_struct *tsk, struct 
> > page *p,
> >
> > if (*tkc) {
> > tk = *tkc;
> > -   *tkc = NULL;
> > } else {
> > tk = kmalloc(sizeof(struct to_kill), GFP_ATOMIC);
> > if (!tk) {
> > @@ -331,16 +330,21 @@ static void add_to_kill(struct task_struct *tsk, 
> > struct page *p,
> > tk->size_shift = compound_order(compound_head(p)) + 
> > PAGE_SHIFT;
> >
> > /*
> > -* In theory we don't have to kill when the page was
> > -* munmaped. But it could be also a mremap. Since that's
> > -* likely very rare kill anyways just out of paranoia, but use
> > -* a SIGKILL because the error is not contained anymore.
> > +* Indeed a page could be mmapped N times within a process. And 
> > it's possible
> > +* that not all of those N VMAs contain valid mapping for the page. 
> > In which
> > +* case we don't want to send SIGKILL to the process on behalf of 
> > the VMAs
> > +* that don't have the valid mapping, because doing so will eclipse 
> > the SIGBUS
> > +* delivered on behalf of the active VMA.
> >  */
> > if (tk->addr == -EFAULT || tk->size_shift == 0) {
> > pr_info("Memory failure: Unable to find user space address 
> > %lx in %s\n",
> > page_to_pfn(p), tsk->comm);
> > -   tk->addr_valid = 0;
> > +   if (tk != *tkc)
> > +   kfree(tk);
> > +   return;

The immediate return bypasses list_add_tail() below, so we might lose
the chance of sending SIGBUS to the process.

tk->size_shift is always non-zero for !is_zone_device_page(), so
"tk->size_shift == 0" effectively checks "no mapping on ZONE_DEVICE" now.
As you mention above, "no mapping" doesn't means "invalid address"
so we can drop "tk->size_shift == 0" check from this if-statement.
Going forward in this direction, "tk->addr_valid == 0" is equivalent to
"tk->addr == -EFAULT", so we seems to be able to remove ->addr_valid.
This observation leads me to the following change, does it work for you?

  --- a/mm/memory-failure.c
  +++ b/mm/memory-failure.c
  @@ -199,7 +199,6 @@ struct to_kill {
struct task_struct *tsk;
unsigned long addr;
short size_shift;
  - char addr_valid;
   };
   
   /*
  @@ -324,7 +323,6 @@ static void add_to_kill(struct task_struct *tsk, struct 
page *p,
}
}
tk->addr = page_address_in_vma(p, vma);
  - tk->addr_valid = 1;
if (is_zone_device_page(p))
tk->size_shift = dev_pagemap_mapping_shift(p, vma);
else
  @@ -336,11 +334,9 @@ static void add_to_kill(struct task_struct *tsk, struct 
page *p,
 * likely very rare kill anyways just out of paranoia, but use
 * a SIGKILL because the error is not contained anymore.
 */
  - if (tk->addr == -EFAULT || 

Re: [Sound-open-firmware] [PATCH v2 3/5] ASoC: SOF: Add DT DSP device support

[Daniel Baluta]

On Tue, Jul 23, 2019 at 6:19 PM Pierre-Louis Bossart
 wrote:
>
>
> > diff --git a/sound/soc/sof/Kconfig b/sound/soc/sof/Kconfig
> > index 61b97fc55bb2..2aa3a1cdf60c 100644
> > --- a/sound/soc/sof/Kconfig
> > +++ b/sound/soc/sof/Kconfig
> > @@ -36,6 +36,15 @@ config SND_SOC_SOF_ACPI
> > Say Y if you need this option
> > If unsure select "N".
> >
> > +config SND_SOC_SOF_DT
> > + tristate "SOF DT enumeration support"
> > + select SND_SOC_SOF
> > + select SND_SOC_SOF_OPTIONS
> > + help
> > +   This adds support for Device Tree enumeration. This option is
> > +   required to enable i.MX8 devices.
> > +   Say Y if you need this option. If unsure select "N".
> > +
>
> [snip]
>
> > diff --git a/sound/soc/sof/imx/Kconfig b/sound/soc/sof/imx/Kconfig
> > index fff64a9970f0..fa35994a79c4 100644
> > --- a/sound/soc/sof/imx/Kconfig
> > +++ b/sound/soc/sof/imx/Kconfig
> > @@ -12,6 +12,7 @@ if SND_SOC_SOF_IMX_TOPLEVEL
> >
> >   config SND_SOC_SOF_IMX8
> >   tristate "SOF support for i.MX8"
> > + select SND_SOC_SOF_DT
>
> This looks upside down. You should select SOF_DT first then include the
> NXP stuff.
>
> >   help
> > This adds support for Sound Open Firmware for NXP i.MX8 
> > platforms
> > Say Y if you have such a device.
> > diff --git a/sound/soc/sof/sof-dt-dev.c b/sound/soc/sof/sof-dt-dev.c
> > new file mode 100644
> > index ..31429bbb5c7e
> > --- /dev/null
> > +++ b/sound/soc/sof/sof-dt-dev.c
> > @@ -0,0 +1,159 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> > +//
> > +// Copyright 2019 NXP
> > +//
> > +// Author: Daniel Baluta 
> > +//
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "ops.h"
> > +
> > +extern struct snd_sof_dsp_ops sof_imx8_ops;
> > +
> > +static char *fw_path;
> > +module_param(fw_path, charp, 0444);
> > +MODULE_PARM_DESC(fw_path, "alternate path for SOF firmware.");
> > +
> > +static char *tplg_path;
> > +module_param(tplg_path, charp, 0444);
> > +MODULE_PARM_DESC(tplg_path, "alternate path for SOF topology.");
> > +
> > +/* platform specific devices */
> > +#if IS_ENABLED(CONFIG_SND_SOC_SOF_IMX8)
> > +static struct sof_dev_desc sof_dt_imx8qxp_desc = {
> > + .default_fw_path = "imx/sof",
> > + .default_tplg_path = "imx/sof-tplg",
> > + .nocodec_fw_filename = "sof-imx8.ri",
> > + .nocodec_tplg_filename = "sof-imx8-nocodec.tplg",
> > + .ops = _imx8_ops,
> > +};
> > +#endif
> > +
> > +static const struct dev_pm_ops sof_dt_pm = {
> > + SET_SYSTEM_SLEEP_PM_OPS(snd_sof_suspend, snd_sof_resume)
> > + SET_RUNTIME_PM_OPS(snd_sof_runtime_suspend, snd_sof_runtime_resume,
> > +NULL)
> > +};
> > +
> > +static void sof_dt_probe_complete(struct device *dev)
> > +{
> > + /* allow runtime_pm */
> > + pm_runtime_set_autosuspend_delay(dev, SND_SOF_SUSPEND_DELAY_MS);
> > + pm_runtime_use_autosuspend(dev);
> > + pm_runtime_enable(dev);
> > +}
> > +
> > +static int sof_dt_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = >dev;
> > + const struct sof_dev_desc *desc;
> > + /*TODO: create a generic snd_soc_xxx_mach */
> > + struct snd_soc_acpi_mach *mach;
>
> I wonder if you really need to use the same structures. For Intel we get
> absolutely zero info from the firmware so rely on an ACPI codec ID as a
> key to find information on which firmware and topology to use, and which
> machine driver to load. You could have all this information in a DT blob?

Yes. I see your point. I will still need to make a generic structure for
snd_soc_acpi_mach so that everyone can use sof_nocodec_setup function.

Maybe something like this:

struct snd_soc_mach {
  union {
  struct snd_soc_acpi_mach acpi_mach;
  struct snd_soc_of_mach of_mach;
  }
};

and then change the prototype of sof_nocodec_setup.

Re: [PATCH] clk: imx: Remove unused function statement

[Uwe Kleine-König]

Hello,

On Wed, Jul 24, 2019 at 02:24:35PM +0800, anson.hu...@nxp.com wrote:
> From: Anson Huang 
> 
> imx_register_uart_clocks_hws() function is NOT implemented
> at all, remove it.
> 
> Signed-off-by: Anson Huang 

Looks right. This function never existed, the prototype was introduced
in commit dd1a6c0d339b ("clk: imx: clk-busy: Switch to clk_hw based
API") in the 5.3-rc1 cycle.

Acked-by: Uwe Kleine-König 

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: KASAN: use-after-free Read in finish_task_switch (2)

[Jason Wang]

On 2019/7/20 上午12:34, syzbot wrote:

syzbot has bisected this bug to:

commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
Author: Jason Wang 
Date:   Fri May 24 08:12:18 2019 +

    vhost: access vq metadata through kernel virtual address

bisection log: 
https://syzkaller.appspot.com/x/bisect.txt?x=123faf7060
start commit:   22051d9c Merge tag 'platform-drivers-x86-v5.3-2' of 
git://..

git tree:   upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=113faf7060
console output: https://syzkaller.appspot.com/x/log.txt?x=163faf7060
kernel config: https://syzkaller.appspot.com/x/.config?x=135cb826ac59d7fc
dashboard link: 
https://syzkaller.appspot.com/bug?extid=7f067c796eee2acbc57a

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12c1898fa0

Reported-by: syzbot+7f067c796eee2acbc...@syzkaller.appspotmail.com
Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual 
address")


For information about bisection process see: 
https://goo.gl/tpsmEJ#bisection



#syz dup: WARNING in __mmdrop

Re: KASAN: use-after-free Write in tlb_finish_mmu

[Jason Wang]

On 2019/7/20 上午4:04, syzbot wrote:

syzbot has bisected this bug to:

commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
Author: Jason Wang 
Date:   Fri May 24 08:12:18 2019 +

    vhost: access vq metadata through kernel virtual address

bisection log: 
https://syzkaller.appspot.com/x/bisect.txt?x=11642a5860
start commit:   22051d9c Merge tag 'platform-drivers-x86-v5.3-2' of 
git://..

git tree:   upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=13642a5860
console output: https://syzkaller.appspot.com/x/log.txt?x=15642a5860
kernel config: https://syzkaller.appspot.com/x/.config?x=d831b9cbe82e79e4
dashboard link: 
https://syzkaller.appspot.com/bug?extid=8267e9af795434ffadad

userspace arch: i386
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10d5878460

Reported-by: syzbot+8267e9af795434ffa...@syzkaller.appspotmail.com
Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual 
address")


For information about bisection process see: 
https://goo.gl/tpsmEJ#bisection



#syz dup: WARNING in __mmdrop

Re: Reminder: 1 open syzbot bug in sound subsystem

[Takashi Iwai]

On Wed, 24 Jul 2019 04:47:23 +0200,
Eric Biggers wrote:
> 
> [This email was generated by a script.  Let me know if you have any 
> suggestions
> to make it better, or if you want it re-generated with the latest status.]
> 
> Of the currently open syzbot reports against the upstream kernel, I've 
> manually
> marked 1 of them as possibly being a bug in the sound subsystem.
> 
> If you believe this bug is no longer valid, please close the syzbot report by
> sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
> original thread, as explained at https://goo.gl/tpsmEJ#status
> 
> If you believe I misattributed this bug to the sound subsystem, please let me
> know, and if possible forward the report to the correct people or mailing 
> list.
> 
> Here is the bug:
> 
> 
> Title:  KASAN: use-after-free Read in wake_up_if_idle
> Last occurred:  131 days ago
> Reported:   267 days ago
> Branches:   Mainline and others
> Dashboard link: 
> https://syzkaller.appspot.com/bug?id=b1e300cd7b124fc83dd4199d4d1df26310111b0f
> Original thread:
> https://lkml.kernel.org/lkml/66ab7105795f2...@google.com/T/#u

This one doesn't look like a bug that is directly related with the
sound stuff.  Although it was triggered from a sound ioctl, UAF is
seen rather in a notifier chain of other component.


thanks,

Takashi

> 
> Unfortunately, this bug does not have a reproducer.
> 
> No one replied to the original thread for this bug.
> 
> If you fix this bug, please add the following tag to the commit:
> Reported-by: syzbot+2c1253bc508adef78...@syzkaller.appspotmail.com
> 
> If you send any email or patch for this bug, please consider replying to the
> original thread.  For the git send-email command to use, or tips on how to 
> reply
> if the thread isn't in your mailbox, see the "Reply instructions" at
> https://lkml.kernel.org/r/66ab7105795f2...@google.com
> 
> 

Re: [PATCH] kmemleak: Increase maximum early log entries to 1000000

[Dmitry Vyukov]

On Wed, Jul 24, 2019 at 12:17 AM Doug Anderson  wrote:
>
> Hi,
>
> On Tue, Jul 23, 2019 at 1:21 AM Dmitry Vyukov  wrote:
> >
> > On Tue, Jul 23, 2019 at 10:13 AM Nicolas Boichat  
> > wrote:
> > >
> > > On Tue, Jul 23, 2019 at 3:46 PM Dmitry Vyukov  wrote:
> > > >
> > > > On Tue, Jul 23, 2019 at 9:26 AM Nicolas Boichat  
> > > > wrote:
> > > > >
> > > > > When KASan is enabled, a lot of memory is allocated early on,
> > > > > and kmemleak complains (this is on a 4GB RAM system):
> > > > > kmemleak: Early log buffer exceeded (129846), please increase
> > > > >   DEBUG_KMEMLEAK_EARLY_LOG_SIZE
> > > > >
> > > > > Let's increase the upper limit to 1M entry. That would take up
> > > > > 160MB of RAM at init (each early_log entry is 160 bytes), but
> > > > > the memory would later be freed (early_log is __initdata).
> > > >
> > > > Interesting. Is it on an arm64 system?
> > >
> > > Yes arm64. And this is chromiumos-4.19 tree. I didn't try to track
> > > down where these allocations come from...
> >
> > So perhaps it's due to arm64, or you have even more configs, or maybe
> > running on real hardware. But I guess it's fine as is, just wondered
> > why such a radical difference. Thanks.
>
> If I had to guess I'd guess gcc vs. clang.  I think we've noticed a
> few places where clang+kasan produces much bloatier code than
> gcc+kasan.  Oh look, I just invented a new word: bloatier.  :-P
>
> ...could you try building with gcc and see if that explains the problems?

Just in case, there is no problem per se. There is just a difference :)
Whom have you asked? We use gcc with KEMEMLEAK atm. But compiler
should not affect number of kernel heap allocations.

Re: [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms

[Joe Perches]

On Wed, 2019-07-24 at 08:53 +0200, Rasmus Villemoes wrote:
> BUILD_BUG_ON(!__same_type())
> strscpy(dst, src, ARRAY_SIZE(dst))

Doing this without the temporary is less legible to read
the compiler error when someone improperly does:

char *foo;
char *bar;

stracpy(foo, bar);

[PATCH] jffs2: remove jffs2_gc_fetch_page and jffs2_gc_release_page

[Christoph Hellwig]

Merge these two helpers into the only callers to get rid of some
amazingly bad calling conventions.

Suggested-by: Al Viro 
Signed-off-by: Christoph Hellwig 
---
 fs/jffs2/fs.c   | 27 ---
 fs/jffs2/gc.c   | 21 +
 fs/jffs2/os-linux.h |  3 ---
 3 files changed, 13 insertions(+), 38 deletions(-)

diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
index 8a20ddd25f2d..a3193c0f3a9b 100644
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@ -678,33 +678,6 @@ struct jffs2_inode_info *jffs2_gc_fetch_inode(struct 
jffs2_sb_info *c,
return JFFS2_INODE_INFO(inode);
 }
 
-unsigned char *jffs2_gc_fetch_page(struct jffs2_sb_info *c,
-  struct jffs2_inode_info *f,
-  unsigned long offset,
-  unsigned long *priv)
-{
-   struct inode *inode = OFNI_EDONI_2SFFJ(f);
-   struct page *pg;
-
-   pg = read_cache_page(inode->i_mapping, offset >> PAGE_SHIFT,
-jffs2_do_readpage_unlock, inode);
-   if (IS_ERR(pg))
-   return (void *)pg;
-
-   *priv = (unsigned long)pg;
-   return kmap(pg);
-}
-
-void jffs2_gc_release_page(struct jffs2_sb_info *c,
-  unsigned char *ptr,
-  unsigned long *priv)
-{
-   struct page *pg = (void *)*priv;
-
-   kunmap(pg);
-   put_page(pg);
-}
-
 static int jffs2_flash_setup(struct jffs2_sb_info *c) {
int ret = 0;
 
diff --git a/fs/jffs2/gc.c b/fs/jffs2/gc.c
index 9ed0f26cf023..373b3b7c9f44 100644
--- a/fs/jffs2/gc.c
+++ b/fs/jffs2/gc.c
@@ -1165,12 +1165,13 @@ static int jffs2_garbage_collect_dnode(struct 
jffs2_sb_info *c, struct jffs2_era
   struct jffs2_inode_info *f, struct 
jffs2_full_dnode *fn,
   uint32_t start, uint32_t end)
 {
+   struct inode *inode = OFNI_EDONI_2SFFJ(f);
struct jffs2_full_dnode *new_fn;
struct jffs2_raw_inode ri;
uint32_t alloclen, offset, orig_end, orig_start;
int ret = 0;
unsigned char *comprbuf = NULL, *writebuf;
-   unsigned long pg;
+   struct page *page;
unsigned char *pg_ptr;
 
memset(, 0, sizeof(ri));
@@ -1325,15 +1326,18 @@ static int jffs2_garbage_collect_dnode(struct 
jffs2_sb_info *c, struct jffs2_era
 * end up here trying to GC the *same* page that jffs2_write_begin() is
 * trying to write out, read_cache_page() will not deadlock. */
mutex_unlock(>sem);
-   pg_ptr = jffs2_gc_fetch_page(c, f, start, );
-   mutex_lock(>sem);
-
-   if (IS_ERR(pg_ptr)) {
+   page = read_cache_page(inode->i_mapping, start >> PAGE_SHIFT,
+  jffs2_do_readpage_unlock, inode);
+   if (IS_ERR(page)) {
pr_warn("read_cache_page() returned error: %ld\n",
-   PTR_ERR(pg_ptr));
-   return PTR_ERR(pg_ptr);
+   PTR_ERR(page));
+   mutex_lock(>sem);
+   return PTR_ERR(page);
}
 
+   pg_ptr = kmap(page);
+   mutex_lock(>sem);
+
offset = start;
while(offset < orig_end) {
uint32_t datalen;
@@ -1396,6 +1400,7 @@ static int jffs2_garbage_collect_dnode(struct 
jffs2_sb_info *c, struct jffs2_era
}
}
 
-   jffs2_gc_release_page(c, pg_ptr, );
+   kunmap(page);
+   put_page(page);
return ret;
 }
diff --git a/fs/jffs2/os-linux.h b/fs/jffs2/os-linux.h
index bd3d5f0ddc34..f4895dda26a3 100644
--- a/fs/jffs2/os-linux.h
+++ b/fs/jffs2/os-linux.h
@@ -183,9 +183,6 @@ unsigned char *jffs2_gc_fetch_page(struct jffs2_sb_info *c,
   struct jffs2_inode_info *f,
   unsigned long offset,
   unsigned long *priv);
-void jffs2_gc_release_page(struct jffs2_sb_info *c,
-  unsigned char *pg,
-  unsigned long *priv);
 void jffs2_flash_cleanup(struct jffs2_sb_info *c);
 
 
-- 
2.20.1

Re: [PATCH v3 6/6] interconnect: Add OPP table support for interconnects

[Vincent Guittot]

On Tue, 16 Jul 2019 at 02:56, Saravana Kannan  wrote:
>
> On Mon, Jul 15, 2019 at 1:16 AM Vincent Guittot
>  wrote:
> >
> > On Tue, 9 Jul 2019 at 21:03, Saravana Kannan  wrote:
> > >
> > > On Tue, Jul 9, 2019 at 12:25 AM Vincent Guittot
> > >  wrote:
> > > >
> > > > On Sun, 7 Jul 2019 at 23:48, Saravana Kannan  
> > > > wrote:
> > > > >
> > > > > On Thu, Jul 4, 2019 at 12:12 AM Vincent Guittot
> > > > >  wrote:
> > > > > >
> > > > > > On Wed, 3 Jul 2019 at 23:33, Saravana Kannan  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Tue, Jul 2, 2019 at 11:45 PM Vincent Guittot
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Wed, 3 Jul 2019 at 03:10, Saravana Kannan 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Interconnect paths can have different performance points. Now 
> > > > > > > > > that OPP
> > > > > > > > > framework supports bandwidth OPP tables, add OPP table 
> > > > > > > > > support for
> > > > > > > > > interconnects.
> > > > > > > > >
> > > > > > > > > Devices can use the interconnect-opp-table DT property to 
> > > > > > > > > specify OPP
> > > > > > > > > tables for interconnect paths. And the driver can obtain the 
> > > > > > > > > OPP table for
> > > > > > > > > an interconnect path by calling icc_get_opp_table().
> > > > > > > >
> > > > > > > > The opp table of a path must come from the aggregation of OPP 
> > > > > > > > tables
> > > > > > > > of the interconnect providers.
> > > > > > >
> > > > > > > The aggregation of OPP tables of the providers is certainly the
> > > > > > > superset of what a path can achieve, but to say that OPPs for
> > > > > > > interconnect path should match that superset is an 
> > > > > > > oversimplification
> > > > > > > of the reality in hardware.
> > > > > > >
> > > > > > > There are lots of reasons an interconnect path might not want to 
> > > > > > > use
> > > > > > > all the available bandwidth options across all the interconnects 
> > > > > > > in
> > > > > > > the route.
> > > > > > >
> > > > > > > 1. That particular path might not have been validated or verified
> > > > > > >during the HW design process for some of the 
> > > > > > > frequencies/bandwidth
> > > > > > >combinations of the providers.
> > > > > >
> > > > > > All these constraint are provider's constraints and not consumer's 
> > > > > > one
> > > > > >
> > > > > > The consumer asks for a bandwidth according to its needs and then 
> > > > > > the
> > > > > > providers select the optimal bandwidth of each interconnect after
> > > > > > aggregating all the request and according to what OPP have been
> > > > > > validated
> > > > >
> > > > > Not really. The screening can be a consumer specific issue. The
> > > > > consumer IP itself might have some issue with using too low of a
> > > > > bandwidth or bandwidth that's not within some range. It should not be
> > > >
> > > > How can an IP ask for not enough bandwidth ?
> > > > It asks the needed bandwidth based on its requirements
> > >
> > > The "enough bandwidth" is not always obvious. It's only for very
> > > simple cases that you can calculate the required bandwidth. Even for
> > > cases that you think might be "obvious/easy" aren't always easy.
> > >
> > > For example, you'd think a display IP would have a fixed bandwidth
> > > requirement for a fixed resolution screen. But that's far from the
> > > truth. It can also change as the number of layers change per frame.
> > > For video decoder/encoder, it depends on how well the frames compress
> > > with a specific compression scheme.
> > > So the "required" bandwidth is often a heuristic based on the IP
> > > frequency or traffic measurement.
> > >
> > > But that's not even the point I was making in this specific "bullet".
> > >
> > > A hardware IP might be screen/verified with only certain bandwidth
> > > levels. Or it might have hardware bugs that prevent it from using
> > > lower bandwidths even though it's technically sufficient. We need a
> > > way to capture that per path. This is not even a fictional case. This
> > > has been true multiple times over widely used IPs.
> >
> > here you are mixing HW constraint on the soc and OPP screening with
> > bandwidth request from consumer
> > ICC framework is about getting bandwidth request not trying to fix
> > some HW/voltage dependency of the SoC
> >
> > >
> > > > > the provider's job to take into account all the IP that might be
> > > > > connected to the interconnects. If the interconnect HW itself didn't
> > > >
> > > > That's not what I'm saying. The provider knows which bandwidth the
> > > > interconnect can provide as it is the ones which configures it. So if
> > > > the interconnect has a finite number of bandwidth point based probably
> > > > on the possible clock frequency and others config of the interconnect,
> > > > it selects the best final config after aggregating the request of the
> > > > consumer.
> > >
> > > I completely agree with this. What you are stating above is how it
> > > should work 

Re: [PATCH 1/2] mmc: sdhci: Add PLL Enable support to internal clock setup

[Ulf Hansson]

On Wed, 17 Jul 2019 at 04:39, Ben Chuang  wrote:
>
> The GL9750 and GL9755 chipsets, and possibly others, require PLL Enable
> setup as part of the internal clock setup as described in 3.2.1 Internal
> Clock Setup Sequence of SD Host Controller Simplified Specification
> Version 4.20.  This changes the timeouts to the new specification of
> 150ms for each step and is documented as safe for "prior versions which
> do not support PLL Enable."
>
> Signed-off-by: Ben Chuang 
> Co-developed-by: Michael K Johnson 
> Signed-off-by: Michael K Johnson 
> ---
>  drivers/mmc/host/sdhci.c | 33 -
>  1 file changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 59acf8e3331e..fd684d7a5f15 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1636,15 +1636,11 @@ void sdhci_enable_clk(struct sdhci_host *host, u16 
> clk)
> clk |= SDHCI_CLOCK_INT_EN;
> sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
>
> -   /* Wait max 20 ms */
> -   timeout = ktime_add_ms(ktime_get(), 20);
> -   while (1) {
> -   bool timedout = ktime_after(ktime_get(), timeout);
> -
> -   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> -   if (clk & SDHCI_CLOCK_INT_STABLE)
> -   break;
> -   if (timedout) {
> +   /* Wait max 150 ms */
> +   timeout = ktime_add_ms(ktime_get(), 150);
> +   while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
> +   & SDHCI_CLOCK_INT_STABLE)) {
> +   if (ktime_after(ktime_get(), timeout)) {
> pr_err("%s: Internal clock never stabilised.\n",
>mmc_hostname(host->mmc));
> sdhci_dumpregs(host);
> @@ -1653,8 +1649,27 @@ void sdhci_enable_clk(struct sdhci_host *host, u16 clk)
> udelay(10);

This looks like it could be changed to an usleep_range(), perhaps an
additional change on top?

> }
>
> +   clk |= SDHCI_CLOCK_PLL_EN;
> +   clk &= ~SDHCI_CLOCK_INT_STABLE;
> +   sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> +
> +   /* Wait max 150 ms */
> +   timeout = ktime_add_ms(ktime_get(), 150);
> +   while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
> +   & SDHCI_CLOCK_INT_STABLE)) {
> +   if (ktime_after(ktime_get(), timeout)) {
> +   pr_err("%s: PLL clock never stabilised.\n",
> +  mmc_hostname(host->mmc));
> +   sdhci_dumpregs(host);
> +   return;
> +   }
> +   udelay(10);

Ditto.

> +   }
> +
> clk |= SDHCI_CLOCK_CARD_EN;
> sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> +
> +   mdelay(1);

This is new, maybe add a comment and change to usleep_range().

>  }
>  EXPORT_SYMBOL_GPL(sdhci_enable_clk);
>
> --
> 2.22.0
>
> 
>
> Genesys Logic Email Confidentiality Notice:
> This mail and any attachments may contain information that is confidential, 
> proprietary, privileged or otherwise protected by law. The mail is intended 
> solely for the named addressee (or a person responsible for delivering it to 
> the addressee). If you are not the intended recipient of this mail, you are 
> not authorized to read, print, copy or disseminate this mail.
>
> If you have received this email in error, please notify us immediately by 
> reply email and immediately delete this message and any attachments from your 
> system. Please be noted that any unauthorized use, dissemination, 
> distribution or copying of this email is strictly prohibited.
> 

If you want me to apply the patch, you have to drop the above notice.

Kind regards
Uffe

Re: [GIT PULL] FPGA Manager fix for 5.3

[Greg KH]

On Tue, Jul 23, 2019 at 10:20:12PM -0700, Moritz Fischer wrote:
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
> 
>   Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux-fpga.git 
> tags/fixes-for-5.3
> 
> for you to fetch changes up to c3aefa0b8f54e8c7967191e546a11019bc060fe6:
> 
>   fpga-manager: altera-ps-spi: Fix build error (2019-07-23 17:29:17 -0700)
> 
> 
> FPGA Manager fixes for 5.3
> 
> Hi Greg,
> 
> this is only one (late) bugfix for 5.3 that fixes a build error,
> when altera-ps-spi is built as builtin while a dependency is built as a
> module.
> 
> This has been on the list for a while and I've reviewed it.
> 
> Signed-off-by: Moritz Fischer 

This message is not in the signed tag in the repo, are you sure you make
this correctly?  All I see is the first line:
FPGA Manager fixes for 5.3

And it's a singluar "fix" :)

Care to fix this up and resend, or, just send the single patch as email,
as that's probably easier here.

thanks,

greg k-h

Re: [PATCH v3] locking/spinlocks, paravirt, hyperv: Correct the hv_nopvspin case

[Zhenzhong Duan]

Hi Maintainers,

Any further comments on this? Thanks

Zhenzhong

On 2019/7/3 10:23, Zhenzhong Duan wrote:

With the boot parameter "hv_nopvspin" specified a Hyperv guest should
not make use of paravirt spinlocks, but behave as if running on bare
metal. This is not true, however, as the qspinlock code will fall back
to a test-and-set scheme when it is detecting a hypervisor.

In order to avoid this disable the virt_spin_lock_key.

Same change for XEN is already in Commit e6fd28eb3522
("locking/spinlocks, paravirt, xen: Correct the xen_nopvspin case")

Signed-off-by: Zhenzhong Duan 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Peter Zijlstra 
Cc: Waiman Long 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: linux-hyp...@vger.kernel.org
---
v3: remove unlikely() as suggested by Sasha

  arch/x86/hyperv/hv_spinlock.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index 07f21a0..210495b 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -64,6 +64,9 @@ __visible bool hv_vcpu_is_preempted(int vcpu)
  
  void __init hv_init_spinlocks(void)

  {
+   if (!hv_pvspin)
+   static_branch_disable(_spin_lock_key);
+
if (!hv_pvspin || !apic ||
!(ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) ||
!(ms_hyperv.features & HV_X64_MSR_GUEST_IDLE_AVAILABLE)) {

Re: [PATCH] [v2] waitqueue: shut up clang -Wuninitialized warnings

[Peter Zijlstra]

On Tue, Jul 23, 2019 at 01:54:03PM -0700, Nick Desaulniers wrote:
> Note that pre-clang-9 can be used for LTS x86_64; I don't think
> CONFIG_JUMP_LABEL was made mandatory for x86 until 4.20 release, IIRC.
> There's only a small window of non LTS kernels and only for x86 where
> clang-9+ is really necessary.

Given all the code-gen issues we've been finding, I wouldn't want to
touch a pre-9 clang. Irrespective of wether it builds or not, it's
absolutely unreliable crap.

Re: [PATCH v2 2/4] arm64: unwind: Prohibit probing on return_address()

[Masami Hiramatsu]

On Tue, 23 Jul 2019 17:04:21 +0100
James Morse  wrote:

> Hi,
> 
> On 22/07/2019 08:48, Masami Hiramatsu wrote:
> > Prohibit probing on return_address() and subroutines which
> > is called from return_address(), since the it is invoked from
> > trace_hardirqs_off() which is also kprobe blacklisted.
> 
> (Nits: "which are called" and "since it is")

Thanks!

> 
> 
> > diff --git a/arch/arm64/kernel/return_address.c 
> > b/arch/arm64/kernel/return_address.c
> > index b21cba90f82d..7f8a143268b0 100644
> > --- a/arch/arm64/kernel/return_address.c
> > +++ b/arch/arm64/kernel/return_address.c
> > @@ -8,6 +8,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -17,7 +18,7 @@ struct return_address_data {
> > void *addr;
> >  };
> >  
> > -static int save_return_addr(struct stackframe *frame, void *d)
> > +static nokprobe_inline int save_return_addr(struct stackframe *frame, void 
> > *d)
> 
> This nokprobe_inline ends up as __always_inline if kprobes is enabled.
> What do we expect the compiler to do with this? save_return_addr is passed as 
> a
> function-pointer to walk_stackframe()... I don't see how the compiler can 
> inline it!

Oops, that's my mistake. Then it should be NOKPROBE_SYMBOL.

> 
> This would be needed for on_accessible_stack().
> Should we cover ftrace_graph_get_ret_stack()?, or is that already in hand?

No, that is OK. It just covers that the functions which are involved in
the kprobe execution path. ftrace_graph_ret_stack() is out of the debug
exception handler.

Thank you,

> >  {
> > struct return_address_data *data = d;
> >  
> > @@ -52,3 +53,4 @@ void *return_address(unsigned int level)
> > return NULL;
> >  }
> >  EXPORT_SYMBOL_GPL(return_address);
> > +NOKPROBE_SYMBOL(return_address);
> 
> 
> Thanks,
> 
> James


-- 
Masami Hiramatsu 

[RESEND PATCH v7] dmaengine: fsl-edma: add i.mx7ulp edma2 version support

[Robin Gong]

Add edma2 for i.mx7ulp by version v3, since v2 has already
been used by mcf-edma.
The big changes based on v1 are belows:
1. only one dmamux.
2. another clock dma_clk except dmamux clk.
3. 16 independent interrupts instead of only one interrupt for
all channels.

Signed-off-by: Robin Gong 
---
Change from v6:
Rebase latest linux-next, please ignore v6 sent yesterday.

Change from v5(https://lkml.org/lkml/2019/6/25/444):
Fix below build issue, replace platform_irq_count() instead
of of_irq_count():
https://lkml.org/lkml/2019/7/8/5

 drivers/dma/fsl-edma-common.c | 18 +++-
 drivers/dma/fsl-edma-common.h |  4 +++
 drivers/dma/fsl-edma.c| 65 +++
 3 files changed, 86 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
index 44d92c3..6d6d8a4 100644
--- a/drivers/dma/fsl-edma-common.c
+++ b/drivers/dma/fsl-edma-common.c
@@ -90,6 +90,19 @@ static void mux_configure8(struct fsl_edma_chan *fsl_chan, 
void __iomem *addr,
iowrite8(val8, addr + off);
 }
 
+void mux_configure32(struct fsl_edma_chan *fsl_chan, void __iomem *addr,
+u32 off, u32 slot, bool enable)
+{
+   u32 val;
+
+   if (enable)
+   val = EDMAMUX_CHCFG_ENBL << 24 | slot;
+   else
+   val = EDMAMUX_CHCFG_DIS;
+
+   iowrite32(val, addr + off * 4);
+}
+
 void fsl_edma_chan_mux(struct fsl_edma_chan *fsl_chan,
unsigned int slot, bool enable)
 {
@@ -103,7 +116,10 @@ void fsl_edma_chan_mux(struct fsl_edma_chan *fsl_chan,
muxaddr = fsl_chan->edma->muxbase[ch / chans_per_mux];
slot = EDMAMUX_CHCFG_SOURCE(slot);
 
-   mux_configure8(fsl_chan, muxaddr, ch_off, slot, enable);
+   if (fsl_chan->edma->drvdata->version == v3)
+   mux_configure32(fsl_chan, muxaddr, ch_off, slot, enable);
+   else
+   mux_configure8(fsl_chan, muxaddr, ch_off, slot, enable);
 }
 EXPORT_SYMBOL_GPL(fsl_edma_chan_mux);
 
diff --git a/drivers/dma/fsl-edma-common.h b/drivers/dma/fsl-edma-common.h
index 4e17556..5eaa290 100644
--- a/drivers/dma/fsl-edma-common.h
+++ b/drivers/dma/fsl-edma-common.h
@@ -125,6 +125,7 @@ struct fsl_edma_chan {
dma_addr_t  dma_dev_addr;
u32 dma_dev_size;
enum dma_data_direction dma_dir;
+   charchan_name[16];
 };
 
 struct fsl_edma_desc {
@@ -139,11 +140,13 @@ struct fsl_edma_desc {
 enum edma_version {
v1, /* 32ch, Vybrid, mpc57x, etc */
v2, /* 64ch Coldfire */
+   v3, /* 32ch, i.mx7ulp */
 };
 
 struct fsl_edma_drvdata {
enum edma_version   version;
u32 dmamuxs;
+   boolhas_dmaclk;
int (*setup_irq)(struct platform_device *pdev,
 struct fsl_edma_engine *fsl_edma);
 };
@@ -153,6 +156,7 @@ struct fsl_edma_engine {
void __iomem*membase;
void __iomem*muxbase[DMAMUX_NR];
struct clk  *muxclk[DMAMUX_NR];
+   struct clk  *dmaclk;
struct mutexfsl_edma_mutex;
const struct fsl_edma_drvdata *drvdata;
u32 n_chans;
diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c
index fcbad6a..7cc2653 100644
--- a/drivers/dma/fsl-edma.c
+++ b/drivers/dma/fsl-edma.c
@@ -162,6 +162,49 @@ fsl_edma_irq_init(struct platform_device *pdev, struct 
fsl_edma_engine *fsl_edma
return 0;
 }
 
+static int
+fsl_edma2_irq_init(struct platform_device *pdev,
+  struct fsl_edma_engine *fsl_edma)
+{
+   int i, ret, irq;
+   int count;
+
+   count = platform_irq_count(pdev);
+   dev_dbg(>dev, "%s Found %d interrupts\r\n", __func__, count);
+   if (count <= 2) {
+   dev_err(>dev, "Interrupts in DTS not correct.\n");
+   return -EINVAL;
+   }
+   /*
+* 16 channel independent interrupts + 1 error interrupt on i.mx7ulp.
+* 2 channel share one interrupt, for example, ch0/ch16, ch1/ch17...
+* For now, just simply request irq without IRQF_SHARED flag, since 16
+* channels are enough on i.mx7ulp whose M4 domain own some peripherals.
+*/
+   for (i = 0; i < count; i++) {
+   irq = platform_get_irq(pdev, i);
+   if (irq < 0)
+   return -ENXIO;
+
+   sprintf(fsl_edma->chans[i].chan_name, "eDMA2-CH%02d", i);
+
+   /* The last IRQ is for eDMA err */
+   if (i == count - 1)
+   ret = devm_request_irq(>dev, irq,
+   fsl_edma_err_handler,
+   0, "eDMA2-ERR", fsl_edma);
+   else
+   ret = devm_request_irq(>dev, irq,
+

Re: [RFC 00/79] perf tools: Initial libperf separation

[Song Liu]

Hi Jiri,

> On Jul 21, 2019, at 4:23 AM, Jiri Olsa  wrote:
> 
> hi,
> we have long term goal to separate some of the perf functionality
> into library. This patchset is initial effort on separating some
> of the interface.
> 
> Currently only the basic counting interface is exported, it allows
> to:
>  - create cpu/threads maps
>  - create evlist/evsel objects
>  - add evsel objects into evlist
>  - open/close evlist/evsel objects
>  - enable/disable events
>  - read evsel counts

Based on my understanding, evsel and evlist are abstractions in
perf utilities. I think most other tools that use perf UAPIs are 
not built based on these abstractions. I looked at a few internal
tools. Most of them just uses sys_perf_event_open() and struct 
perf_event_attr. I am not sure whether these tools would adopt
libperf, as libperf changes their existing concepts/abstractions.

> 
> The initial effort was to have total separation of the objects
> from perf code, but it showed not to be a good way. The amount
> of changed code was too big with high chance for regressions,
> mainly because of the code embedding one of the above objects
> statically.
> 
> We took the other approach of sharing the objects/struct details
> within the perf and libperf code. This way we can keep perf
> functionality without any major changes and the libperf users
> are still separated from the object/struct details. We can move
> to total libperf's objects separation gradually in future.

I found some duplicated logic between libperf and perf, for 
example, perf_evlist__open() and evlist__open(). Do we plan to 
merge them in the future? 

Thanks,
Song

5.3-rc1 BUGS in dma_addressing_limited

[Nikolay Borisov]

Hello Christoph, 

5.3-rc1 crashes for me when run in qemu with scsi disks. 
Quick investigation shows that the following triggers a BUG_ON: 

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index e11b115dd0e4..4465e352b8dd 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -689,6 +689,7 @@ static inline int dma_coerce_mask_and_coherent(struct 
device *dev, u64 mask)
  */
 static inline bool dma_addressing_limited(struct device *dev)
 {
+   BUG_ON(!(dev->dma_mask));
return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) <
dma_get_required_mask(dev);


Otherwise here is what the real backtrace looks like: 

[5.387839] scsi host0: Virtio SCSI HBA
[5.389860] BUG: kernel NULL pointer dereference, address: 
[5.390217] #PF: supervisor read access in kernel mode
[5.390520] #PF: error_code(0x) - not-present page
[5.390813] PGD 0 P4D 0 
[5.391007] Oops:  [#1] SMP
[5.391007] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc1-default #578
[5.391007] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1ubuntu1 04/01/2014
[5.391007] RIP: 0010:dma_direct_max_mapping_size+0x21/0x80
[5.391007] Code: 0f b6 c0 c3 0f 1f 44 00 00 0f 1f 44 00 00 55 53 48 89 fb 
e8 f1 0e 00 00 84 c0 74 42 48 8b 83 e8 01 00 00 48 8b ab f8 01 00 00 <48> 8b 00 
48 85 c0 74 0c 48 85 ed 74 31 48 39 c5 48 0f 47 e8 48 89
[5.391007] RSP: :b0edc0013ac0 EFLAGS: 00010202
[5.391007] RAX:  RBX: 9216f9d8b838 RCX: 
[5.391007] RDX:  RSI: 007e RDI: 9216f9d8b838
[5.391007] RBP:  R08: 000249ffd97b R09: 0001
[5.391007] R10:  R11:  R12: 9216f9d8b838
[5.391007] R13:  R14: 9216f7348580 R15: 
[5.391007] FS:  () GS:9216fba0() 
knlGS:
[5.391007] CS:  0010 DS:  ES:  CR0: 80050033
[5.391007] CR2:  CR3: 7a211000 CR4: 06e0
[5.391007] Call Trace:
[5.391007]  __scsi_init_queue+0x75/0x130
[5.391007]  scsi_mq_alloc_queue+0x34/0x50
[5.391007]  scsi_alloc_sdev+0x232/0x300
[5.391007]  scsi_probe_and_add_lun+0x482/0xda0
[5.391007]  ? scsi_alloc_target+0x282/0x340
[5.391007]  __scsi_scan_target+0xe6/0x610
[5.391007]  ? sched_clock_local+0x12/0x80
[5.391007]  ? sched_clock_cpu+0x94/0xc0
[5.391007]  scsi_scan_channel.part.15+0x55/0x70
[5.391007]  scsi_scan_host_selected+0xd7/0x180
[5.391007]  virtscsi_probe+0x6f6/0x710
[5.391007]  ? msi_get_domain_info+0x10/0x10
[5.391007]  virtio_dev_probe+0x147/0x1d0
[5.391007]  really_probe+0xd6/0x3b0
[5.391007]  ? set_debug_rodata+0x11/0x11
[5.391007]  device_driver_attach+0x4f/0x60
[5.391007]  __driver_attach+0x99/0x130
[5.391007]  ? device_driver_attach+0x60/0x60
[5.391007]  bus_for_each_dev+0x76/0xc0
[5.391007]  bus_add_driver+0x144/0x220
[5.391007]  ? sym2_init+0xf6/0xf6
[5.391007]  driver_register+0x5b/0xe0
[5.391007]  ? sym2_init+0xf6/0xf6
[5.391007]  init+0x86/0xcc
[5.391007]  do_one_initcall+0x5a/0x2d4
[5.391007]  ? set_debug_rodata+0x11/0x11
[5.391007]  ? rcu_read_lock_sched_held+0x74/0x80
[5.391007]  kernel_init_freeable+0x139/0x1c9
[5.391007]  ? rest_init+0x260/0x260
[5.391007]  kernel_init+0xa/0x100
[5.391007]  ret_from_fork+0x24/0x30
[5.391007] Modules linked in:
[5.391007] CR2: 
[5.391007] ---[ end trace 03e50b8909d2f2e5 ]---
[5.391007] RIP: 0010:dma_direct_max_mapping_size+0x21/0x80
[5.391007] Code: 0f b6 c0 c3 0f 1f 44 00 00 0f 1f 44 00 00 55 53 48 89 fb 
e8 f1 0e 00 00 84 c0 74 42 48 8b 83 e8 01 00 00 48 8b ab f8 01 00 00 <48> 8b 00 
48 85 c0 74 0c 48 85 ed 74 31 48 39 c5 48 0f 47 e8 48 89
[5.391007] RSP: :b0edc0013ac0 EFLAGS: 00010202
[5.391007] RAX:  RBX: 9216f9d8b838 RCX: 
[5.391007] RDX:  RSI: 007e RDI: 9216f9d8b838
[5.391007] RBP:  R08: 000249ffd97b R09: 0001
[5.391007] R10:  R11:  R12: 9216f9d8b838
[5.391007] R13:  R14: 9216f7348580 R15: 
[5.391007] FS:  () GS:9216fba0() 
knlGS:
[5.391007] CS:  0010 DS:  ES:  CR0: 80050033
[5.391007] CR2:  CR3: 7a211000 CR4: 06e0
[5.391007] BUG: sleeping function called from invalid context at 
./include/linux/percpu-rwsem.h:38
[5.391007] in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: swapper/0
[5.391007] INFO: lockdep is turned off.
[5.391007] irq event stamp: 13427044
[5.391007] hardirqs last  enabled at (13427043): [] 

[PATCH v5 1/3] PM: wakeup: Add routine to help fetch wakeup source object.

[Ran Wang]

Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. So add this API to help walk through all registered
wakeup source objects on that list and return them one by one.

Signed-off-by: Ran Wang 
---
Change in v5:
- Update commit message, add decription of walk through all wakeup
source objects.
- Add SCU protection in function wakeup_source_get_next().
- Rename wakeup_source member 'attached_dev' to 'dev' and move it up
(before wakeirq).

Change in v4:
- None.

Change in v3:
- Adjust indentation of *attached_dev;.

Change in v2:
- None.

 drivers/base/power/wakeup.c | 24 
 include/linux/pm_wakeup.h   |  3 +++
 2 files changed, 27 insertions(+)

diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index ee31d4f..2fba891 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -226,6 +227,28 @@ void wakeup_source_unregister(struct wakeup_source *ws)
}
 }
 EXPORT_SYMBOL_GPL(wakeup_source_unregister);
+/**
+ * wakeup_source_get_next - Get next wakeup source from the list
+ * @ws: Previous wakeup source object, null means caller want first one.
+ */
+struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws)
+{
+   struct list_head *ws_head = _sources;
+   struct wakeup_source *next_ws = NULL;
+   int idx;
+
+   idx = srcu_read_lock(_srcu);
+   if (ws)
+   next_ws = list_next_or_null_rcu(ws_head, >entry,
+   struct wakeup_source, entry);
+   else
+   next_ws = list_entry_rcu(ws_head->next,
+   struct wakeup_source, entry);
+   srcu_read_unlock(_srcu, idx);
+
+   return next_ws;
+}
+EXPORT_SYMBOL_GPL(wakeup_source_get_next);
 
 /**
  * device_wakeup_attach - Attach a wakeup source object to a device object.
@@ -242,6 +265,7 @@ static int device_wakeup_attach(struct device *dev, struct 
wakeup_source *ws)
return -EEXIST;
}
dev->power.wakeup = ws;
+   ws->dev = dev;
if (dev->power.wakeirq)
device_wakeup_attach_irq(dev, dev->power.wakeirq);
spin_unlock_irq(>power.lock);
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index 9102760..fc23c1a 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -23,6 +23,7 @@ struct wake_irq;
  * @name: Name of the wakeup source
  * @entry: Wakeup source list entry
  * @lock: Wakeup source lock
+ * @dev: The device it attached to
  * @wakeirq: Optional device specific wakeirq
  * @timer: Wakeup timer list
  * @timer_expires: Wakeup timer expiration
@@ -42,6 +43,7 @@ struct wakeup_source {
const char  *name;
struct list_headentry;
spinlock_t  lock;
+   struct device   *dev;
struct wake_irq *wakeirq;
struct timer_list   timer;
unsigned long   timer_expires;
@@ -88,6 +90,7 @@ extern void wakeup_source_add(struct wakeup_source *ws);
 extern void wakeup_source_remove(struct wakeup_source *ws);
 extern struct wakeup_source *wakeup_source_register(const char *name);
 extern void wakeup_source_unregister(struct wakeup_source *ws);
+extern struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws);
 extern int device_wakeup_enable(struct device *dev);
 extern int device_wakeup_disable(struct device *dev);
 extern void device_set_wakeup_capable(struct device *dev, bool capable);
-- 
2.7.4

[PATCH v5 3/3] soc: fsl: add RCPM driver

[Ran Wang]

The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.

This driver depends on PM wakeup source framework which help to
collect wake information.

Signed-off-by: Ran Wang 
Acked-by: Pavel Machek 
---
Change in v5:
- Fix v4 regression of the return value of wakeup_source_get_next()
didn't pass to ws in while loop.
- Rename wakeup_source member 'attached_dev' to 'dev'.
- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-cells'.
please see https://lore.kernel.org/patchwork/patch/1101022/

Change in v4:
- Remove extra ',' in author line of rcpm.c
- Update usage of wakeup_source_get_next() to be less confusing to the
reader, code logic remain the same.

Change in v3:
- Some whitespace ajdustment.

Change in v2:
- Rebase Kconfig and Makefile update to latest mainline.

 drivers/soc/fsl/Kconfig  |   8 +++
 drivers/soc/fsl/Makefile |   1 +
 drivers/soc/fsl/rcpm.c   | 126 +++
 3 files changed, 135 insertions(+)
 create mode 100644 drivers/soc/fsl/rcpm.c

diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index f9ad8ad..4918856 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -40,4 +40,12 @@ config DPAA2_CONSOLE
  /dev/dpaa2_mc_console and /dev/dpaa2_aiop_console,
  which can be used to dump the Management Complex and AIOP
  firmware logs.
+
+config FSL_RCPM
+   bool "Freescale RCPM support"
+   depends on PM_SLEEP
+   help
+ The NXP QorIQ Processors based on ARM Core have RCPM module
+ (Run Control and Power Management), which performs all device-level
+ tasks associated with power management, such as wakeup source control.
 endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 71dee8d..906f1cd 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_FSL_DPAA) += qbman/
 obj-$(CONFIG_QUICC_ENGINE) += qe/
 obj-$(CONFIG_CPM)  += qe/
+obj-$(CONFIG_FSL_RCPM) += rcpm.o
 obj-$(CONFIG_FSL_GUTS) += guts.o
 obj-$(CONFIG_FSL_MC_DPIO)  += dpio/
 obj-$(CONFIG_DPAA2_CONSOLE)+= dpaa2-console.o
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
new file mode 100644
index 000..02244a1
--- /dev/null
+++ b/drivers/soc/fsl/rcpm.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// rcpm.c - Freescale QorIQ RCPM driver
+//
+// Copyright 2019 NXP
+//
+// Author: Ran Wang 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RCPM_WAKEUP_CELL_MAX_SIZE  7
+
+struct rcpm {
+   unsigned intwakeup_cells;
+   void __iomem*ippdexpcr_base;
+   boollittle_endian;
+};
+
+static int rcpm_pm_prepare(struct device *dev)
+{
+   struct device_node  *np = dev->of_node;
+   struct wakeup_source*ws;
+   struct rcpm *rcpm;
+   u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
+   int i, ret;
+
+   rcpm = dev_get_drvdata(dev);
+   if (!rcpm)
+   return -EINVAL;
+
+   /* Begin with first registered wakeup source */
+   ws = NULL;
+   while (ws = wakeup_source_get_next(ws)) {
+   /* skip object which is not attached to device */
+   if (!ws->dev)
+   continue;
+
+   ret = device_property_read_u32_array(ws->dev,
+   "fsl,rcpm-wakeup", value, rcpm->wakeup_cells + 
1);
+
+   /*  Wakeup source should refer to current rcpm device */
+   if (ret || (np->phandle != value[0])) {
+   dev_info(dev, "%s doesn't refer to this rcpm\n",
+   ws->name);
+   continue;
+   }
+
+   for (i = 0; i < rcpm->wakeup_cells; i++) {
+   /* We can only OR related bits */
+   if (value[i + 1]) {
+   if (rcpm->little_endian) {
+   tmp = ioread32(rcpm->ippdexpcr_base + i 
* 4);
+   tmp |= value[i + 1];
+   iowrite32(tmp, rcpm->ippdexpcr_base + i 
* 4);
+   } else {
+   tmp = ioread32be(rcpm->ippdexpcr_base + 
i * 4);
+   tmp |= value[i + 1];
+   iowrite32be(tmp, rcpm->ippdexpcr_base + 
i * 4);
+   }
+   }
+   }
+   }
+
+   return 0;
+}
+
+static const struct dev_pm_ops rcpm_pm_ops = {
+   .prepare =  rcpm_pm_prepare,

[PATCH v5 2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define

[Ran Wang]

By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are Little
Endian. So add this optional property to help identify them.

Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc SoC.

Signed-off-by: Ran Wang 
Reviewed-by: Rob Herring 
---
Change in v5:
- Add 'Reviewed-by: Rob Herring ' to commit message.
- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-cells'.
please see https://lore.kernel.org/patchwork/patch/1101022/

Change in v4:
- Adjust indectation of 'ls1021a, ls1012a, ls1043a, ls1046a'.

Change in v3:
- None.

Change in v2:
- None.

 Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt 
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index e284e4e..5a33619 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -5,7 +5,7 @@ and power management.
 
 Required properites:
   - reg : Offset and length of the register set of the RCPM block.
-  - fsl,#rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
+  - #fsl,rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
fsl,rcpm-wakeup property.
   - compatible : Must contain a chip-specific RCPM block compatible string
and (if applicable) may contain a chassis-version RCPM compatible
@@ -20,6 +20,7 @@ Required properites:
* "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
* "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
* "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
+   * "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm
 
 All references to "1.0" and "2.0" refer to the QorIQ chassis version to
 which the chip complies.
@@ -27,14 +28,19 @@ Chassis Version Example Chips
 ------
 1.0p4080, p5020, p5040, p2041, p3041
 2.0t4240, b4860, b4420
-2.1t1040, ls1021
+2.1t1040,
+2.1+   ls1021a, ls1012a, ls1043a, ls1046a
+
+Optional properties:
+ - little-endian : RCPM register block is Little Endian. Without it RCPM
+   will be Big Endian (default case).
 
 Example:
 The RCPM node for T4240:
rcpm: global-utilities@e2000 {
compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
reg = <0xe2000 0x1000>;
-   fsl,#rcpm-wakeup-cells = <2>;
+   #fsl,rcpm-wakeup-cells = <2>;
};
 
 * Freescale RCPM Wakeup Source Device Tree Bindings
@@ -44,7 +50,7 @@ can be used as a wakeup source.
 
   - fsl,rcpm-wakeup: Consists of a phandle to the rcpm node and the IPPDEXPCR
register cells. The number of IPPDEXPCR register cells is defined in
-   "fsl,#rcpm-wakeup-cells" in the rcpm node. The first register cell is
+   "#fsl,rcpm-wakeup-cells" in the rcpm node. The first register cell is
the bit mask that should be set in IPPDEXPCR0, and the second register
cell is for IPPDEXPCR1, and so on.
 
-- 
2.7.4

Re: x86 - clang / objtool status

[Peter Zijlstra]

On Tue, Jul 23, 2019 at 09:43:24PM -0500, Josh Poimboeuf wrote:
> On Thu, Jul 18, 2019 at 10:40:09PM +0200, Thomas Gleixner wrote:
> 
> >   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: 
> > .altinstr_replacement+0x86: redundant UACCESS disable
> 
> Looking at this one, I think I agree with objtool.
> 
> PeterZ, Linus, I know y'all discussed this code a few months ago.
> 
> __copy_from_user() already does a CLAC in its error path.  So isn't the
> user_access_end() redundant for the __copy_from_user() error path?

Hmm, is this a result of your c705cecc8431 ("objtool: Track original function 
across branches") ?

I'm thinking it might've 'overlooked' the CLAC in the error path before
(because it didn't have a related function) and now it sees it and
worries about it.

Then again, I'm not seeing this warning on my GCC builds; so what's
happening?

Re: [PATCH] asm-generic: fix -Wtype-limits compiler warnings

[David Howells]

Qian Cai  wrote:

> Fix it by moving almost all of this multi-line macro into a proper
> function __get_order(), and leave get_order() as a single-line macro in
> order to avoid compilation errors.

The idea was that you could compile-time initialise a global variable with
get_order():

int a = get_order(SOME_MACRO);

This is the same reason that ilog2() is a macro:

int a = ilog2(SOME_MACRO);

See the banner comment on get_order():

 * This function may be used to initialise variables with compile time
 * evaluations of constants.

If you're moving the constant branch into __get_order(), an inline function,
then we'll no longer be able to do this and you need to modify the comment
too.  In fact, would there still be a point in having the get_order() macro?

Also, IIRC, older versions of gcc see __builtin_constant_p(n) == 0 inside an
function, inline or otherwise, even if the passed-in argument *is* constant.

David

[PATCH 1/2] dt-bindings: arm: fsl: Add PHYTEC i.MX6 UL/ULL devicetree bindings

[Stefan Riedmueller]

Add devicetree bindings for i.MX6 UL/ULL based phyCORE-i.MX6 UL/ULL and
phyBOARD-Segin.

Signed-off-by: Stefan Riedmueller 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..40f007859092 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -161,12 +161,20 @@ properties:
 items:
   - enum:
   - fsl,imx6ul-14x14-evk  # i.MX6 UltraLite 14x14 EVK Board
+  - phytec,imx6ul-pbacd10 # PHYTEC phyBOARD-Segin with i.MX6 UL
+  - phytec,imx6ul-pbacd10-emmc  # PHYTEC phyBOARD-Segin eMMC Kit
+  - phytec,imx6ul-pbacd10-nand  # PHYTEC phyBOARD-Segin NAND Kit
+  - phytec,imx6ul-pcl063  # PHYTEC phyCORE-i.MX 6UL
   - const: fsl,imx6ul
 
   - description: i.MX6ULL based Boards
 items:
   - enum:
   - fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board
+  - phytec,imx6ull-pbacd10# PHYTEC phyBOARD-Segin with i.MX6 
ULL
+  - phytec,imx6ull-pbacd10-emmc # PHYTEC phyBOARD-Segin eMMC Kit
+  - phytec,imx6ull-pbacd10-nand # PHYTEC phyBOARD-Segin NAND Kit
+  - phytec,imx6ull-pcl063 # PHYTEC phyCORE-i.MX 6ULL
   - const: fsl,imx6ull
 
   - description: i.MX6ULZ based Boards
-- 
2.7.4

[PATCH 2/2] dt-bindings: arm: fsl: Add PHYTEC i.MX6 devicetree bindings

[Stefan Riedmueller]

Add devicetree bindings for i.MX6 based phyCORE-i.MX6, phyBOARD-Mira and
phyFLEX-i.MX6.

Signed-off-by: Stefan Riedmueller 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 40f007859092..00a037cf5c86 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -112,6 +112,13 @@ properties:
   - fsl,imx6q-sabreauto
   - fsl,imx6q-sabrelite
   - fsl,imx6q-sabresd
+  - phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6
+  - phytec,imx6q-pbab01   # PHYTEC phyFLEX carrier board
+  - phytec,imx6q-pbab01-nand  # PHYTEC phyFLEX eval Kit
+  - phytec,imx6q-pbac06   # PHYTEC phyBOARD-Mira with i.MX6 
Quad
+  - phytec,imx6q-pbac06-emmc  # PHYTEC phyBOARD-Mira eMMC RDK
+  - phytec,imx6q-pbac06-nand  # PHYTEC phyBOARD-Mira NAND RDK
+  - phytec,imx6q-pfla02   # PHYTEC phyFLEX-i.MX6 Quad
   - technologic,imx6q-ts4900
   - technologic,imx6q-ts7970
   - const: fsl,imx6q
@@ -121,6 +128,9 @@ properties:
   - enum:
   - fsl,imx6qp-sabreauto  # i.MX6 Quad Plus SABRE Automotive 
Board
   - fsl,imx6qp-sabresd# i.MX6 Quad Plus SABRE Smart Device 
Board
+  - phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6
+  - phytec,imx6qp-pbac06  # PHYTEC phyBOARD-Mira with i.MX6 
QuadPlus
+  - phytec,imx6qp-pbac06-nand # PHYTEC phyBOARD-Mira NAND RDK
   - const: fsl,imx6qp
 
   - description: i.MX6DL based Boards
@@ -131,6 +141,13 @@ properties:
   - emtrion,emcon-mx6-avari   # emCON-MX6S or emCON-MX6DL SoM on 
Avari Base
   - fsl,imx6dl-sabreauto  # i.MX6 DualLite/Solo SABRE 
Automotive Board
   - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device 
Board
+  - phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6
+  - phytec,imx6dl-pbab01  # PHYTEC phyFLEX carrier board
+  - phytec,imx6dl-pbab01-nand # PHYTEC phyFLEX eval Kit
+  - phytec,imx6dl-pbac06  # PHYTEC phyBOARD-Mira with i.MX6 DL
+  - phytec,imx6dl-pbac06-emmc # PHYTEC phyBOARD-Mira eMMC RDK
+  - phytec,imx6dl-pbac06-nand # PHYTEC phyBOARD-Mira NAND RDK
+  - phytec,imx6dl-pfla02  # PHYTEC phyFLEX-i.MX6 DL
   - technologic,imx6dl-ts4900
   - technologic,imx6dl-ts7970
   - ysoft,imx6dl-yapp4-draco  # i.MX6 DualLite Y Soft IOTA Draco 
board
-- 
2.7.4

Re: [PATCH] net: sctp: fix memory leak in sctp_send_reset_streams

[Xin Long]

On Sun, Jun 2, 2019 at 9:36 PM Xin Long  wrote:
>
> On Sun, Jun 2, 2019 at 6:52 PM Neil Horman  wrote:
> >
> > On Sun, Jun 02, 2019 at 11:44:29AM +0800, Hillf Danton wrote:
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:036e3431 Merge 
> > > git://git.kernel.org/pub/scm/linux/kernel/g..
> > > git tree:   upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=153cff12a0
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=8f0f63a62bb5b13c
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=6ad9c3bd0a218a2ab41d
> > > compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12561c86a0
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15b76fd8a0
> > >
> > > executing program
> > > executing program
> > > executing program
> > > executing program
> > > executing program
> > > BUG: memory leak
> > > unreferenced object 0x888123894820 (size 32):
> > >   comm "syz-executor045", pid 7267, jiffies 4294943559 (age 13.660s)
> > >   hex dump (first 32 bytes):
> > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> > >   backtrace:
> > > [] kmemleak_alloc_recursive
> > > include/linux/kmemleak.h:55 [inline]
> > > [] slab_post_alloc_hook mm/slab.h:439 [inline]
> > > [] slab_alloc mm/slab.c:3326 [inline]
> > > [] __do_kmalloc mm/slab.c:3658 [inline]
> > > [] __kmalloc+0x161/0x2c0 mm/slab.c:3669
> > > [<3250ed8e>] kmalloc_array include/linux/slab.h:670 [inline]
> > > [<3250ed8e>] kcalloc include/linux/slab.h:681 [inline]
> > > [<3250ed8e>] sctp_send_reset_streams+0x1ab/0x5a0 
> > > net/sctp/stream.c:302
> > > [] sctp_setsockopt_reset_streams 
> > > net/sctp/socket.c:4314 [inline]
> > > [] sctp_setsockopt net/sctp/socket.c:4765 [inline]
> > > [] sctp_setsockopt+0xc23/0x2bf0 
> > > net/sctp/socket.c:4608
> > > [] sock_common_setsockopt+0x38/0x50 
> > > net/core/sock.c:3130
> > > [<9eb87ae7>] __sys_setsockopt+0x98/0x120 net/socket.c:2078
> > > [] __do_sys_setsockopt net/socket.c:2089 [inline]
> > > [] __se_sys_setsockopt net/socket.c:2086 [inline]
> > > [] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
> > > [] do_syscall_64+0x76/0x1a0 
> > > arch/x86/entry/common.c:301
> > > [] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > >
> > >
> > > It was introduced in commit d570a59c5b5f ("sctp: only allow the out stream
> > > reset when the stream outq is empty"), in orde to check stream outqs 
> > > before
> > > sending SCTP_STRRESET_IN_PROGRESS back to the peer of the stream. EAGAIN 
> > > is
> > > returned, however, without the nstr_list slab released, if any outq is 
> > > found
> > > to be non empty.
> > >
> > > Freeing the slab in question before bailing out fixes it.
> > >
> > > Fixes: d570a59c5b5f ("sctp: only allow the out stream reset when the 
> > > stream outq is empty")
> > > Reported-by: syzbot 
> > > 
> > > Reported-by: Marcelo Ricardo Leitner 
> > > Tested-by: Marcelo Ricardo Leitner 
> > > Cc: Xin Long 
> > > Cc: Neil Horman 
> > > Cc: Vlad Yasevich 
> > > Cc: Eric Dumazet 
> > > Signed-off-by: Hillf Danton 
> > > ---
> > > net/sctp/stream.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> > > index 93ed078..d3e2f03 100644
> > > --- a/net/sctp/stream.c
> > > +++ b/net/sctp/stream.c
> > > @@ -310,6 +310,7 @@ int sctp_send_reset_streams(struct sctp_association 
> > > *asoc,
> > >
> > >   if (out && !sctp_stream_outq_is_empty(stream, str_nums, nstr_list)) 
> > > {
> > >   retval = -EAGAIN;
> > > + kfree(nstr_list);
> > >   goto out;
> > >   }
> > >
> > > --
> > >
> > >
> > Acked-by: Neil Horman 
> Reviewed-by: Xin Long 
This fix is not applied, pls resend it with:
to = network dev 
cc = da...@davemloft.net
to = linux-s...@vger.kernel.org
cc = Neil Horman 
cc = Marcelo Ricardo Leitner 

[PATCH] clk: imx8mn: Keep uart clocks on for early console

[Anson . Huang]

From: Anson Huang 

Call imx_register_uart_clocks() API to keep uart clocks enabled
when earlyprintk or earlycon is active.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx8mn.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index 07481a5..ecd1062 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -355,6 +355,14 @@ static const char * const imx8mn_clko2_sels[] = 
{"osc_24m", "sys_pll2_200m", "sy
 static struct clk *clks[IMX8MN_CLK_END];
 static struct clk_onecell_data clk_data;
 
+static struct clk ** const uart_clks[] = {
+   [IMX8MN_CLK_UART1_ROOT],
+   [IMX8MN_CLK_UART2_ROOT],
+   [IMX8MN_CLK_UART3_ROOT],
+   [IMX8MN_CLK_UART4_ROOT],
+   NULL
+};
+
 static int imx8mn_clocks_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -612,6 +620,8 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
goto unregister_clks;
}
 
+   imx_register_uart_clocks(uart_clks);
+
return 0;
 
 unregister_clks:
-- 
2.7.4

Re: [PATCH] rcu: Make jiffies_till_sched_qs writable

[Byungchul Park]

On Tue, Jul 23, 2019 at 09:54:03AM -0700, Paul E. McKenney wrote:
> On Tue, Jul 23, 2019 at 06:47:17AM -0700, Paul E. McKenney wrote:
> > On Tue, Jul 23, 2019 at 08:05:21PM +0900, Byungchul Park wrote:
> > > On Fri, Jul 19, 2019 at 04:33:56PM -0400, Joel Fernandes wrote:
> > > > On Fri, Jul 19, 2019 at 3:57 PM Paul E. McKenney 
> > > >  wrote:
> > > > >
> > > > > On Fri, Jul 19, 2019 at 06:57:58PM +0900, Byungchul Park wrote:
> > > > > > On Fri, Jul 19, 2019 at 4:43 PM Paul E. McKenney 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thu, Jul 18, 2019 at 08:52:52PM -0400, Joel Fernandes wrote:
> > > > > > > > On Thu, Jul 18, 2019 at 8:40 PM Byungchul Park 
> > > > > > > >  wrote:
> > > > > > > > [snip]
> > > > > > > > > > - There is a bug in the CPU stopper machinery itself 
> > > > > > > > > > preventing it
> > > > > > > > > > from scheduling the stopper on Y. Even though Y is not 
> > > > > > > > > > holding up the
> > > > > > > > > > grace period.
> > > > > > > > >
> > > > > > > > > Or any thread on Y is busy with preemption/irq disabled 
> > > > > > > > > preventing the
> > > > > > > > > stopper from being scheduled on Y.
> > > > > > > > >
> > > > > > > > > Or something is stuck in ttwu() to wake up the stopper on Y 
> > > > > > > > > due to any
> > > > > > > > > scheduler locks such as pi_lock or rq->lock or something.
> > > > > > > > >
> > > > > > > > > I think what you mentioned can happen easily.
> > > > > > > > >
> > > > > > > > > Basically we would need information about preemption/irq 
> > > > > > > > > disabled
> > > > > > > > > sections on Y and scheduler's current activity on every cpu 
> > > > > > > > > at that time.
> > > > > > > >
> > > > > > > > I think all that's needed is an NMI backtrace on all CPUs. An 
> > > > > > > > ARM we
> > > > > > > > don't have NMI solutions and only IPI or interrupt based 
> > > > > > > > backtrace
> > > > > > > > works which should at least catch and the preempt disable and 
> > > > > > > > softirq
> > > > > > > > disable cases.
> > > > > > >
> > > > > > > True, though people with systems having hundreds of CPUs might not
> > > > > > > thank you for forcing an NMI backtrace on each of them.  Is it 
> > > > > > > possible
> > > > > > > to NMI only the ones that are holding up the CPU stopper?
> > > > > >
> > > > > > What a good idea! I think it's possible!
> > > > > >
> > > > > > But we need to think about the case NMI doesn't work when the
> > > > > > holding-up was caused by IRQ disabled.
> > > > > >
> > > > > > Though it's just around the corner of weekend, I will keep thinking
> > > > > > on it during weekend!
> > > > >
> > > > > Very good!
> > > > 
> > > > Me too will think more about it ;-) Agreed with point about 100s of
> > > > CPUs usecase,
> > > > 
> > > > Thanks, have a great weekend,
> > > 
> > > BTW, if there's any long code section with irq/preemption disabled, then
> > > the problem would be not only about RCU stall. And we can also use
> > > latency tracer or something to detect the bad situation.
> > > 
> > > So in this case, sending ipi/nmi to the CPUs where the stoppers cannot
> > > to be scheduled does not give us additional meaningful information.
> > > 
> > > I think Paul started to think about this to solve some real problem. I
> > > seriously love to help RCU and it's my pleasure to dig deep into kind of
> > > RCU stuff, but I've yet to define exactly what problem is. Sorry.
> > > 
> > > Could you share the real issue? I think you don't have to reproduce it.
> > > Just sharing the issue that you got inspired from is enough. Then I
> > > might be able to develop 'how' with Joel! :-) It's our pleasure!
> > 
> > It is unfortunately quite intermittent.  I was hoping to find a way
> > to make it happen more often.  Part of the underlying problem appears
> > to be lock contention, in that reducing contention made it even more
> > intermittent.  Which is good in general, but not for exercising the
> > CPU-stopper issue.
> > 
> > But perhaps your hardware will make this happen more readily than does
> > mine.  The repeat-by is simple, namely run TREE04 on branch "dev" on an
> > eight-CPU system.  It appear that the number of CPUs used by the test
> > should match the number available on the system that you are running on,
> > though perhaps affinity could allow mismatches.
> > 
> > So why not try it and see what happens?
> 
> And another potential issue causing this is a CONFIG_NO_HZ_FULL=y

I see. This provides more insight into the problem.

Thanks,
Byungchul

> kernel running in kernel mode (rcutorture on the one hand and callback
> invocation on the other) for extended periods of time with the scheduling
> clock disabled.  Just started the tests for this.  They will be running
> for quite some time, which this week is a good thing.  ;-)
> 
>   Thanx, Paul

Re: [PATCH] rcu: Make jiffies_till_sched_qs writable

[Byungchul Park]

On Tue, Jul 23, 2019 at 06:47:17AM -0700, Paul E. McKenney wrote:
> On Tue, Jul 23, 2019 at 08:05:21PM +0900, Byungchul Park wrote:
> > On Fri, Jul 19, 2019 at 04:33:56PM -0400, Joel Fernandes wrote:
> > > On Fri, Jul 19, 2019 at 3:57 PM Paul E. McKenney  
> > > wrote:
> > > >
> > > > On Fri, Jul 19, 2019 at 06:57:58PM +0900, Byungchul Park wrote:
> > > > > On Fri, Jul 19, 2019 at 4:43 PM Paul E. McKenney 
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, Jul 18, 2019 at 08:52:52PM -0400, Joel Fernandes wrote:
> > > > > > > On Thu, Jul 18, 2019 at 8:40 PM Byungchul Park 
> > > > > > >  wrote:
> > > > > > > [snip]
> > > > > > > > > - There is a bug in the CPU stopper machinery itself 
> > > > > > > > > preventing it
> > > > > > > > > from scheduling the stopper on Y. Even though Y is not 
> > > > > > > > > holding up the
> > > > > > > > > grace period.
> > > > > > > >
> > > > > > > > Or any thread on Y is busy with preemption/irq disabled 
> > > > > > > > preventing the
> > > > > > > > stopper from being scheduled on Y.
> > > > > > > >
> > > > > > > > Or something is stuck in ttwu() to wake up the stopper on Y due 
> > > > > > > > to any
> > > > > > > > scheduler locks such as pi_lock or rq->lock or something.
> > > > > > > >
> > > > > > > > I think what you mentioned can happen easily.
> > > > > > > >
> > > > > > > > Basically we would need information about preemption/irq 
> > > > > > > > disabled
> > > > > > > > sections on Y and scheduler's current activity on every cpu at 
> > > > > > > > that time.
> > > > > > >
> > > > > > > I think all that's needed is an NMI backtrace on all CPUs. An ARM 
> > > > > > > we
> > > > > > > don't have NMI solutions and only IPI or interrupt based backtrace
> > > > > > > works which should at least catch and the preempt disable and 
> > > > > > > softirq
> > > > > > > disable cases.
> > > > > >
> > > > > > True, though people with systems having hundreds of CPUs might not
> > > > > > thank you for forcing an NMI backtrace on each of them.  Is it 
> > > > > > possible
> > > > > > to NMI only the ones that are holding up the CPU stopper?
> > > > >
> > > > > What a good idea! I think it's possible!
> > > > >
> > > > > But we need to think about the case NMI doesn't work when the
> > > > > holding-up was caused by IRQ disabled.
> > > > >
> > > > > Though it's just around the corner of weekend, I will keep thinking
> > > > > on it during weekend!
> > > >
> > > > Very good!
> > > 
> > > Me too will think more about it ;-) Agreed with point about 100s of
> > > CPUs usecase,
> > > 
> > > Thanks, have a great weekend,
> > 
> > BTW, if there's any long code section with irq/preemption disabled, then
> > the problem would be not only about RCU stall. And we can also use
> > latency tracer or something to detect the bad situation.
> > 
> > So in this case, sending ipi/nmi to the CPUs where the stoppers cannot
> > to be scheduled does not give us additional meaningful information.
> > 
> > I think Paul started to think about this to solve some real problem. I
> > seriously love to help RCU and it's my pleasure to dig deep into kind of
> > RCU stuff, but I've yet to define exactly what problem is. Sorry.
> > 
> > Could you share the real issue? I think you don't have to reproduce it.
> > Just sharing the issue that you got inspired from is enough. Then I
> > might be able to develop 'how' with Joel! :-) It's our pleasure!
> 
> It is unfortunately quite intermittent.  I was hoping to find a way
> to make it happen more often.  Part of the underlying problem appears
> to be lock contention, in that reducing contention made it even more
> intermittent.  Which is good in general, but not for exercising the
> CPU-stopper issue.
> 
> But perhaps your hardware will make this happen more readily than does
> mine.  The repeat-by is simple, namely run TREE04 on branch "dev" on an
> eight-CPU system.  It appear that the number of CPUs used by the test
> should match the number available on the system that you are running on,
> though perhaps affinity could allow mismatches.
> 
> So why not try it and see what happens?

Thank you. I'll try it too.

[PATCH] pinctrl: aspeed-g5: Delay acquisition of regmaps

[Andrew Jeffery]

While sorting out some devicetree issues I found that the pinctrl driver
was failing to acquire its GFX regmap even though the phandle was
present in the devicetree:

[0.124190] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: No GFX phandle 
found, some mux configurations may fail

Without access to the GFX regmap we fail to configure the mux for the
VPO function:

[1.548866] pinctrl core: add 1 pinctrl maps
[1.549826] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: found group 
selector 164 for VPO
[1.550638] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 144 
(V20) for 1e6e6000.display
[1.551346] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 145 
(U19) for 1e6e6000.display
...
[1.562057] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 218 
(T22) for 1e6e6000.display
[1.562541] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 219 
(R20) for 1e6e6000.display
[1.563113] Muxing pin 144 for VPO
[1.563456] Want SCU8C[0x0001]=0x1, got 0x0 from 0x
[1.564624] aspeed_gfx 1e6e6000.display: Error applying setting, reverse 
things back

This turned out to be a simple problem of timing: The ASPEED pinctrl
driver is probed during arch_initcall(), while GFX is processed much
later. As such the GFX syscon is not yet registered during the pinctrl
probe() and we get an -EPROBE_DEFER when we try to look it up, however
we must not defer probing the pinctrl driver for the inability to mux
some GFX-related functions.

Switch to lazily grabbing the regmaps when they're first required by the
mux configuration. This generates a bit of noise in the patch as we have
to drop the `const` qualifier on arguments for several function
prototypes, but has the benefit of working.

I've smoke tested this for the ast2500-evb under qemu with a dummy
graphics device. We now succeed in our attempts to configure the SoC's
VPO pinmux function.

Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX 
controllers")
Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c |  2 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 92 +++---
 drivers/pinctrl/aspeed/pinctrl-aspeed.c| 12 ++-
 drivers/pinctrl/aspeed/pinmux-aspeed.h |  5 +-
 4 files changed, 74 insertions(+), 37 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index 384396cbb22d..22256576b69a 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -2412,7 +2412,7 @@ static const struct aspeed_pin_config aspeed_g4_configs[] 
= {
{ PIN_CONFIG_INPUT_DEBOUNCE, { C14, B14 }, SCUA8, 27 },
 };
 
-static int aspeed_g4_sig_expr_set(const struct aspeed_pinmux_data *ctx,
+static int aspeed_g4_sig_expr_set(struct aspeed_pinmux_data *ctx,
  const struct aspeed_sig_expr *expr,
  bool enable)
 {
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 053101f795a2..ba6438ac4d72 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -2507,6 +2507,61 @@ static struct aspeed_pin_config aspeed_g5_configs[] = {
{ PIN_CONFIG_INPUT_DEBOUNCE, { A20, B19 }, SCUA8, 27 },
 };
 
+static struct regmap *aspeed_g5_acquire_regmap(struct aspeed_pinmux_data *ctx,
+  int ip)
+{
+   if (ip == ASPEED_IP_SCU) {
+   WARN(!ctx->maps[ip], "Missing SCU syscon!");
+   return ctx->maps[ip];
+   }
+
+   if (ip >= ASPEED_NR_PINMUX_IPS)
+   return ERR_PTR(-EINVAL);
+
+   if (likely(ctx->maps[ip]))
+   return ctx->maps[ip];
+
+   if (ip == ASPEED_IP_GFX) {
+   struct device_node *node;
+   struct regmap *map;
+
+   node = of_parse_phandle(ctx->dev->of_node,
+   "aspeed,external-nodes", 0);
+   if (node) {
+   map = syscon_node_to_regmap(node);
+   of_node_put(node);
+   if (IS_ERR(map))
+   return map;
+   } else
+   return ERR_PTR(-ENODEV);
+
+   ctx->maps[ASPEED_IP_GFX] = map;
+   dev_dbg(ctx->dev, "Acquired GFX regmap");
+   return map;
+   }
+
+   if (ip == ASPEED_IP_LPC) {
+   struct device_node *node;
+   struct regmap *map;
+
+   node = of_parse_phandle(ctx->dev->of_node,
+   "aspeed,external-nodes", 1);
+   if (node) {
+   map = syscon_node_to_regmap(node->parent);
+   of_node_put(node);
+   if (IS_ERR(map))
+   return map;
+  

Re: WARNING in __mmdrop

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 10:17:14AM +0800, Jason Wang wrote:
> 
> On 2019/7/23 下午11:02, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 09:34:29PM +0800, Jason Wang wrote:
> > > On 2019/7/23 下午6:27, Michael S. Tsirkin wrote:
> > > > > Yes, since there could be multiple co-current invalidation requests. 
> > > > > We need
> > > > > count them to make sure we don't pin wrong pages.
> > > > > 
> > > > > 
> > > > > > I also wonder about ordering. kvm has this:
> > > > > >   /*
> > > > > > * Used to check for invalidations in progress, of the 
> > > > > > pfn that is
> > > > > > * returned by pfn_to_pfn_prot below.
> > > > > > */
> > > > > >mmu_seq = kvm->mmu_notifier_seq;
> > > > > >/*
> > > > > > * Ensure the read of mmu_notifier_seq isn't reordered 
> > > > > > with PTE reads in
> > > > > > * gfn_to_pfn_prot() (which calls get_user_pages()), so 
> > > > > > that we don't
> > > > > > * risk the page we get a reference to getting unmapped 
> > > > > > before we have a
> > > > > > * chance to grab the mmu_lock without 
> > > > > > mmu_notifier_retry() noticing.
> > > > > > *
> > > > > > * This smp_rmb() pairs with the effective smp_wmb() of 
> > > > > > the combination
> > > > > > * of the pte_unmap_unlock() after the PTE is zapped, 
> > > > > > and the
> > > > > > * spin_lock() in 
> > > > > > kvm_mmu_notifier_invalidate_() before
> > > > > > * mmu_notifier_seq is incremented.
> > > > > > */
> > > > > >smp_rmb();
> > > > > > 
> > > > > > does this apply to us? Can't we use a seqlock instead so we do
> > > > > > not need to worry?
> > > > > I'm not familiar with kvm MMU internals, but we do everything under of
> > > > > mmu_lock.
> > > > > 
> > > > > Thanks
> > > > I don't think this helps at all.
> > > > 
> > > > There's no lock between checking the invalidate counter and
> > > > get user pages fast within vhost_map_prefetch. So it's possible
> > > > that get user pages fast reads PTEs speculatively before
> > > > invalidate is read.
> > > > 
> > > > -- 
> > > 
> > > In vhost_map_prefetch() we do:
> > > 
> > >      spin_lock(>mmu_lock);
> > > 
> > >          ...
> > > 
> > >      err = -EFAULT;
> > >      if (vq->invalidate_count)
> > >      goto err;
> > > 
> > >      ...
> > > 
> > >      npinned = __get_user_pages_fast(uaddr->uaddr, npages,
> > >      uaddr->write, pages);
> > > 
> > >      ...
> > > 
> > >          spin_unlock(>mmu_lock);
> > > 
> > > Is this not sufficient?
> > > 
> > > Thanks
> > So what orders __get_user_pages_fast wrt invalidate_count read?
> 
> 
> So in invalidate_end() callback we have:
> 
> spin_lock(>mmu_lock);
> --vq->invalidate_count;
>     spin_unlock(>mmu_lock);
> 
> 
> So even PTE is read speculatively before reading invalidate_count (only in
> the case of invalidate_count is zero). The spinlock has guaranteed that we
> won't read any stale PTEs.
> 
> Thanks

I'm sorry I just do not get the argument.
If you want to order two reads you need an smp_rmb
or stronger between them executed on the same CPU.

Executing any kind of barrier on another CPU
will have no ordering effect on the 1st one.


So if CPU1 runs the prefetch, and CPU2 runs invalidate
callback, read of invalidate counter on CPU1 can bypass
read of PTE on CPU1 unless there's a barrier
in between, and nothing CPU2 does can affect that outcome.


What did I miss?

> 
> > 

[PATCH 0/3] ARM: dts: aspeed: Deprecate g[45]-style compatibles

[Andrew Jeffery]

Hello,

Joel and I decided that going forward we're not going to name compatibles along
the lines of SoC generations, so discourage any further attempts by removing
the remaining instances.

It's probably best if we push the three patches all through one tree rather
than fragmenting. Is everyone happy if Joel applies them to the aspeed tree?

Cheers,

Andrew

Andrew Jeffery (3):
  dts: ARM: aspeed: Migrate away from aspeed,g[45].* compatibles
  pinctrl: aspeed: Document existence of deprecated compatibles
  dt-bindings: aspeed: Remove mention of deprecated compatibles

 Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 2 --
 Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt   | 2 --
 .../devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml  | 5 +
 .../devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml  | 4 +---
 arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
 arch/arm/boot/dts/aspeed-g5.dtsi | 2 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c   | 4 
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c   | 4 
 8 files changed, 12 insertions(+), 13 deletions(-)

-- 
2.20.1

Re: [PATCH net-next v2 0/8] Use dev_get_drvdata where possible

[Chuhong Yuan]

On Wed, Jul 24, 2019 at 2:05 PM Chuhong Yuan  wrote:
>
> These patches use dev_get_drvdata instead of
> using to_pci_dev + pci_get_drvdata to make
> code simpler where possible.
>
> Changelog:
>
> v1 -> v2:
> - Change pci_set_drvdata to dev_set_drvdata
>   to keep consistency.
>

Hi all,
I checked the cases which mentioned the consistency
of get/set_drvdata usages.
The cases' commit IDs are
488d040e3a3452a0dceef5d3ec4f61942262f57f
b77c98780e682fe780d899b91543769d4cf94585

After checking, I think that the consistency problem
refers to inconsistency between probe and remove.
But the changes of these patches are not related
to probe and remove.

So I think the previously sent and applied v1 patches
which do not change pci_set_drvdata to dev_set_drvdata
are okay.
Therefore there may be no need to use these v2 patches.

Regards,
Chuhong


> Chuhong Yuan (8):
>   net: 3com: 3c59x: Use dev_get_drvdata
>   net: atheros: Use dev_get_drvdata
>   net: broadcom: Use dev_get_drvdata
>   e1000e: Use dev_get_drvdata where possible
>   fm10k: Use dev_get_drvdata
>   i40e: Use dev_get_drvdata
>   igb: Use dev_get_drvdata where possible
>   net: jme: Use dev_get_drvdata
>
>  drivers/net/ethernet/3com/3c59x.c   |  8 +++-
>  drivers/net/ethernet/atheros/alx/main.c |  8 +++-
>  drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 10 --
>  drivers/net/ethernet/atheros/atlx/atl1.c|  8 +++-
>  drivers/net/ethernet/broadcom/bnx2.c|  8 +++-
>  drivers/net/ethernet/broadcom/bnxt/bnxt.c   |  8 +++-
>  drivers/net/ethernet/broadcom/tg3.c |  8 +++-
>  drivers/net/ethernet/intel/e1000e/netdev.c  |  9 -
>  drivers/net/ethernet/intel/fm10k/fm10k_pci.c|  6 +++---
>  drivers/net/ethernet/intel/i40e/i40e_main.c | 10 --
>  drivers/net/ethernet/intel/igb/igb_main.c   |  5 ++---
>  drivers/net/ethernet/jme.c  |  8 +++-
>  12 files changed, 38 insertions(+), 58 deletions(-)
>
> --
> 2.20.1
>

[PATCH 1/3] dts: ARM: aspeed: Migrate away from aspeed,g[45].* compatibles

[Andrew Jeffery]

Use the SoC-specific compatible strings instead.

Signed-off-by: Andrew Jeffery 
---
 arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
 arch/arm/boot/dts/aspeed-g5.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index dd4b0b15afcf..7f06dc21dc19 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -162,7 +162,7 @@
#reset-cells = <1>;
 
pinctrl: pinctrl {
-   compatible = "aspeed,g4-pinctrl";
+   compatible = "aspeed,ast2400-pinctrl";
};
 
p2a: p2a-control {
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 5b1ca265c2ce..04c97138e18b 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -215,7 +215,7 @@
#reset-cells = <1>;
 
pinctrl: pinctrl {
-   compatible = "aspeed,g5-pinctrl";
+   compatible = "aspeed,ast2500-pinctrl";
aspeed,external-nodes = < >;
 
};
-- 
2.20.1

[PATCH 3/3] dt-bindings: aspeed: Remove mention of deprecated compatibles

[Andrew Jeffery]

Guide readers away from using the aspeed,g[45].* compatible patterns.

Signed-off-by: Andrew Jeffery 
---
 Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 2 --
 Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt   | 2 --
 .../devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml  | 5 +
 .../devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml  | 4 +---
 4 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
index ce8cf0ec6279..4d92c0bb6687 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
@@ -4,9 +4,7 @@ configuring elements such as clocks, pinmux, and reset.
 Required properties:
 - compatible:  One of:
"aspeed,ast2400-scu", "syscon", "simple-mfd"
-   "aspeed,g4-scu", "syscon", "simple-mfd"
"aspeed,ast2500-scu", "syscon", "simple-mfd"
-   "aspeed,g5-scu", "syscon", "simple-mfd"
 
 - reg: contains the offset and length of the SCU memory region
 - #clock-cells: should be set to <1> - the system controller is also a
diff --git a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt 
b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
index 854bd67ffec6..0e1fa5bc6a30 100644
--- a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
+++ b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
@@ -26,9 +26,7 @@ property:
 
 - compatible : Should be one of the following:
"aspeed,ast2400-scu", "syscon", "simple-mfd"
-   "aspeed,g4-scu", "syscon", "simple-mfd"
"aspeed,ast2500-scu", "syscon", "simple-mfd"
-   "aspeed,g5-scu", "syscon", "simple-mfd"
 
 Example
 ===
diff --git 
a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
index 125599a2dc5e..9368e4b6d4d0 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
@@ -15,16 +15,13 @@ description: |+
 
   - compatible: Should be one of the following:
 "aspeed,ast2400-scu", "syscon", "simple-mfd"
-"aspeed,g4-scu", "syscon", "simple-mfd"
 
   Refer to the the bindings described in
   Documentation/devicetree/bindings/mfd/syscon.txt
 
 properties:
   compatible:
-enum:
-  - aspeed,ast2400-pinctrl
-  - aspeed,g4-pinctrl
+const: aspeed,ast2400-pinctrl
 
 patternProperties:
   '^.*$':
diff --git 
a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
index 3e6d85318577..939fb755a6db 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
@@ -22,9 +22,7 @@ description: |+
 
 properties:
   compatible:
-enum:
-  - aspeed,ast2500-pinctrl
-  - aspeed,g5-pinctrl
+const: aspeed,ast2500-pinctrl
   aspeed,external-nodes:
 minItems: 2
 maxItems: 2
-- 
2.20.1

[PATCH 2/3] pinctrl: aspeed: Document existence of deprecated compatibles

[Andrew Jeffery]

Otherwise they look odd in the face of not being listed in the bindings
documents.

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 4 
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 4 
 2 files changed, 8 insertions(+)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index 384396cbb22d..0e087fe759d2 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -2531,6 +2531,10 @@ static int aspeed_g4_pinctrl_probe(struct 
platform_device *pdev)
 
 static const struct of_device_id aspeed_g4_pinctrl_of_match[] = {
{ .compatible = "aspeed,ast2400-pinctrl", },
+   /*
+* The aspeed,g4-pinctrl compatible has been removed the from the
+* bindings, but keep the match in case of old devicetrees.
+*/
{ .compatible = "aspeed,g4-pinctrl", },
{ },
 };
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 053101f795a2..49255802735b 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -2676,6 +2676,10 @@ static int aspeed_g5_pinctrl_probe(struct 
platform_device *pdev)
 
 static const struct of_device_id aspeed_g5_pinctrl_of_match[] = {
{ .compatible = "aspeed,ast2500-pinctrl", },
+   /*
+* The aspeed,g5-pinctrl compatible has been removed the from the
+* bindings, but keep the match in case of old devicetrees.
+*/
{ .compatible = "aspeed,g5-pinctrl", },
{ },
 };
-- 
2.20.1

[PATCH 3/3] platform/x86: dell-wmi: Use existing defined KBD_LED_* magic values

[Rhys Kidd]

These values have already been defined in platform/x86/dell-smbios.h

Signed-off-by: Rhys Kidd 
---
 drivers/platform/x86/dell-wmi.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 68a8a4eba4e3..fc33c38f5f82 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -311,13 +311,13 @@ static const struct key_entry dell_wmi_keymap_type_0011[] 
= {
{ KE_IGNORE, 0xfff1, { KEY_RESERVED } },
 
/* Keyboard backlight level changed */
-   { KE_IGNORE, 0x01e1, { KEY_RESERVED } },
-   { KE_IGNORE, 0x01e2, { KEY_RESERVED } },
-   { KE_IGNORE, 0x01e3, { KEY_RESERVED } },
-   { KE_IGNORE, 0x02ea, { KEY_RESERVED } },
-   { KE_IGNORE, 0x02eb, { KEY_RESERVED } },
-   { KE_IGNORE, 0x02ec, { KEY_RESERVED } },
-   { KE_IGNORE, 0x02f6, { KEY_RESERVED } },
+   { KE_IGNORE, KBD_LED_OFF_TOKEN,  { KEY_RESERVED } },
+   { KE_IGNORE, KBD_LED_ON_TOKEN,   { KEY_RESERVED } },
+   { KE_IGNORE, KBD_LED_AUTO_TOKEN, { KEY_RESERVED } },
+   { KE_IGNORE, KBD_LED_AUTO_25_TOKEN,  { KEY_RESERVED } },
+   { KE_IGNORE, KBD_LED_AUTO_50_TOKEN,  { KEY_RESERVED } },
+   { KE_IGNORE, KBD_LED_AUTO_75_TOKEN,  { KEY_RESERVED } },
+   { KE_IGNORE, KBD_LED_AUTO_100_TOKEN, { KEY_RESERVED } },
 };
 
 static void dell_wmi_process_key(struct wmi_device *wdev, int type, int code)
-- 
2.20.1

[PATCH 2/3] platform/x86: dell-wmi: Ignore keyboard backlight change KBD_LED_AUTO_TOKEN

[Rhys Kidd]

There's a wmi event generated by dell-wmi when pressing keyboard backlight
toggle key:
[1224178.355650] dell_wmi: Unknown key with type 0x0011 and code 0x01e3 pressed

This event is for notification purposes, let's ignore it.

Signed-off-by: Rhys Kidd 
---
 drivers/platform/x86/dell-wmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index ae331ac119a1..68a8a4eba4e3 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -313,6 +313,7 @@ static const struct key_entry dell_wmi_keymap_type_0011[] = 
{
/* Keyboard backlight level changed */
{ KE_IGNORE, 0x01e1, { KEY_RESERVED } },
{ KE_IGNORE, 0x01e2, { KEY_RESERVED } },
+   { KE_IGNORE, 0x01e3, { KEY_RESERVED } },
{ KE_IGNORE, 0x02ea, { KEY_RESERVED } },
{ KE_IGNORE, 0x02eb, { KEY_RESERVED } },
{ KE_IGNORE, 0x02ec, { KEY_RESERVED } },
-- 
2.20.1

[PATCH 1/3] platform/x86: dell-wmi: Ignore keyboard backlight change KBD_LED_ON_TOKEN

[Rhys Kidd]

There's a wmi event generated by dell-wmi when pressing keyboard backlight
toggle key:
[1224203.948894] dell_wmi: Unknown key with type 0x0011 and code 0x01e2 pressed

This event is for notification purposes, let's ignore it.

Signed-off-by: Rhys Kidd 
---
 drivers/platform/x86/dell-wmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 1f565fb69098..ae331ac119a1 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -312,6 +312,7 @@ static const struct key_entry dell_wmi_keymap_type_0011[] = 
{
 
/* Keyboard backlight level changed */
{ KE_IGNORE, 0x01e1, { KEY_RESERVED } },
+   { KE_IGNORE, 0x01e2, { KEY_RESERVED } },
{ KE_IGNORE, 0x02ea, { KEY_RESERVED } },
{ KE_IGNORE, 0x02eb, { KEY_RESERVED } },
{ KE_IGNORE, 0x02ec, { KEY_RESERVED } },
-- 
2.20.1

Re: [v4 PATCH 2/2] mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind

[Vlastimil Babka]

On 7/23/19 7:35 AM, Yang Shi wrote:
> 
> 
> On 7/22/19 6:02 PM, Andrew Morton wrote:
>> On Mon, 22 Jul 2019 09:25:09 +0200 Vlastimil Babka  wrote:
>>
 since there may be pages off LRU temporarily.  We should migrate other
 pages if MPOL_MF_MOVE* is specified.  Set has_unmovable flag if some
 paged could not be not moved, then return -EIO for mbind() eventually.

 With this change the above test would return -EIO as expected.

 Cc: Vlastimil Babka 
 Cc: Michal Hocko 
 Cc: Mel Gorman 
 Signed-off-by: Yang Shi 
>>> Reviewed-by: Vlastimil Babka 
>> Thanks.
>>
>> I'm a bit surprised that this doesn't have a cc:stable.  Did we
>> consider that?
> 
> The VM_BUG just happens on 4.9, and it is enabled only by CONFIG_VM. For 
> post-4.9 kernel, this fixes the semantics of mbind which should be not a 
> regression IMHO.

4.9 is a LTS kernel, so perhaps worth trying?

>>
>> Also, is this patch dependent upon "mm: mempolicy: make the behavior
>> consistent when MPOL_MF_MOVE* and MPOL_MF_STRICT were specified"?
>> Doesn't look that way..
> 
> No, it depends on patch #1.
> 
>>
>> Also, I have a note that you had concerns with "mm: mempolicy: make the
>> behavior consistent when MPOL_MF_MOVE* and MPOL_MF_STRICT were
>> specified".  What is the status now?
> 
> Vlastimil had given his Reviewed-by.

Yes, the concerns were resolved.

Re: [PATCH v1] extcon: arizona: Switch to use device_property_count_u32()

[Charles Keepax]

On Tue, Jul 23, 2019 at 08:40:21PM +0300, Andy Shevchenko wrote:
> Use use device_property_count_u32() directly, that makes code neater.
> 
> Signed-off-by: Andy Shevchenko 
> ---

Acked-by: Charles Keepax 

Thanks,
Charles

Re: Backlight in motorola Droid 4

[Pavel Machek]

On Tue 2019-07-23 10:53:16, Dan Murphy wrote:
> Pavel
> 
> On 7/22/19 3:59 PM, Pavel Machek wrote:
> >Hi!
> >
> >So now the backlight LED can be controlled. Good. (And thanks!)
> >
> >But I seem to remember that backlight had range from "is it really on?"
> >to "very bright"; now it seems to have range from "bright" to "very
> >bright".
> >
> >Any ideas what goes on there?
> 
> In the LM3552 driver we are changing the Full scale brightness registers for
> the
> 
> specific control bank.
> 
> #define LM3532_REG_CTRL_A_BRT    0x17
> #define LM3532_REG_CTRL_B_BRT    0x19
> #define LM3532_REG_CTRL_C_BRT    0x1b

Yep, and those registers are 5-bit linear...

> In the ti-lmu code the ALS zones were being modified not the control bank
> brightness.
> 
> #define LM3532_REG_BRT_A            0x70    /* zone 0 */
> #define LM3532_REG_BRT_B            0x76    /* zone 1 */
> #define LM3532_REG_BRT_C            0x7C    /* zone 2 */

...while these allow 14-bits of control.

That explains very limited range of backlight control.

Do you have any plans to change that?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v7 2/4] uprobe: use original page when all uprobes are removed

[Song Liu]

> On Jul 15, 2019, at 8:25 AM, Oleg Nesterov  wrote:
> 
> On 06/25, Song Liu wrote:
>> 
>> This patch allows uprobe to use original page when possible (all uprobes
>> on the page are already removed).
> 
> I can't review. I do not understand vm enough.
> 
>> +if (!is_register) {
>> +struct page *orig_page;
>> +pgoff_t index;
>> +
>> +index = vaddr_to_offset(vma, vaddr & PAGE_MASK) >> PAGE_SHIFT;
>> +orig_page = find_get_page(vma->vm_file->f_inode->i_mapping,
>> +  index);
>> +
>> +if (orig_page) {
>> +if (pages_identical(new_page, orig_page)) {
> 
> Shouldn't we at least check PageUptodate?

For page cache, we only do ClearPageUptodate() on read failures, so 
this should be really rare case. But I guess we can check anyway. 

> 
> and I am a bit surprised there is no simple way to unmap the old page
> in this case... 

The easiest way I have found requires flush_cache_page() plus a few
mmu_notifier calls around it. I think current solution is better than
that, as it saves a page fault. 

Thanks,
Song

Re: [PATCH v5 04/13] media: rc: sunxi: Add RXSTA bits definition

[Maxime Ripard]

On Wed, Jul 24, 2019 at 06:39:37AM +0100, Sean Young wrote:
> On Tue, Jul 23, 2019 at 09:04:40AM +0200, Maxime Ripard wrote:
> > Hi Sean,
> >
> > On Tue, Jul 23, 2019 at 07:25:57AM +0100, Sean Young wrote:
> > > On Mon, Jul 15, 2019 at 01:12:45PM +0100, Sean Young wrote:
> > > > On Sun, Jul 14, 2019 at 04:32:22PM +0200, Clément Péron wrote:
> > > > > Hi Sean,
> > > > >
> > > > > You acked the whole v3 series but this patch has been introduced in v5
> > > > > could you ack this one too?
> > > >
> > > > Acked-by: Sean Young 
> > >
> > > So who's tree should this series go through? It seems mostly device tree.
> > > Alternatively I'm happy to try it get merged via the media tree.
> >
> > Ideally the media bits should go through the media tree, the DT bits
> > will go through arm-soc
> >
> > So you can apply the patches 1-4, 7 and 10, I'll apply the rest.
> >
> > Does that work for you?
>
> Works for me, I'll add them to my next pull request to Mauro.

Applied 5, 6, 8, 9 and 11 to 13.

Thanks!
Maxmie

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH v3 7/7] backlight: gpio: use a helper variable for >dev

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Instead of dereferencing pdev each time, use a helper variable for
the associated device pointer.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/video/backlight/gpio_backlight.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/gpio_backlight.c 
b/drivers/video/backlight/gpio_backlight.c
index cd6a75bca9cc..7dc4f90d926b 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -54,29 +54,29 @@ static const struct backlight_ops gpio_backlight_ops = {
 
 static int gpio_backlight_probe(struct platform_device *pdev)
 {
-   struct gpio_backlight_platform_data *pdata =
-   dev_get_platdata(>dev);
+   struct device *dev = >dev;
+   struct gpio_backlight_platform_data *pdata = dev_get_platdata(dev);
struct backlight_properties props;
struct backlight_device *bl;
struct gpio_backlight *gbl;
enum gpiod_flags flags;
int ret, def_value;
 
-   gbl = devm_kzalloc(>dev, sizeof(*gbl), GFP_KERNEL);
+   gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL);
if (gbl == NULL)
return -ENOMEM;
 
if (pdata)
gbl->fbdev = pdata->fbdev;
 
-   def_value = device_property_read_bool(>dev, "default-on");
+   def_value = device_property_read_bool(dev, "default-on");
flags = def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
 
-   gbl->gpiod = devm_gpiod_get(>dev, NULL, flags);
+   gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
if (IS_ERR(gbl->gpiod)) {
ret = PTR_ERR(gbl->gpiod);
if (ret != -EPROBE_DEFER) {
-   dev_err(>dev,
+   dev_err(dev,
"Error: The gpios parameter is missing or 
invalid.\n");
}
return ret;
@@ -85,11 +85,10 @@ static int gpio_backlight_probe(struct platform_device 
*pdev)
memset(, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = 1;
-   bl = devm_backlight_device_register(>dev, dev_name(>dev),
-   >dev, gbl, _backlight_ops,
-   );
+   bl = devm_backlight_device_register(dev, dev_name(dev), dev, gbl,
+   _backlight_ops, );
if (IS_ERR(bl)) {
-   dev_err(>dev, "failed to register backlight\n");
+   dev_err(dev, "failed to register backlight\n");
return PTR_ERR(bl);
}
 
-- 
2.21.0

[PATCH v3 1/7] sh: ecovec24: add additional properties to the backlight device

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Add a GPIO lookup entry and a device property for GPIO backlight to the
board file. Tie them to the platform device which is now registered using
platform_device_register_full() because of the properties. These changes
are inactive now but will be used once the gpio backlight driver is
modified.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Andy Shevchenko 
---
 arch/sh/boards/mach-ecovec24/setup.c | 30 +++-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c 
b/arch/sh/boards/mach-ecovec24/setup.c
index f402aa741bf3..6926bb3865b9 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -371,6 +371,19 @@ static struct platform_device lcdc_device = {
},
 };
 
+static struct gpiod_lookup_table gpio_backlight_lookup = {
+   .dev_id = "gpio-backlight.0",
+   .table = {
+   GPIO_LOOKUP("sh7724_pfc", GPIO_PTR1, NULL, GPIO_ACTIVE_HIGH),
+   { }
+   },
+};
+
+static struct property_entry gpio_backlight_props[] = {
+   PROPERTY_ENTRY_BOOL("default-on"),
+   { }
+};
+
 static struct gpio_backlight_platform_data gpio_backlight_data = {
.fbdev = _device.dev,
.gpio = GPIO_PTR1,
@@ -378,13 +391,15 @@ static struct gpio_backlight_platform_data 
gpio_backlight_data = {
.name = "backlight",
 };
 
-static struct platform_device gpio_backlight_device = {
+static const struct platform_device_info gpio_backlight_device_info = {
.name = "gpio-backlight",
-   .dev = {
-   .platform_data = _backlight_data,
-   },
+   .data = _backlight_data,
+   .size_data = sizeof(gpio_backlight_data),
+   .properties = gpio_backlight_props,
 };
 
+static struct platform_device *gpio_backlight_device;
+
 /* CEU0 */
 static struct ceu_platform_data ceu0_pdata = {
.num_subdevs= 2,
@@ -1006,7 +1021,6 @@ static struct platform_device *ecovec_devices[] 
__initdata = {
_common_device,
_device,
_device,
-   _backlight_device,
_device,
_power,
 #if defined(CONFIG_MMC_SDHI) || defined(CONFIG_MMC_SDHI_MODULE)
@@ -1464,6 +1478,12 @@ static int __init arch_setup(void)
 #endif
 #endif
 
+   gpiod_add_lookup_table(_backlight_lookup);
+   gpio_backlight_device = platform_device_register_full(
+   _backlight_device_info);
+   if (IS_ERR(gpio_backlight_device))
+   return PTR_ERR(gpio_backlight_device);
+
return platform_add_devices(ecovec_devices,
ARRAY_SIZE(ecovec_devices));
 }
-- 
2.21.0

[PATCH v3 5/7] backlight: gpio: remove dev from struct gpio_backlight

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

This field is unused. Remove it.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Andy Shevchenko 
---
 drivers/video/backlight/gpio_backlight.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/video/backlight/gpio_backlight.c 
b/drivers/video/backlight/gpio_backlight.c
index 01262186fa1e..70882556f047 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -19,9 +19,7 @@
 #include 
 
 struct gpio_backlight {
-   struct device *dev;
struct device *fbdev;
-
struct gpio_desc *gpiod;
int def_value;
 };
@@ -69,8 +67,6 @@ static int gpio_backlight_probe(struct platform_device *pdev)
if (gbl == NULL)
return -ENOMEM;
 
-   gbl->dev = >dev;
-
if (pdata)
gbl->fbdev = pdata->fbdev;
 
-- 
2.21.0

Re: memory leak in kobject_set_name_vargs (2)

[Dmitry Vyukov]

On Wed, Jul 24, 2019 at 1:08 AM syzbot
 wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:3bfe1fc4 Merge tag 'for-5.3/dm-changes-2' of git://git.ker..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=130322afa0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=dcfc65ee492509c6
> dashboard link: https://syzkaller.appspot.com/bug?extid=ad8ca40ecd77896d51e2
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=135cbed060
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14dd4e3460
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ad8ca40ecd77896d5...@syzkaller.appspotmail.com

+net/ipv6/ip6_vti.c maintainers

> BUG: memory leak
> unreferenced object 0x88810cc5d860 (size 32):
>comm "syz-executor938", pid 7153, jiffies 4294945400 (age 8.020s)
>hex dump (first 32 bytes):
>  69 70 36 5f 76 74 69 31 00 2f 37 31 35 33 00 00  ip6_vti1./7153..
>  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>backtrace:
>  [<0800471f>] kmemleak_alloc_recursive
> /./include/linux/kmemleak.h:43 [inline]
>  [<0800471f>] slab_post_alloc_hook /mm/slab.h:522 [inline]
>  [<0800471f>] slab_alloc /mm/slab.c:3319 [inline]
>  [<0800471f>] __do_kmalloc /mm/slab.c:3653 [inline]
>  [<0800471f>] __kmalloc_track_caller+0x165/0x300 /mm/slab.c:3670
>  [<7a2eef8e>] kstrdup+0x3a/0x70 /mm/util.c:53
>  [] kstrdup_const+0x48/0x60 /mm/util.c:75
>  [] kvasprintf_const+0x7e/0xe0 /lib/kasprintf.c:48
>  [<5a964730>] kobject_set_name_vargs+0x40/0xe0 /lib/kobject.c:289
>  [] dev_set_name+0x63/0x90 /drivers/base/core.c:1915
>  [<7bc7b1da>] netdev_register_kobject+0x5a/0x1b0
> /net/core/net-sysfs.c:1727
>  [<637b4645>] register_netdevice+0x397/0x600 /net/core/dev.c:8723
>  [<38b21fdc>] vti6_tnl_create2+0x47/0xb0 /net/ipv6/ip6_vti.c:189
>  [<23231475>] vti6_tnl_create /net/ipv6/ip6_vti.c:229 [inline]
>  [<23231475>] vti6_locate /net/ipv6/ip6_vti.c:277 [inline]
>  [<23231475>] vti6_locate+0x244/0x2c0 /net/ipv6/ip6_vti.c:255
>  [<6ebf0a44>] vti6_ioctl+0x17f/0x390 /net/ipv6/ip6_vti.c:802
>  [<077406fa>] dev_ifsioc+0x324/0x460 /net/core/dev_ioctl.c:322
>  [<465d817c>] dev_ioctl+0x157/0x45e /net/core/dev_ioctl.c:514
>  [] sock_ioctl+0x394/0x480 /net/socket.c:1099
>  [<24234c3b>] vfs_ioctl /fs/ioctl.c:46 [inline]
>  [<24234c3b>] file_ioctl /fs/ioctl.c:509 [inline]
>  [<24234c3b>] do_vfs_ioctl+0x62a/0x810 /fs/ioctl.c:696
>  [<15b52ca4>] ksys_ioctl+0x86/0xb0 /fs/ioctl.c:713
>
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/syzkaller-bugs/edcb3c058e6143d5%40google.com.

Re: [PATCH] can: ti_hecc: use timestamp based rx-offloading

[Marc Kleine-Budde]

On 4/29/19 2:03 PM, Jeroen Hofstee wrote:
> As already mentioned in [1] and included in [2], there is an off by one
> issue since the high bank is already enabled when the _next_ mailbox to
> be read has index 12, so the mailbox being read was 13. The message can
> therefore go into mailbox 31 and the driver will be repolled until the
> mailbox 12 eventually receives a msg. Or the message might end up in the
> 12th mailbox, but then it would become disabled after reading it and only
> be enabled again in the next "round" after mailbox 13 was read, which can
> cause out of order messages, since the lower priority mailboxes can
> accept messages in the meantime.
> 
> As mentioned in [3] there is a hardware race condition when changing the
> CANME register while messages are being received. Even when including a
> busy poll on reception, like in [2] there are still overflows and out of
> order messages at times, but less then without the busy loop polling.
> Unlike what the patch suggests, the polling time is not in the microsecond
> range, but takes as long as a current CAN bus reception needs to finish,
> so typically more in the fraction of millisecond range. Since the timeout
> is in jiffies it won't timeout.
> 
> Even with these additional fixes the driver is still not able to provide a
> proper FIFO which doesn't drop packages. So change the driver to use
> rx-offload and base order on timestamp instead of message box numbers. As
> a side affect, this also fixes [4] and [5].
> 
> Before this change messages with a single byte counter were dropped /
> received out of order at a bitrate of 250kbit/s on an am3517. With this
> patch that no longer occurs up to and including 1Mbit/s.
> 
> [1] 
> https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post6
> [2] 
> http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=02346892777f07245de4d5af692513ebd852dcb2
> [3] 
> https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post5
> [4] https://patchwork.ozlabs.org/patch/895956/
> [5] https://www.spinics.net/lists/netdev/msg494971.html
> 
> Cc: Anant Gole 
> Cc: AnilKumar Ch 
> Signed-off-by: Jeroen Hofstee 
> ---
>  drivers/net/can/ti_hecc.c | 189 
> +-
>  1 file changed, 53 insertions(+), 136 deletions(-)
> 
> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
> index db6ea93..fe7 100644
> --- a/drivers/net/can/ti_hecc.c
> +++ b/drivers/net/can/ti_hecc.c
> @@ -5,6 +5,7 @@
>   * specs for the same is available at 
>   *
>   * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
> + * Copyright (C) 2019 Jeroen Hofstee 
>   *
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License as
> @@ -34,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DRV_NAME "ti_hecc"
>  #define HECC_MODULE_VERSION "0.7"
> @@ -63,29 +65,16 @@ MODULE_VERSION(HECC_MODULE_VERSION);
>  #define HECC_TX_PRIO_MASK(MAX_TX_PRIO << HECC_MB_TX_SHIFT)
>  #define HECC_TX_MB_MASK  (HECC_MAX_TX_MBOX - 1)
>  #define HECC_TX_MASK ((HECC_MAX_TX_MBOX - 1) | HECC_TX_PRIO_MASK)
> -#define HECC_TX_MBOX_MASK(~(BIT(HECC_MAX_TX_MBOX) - 1))
> -#define HECC_DEF_NAPI_WEIGHT HECC_MAX_RX_MBOX
>  
>  /*
> - * Important Note: RX mailbox configuration
> - * RX mailboxes are further logically split into two - main and buffer
> - * mailboxes. The goal is to get all packets into main mailboxes as
> - * driven by mailbox number and receive priority (higher to lower) and
> - * buffer mailboxes are used to receive pkts while main mailboxes are being
> - * processed. This ensures in-order packet reception.
> - *
> - * Here are the recommended values for buffer mailbox. Note that RX mailboxes
> - * start after TX mailboxes:
> - *
> - * HECC_MAX_RX_MBOX  HECC_RX_BUFFER_MBOX No of buffer mailboxes
> - * 2812  8
> - * 1620  4
> + * RX mailbox configuration
> + * The remaining mailboxes are used for reception and are delivered based on
> + * their timestamp, to avoid a hardware race when CANME is changed while
> + * CAN-bus traffix is being received.
>   */
>  
>  #define HECC_MAX_RX_MBOX (HECC_MAX_MAILBOXES - HECC_MAX_TX_MBOX)
> -#define HECC_RX_BUFFER_MBOX  12 /* as per table above */
>  #define HECC_RX_FIRST_MBOX   (HECC_MAX_MAILBOXES - 1)
> -#define HECC_RX_HIGH_MBOX_MASK   (~(BIT(HECC_RX_BUFFER_MBOX) - 1))
>  
>  /* TI HECC module registers */
>  #define HECC_CANME   0x0 /* Mailbox enable */
> @@ -123,6 +112,8 @@ MODULE_VERSION(HECC_MODULE_VERSION);
>  #define HECC_CANMDL  0x8
>  #define HECC_CANMDH  0xC
>  
> +#define HECC_CANMOTS 0x100

It's actually 0x80

> +
>  #define HECC_SET_REG 

[PATCH v3 4/7] backlight: gpio: remove unused fields from platform data

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Remove the platform data fields that nobody uses.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Andy Shevchenko 
---
 include/linux/platform_data/gpio_backlight.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/linux/platform_data/gpio_backlight.h 
b/include/linux/platform_data/gpio_backlight.h
index 34179d600360..1a8b5b1946fe 100644
--- a/include/linux/platform_data/gpio_backlight.h
+++ b/include/linux/platform_data/gpio_backlight.h
@@ -9,9 +9,6 @@ struct device;
 
 struct gpio_backlight_platform_data {
struct device *fbdev;
-   int gpio;
-   int def_value;
-   const char *name;
 };
 
 #endif
-- 
2.21.0

[PATCH v3 0/7] backlight: gpio: simplify the driver

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

While working on my other series related to gpio-backlight[1] I noticed
that we could simplify the driver if we made the only user of platform
data use GPIO lookups and device properties. This series tries to do
that.

The first patch adds all necessary data structures to ecovec24. Patch
2/7 unifies much of the code for both pdata and non-pdata cases. Patches
3-4/7 remove unused platform data fields. Last three patches contain
additional improvements for the GPIO backlight driver while we're already
modifying it.

I don't have access to this HW but hopefully this works. Only compile
tested.

[1] https://lkml.org/lkml/2019/6/25/900

v1 -> v2:
- rebased on top of v5.3-rc1 and adjusted to the recent changes from Andy
- added additional two patches with minor improvements

v2 -> v3:
- in patch 7/7: used initializers to set values for pdata and dev local vars

Bartosz Golaszewski (7):
  sh: ecovec24: add additional properties to the backlight device
  backlight: gpio: simplify the platform data handling
  sh: ecovec24: don't set unused fields in platform data
  backlight: gpio: remove unused fields from platform data
  backlight: gpio: remove dev from struct gpio_backlight
  backlight: gpio: remove def_value from struct gpio_backlight
  backlight: gpio: use a helper variable for >dev

 arch/sh/boards/mach-ecovec24/setup.c | 33 ++--
 drivers/video/backlight/gpio_backlight.c | 82 +---
 include/linux/platform_data/gpio_backlight.h |  3 -
 3 files changed, 44 insertions(+), 74 deletions(-)

-- 
2.21.0