Re: [PATCH v5 13/13] mm: Clear shrinker bit if there are no objects related to memcg

2018-05-14 Thread Vladimir Davydov
On Thu, May 10, 2018 at 12:54:15PM +0300, Kirill Tkhai wrote:
> To avoid further unneed calls of do_shrink_slab()
> for shrinkers, which already do not have any charged
> objects in a memcg, their bits have to be cleared.
> 
> This patch introduces a lockless mechanism to do that
> without races without parallel list lru add. After
> do_shrink_slab() returns SHRINK_EMPTY the first time,
> we clear the bit and call it once again. Then we restore
> the bit, if the new return value is different.
> 
> Note, that single smp_mb__after_atomic() in shrink_slab_memcg()
> covers two situations:
> 
> 1)list_lru_add() shrink_slab_memcg
> list_add_tail()for_each_set_bit() <--- read bit
>  do_shrink_slab() <--- missed list update (no barrier)
>  
> set_bit()do_shrink_slab() <--- seen list update
> 
> This situation, when the first do_shrink_slab() sees set bit,
> but it doesn't see list update (i.e., race with the first element
> queueing), is rare. So we don't add  before the first call
> of do_shrink_slab() instead of this to do not slow down generic
> case. Also, it's need the second call as seen in below in (2).
> 
> 2)list_lru_add()  shrink_slab_memcg()
> list_add_tail() ...
> set_bit()   ...
>   ...   for_each_set_bit()
>   do_shrink_slab()do_shrink_slab()
> clear_bit()   ...
>   ... ...
>   list_lru_add()  ...
> list_add_tail()   clear_bit()
>   
> set_bit() do_shrink_slab()
> 
> The barriers guarantees, the second do_shrink_slab()
> in the right side task sees list update if really
> cleared the bit. This case is drawn in the code comment.
> 
> [Results/performance of the patchset]
> 
> After the whole patchset applied the below test shows signify
> increase of performance:
> 
> $echo 1 > /sys/fs/cgroup/memory/memory.use_hierarchy
> $mkdir /sys/fs/cgroup/memory/ct
> $echo 4000M > /sys/fs/cgroup/memory/ct/memory.kmem.limit_in_bytes
> $for i in `seq 0 4000`; do mkdir /sys/fs/cgroup/memory/ct/$i; echo $$ > 
> /sys/fs/cgroup/memory/ct/$i/cgroup.procs; mkdir -p s/$i; mount -t tmpfs $i 
> s/$i; touch s/$i/file; done
> 
> Then, 5 sequential calls of drop caches:
> $time echo 3 > /proc/sys/vm/drop_caches
> 
> 1)Before:
> 0.00user 13.78system 0:13.78elapsed 99%CPU
> 0.00user 5.59system 0:05.60elapsed 99%CPU
> 0.00user 5.48system 0:05.48elapsed 99%CPU
> 0.00user 8.35system 0:08.35elapsed 99%CPU
> 0.00user 8.34system 0:08.35elapsed 99%CPU
> 
> 2)After
> 0.00user 1.10system 0:01.10elapsed 99%CPU
> 0.00user 0.00system 0:00.01elapsed 64%CPU
> 0.00user 0.01system 0:00.01elapsed 82%CPU
> 0.00user 0.00system 0:00.01elapsed 64%CPU
> 0.00user 0.01system 0:00.01elapsed 82%CPU
> 
> The results show the performance increases at least in 548 times.
> 
> Signed-off-by: Kirill Tkhai 
> ---
>  include/linux/memcontrol.h |2 ++
>  mm/vmscan.c|   19 +--
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 436691a66500..82c0bf2d0579 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1283,6 +1283,8 @@ static inline void memcg_set_shrinker_bit(struct 
> mem_cgroup *memcg, int nid, int
>  
>   rcu_read_lock();
>   map = MEMCG_SHRINKER_MAP(memcg, nid);
> + /* Pairs with smp mb in shrink_slab() */
> + smp_mb__before_atomic();
>   set_bit(nr, map->map);
>   rcu_read_unlock();
>   }
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 7b0075612d73..189b163bef4a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -586,8 +586,23 @@ static unsigned long shrink_slab_memcg(gfp_t gfp_mask, 
> int nid,
>   continue;
>  
>   ret = do_shrink_slab(, shrinker, priority);
> - if (ret == SHRINK_EMPTY)
> - ret = 0;
> + if (ret == SHRINK_EMPTY) {
> + clear_bit(i, map->map);
> + /*
> +  * Pairs with mb in memcg_set_shrinker_bit():
> +  *
> +  * list_lru_add() shrink_slab_memcg()
> +  *   list_add_tail()clear_bit()
> +  *  
> +  *   set_bit()  do_shrink_slab()
> +  */

Please improve the comment so that it isn't just a diagram.

> + smp_mb__after_atomic();
> + ret = do_shrink_slab(, shrinker, priority);
> + if (ret == SHRINK_EMPTY)
> + ret = 0;
> + else
> + memcg_set_shrinker_bit(memcg, nid, i);
> + }
>   freed += ret;
>  
>   if (rwsem_is_contended(_rwsem)) {
> 


[PATCH v3 3/8] PCI: Rename device node parameter of of_pci_get_host_bridge_resources()

2018-05-14 Thread Jan Kiszka
From: Jan Kiszka 

We will add a real device parameter to this function soon.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c   | 18 +-
 include/linux/of_pci.h |  4 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c273ae..8d4778ef5806 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -245,7 +245,7 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
 #if defined(CONFIG_OF_ADDRESS)
 /**
  * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
- * @dev: device node of the host bridge having the range property
+ * @dev_node: device node of the host bridge having the range property
  * @busno: bus number associated with the bridge root bus
  * @bus_max: maximum number of buses for this bridge
  * @resources: list where the range of resources will be added after DT parsing
@@ -262,7 +262,7 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
  * It returns zero if the range parsing has been successful or a standard error
  * value if it failed.
  */
-int of_pci_get_host_bridge_resources(struct device_node *dev,
+int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
@@ -281,15 +281,15 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (!bus_range)
return -ENOMEM;
 
-   pr_info("host bridge %pOF ranges:\n", dev);
+   pr_info("host bridge %pOF ranges:\n", dev_node);
 
-   err = of_pci_parse_bus_range(dev, bus_range);
+   err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
pr_info("  No bus range found for %pOF, using %pR\n",
-   dev, bus_range);
+   dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -297,7 +297,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
pci_add_resource(resources, bus_range);
 
/* Check for ranges property */
-   err = of_pci_range_parser_init(, dev);
+   err = of_pci_range_parser_init(, dev_node);
if (err)
goto parse_failed;
 
@@ -327,7 +327,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
goto parse_failed;
}
 
-   err = of_pci_range_to_resource(, dev, res);
+   err = of_pci_range_to_resource(, dev_node, res);
if (err) {
kfree(res);
continue;
@@ -336,13 +336,13 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
pr_err("I/O range found for %pOF. Please 
provide an io_base pointer to save CPU base address\n",
-   dev);
+   dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
pr_warn("More than one I/O resource converted 
for %pOF. CPU base address for old range lost!\n",
-   dev);
+   dev_node);
*io_base = range.cpu_addr;
}
 
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 091033a6b836..74eec1943ad2 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -71,11 +71,11 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 
slot, u8 pin)
 #endif
 
 #if defined(CONFIG_OF_ADDRESS)
-int of_pci_get_host_bridge_resources(struct device_node *dev,
+int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
 #else
-static inline int of_pci_get_host_bridge_resources(struct device_node *dev,
+static inline int of_pci_get_host_bridge_resources(struct device_node 
*dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
-- 
2.13.6



[PATCH v3 4/8] PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources with device

2018-05-14 Thread Jan Kiszka
From: Jan Kiszka 

Another step towards a managed version of
of_pci_get_host_bridge_resources(): Feed in the underlying device,
rather than just the OF node. This will allow to use managed resource
allocation internally later on.

CC: Jingoo Han 
CC: Joao Pinto 
CC: Lorenzo Pieralisi 
Signed-off-by: Jan Kiszka 
---
 drivers/pci/dwc/pcie-designware-host.c | 2 +-
 drivers/pci/host/pci-aardvark.c| 5 ++---
 drivers/pci/host/pci-ftpci100.c| 4 ++--
 drivers/pci/host/pci-v3-semi.c | 3 ++-
 drivers/pci/host/pci-versatile.c   | 3 +--
 drivers/pci/host/pci-xgene.c   | 3 ++-
 drivers/pci/host/pcie-altera.c | 5 ++---
 drivers/pci/host/pcie-iproc-platform.c | 4 ++--
 drivers/pci/host/pcie-rcar.c   | 5 ++---
 drivers/pci/host/pcie-rockchip.c   | 4 ++--
 drivers/pci/host/pcie-xilinx-nwl.c | 4 ++--
 drivers/pci/host/pcie-xilinx.c | 4 ++--
 drivers/pci/of.c   | 9 +
 include/linux/of_pci.h | 4 ++--
 14 files changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index 6c409079d514..5a535690b7b5 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (!bridge)
return -ENOMEM;
 
-   ret = of_pci_get_host_bridge_resources(np, 0, 0xff,
+   ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
>windows, >io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index 9abf549631b4..39d8fc2a8a76 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -822,14 +822,13 @@ static int advk_pcie_parse_request_of_pci_ranges(struct 
advk_pcie *pcie)
 {
int err, res_valid = 0;
struct device *dev = >pdev->dev;
-   struct device_node *np = dev->of_node;
struct resource_entry *win, *tmp;
resource_size_t iobase;
 
INIT_LIST_HEAD(>resources);
 
-   err = of_pci_get_host_bridge_resources(np, 0, 0xff, >resources,
-  );
+   err = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+   >resources, );
if (err)
return err;
 
diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-ftpci100.c
index 5008fd87956a..5c176f806fe5 100644
--- a/drivers/pci/host/pci-ftpci100.c
+++ b/drivers/pci/host/pci-ftpci100.c
@@ -476,8 +476,8 @@ static int faraday_pci_probe(struct platform_device *pdev)
if (IS_ERR(p->base))
return PTR_ERR(p->base);
 
-   ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
-  , _base);
+   ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+   , _base);
if (ret)
return ret;
 
diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-semi.c
index 0a4dea796663..f3f39935ac2f 100644
--- a/drivers/pci/host/pci-v3-semi.c
+++ b/drivers/pci/host/pci-v3-semi.c
@@ -791,7 +791,8 @@ static int v3_pci_probe(struct platform_device *pdev)
if (IS_ERR(v3->config_base))
return PTR_ERR(v3->config_base);
 
-   ret = of_pci_get_host_bridge_resources(np, 0, 0xff, , _base);
+   ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, ,
+   _base);
if (ret)
return ret;
 
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
index 5b3876f5312b..ef33ec0a9e1b 100644
--- a/drivers/pci/host/pci-versatile.c
+++ b/drivers/pci/host/pci-versatile.c
@@ -64,11 +64,10 @@ static int versatile_pci_parse_request_of_pci_ranges(struct 
device *dev,
 struct list_head *res)
 {
int err, mem = 1, res_valid = 0;
-   struct device_node *np = dev->of_node;
resource_size_t iobase;
struct resource_entry *win, *tmp;
 
-   err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, );
+   err = of_pci_get_host_bridge_resources(dev, 0, 0xff, res, );
if (err)
return err;
 
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 0a0d7ee6d3c9..88e9a6d315b3 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -632,7 +632,8 @@ static int xgene_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   ret = of_pci_get_host_bridge_resources(dn, 0, 0xff, , );
+   ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, ,
+ 

[PATCH] cpufreq: add imx8mq-cpufreq driver

2018-05-14 Thread Anson Huang
Add imx8mq-cpufreq driver for NXP i.MX8MQ SoC to support the
hardware specific frequency and voltage scaling requirements.

Signed-off-by: Anson Huang 
---
 drivers/cpufreq/Kconfig.arm  |   8 ++
 drivers/cpufreq/Makefile |   1 +
 drivers/cpufreq/imx8mq-cpufreq.c | 234 +++
 3 files changed, 243 insertions(+)
 create mode 100644 drivers/cpufreq/imx8mq-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 96b35b8..ea8e2b6 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -105,6 +105,14 @@ config ARM_IMX6Q_CPUFREQ
 
  If in doubt, say N.
 
+config ARM_IMX8MQ_CPUFREQ
+   tristate "NXP i.MX8MQ cpufreq support"
+   select PM_OPP
+   help
+ This adds cpufreq driver support for NXP i.MX8MQ SoC.
+
+ If in doubt, say N.
+
 config ARM_KIRKWOOD_CPUFREQ
def_bool MACH_KIRKWOOD
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..a3bc61c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_ARCH_DAVINCI)+= davinci-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
+obj-$(CONFIG_ARM_IMX8MQ_CPUFREQ)   += imx8mq-cpufreq.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
 obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
 obj-$(CONFIG_MACH_MVEBU_V7)+= mvebu-cpufreq.o
diff --git a/drivers/cpufreq/imx8mq-cpufreq.c b/drivers/cpufreq/imx8mq-cpufreq.c
new file mode 100644
index 000..2aee6049
--- /dev/null
+++ b/drivers/cpufreq/imx8mq-cpufreq.c
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 NXP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct device *cpu_dev;
+static bool free_opp;
+static struct cpufreq_frequency_table *freq_table;
+static unsigned int transition_latency;
+static struct thermal_cooling_device *cdev;
+static struct regulator *arm_reg;
+static unsigned int max_freq;
+
+#define IMX8MQ_CPUFREQ_CLK_NUM 5
+
+enum IMX8MQ_CPUFREQ_CLKS {
+   A53,
+   A53_SRC,
+   ARM_PLL,
+   ARM_PLL_OUT,
+   SYS1_PLL_800M,
+};
+
+static struct clk_bulk_data clks[] = {
+   { .id = "a53" },
+   { .id = "a53_src" },
+   { .id = "arm_pll" },
+   { .id = "arm_pll_out" },
+   { .id = "sys1_pll_800m" },
+};
+
+static int imx8mq_set_target(struct cpufreq_policy *policy, unsigned int index)
+{
+   struct dev_pm_opp *opp;
+   unsigned long freq_hz, volt;
+   unsigned int old_freq, new_freq;
+   int ret;
+
+   new_freq = freq_table[index].frequency;
+   freq_hz = new_freq * 1000;
+   old_freq = policy->cur;
+
+   opp = dev_pm_opp_find_freq_ceil(cpu_dev, _hz);
+   if (IS_ERR(opp)) {
+   dev_err(cpu_dev, "failed to find OPP for %ld\n", freq_hz);
+   return PTR_ERR(opp);
+   }
+   volt = dev_pm_opp_get_voltage(opp);
+   dev_pm_opp_put(opp);
+
+   dev_dbg(cpu_dev, "%u MHz --> %u MHz\n",
+   old_freq / 1000, new_freq / 1000);
+
+   if (new_freq > old_freq) {
+   ret = regulator_set_voltage_tol(arm_reg, volt, 0);
+   if (ret) {
+   dev_err(cpu_dev, "failed to scale arm_reg up: %d\n",
+   ret);
+   return ret;
+   }
+   }
+
+   clk_set_parent(clks[A53_SRC].clk, clks[SYS1_PLL_800M].clk);
+   clk_set_rate(clks[ARM_PLL].clk, new_freq * 1000);
+   clk_set_parent(clks[A53_SRC].clk, clks[ARM_PLL_OUT].clk);
+
+   /* Ensure the arm clock divider is what we expect */
+   ret = clk_set_rate(clks[A53].clk, new_freq * 1000);
+   if (ret)
+   dev_err(cpu_dev, "failed to set clock rate: %d\n", ret);
+
+   if (new_freq < old_freq) {
+   ret = regulator_set_voltage_tol(arm_reg, volt, 0);
+   if (ret) {
+   dev_err(cpu_dev, "failed to scale arm_reg down: %d\n",
+   ret);
+   return ret;
+   }
+   }
+
+   return ret;
+}
+
+static void imx8mq_cpufreq_ready(struct cpufreq_policy *policy)
+{
+   cdev = of_cpufreq_cooling_register(policy);
+}
+
+static int imx8mq_cpufreq_init(struct cpufreq_policy *policy)
+{
+   int ret;
+
+   policy->clk = clks[A53].clk;
+   ret = cpufreq_generic_init(policy, freq_table, transition_latency);
+   policy->suspend_freq = max_freq;
+
+   

linux-next: build failure after merge of the kbuild tree

2018-05-14 Thread Stephen Rothwell
Hi Masahiro,

After merging the kbuild tree, today's linux-next build (x86_64
modules_install) failed like this:

Usage: scripts/depmod.sh /sbin/depmod  
Makefile:1314: recipe for target '_modinst_post' failed

Caused by commit

  ea7ad9856a2c ("depmod.sh: remove symbol prefix support")

I added the following fix for today:

From: Stephen Rothwell 
Date: Tue, 15 May 2018 15:47:33 +1000
Subject: [PATCH] depmod.sh: fix syntax check and uage message

fixes: ea7ad9856a2c ("depmod.sh: remove symbol prefix support")
Signed-off-by: Stephen Rothwell 
---
 scripts/depmod.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/depmod.sh b/scripts/depmod.sh
index 421d1aa01304..1a6f85e0e6e1 100755
--- a/scripts/depmod.sh
+++ b/scripts/depmod.sh
@@ -3,8 +3,8 @@
 #
 # A depmod wrapper used by the toplevel Makefile
 
-if test $# -ne 3; then
-   echo "Usage: $0 /sbin/depmod  " >&2
+if test $# -ne 2; then
+   echo "Usage: $0 /sbin/depmod " >&2
exit 1
 fi
 DEPMOD=$1
-- 
2.17.0

-- 
Cheers,
Stephen Rothwell


pgpcyekDFttro.pgp
Description: OpenPGP digital signature


Re: [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers

2018-05-14 Thread Oleksandr Andrushchenko

On 05/14/2018 11:28 PM, Takashi Iwai wrote:

On Mon, 14 May 2018 08:27:40 +0200,
Oleksandr Andrushchenko wrote:

--- /dev/null
+++ b/sound/xen/xen_snd_front_shbuf.c
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+/*
+ * Xen para-virtual sound device
+ *
+ * Copyright (C) 2016-2018 EPAM Systems Inc.
+ *
+ * Author: Oleksandr Andrushchenko 
+ */
+
+#include 
+#include 
+
+#include "xen_snd_front_shbuf.h"

Hm, with the local build test, I get the following error:

   CC [M]  sound/xen/xen_snd_front_shbuf.o
   In file included from sound/xen/xen_snd_front_shbuf.c:11:0:
   ./include/xen/xen.h:18:8: error: unknown type name ‘bool’
extern bool xen_pvh;
^~~~
In file included from ./include/xen/interface/xen.h:30:0,
 from ./include/xen/xen.h:29,
 from sound/xen/xen_snd_front_shbuf.c:11:
   ./arch/x86/include/asm/xen/interface.h:92:21: error: unknown type name 
‘uint64_t’
DEFINE_GUEST_HANDLE(uint64_t);
^

Adding #include  fixed the issue.

Did you really test your patches with the latest Linus tree?

My bad, it does build for ARM (which is my target), but also does
need "#include " for x86 which I didn't build this time.
Sorry about that.

Do you want me to resend this single patch or you can make the change
while applying?



thanks,

Takashi

Thank you,
Oleksandr


Re: [PATCH v5 11/13] mm: Iterate only over charged shrinkers during memcg shrink_slab()

2018-05-14 Thread Vladimir Davydov
On Thu, May 10, 2018 at 12:53:55PM +0300, Kirill Tkhai wrote:
> Using the preparations made in previous patches, in case of memcg
> shrink, we may avoid shrinkers, which are not set in memcg's shrinkers
> bitmap. To do that, we separate iterations over memcg-aware and
> !memcg-aware shrinkers, and memcg-aware shrinkers are chosen
> via for_each_set_bit() from the bitmap. In case of big nodes,
> having many isolated environments, this gives significant
> performance growth. See next patches for the details.
> 
> Note, that the patch does not respect to empty memcg shrinkers,
> since we never clear the bitmap bits after we set it once.
> Their shrinkers will be called again, with no shrinked objects
> as result. This functionality is provided by next patches.
> 
> Signed-off-by: Kirill Tkhai 
> ---
>  include/linux/memcontrol.h |1 +
>  mm/vmscan.c|   70 
> ++--
>  2 files changed, 62 insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 82f892e77637..436691a66500 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -760,6 +760,7 @@ void mem_cgroup_split_huge_fixup(struct page *head);
>  #define MEM_CGROUP_ID_MAX0
>  
>  struct mem_cgroup;
> +#define root_mem_cgroup NULL

Let's instead export mem_cgroup_is_root(). In case if MEMCG is disabled
it will always return false.

>  
>  static inline bool mem_cgroup_disabled(void)
>  {
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index d8a2870710e0..a2e38e05adb5 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -376,6 +376,7 @@ int prealloc_shrinker(struct shrinker *shrinker)
>   goto free_deferred;
>   }
>  
> + INIT_LIST_HEAD(>list);

IMO this shouldn't be here, see my comment below.

>   return 0;
>  
>  free_deferred:
> @@ -547,6 +548,63 @@ static unsigned long do_shrink_slab(struct 
> shrink_control *shrinkctl,
>   return freed;
>  }
>  
> +#ifdef CONFIG_MEMCG_SHRINKER
> +static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
> + struct mem_cgroup *memcg, int priority)
> +{
> + struct memcg_shrinker_map *map;
> + unsigned long freed = 0;
> + int ret, i;
> +
> + if (!memcg_kmem_enabled() || !mem_cgroup_online(memcg))
> + return 0;
> +
> + if (!down_read_trylock(_rwsem))
> + return 0;
> +
> + /*
> +  * 1)Caller passes only alive memcg, so map can't be NULL.
> +  * 2)shrinker_rwsem protects from maps expanding.

^^
Nit: space missing here :-)

> +  */
> + map = rcu_dereference_protected(MEMCG_SHRINKER_MAP(memcg, nid), true);
> + BUG_ON(!map);
> +
> + for_each_set_bit(i, map->map, memcg_shrinker_nr_max) {
> + struct shrink_control sc = {
> + .gfp_mask = gfp_mask,
> + .nid = nid,
> + .memcg = memcg,
> + };
> + struct shrinker *shrinker;
> +
> + shrinker = idr_find(_idr, i);
> + if (!shrinker) {
> + clear_bit(i, map->map);
> + continue;
> + }

The shrinker must be memcg aware so please add

  BUG_ON((shrinker->flags & SHRINKER_MEMCG_AWARE) == 0);

> + if (list_empty(>list))
> + continue;

I don't like using shrinker->list as an indicator that the shrinker has
been initialized. IMO if you do need such a check, you should split
shrinker_idr registration in two steps - allocate a slot in 'prealloc'
and set the pointer in 'register'. However, can we really encounter an
unregistered shrinker here? AFAIU a bit can be set in the shrinker map
only after the corresponding shrinker has been initialized, no?

> +
> + ret = do_shrink_slab(, shrinker, priority);
> + freed += ret;
> +
> + if (rwsem_is_contended(_rwsem)) {
> + freed = freed ? : 1;
> + break;
> + }
> + }
> +
> + up_read(_rwsem);
> + return freed;
> +}
> +#else /* CONFIG_MEMCG_SHRINKER */
> +static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
> + struct mem_cgroup *memcg, int priority)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_MEMCG_SHRINKER */
> +
>  /**
>   * shrink_slab - shrink slab caches
>   * @gfp_mask: allocation context
> @@ -576,8 +634,8 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>   struct shrinker *shrinker;
>   unsigned long freed = 0;
>  
> - if (memcg && (!memcg_kmem_enabled() || !mem_cgroup_online(memcg)))
> - return 0;
> + if (memcg && memcg != root_mem_cgroup)

if (!mem_cgroup_is_root(memcg))

> + return shrink_slab_memcg(gfp_mask, nid, memcg, priority);
>  
>   if (!down_read_trylock(_rwsem))
>   goto out;
> @@ -589,13 +647,7 @@ static unsigned long shrink_slab(gfp_t 

Re: [RFC PATCH v2 2/2] locking/percpu-rwsem: Mark rwsem as non-spinnable in percpu_rwsem_release()

2018-05-14 Thread Amir Goldstein
On Mon, May 14, 2018 at 10:31 PM, Waiman Long  wrote:
> The percpu_rwsem_release() is called when the ownership of the embedded
> rwsem is to be transferred to another task. The new owner, however, may
> take a while to get the ownership of the lock via percpu_rwsem_acquire().
> During that period, the rwsem is now marked as writer-owned with no
> optimistic spinning.
>

Waiman,

Thanks for the fix. I will test it soon.

For this commit message I suggest that you add parts of the reproducer
found here:
https://marc.info/?l=linux-fsdevel=152622016219975=2

Thanks,
Amir.

> Signed-off-by: Waiman Long 
> ---
>  include/linux/percpu-rwsem.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
> index b1f37a8..dd37102 100644
> --- a/include/linux/percpu-rwsem.h
> +++ b/include/linux/percpu-rwsem.h
> @@ -131,16 +131,16 @@ static inline void percpu_rwsem_release(struct 
> percpu_rw_semaphore *sem,
> bool read, unsigned long ip)
>  {
> lock_release(>rw_sem.dep_map, 1, ip);
> -#ifdef CONFIG_RWSEM_SPIN_ON_OWNER
> if (!read)
> -   sem->rw_sem.owner = NULL;
> -#endif
> +   rwsem_set_writer_owned_nospin(>rw_sem);
>  }
>
>  static inline void percpu_rwsem_acquire(struct percpu_rw_semaphore *sem,
> bool read, unsigned long ip)
>  {
> lock_acquire(>rw_sem.dep_map, 0, 1, read, 1, NULL, ip);
> +   if (!read)
> +   rwsem_set_writer_owned(>rw_sem, current);
>  }
>
>  #endif
> --
> 1.8.3.1
>


[tip:x86/build] x86/build/vdso: Put generated linker scripts to $(obj)/

2018-05-14 Thread tip-bot for Masahiro Yamada
Commit-ID:  1742ed2088ccc4ade3abd8fe888742dd0f1343f8
Gitweb: https://git.kernel.org/tip/1742ed2088ccc4ade3abd8fe888742dd0f1343f8
Author: Masahiro Yamada 
AuthorDate: Tue, 15 May 2018 11:52:24 +0900
Committer:  Ingo Molnar 
CommitDate: Tue, 15 May 2018 07:32:42 +0200

x86/build/vdso: Put generated linker scripts to $(obj)/

Let's put generated files to $(obj)/ rather than $(src)/ although
this is just a matter of taste because both are the same.

Signed-off-by: Masahiro Yamada 
Cc: Andy Lutomirski 
Cc: Jeff Dike 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Richard Weinberger 
Cc: Thomas Gleixner 
Cc: user-mode-linux-de...@lists.sourceforge.net
Cc: user-mode-linux-u...@lists.sourceforge.net
Link: 
http://lkml.kernel.org/r/1526352744-28229-4-git-send-email-yamada.masah...@socionext.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/vdso/Makefile | 4 ++--
 arch/x86/um/vdso/Makefile| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 690df4c6b40a..261802b1cc50 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -51,7 +51,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
-Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 \
$(DISABLE_LTO)
 
-$(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
+$(obj)/vdso64.so.dbg: $(obj)/vdso.lds $(vobjs) FORCE
$(call if_changed,vdso)
 
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi 
-I$(srctree)/arch/$(SUBARCH)/include/uapi
@@ -119,7 +119,7 @@ $(obj)/%.so: OBJCOPYFLAGS := -S
 $(obj)/%.so: $(obj)/%.so.dbg
$(call if_changed,objcopy)
 
-$(obj)/vdsox32.so.dbg: $(src)/vdsox32.lds $(vobjx32s) FORCE
+$(obj)/vdsox32.so.dbg: $(obj)/vdsox32.lds $(vobjx32s) FORCE
$(call if_changed,vdso)
 
 CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index e51d95c9098c..b2d6967262b2 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -30,7 +30,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
 
 $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so
 
-$(obj)/vdso.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
+$(obj)/vdso.so.dbg: $(obj)/vdso.lds $(vobjs) FORCE
$(call if_changed,vdso)
 
 $(obj)/%.so: OBJCOPYFLAGS := -S


[tip:x86/build] x86/build/vdso: Remove unnecessary export in Makefile

2018-05-14 Thread tip-bot for Masahiro Yamada
Commit-ID:  61615faf0a8968b604bd279fec5cb834ba59ed58
Gitweb: https://git.kernel.org/tip/61615faf0a8968b604bd279fec5cb834ba59ed58
Author: Masahiro Yamada 
AuthorDate: Tue, 15 May 2018 11:52:23 +0900
Committer:  Ingo Molnar 
CommitDate: Tue, 15 May 2018 07:32:42 +0200

x86/build/vdso: Remove unnecessary export in Makefile

CPPFLAGS_vdso.lds is assigned and referenced internally in each
Makefile.  No need to export it.

Signed-off-by: Masahiro Yamada 
Cc: Andy Lutomirski 
Cc: Jeff Dike 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Richard Weinberger 
Cc: Thomas Gleixner 
Cc: user-mode-linux-de...@lists.sourceforge.net
Cc: user-mode-linux-u...@lists.sourceforge.net
Link: 
http://lkml.kernel.org/r/1526352744-28229-3-git-send-email-yamada.masah...@socionext.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/vdso/Makefile | 2 +-
 arch/x86/um/vdso/Makefile| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 298850683ee2..690df4c6b40a 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -44,7 +44,7 @@ obj-y += $(vdso_img_objs)
 targets += $(vdso_img_cfiles)
 targets += $(vdso_img_sodbg) $(vdso_img-y:%=vdso%.so)
 
-export CPPFLAGS_vdso.lds += -P -C
+CPPFLAGS_vdso.lds += -P -C
 
 VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
-Wl,--no-undefined \
diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 10003359e633..e51d95c9098c 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -23,7 +23,7 @@ $(obj)/vdso.o: $(obj)/vdso.so
 
 targets += vdso.so vdso.so.dbg vdso.lds $(vobjs-y)
 
-export CPPFLAGS_vdso.lds += -P -C
+CPPFLAGS_vdso.lds += -P -C
 
 VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
-Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096


[tip:x86/build] x86/build/vdso: Remove unused $(vobjs-nox32) in Makefile

2018-05-14 Thread tip-bot for Masahiro Yamada
Commit-ID:  b3656612118f8961182f988168c835f023f0408a
Gitweb: https://git.kernel.org/tip/b3656612118f8961182f988168c835f023f0408a
Author: Masahiro Yamada 
AuthorDate: Tue, 15 May 2018 11:52:22 +0900
Committer:  Ingo Molnar 
CommitDate: Tue, 15 May 2018 07:32:42 +0200

x86/build/vdso: Remove unused $(vobjs-nox32) in Makefile

Since commit bfad381c0d1e ("x86/vdso: Improve the fake section
headers"), $(vobjs-nox32) is empty.  Therefore, $(vobjs64-for-x32)
is the same as $(vobjs-y).

Signed-off-by: Masahiro Yamada 
Cc: Andy Lutomirski 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1526352744-28229-2-git-send-email-yamada.masah...@socionext.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/vdso/Makefile | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index d998a487c9b1..298850683ee2 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -100,11 +100,8 @@ VDSO_LDFLAGS_vdsox32.lds = -Wl,-m,elf32_x86_64 \
   -Wl,-z,max-page-size=4096 \
   -Wl,-z,common-page-size=4096
 
-# 64-bit objects to re-brand as x32
-vobjs64-for-x32 := $(filter-out $(vobjs-nox32),$(vobjs-y))
-
 # x32-rebranded versions
-vobjx32s-y := $(vobjs64-for-x32:.o=-x32.o)
+vobjx32s-y := $(vobjs-y:.o=-x32.o)
 
 # same thing, but in the output directory
 vobjx32s := $(foreach F,$(vobjx32s-y),$(obj)/$F)


Re: [PATCH 4.9 00/36] 4.9.100-stable review

2018-05-14 Thread Naresh Kamboju
On 14 May 2018 at 12:18, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.9.100 release.
> There are 36 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed May 16 06:47:47 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.100-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.9.100-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 126d655643a828cd86fd7d8e154aa397bd08b31b
git describe: v4.9.99-37-g126d655643a8
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.99-37-g126d655643a8


No regressions (compared to build v4.9.99-16-gb8ef70c6c0c7)

Boards, architectures and test suites:
-

dragonboard-410c
* boot - pass: 20
* kselftest - skip: 32, pass: 34
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 135, pass: 1015
* ltp-timers-tests - pass: 13

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 29, pass: 37
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 136, pass: 1014
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 29, pass: 37
* libhugetlbfs - skip: 1, pass: 90
* ltp-containers-tests - skip: 17, pass: 64
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 135, pass: 1015
* ltp-timers-tests - pass: 13

qemu_arm64
* boot - fail: 1, pass: 20
* kselftest - skip: 33, pass: 35
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 6, pass: 8
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - fail: 2, skip: 157, pass: 991
* ltp-timers-tests - pass: 13

qemu_x86_64
* boot - pass: 20
* kselftest - skip: 33, pass: 47
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 152, pass: 998
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - skip: 29, pass: 36
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 18, pass: 63
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 5, pass: 58
* 

Re: [PATCH v4 0/4] ALSA: usb: UAC3 new features.

2018-05-14 Thread Takashi Iwai
On Fri, 11 May 2018 17:25:33 +0200,
Jorge Sanjuan wrote:
> 
> v4 Updates:
>  - Removes already applied patch from v2 of this patchset.
>  - Adds small patch to parse Feature Unit number of channels.
>  - Rebased onto latest linux-next tag as today.
> 
> Now that the UAC3 patch [1] has made it to linux-next I have some extra
> features to make a UAC3 devices fully work in Linux. Including Jack 
> insertion control that I have put on top of this other patch [2] for 
> UAC2. Also adding support for the UAC3 Mixer Unit which is most likely
> to appear in most headset type devices.
> 
> UAC3 devices also require to have a Basic Audio Device (BADD) in a separate 
> config for which both Ruslan Bilovol and myself have submited different 
> approaches[3][4]. After an ongoing discussion between Ruslan and myself
> we have decided that the patch from Ruslan[3] implements a simpler and
> yet more robust BADD driver.
> 
> All this features are tested with an actual UAC3 device that is still in
> development. For this patch series, only the legacy config (#1. UAC1/UAC2)
> and the UAC3 config have been tested. The BADD config will come in
> a different patch from Ruslan.
> 
> [1]: https://patchwork.kernel.org/patch/10298179/
> [2]: https://patchwork.kernel.org/patch/10305847/
> [3]: https://patchwork.kernel.org/patch/10340851/
> [4]: https://www.spinics.net/lists/alsa-devel/msg71617.html
> 
> Based on linux-next tag: next-20180510
> 
> Jorge Sanjuan (4):
>   ALSA: usb-audio: UAC3. Add support for mixer unit.
>   ALSA: usb-audio: Use Class Specific EP for UAC3 devices.
>   ALSA: usb-audio: UAC3 Add support for connector insertion.
>   ALSA: usb-audio: UAC3: Parse Input Terminal number of channels.

OK, now I applied all four patches.  The patch 2 was queued to
for-linus branch while others to for-next.  The patch 4 was taken from
the revised v4.


Thanks!

Takashi


Re: [PATCH 4.14 00/62] 4.14.41-stable review

2018-05-14 Thread Naresh Kamboju
On 14 May 2018 at 12:18, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.14.41 release.
> There are 62 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed May 16 06:47:52 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.41-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.14.41-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 13b3d94ce25df5cc037e4d28af3ef61933281cc5
git describe: v4.14.40-63-g13b3d94ce25d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.40-63-g13b3d94ce25d


No regressions (compared to build v4.14.40-22-g70a593c357b7)

Boards, architectures and test suites:
-

dragonboard-410c
* boot - pass: 20,
* kselftest - pass: 41, skip: 27
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1016, skip: 134
* ltp-timers-tests - pass: 13,

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 44, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1015, skip: 135
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 27,
* kselftest - pass: 43, skip: 25
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 12,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 2032, skip: 268
* ltp-timers-tests - pass: 13,

qemu_arm64
* boot - pass: 21, fail: 1,
* kselftest - pass: 41, skip: 29
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 8, skip: 6
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 992, fail: 2, skip: 156
* ltp-timers-tests - pass: 13,

qemu_x86_64
* boot - pass: 20,
* kselftest - pass: 50, skip: 30
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 998, skip: 152
* ltp-timers-tests - pass: 13,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 37, fail: 2, skip: 26
* libhugetlbfs - pass: 87, skip: 1
* 

Re: [PATCH v1 4/4] samples/bpf: an example of a raw IR decoder

2018-05-14 Thread Y Song
On Mon, May 14, 2018 at 2:11 PM, Sean Young  wrote:
> This implements the grundig-16 IR protocol.
>
> Signed-off-by: Sean Young 
> ---
>  samples/bpf/Makefile  |   4 +
>  samples/bpf/bpf_load.c|   9 +-
>  samples/bpf/grundig_decoder_kern.c| 112 ++
>  samples/bpf/grundig_decoder_user.c|  54 +++
>  tools/bpf/bpftool/prog.c  |   1 +
>  tools/include/uapi/linux/bpf.h|  17 +++-
>  tools/testing/selftests/bpf/bpf_helpers.h |   6 ++
>  7 files changed, 200 insertions(+), 3 deletions(-)
>  create mode 100644 samples/bpf/grundig_decoder_kern.c
>  create mode 100644 samples/bpf/grundig_decoder_user.c
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 4d6a6edd4bf6..c6fa111f103a 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -44,6 +44,7 @@ hostprogs-y += xdp_monitor
>  hostprogs-y += xdp_rxq_info
>  hostprogs-y += syscall_tp
>  hostprogs-y += cpustat
> +hostprogs-y += grundig_decoder
>
>  # Libbpf dependencies
>  LIBBPF := ../../tools/lib/bpf/bpf.o ../../tools/lib/bpf/nlattr.o
> @@ -95,6 +96,7 @@ xdp_monitor-objs := bpf_load.o $(LIBBPF) xdp_monitor_user.o
>  xdp_rxq_info-objs := bpf_load.o $(LIBBPF) xdp_rxq_info_user.o
>  syscall_tp-objs := bpf_load.o $(LIBBPF) syscall_tp_user.o
>  cpustat-objs := bpf_load.o $(LIBBPF) cpustat_user.o
> +grundig_decoder-objs := bpf_load.o $(LIBBPF) grundig_decoder_user.o
>
>  # Tell kbuild to always build the programs
>  always := $(hostprogs-y)
> @@ -148,6 +150,7 @@ always += xdp_rxq_info_kern.o
>  always += xdp2skb_meta_kern.o
>  always += syscall_tp_kern.o
>  always += cpustat_kern.o
> +always += grundig_decoder_kern.o
>
>  HOSTCFLAGS += -I$(objtree)/usr/include
>  HOSTCFLAGS += -I$(srctree)/tools/lib/
> @@ -193,6 +196,7 @@ HOSTLOADLIBES_xdp_monitor += -lelf
>  HOSTLOADLIBES_xdp_rxq_info += -lelf
>  HOSTLOADLIBES_syscall_tp += -lelf
>  HOSTLOADLIBES_cpustat += -lelf
> +HOSTLOADLIBES_grundig_decoder += -lelf
>
>  # Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on 
> cmdline:
>  #  make samples/bpf/ LLC=~/git/llvm/build/bin/llc 
> CLANG=~/git/llvm/build/bin/clang
> diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
> index bebe4188b4b3..0fd389e95bb9 100644
> --- a/samples/bpf/bpf_load.c
> +++ b/samples/bpf/bpf_load.c
> @@ -69,6 +69,7 @@ static int load_and_attach(const char *event, struct 
> bpf_insn *prog, int size)
> bool is_sockops = strncmp(event, "sockops", 7) == 0;
> bool is_sk_skb = strncmp(event, "sk_skb", 6) == 0;
> bool is_sk_msg = strncmp(event, "sk_msg", 6) == 0;
> +   bool is_ir_decoder = strncmp(event, "ir_decoder", 10) == 0;
> size_t insns_cnt = size / sizeof(struct bpf_insn);
> enum bpf_prog_type prog_type;
> char buf[256];
> @@ -102,6 +103,8 @@ static int load_and_attach(const char *event, struct 
> bpf_insn *prog, int size)
> prog_type = BPF_PROG_TYPE_SK_SKB;
> } else if (is_sk_msg) {
> prog_type = BPF_PROG_TYPE_SK_MSG;
> +   } else if (is_ir_decoder) {
> +   prog_type = BPF_PROG_TYPE_RAWIR_DECODER;
> } else {
> printf("Unknown event '%s'\n", event);
> return -1;
> @@ -116,7 +119,8 @@ static int load_and_attach(const char *event, struct 
> bpf_insn *prog, int size)
>
> prog_fd[prog_cnt++] = fd;
>
> -   if (is_xdp || is_perf_event || is_cgroup_skb || is_cgroup_sk)
> +   if (is_xdp || is_perf_event || is_cgroup_skb || is_cgroup_sk ||
> +   is_ir_decoder)
> return 0;
>
> if (is_socket || is_sockops || is_sk_skb || is_sk_msg) {
> @@ -607,7 +611,8 @@ static int do_load_bpf_file(const char *path, 
> fixup_map_cb fixup_map)
> memcmp(shname, "cgroup/", 7) == 0 ||
> memcmp(shname, "sockops", 7) == 0 ||
> memcmp(shname, "sk_skb", 6) == 0 ||
> -   memcmp(shname, "sk_msg", 6) == 0) {
> +   memcmp(shname, "sk_msg", 6) == 0 ||
> +   memcmp(shname, "ir_decoder", 10) == 0) {
> ret = load_and_attach(shname, data->d_buf,
>   data->d_size);
> if (ret != 0)
> diff --git a/samples/bpf/grundig_decoder_kern.c 
> b/samples/bpf/grundig_decoder_kern.c
> new file mode 100644
> index ..c80f2c9cc69a
> --- /dev/null
> +++ b/samples/bpf/grundig_decoder_kern.c
> @@ -0,0 +1,112 @@
> +
> +#include 
> +#include 
> +#include "bpf_helpers.h"
> +#include 
> +
> +enum grundig_state {
> +   STATE_INACTIVE,
> +   STATE_HEADER_SPACE,
> +   STATE_LEADING_PULSE,
> +   STATE_BITS_SPACE,
> +   STATE_BITS_PULSE,
> +};
> +
> +struct decoder_state {
> +   u32 bits;
> +   enum grundig_state state;
> +   u32 count;
> +   u32 last_space;
> +};
> +
> +struct bpf_map_def 

[tip:core/urgent] objtool: Detect RIP-relative switch table references

2018-05-14 Thread tip-bot for Josh Poimboeuf
Commit-ID:  6f5ec2993b1f39aed12fa6fd56e8dc2272ee8a33
Gitweb: https://git.kernel.org/tip/6f5ec2993b1f39aed12fa6fd56e8dc2272ee8a33
Author: Josh Poimboeuf 
AuthorDate: Mon, 14 May 2018 08:53:24 -0500
Committer:  Ingo Molnar 
CommitDate: Tue, 15 May 2018 07:30:59 +0200

objtool: Detect RIP-relative switch table references

Typically a switch table can be found by detecting a .rodata access
followed an indirect jump:

1969:   4a 8b 0c e5 00 00 00mov0x0(,%r12,8),%rcx
1970:   00
196d: R_X86_64_32S  .rodata+0x438
1971:   e9 00 00 00 00  jmpq   1976 

1972: R_X86_64_PC32 __x86_indirect_thunk_rcx-0x4

Randy Dunlap reported a case (seen with GCC 4.8) where the .rodata
access uses RIP-relative addressing:

19bd:   48 8b 3d 00 00 00 00mov0x0(%rip),%rdi# 19c4 

19c0: R_X86_64_PC32 .rodata+0x45c
19c4:   e9 00 00 00 00  jmpq   19c9 

19c5: R_X86_64_PC32 __x86_indirect_thunk_rdi-0x4

In this case the relocation addend needs to be adjusted accordingly in
order to find the location of the switch table.

The fix is for case 3 (as described in the comments), but also make the
existing case 1 & 2 checks more precise by only adjusting the addend for
R_X86_64_PC32 relocations.

This fixes the following warnings:

  drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool: 
dispc_runtime_suspend()+0xbb8: sibling call from callable instruction with 
modified stack frame
  drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool: 
dispc_runtime_resume()+0xcc5: sibling call from callable instruction with 
modified stack frame

Reported-by: Randy Dunlap 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/b6098294fd67afb69af8c47c9883d7a68bf0f8ea.1526305958.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 tools/objtool/check.c | 33 ++---
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 9bb04fddd3c8..f4bbce838433 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -903,24 +903,24 @@ static struct rela *find_switch_table(struct objtool_file 
*file,
 {
struct rela *text_rela, *rodata_rela;
struct instruction *orig_insn = insn;
+   unsigned long table_offset;
 
+   /* case 1 & 2 */
text_rela = find_rela_by_dest_range(insn->sec, insn->offset, insn->len);
if (text_rela && text_rela->sym == file->rodata->sym &&
!find_symbol_containing(file->rodata, text_rela->addend)) {
 
-   /* case 1 */
-   rodata_rela = find_rela_by_dest(file->rodata,
-   text_rela->addend);
-   if (rodata_rela)
-   return rodata_rela;
+   table_offset = text_rela->addend;
+   if (text_rela->type == R_X86_64_PC32) {
+   /* case 2 */
+   table_offset += 4;
+   file->ignore_unreachables = true;
+   }
 
-   /* case 2 */
-   rodata_rela = find_rela_by_dest(file->rodata,
-   text_rela->addend + 4);
+   rodata_rela = find_rela_by_dest(file->rodata, table_offset);
if (!rodata_rela)
return NULL;
 
-   file->ignore_unreachables = true;
return rodata_rela;
}
 
@@ -954,18 +954,21 @@ static struct rela *find_switch_table(struct objtool_file 
*file,
if (!text_rela || text_rela->sym != file->rodata->sym)
continue;
 
+   table_offset = text_rela->addend;
+   if (text_rela->type == R_X86_64_PC32)
+   table_offset += 4;
+
/*
 * Make sure the .rodata address isn't associated with a
 * symbol.  gcc jump tables are anonymous data.
 */
-   if (find_symbol_containing(file->rodata, text_rela->addend))
-   continue;
-
-   rodata_rela = find_rela_by_dest(file->rodata, 
text_rela->addend);
-   if (!rodata_rela)
+   if (find_symbol_containing(file->rodata, table_offset))
continue;
 
-   return rodata_rela;
+   /* mov [rodata addr], %reg */
+   rodata_rela = find_rela_by_dest(file->rodata, table_offset);
+   if (rodata_rela)
+   return rodata_rela;
   

Re: [PATCH] x86: add the flag -fno-reorder-blocks-and-partition

2018-05-14 Thread Ingo Molnar

* Mikulas Patocka  wrote:

> GCC 8 turns on -freorder-blocks-and-partition by default, the ORC unwinder 
> can't deal with it and it results in a lot of warnings "sibling call from 
> callable instruction with modified stack frame". This patch adds the 
> -fno-reorder-blocks-and-partition option to KBUILD_CFLAGS.
> 
> Signed-off-by: Mikulas Patocka 
> Cc: sta...@vger.kernel.org
> 
> ---
>  arch/x86/Makefile |1 +
>  1 file changed, 1 insertion(+)
> 
> Index: linux-2.6/arch/x86/Makefile
> ===
> --- linux-2.6.orig/arch/x86/Makefile  2018-05-15 07:19:40.0 +0200
> +++ linux-2.6/arch/x86/Makefile   2018-05-15 07:19:40.0 +0200
> @@ -59,6 +59,7 @@ endif
>  #
>  KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
>  KBUILD_CFLAGS += $(call cc-option,-mno-avx,)
> +KBUILD_CFLAGS += $(call cc-option,-fno-reorder-blocks-and-partition,)

Could you check whether the latest objtool fixes in -tip:

  git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git master

solves those warnings?

Thanks,

Ingo


Re: CONFIG_KCOV causing crash in svm_vcpu_run()

2018-05-14 Thread Dmitry Vyukov
On Mon, May 14, 2018 at 7:25 PM, Eric Biggers  wrote:
> On Mon, May 14, 2018 at 07:14:41AM +0200, Dmitry Vyukov wrote:
>> On Mon, May 14, 2018 at 5:02 AM, Eric Biggers  wrote:
>> > Sorry, messed up address for KVM mailing list.  See message below.
>> >
>> > On Sun, May 13, 2018 at 08:00:07PM -0700, Eric Biggers wrote:
>> >> With CONFIG_KCOV=y and an AMD processor, running the following program 
>> >> crashes
>> >> the kernel with no output (I'm testing in a VM, so it's using nested
>> >> virtualization):
>> >>
>> >>   #include 
>> >>   #include 
>> >>   #include 
>> >>
>> >>   int main()
>> >>   {
>> >>   int dev, vm, cpu;
>> >>   char page[4096] __attribute__((aligned(4096))) = { 0 };
>> >>   struct kvm_userspace_memory_region memreg = {
>> >>   .memory_size = 4096,
>> >>   .userspace_addr = (unsigned long)page,
>> >>   };
>> >>   dev = open("/dev/kvm", O_RDONLY);
>> >>   vm = ioctl(dev, KVM_CREATE_VM, 0);
>> >>   cpu = ioctl(vm, KVM_CREATE_VCPU, 0);
>> >>   ioctl(vm, KVM_SET_USER_MEMORY_REGION, );
>> >>   ioctl(cpu, KVM_RUN, 0);
>> >>   }
>> >>
>> >> It bisects down to commit b2ac58f90540e39 ("KVM/SVM: Allow direct access 
>> >> to
>> >> MSR_IA32_SPEC_CTRL").  The bug is apparently that due to the new code for
>> >> managing the SPEC_CTRL MSR, __sanitizer_cov_trace_pc() is being called 
>> >> from
>> >> svm_vcpu_run() before the host's MSR_GS_BASE has been restored, which 
>> >> causes a
>> >> crash somehow.  The following patch fixes it, though I don't know that 
>> >> it's the
>> >> right solution; maybe KCOV should be disabled in the function instead, or 
>> >> maybe
>> >> there's a more fundamental problem.  What do people think?
>>
>>
>> If __sanitizer_cov_trace_pc() crashes, I would expect there must be
>> few more of them here:
>>
>> if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)))
>> svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL);
>>
>> if (svm->spec_ctrl)
>> native_wrmsrl(MSR_IA32_SPEC_CTRL, 0);
>>
>> Compiler inserts these callbacks into every basic block/edge.. Aren't there?
>>
>> Unfortunately we don't have an attribute that disables instrumentation
>> of a single function. This is currently possible only on file level.
>>
>
> Yes, due to the code dealing with MSR_IA32_SPEC_CTRL, there were several calls
> to __sanitizer_cov_trace_pc() before the write to MSR_GS_BASE.  The patch I
> tested moves the write to MSR_GS_BASE to before all of them, so it's once 
> again
> the first thing after the asm block.  Again I'm not sure it's the proper
> solution, but it did make it stop crashing.

>From KCOV perspective:
This is definitely the simplest and less intrusive solution.
It's somewhat unreliable. But it's hard to tell if/when it will
actually break in practice. Compiler can decide to insert the callback
after asm block, or a branch can be added to wrmsrl (e.g. under some
debug config). More reliable solution would be to restore registers in
asm block itself, or move this to a separate file and disable
instrumentation of that file (though, will not save from non-inlined
wrmsrl). But again, the proposed solution may work well for the next
10 years, so additional complexity may not worth it.

Btw, I don't see anything about fs/gs in vmx_vcpu_run. Is it VMLAUNCH
that saves/restores them?


Re: [PATCH 1/2] ARM64: dts: meson-gxbb: odroidc2: enable sdcard UHS modes

2018-05-14 Thread Anand Moon
Hi Jerome

On 14 May 2018 at 19:18, Jerome Brunet  wrote:
> On Wed, 2018-05-02 at 00:29 +0530, Anand Moon wrote:
>> Enable UHS modes for sdcard, on odroidc2.
>>
>> Signed-off-by: Anand Moon 
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts 
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> index 54954b314a45..c90f8b46c60c 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> @@ -258,6 +258,11 @@
>>   cap-sd-highspeed;
>>   max-frequency = <1>;
>>   disable-wp;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> + sd-uhs-ddr50;
>>
>>   cd-gpios = < CARD_6 GPIO_ACTIVE_HIGH>;
>>   cd-inverted;
>
> Hi Anand,
>
> I tried a few sdcards on the OC2 with your 2 patches.
> Like with the libretech-cc, sdr104@200Mhz works "mostly", but, with some
> sdcards, it does not - please see below. The same sdcards appear to be working
> fine on my laptop.
>
> This is something I have not been able to crack yet on the libretech-cc.
>
> I'd suggest dropping sdr104 and keeping the max frequency at 100Mhz until we 
> can
> figure out the problem here.
>
> With this changed:
>
> Tested-by: Jerome Brunet 
>
> dd if=/dev/mmcblk1 of=/dev/zero bs=4M
> [  446.925817] mmc1: tuning execution failed: -5
> [  446.956597] mmc1: tuning execution failed: -5
> [  489.957810] print_req_error: I/O error, dev mmcblk1, sector 6654424
> [  490.141975] print_req_error: I/O error, dev mmcblk1, sector 6656440
> [  490.148304] print_req_error: I/O error, dev mmcblk1, sector 6656944
> [  490.349650] print_req_error: I/O error, dev mmcblk1, sector 6658456
> [  491.804382] print_req_error: I/O error, dev mmcblk1, sector 6747688
> [  492.281246] print_req_error: I/O error, dev mmcblk1, sector 6784992
> [  492.419034] print_req_error: I/O error, dev mmcblk1, sector 6785496
> [  492.865878] print_req_error: I/O error, dev mmcblk1, sector 6791800
> [  493.023809] print_req_error: I/O error, dev mmcblk1, sector 6792192
> [  493.024435] Buffer I/O error on dev mmcblk1, logical block 849024, async 
> page
> read
> [  493.217751] print_req_error: I/O error, dev mmcblk1, sector 6792808
> [  494.891779] mmc1: tuning execution failed: -5
> [  495.374186] print_req_error: 3 callbacks suppressed
> [  495.374193] print_req_error: I/O error, dev mmcblk1, sector 6854576
> [  495.767498] print_req_error: I/O error, dev mmcblk1, sector 686
> [  496.013104] print_req_error: I/O error, dev mmcblk1, sector 6863024
> [  496.223042] print_req_error: I/O error, dev mmcblk1, sector 6864032
> [  496.227003] print_req_error: I/O error, dev mmcblk1, sector 6864536
> [  496.375175] print_req_error: I/O error, dev mmcblk1, sector 6864176
> [  496.375806] Buffer I/O error on dev mmcblk1, logical block 858022, async 
> page
> read
> [  496.521229] print_req_error: I/O error, dev mmcblk1, sector 6864184
> [  496.521852] Buffer I/O error on dev mmcblk1, logical block 858023, async 
> page
> read
> [  503.596978] print_req_error: I/O error, dev mmcblk1, sector 6983312
> [  503.597606] Buffer I/O error on dev mmcblk1, logical block 872914, async 
> page
> read
> [  505.280621] print_req_error: I/O error, dev mmcblk1, sector 7004536
> [  505.281249] Buffer I/O error on dev mmcblk1, logical block 875567, async 
> page
> read
> [  507.372560] print_req_error: I/O error, dev mmcblk1, sector 7048696
> [  507.373192] Buffer I/O error on dev mmcblk1, logical block 881087, async 
> page
> read
> [  511.355248] print_req_error: I/O error, dev mmcblk1, sector 7131352
> [  511.355883] Buffer I/O error on dev mmcblk1, logical block 891419, async 
> page
> read
> [  511.369076] print_req_error: I/O error, dev mmcblk1, sector 7131352
> [  511.369694] Buffer I/O error on dev mmcblk1, logical block 891419, async 
> page
> read
> dd: error reading '/dev/mmcblk1': Input/output error
> 868+7 records in
> 868+7 records out
> 3651252224 bytes (3.7 GB, 3.4 GiB) copied, 66.7736 s, 54.7 MB/s


Thank for your testing, I will also do some more testing on all the
sdcard and share you the result..

Mean while Sandisk Ultra microSDHC UHS-I card @A1 32GB shows.

On my Odroid C2:

[1.165784] meson-gx-mmc d0074000.mmc: allocated mmc-pwrseq
[1.403756] meson-gx-mmc d0072000.mmc: Got CD GPIO
[1.456160] Waiting for root device /dev/mmcblk1p2...
[1.608180] mmc1: new ultra high speed SDR104 SDHC card at address 
[1.610002] mmcblk1: mmc1: JULIE 29.7 GiB
[1.617811]  mmcblk1: p1 p2

Also I did not encounter and read/write failure on the sdcard but I
will re-test them.

root@odroid64:~#  dd if=/dev/mmcblk1 of=/dev/zero bs=4M
7609+1 records in
7609+1 records out
31914983424 bytes (32 GB, 30 GiB) copied, 368.637 s, 86.6 MB/s
root@odroid64:~#


Re: [PATCH 4.16 00/72] 4.16.9-stable review

2018-05-14 Thread Naresh Kamboju
On 14 May 2018 at 12:18, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.16.9 release.
> There are 72 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed May 16 06:47:58 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.9-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.16.9-rc2
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.16.y
git commit: 618cea778f02d997c2e7bc0bf800617cf66f571d
git describe: v4.16.8-72-g618cea778f02
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.8-72-g618cea778f02


No regressions (compared to build v4.16.8-73-gdaccae8696e8)

Boards, architectures and test suites:
-

dragonboard-410c - arm64
* boot - fail: 3, pass: 19
* kselftest - fail: 1, skip: 26, pass: 41
* libhugetlbfs - fail: 1, skip: 1, pass: 89
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 133, pass: 1017
* ltp-timers-tests - pass: 13

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 23, pass: 45
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 134, pass: 1016
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 24, pass: 44
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 133, pass: 1017

qemu_arm64
* boot - fail: 3, pass: 20
* kselftest - skip: 29, pass: 41
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 6, pass: 8
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - fail: 2, skip: 155, pass: 993
* ltp-timers-tests - pass: 13

qemu_x86_64
* boot - pass: 19
* kselftest - skip: 30, pass: 50
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 152, pass: 998
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 21
* kselftest - skip: 28, pass: 37
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 18, pass: 63
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 5, pass: 58
* 

Re: [PATCH v1 3/4] media: rc bpf: move ir_raw_event to uapi

2018-05-14 Thread Y Song
On Mon, May 14, 2018 at 2:11 PM, Sean Young  wrote:
> The context provided to a BPF_PROG_RAWIR_DECODER is a struct ir_raw_event;
> ensure user space has a a definition.
>
> Signed-off-by: Sean Young 
> ---
>  include/media/rc-core.h| 19 +--
>  include/uapi/linux/bpf_rcdev.h | 24 

Patch #2 already referenced this file. So if Patches #1 and #2
applied, there will be
a compilation error. Could you re-arrange your patchset so that after
sequentially
applying each patch, there is no compilation error?

>  2 files changed, 25 insertions(+), 18 deletions(-)
>  create mode 100644 include/uapi/linux/bpf_rcdev.h
>
> diff --git a/include/media/rc-core.h b/include/media/rc-core.h
> index 6742fd86ff65..5d31e31d8ade 100644
> --- a/include/media/rc-core.h
> +++ b/include/media/rc-core.h
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  /**
> @@ -299,24 +300,6 @@ void rc_keydown_notimeout(struct rc_dev *dev, enum 
> rc_proto protocol,
>  void rc_keyup(struct rc_dev *dev);
>  u32 rc_g_keycode_from_table(struct rc_dev *dev, u32 scancode);
>
> -/*
> - * From rc-raw.c
> - * The Raw interface is specific to InfraRed. It may be a good idea to
> - * split it later into a separate header.
> - */
> -struct ir_raw_event {
> -   union {
> -   u32 duration;
> -   u32 carrier;
> -   };
> -   u8  duty_cycle;
> -
> -   unsignedpulse:1;
> -   unsignedreset:1;
> -   unsignedtimeout:1;
> -   unsignedcarrier_report:1;
> -};
> -
>  #define DEFINE_IR_RAW_EVENT(event) struct ir_raw_event event = {}
>
>  static inline void init_ir_raw_event(struct ir_raw_event *ev)
> diff --git a/include/uapi/linux/bpf_rcdev.h b/include/uapi/linux/bpf_rcdev.h
> new file mode 100644
> index ..d8629ff2b960
> --- /dev/null
> +++ b/include/uapi/linux/bpf_rcdev.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/* Copyright (c) 2018 Sean Young 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of version 2 of the GNU General Public
> + * License as published by the Free Software Foundation.
> + */
> +#ifndef _UAPI__LINUX_BPF_RCDEV_H__
> +#define _UAPI__LINUX_BPF_RCDEV_H__
> +
> +struct ir_raw_event {
> +   union {
> +   __u32   duration;
> +   __u32   carrier;
> +   };
> +   __u8duty_cycle;
> +
> +   unsignedpulse:1;
> +   unsignedreset:1;
> +   unsignedtimeout:1;
> +   unsignedcarrier_report:1;
> +};
> +
> +#endif /* _UAPI__LINUX_BPF_RCDEV_H__ */
> --
> 2.17.0
>


Re: [PATCH v1 2/4] media: bpf: allow raw IR decoder bpf programs to be used

2018-05-14 Thread Y Song
On Mon, May 14, 2018 at 2:10 PM, Sean Young  wrote:
> This implements attaching, detaching, querying and execution. The target
> fd has to be the /dev/lircN device.
>
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/ir-bpf-decoder.c | 191 ++
>  drivers/media/rc/lirc_dev.c   |  30 +
>  drivers/media/rc/rc-core-priv.h   |  15 +++
>  drivers/media/rc/rc-ir-raw.c  |   5 +
>  include/uapi/linux/bpf.h  |   1 +
>  kernel/bpf/syscall.c  |   7 ++
>  6 files changed, 249 insertions(+)
>
> diff --git a/drivers/media/rc/ir-bpf-decoder.c 
> b/drivers/media/rc/ir-bpf-decoder.c
> index aaa5e208b1a5..651590a14772 100644
> --- a/drivers/media/rc/ir-bpf-decoder.c
> +++ b/drivers/media/rc/ir-bpf-decoder.c
> @@ -91,3 +91,194 @@ const struct bpf_verifier_ops ir_decoder_verifier_ops = {
> .get_func_proto  = ir_decoder_func_proto,
> .is_valid_access = ir_decoder_is_valid_access
>  };
> +
> +#define BPF_MAX_PROGS 64
> +
> +int rc_dev_bpf_attach(struct rc_dev *rcdev, struct bpf_prog *prog, u32 flags)

flags is not used in this function.

> +{
> +   struct ir_raw_event_ctrl *raw;
> +   struct bpf_prog_array __rcu *old_array;
> +   struct bpf_prog_array *new_array;
> +   int ret;
> +
> +   if (rcdev->driver_type != RC_DRIVER_IR_RAW)
> +   return -EINVAL;
> +
> +   ret = mutex_lock_interruptible(>lock);
> +   if (ret)
> +   return ret;
> +
> +   raw = rcdev->raw;
> +
> +   if (raw->progs && bpf_prog_array_length(raw->progs) >= BPF_MAX_PROGS) 
> {
> +   ret = -E2BIG;
> +   goto out;
> +   }
> +
> +   old_array = raw->progs;
> +   ret = bpf_prog_array_copy(old_array, NULL, prog, _array);
> +   if (ret < 0)
> +   goto out;
> +
> +   rcu_assign_pointer(raw->progs, new_array);
> +   bpf_prog_array_free(old_array);
> +out:
> +   mutex_unlock(>lock);
> +   return ret;
> +}
> +
> +int rc_dev_bpf_detach(struct rc_dev *rcdev, struct bpf_prog *prog, u32 flags)

flags is not used in this function.

> +{
> +   struct ir_raw_event_ctrl *raw;
> +   struct bpf_prog_array __rcu *old_array;
> +   struct bpf_prog_array *new_array;
> +   int ret;
> +
> +   if (rcdev->driver_type != RC_DRIVER_IR_RAW)
> +   return -EINVAL;
> +
> +   ret = mutex_lock_interruptible(>lock);
> +   if (ret)
> +   return ret;
> +
> +   raw = rcdev->raw;
> +
> +   old_array = raw->progs;
> +   ret = bpf_prog_array_copy(old_array, prog, NULL, _array);
> +   if (ret < 0) {
> +   bpf_prog_array_delete_safe(old_array, prog);
> +   } else {
> +   rcu_assign_pointer(raw->progs, new_array);
> +   bpf_prog_array_free(old_array);
> +   }
> +
> +   bpf_prog_put(prog);
> +   mutex_unlock(>lock);
> +   return 0;
> +}
> +
> +void rc_dev_bpf_run(struct rc_dev *rcdev)
> +{
> +   struct ir_raw_event_ctrl *raw = rcdev->raw;
> +
> +   if (raw->progs)
> +   BPF_PROG_RUN_ARRAY(raw->progs, >prev_ev, BPF_PROG_RUN);
> +}
> +
> +void rc_dev_bpf_put(struct rc_dev *rcdev)
> +{
> +   struct bpf_prog_array *progs = rcdev->raw->progs;
> +   int i, size;
> +
> +   if (!progs)
> +   return;
> +
> +   size = bpf_prog_array_length(progs);
> +   for (i = 0; i < size; i++)
> +   bpf_prog_put(progs->progs[i]);
> +
> +   bpf_prog_array_free(rcdev->raw->progs);
> +}
> +
> +int rc_dev_prog_attach(const union bpf_attr *attr)
> +{
> +   struct bpf_prog *prog;
> +   struct rc_dev *rcdev;
> +   int ret;
> +
> +   if (attr->attach_flags & BPF_F_ALLOW_OVERRIDE)
> +   return -EINVAL;

Looks like you really did not use flags except here.
BPF_F_ALLOW_OVERRIDE is originally used for
cgroup type of attachment and the comment explicits
saying so.

In the query below, the flags value "0" is copied to userspace.

In your case, I think you can just disallow any value, i.g.,
attr->attach_flags must be 0, and then you further down
check that if the prog is already in the array, you just return an error.

> +
> +   prog = bpf_prog_get_type(attr->attach_bpf_fd,
> +BPF_PROG_TYPE_RAWIR_DECODER);
> +   if (IS_ERR(prog))
> +   return PTR_ERR(prog);
> +
> +   rcdev = rc_dev_get_from_fd(attr->target_fd);
> +   if (IS_ERR(rcdev)) {
> +   bpf_prog_put(prog);
> +   return PTR_ERR(rcdev);
> +   }
> +
> +   ret = rc_dev_bpf_attach(rcdev, prog, attr->attach_flags);
> +   if (ret)
> +   bpf_prog_put(prog);
> +
> +   put_device(>dev);
> +
> +   return ret;
> +}
> +
> +int rc_dev_prog_detach(const union bpf_attr *attr)
> +{
> +   struct bpf_prog *prog;
> +   struct rc_dev *rcdev;
> +   int ret;
> +
> +   if (attr->attach_flags & BPF_F_ALLOW_OVERRIDE)
> +   

[PATCH] x86: add the flag -fno-reorder-blocks-and-partition

2018-05-14 Thread Mikulas Patocka
GCC 8 turns on -freorder-blocks-and-partition by default, the ORC unwinder 
can't deal with it and it results in a lot of warnings "sibling call from 
callable instruction with modified stack frame". This patch adds the 
-fno-reorder-blocks-and-partition option to KBUILD_CFLAGS.

Signed-off-by: Mikulas Patocka 
Cc: sta...@vger.kernel.org

---
 arch/x86/Makefile |1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6/arch/x86/Makefile
===
--- linux-2.6.orig/arch/x86/Makefile2018-05-15 07:19:40.0 +0200
+++ linux-2.6/arch/x86/Makefile 2018-05-15 07:19:40.0 +0200
@@ -59,6 +59,7 @@ endif
 #
 KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
 KBUILD_CFLAGS += $(call cc-option,-mno-avx,)
+KBUILD_CFLAGS += $(call cc-option,-fno-reorder-blocks-and-partition,)
 
 ifeq ($(CONFIG_X86_32),y)
 BITS := 32


[PATCH] Staging:Comedi:comedi_compat32.c: Lindent changes

2018-05-14 Thread Pratik Jain
Recommended indentation by Lindent on file comedi_compat32.c

Signed-off-by: Pratik Jain 
---
 drivers/staging/comedi/comedi_compat32.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/comedi/comedi_compat32.c 
b/drivers/staging/comedi/comedi_compat32.c
index 97fb9388bc22..fa9d239474ee 100644
--- a/drivers/staging/comedi/comedi_compat32.c
+++ b/drivers/staging/comedi/comedi_compat32.c
@@ -34,7 +34,7 @@
 struct comedi32_chaninfo_struct {
unsigned int subdev;
compat_uptr_t maxdata_list; /* 32-bit 'unsigned int *' */
-   compat_uptr_t flaglist; /* 32-bit 'unsigned int *' */
+   compat_uptr_t flaglist; /* 32-bit 'unsigned int *' */
compat_uptr_t rangelist;/* 32-bit 'unsigned int *' */
unsigned int unused[4];
 };
@@ -57,16 +57,16 @@ struct comedi32_cmd_struct {
unsigned int scan_end_arg;
unsigned int stop_src;
unsigned int stop_arg;
-   compat_uptr_t chanlist; /* 32-bit 'unsigned int *' */
+   compat_uptr_t chanlist; /* 32-bit 'unsigned int *' */
unsigned int chanlist_len;
-   compat_uptr_t data; /* 32-bit 'short *' */
+   compat_uptr_t data; /* 32-bit 'short *' */
unsigned int data_len;
 };
 
 struct comedi32_insn_struct {
unsigned int insn;
unsigned int n;
-   compat_uptr_t data; /* 32-bit 'unsigned int *' */
+   compat_uptr_t data; /* 32-bit 'unsigned int *' */
unsigned int subdev;
unsigned int chanspec;
unsigned int unused[3];
@@ -74,7 +74,7 @@ struct comedi32_insn_struct {
 
 struct comedi32_insnlist_struct {
unsigned int n_insns;
-   compat_uptr_t insns;/* 32-bit 'struct comedi_insn *' */
+   compat_uptr_t insns;/* 32-bit 'struct comedi_insn *' */
 };
 
 /* Handle translated ioctl. */
@@ -194,7 +194,7 @@ static int get_compat_cmd(struct comedi_cmd __user *cmd,
err |= __put_user(temp.uint, >stop_arg);
err |= __get_user(temp.uptr, >chanlist);
err |= __put_user((unsigned int __force *)compat_ptr(temp.uptr),
-   >chanlist);
+ >chanlist);
err |= __get_user(temp.uint, >chanlist_len);
err |= __put_user(temp.uint, >chanlist_len);
err |= __get_user(temp.uptr, >data);
-- 
2.17.0



Re: printk feature for syzbot?

2018-05-14 Thread Sergey Senozhatsky
Hello,

On (05/11/18 09:37), Steven Rostedt wrote:
> > On (05/11/18 11:17), Dmitry Vyukov wrote:
> > > 
> > > From what I see, it seems that interrupts can be nested:  
> > 
> > Hm, I thought that in general IRQ handlers run with local IRQs
> > disabled on CPU. So, generally, IRQs don't nest. Was I wrong?
> > NMIs can nest, that's true; but I thought that at least IRQs
> > don't.
> 
> We normally don't run nested interrupts, although as the comment in
> preempt.h says:
> 
>  * The hardirq count could in theory be the same as the number of
>  * interrupts in the system, but we run all interrupt handlers with
>  * interrupts disabled, so we cannot have nesting interrupts. Though
>  * there are a few palaeontologic drivers which reenable interrupts in
>  * the handler, so we need more than one bit here.
> 
> And no, NMI handlers do not nest. Yes, we deal with nested NMIs, but in
> those cases, we just set a bit as a latch, and return, and when the
> first NMI is complete, it checks that bit and if it is set, it executes
> another NMI handler.

Good to know!
I thought that NMI can nest in some weird cases, like a breakpoint from
NMI. This must be super tricky, given that nested NMI will corrupt the
stack of the previous NMI, etc. Anyway.

> > Well, hm. __irq_enter() does preempt_count_add(HARDIRQ_OFFSET) and
> > __irq_exit() does preempt_count_sub(HARDIRQ_OFFSET). So, technically,
> > you can store
> > 
> > preempt_count() & HARDIRQ_MASK
> > preempt_count() & SOFTIRQ_MASK
> > preempt_count() & NMI_MASK
> >
[..]
> I handle nesting of different contexts in the ftrace ring buffer using
> the preempt count. See trace_recursive_lock/unlock() in
> kernel/trace/ring_buffer.c.

Thanks. So you are also checking the preempt_count().

-ss


Re: possible deadlock in sk_diag_fill

2018-05-14 Thread Dmitry Vyukov
On Mon, May 14, 2018 at 8:00 PM, Andrei Vagin  wrote:
>> >> Hello,
>> >>
>> >> syzbot found the following crash on:
>> >>
>> >> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of 
>> >> git://git.k..
>> >> git tree:   upstream
>> >> console output: https://syzkaller.appspot.com/x/log.txt?x=12164c9780
>> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
>> >> dashboard link: 
>> >> https://syzkaller.appspot.com/bug?extid=c1872be62e587eae9669
>> >> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
>> >> userspace arch: i386
>> >>
>> >> Unfortunately, I don't have any reproducer for this crash yet.
>> >>
>> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> >> Reported-by: syzbot+c1872be62e587eae9...@syzkaller.appspotmail.com
>> >>
>> >>
>> >> ==
>> >> WARNING: possible circular locking dependency detected
>> >> 4.17.0-rc3+ #59 Not tainted
>> >> --
>> >> syz-executor1/25282 is trying to acquire lock:
>> >> 4fddf743 (&(>lock)->rlock/1){+.+.}, at: sk_diag_dump_icons
>> >> net/unix/diag.c:82 [inline]
>> >> 4fddf743 (&(>lock)->rlock/1){+.+.}, at:
>> >> sk_diag_fill.isra.5+0xa43/0x10d0 net/unix/diag.c:144
>> >>
>> >> but task is already holding lock:
>> >> b6895645 (rlock-AF_UNIX){+.+.}, at: spin_lock
>> >> include/linux/spinlock.h:310 [inline]
>> >> b6895645 (rlock-AF_UNIX){+.+.}, at: sk_diag_dump_icons
>> >> net/unix/diag.c:64 [inline]
>> >> b6895645 (rlock-AF_UNIX){+.+.}, at: 
>> >> sk_diag_fill.isra.5+0x94e/0x10d0
>> >> net/unix/diag.c:144
>> >>
>> >> which lock already depends on the new lock.
>> >
>> > In the code, we have a comment which explains why it is safe to take this 
>> > lock
>> >
>> > /*
>> >  * The state lock is outer for the same sk's
>> >  * queue lock. With the other's queue locked it's
>> >  * OK to lock the state.
>> >  */
>> > unix_state_lock_nested(req);
>> >
>> > It is a question how to explain this to lockdep.
>>
>> Do I understand it correctly that (>lock)->rlock associated with
>> AF_UNIX is locked under rlock-AF_UNIX, and then rlock-AF_UNIX is
>> locked under (>lock)->rlock associated with AF_NETLINK? If so, I
>> think we need to split (>lock)->rlock by family too, so that we
>> have u->lock-AF_UNIX and u->lock-AF_NETLINK.
>
> I think here is another problem. lockdep woried about
> sk->sk_receive_queue vs unix_sk(s)->lock.
>
> sk_diag_dump_icons() takes sk->sk_receive_queue and then
> unix_sk(s)->lock.
>
> unix_dgram_sendmsg takes unix_sk(sk)->lock and then sk->sk_receive_queue.
>
> sk_diag_dump_icons() takes locks for two different sockets, but
> unix_dgram_sendmsg() takes locks for one socket.
>
> sk_diag_dump_icons
> if (sk->sk_state == TCP_LISTEN) {
> spin_lock(>sk_receive_queue.lock);
> skb_queue_walk(>sk_receive_queue, skb) {
> unix_state_lock_nested(req);
> spin_lock_nested(_sk(s)->lock,
>
>
> unix_dgram_sendmsg
> unix_state_lock(other)
> spin_lock(_sk(s)->lock)
> skb_queue_tail(>sk_receive_queue, skb);
> spin_lock_irqsave(>lock, flags);


Do you mean the following?
There is socket 1 with state lock (S1) and queue lock (Q2), and socket
2 with state lock (S2) and queue lock (Q2). unix_dgram_sendmsg lock
S1->Q1. And sk_diag_dump_icons locks Q1->S2.
If yes, then this looks pretty much as deadlock. Consider that 2
unix_dgram_sendmsg in 2 different threads lock S1 and S2 respectively.
Now 2  sk_diag_dump_icons in 2 different threads lock Q1 and Q2
respectively. Now sk_diag_dump_icons want to lock S's, and
unix_dgram_sendmsg want to lock Q's. Nobody can proceed.


Re: [PATCH v9 06/11] arm64: kexec_file: allow for loading Image-format kernel

2018-05-14 Thread AKASHI Takahiro
James,

On Fri, May 11, 2018 at 06:07:06PM +0100, James Morse wrote:
> Hi Akashi,
> 
> On 07/05/18 08:21, AKASHI Takahiro wrote:
> > On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote:
> >> On 25/04/18 07:26, AKASHI Takahiro wrote:
> >>> This patch provides kexec_file_ops for "Image"-format kernel. In this
> >>> implementation, a binary is always loaded with a fixed offset identified
> >>> in text_offset field of its header.
> 
> >>> diff --git a/arch/arm64/include/asm/kexec.h 
> >>> b/arch/arm64/include/asm/kexec.h
> >>> index e4de1223715f..3cba4161818a 100644
> >>> --- a/arch/arm64/include/asm/kexec.h
> >>> +++ b/arch/arm64/include/asm/kexec.h
> >>> @@ -102,6 +102,56 @@ struct kimage_arch {
> >>>   void *dtb_buf;
> >>>  };
> >>>  
> >>> +/**
> >>> + * struct arm64_image_header - arm64 kernel image header
> >>> + *
> >>> + * @pe_sig: Optional PE format 'MZ' signature

To be precise, this is NOT a PE signature but MS-DOS header's magic.
(There is another "PE" signature in PE COFF file header pointed to by
'pe_header'.)
I will correct its name.

> >>> + * @branch_code: Instruction to branch to stext
> >>> + * @text_offset: Image load offset, little endian
> >>> + * @image_size: Effective image size, little endian
> >>> + * @flags:
> >>> + *   Bit 0: Kernel endianness. 0=little endian, 1=big endian
> >>
> >> Page size? What about 'phys_base'?, (whatever that is...)
> >> Probably best to refer to Documentation/arm64/booting.txt here, its the
> >> authoritative source of what these fields mean.
> > 
> > While we don't care other bit fields for now, I will add the reference
> > to the Documentation file.
> 
> Thanks, I don't want to create a second, incomplete set of documentation!

I will leave a minimum of description of parameters here.

> 
> 
> >>> + u64 reserved[3];
> >>> + u8 magic[4];
> >>> + u32 pe_header;
> >>> +};
> >>
> >> I'm surprised we don't have a definition for this already, I guess its 
> >> always
> >> done in asm. We have kernel/image.h that holds some of this stuff, if we 
> >> are
> >> going to validate the flags, is it worth adding the code there, (and 
> >> moving it
> >> to include/asm)?
> > 
> > A comment at the beginning of this file says,
> > #ifndef LINKER_SCRIPT
> > #error This file should only be included in vmlinux.lds.S
> > #endif
> > Let me think about.
> 
> Ah, I missed that.
> 
> Having two definitions of something makes me nervous that they can become
> different... looks like that header belongs to the linker, and shouldn't be 
> used
> here then.

OK.

> 
> >> I guess you skip the MZ prefix as its not present for !EFI?

Correct, but MZ checking in probe function is just an informative message.

> > 
> > CONFIG_KEXEC_IMAGE_VERIFY_SIG depends on the fact that the file
> > format is PE (that is, EFI is enabled).
> 
> So if the signature checking is enabled, its already been checked.

The signature, either MZ or PE, in a file will be actually checked
in verify_pefile_signature().

> 
> >> Could we check branch_code is non-zero, and text-offset points within 
> >> image-size?
> > 
> > We could do it, but I don't think this check is very useful.
> > 
> >>
> >> We could check that this platform supports the page-size/endian config 
> >> that this
> >> Image was built with... We get a message from the EFI stub if the page-size
> >> can't be supported, it would be nice to do the same here (as we can).
> > 
> > There is no restriction on page-size or endianness for kexec.
> 
> No, but it won't boot if the hardware doesn't support it. The kernel will spin
> at a magic address that is, difficult, to debug without JTAG. The bug report
> will be "it didn't boot".

OK.
Added sanity checks for cpu features, endianness as well as page size.

> 
> > What will be the purpose of this check?
> 
> These values are in the header so that the bootloader can check them, then 
> print
> a meaningful error. Here, kexec_file_load() is playing the part of the 
> bootloader.
> 
> I'm assuming kexec_file_load() can only be used to kexec linux... unlike 
> regular
> kexec. Is this where I'm going wrong?
> 
> 
> >>> diff --git a/arch/arm64/kernel/kexec_image.c 
> >>> b/arch/arm64/kernel/kexec_image.c
> >>> new file mode 100644
> >>> index ..4dd524ad6611
> >>> --- /dev/null
> >>> +++ b/arch/arm64/kernel/kexec_image.c
> >>> @@ -0,0 +1,79 @@
> >>
> >>> +static void *image_load(struct kimage *image,
> >>> + char *kernel, unsigned long kernel_len,
> >>> + char *initrd, unsigned long initrd_len,
> >>> + char *cmdline, unsigned long cmdline_len)
> >>> +{
> >>> + struct kexec_buf kbuf;
> >>> + struct arm64_image_header *h = (struct arm64_image_header *)kernel;
> >>> + unsigned long text_offset;
> >>> + int ret;
> >>> +
> >>> + /* Load the kernel */
> >>> + kbuf.image = image;
> >>> + kbuf.buf_min = 0;
> >>> + kbuf.buf_max = ULONG_MAX;
> >>> + kbuf.top_down = false;
> >>> +
> >>> + kbuf.buffer = kernel;
> 

Re: [PATCH V2] powercap/drivers/idle_injection: Add an idle injection framework

2018-05-14 Thread Viresh Kumar
On 11-05-18, 13:55, Daniel Lezcano wrote:
> On Fri, May 11, 2018 at 03:02:21PM +0530, viresh kumar wrote:
> > On 10-05-18, 14:26, Daniel Lezcano wrote:
> > > +int idle_injection_start(struct idle_injection_device *ii_dev)
> > > +{
> > > + if (!atomic_read(_dev->idle_duration_ms))
> > > + return -EINVAL;
> > > +
> > > + if (!atomic_read(_dev->run_duration_ms))
> > > + return -EINVAL;
> > 
> > You are required to have them as atomic variables to take care of the
> > races while they are set ? 
> 
> The race is when you change the values, while the idle injection is acting and
> you read those values in the idle injection thread function.
> 
> > What about getting the durations as arguments to this routine then ?
> 
> May be I missed your point but I don't think that will change the above.

Well, it can. Can you explain the kind of use-cases you have in mind ?

For example, what I assumed to be the usecase was:

idle_injection_start(iidev, idle_duration, run_duration);

and then at some point of time:

idle_injection_stop(iidev);


With this, you would be required to stop the idle injection stuff to
reconfigure the durations. And then you will never have a race which
you mentioned above.

What you are trying to do is something like this:

idle_injection_set_duration(idle_duration, run_duration);
idle_injection_start(iidev);

and then at some point of time:
idle_injection_set_duration(idle_duration2, run_duration2);

and then at some point of time:
idle_injection_stop(iidev);

I am not sure if we would ever want to do something like this. Or if
stopping the idle injection to start it again is that bad of an idea.

> > > +struct idle_injection_device *
> > > +idle_injection_register(struct cpumask *cpumask, const char *name)
> > > +{
> > > + struct idle_injection_device *ii_dev;
> > > + struct smp_hotplug_thread *smp_hotplug_thread;
> > > + char *idle_injection_comm;
> > > + int cpu, ret;
> > > +
> > > + ret = -ENOMEM;
> > 
> > Maybe merge it earlier only ?
> 
> What do you mean ? int ret = -ENOMEM ?

Yes.

-- 
viresh


Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

2018-05-14 Thread kgunda

On 2018-05-14 22:27, Pavel Machek wrote:

Hi!


WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -
 drivers/video/backlight/qcom-wled.c| 749 
+++--

 2 files changed, 696 insertions(+), 225 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index fb39e32..0ceffa1 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,30 +1,129 @@
 Binding for Qualcomm Technologies, Inc. WLED driver

-Required properties:
-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be "qcom,pm8941-wled" or "qcom,pmi8998-wled".
+ or "qcom,pm660l-wled".
+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.


I'm not sure if this change of format is good idea here...

Pavel
--
This format is clean and easily readable. That's why I have moved to 
this format.
To avoid confusion, I will move out the existing properties 
(pm8941-wled.c) to other

patch. So that it will be easy to review.

To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic

2018-05-14 Thread kgunda

On 2018-05-14 22:32, Bjorn Andersson wrote:

On Wed 09 May 00:14 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 23:40, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
>
> [..]
> > +
> > +#define WLED_AUTO_DETECT_OVP_COUNT   5
> > +#define WLED_AUTO_DETECT_CNT_DLY_US  HZ /* 1 second */
> > +static bool wled_auto_detection_required(struct wled *wled)
>
> So cfg.auto_detection_enabled is set, but we didn't have a fault during
> wled_auto_detection_at_init(), which I presume indicates that the boot
> loader configured the strings appropriately (or didn't enable the BL).
> Then first time we try to enable the backlight we will hit the ovp irq,
> which will  enter here a few times to figure out that the strings are
> incorrectly configured and then we will do the same thing that would
> have been done if we probed with a fault.
>
> This is convoluted!
>
> If auto-detection is a feature allowing the developer to omit the string
> configuration then just do the auto detection explicitly in probe when
> the developer did so and then never do it again.
>
As explained in the previous patch, the auto-detection is needed 
later,
because are also cases where one/more of the connected LED string of 
the
display-backlight is malfunctioning (because of damage) and requires 
the
damaged string to be turned off to prevent the complete panel and/or 
board

from being damaged.


Okay, that sounds very reasonable. Please ensure that it's clearly
described in the commit message, so that we have this documented if
someone wonders in the future.

Regards,
Bjorn
--

Thanks for that ! Sure I will describe it in the commit message.
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[git pull] drm fix for mmap regression

2018-05-14 Thread Dave Airlie
Hi Linus,

This patch fixes the mmap regression reported to me on irc by an i686
kernel user today, he's tested the fix works, and I've audited all the
drm drivers for the bad mmap usage and since we use the mmap offset as
a lookup in a table we aren't inclined to have anything bad in there.

Thanks,
Dave.

The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:

  Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux
tags/drm-fixes-for-v4.17-rc6-urgent

for you to fetch changes up to 76ef6b28ea4f81c3d511866a9b31392caa833126:

  drm: set FMODE_UNSIGNED_OFFSET for drm files (2018-05-15 14:46:04 +1000)


urgent i686 mmap fix for drm drivers


Dave Airlie (1):
  drm: set FMODE_UNSIGNED_OFFSET for drm files

 drivers/gpu/drm/drm_file.c | 1 +
 1 file changed, 1 insertion(+)


Re: [PATCH v1 1/4] media: rc: introduce BPF_PROG_IR_DECODER

2018-05-14 Thread Y Song
On Mon, May 14, 2018 at 2:10 PM, Sean Young  wrote:
> Add support for BPF_PROG_IR_DECODER. This type of BPF program can call
> rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> that the last key should be repeated.
>
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/Kconfig  |  8 +++
>  drivers/media/rc/Makefile |  1 +
>  drivers/media/rc/ir-bpf-decoder.c | 93 +++
>  include/linux/bpf_types.h |  3 +
>  include/uapi/linux/bpf.h  | 16 +-
>  5 files changed, 120 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/rc/ir-bpf-decoder.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index eb2c3b6eca7f..10ad6167d87c 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -120,6 +120,14 @@ config IR_IMON_DECODER
>remote control and you would like to use it with a raw IR
>receiver, or if you wish to use an encoder to transmit this IR.
>
> +config IR_BPF_DECODER
> +   bool "Enable IR raw decoder using BPF"
> +   depends on BPF_SYSCALL
> +   depends on RC_CORE=y
> +   help
> +  Enable this option to make it possible to load custom IR
> +  decoders written in BPF.
> +
>  endif #RC_DECODERS
>
>  menuconfig RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 2e1c87066f6c..12e1118430d0 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -5,6 +5,7 @@ obj-y += keymaps/
>  obj-$(CONFIG_RC_CORE) += rc-core.o
>  rc-core-y := rc-main.o rc-ir-raw.o
>  rc-core-$(CONFIG_LIRC) += lirc_dev.o
> +rc-core-$(CONFIG_IR_BPF_DECODER) += ir-bpf-decoder.o
>  obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
>  obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
>  obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
> diff --git a/drivers/media/rc/ir-bpf-decoder.c 
> b/drivers/media/rc/ir-bpf-decoder.c
> new file mode 100644
> index ..aaa5e208b1a5
> --- /dev/null
> +++ b/drivers/media/rc/ir-bpf-decoder.c
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// ir-bpf-decoder.c - handles bpf decoders
> +//
> +// Copyright (C) 2018 Sean Young 
> +
> +#include 
> +#include 
> +#include "rc-core-priv.h"
> +
> +/*
> + * BPF interface for raw IR decoder
> + */
> +const struct bpf_prog_ops ir_decoder_prog_ops = {
> +};
> +
> +BPF_CALL_1(bpf_rc_repeat, struct ir_raw_event*, event)
> +{
> +   struct ir_raw_event_ctrl *ctrl;
> +
> +   ctrl = container_of(event, struct ir_raw_event_ctrl, prev_ev);
> +
> +   rc_repeat(ctrl->dev);
> +   return 0;
> +}
> +
> +static const struct bpf_func_proto rc_repeat_proto = {
> +   .func  = bpf_rc_repeat,
> +   .gpl_only  = true, // rc_repeat is EXPORT_SYMBOL_GPL
> +   .ret_type  = RET_VOID,

I suggest using RET_INTEGER here since we do return an integer 0.
RET_INTEGER will also make it easy to extend if you want to return
a non-zero value for error code or other reasons.

> +   .arg1_type = ARG_PTR_TO_CTX,
> +};
> +
> +BPF_CALL_4(bpf_rc_keydown, struct ir_raw_event*, event, u32, protocol,
> +  u32, scancode, u32, toggle)
> +{
> +   struct ir_raw_event_ctrl *ctrl;
> +
> +   ctrl = container_of(event, struct ir_raw_event_ctrl, prev_ev);
> +   rc_keydown(ctrl->dev, protocol, scancode, toggle != 0);
> +   return 0;
> +}
> +
> +static const struct bpf_func_proto rc_keydown_proto = {
> +   .func  = bpf_rc_keydown,
> +   .gpl_only  = true, // rc_keydown is EXPORT_SYMBOL_GPL
> +   .ret_type  = RET_VOID,

ditto. RET_INTEGER is preferable.

> +   .arg1_type = ARG_PTR_TO_CTX,
> +   .arg2_type = ARG_ANYTHING,
> +   .arg3_type = ARG_ANYTHING,
> +   .arg4_type = ARG_ANYTHING,
> +};
> +
> +static const struct bpf_func_proto *ir_decoder_func_proto(enum bpf_func_id 
> func_id, const struct bpf_prog *prog)
> +{
> +   switch (func_id) {
> +   case BPF_FUNC_rc_repeat:
> +   return _repeat_proto;
> +   case BPF_FUNC_rc_keydown:
> +   return _keydown_proto;
> +   case BPF_FUNC_map_lookup_elem:
> +   return _map_lookup_elem_proto;
> +   case BPF_FUNC_map_update_elem:
> +   return _map_update_elem_proto;
> +   case BPF_FUNC_map_delete_elem:
> +   return _map_delete_elem_proto;
> +   case BPF_FUNC_ktime_get_ns:
> +   return _ktime_get_ns_proto;
> +   case BPF_FUNC_tail_call:
> +   return _tail_call_proto;
> +   case BPF_FUNC_get_prandom_u32:
> +   return _get_prandom_u32_proto;
> +   default:
> +   return NULL;
> +   }
> +}
> +
> +static bool ir_decoder_is_valid_access(int off, int size,
> +  enum bpf_access_type type,
> +  const struct bpf_prog *prog,
> +  struct 

Re: [PATCH] driver core: Respect all error codes from dev_pm_domain_attach()

2018-05-14 Thread Guenter Roeck
On Thu, Apr 26, 2018 at 10:53:06AM +0200, Ulf Hansson wrote:
> The limitation of being able to check only for -EPROBE_DEFER from
> dev_pm_domain_attach() has been removed. Hence let's respect all error
> codes and bail out accordingly.
> 

AFAICS this patch causes all drivers/devices to fail instantiating
if dev_pm_domain_set() is called in the device initialization path.
That seems to be a systemic problem, since dev_pm_domain_set() must
only be called for unbound devices.

In practice, I see the problem when trying to boot beagle or overo
with qemu (the Linaro version). Of course, that doesn't mean much
because that is not real hardware. However, I am not surprised that
all devices instantiated through, for example, omap_device_build_from_dt()
fail to instantiate. Instrumentation confirms that dev_pm_domain_set()
is called prior to platform_drv_probe(). 

Guenter

> Signed-off-by: Ulf Hansson 
> Acked-by: Greg Kroah-Hartman 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/base/platform.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 8075ddc70a17..9460139d9b02 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -572,17 +572,16 @@ static int platform_drv_probe(struct device *_dev)
>   return ret;
>  
>   ret = dev_pm_domain_attach(_dev, true);
> - if (ret != -EPROBE_DEFER) {
> - if (drv->probe) {
> - ret = drv->probe(dev);
> - if (ret)
> - dev_pm_domain_detach(_dev, true);
> - } else {
> - /* don't fail if just dev_pm_domain_attach failed */
> - ret = 0;
> - }
> + if (ret)
> + goto out;
> +
> + if (drv->probe) {
> + ret = drv->probe(dev);
> + if (ret)
> + dev_pm_domain_detach(_dev, true);
>   }
>  
> +out:
>   if (drv->prevent_deferred_probe && ret == -EPROBE_DEFER) {
>   dev_warn(_dev, "probe deferral not supported\n");
>   ret = -ENXIO;
> -- 
> 2.7.4


Re: [PATCH v7] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

2018-05-14 Thread Chris Moore

Hi,

Le 13/05/2018 à 06:30, Wan, Jane (Nokia - US/Sunnyvale) a écrit :

Per ONFI specification (Rev. 4.0), if all parameter pages have invalid CRC 
values, the bit-wise majority may be used to recover the contents of the 
parameter pages from the parameter page copies present.

Signed-off-by: Jane Wan 
---
v7: change debug print messages
v6: support the cases that srcbufs are not contiguous
v5: make the bit-wise majority functon generic
v4: move the bit-wise majority code in a separate function
v3: fix warning message detected by kbuild test robot
v2: rebase the changes on top of v4.17-rc1
  
drivers/mtd/nand/raw/nand_base.c |   50 ++

  1 file changed, 45 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89..b43b784 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5087,6 +5087,35 @@ static int nand_flash_detect_ext_param_page(struct 
nand_chip *chip,
  }
  
  /*

+ * Recover data with bit-wise majority
+ */
+static void nand_bit_wise_majority(const void **srcbufs,
+  unsigned int nsrcbufs,
+  void *dstbuf,
+  unsigned int bufsize)
+{
+   int i, j, k;
+
+   for (i = 0; i < bufsize; i++) {
+   u8 cnt, val;
+
+   val = 0;
+   for (j = 0; j < 8; j++) {
+   cnt = 0;
+   for (k = 0; k < nsrcbufs; k++) {
+   const u8 *srcbuf = srcbufs[k];
+
+   if (srcbuf[i] & BIT(j))
+   cnt++;
+   }
+   if (cnt > nsrcbufs / 2)
+   val |= BIT(j);
+   }
+   ((u8 *)dstbuf)[i] = val;
+   }
+}
+
+/*
   * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
   */
  static int nand_flash_detect_onfi(struct nand_chip *chip)
@@ -5102,7 +5131,7 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
return 0;
  
  	/* ONFI chip: allocate a buffer to hold its parameter page */

-   p = kzalloc(sizeof(*p), GFP_KERNEL);
+   p = kzalloc((sizeof(*p) * 3), GFP_KERNEL);
if (!p)
return -ENOMEM;
  
@@ -5113,21 +5142,32 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)

}
  
  	for (i = 0; i < 3; i++) {

-   ret = nand_read_data_op(chip, p, sizeof(*p), true);
+   ret = nand_read_data_op(chip, [i], sizeof(*p), true);
if (ret) {
ret = 0;
goto free_onfi_param_page;
}
  
-		if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==

+   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)[i], 254) ==
le16_to_cpu(p->crc)) {
+   if (i)
+   memcpy(p, [i], sizeof(*p));
break;
}
}
  
  	if (i == 3) {

-   pr_err("Could not find valid ONFI parameter page; aborting\n");
-   goto free_onfi_param_page;
+   const void *srcbufs[3] = {p, p + 1, p + 2};
+
+   pr_warn("Could not find a valid ONFI parameter page, trying bit-wise 
majority to recover it\n");
+   nand_bit_wise_majority(srcbufs, ARRAY_SIZE(srcbufs), p,
+  sizeof(*p));
+
+   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)p, 254) !=
+   le16_to_cpu(p->crc)) {
+   pr_err("ONFI parameter recovery failed, aborting\n");
+   goto free_onfi_param_page;
+   }
}
  
  	/* Check version */


This version is still hard coded for a three sample bitwise majority vote.
So why not use the method which I suggested previously for v2 and which 
I repeat below?


The three sample bitwise majority can be implemented without bit level 
manipulation using the identity:

majority3(a, b, c) = (a & b) | (a & c) | (b & c)
This can be factorized slightly to (a & (b | c)) | (b & c)
This enables the operation to be performed 8, 16, 32 or even 64 bits at 
a time depending on the hardware.


This method is not only faster and but also more compact.

Cheers,
Chris



Re: [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory

2018-05-14 Thread AKASHI Takahiro
James,

On Fri, May 11, 2018 at 06:03:49PM +0100, James Morse wrote:
> Hi Akashi,
> 
> On 07/05/18 06:22, AKASHI Takahiro wrote:
> > On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
> >> On 25/04/18 07:26, AKASHI Takahiro wrote:
> >>> diff --git a/arch/arm64/kernel/machine_kexec.c 
> >>> b/arch/arm64/kernel/machine_kexec.c
> >>> index f76ea92dff91..f7dbba00be10 100644
> >>> --- a/arch/arm64/kernel/machine_kexec.c
> >>> +++ b/arch/arm64/kernel/machine_kexec.c
> >>> @@ -205,10 +205,17 @@ void machine_kexec(struct kimage *kimage)
> 
> >>>   cpu_soft_restart(kimage != kexec_crash_image,
> >>> - reboot_code_buffer_phys, kimage->head, kimage->start, 0);
> >>> + reboot_code_buffer_phys, kimage->head, kimage->start,
> >>> +#ifdef CONFIG_KEXEC_FILE
> >>> + kimage->purgatory_info.purgatory_buf ?
> >>> + 0 : kimage->arch.dtb_mem);
> >>> +#else
> >>> + 0);
> >>> +#endif
> 
> 
> >> purgatory_buf seems to only be set in kexec_purgatory_setup_kbuf(), called 
> >> from
> >> kexec_load_purgatory(), which we don't use. How does this get a value?
> >>
> >> Would it be better to always use kimage->arch.dtb_mem, and ensure that is 
> >> 0 for
> >> regular kexec (as we can't know where the dtb is)? (image_arg may then be a
> >> better name).
> > 
> > The problem is arch.dtb_mem is currently defined only if CONFIG_KEXEC_FILE.
> 
> I thought it was ARCH_HAS_KIMAGE_ARCH, which we can define all the time if
> that's what we want.
> 
> 
> > So I would like to
> > - merge this patch with patch#8
> > - change the condition
> > #ifdef CONFIG_KEXEC_FILE
> > kimage->file_mode ? 
> > kimage->arch.dtb_mem : 0);
> > #else
> > 0);
> > #endif
> 
> If we can avoid even this #ifdef by always having kimage->arch, I'd prefer 
> that.
> If we do that 'dtb_mem' would need some thing that indicates its for 
> kexec_file,
> as kexec has a DTB too, we just don't know where it is...

OK, but I want to have a minimum of kexec.arch always exist.
How about this?

| #define ARCH_HAS_KIMAGE_ARCH
|
| struct kimage_arch {
|   phys_addr_t dtb_mem;
| #ifdef CONFIG_KEXEC_FILE
|   void *dtb_buf;
|   /* Core ELF header buffer */
|   void *elf_headers;
|   unsigned long elf_headers_sz;
|   unsigned long elf_load_addr;
| #endif

| void machine_kexec(struct kimage *kimage)
| {
|   ...
|   cpu_soft_restart(kimage != kexec_crash_image,
|   reboot_code_buffer_phys, kimage->head, kimage->start,
|   kimage->arch.dtb_mem);

Thanks
-Takahiro AKASHI

> 
> 
> Thanks,
> 
> James


[PATCH v2] arm64: dts: qcom: sdm845: Sort nodes in the reserved mem by address

2018-05-14 Thread Douglas Anderson
Let's keep the reserved-memory node tidy and neat and keep it sorted
by address.  This should have no functional change.

Signed-off-by: Douglas Anderson 
---

Changes in v2:
- Oops!  v1 accidentally changed the node name.  Fixed.

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 7c85e7c596db..73f71061fef8 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -31,6 +31,12 @@
no-map;
};
 
+   memory@85fe {
+   compatible = "qcom,cmd-db";
+   reg = <0x0 0x85fe 0x0 0x2>;
+   no-map;
+   };
+
smem_mem: memory@8600 {
reg = <0x0 0x8600 0x0 0x20>;
no-map;
@@ -40,12 +46,6 @@
reg = <0 0x8620 0 0x2d0>;
no-map;
};
-
-   memory@85fe {
-   compatible = "qcom,cmd-db";
-   reg = <0x0 0x85fe 0x0 0x2>;
-   no-map;
-   };
};
 
cpus {
-- 
2.17.0.441.gb46fe60e1d-goog



[PATCH] vsprintf: Add command line option debug_boot_weak_hash

2018-05-14 Thread Tobin C. Harding
Currently printing [hashed] pointers requires enough entropy to be
available.  Early in the boot sequence this may not be the case
resulting in a dummy string '(ptrval)' being printed.  This
makes debugging the early boot sequence difficult.  We can relax the
requirement to use cryptographically secure hashing during debugging.
This enables debugging while keeping development/production kernel
behaviour the same.

If new command line option debug_boot_weak_hash is enabled use
cryptographically insecure hashing and hash pointer value immediately.

Signed-off-by: Tobin C. Harding 
---

This patch was previously submitted as the last in the set

[PATCH v3 0/4] enable early printing of hashed pointers

Helps debugging using ftrace.  Original problem reported by Anna-Maria,
solution requested by Steve.

Changes since above mentioned patch set
 - change option name from debug_early_boot -> debug_boot_weak_hash
   (suggested by Steve).


I have only tested this by enabling the option and printing some
pointers.  This does not _prove_ that it fixes the ftrace issue.

thanks,
Tobin.


 Documentation/admin-guide/kernel-parameters.txt |  8 
 lib/vsprintf.c  | 18 ++
 2 files changed, 26 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 3b8032431585..c95dd6704592 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -748,6 +748,14 @@
 
debug   [KNL] Enable kernel debugging (events log level).
 
+   debug_boot_weak_hash
+   [KNL] Enable debugging early in the boot sequence.  If
+   enabled, we use a weak hash instead of siphash to hash
+   pointers.  Use this option if you need to see pointer
+   values during early boot (i.e you are seeing instances
+   of '(___ptrval___)') - cryptographically insecure,
+   please do not use on production kernels.
+
debug_locks_verbose=
[KNL] verbose self-tests
Format=<0|1>
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index b82f0c6c2aec..5ff18f8fe3bd 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1654,6 +1654,18 @@ char *device_node_string(char *buf, char *end, struct 
device_node *dn,
return widen_string(buf, buf - buf_start, end, spec);
 }
 
+/* Make pointers available for printing early in the boot sequence. */
+static int debug_boot_weak_hash __ro_after_init;
+EXPORT_SYMBOL(debug_boot_weak_hash);
+
+static int __init debug_boot_weak_hash_enable(char *str)
+{
+   debug_boot_weak_hash = 1;
+   pr_info("debug_boot_weak_hash enabled\n");
+   return 0;
+}
+early_param("debug_boot_weak_hash", debug_boot_weak_hash_enable);
+
 static bool have_filled_random_ptr_key __read_mostly;
 static siphash_key_t ptr_key __read_mostly;
 
@@ -1694,6 +1706,12 @@ static char *ptr_to_id(char *buf, char *end, void *ptr, 
struct printf_spec spec)
const char *str = sizeof(ptr) == 8 ? "(ptrval)" : "(ptrval)";
unsigned long hashval;
 
+   /* When debugging early boot use non-cryptographically secure hash */
+   if (unlikely(debug_boot_weak_hash)) {
+   hashval = hash_long((unsigned long)ptr, 32);
+   return pointer_string(buf, end, (const void *)hashval, spec);
+   }
+
if (unlikely(!have_filled_random_ptr_key)) {
spec.field_width = 2 * sizeof(ptr);
/* string length must be less than default_width */
-- 
2.7.4



[PATCH] arm64: dts: qcom: sdm845: Sort nodes in the reserved mem by address

2018-05-14 Thread Douglas Anderson
Let's keep the reserved-memory node tidy and neat and keep it sorted
by address.  This should have no functional change.

Signed-off-by: Douglas Anderson 
---

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 7c85e7c596db..63026133feab 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -31,6 +31,12 @@
no-map;
};
 
+   reserved-memory@85fe {
+   compatible = "qcom,cmd-db";
+   reg = <0x0 0x85fe 0x0 0x2>;
+   no-map;
+   };
+
smem_mem: memory@8600 {
reg = <0x0 0x8600 0x0 0x20>;
no-map;
@@ -40,12 +46,6 @@
reg = <0 0x8620 0 0x2d0>;
no-map;
};
-
-   memory@85fe {
-   compatible = "qcom,cmd-db";
-   reg = <0x0 0x85fe 0x0 0x2>;
-   no-map;
-   };
};
 
cpus {
-- 
2.17.0.441.gb46fe60e1d-goog



Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

2018-05-14 Thread AKASHI Takahiro
James,

On Mon, May 07, 2018 at 02:59:07PM +0900, AKASHI Takahiro wrote:
> James,
> 
> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> > Hi Akashi,
> > 
> > On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > We need to prevent firmware-reserved memory regions, particularly EFI
> > > memory map as well as ACPI tables, from being corrupted by loading
> > > kernel/initrd (or other kexec buffers). We also want to support memory
> > > allocation in top-down manner in addition to default bottom-up.
> > > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > > for available memory ranges in usable memblock list,
> > > i.e. !NOMAP & !reserved, 
> > 
> > > instead of system resource tree.
> > 
> > Didn't we try to fix the system-resource-tree in order to fix regular-kexec 
> > to
> > be safe in the EFI-memory-map/ACPI-tables case?
> > 
> > It would be good to avoid having two ways of doing this, and I would like to
> > avoid having extra arch code...
> 
> I know what you mean.
> /proc/iomem or system resource is, in my opinion, not the best place to
> describe memory usage of kernel but rather to describe *physical* hardware
> layout. As we are still discussing about "reserved" memory, I don't want
> to depend on it.
> Along with memblock list, we will have more accurate control over memory
> usage.

If you don't have further objection, I will take memblock approach
(with factoring out powerpc's arch_kexec_walk_mem()).

Thanks,
-Takahiro AKASHI


> > 
> > > diff --git a/arch/arm64/kernel/machine_kexec_file.c 
> > > b/arch/arm64/kernel/machine_kexec_file.c
> > > new file mode 100644
> > > index ..f9ebf54ca247
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > @@ -0,0 +1,57 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * kexec_file for arm64
> > > + *
> > > + * Copyright (C) 2018 Linaro Limited
> > > + * Author: AKASHI Takahiro 
> > > + *
> > 
> > > + * Most code is derived from arm64 port of kexec-tools
> > 
> > How does kexec-tools walk memblock?
> 
> Will remove this comment from this patch.
> Obviously, this comment is for the rest of the code which will be
> added to succeeding patches (patch #5 and #7).
> 
> 
> > 
> > > + */
> > > +
> > > +#define pr_fmt(fmt) "kexec_file: " fmt
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > + int (*func)(struct resource *, void *))
> > > +{
> > > + phys_addr_t start, end;
> > > + struct resource res;
> > > + u64 i;
> > > + int ret = 0;
> > > +
> > > + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > > + return func(_res, kbuf);
> > > +
> > > + if (kbuf->top_down)
> > > + for_each_mem_range_rev(i, , ,
> > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > + , , NULL) {
> > 
> > for_each_free_mem_range_reverse() is a more readable version of this helper.
> 
> OK. I used to use my own limited list of reserved memory instead of
> memblock.reserved here to exclude verbose ranges.
> 
> 
> > > + if (!memblock_is_map_memory(start))
> > > + continue;
> > 
> > Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.
> 
> Sure, I confirmed it.
> 
> > 
> > > + res.start = start;
> > > + res.end = end;
> > > + ret = func(, kbuf);
> > > + if (ret)
> > > + break;
> > > + }
> > > + else
> > > + for_each_mem_range(i, , ,
> > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > + , , NULL) {
> > 
> > for_each_free_mem_range()?
> 
> OK.
> 
> > > + if (!memblock_is_map_memory(start))
> > > + continue;
> > > +
> > > + res.start = start;
> > > + res.end = end;
> > > + ret = func(, kbuf);
> > > + if (ret)
> > > + break;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > 
> > 
> > With these changes, what we have is almost:
> > arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> > (the difference being powerpc doesn't yet support crash-kernels here)
> > 
> > If the argument is walking memblock gives a better answer than the stringy
> > walk_system_ram_res() thing, is there any mileage in moving this code into
> > kexec_file.c, and using it if !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)?
> > 
> > This would save arm64/powerpc having near-identical implementations.
> > 32bit arm keeps memblock if it has kexec, so it may be useful there too if
> > kexec_file_load() support is added.
> 
> Thanks. I've forgot ppc.
> 
> -Takahiro AKASHI
> 
> 
> > 
> > Thanks,
> > 
> > James


Re: cpu stopper threads and load balancing leads to deadlock

2018-05-14 Thread Mike Galbraith
On Thu, 2018-05-03 at 18:45 +0200, Peter Zijlstra wrote:
> On Thu, May 03, 2018 at 09:12:31AM -0700, Paul E. McKenney wrote:
> > On Thu, May 03, 2018 at 04:44:50PM +0200, Peter Zijlstra wrote:
> > > On Thu, May 03, 2018 at 04:16:55PM +0200, Mike Galbraith wrote:
> > > > On Thu, 2018-05-03 at 15:56 +0200, Peter Zijlstra wrote:
> > > > > On Thu, May 03, 2018 at 03:32:39PM +0200, Mike Galbraith wrote:
> > > > > 
> > > > > > Dang.  With $subject fix applied as well..
> > > > > 
> > > > > That's a NO then... :-(
> > > > 
> > > > Could say who cares about oddball offline wakeup stat. 
> > > 
> > > Yeah, nobody.. but I don't want to have to change the wakeup code to
> > > deal with this if at all possible. That'd just add conditions that are
> > > 'always' false, except in this exceedingly rare circumstance.
> > > 
> > > So ideally we manage to tell RCU that it needs to pay attention while
> > > we're doing this here thing, which is what I thought RCU_NONIDLE() was
> > > about.
> > 
> > One straightforward approach would be to provide a arch-specific
> > Kconfig option that tells notify_cpu_starting() not to bother invoking
> > rcu_cpu_starting().  Then x86 selects this Kconfig option and invokes
> > rcu_cpu_starting() itself early enough to avoid splats.
> > 
> > See the (untested, probably does not even build) patch below.
> > 
> > I have no idea where to insert either the "select" or the call to
> > rcu_cpu_starting(), so I left those out.  I know that putting the
> > call too early will cause trouble, but I have no idea what constitutes
> > "too early".  :-/
> 
> Something like so perhaps? Mike, can you play around with that? Could
> burn your granny and eat your cookies.

Did this get queued anywhere?

> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index 7468de429087..07360523c3ce 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -793,6 +793,9 @@ void mtrr_ap_init(void)
>  
>   if (!use_intel() || mtrr_aps_delayed_init)
>   return;
> +
> + rcu_cpu_starting(smp_processor_id());
> +
>   /*
>* Ideally we should hold mtrr_mutex here to avoid mtrr entries
>* changed, but this routine will be called in cpu boot time,
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 2a734692a581..4dab46950fdb 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -3775,6 +3775,8 @@ int rcutree_dead_cpu(unsigned int cpu)
>   return 0;
>  }
>  
> +static DEFINE_PER_CPU(int, rcu_cpu_started);
> +
>  /*
>   * Mark the specified CPU as being online so that subsequent grace periods
>   * (both expedited and normal) will wait on it.  Note that this means that
> @@ -3796,6 +3798,11 @@ void rcu_cpu_starting(unsigned int cpu)
>   struct rcu_node *rnp;
>   struct rcu_state *rsp;
>  
> + if (per_cpu(rcu_cpu_started, cpu))
> + return;
> +
> + per_cpu(rcu_cpu_started, cpu) = 1;
> +
>   for_each_rcu_flavor(rsp) {
>   rdp = per_cpu_ptr(rsp->rda, cpu);
>   rnp = rdp->mynode;
> @@ -3852,6 +3859,8 @@ void rcu_report_dead(unsigned int cpu)
>   preempt_enable();
>   for_each_rcu_flavor(rsp)
>   rcu_cleanup_dying_idle_cpu(cpu, rsp);
> +
> + per_cpu(rcu_cpu_started, cpu) = 0;
>  }
>  
>  /* Migrate the dead CPU's callbacks to the current CPU. */


Re: [PATCH] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver

2018-05-14 Thread kbuild test robot
Hi Katsuhiro,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.17-rc5 next-20180514]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Katsuhiro-Suzuki/media-dvb-frontends-add-Socionext-SC1501A-ISDB-S-T-demodulator-driver/20180515-091453
base:   git://linuxtv.org/media_tree.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/media/dvb-frontends/sc1501a.c:313:47: sparse: constant 211243671486 
>> is so big it is long

vim +313 drivers/media/dvb-frontends/sc1501a.c

   258  
   259  static int sc1501a_s_read_status(struct sc1501a_priv *chip,
   260   struct dtv_frontend_properties *c,
   261   enum fe_status *status)
   262  {
   263  struct regmap *r_s = chip->regmap_s;
   264  u32 cpmon, tmpu, tmpl, flg;
   265  u64 tmp;
   266  
   267  /* Sync detection */
   268  regmap_read(r_s, CPMON1_S, );
   269  
   270  *status = 0;
   271  if (cpmon & CPMON1_S_FSYNC)
   272  *status |= FE_HAS_VITERBI | FE_HAS_SYNC | FE_HAS_LOCK;
   273  if (cpmon & CPMON1_S_W2LOCK)
   274  *status |= FE_HAS_SIGNAL | FE_HAS_CARRIER;
   275  
   276  /* Signal strength */
   277  c->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
   278  
   279  if (*status & FE_HAS_SIGNAL) {
   280  u32 agc;
   281  
   282  regmap_read(r_s, AGCREAD_S, );
   283  agc = tmpu << 8;
   284  
   285  c->strength.len = 1;
   286  c->strength.stat[0].scale = FE_SCALE_RELATIVE;
   287  c->strength.stat[0].uvalue = agc;
   288  }
   289  
   290  /* C/N rate */
   291  c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
   292  
   293  if (*status & FE_HAS_VITERBI) {
   294  u32 cnr = 0, x, y, d;
   295  u64 d_3 = 0;
   296  
   297  regmap_read(r_s, CNRDXU_S, );
   298  regmap_read(r_s, CNRDXL_S, );
   299  x = (tmpu << 8) | tmpl;
   300  regmap_read(r_s, CNRDYU_S, );
   301  regmap_read(r_s, CNRDYL_S, );
   302  y = (tmpu << 8) | tmpl;
   303  
   304  /* CNR[dB]: 10 * log10(D) - 30.74 / D^3 - 3 */
   305  /*   D = x^2 / (2^15 * y - x^2) */
   306  d = (y << 15) - x * x;
   307  if (d > 0) {
   308  /* (2^4 * D)^3 = 2^12 * D^3 */
   309  /* 3.074 * 2^(12 + 24) = 211243671486 */
   310  d_3 = div_u64(16 * x * x, d);
   311  d_3 = d_3 * d_3 * d_3;
   312  if (d_3)
 > 313  d_3 = div_u64(211243671486, d_3);
   314  }
   315  
   316  if (d_3) {
   317  /* 0.3 * 2^24 = 5033164 */
   318  tmp = (s64)2 * intlog10(x) - intlog10(abs(d)) - 
d_3
   319  - 5033164;
   320  cnr = div_u64(tmp * 1, 1 << 24);
   321  }
   322  
   323  if (cnr) {
   324  c->cnr.len = 1;
   325  c->cnr.stat[0].scale = FE_SCALE_DECIBEL;
   326  c->cnr.stat[0].uvalue = cnr;
   327  }
   328  }
   329  
   330  /* BER */
   331  c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
   332  c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
   333  
   334  regmap_read(r_s, BERCNFLG_S, );
   335  
   336  if ((*status & FE_HAS_VITERBI) && (flg & BERCNFLG_S_BERVRDY)) {
   337  u32 bit_err, bit_cnt;
   338  
   339  regmap_read(r_s, BERVRDU_S, );
   340  regmap_read(r_s, BERVRDL_S, );
   341  bit_err = (tmpu << 8) | tmpl;
   342  bit_cnt = (1 << 13) * 204;
   343  
   344  if (bit_cnt) {
   345  c->post_bit_error.len = 1;
   346  c->post_bit_error.stat[0].scale = 
FE_SCALE_COUNTER;
   347  c->post_bit_error.stat[0].uvalue = bit_err;
   348  c->post_bit_count.len = 1;
   349  c->post_bit_count.stat[0].scale = 
FE_SCALE_COUNTER;
   350  c->

Re: [PATCH] rcu: Report a quiescent state of TASKS_RCU on a tick from user

2018-05-14 Thread Byungchul Park



On 2018-05-15 13:11, Paul E. McKenney wrote:

On Tue, May 15, 2018 at 09:33:46AM +0900, Byungchul Park wrote:

Hello Paul,

You removed the reporing while simplifying the commit 508880df6 :)
Fold this patch onto the commit or add, whatever you want.


First, thank you for checking!

But second, the removal was intentional.  Tiny RCU only exists in
PREEMPT=n kernels, and in such kernels there can be no RCU-tasks.
This is the reason for this line in the new commit log:


I see. Thank you.


[ paulmck: Simplify rcutiny portion given no RCU-tasks for !PREEMPT. ]

Thanx, Paul


Thanks,
Byungchul

->8-
>From 18a2d8da3baf79d0edd5ccf94abe6f989da5b1c1 Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Tue, 15 May 2018 09:21:43 +0900
Subject: [PATCH] rcu: Report a quiescent state of TASKS_RCU on a tick from
  user

The reporting was removed while simplifying the commit 508880df6 (rcu:
Improve rcu_note_voluntary_context_switch() reporting). Add it back.

Signed-off-by: Byungchul Park 
---
  kernel/rcu/tiny.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
index befc932..3345596 100644
--- a/kernel/rcu/tiny.c
+++ b/kernel/rcu/tiny.c
@@ -120,8 +120,10 @@ void rcu_bh_qs(void)
   */
  void rcu_check_callbacks(int user)
  {
-   if (user)
+   if (user) {
rcu_sched_qs();
+   rcu_tasks_qs();
+   }
if (user || !in_softirq())
rcu_bh_qs();
  }
--
1.9.1






--
Thanks,
Byungchul


Re: [PATCH v6 14/14] dt: qcom: Add qcom-cpufreq-kryo driver configuration

2018-05-14 Thread Viresh Kumar
On 14-05-18, 16:12, Ilia Lin wrote:
> Signed-off-by: Ilia Lin 
> ---
>  arch/arm64/boot/dts/qcom/apq8096-db820c.dts |   2 +-
>  arch/arm64/boot/dts/qcom/msm8996.dtsi   | 310 
> +++-
>  2 files changed, 309 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dts 
> b/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
> index 230e9c8..da23bda 100644
> --- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
> +++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
> @@ -17,5 +17,5 @@
>  
>  / {
>   model = "Qualcomm Technologies, Inc. DB820c";
> - compatible = "arrow,apq8096-db820c", "qcom,apq8096-sbc";
> + compatible = "arrow,apq8096-db820c", "qcom,apq8096-sbc", "qcom,apq8096";
>  };
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index d7adef9..fbf92f6 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -174,218 +174,519 @@
>   };
>  
>   cluster0_opp: opp_table0 {
> - compatible = "operating-points-v2";
> + compatible = "operating-points-v2-kryo-cpu";

I think you need to mention both the above compatible strings here
with the kyro one mentioned first.


-- 
viresh


Re: [PATCH v6 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

2018-05-14 Thread Viresh Kumar
On 14-05-18, 16:11, Ilia Lin wrote:
> In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
> that have KRYO processors, the CPU ferequencies subset and voltage value
> of each OPP varies based on the silicon variant in use.
> Qualcomm Technologies, Inc. Process Voltage Scaling Tables
> defines the voltage and frequency value based on the msm-id in SMEM
> and speedbin blown in the efuse combination.
> The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
> to provide the OPP framework with required information.
> This is used to determine the voltage and frequency value for each OPP of
> operating-points-v2 table when it is parsed by the OPP framework.
> 
> This change adds documentation.
> 
> Signed-off-by: Ilia Lin 
> ---
>  .../devicetree/bindings/opp/kryo-cpufreq.txt   | 680 
> +
>  1 file changed, 680 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH] rcu: Report a quiescent state of TASKS_RCU on a tick from user

2018-05-14 Thread Paul E. McKenney
On Tue, May 15, 2018 at 09:33:46AM +0900, Byungchul Park wrote:
> Hello Paul,
> 
> You removed the reporing while simplifying the commit 508880df6 :)
> Fold this patch onto the commit or add, whatever you want.

First, thank you for checking!

But second, the removal was intentional.  Tiny RCU only exists in
PREEMPT=n kernels, and in such kernels there can be no RCU-tasks.
This is the reason for this line in the new commit log:

[ paulmck: Simplify rcutiny portion given no RCU-tasks for !PREEMPT. ]

Thanx, Paul

> Thanks,
> Byungchul
> 
> ->8-
> >From 18a2d8da3baf79d0edd5ccf94abe6f989da5b1c1 Mon Sep 17 00:00:00 2001
> From: Byungchul Park 
> Date: Tue, 15 May 2018 09:21:43 +0900
> Subject: [PATCH] rcu: Report a quiescent state of TASKS_RCU on a tick from
>  user
> 
> The reporting was removed while simplifying the commit 508880df6 (rcu:
> Improve rcu_note_voluntary_context_switch() reporting). Add it back.
> 
> Signed-off-by: Byungchul Park 
> ---
>  kernel/rcu/tiny.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
> index befc932..3345596 100644
> --- a/kernel/rcu/tiny.c
> +++ b/kernel/rcu/tiny.c
> @@ -120,8 +120,10 @@ void rcu_bh_qs(void)
>   */
>  void rcu_check_callbacks(int user)
>  {
> - if (user)
> + if (user) {
>   rcu_sched_qs();
> + rcu_tasks_qs();
> + }
>   if (user || !in_softirq())
>   rcu_bh_qs();
>  }
> -- 
> 1.9.1
> 



Re: [PATCH v6 12/14] cpufreq: Add Kryo CPU scaling driver

2018-05-14 Thread Viresh Kumar
On 14-05-18, 16:11, Ilia Lin wrote:
> +static int __init qcom_cpufreq_kryo_driver_init(void)
> +{
> + size_t len;
> + int ret;
> + u32 versions;
> + enum _msm8996_version msm8996_version;
> + u8 *speedbin;
> + struct device *cpu_dev;
> + struct device_node *np;
> + struct nvmem_cell *speedbin_nvmem;
> + struct opp_table *opp_temp = NULL;
> +
> + cpu_dev = get_cpu_device(SILVER_LEAD);
> + if (IS_ERR_OR_NULL(cpu_dev))
> + return PTR_ERR(cpu_dev);
> +
> + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> + dev_err(cpu_dev, "Not Snapdragon 820/821!");
> + return -ENODEV;
> +}
> +
> + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> + if (IS_ERR_OR_NULL(np))
> + return PTR_ERR(np);
> +
> + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
> + ret = -ENOENT;
> + goto free_np;
> + }
> +
> + speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> + if (IS_ERR(speedbin_nvmem)) {
> + ret = PTR_ERR(speedbin_nvmem);
> + dev_err(cpu_dev, "Could not get nvmem cell: %d\n", ret);
> + goto free_np;
> + }
> +
> + speedbin = nvmem_cell_read(speedbin_nvmem, );
> +
> + switch (msm8996_version) {
> + case MSM8996_V3:
> + versions = 1 << (unsigned int)(*speedbin);
> + break;
> + case MSM8996_SG:
> + versions = 1 << ((unsigned int)(*speedbin) + 4);
> + break;
> + default:
> + BUG();
> + break;
> + }
> +
> + ret = PTR_ERR_OR_ZERO(opp_temp = \

Why back slash here ?

> +   dev_pm_opp_set_supported_hw(cpu_dev,,1));
> + if (0 > ret)
> + goto free_np;
> +
> + dev_pm_opp_put_supported_hw(opp_temp);
> +
> + cpu_dev = get_cpu_device(GOLD_LEAD);
> + ret = PTR_ERR_OR_ZERO(opp_temp = \

And here.

> +   dev_pm_opp_set_supported_hw(cpu_dev,,1));
> + if (0 > ret)
> + goto free_np;
> +
> + ret = PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-dt", \

and here.

> +   -1, NULL, 0));
> +
> + dev_pm_opp_put_supported_hw(opp_temp);

And this is wrong. You don't need to call this in success case here.
It may have worked for you as cpufreq-dt driver would have already
been initialized, but that's not the case always. For example try
inserting cpufreq-dt module after kernel boots and it will fail.

> +
> +free_np:
> + of_node_put(np);
> +
> + return ret;
> +}
> +late_initcall(qcom_cpufreq_kryo_driver_init);
> +
> +MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
> +MODULE_LICENSE("GPL v2");
> -- 
> 1.9.1

-- 
viresh


Re: [PATCH v5 10/13] mm: Set bit in memcg shrinker bitmap on first list_lru item apearance

2018-05-14 Thread Vladimir Davydov
On Thu, May 10, 2018 at 12:53:45PM +0300, Kirill Tkhai wrote:
> Introduce set_shrinker_bit() function to set shrinker-related
> bit in memcg shrinker bitmap, and set the bit after the first
> item is added and in case of reparenting destroyed memcg's items.
> 
> This will allow next patch to make shrinkers be called only,
> in case of they have charged objects at the moment, and
> to improve shrink_slab() performance.
> 
> Signed-off-by: Kirill Tkhai 
> ---
>  include/linux/memcontrol.h |   15 +++
>  mm/list_lru.c  |   22 --
>  2 files changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index e5e7e0fc7158..82f892e77637 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1274,6 +1274,21 @@ static inline void memcg_put_cache_ids(void)
>  
>  extern int memcg_shrinker_nr_max;
>  extern int memcg_expand_shrinker_maps(int old_id, int id);
> +
> +static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg, int nid, 
> int nr)

Nit: too long line (> 80 characters)
Nit: let's rename 'nr' to 'shrinker_id'

> +{
> + if (nr >= 0 && memcg && memcg != root_mem_cgroup) {
> + struct memcg_shrinker_map *map;
> +
> + rcu_read_lock();
> + map = MEMCG_SHRINKER_MAP(memcg, nid);

Missing rcu_dereference.

> + set_bit(nr, map->map);
> + rcu_read_unlock();
> + }
> +}
> +#else
> +static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
> +   int node, int id) { }

Nit: please keep the signature (including argument names) the same as in
MEMCG-enabled definition, namely 'node' => 'nid', 'id' => 'shrinker_id'.

Thanks.


Re: [PATCH v6 11/14] dt: qcom: Add SAW regulator for 8x96 CPUs

2018-05-14 Thread Viresh Kumar
On 14-05-18, 16:11, Ilia Lin wrote:
> 1. Add syscon node for the SAW CPU registers
> 2. Add SAW regulators gang definition for s8-s11
> 3. Add voltages to the OPP tables
> 4. Add the s11 SAW regulator as CPU regulator
> 
> Signed-off-by: Ilia Lin 
> ---
>  arch/arm64/boot/dts/qcom/msm8996.dtsi | 75 
> +++
>  1 file changed, 75 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH v6 08/14] dt: qcom: Add opp and thermal to the msm8996

2018-05-14 Thread Viresh Kumar
On 14-05-18, 16:11, Ilia Lin wrote:
> Signed-off-by: Ilia Lin 
> ---
>  arch/arm64/boot/dts/qcom/msm8996.dtsi | 269 
> --
>  1 file changed, 260 insertions(+), 9 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh


[PATCH v2] arm64: dts: qcom: sdm845: Sort nodes in the soc by address

2018-05-14 Thread Douglas Anderson
This is pure-churn and should be a no-op.  I'm doing it in the hopes
of reducing merge conflicts.  When things are sorted in a sane way
(and by base address seems sane) then it's less likely that future
patches will cause merge conflicts.

Signed-off-by: Douglas Anderson 
Acked-by: Bjorn Andersson 
---

Changes in v2:
- rebase atop tree today

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 96 ++--
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 7c85e7c596db..96dd4b2a41d6 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -198,6 +198,54 @@
ranges = <0 0 0 0x>;
compatible = "simple-bus";
 
+   gcc: clock-controller@10 {
+   compatible = "qcom,gcc-sdm845";
+   reg = <0x10 0x1f>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   #power-domain-cells = <1>;
+   };
+
+   tcsr_mutex_regs: syscon@1f4 {
+   compatible = "syscon";
+   reg = <0x1f4 0x4>;
+   };
+
+   tlmm: pinctrl@340 {
+   compatible = "qcom,sdm845-pinctrl";
+   reg = <0x0340 0xc0>;
+   interrupts = ;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   spmi_bus: spmi@c44 {
+   compatible = "qcom,spmi-pmic-arb";
+   reg = <0xc44 0x1100>,
+ <0xc60 0x200>,
+ <0xe60 0x10>,
+ <0xe70 0xa>,
+ <0xc40a000 0x26000>;
+   reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
+   interrupt-names = "periph_irq";
+   interrupts = ;
+   qcom,ee = <0>;
+   qcom,channel = <0>;
+   #address-cells = <2>;
+   #size-cells = <0>;
+   interrupt-controller;
+   #interrupt-cells = <4>;
+   cell-index = <0>;
+   };
+
+   apss_shared: mailbox@1799 {
+   compatible = "qcom,sdm845-apss-shared";
+   reg = <0x1799 0x1000>;
+   #mbox-cells = <1>;
+   };
+
intc: interrupt-controller@17a0 {
compatible = "arm,gic-v3";
#address-cells = <1>;
@@ -218,24 +266,6 @@
};
};
 
-   gcc: clock-controller@10 {
-   compatible = "qcom,gcc-sdm845";
-   reg = <0x10 0x1f>;
-   #clock-cells = <1>;
-   #reset-cells = <1>;
-   #power-domain-cells = <1>;
-   };
-
-   tlmm: pinctrl@340 {
-   compatible = "qcom,sdm845-pinctrl";
-   reg = <0x0340 0xc0>;
-   interrupts = ;
-   gpio-controller;
-   #gpio-cells = <2>;
-   interrupt-controller;
-   #interrupt-cells = <2>;
-   };
-
timer@17c9 {
#address-cells = <1>;
#size-cells = <1>;
@@ -293,35 +323,5 @@
status = "disabled";
};
};
-
-   spmi_bus: spmi@c44 {
-   compatible = "qcom,spmi-pmic-arb";
-   reg = <0xc44 0x1100>,
- <0xc60 0x200>,
- <0xe60 0x10>,
- <0xe70 0xa>,
- <0xc40a000 0x26000>;
-   reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
-   interrupt-names = "periph_irq";
-   interrupts = ;
-   qcom,ee = <0>;
-   qcom,channel = <0>;
-   #address-cells = <2>;
-   #size-cells = <0>;
-   interrupt-controller;
-   #interrupt-cells = <4>;
-   cell-index = <0>;
-   };
-
-   tcsr_mutex_regs: syscon@1f4 {
-   compatible = "syscon";
-   reg = <0x1f4 0x4>;
-

Re: [PATCH RFC 1/8] rcu: Add comment documenting how rcu_seq_snap works

2018-05-14 Thread Paul E. McKenney
On Mon, May 14, 2018 at 06:51:33PM -0700, Joel Fernandes wrote:
> On Mon, May 14, 2018 at 10:38:16AM -0700, Paul E. McKenney wrote:
> > On Sun, May 13, 2018 at 08:15:34PM -0700, Joel Fernandes (Google) wrote:
> > > rcu_seq_snap may be tricky for someone looking at it for the first time.
> > > Lets document how it works with an example to make it easier.
> > > 
> > > Signed-off-by: Joel Fernandes (Google) 
> > > ---
> > >  kernel/rcu/rcu.h | 24 +++-
> > >  1 file changed, 23 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> > > index 003671825d62..fc3170914ac7 100644
> > > --- a/kernel/rcu/rcu.h
> > > +++ b/kernel/rcu/rcu.h
> > > @@ -91,7 +91,29 @@ static inline void rcu_seq_end(unsigned long *sp)
> > >   WRITE_ONCE(*sp, rcu_seq_endval(sp));
> > >  }
> > > 
> > > -/* Take a snapshot of the update side's sequence number. */
> > > +/*
> > > + * Take a snapshot of the update side's sequence number.
> > > + *
> > > + * This function predicts what the grace period number will be the next
> > > + * time an RCU callback will be executed, given the current grace 
> > > period's
> > > + * number. This can be gp+1 if RCU is idle, or gp+2 if a grace period is
> > > + * already in progress.
> > 
> > How about something like this?
> > 
> > This function returns the earliest value of the grace-period
> > sequence number that will indicate that a full grace period has
> > elapsed since the current time.  Once the grace-period sequence
> > number has reached this value, it will be safe to invoke all
> > callbacks that have been registered prior to the current time.
> > This value is the current grace-period number plus two to the
> > power of the number of low-order bits reserved for state, then
> > rounded up to the next value in which the state bits are all zero.
> 
> This makes sense too, but do you disagree with what I said?

In a pedantic sense, definitely.  RCU callbacks are being executed pretty
much all the time on a busy system, so it is only the recently queued
ones that are guaranteed to be deferred that long.  And my experience
indicates that someone really will get confused by that distinction,
so I feel justified in being pedantic in this case.

> I was kind of thinking of snap along the lines of how the previous code
> worked. Where you were calling rcu_cbs_completed() or a function with a
> similar name. Now we call _snap.

You are quite correct that rcu_seq_snap() is the new analog of
rcu_cbs_completed(), though there are differences due to the old ->gpnum
and ->completed now being represented by a single ->gp_seq value.

> So basically I connected these 2 facts together to mean that rcu_seq_snap
> also does that same thing as rcu_cbs_completed - which is basically it gives
> the "next GP" where existing callbacks have already run and new callbacks
> will run at the end of this "next GP".

Ah, but you didn't have the qualifier "new" in your original.  And even
then, the definition of "new" might be different for different readers.

> > > + *
> > > + * We do this with a single addition and masking.
> > 
> > Please either fold this sentence into rest of the paragraph or add a
> > blank line after it.
> > 
> > > + * For example, if RCU_SEQ_STATE_MASK=1 and the least significant bit 
> > > (LSB) of
> > > + * the seq is used to track if a GP is in progress or not, its 
> > > sufficient if we
> > > + * add (2+1) and mask with ~1. Let's see why with an example:
> > > + *
> > > + * Say the current seq is 6 which is 0b110 (gp is 3 and state bit is 0).
> > > + * To get the next GP number, we have to at least add 0b10 to this (0x1 
> > > << 1)
> > > + * to account for the state bit. However, if the current seq is 7 (gp is 
> > > 3 and
> > > + * state bit is 1), then it means the current grace period is already in
> > > + * progress so the next time the callback will run is at the end of grace
> > > + * period number gp+2. To account for the extra +1, we just overflow the 
> > > LSB by
> > > + * adding another 0x1 and masking with ~0x1. In case no GP was in 
> > > progress (RCU
> > > + * is idle), then the addition of the extra 0x1 and masking will have no
> > > + * effect. This is calculated as below.
> > > + */
> > 
> > Having the explicit numbers is good, but please use RCU_SEQ_STATE_MASK=3,
> > since that is the current value.  One alternative (or perhaps addition)
> > is to have a short table of numbers showing the mapping from *sp to the
> > return value.  (I started from such a table when writing this function,
> > for whatever that is worth.)
> 
> Ok I'll try to give a better example above. thanks,

Sounds good!

> Also just to let you know, thanks so much for elaborately providing an
> example on the other thread where we are discussing the rcu_seq_done check. I
> will take some time to trace this down and see if I can zero in on the same
> understanding as yours.
> 
> I get why we use 

Re: [PATCH v5 03/13] mm: Assign memcg-aware shrinkers bitmap to memcg

2018-05-14 Thread Vladimir Davydov
On Mon, May 14, 2018 at 12:34:45PM +0300, Kirill Tkhai wrote:
> >> +static void memcg_free_shrinker_maps(struct mem_cgroup *memcg)
> >> +{
> >> +  struct mem_cgroup_per_node *pn;
> >> +  struct memcg_shrinker_map *map;
> >> +  int nid;
> >> +
> >> +  if (memcg == root_mem_cgroup)
> >> +  return;
> >> +
> >> +  mutex_lock(_nr_max_mutex);
> > 
> > Why do you need to take the mutex here? You don't access shrinker map
> > capacity here AFAICS.
> 
> Allocation of shrinkers map is in css_online() now, and this wants its pay.
> memcg_expand_one_shrinker_map() must be able to differ mem cgroups with
> allocated maps, mem cgroups with not allocated maps, and mem cgroups with
> failed/failing css_online. So, the mutex is used for synchronization with
> expanding. See "old_size && !old" check in memcg_expand_one_shrinker_map().

Another reason to have 'expand' and 'alloc' paths separated - you
wouldn't need to take the mutex here as 'free' wouldn't be used for
undoing initial allocation, instead 'alloc' would cleanup by itself
while still holding the mutex.

> 
> >> +  for_each_node(nid) {
> >> +  pn = mem_cgroup_nodeinfo(memcg, nid);
> >> +  map = rcu_dereference_protected(pn->shrinker_map, true);
> >> +  if (map)
> >> +  call_rcu(>rcu, memcg_free_shrinker_map_rcu);
> >> +  rcu_assign_pointer(pn->shrinker_map, NULL);
> >> +  }
> >> +  mutex_unlock(_nr_max_mutex);
> >> +}
> >> +
> >> +static int memcg_alloc_shrinker_maps(struct mem_cgroup *memcg)
> >> +{
> >> +  int ret, size = memcg_shrinker_nr_max/BITS_PER_BYTE;
> >> +
> >> +  if (memcg == root_mem_cgroup)
> >> +  return 0;
> >> +
> >> +  mutex_lock(_nr_max_mutex);
> >> +  ret = memcg_expand_one_shrinker_map(memcg, size, 0);
> > 
> > I don't think it's worth reusing the function designed for reallocating
> > shrinker maps for initial allocation. Please just fold the code here -
> > it will make both 'alloc' and 'expand' easier to follow IMHO.
> 
> These function will have 80% code the same. What are the reasons to duplicate
> the same functionality? Two functions are more difficult for support, and
> everywhere in kernel we try to avoid this IMHO.

IMHO two functions with clear semantics are easier to maintain than
a function that does one of two things depending on some condition.
Separating 'alloc' from 'expand' would only add 10-15 SLOC.

> >> +  mutex_unlock(_nr_max_mutex);
> >> +
> >> +  if (ret)
> >> +  memcg_free_shrinker_maps(memcg);
> >> +
> >> +  return ret;
> >> +}
> >> +
> >> +static struct idr mem_cgroup_idr;
> >> +
> >> +int memcg_expand_shrinker_maps(int old_nr, int nr)
> >> +{
> >> +  int size, old_size, ret = 0;
> >> +  struct mem_cgroup *memcg;
> >> +
> >> +  old_size = old_nr / BITS_PER_BYTE;
> >> +  size = nr / BITS_PER_BYTE;
> >> +
> >> +  mutex_lock(_nr_max_mutex);
> >> +
> >> +  if (!root_mem_cgroup)
> >> +  goto unlock;
> > 
> > This wants a comment.
> 
> Which comment does this want? "root_mem_cgroup is not initialized, so
> it does not have child mem cgroups"?

Looking at this code again, I find it pretty self-explaining, sorry.

Thanks.


Re: [PATCH v2 1/5] staging: lustre: llite: add support set_acl method in inode operations

2018-05-14 Thread NeilBrown
On Mon, May 14 2018, James Simmons wrote:

> From: Dmitry Eremin 
>
> Linux kernel v3.14 adds set_acl method to inode operations.
> This patch adds support to Lustre for proper acl management.
>
> Signed-off-by: Dmitry Eremin 
> Signed-off-by: John L. Hammond 
> Signed-off-by: James Simmons 
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-9183
> Reviewed-on: https://review.whamcloud.com/25965
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-10541
> Reviewed-on: https://review.whamcloud.com/31588
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-10926
> Reviewed-on: https://review.whamcloud.com/32045
> Reviewed-by: Bob Glossman 
> Reviewed-by: James Simmons 
> Reviewed-by: Andreas Dilger 
> Reviewed-by: Dmitry Eremin 
> Reviewed-by: Oleg Drokin 
> Signed-off-by: James Simmons 
> ---
> Changelog:
>
> v1) Initial patch ported to staging tree
> v2) Fixed up goto handling and avoid BUG() when calling
> forget_cached_acl()with invalid type as pointed out by Dan Carpenter
>
>  drivers/staging/lustre/lustre/llite/file.c | 62 
> ++
>  .../staging/lustre/lustre/llite/llite_internal.h   |  4 ++
>  drivers/staging/lustre/lustre/llite/namei.c| 10 +++-
>  3 files changed, 74 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/llite/file.c 
> b/drivers/staging/lustre/lustre/llite/file.c
> index 0026fde..64a5698 100644
> --- a/drivers/staging/lustre/lustre/llite/file.c
> +++ b/drivers/staging/lustre/lustre/llite/file.c
> @@ -3030,6 +3030,7 @@ static int ll_fiemap(struct inode *inode, struct 
> fiemap_extent_info *fieinfo,
>   return rc;
>  }
>  
> +#ifdef CONFIG_FS_POSIX_ACL

Using #ifdef in  .c files is generally discouraged.
The "standard" approach here is:
- put the acl code in a separate file (acl.c)
- optionally include it via the Make file
 lustre-$(CONFIG_FS_POSIX_ACL) += acl.o

- in the header where ll_get_acl and ll_set_acl are declared have
 #ifdef CONFIG_FS_POSIX_ACL
   declare the functions
 #else
 #define ll_get_acl NULL
 #define ll_set_acl NULL
 #endif

Now as this is staging and that is (presumably) an upstream patch
lightly improved it is probably fine to include the patch as-is,
but in that case we will probably want to fix it up later.

Thanks,
NeilBrown

>  struct posix_acl *ll_get_acl(struct inode *inode, int type)
>  {
>   struct ll_inode_info *lli = ll_i2info(inode);
> @@ -3043,6 +3044,64 @@ struct posix_acl *ll_get_acl(struct inode *inode, int 
> type)
>   return acl;
>  }
>  
> +int ll_set_acl(struct inode *inode, struct posix_acl *acl, int type)
> +{
> + struct ll_sb_info *sbi = ll_i2sbi(inode);
> + struct ptlrpc_request *req = NULL;
> + const char *name = NULL;
> + size_t value_size = 0;
> + char *value = NULL;
> + int rc;
> +
> + switch (type) {
> + case ACL_TYPE_ACCESS:
> + name = XATTR_NAME_POSIX_ACL_ACCESS;
> + if (acl)
> + rc = posix_acl_update_mode(inode, >i_mode, );
> + break;
> +
> + case ACL_TYPE_DEFAULT:
> + name = XATTR_NAME_POSIX_ACL_DEFAULT;
> + if (!S_ISDIR(inode->i_mode))
> + rc = acl ? -EACCES : 0;
> + break;
> +
> + default:
> + rc = -EINVAL;
> + break;
> + }
> + if (rc)
> + return rc;
> +
> + if (acl) {
> + value_size = posix_acl_xattr_size(acl->a_count);
> + value = kmalloc(value_size, GFP_NOFS);
> + if (!value) {
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + rc = posix_acl_to_xattr(_user_ns, acl, value, value_size);
> + if (rc < 0)
> + goto out_value;
> + }
> +
> + rc = md_setxattr(sbi->ll_md_exp, ll_inode2fid(inode),
> +  value ? OBD_MD_FLXATTR : OBD_MD_FLXATTRRM,
> +  name, value, value_size, 0, 0, 0, );
> +
> + ptlrpc_req_finished(req);
> +out_value:
> + kfree(value);
> +out:
> + if (rc)
> + forget_cached_acl(inode, type);
> + else
> + set_cached_acl(inode, type, acl);
> + return rc;
> +}
> +#endif /* CONFIG_FS_POSIX_ACL */
> +
>  int ll_inode_permission(struct inode *inode, int mask)
>  {
>   struct ll_sb_info *sbi;
> @@ -3164,7 +3223,10 @@ int ll_inode_permission(struct inode *inode, int mask)
>   .permission = ll_inode_permission,
>   .listxattr  = ll_listxattr,
>   .fiemap = ll_fiemap,
> +#ifdef CONFIG_FS_POSIX_ACL
>   .get_acl= ll_get_acl,
> + .set_acl= ll_set_acl,
> +#endif
>  };
>  
>  /* dynamic ioctl number support routines */
> diff --git 

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

2018-05-14 Thread Gustavo A. R. Silva

Hi Mauro,

On 04/26/2018 06:42 PM, Mauro Carvalho Chehab wrote:



I noticed you changed the status of this series from rejected to new.


Yes.


Also, there are other similar issues in media/pci/


Well, the issues will be there everywhere on all media drivers.

I marked your patches because I need to study it carefully, after
Peter's explanations. My plan is to do it next week. Still not
sure if the approach you took is the best one or not.

As I said, one possibility is to change the way v4l2-core handles
VIDIOC_ENUM_foo ioctls, but that would be make harder to -stable
backports.

I need a weekend to sleep on it.



I'm curious about how you finally resolved to handle these issues.

I noticed Smatch is no longer reporting them.

Thanks
--
Gustavo


Re: [PATCH RFC 7/8] rcu: trace CleanupMore condition only if needed

2018-05-14 Thread Paul E. McKenney
On Mon, May 14, 2018 at 06:01:31PM -0700, Joel Fernandes wrote:
> On Mon, May 14, 2018 at 12:20:28PM -0700, Paul E. McKenney wrote:
> > On Sun, May 13, 2018 at 08:15:40PM -0700, Joel Fernandes (Google) wrote:
> > > Currently the tree RCU clean up code records a CleanupMore trace event
> > > even if the GP was already in progress. This makes CleanupMore show up
> > > twice for no reason. Avoid it.
> > > 
> > > Signed-off-by: Joel Fernandes (Google) 
> > 
> > Good catch, and I applied this patch.  I did rework the commit log
> > a bit, so please look it over to make sure I didn't mess it up.
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > commit 52c4e689efd975f5383895b1bc1b91bc90fdd372
> > Author: Joel Fernandes (Google) 
> > Date:   Sun May 13 20:15:40 2018 -0700
> > 
> > rcu: Produce last "CleanupMore" trace only if late-breaking request
> > 
> > Currently the tree RCU clean-up code records a "CleanupMore" trace
> > event in response to late-arriving grace-period requests even if the
> > grace period was already requested. This makes "CleanupMore" show up an
> > extra time (in addition to once for each rcu_node structure that was
> > previously marked with the request) for no good reason.  This commit
> > therefore avoids emitting this trace message unless the only if the only
> > request for this next grace period arrived during or after the cleanup
> > scan of the rcu_node structures.
> 
> Yes, this is fine except "unless the only if the only" should be "unless the".

I did update this after sending, and I still have "the the".  Will fix on
next rebase.  As my daughter recently reminded me, the Law of Conservation
of Bugs.  ;-)

Thanx, Paul

> thanks,
> 
> - Joel
> 
> > 
> > Signed-off-by: Joel Fernandes (Google) 
> > Signed-off-by: Paul E. McKenney 
> > 
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 8063a0478870..de6447dd73de 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -2072,7 +2072,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
> > rsp->gp_state = RCU_GP_IDLE;
> > /* Check for GP requests since above loop. */
> > rdp = this_cpu_ptr(rsp->rda);
> > -   if (ULONG_CMP_LT(rnp->gp_seq, rnp->gp_seq_needed)) {
> > +   if (!needgp && ULONG_CMP_LT(rnp->gp_seq, rnp->gp_seq_needed)) {
> > trace_rcu_this_gp(rnp, rdp, rnp->gp_seq_needed,
> >   TPS("CleanupMore"));
> > needgp = true;
> > 
> 



Re: [PATCH RFC 6/8] rcu: Add back the Startedleaf tracepoint

2018-05-14 Thread Paul E. McKenney
On Mon, May 14, 2018 at 05:57:09PM -0700, Joel Fernandes wrote:
> On Mon, May 14, 2018 at 11:38:23AM -0700, Paul E. McKenney wrote:
> > On Sun, May 13, 2018 at 08:15:39PM -0700, Joel Fernandes (Google) wrote:
> > > In recent discussion [1], the check for whether a leaf believes RCU is
> > > not idle, is being added back to funnel locking code, to avoid more
> > > locking. In this we are marking the leaf node for a future grace-period
> > > and bailing out since a GP is currently in progress. However the
> > > tracepoint is missing. Lets add it back.
> > > 
> > > Also add a small comment about why we do this check (basically the point
> > > is to avoid locking intermediate nodes unnecessarily) and clarify the
> > > comments in the trace event header now that we are doing traversal of
> > > one or more intermediate nodes.
> > > 
> > > [1] http://lkml.kernel.org/r/20180513190906.gl26...@linux.vnet.ibm.com
> > > 
> > > Signed-off-by: Joel Fernandes (Google) 
> > 
> > Looks like a good idea, but it does not apply -- which is not a surprise,
> > given the change rate in this code.  I hand-applied as a modification
> > to c1b3f9fce26f ("rcu: Don't funnel-lock above leaf node if GP in progress")
> > with attribution, but with the changes below.  Please let me know if I
> > am missing something.
> > 
> > Ah, I see -- this commit depends on your earlier name-change commit.
> > I therefore made this patch use the old names.
> 
> Ok, I'll check your new tree and rebase.

Sounds good!

> > > ---
> > >  include/trace/events/rcu.h |  4 ++--
> > >  kernel/rcu/tree.c  | 11 ++-
> > >  2 files changed, 12 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
> > > index 539900a9f8c7..dc0bd11739c7 100644
> > > --- a/include/trace/events/rcu.h
> > > +++ b/include/trace/events/rcu.h
> > > @@ -91,8 +91,8 @@ TRACE_EVENT(rcu_grace_period,
> > >   *
> > >   * "Startleaf": Request a grace period based on leaf-node data.
> > >   * "Prestarted": Someone beat us to the request
> > > - * "Startedleaf": Leaf-node start proved sufficient.
> > > - * "Startedleafroot": Leaf-node start proved sufficient after checking 
> > > root.
> > > + * "Startedleaf": Leaf and one or more non-root nodes marked for future 
> > > start.
> > 
> > Actually, we only get to that trace if all we did was mark the leaf
> > node, right?
> 
> I didn't think so. In the code we are doing the check for rnp every time we
> walk up the tree. So even when we are on an intermediate node, we do the
> check of the node we started with. I thought that's what you wanted to do. It
> makes sense to me to do so too.

If we are not on the initial (usually leaf) node, then the similar check
in the previous "if" statement would have sent us to unlock_out, right?

(And yes, I should have said "mark the initial node" above.)

Thanx, Paul

> > > + * "Startedleafroot": all non-root nodes from leaf to root marked for 
> > > future start.
> > 
> > I got rid of the "non-root" part, given that we had to have marked
> > the root to break out of the loop.
> 
> Ah yes, sorry. That's absolutely true.
> 
> thanks,
> 
> - Joel
> 



Re: [PATCH RFC 2/8] rcu: Clarify usage of cond_resched for tasks-RCU

2018-05-14 Thread Paul E. McKenney
On Mon, May 14, 2018 at 05:35:55PM -0700, Joel Fernandes wrote:
> On Mon, May 14, 2018 at 10:22:05AM -0700, Paul E. McKenney wrote:
> > On Mon, May 14, 2018 at 10:54:54AM -0400, Steven Rostedt wrote:
> > > On Sun, 13 May 2018 20:15:35 -0700
> > > "Joel Fernandes (Google)"  wrote:
> > > 
> > > > Recently we had a discussion about cond_resched unconditionally
> > > > recording a voluntary context switch [1].
> > > > 
> > > > Lets add a comment clarifying that how this API is to be used.
> > > > 
> > > > [1] 
> > > > https://lkml.kernel.org/r/1526027434-21237-1-git-send-email-byungchul.p...@lge.com
> > > > 
> > > > Signed-off-by: Joel Fernandes (Google) 
> > > > ---
> > > >  include/linux/rcupdate.h | 11 ---
> > > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > > index 743226176350..a9881007ece6 100644
> > > > --- a/include/linux/rcupdate.h
> > > > +++ b/include/linux/rcupdate.h
> > > > @@ -159,8 +159,12 @@ static inline void rcu_init_nohz(void) { }
> > > > } while (0)
> > > >  
> > > >  /*
> > > > - * Note a voluntary context switch for RCU-tasks benefit.  This is a
> > > > - * macro rather than an inline function to avoid #include hell.
> > > > + * Note an attempt to perform a voluntary context switch for RCU-tasks 
> > > > benefit.
> > > > + *
> > > > + * This is called even in situations where a context switch didn't 
> > > > really
> > > > + * happen even though it was requested. The caller uses it to indicate
> > > > + * traversal of an RCU-tasks quiescent state. This is a macro rather 
> > > > than an
> > > > + * inline function to avoid #include hell.
> > > 
> > > I don't know. I just don't like the wording. It sounds too much like
> > > it was written by someone that was confused for it being called when a
> > > context switch didn't occur ;-)
> 
> True :)
> 
> > > 
> > > What about something more like:
> > > 
> > > /*
> > >  * This is called to denote a RCU-task quiescent state. It is placed at
> > >  * voluntary preemption points, as RCU-task critical sections may not
> > >  * perform voluntary preemption or scheduling calls. It does not matter
> > >  * if the task is scheduled out or not, just that a voluntary preemption
> > >  * may be done.
> > >  */
> > 
> > s/RCU-task/RCU-tasks/ and I am good with this.
> 
> Ok. I like Steve's comment better too.
> 
> Btw, I see you just posted a change of the macro name from
> rcu_note_voluntary_context_switch_lite to rcu_tasks_qs which actually in
> itself is much more descriptive. Considering this, I feel the new name is
> quite self-documenting in itself. So I am more inclined to drop this patch in
> any series reposting, but let me know if you feel otherwise.

I agree, but let's see what other people think.

Thanx, Paul



Re: [PATCH v2] staging: lustre: obdclass: change object lookup to no wait mode

2018-05-14 Thread NeilBrown
On Mon, May 14 2018, James Simmons wrote:

> From: Lai Siyao 
>
> Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want
> to remove object from cache, but this may lead to deadlock, because
> when other process lookup such object, it needs to wait for this
> object until release (done at last refcount put), while that process
> maybe already hold an LDLM lock.
>
> Now that current code can handle dying object correctly, we can just
> return such object in lookup, thus the above deadlock can be avoided.
>
> Signed-off-by: Lai Siyao 
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-9049
> Reviewed-on: https://review.whamcloud.com/26965
> Reviewed-by: Alex Zhuravlev 
> Tested-by: Cliff White 
> Reviewed-by: Fan Yong 
> Reviewed-by: Oleg Drokin 
> Signed-off-by: James Simmons 

Reviewed-by: NeilBrown 

Thanks :-)

NeilBrown

> ---
> Changelog:
>
> v1) Initial patch that didn't apply to staging-testing branch
> v2) Rebased after Neil's patches landed. Remove unlikely() test
> as requested by Dan Carpenter
>
>  drivers/staging/lustre/lustre/obdclass/lu_object.c | 39 
> +-
>  1 file changed, 9 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c 
> b/drivers/staging/lustre/lustre/obdclass/lu_object.c
> index f14e350..e0abd4f 100644
> --- a/drivers/staging/lustre/lustre/obdclass/lu_object.c
> +++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c
> @@ -593,15 +593,10 @@ static struct lu_object *htable_lookup(struct lu_site 
> *s,
>  const struct lu_fid *f,
>  __u64 *version)
>  {
> - struct cfs_hash *hs = s->ls_obj_hash;
>   struct lu_site_bkt_data *bkt;
>   struct lu_object_header *h;
>   struct hlist_node   *hnode;
> - __u64 ver;
> - wait_queue_entry_t waiter;
> -
> -retry:
> - ver = cfs_hash_bd_version_get(bd);
> + u64 ver = cfs_hash_bd_version_get(bd);
>  
>   if (*version == ver)
>   return ERR_PTR(-ENOENT);
> @@ -618,31 +613,13 @@ static struct lu_object *htable_lookup(struct lu_site 
> *s,
>   }
>  
>   h = container_of(hnode, struct lu_object_header, loh_hash);
> - if (likely(!lu_object_is_dying(h))) {
> - cfs_hash_get(s->ls_obj_hash, hnode);
> - lprocfs_counter_incr(s->ls_stats, LU_SS_CACHE_HIT);
> - if (!list_empty(>loh_lru)) {
> - list_del_init(>loh_lru);
> - percpu_counter_dec(>ls_lru_len_counter);
> - }
> - return lu_object_top(h);
> + cfs_hash_get(s->ls_obj_hash, hnode);
> + lprocfs_counter_incr(s->ls_stats, LU_SS_CACHE_HIT);
> + if (!list_empty(>loh_lru)) {
> + list_del_init(>loh_lru);
> + percpu_counter_dec(>ls_lru_len_counter);
>   }
> -
> - /*
> -  * Lookup found an object being destroyed this object cannot be
> -  * returned (to assure that references to dying objects are eventually
> -  * drained), and moreover, lookup has to wait until object is freed.
> -  */
> -
> - init_waitqueue_entry(, current);
> - add_wait_queue(>lsb_marche_funebre, );
> - set_current_state(TASK_UNINTERRUPTIBLE);
> - lprocfs_counter_incr(s->ls_stats, LU_SS_CACHE_DEATH_RACE);
> - cfs_hash_bd_unlock(hs, bd, 1);
> - schedule();
> - remove_wait_queue(>lsb_marche_funebre, );
> - cfs_hash_bd_lock(hs, bd, 1);
> - goto retry;
> + return lu_object_top(h);
>  }
>  
>  /**
> @@ -683,6 +660,8 @@ static void lu_object_limit(const struct lu_env *env, 
> struct lu_device *dev)
>  }
>  
>  /**
> + * Core logic of lu_object_find*() functions.
> + *
>   * Much like lu_object_find(), but top level device of object is specifically
>   * \a dev rather than top level device of the site. This interface allows
>   * objects of different "stacking" to be created within the same site.
> -- 
> 1.8.3.1


signature.asc
Description: PGP signature


Re: [PATCH 18/18] rcu: Use pr_fmt to prefix "rcu: " to logging output

2018-05-14 Thread Paul E. McKenney
On Mon, May 14, 2018 at 06:22:02PM -0700, Joe Perches wrote:
> On Mon, 2018-05-14 at 17:32 -0700, Paul E. McKenney wrote:
> > So this change does not affect WARN_ON_ONCE() and friends?
> 
> Changing define pr_fmt does not modify WARN_ON output.

Very good, I removed my --squash patch adding pr_fmt() to the file
kernel/rcu/rcu_segcblist.c.

Thanx, Paul



Re: [PATCH] lib/rhashtable: reorder some inititalization sequences

2018-05-14 Thread Herbert Xu
On Mon, May 14, 2018 at 10:52:13PM -0400, David Miller wrote:
> From: Davidlohr Bueso 
> Date: Mon, 14 May 2018 08:13:32 -0700
> 
> > rhashtable_init() allocates memory at the very end of the
> > call, once everything is setup; with the exception of the
> > nelems parameter. However, unless the user is doing something
> > bogus with params for which -EINVAL is returned, memory
> > allocation is the only operation that can trigger the call
> > to fail.
> > 
> > Thus move bucket_table_alloc() up such that we fail back to
> > the caller asap, instead of doing useless checks. This is
> > safe as the the table allocation isn't using the halfly
> > setup 'ht' structure and bucket_table_alloc() call chain only
> > ends up using the ht->nulls_base member in INIT_RHT_NULLS_HEAD.
> > 
> > Also move the locking initialization down to the end.
> > 
> > Signed-off-by: Davidlohr Bueso 
> 
> The user potentially "doing something bogus" is why the most
> expensive part of the initialization (the memory allocation)
> is done after everything else is validated.
> 
> I think it's best to keep things as-is.

I agree.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH v5 01/13] mm: Assign id to every memcg-aware shrinker

2018-05-14 Thread Vladimir Davydov
On Mon, May 14, 2018 at 12:03:38PM +0300, Kirill Tkhai wrote:
> On 13.05.2018 08:15, Vladimir Davydov wrote:
> > On Thu, May 10, 2018 at 12:52:18PM +0300, Kirill Tkhai wrote:
> >> The patch introduces shrinker::id number, which is used to enumerate
> >> memcg-aware shrinkers. The number start from 0, and the code tries
> >> to maintain it as small as possible.
> >>
> >> This will be used as to represent a memcg-aware shrinkers in memcg
> >> shrinkers map.
> >>
> >> Since all memcg-aware shrinkers are based on list_lru, which is per-memcg
> >> in case of !SLOB only, the new functionality will be under MEMCG && !SLOB
> >> ifdef (symlinked to CONFIG_MEMCG_SHRINKER).
> > 
> > Using MEMCG && !SLOB instead of introducing a new config option was done
> > deliberately, see:
> > 
> >   http://lkml.kernel.org/r/20151210202244.ga4...@cmpxchg.org
> > 
> > I guess, this doesn't work well any more, as there are more and more
> > parts depending on kmem accounting, like shrinkers. If you really want
> > to introduce a new option, I think you should call it CONFIG_MEMCG_KMEM
> > and use it consistently throughout the code instead of MEMCG && !SLOB.
> > And this should be done in a separate patch.
> 
> What do you mean under "consistently throughout the code"? Should I replace
> all MEMCG && !SLOB with CONFIG_MEMCG_KMEM over existing code?

Yes, otherwise it looks messy - in some places we check !SLOB, in others
we use CONFIG_MEMCG_SHRINKER (or whatever it will be called).

> 
> >> diff --git a/fs/super.c b/fs/super.c
> >> index 122c402049a2..16c153d2f4f1 100644
> >> --- a/fs/super.c
> >> +++ b/fs/super.c
> >> @@ -248,6 +248,9 @@ static struct super_block *alloc_super(struct 
> >> file_system_type *type, int flags,
> >>s->s_time_gran = 10;
> >>s->cleancache_poolid = CLEANCACHE_NO_POOL;
> >>  
> >> +#ifdef CONFIG_MEMCG_SHRINKER
> >> +  s->s_shrink.id = -1;
> >> +#endif
> > 
> > No point doing that - you are going to overwrite the id anyway in
> > prealloc_shrinker().
> 
> Not so, this is done deliberately. alloc_super() has the only "fail" label,
> and it handles all the allocation errors there. The patch just behaves in
> the same style. It sets "-1" to make destroy_unused_super() able to differ
> the cases, when shrinker is really initialized, and when it's not.
> If you don't like this, I can move "s->s_shrink.id = -1;" into
> prealloc_memcg_shrinker() instead of this.

Yes, please do so that we don't have MEMCG ifdefs in fs code.

Thanks.


Re: [PATCH ghak81 RFC V2 3/5] audit: use inline function to get audit context

2018-05-14 Thread Richard Guy Briggs
On 2018-05-14 23:05, Richard Guy Briggs wrote:
> On 2018-05-14 17:44, Paul Moore wrote:
> > On Sat, May 12, 2018 at 9:58 PM, Richard Guy Briggs  wrote:
> > > Recognizing that the audit context is an internal audit value, use an
> > > access function to retrieve the audit context pointer for the task
> > > rather than reaching directly into the task struct to get it.
> > >
> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > >  include/linux/audit.h| 14 ++--
> > >  include/net/xfrm.h   |  2 +-
> > >  kernel/audit.c   |  6 ++--
> > >  kernel/audit_watch.c |  2 +-
> > >  kernel/auditsc.c | 64 
> > > +---
> > >  net/bridge/netfilter/ebtables.c  |  2 +-
> > >  net/core/dev.c   |  2 +-
> > >  net/netfilter/x_tables.c |  2 +-
> > >  net/netlabel/netlabel_user.c |  2 +-
> > >  security/integrity/ima/ima_api.c |  2 +-
> > >  security/integrity/integrity_audit.c |  2 +-
> > >  security/lsm_audit.c |  2 +-
> > >  security/selinux/hooks.c |  4 +--
> > >  security/selinux/selinuxfs.c |  6 ++--
> > >  security/selinux/ss/services.c   | 12 +++
> > >  15 files changed, 64 insertions(+), 60 deletions(-)
> > 
> > Merged, but there was some fuzz due to the missing 1/5 patch and a
> > handfull of checkpatch.pl fixes.  Please take a look at the commit in
> > the audit/next branch and if anything looks awry please send a patch
> > to fix it.
> 
> Some of that fuzz was due to the two patches (ghak46/47) that went
> through the xelinux tree...  There will be a merge conflict.
> 
> Otherwise, looks ok.

Spoke too soon, missed one from the new seccomp actions_logged...

Patch pending...

> > paul moore
> 
> - RGB

- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635


Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware

2018-05-14 Thread Luis R. Rodriguez
On Mon, May 14, 2018 at 10:02:31PM -0400, Mimi Zohar wrote:
> On Mon, 2018-05-14 at 19:28 +, Luis R. Rodriguez wrote:
> > > - CONFIG_IMA_APPRAISE is not fine enough grained.
> > > 
> > > The CONFIG_IMA_APPRAISE_FIRMWARE will be a Kconfig option.  Similar
> > > Kconfig options will require kernel modules, kexec'ed image, and the
> > > IMA policy to be signed.
> > 
> > Sure, it is still unclear to me if CONFIG_IMA_APPRAISE_FIRMWARE will be
> > doing firmware verification in userspace or in the kernel.
> 
> The kernel is verifying signatures.
> 
> > > There are a number of reasons that the kernel should be verifying
> > > firmware signatures (eg. requiring a specific version of the firmware,
> > > that was locally signed).
> > 
> > Oh I agree, Linux enterprise distributions also have a strong reason to
> > have this, so that for instance we only trust and run vendor-approved
> > signed firmware. Otherwise the driver should reject the firmware. Every
> > now and then enterprise distros may run into cases were certain customers
> > may run oddball firmwares, and its unclear if we expect proper functionality
> > with that firmware. Having some form of firmware signing would help with
> > this pipeline, but this is currently dealt with at the packaging, and
> > noting other than logs ensures the driver is using an intended firmware.
> > But these needs *IMHO* have not been enough to push to generalize a kernel
> > firmware signing facility.
> 
> In order for IMA-appraisal to verify firmware signatures, the
> signatures need to be distributed with the firmware.  Perhaps this
> will be enough of an incentive for distros to start including firmware
> signatures in the packages.

Best to poke the maintainers about that... We have been sending mixed messages
about firmware signing over years now. Josh, heads up the new one is we can
do firmware signing through IMA future CONFIG_IMA_APPRAISE_FIRMWARE. I'll
bounce you a few emails related to this.

> > If CONFIG_IMA_APPRAISE_FIRMWARE is going to provide this functionality 
> > somehow
> > I'm happy to hear it.
> 
> The functionality has been there since commit 5a9196d ("ima: add
> support for measuring and appraising firmware").  The
> security_kernel_fw_from_file() hook was later replaced with the
> generic security_kernel_read_file() hook.

Groovy, its unclear from the code on that commit how this is done, so I
suppose I need to study this a bit more. Josh, do you grok it?

  Luis


Re: [PATCH -mm] mm, hugetlb: Pass fault address to no page handler

2018-05-14 Thread Mike Kravetz
On 05/14/2018 05:57 PM, Huang, Ying wrote:
> From: Huang Ying 
> 
> This is to take better advantage of huge page clearing
> optimization (c79b57e462b5d, "mm: hugetlb: clear target sub-page last
> when clearing huge page").  Which will clear to access sub-page last
> to avoid the cache lines of to access sub-page to be evicted when
> clearing other sub-pages.  This needs to get the address of the
> sub-page to access, that is, the fault address inside of the huge
> page.  So the hugetlb no page fault handler is changed to pass that
> information.  This will benefit workloads which don't access the begin
> of the huge page after page fault.
> 
> With this patch, the throughput increases ~28.1% in vm-scalability
> anon-w-seq test case with 88 processes on a 2 socket Xeon E5 2699 v4
> system (44 cores, 88 threads).  The test case creates 88 processes,
> each process mmap a big anonymous memory area and writes to it from
> the end to the begin.  For each process, other processes could be seen
> as other workload which generates heavy cache pressure.  At the same
> time, the cache miss rate reduced from ~36.3% to ~25.6%, the
> IPC (instruction per cycle) increased from 0.3 to 0.37, and the time
> spent in user space is reduced ~19.3%

Since this patch only addresses hugetlbfs huge pages, I would suggest
making that more explicit in the commit message.  Other than that, the
changes look fine to me.

> Signed-off-by: "Huang, Ying" 

Reviewed-by: Mike Kravetz 
-- 
Mike Kravetz

> Cc: Andrea Arcangeli 
> Cc: "Kirill A. Shutemov" 
> Cc: Andi Kleen 
> Cc: Jan Kara 
> Cc: Michal Hocko 
> Cc: Matthew Wilcox 
> Cc: Hugh Dickins 
> Cc: Minchan Kim 
> Cc: Shaohua Li 
> Cc: Christopher Lameter 
> Cc: "Aneesh Kumar K.V" 
> Cc: Punit Agrawal 
> Cc: Anshuman Khandual 
> ---
>  mm/hugetlb.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 129088710510..3de6326abf39 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3677,7 +3677,7 @@ int huge_add_to_page_cache(struct page *page, struct 
> address_space *mapping,
>  
>  static int hugetlb_no_page(struct mm_struct *mm, struct vm_area_struct *vma,
>  struct address_space *mapping, pgoff_t idx,
> -unsigned long address, pte_t *ptep, unsigned int 
> flags)
> +unsigned long faddress, pte_t *ptep, unsigned int 
> flags)
>  {
>   struct hstate *h = hstate_vma(vma);
>   int ret = VM_FAULT_SIGBUS;
> @@ -3686,6 +3686,7 @@ static int hugetlb_no_page(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>   struct page *page;
>   pte_t new_pte;
>   spinlock_t *ptl;
> + unsigned long address = faddress & huge_page_mask(h);
>  
>   /*
>* Currently, we are forced to kill the process in the event the
> @@ -3749,7 +3750,7 @@ static int hugetlb_no_page(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>   ret = VM_FAULT_SIGBUS;
>   goto out;
>   }
> - clear_huge_page(page, address, pages_per_huge_page(h));
> + clear_huge_page(page, faddress, pages_per_huge_page(h));
>   __SetPageUptodate(page);
>   set_page_huge_active(page);
>  
> @@ -3871,7 +3872,7 @@ u32 hugetlb_fault_mutex_hash(struct hstate *h, struct 
> mm_struct *mm,
>  #endif
>  
>  int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> - unsigned long address, unsigned int flags)
> + unsigned long faddress, unsigned int flags)
>  {
>   pte_t *ptep, entry;
>   spinlock_t *ptl;
> @@ -3883,8 +3884,7 @@ int hugetlb_fault(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>   struct hstate *h = hstate_vma(vma);
>   struct address_space *mapping;
>   int need_wait_lock = 0;
> -
> - address &= huge_page_mask(h);
> + unsigned long address = faddress & huge_page_mask(h);
>  
>   ptep = huge_pte_offset(mm, address, huge_page_size(h));
>   if (ptep) {
> @@ -3914,7 +3914,7 @@ int hugetlb_fault(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>  
>   entry = huge_ptep_get(ptep);
>   if (huge_pte_none(entry)) {
> - ret = hugetlb_no_page(mm, vma, mapping, idx, address, ptep, 
> flags);
> + ret = hugetlb_no_page(mm, vma, mapping, idx, faddress, ptep, 
> flags);
>   goto out_mutex;
>   }
>  
> 


Re: linux-next: manual merge of the audit tree with the selinux tree

2018-05-14 Thread Richard Guy Briggs
On 2018-05-15 13:06, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the audit tree got a conflict in:
> 
>   security/selinux/selinuxfs.c
> 
> between commit:
> 
>   4195ed425d3c ("audit: normalize MAC_STATUS record")
> 
> from the selinux tree and commits:
> 
>   cdfb6b341f0f ("audit: use inline function to get audit context")
>   d141136f523a ("audit: normalize MAC_POLICY_LOAD record")
> 
> from the audit tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

This was expected...  It looks ok.

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc security/selinux/selinuxfs.c
> index c0cadbc5f85c,35fd77737c59..
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@@ -167,13 -167,11 +167,13 @@@ static ssize_t sel_write_enforce(struc
> NULL);
>   if (length)
>   goto out;
> - audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_MAC_STATUS,
>  -"enforcing=%d old_enforcing=%d auid=%u ses=%u",
>  +"enforcing=%d old_enforcing=%d auid=%u ses=%u"
>  +" enabled=%d old-enabled=%d lsm=selinux res=1",
>   new_value, old_value,
>   from_kuid(_user_ns, audit_get_loginuid(current)),
>  -audit_get_sessionid(current));
>  +audit_get_sessionid(current),
>  +selinux_enabled, selinux_enabled);
>   enforcing_set(state, new_value);
>   if (new_value)
>   avc_ss_reset(state->avc, 0);
> @@@ -303,12 -299,10 +303,12 @@@ static ssize_t sel_write_disable(struc
>   length = selinux_disable(fsi->state);
>   if (length)
>   goto out;
> - audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_MAC_STATUS,
>  -"selinux=0 auid=%u ses=%u",
>  +"enforcing=%d old_enforcing=%d auid=%u ses=%u"
>  +" enabled=%d old-enabled=%d lsm=selinux res=1",
>  +enforcing, enforcing,
>   from_kuid(_user_ns, audit_get_loginuid(current)),
>  -audit_get_sessionid(current));
>  +audit_get_sessionid(current), 0, 1);
>   }
>   
>   length = count;
> @@@ -581,8 -575,8 +581,8 @@@ static ssize_t sel_write_load(struct fi
>   length = count;
>   
>   out1:
> - audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_POLICY_LOAD,
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_MAC_POLICY_LOAD,
>  -"policy loaded auid=%u ses=%u",
>  +"auid=%u ses=%u lsm=selinux res=1",
>   from_kuid(_user_ns, audit_get_loginuid(current)),
>   audit_get_sessionid(current));
>   out:



- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635


[PATCH v4 3/4] phy: rockchip-typec: support variable phy config value

2018-05-14 Thread Lin Huang
the phy config values used to fix in dp firmware, but some boards
need change these values to do training and get the better eye diagram
result. So support that in phy driver.

Signed-off-by: Chris Zhong 
Signed-off-by: Lin Huang 
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- delete need_software_training variable
- add default phy config value, if dts do not define phy config value, use 
these value
Changes in v4:
- rename variable config to tcphy_default_config

 drivers/phy/rockchip/phy-rockchip-typec.c | 306 --
 include/soc/rockchip/rockchip_phy_typec.h |  63 ++
 2 files changed, 271 insertions(+), 98 deletions(-)
 create mode 100644 include/soc/rockchip/rockchip_phy_typec.h

diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c 
b/drivers/phy/rockchip/phy-rockchip-typec.c
index 76a4b58..5d8692d 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -63,6 +63,7 @@
 
 #include 
 #include 
+#include 
 
 #define CMN_SSM_BANDGAP(0x21 << 2)
 #define CMN_SSM_BIAS   (0x22 << 2)
@@ -323,21 +324,29 @@
  * clock 0: PLL 0 div 1
  * clock 1: PLL 1 div 2
  */
-#define CLK_PLL_CONFIG 0X30
+#define CLK_PLL1_DIV1  0x20
+#define CLK_PLL1_DIV2  0x30
 #define CLK_PLL_MASK   0x33
 
 #define CMN_READY  BIT(0)
 
+#define DP_PLL_CLOCK_ENABLE_ACKBIT(3)
 #define DP_PLL_CLOCK_ENABLEBIT(2)
+#define DP_PLL_ENABLE_ACK  BIT(1)
 #define DP_PLL_ENABLE  BIT(0)
 #define DP_PLL_DATA_RATE_RBR   ((2 << 12) | (4 << 8))
 #define DP_PLL_DATA_RATE_HBR   ((2 << 12) | (4 << 8))
 #define DP_PLL_DATA_RATE_HBR2  ((1 << 12) | (2 << 8))
+#define DP_PLL_DATA_RATE_MASK  0xff00
 
-#define DP_MODE_A0 BIT(4)
-#define DP_MODE_A2 BIT(6)
-#define DP_MODE_ENTER_A0   0xc101
-#define DP_MODE_ENTER_A2   0xc104
+#define DP_MODE_MASK   0xf
+#define DP_MODE_ENTER_A0   BIT(0)
+#define DP_MODE_ENTER_A2   BIT(2)
+#define DP_MODE_ENTER_A3   BIT(3)
+#define DP_MODE_A0_ACK BIT(4)
+#define DP_MODE_A2_ACK BIT(6)
+#define DP_MODE_A3_ACK BIT(7)
+#define DP_LINK_RESET_DEASSERTED   BIT(8)
 
 #define PHY_MODE_SET_TIMEOUT   10
 
@@ -349,51 +358,7 @@
 #define MODE_DFP_USB   BIT(1)
 #define MODE_DFP_DPBIT(2)
 
-struct usb3phy_reg {
-   u32 offset;
-   u32 enable_bit;
-   u32 write_enable;
-};
-
-/**
- * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
- * @reg: the base address for usb3-phy config.
- * @typec_conn_dir: the register of type-c connector direction.
- * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
- * @external_psm: the register of type-c phy external psm clock.
- * @pipe_status: the register of type-c phy pipe status.
- * @usb3_host_disable: the register of type-c usb3 host disable.
- * @usb3_host_port: the register of type-c usb3 host port.
- * @uphy_dp_sel: the register of type-c phy DP select control.
- */
-struct rockchip_usb3phy_port_cfg {
-   unsigned int reg;
-   struct usb3phy_reg typec_conn_dir;
-   struct usb3phy_reg usb3tousb2_en;
-   struct usb3phy_reg external_psm;
-   struct usb3phy_reg pipe_status;
-   struct usb3phy_reg usb3_host_disable;
-   struct usb3phy_reg usb3_host_port;
-   struct usb3phy_reg uphy_dp_sel;
-};
-
-struct rockchip_typec_phy {
-   struct device *dev;
-   void __iomem *base;
-   struct extcon_dev *extcon;
-   struct regmap *grf_regs;
-   struct clk *clk_core;
-   struct clk *clk_ref;
-   struct reset_control *uphy_rst;
-   struct reset_control *pipe_rst;
-   struct reset_control *tcphy_rst;
-   const struct rockchip_usb3phy_port_cfg *port_cfgs;
-   /* mutex to protect access to individual PHYs */
-   struct mutex lock;
-
-   bool flip;
-   u8 mode;
-};
+#define DP_DEFAULT_RATE162000
 
 struct phy_reg {
u16 value;
@@ -417,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
{ 0x8,  CMN_DIAG_PLL0_LF_PROG },
 };
 
-struct phy_reg dp_pll_cfg[] = {
+struct phy_reg dp_pll_rbr_cfg[] = {
{ 0xf0, CMN_PLL1_VCOCAL_INIT },
{ 0x18, CMN_PLL1_VCOCAL_ITER },
{ 0x30b9,   CMN_PLL1_VCOCAL_START },
-   { 0x21c,CMN_PLL1_INTDIV },
+   { 0x87, CMN_PLL1_INTDIV },
{ 0,CMN_PLL1_FRACDIV },
-   { 0x5,  CMN_PLL1_HIGH_THR },
-   { 0x35, CMN_PLL1_SS_CTRL1 },
-   { 0x7f1e,   CMN_PLL1_SS_CTRL2 },
+   { 0x22, CMN_PLL1_HIGH_THR },
+   { 0x8000,   CMN_PLL1_SS_CTRL1 },
+   { 0,   

Re: [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD

2018-05-14 Thread Chris Chiu
On Mon, May 14, 2018 at 10:20 PM, Jarkko Nikula
 wrote:
> On 05/10/2018 03:03 PM, Chris Chiu wrote:
>>
>> Report from guys who can access scope. If i2c-sda-falling-time-ns=400ns
>> , HCNT increase to 117, the SCL high duration is 576ns as follows
>> https://pasteboard.co/HkwERvP.png
>>
>> The original SCL high duration (HCNT = 105, 120MHz) is as follows
>> https://pasteboard.co/HkwFxgY.png
>>
>> So the HCNT does affect but per this HCNT/LCNT value, just not 400kHz
>> as expected. Any suggestion?
>>
> Thanks for measurements. I was sidetracked last week so I don't have yet
> explanation why signals run faster than expected :-(
>
> Using 120 MHz SPT I2C clocks in commit b418bbff36dd ("mfd: intel-lpss: Add
> Intel Cannonlake PCI IDs") is clearly wrong but before going to 133 MHz
> (which work for you but still runs too fast) I would like to find
> explanation why it appears to be much higher.
>
> --
> Jarkko

What if I change the 120MHz to 180MHz and then make sure that the I2C operates
in target FS mode frequency 400kHz via scope? Would there be any side effect?
Maybe some other busses frequency could be also affected and causing some other
component malfunction?

Chris


[PATCH v4 1/4] drm/rockchip: add transfer function for cdn-dp

2018-05-14 Thread Lin Huang
From: Chris Zhong 

We may support training outside firmware, so we need support
dpcd read/write to get the message or do some setting with
display.

Signed-off-by: Chris Zhong 
Signed-off-by: Lin Huang 
Reviewed-by: Sean Paul 
Reviewed-by: Enric Balletbo 
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- None
Changes in v4:
- None

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++
 drivers/gpu/drm/rockchip/cdn-dp-core.h |  1 +
 drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 69 ++
 drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 14 ++-
 4 files changed, 122 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index c6fbdcd..cce64c1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp, 
u8 *sink_count)
u8 value;
 
*sink_count = 0;
-   ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
-   if (ret)
+   ret = drm_dp_dpcd_read(>aux, DP_SINK_COUNT, , 1);
+   if (ret < 0)
return ret;
 
*sink_count = DP_GET_SINK_COUNT(value);
@@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device 
*dp)
if (!cdn_dp_check_sink_connection(dp))
return -ENODEV;
 
-   ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
-  DP_RECEIVER_CAP_SIZE);
-   if (ret) {
+   ret = drm_dp_dpcd_read(>aux, DP_DPCD_REV, dp->dpcd,
+  sizeof(dp->dpcd));
+   if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
return ret;
}
@@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device 
*dp)
if (!port || !dp->link.rate || !dp->link.num_lanes)
return false;
 
-   if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
-DP_LINK_STATUS_SIZE)) {
+   if (drm_dp_dpcd_read_link_status(>aux, link_status) !=
+   DP_LINK_STATUS_SIZE) {
DRM_ERROR("Failed to get link status\n");
return false;
}
@@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
return NOTIFY_DONE;
 }
 
+static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
+  struct drm_dp_aux_msg *msg)
+{
+   struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
+   int ret;
+   u8 status;
+
+   switch (msg->request & ~DP_AUX_I2C_MOT) {
+   case DP_AUX_NATIVE_WRITE:
+   case DP_AUX_I2C_WRITE:
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+   ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
+   msg->size);
+   break;
+   case DP_AUX_NATIVE_READ:
+   case DP_AUX_I2C_READ:
+   ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
+  msg->size);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   status = cdn_dp_get_aux_status(dp);
+   if (status == AUX_STATUS_ACK)
+   msg->reply = DP_AUX_NATIVE_REPLY_ACK;
+   else if (status == AUX_STATUS_NACK)
+   msg->reply = DP_AUX_NATIVE_REPLY_NACK;
+   else if (status == AUX_STATUS_DEFER)
+   msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
+
+   return ret;
+}
+
 static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
 {
struct cdn_dp_device *dp = dev_get_drvdata(dev);
@@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device 
*master, void *data)
dp->active = false;
dp->active_port = -1;
dp->fw_loaded = false;
+   dp->aux.name = "DP-AUX";
+   dp->aux.transfer = cdn_dp_aux_transfer;
+   dp->aux.dev = dev;
+
+   ret = drm_dp_aux_register(>aux);
+   if (ret)
+   return ret;
 
INIT_WORK(>event_work, cdn_dp_pd_event_work);
 
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index f57e296..46159b2 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -78,6 +78,7 @@ struct cdn_dp_device {
struct platform_device *audio_pdev;
struct work_struct event_work;
struct edid *edid;
+   struct drm_dp_aux aux;
 
struct mutex lock;
bool connected;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c 
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index eb3042c..979355d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -221,7 +221,12 @@ static int cdn_dp_reg_write_bit(struct 

[PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware

2018-05-14 Thread Lin Huang
DP firmware uses fixed phy config values to do training, but some
boards need to adjust these values to fit for their unique hardware
design. So get phy config values from dts and use software link training
instead of relying on firmware, if software training fail, keep firmware
training as a fallback if sw training fails.


Signed-off-by: Chris Zhong 
Signed-off-by: Lin Huang 
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- use variable fw_training instead sw_training_success
- base on DP SPCE, if training fail use lower link rate to retry training
Changes in v4:
- improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow 
Sean suggest

 drivers/gpu/drm/rockchip/Makefile   |   3 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
 drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
 6 files changed, 505 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c

diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a314e21..b932f62 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
 rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
+   cdn-dp-link-training.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index cce64c1..d9d0d4d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
*encoder)
goto out;
}
}
-
-   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
-   if (ret) {
-   DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
-   goto out;
+   if (dp->use_fw_training == true) {
+   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
+   if (ret) {
+   DRM_DEV_ERROR(dp->dev,
+ "Failed to idle video %d\n", ret);
+   goto out;
+   }
}
 
ret = cdn_dp_config_video(dp);
@@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
*encoder)
goto out;
}
 
-   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
-   if (ret) {
-   DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
-   goto out;
+   if (dp->use_fw_training == true) {
+   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
+   if (ret) {
+   DRM_DEV_ERROR(dp->dev,
+   "Failed to valid video %d\n", ret);
+   goto out;
+   }
}
+
 out:
mutex_unlock(>lock);
 }
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 46159b2..77a9793 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -84,6 +84,7 @@ struct cdn_dp_device {
bool connected;
bool active;
bool suspended;
+   bool use_fw_training;
 
const struct firmware *fw;  /* cdn dp firmware */
unsigned int fw_version;/* cdn fw version */
@@ -106,6 +107,7 @@ struct cdn_dp_device {
u8 ports;
u8 lanes;
int active_port;
+   u8 train_set[4];
 
u8 dpcd[DP_RECEIVER_CAP_SIZE];
bool sink_has_audio;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c 
b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
new file mode 100644
index 000..7efd070
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+
+static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
+{
+   struct cdn_dp_port *port = dp->port[dp->active_port];
+   struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
+
+   int rate = 

[PATCH v4 2/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY

2018-05-14 Thread Lin Huang
If want to do training outside DP Firmware, need phy voltage swing
and pre_emphasis value.

Signed-off-by: Lin Huang 
---
Changes in v2:
- None 
Changes in v3:
- modify property description and add this property to Example
Change in v4:
- None

 .../devicetree/bindings/phy/phy-rockchip-typec.txt | 29 +-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
index 960da7f..af298f2 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
@@ -17,7 +17,8 @@ Required properties:
 
 Optional properties:
  - extcon : extcon specifier for the Power Delivery
-
+ - rockchip,phy_config : A list of voltage swing(mv) and pre-emphasis
+   (dB) pairs.
 Required nodes : a sub-node is required for each port the phy provides.
 The sub-node name is used to identify dp or usb3 port,
 and shall be the following entries:
@@ -50,6 +51,19 @@ Example:
 < SRST_P_UPHY0_TCPHY>;
reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
 
+   rockchip,phy_config =<0x2a 0x00
+   0x1f 0x15
+   0x14 0x22
+   0x02 0x2b
+   0x21 0x00
+   0x12 0x15
+   0x02 0x22
+   0 0
+   0x15 0x00
+   0x00 0x15
+   0 0
+   0 0>;
+
tcphy0_dp: dp-port {
#phy-cells = <0>;
};
@@ -74,6 +88,19 @@ Example:
 < SRST_P_UPHY1_TCPHY>;
reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
 
+   rockchip,phy_config =<0x2a 0x00
+   0x1f 0x15
+   0x14 0x22
+   0x02 0x2b
+   0x21 0x00
+   0x12 0x15
+   0x02 0x22
+   0 0
+   0x15 0x00
+   0x00 0x15
+   0 0
+   0 0>;
+
tcphy1_dp: dp-port {
#phy-cells = <0>;
};
-- 
2.7.4



Re: [PATCH REPOST 4/5] powerpc: Use update_thread_flag()

2018-05-14 Thread Michael Ellerman
Dave Martin  writes:

> This patch uses the new update_thread_flag() helper to simplify a
> couple of if () set; else clear; constructs.
>
> No functional change.
>
> Signed-off-by: Dave Martin 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> ---
>  arch/powerpc/include/asm/elf.h | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
> index 548d9a4..136c9b1 100644
> --- a/arch/powerpc/include/asm/elf.h
> +++ b/arch/powerpc/include/asm/elf.h
> @@ -88,14 +88,8 @@ typedef elf_vrregset_t elf_fpxregset_t;
>  #ifdef __powerpc64__
>  # define SET_PERSONALITY(ex) \
>  do { \
> - if (((ex).e_flags & 0x3) == 2)  \
> - set_thread_flag(TIF_ELF2ABI);   \
> - else\
> - clear_thread_flag(TIF_ELF2ABI); \
> - if ((ex).e_ident[EI_CLASS] == ELFCLASS32)   \
> - set_thread_flag(TIF_32BIT); \
> - else\
> - clear_thread_flag(TIF_32BIT);   \
> + update_thread_flag(TIF_ELF2ABI, ((ex).e_flags & 0x3) == 2); \
> + update_thread_flag(TIF_32BIT, (ex).e_ident[EI_CLASS] == ELFCLASS32); \
>   if (personality(current->personality) != PER_LINUX32)   \
>   set_personality(PER_LINUX | \
>   (current->personality & (~PER_MASK)));  \

Thanks for cleaning it up.

Acked-by: Michael Ellerman 

cheers


[PATCH] cfg80211: further limit wiphy names to 64 bytes

2018-05-14 Thread Eric Biggers
From: Eric Biggers 

wiphy names were recently limited to 128 bytes by commit a7cfebcb7594
("cfg80211: limit wiphy names to 128 bytes").  As it turns out though,
this isn't sufficient because dev_vprintk_emit() needs the syslog header
string "SUBSYSTEM=ieee80211\0DEVICE=+ieee80211:$devname" to fit into 128
bytes.  This triggered the "device/subsystem name too long" WARN when
the device name was >= 90 bytes.  As before, this was reproduced by
syzbot by sending an HWSIM_CMD_NEW_RADIO command to the MAC80211_HWSIM
generic netlink family.

Fix it by further limiting wiphy names to 64 bytes.

Reported-by: syzbot+e64565577af34b376...@syzkaller.appspotmail.com
Fixes: a7cfebcb7594 ("cfg80211: limit wiphy names to 128 bytes")
Signed-off-by: Eric Biggers 
---
 include/uapi/linux/nl80211.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 9c3630146cec0..271b93783d282 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2698,7 +2698,7 @@ enum nl80211_attrs {
 #define NL80211_ATTR_KEYS NL80211_ATTR_KEYS
 #define NL80211_ATTR_FEATURE_FLAGS NL80211_ATTR_FEATURE_FLAGS
 
-#define NL80211_WIPHY_NAME_MAXLEN  128
+#define NL80211_WIPHY_NAME_MAXLEN  64
 
 #define NL80211_MAX_SUPP_RATES 32
 #define NL80211_MAX_SUPP_HT_RATES  77
-- 
2.17.0



[PATCH v4 1/3] random: Fix whitespace pre random-bytes work

2018-05-14 Thread Tobin C. Harding
There are a couple of whitespace issues around the function
get_random_bytes_arch().  In preparation for patching this function
let's clean them up.

Signed-off-by: Tobin C. Harding 
Acked-by: Theodore Ts'o 
---
 drivers/char/random.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index cd888d4ee605..031d18b31e0f 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1737,7 +1737,7 @@ void get_random_bytes_arch(void *buf, int nbytes)
 
if (!arch_get_random_long())
break;
-   
+
memcpy(p, , chunk);
p += chunk;
nbytes -= chunk;
@@ -1748,7 +1748,6 @@ void get_random_bytes_arch(void *buf, int nbytes)
 }
 EXPORT_SYMBOL(get_random_bytes_arch);
 
-
 /*
  * init_std_data - initialize pool with system data
  *
-- 
2.7.4



[PATCH v4 0/3] enable early printing of hashed pointers

2018-05-14 Thread Tobin C. Harding
Currently if an attempt is made to print a pointer before there is
enough entropy then '(ptrval)' is printed.  This makes debugging
stack traces during early boot difficult.

One partial solution to this problem is to use the hw RNG if it is
available.

This version drops the final patch from the series to facilitate 
merge via Ted's tree.

Ted are you able to take these patches please?

Patch 1 - Whitespace fixes.
Patch 2 - Fix get_random_bytes_arch()
Patch 3 - Use hw RNG for pointer hashing if available (by default).


thanks,
Tobin.

v3 -> v4
 - remove last patch of series (command line option patch)

v2 -> v3
 - Add __ro_after_init (suggested by Kees).

v1 -> v2
 - Use min_t() instead of min() (thanks checkpatch).
 - Add __must_check to function declaration (thanks Steve).
 - Use hw RNG by default if available (as originally suggested by Kees).
 - Add command line option to use cryptographically insecure hashing.
   If debug_early_boot is enabled use hash_long() instead of siphash
   (as requested by Steve, and solves original problem for Anna-Maria).

Tobin C. Harding (3):
  random: Fix whitespace pre random-bytes work
  random: Return nbytes filled from hw RNG
  vsprintf: Use hw RNG for ptr_key

 drivers/char/random.c  | 19 ++-
 include/linux/random.h |  2 +-
 lib/vsprintf.c | 19 ---
 3 files changed, 27 insertions(+), 13 deletions(-)

-- 
2.7.4



[PATCH v4 3/3] vsprintf: Use hw RNG for ptr_key

2018-05-14 Thread Tobin C. Harding
Currently we must wait for enough entropy to become available before
hashed pointers can be printed.  We can remove this wait by using the
hw RNG if available.

Use hw RNG to get keying material.

Suggested-by: Kees Cook 
Signed-off-by: Tobin C. Harding 
---
 lib/vsprintf.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index b82f0c6c2aec..3697a19c2b25 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1657,9 +1657,8 @@ char *device_node_string(char *buf, char *end, struct 
device_node *dn,
 static bool have_filled_random_ptr_key __read_mostly;
 static siphash_key_t ptr_key __read_mostly;
 
-static void fill_random_ptr_key(struct random_ready_callback *unused)
+static void ptr_key_ready(void)
 {
-   get_random_bytes(_key, sizeof(ptr_key));
/*
 * have_filled_random_ptr_key==true is dependent on get_random_bytes().
 * ptr_to_id() needs to see have_filled_random_ptr_key==true
@@ -1669,14 +1668,28 @@ static void fill_random_ptr_key(struct 
random_ready_callback *unused)
WRITE_ONCE(have_filled_random_ptr_key, true);
 }
 
+static void fill_random_ptr_key(struct random_ready_callback *unused)
+{
+   get_random_bytes(_key, sizeof(ptr_key));
+   ptr_key_ready();
+}
+
 static struct random_ready_callback random_ready = {
.func = fill_random_ptr_key
 };
 
 static int __init initialize_ptr_random(void)
 {
-   int ret = add_random_ready_callback(_ready);
+   int ret;
+   int key_size = sizeof(ptr_key);
+
+   /* Use hw RNG if available */
+   if (get_random_bytes_arch(_key, key_size) == key_size) {
+   ptr_key_ready();
+   return 0;
+   }
 
+   ret = add_random_ready_callback(_ready);
if (!ret) {
return 0;
} else if (ret == -EALREADY) {
-- 
2.7.4



[PATCH v4 2/3] random: Return nbytes filled from hw RNG

2018-05-14 Thread Tobin C. Harding
Currently the function get_random_bytes_arch() has return value 'void'.
If the hw RNG fails we currently fall back to using get_random_bytes().
This defeats the purpose of requesting random material from the hw RNG
in the first place.

There are currently no intree users of get_random_bytes_arch().

Only get random bytes from the hw RNG, make function return the number
of bytes retrieved from the hw RNG.

Signed-off-by: Tobin C. Harding 
Acked-by: Theodore Ts'o 
Signed-off-by: Tobin C. Harding 
---
 drivers/char/random.c  | 16 +---
 include/linux/random.h |  2 +-
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 031d18b31e0f..4b0ec597e783 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1725,26 +1725,28 @@ EXPORT_SYMBOL(del_random_ready_callback);
  * key known by the NSA).  So it's useful if we need the speed, but
  * only if we're willing to trust the hardware manufacturer not to
  * have put in a back door.
+ *
+ * Return number of bytes filled in.
  */
-void get_random_bytes_arch(void *buf, int nbytes)
+int __must_check get_random_bytes_arch(void *buf, int nbytes)
 {
char *p = buf;
+   int left = nbytes;
 
-   trace_get_random_bytes_arch(nbytes, _RET_IP_);
-   while (nbytes) {
+   trace_get_random_bytes_arch(left, _RET_IP_);
+   while (left) {
unsigned long v;
-   int chunk = min(nbytes, (int)sizeof(unsigned long));
+   int chunk = min_t(int, left, (int)sizeof(unsigned long));
 
if (!arch_get_random_long())
break;
 
memcpy(p, , chunk);
p += chunk;
-   nbytes -= chunk;
+   left -= chunk;
}
 
-   if (nbytes)
-   get_random_bytes(p, nbytes);
+   return nbytes - left;
 }
 EXPORT_SYMBOL(get_random_bytes_arch);
 
diff --git a/include/linux/random.h b/include/linux/random.h
index 2ddf13b4281e..f1c9bc5cd231 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -38,7 +38,7 @@ extern void get_random_bytes(void *buf, int nbytes);
 extern int wait_for_random_bytes(void);
 extern int add_random_ready_callback(struct random_ready_callback *rdy);
 extern void del_random_ready_callback(struct random_ready_callback *rdy);
-extern void get_random_bytes_arch(void *buf, int nbytes);
+extern int __must_check get_random_bytes_arch(void *buf, int nbytes);
 
 #ifndef MODULE
 extern const struct file_operations random_fops, urandom_fops;
-- 
2.7.4



linux-next: manual merge of the audit tree with the selinux tree

2018-05-14 Thread Stephen Rothwell
Hi Paul,

Today's linux-next merge of the audit tree got a conflict in:

  security/selinux/selinuxfs.c

between commit:

  4195ed425d3c ("audit: normalize MAC_STATUS record")

from the selinux tree and commits:

  cdfb6b341f0f ("audit: use inline function to get audit context")
  d141136f523a ("audit: normalize MAC_POLICY_LOAD record")

from the audit tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc security/selinux/selinuxfs.c
index c0cadbc5f85c,35fd77737c59..
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@@ -167,13 -167,11 +167,13 @@@ static ssize_t sel_write_enforce(struc
  NULL);
if (length)
goto out;
-   audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
+   audit_log(audit_context(), GFP_KERNEL, AUDIT_MAC_STATUS,
 -  "enforcing=%d old_enforcing=%d auid=%u ses=%u",
 +  "enforcing=%d old_enforcing=%d auid=%u ses=%u"
 +  " enabled=%d old-enabled=%d lsm=selinux res=1",
new_value, old_value,
from_kuid(_user_ns, audit_get_loginuid(current)),
 -  audit_get_sessionid(current));
 +  audit_get_sessionid(current),
 +  selinux_enabled, selinux_enabled);
enforcing_set(state, new_value);
if (new_value)
avc_ss_reset(state->avc, 0);
@@@ -303,12 -299,10 +303,12 @@@ static ssize_t sel_write_disable(struc
length = selinux_disable(fsi->state);
if (length)
goto out;
-   audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
+   audit_log(audit_context(), GFP_KERNEL, AUDIT_MAC_STATUS,
 -  "selinux=0 auid=%u ses=%u",
 +  "enforcing=%d old_enforcing=%d auid=%u ses=%u"
 +  " enabled=%d old-enabled=%d lsm=selinux res=1",
 +  enforcing, enforcing,
from_kuid(_user_ns, audit_get_loginuid(current)),
 -  audit_get_sessionid(current));
 +  audit_get_sessionid(current), 0, 1);
}
  
length = count;
@@@ -581,8 -575,8 +581,8 @@@ static ssize_t sel_write_load(struct fi
length = count;
  
  out1:
-   audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_POLICY_LOAD,
+   audit_log(audit_context(), GFP_KERNEL, AUDIT_MAC_POLICY_LOAD,
 -  "policy loaded auid=%u ses=%u",
 +  "auid=%u ses=%u lsm=selinux res=1",
from_kuid(_user_ns, audit_get_loginuid(current)),
audit_get_sessionid(current));
  out:


pgpz_EB9ONekh.pgp
Description: OpenPGP digital signature


Re: [RFC PATCH 07/11] powerpc: Move arch-specific prctls out of core code

2018-05-14 Thread Michael Ellerman
Dave Martin  writes:

> This patch moves the powerpc-specific prctl call implementations
> out of core code and removes redundant boilerplate associated with
> them.
>
> No functional change.
>
> Signed-off-by: Dave Martin 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> ---
>  arch/powerpc/Kconfig |  1 +
>  arch/powerpc/include/asm/processor.h |  6 --
>  arch/powerpc/kernel/syscalls.c   | 17 +
>  kernel/sys.c | 24 
>  4 files changed, 18 insertions(+), 30 deletions(-)

This also looks OK to me.

Acked-by: Michael Ellerman 

cheers


Re: [PATCH ghak81 RFC V2 3/5] audit: use inline function to get audit context

2018-05-14 Thread Richard Guy Briggs
On 2018-05-14 17:44, Paul Moore wrote:
> On Sat, May 12, 2018 at 9:58 PM, Richard Guy Briggs  wrote:
> > Recognizing that the audit context is an internal audit value, use an
> > access function to retrieve the audit context pointer for the task
> > rather than reaching directly into the task struct to get it.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  include/linux/audit.h| 14 ++--
> >  include/net/xfrm.h   |  2 +-
> >  kernel/audit.c   |  6 ++--
> >  kernel/audit_watch.c |  2 +-
> >  kernel/auditsc.c | 64 
> > +---
> >  net/bridge/netfilter/ebtables.c  |  2 +-
> >  net/core/dev.c   |  2 +-
> >  net/netfilter/x_tables.c |  2 +-
> >  net/netlabel/netlabel_user.c |  2 +-
> >  security/integrity/ima/ima_api.c |  2 +-
> >  security/integrity/integrity_audit.c |  2 +-
> >  security/lsm_audit.c |  2 +-
> >  security/selinux/hooks.c |  4 +--
> >  security/selinux/selinuxfs.c |  6 ++--
> >  security/selinux/ss/services.c   | 12 +++
> >  15 files changed, 64 insertions(+), 60 deletions(-)
> 
> Merged, but there was some fuzz due to the missing 1/5 patch and a
> handfull of checkpatch.pl fixes.  Please take a look at the commit in
> the audit/next branch and if anything looks awry please send a patch
> to fix it.

Some of that fuzz was due to the two patches (ghak46/47) that went
through the xelinux tree...  There will be a merge conflict.

Otherwise, looks ok.

> paul moore

- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635


Re: [RFC PATCH 06/11] powerpc: Remove unused task argument from prctl functions

2018-05-14 Thread Michael Ellerman
Dave Martin  writes:

> Some powerpc-specific prctl backends take a task argument that is
> redundant, since the only thing ever passed is "current".
>
> This patch gets rid of the redundant arguments.
>
> No functional change.
>
> Signed-off-by: Dave Martin 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> ---
>  arch/powerpc/include/asm/processor.h | 16 
>  arch/powerpc/kernel/process.c| 30 +++---
>  kernel/sys.c | 12 ++--
>  3 files changed, 29 insertions(+), 29 deletions(-)

This looks fine. I'm happy for it to get tested in linux-next to shake
out anything subtle.

Acked-by: Michael Ellerman 

cheers


RE: for_each_cpu() is buggy for UP kernel?

2018-05-14 Thread Dexuan Cui
> From: Linus Torvalds 
> Sent: Sunday, May 13, 2018 11:22
> On Tue, May 8, 2018 at 11:24 PM Dexuan Cui  wrote:
> 
> > Should we fix the for_each_cpu() in include/linux/cpumask.h for UP?
> 
> As Thomas points out, this has come up before.
> 
> One of the issues is historical - we tried very hard to make the SMP code
> not cause code generation problems for UP, and part of that was just that
> all these loops were literally designed to entirely go away under UP. It
> still *looks* syntactically like a loop, but an optimizing compiler will
> see that there's nothing there, and "for_each_cpu(...) x" essentially just
> turns into "x" on UP.  An empty mask simply generally doesn't make sense,
> since opn UP you also don't have any masking of CPU ops, so the mask is
> ignored, and that helps the code generation immensely.
> 
> If you have to load and test the mask, you immediately lose out badly in
> code generation.
Thank you all for the insights and the detailed background introduction!
 
> So honestly, I'd really prefer to keep our current behavior. Perhaps with a
> debug option that actually tests (on SMP - because that's what every
> developer is actually _using_ these days) that the mask isn't empty. But
> I'm not sure that would find this case, since presumably on SMP it might
> never be empty.
I agree.

> Now, there is likely a fairly good argument that UP is getting _so_
> uninteresting that we shouldn't even worry about code generation. But the
> counter-argument to that is that if people are using UP in this day and
> age, they probably are using some really crappy hardware that needs all the
> help it can get.
FWIW, I happened to find this issue in a SMP virtual machine, but the kernel
from a customer was built with CONFIG_SMP disabled. After spending 1 day
debugging the strange boot-up delay, which was caused by the unexpected
PIT interrupt storm, I finally tracked it down to the UP version of 
for_each_cpu().

The function exposing the issue is kernel/time/tick-broadcast.c:
tick_handle_oneshot_broadcast().

If you're OK with the below fix (not tested yet), I'll submit a patch for it:

--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -616,6 +616,10 @@ static void tick_handle_oneshot_broadcast(struct 
clock_event_device *dev)
now = ktime_get();
/* Find all expired events */
for_each_cpu(cpu, tick_broadcast_oneshot_mask) {
+#ifndef CONFIG_SMP
+   if (cpumask_empty(tick_broadcast_oneshot_mask))
+   break;
+#endif
td = _cpu(tick_cpu_device, cpu);
if (td->evtdev->next_event <= now) {
cpumask_set_cpu(cpu, tmpmask); 

> At least for now, I'd rather have this inconsistency, because it really
> makes a surprisingly *big* difference in code generation.  From the little
> test I just did, adding that mask testing to a *single* case of
> for_each_cpu() added 20 instructions.  I didn't look at exactly why that
> happened (because the code generation was so radically different), but it
> was very noticeable. I used your macro replacement in kernel/taskstats.c in
> case you want to try to dig into what happened, but I'm not surprised. It
> really turns an unconditional trivial loop into a much more complex thing
> that needs to look at and test a value that we didn't care about before.
I agree.

 
> Maybe we should introduce a "for_each_cpu_maybe_empty()" helper for
> cases  like this?
> Linus
Sounds like a good idea.

Thanks,
-- Dexuan


[PATCH] kernel: sys: fix potential Spectre v1

2018-05-14 Thread Gustavo A. R. Silva
resource can be controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential
spectre issue 'get_current()->signal->rlim' (local cap)
kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue
'get_current()->signal->rlim' (local cap)

Fix this by sanitizing *resource* before using it to index
current->signal->rlim

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel=152449131114778=2

Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
---
 kernel/sys.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/sys.c b/kernel/sys.c
index 63ef036..78646e6 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -69,6 +69,9 @@
 #include 
 #include 
 
+/* Hardening for Spectre-v1 */
+#include 
+
 #include "uid16.h"
 
 #ifndef SET_UNALIGN_CTL
@@ -1451,6 +1454,7 @@ SYSCALL_DEFINE2(old_getrlimit, unsigned int, resource,
if (resource >= RLIM_NLIMITS)
return -EINVAL;
 
+   resource = array_index_nospec(resource, RLIM_NLIMITS);
task_lock(current->group_leader);
x = current->signal->rlim[resource];
task_unlock(current->group_leader);
@@ -1470,6 +1474,7 @@ COMPAT_SYSCALL_DEFINE2(old_getrlimit, unsigned int, 
resource,
if (resource >= RLIM_NLIMITS)
return -EINVAL;
 
+   resource = array_index_nospec(resource, RLIM_NLIMITS);
task_lock(current->group_leader);
r = current->signal->rlim[resource];
task_unlock(current->group_leader);
-- 
2.7.4



[PATCH v2 5/5] hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX

2018-05-14 Thread Leo Yan
From: Daniel Lezcano 

The current defconfig is inconsistent as it selects the mailbox and
the clock for the hi6220 and the hi3660 without having their Kconfigs
making sure the dependencies are correct. It ends up when selecting
different versions for the kernel (for example when git bisecting)
those options disappear and they don't get back, leading to unexpected
behaviors. In our case, the cpufreq driver does no longer work because
the clock fails to initialize due to the clock stub and the mailbox
missing.

In order to have the dependencies correctly set when defaulting, let's
do the same as commit 3a49afb84ca074e ("clk: enable hi655x common clk
automatically") where we select automatically the driver when the
parent driver is selected. With sensible defaults in place, we can leave
other choices for EXPERT.

Acked-by: Stephen Boyd 
Acked-by: Jassi Brar 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Leo Yan 
---
 arch/arm64/configs/defconfig  |  1 -
 drivers/clk/hisilicon/Kconfig | 13 -
 drivers/mailbox/Kconfig   | 12 
 3 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ecf6137..1d9d8b9 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -549,7 +549,6 @@ CONFIG_HWSPINLOCK_QCOM=y
 CONFIG_ARM_MHU=y
 CONFIG_PLATFORM_MHU=y
 CONFIG_BCM2835_MBOX=y
-CONFIG_HI6220_MBOX=y
 CONFIG_QCOM_APCS_IPC=y
 CONFIG_ROCKCHIP_IOMMU=y
 CONFIG_TEGRA_IOMMU_SMMU=y
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index 1bd4355..becdb1d 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -44,14 +44,17 @@ config RESET_HISI
  Build reset controller driver for HiSilicon device chipsets.
 
 config STUB_CLK_HI6220
-   bool "Hi6220 Stub Clock Driver"
-   depends on COMMON_CLK_HI6220 && MAILBOX
-   default ARCH_HISI
+   bool "Hi6220 Stub Clock Driver" if EXPERT
+   depends on (COMMON_CLK_HI6220 || COMPILE_TEST)
+   depends on MAILBOX
+   default COMMON_CLK_HI6220
help
  Build the Hisilicon Hi6220 stub clock driver.
 
 config STUB_CLK_HI3660
-   bool "Hi3660 Stub Clock Driver"
-   depends on COMMON_CLK_HI3660 && MAILBOX
+   bool "Hi3660 Stub Clock Driver" if EXPERT
+   depends on (COMMON_CLK_HI3660 || COMPILE_TEST)
+   depends on MAILBOX
+   default COMMON_CLK_HI3660
help
  Build the Hisilicon Hi3660 stub clock driver.
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index a2bb274..567cd02 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -109,16 +109,20 @@ config TI_MESSAGE_MANAGER
  platform has support for the hardware block.
 
 config HI3660_MBOX
-   tristate "Hi3660 Mailbox"
-   depends on ARCH_HISI && OF
+   tristate "Hi3660 Mailbox" if EXPERT
+   depends on (ARCH_HISI || COMPILE_TEST)
+   depends on OF
+   default ARCH_HISI
help
  An implementation of the hi3660 mailbox. It is used to send message
  between application processors and other processors/MCU/DSP. Select
  Y here if you want to use Hi3660 mailbox controller.
 
 config HI6220_MBOX
-   tristate "Hi6220 Mailbox"
-   depends on ARCH_HISI
+   tristate "Hi6220 Mailbox" if EXPERT
+   depends on (ARCH_HISI || COMPILE_TEST)
+   depends on OF
+   default ARCH_HISI
help
  An implementation of the hi6220 mailbox. It is used to send message
  between application processors and MCU. Say Y here if you want to
-- 
1.9.1



[PATCH v2 4/5] arm64: dts: hi3660: Add thermal cooling management

2018-05-14 Thread Leo Yan
From: Tao Wang 

Add nodes and properties for thermal cooling management support.

Signed-off-by: Tao Wang 
Signed-off-by: Leo Yan 
---
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 44 +++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index a39da09..e20edd9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 
 / {
compatible = "hisilicon,hi3660";
@@ -64,6 +65,8 @@
capacity-dmips-mhz = <592>;
clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
+   dynamic-power-coefficient = <110>;
};
 
cpu1: cpu@1 {
@@ -112,6 +115,8 @@
capacity-dmips-mhz = <1024>;
clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
+   dynamic-power-coefficient = <550>;
};
 
cpu5: cpu@101 {
@@ -1073,5 +1078,44 @@
interrupts = ;
#thermal-sensor-cells = <1>;
};
+
+   thermal-zones {
+
+   cls0: cls0 {
+   polling-delay = <1000>;
+   polling-delay-passive = <100>;
+   sustainable-power = <4500>;
+
+   /* sensor ID */
+   thermal-sensors = < 1>;
+
+   trips {
+   threshold: trip-point@0 {
+   temperature = <65000>;
+   hysteresis = <1000>;
+   type = "passive";
+   };
+
+   target: trip-point@1 {
+   temperature = <75000>;
+   hysteresis = <1000>;
+   type = "passive";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   contribution = <1024>;
+   cooling-device = < 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   map1 {
+   trip = <>;
+   contribution = <512>;
+   cooling-device = < 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+   };
+   };
};
 };
-- 
1.9.1



[PATCH 0/3] x86/build: clean-up of vdso Makefile

2018-05-14 Thread Masahiro Yamada



Masahiro Yamada (3):
  x86/build: vdso: remove unused $(vobjs-nox32) in Makefile
  x86/build: vdso: remove unnecessary export in Makefile
  x86/build: vdso: put generated linker scripts to $(obj)/

 arch/x86/entry/vdso/Makefile | 11 ---
 arch/x86/um/vdso/Makefile|  4 ++--
 2 files changed, 6 insertions(+), 9 deletions(-)

-- 
2.7.4



[PATCH v2 3/5] arm64: dts: hi3660: Add CPU frequency scaling support

2018-05-14 Thread Leo Yan
Add two CPU OPP tables, one table is corresponding to one cluster,
which allow CPU frequency scaling on hi3660 platforms.

Signed-off-by: Leo Yan 
---
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 86 +++
 1 file changed, 86 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 3a3bcff..a39da09 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -62,6 +62,8 @@
next-level-cache = <_L2>;
cpu-idle-states = <_SLEEP _SLEEP_0>;
capacity-dmips-mhz = <592>;
+   clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
+   operating-points-v2 = <_opp>;
};
 
cpu1: cpu@1 {
@@ -72,6 +74,8 @@
next-level-cache = <_L2>;
cpu-idle-states = <_SLEEP _SLEEP_0>;
capacity-dmips-mhz = <592>;
+   clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
+   operating-points-v2 = <_opp>;
};
 
cpu2: cpu@2 {
@@ -82,6 +86,8 @@
next-level-cache = <_L2>;
cpu-idle-states = <_SLEEP _SLEEP_0>;
capacity-dmips-mhz = <592>;
+   clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
+   operating-points-v2 = <_opp>;
};
 
cpu3: cpu@3 {
@@ -92,6 +98,8 @@
next-level-cache = <_L2>;
cpu-idle-states = <_SLEEP _SLEEP_0>;
capacity-dmips-mhz = <592>;
+   clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
+   operating-points-v2 = <_opp>;
};
 
cpu4: cpu@100 {
@@ -102,6 +110,8 @@
next-level-cache = <_L2>;
cpu-idle-states = <_SLEEP _SLEEP_1>;
capacity-dmips-mhz = <1024>;
+   clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
+   operating-points-v2 = <_opp>;
};
 
cpu5: cpu@101 {
@@ -112,6 +122,8 @@
next-level-cache = <_L2>;
cpu-idle-states = <_SLEEP _SLEEP_1>;
capacity-dmips-mhz = <1024>;
+   clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
+   operating-points-v2 = <_opp>;
};
 
cpu6: cpu@102 {
@@ -122,6 +134,8 @@
next-level-cache = <_L2>;
cpu-idle-states = <_SLEEP _SLEEP_1>;
capacity-dmips-mhz = <1024>;
+   clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
+   operating-points-v2 = <_opp>;
};
 
cpu7: cpu@103 {
@@ -132,6 +146,8 @@
next-level-cache = <_L2>;
cpu-idle-states = <_SLEEP _SLEEP_1>;
capacity-dmips-mhz = <1024>;
+   clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
+   operating-points-v2 = <_opp>;
};
 
idle-states {
@@ -174,6 +190,76 @@
};
};
 
+   cluster0_opp: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp00 {
+   opp-hz = /bits/ 64 <53300>;
+   opp-microvolt = <70>;
+   clock-latency-ns = <30>;
+   };
+
+   opp01 {
+   opp-hz = /bits/ 64 <99900>;
+   opp-microvolt = <80>;
+   clock-latency-ns = <30>;
+   };
+
+   opp02 {
+   opp-hz = /bits/ 64 <140200>;
+   opp-microvolt = <90>;
+   clock-latency-ns = <30>;
+   };
+
+   opp03 {
+   opp-hz = /bits/ 64 <170900>;
+   opp-microvolt = <100>;
+   clock-latency-ns = <30>;
+   };
+
+   opp04 {
+   opp-hz = /bits/ 64 <184400>;
+   opp-microvolt = <110>;
+   clock-latency-ns = <30>;
+   };
+   };
+
+   cluster1_opp: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp10 {
+   opp-hz = /bits/ 64 <90300>;
+   opp-microvolt = <70>;
+   clock-latency-ns = <30>;
+   };
+
+   opp11 {
+   opp-hz = /bits/ 64 <142100>;
+   

[PATCH v2 2/5] arm64: dts: hi3660: Add stub clock node

2018-05-14 Thread Leo Yan
From: Kaihua Zhong 

Add stub clock node for hi3660 platform.

Reviewed-by: Leo Yan 
Signed-off-by: Kaihua Zhong 
Signed-off-by: Leo Yan 
---
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index b9e7c91..3a3bcff 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -282,6 +282,13 @@
#mbox-cells = <3>;
};
 
+   stub_clock: stub_clock@e896b500 {
+   compatible = "hisilicon,hi3660-stub-clk";
+   reg = <0x0 0xe896b500 0x0 0x0100>;
+   #clock-cells = <1>;
+   mboxes = < 13 3 0>;
+   };
+
dual_timer0: timer@fff14000 {
compatible = "arm,sp804", "arm,primecell";
reg = <0x0 0xfff14000 0x0 0x1000>;
-- 
1.9.1



Re: [PATCH v9 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

2018-05-14 Thread Michael Ellerman
Hi Bart,

Bart Van Assche  writes:
>
...
> diff --git a/Documentation/features/locking/cmpxchg64/arch-support.txt 
> b/Documentation/features/locking/cmpxchg64/arch-support.txt
> new file mode 100644
> index ..65b3290ce5d5
> --- /dev/null
> +++ b/Documentation/features/locking/cmpxchg64/arch-support.txt
> @@ -0,0 +1,31 @@
> +#
> +# Feature name:  cmpxchg64
> +# Kconfig:   ARCH_HAVE_CMPXCHG64
> +# description:   arch supports the cmpxchg64() API
> +#
> +---
> +| arch |status|
> +---
> +|   alpha: |  ok  |
> +| arc: | TODO |
> +| arm: |!thumb|
> +|   arm64: |  ok  |
> +| c6x: | TODO |
> +|   h8300: | TODO |
> +| hexagon: | TODO |
> +|ia64: |  ok  |
> +|m68k: |  ok  |
> +|  microblaze: | TODO |
> +|mips: |64-bit|
> +|   nios2: | TODO |
> +|openrisc: | TODO |
> +|  parisc: |  ok  |
> +| powerpc: |64-bit|

I think that is correct for powerpc, we don't have a 32-bit
implementation and there's no fallback it seems.

> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -150,6 +150,7 @@ config PPC
>   select ARCH_HAS_UBSAN_SANITIZE_ALL
>   select ARCH_HAS_ZONE_DEVICE if PPC_BOOK3S_64
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
> + select ARCH_HAVE_CMPXCHG64

So shouldn't this should be:

+   select ARCH_HAVE_CMPXCHG64  if PPC64

And it should be sorted alphabetically, ie. above the previous NMI entry.

cheers


[PATCH 3/3] x86/build: vdso: put generated linker scripts to $(obj)/

2018-05-14 Thread Masahiro Yamada
Let's put generated files to $(obj)/ rather than $(src)/ although
this is just a matter of taste because both are the same.

Signed-off-by: Masahiro Yamada 
---

 arch/x86/entry/vdso/Makefile | 4 ++--
 arch/x86/um/vdso/Makefile| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 690df4c..261802b 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -51,7 +51,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
-Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 \
$(DISABLE_LTO)
 
-$(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
+$(obj)/vdso64.so.dbg: $(obj)/vdso.lds $(vobjs) FORCE
$(call if_changed,vdso)
 
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi 
-I$(srctree)/arch/$(SUBARCH)/include/uapi
@@ -119,7 +119,7 @@ $(obj)/%.so: OBJCOPYFLAGS := -S
 $(obj)/%.so: $(obj)/%.so.dbg
$(call if_changed,objcopy)
 
-$(obj)/vdsox32.so.dbg: $(src)/vdsox32.lds $(vobjx32s) FORCE
+$(obj)/vdsox32.so.dbg: $(obj)/vdsox32.lds $(vobjx32s) FORCE
$(call if_changed,vdso)
 
 CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 3af55cd..822ccdb 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -30,7 +30,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
 
 $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so
 
-$(obj)/vdso.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
+$(obj)/vdso.so.dbg: $(obj)/vdso.lds $(vobjs) FORCE
$(call if_changed,vdso)
 
 $(obj)/%.so: OBJCOPYFLAGS := -S
-- 
2.7.4



[PATCH v2 0/5] Hi3660: enable power management features

2018-05-14 Thread Leo Yan
Since hi3660 drivers have been merged into Linux kernel (mailbox driver is in
Linux-next branch and other drivers are existed in Linux mainline kernel), so
this patch series is to enable power management features on hi3660.

This patch series includes device tree binding for mailbox, stub clock and CPU
OPPs, and has one patch to consolidate the Kconfigs for driver modules.

This patch set have been tested on Hikey960 and also verified the patch 'hisi:
Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX' for Hikey620.

Changes from v1:
* Changed patch subject from "dts: arm64: hi3660" to "arm64: dts: hi3660".


Daniel Lezcano (1):
  hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX

Kaihua Zhong (2):
  arm64: dts: hi3660: Add mailbox node
  arm64: dts: hi3660: Add stub clock node

Leo Yan (1):
  arm64: dts: hi3660: Add CPU frequency scaling support

Tao Wang (1):
  arm64: dts: hi3660: Add thermal cooling management

 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 145 ++
 arch/arm64/configs/defconfig  |   1 -
 drivers/clk/hisilicon/Kconfig |  13 +--
 drivers/mailbox/Kconfig   |  12 ++-
 4 files changed, 161 insertions(+), 10 deletions(-)

-- 
1.9.1



[PATCH 2/3] x86/build: vdso: remove unnecessary export in Makefile

2018-05-14 Thread Masahiro Yamada
CPPFLAGS_vdso.lds is assigned and referenced internally in each
Makefile.  No need to export it.

Signed-off-by: Masahiro Yamada 
---

 arch/x86/entry/vdso/Makefile | 2 +-
 arch/x86/um/vdso/Makefile| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 2988506..690df4c 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -44,7 +44,7 @@ obj-y += $(vdso_img_objs)
 targets += $(vdso_img_cfiles)
 targets += $(vdso_img_sodbg) $(vdso_img-y:%=vdso%.so)
 
-export CPPFLAGS_vdso.lds += -P -C
+CPPFLAGS_vdso.lds += -P -C
 
 VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
-Wl,--no-undefined \
diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 426681e..3af55cd 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -23,7 +23,7 @@ $(obj)/vdso.o: $(obj)/vdso.so
 
 targets += vdso.so vdso.so.dbg vdso.lds $(vobjs-y)
 
-export CPPFLAGS_vdso.lds += -P -C
+CPPFLAGS_vdso.lds += -P -C
 
 VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
-Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
-- 
2.7.4



[PATCH v2 1/5] arm64: dts: hi3660: Add mailbox node

2018-05-14 Thread Leo Yan
From: Kaihua Zhong 

Add the mailbox controller node for hi3660 platform.

Signed-off-by: Kaihua Zhong 
Signed-off-by: Leo Yan 
---
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ec3eb8e..b9e7c91 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -274,6 +274,14 @@
#reset-cells = <2>;
};
 
+   mailbox: mailbox@e896b000 {
+   compatible = "hisilicon,hi3660-mbox";
+   reg = <0x0 0xe896b000 0x0 0x1000>;
+   interrupts = ,
+;
+   #mbox-cells = <3>;
+   };
+
dual_timer0: timer@fff14000 {
compatible = "arm,sp804", "arm,primecell";
reg = <0x0 0xfff14000 0x0 0x1000>;
-- 
1.9.1



[PATCH 1/3] x86/build: vdso: remove unused $(vobjs-nox32) in Makefile

2018-05-14 Thread Masahiro Yamada
Since commit bfad381c0d1e ("x86/vdso: Improve the fake section
headers"), $(vobjs-nox32) is empty.  Therefore, $(vobjs64-for-x32)
is the same as $(vobjs-y).

Signed-off-by: Masahiro Yamada 
---

 arch/x86/entry/vdso/Makefile | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index d998a48..2988506 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -100,11 +100,8 @@ VDSO_LDFLAGS_vdsox32.lds = -Wl,-m,elf32_x86_64 \
   -Wl,-z,max-page-size=4096 \
   -Wl,-z,common-page-size=4096
 
-# 64-bit objects to re-brand as x32
-vobjs64-for-x32 := $(filter-out $(vobjs-nox32),$(vobjs-y))
-
 # x32-rebranded versions
-vobjx32s-y := $(vobjs64-for-x32:.o=-x32.o)
+vobjx32s-y := $(vobjs-y:.o=-x32.o)
 
 # same thing, but in the output directory
 vobjx32s := $(foreach F,$(vobjx32s-y),$(obj)/$F)
-- 
2.7.4



Re: [PATCH] lib/rhashtable: reorder some inititalization sequences

2018-05-14 Thread David Miller
From: Davidlohr Bueso 
Date: Mon, 14 May 2018 08:13:32 -0700

> rhashtable_init() allocates memory at the very end of the
> call, once everything is setup; with the exception of the
> nelems parameter. However, unless the user is doing something
> bogus with params for which -EINVAL is returned, memory
> allocation is the only operation that can trigger the call
> to fail.
> 
> Thus move bucket_table_alloc() up such that we fail back to
> the caller asap, instead of doing useless checks. This is
> safe as the the table allocation isn't using the halfly
> setup 'ht' structure and bucket_table_alloc() call chain only
> ends up using the ht->nulls_base member in INIT_RHT_NULLS_HEAD.
> 
> Also move the locking initialization down to the end.
> 
> Signed-off-by: Davidlohr Bueso 

The user potentially "doing something bogus" is why the most
expensive part of the initialization (the memory allocation)
is done after everything else is validated.

I think it's best to keep things as-is.


Re: [PATCH] mptlan: fix mpt_lan_sdu_send()'s return type

2018-05-14 Thread Martin K. Petersen

Luc,

>> You forgot to update the function prototype accordingly.
>
> Hmmm, the function mpt_lan_sdu_send() has no other declaration
> than the one I modified the return type in this patch.
>
> Must be a misunderstanding somewhere.

My bad, I thought you were updating mpt_lan_send_reply().

Applied to 4.18/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering


[PATCH] usbip: usbip_host: fix NULL-ptr deref and use-after-free errors

2018-05-14 Thread Shuah Khan (Samsung OSG)
usbip_host updates device status without holding lock from stub probe,
disconnect and rebind code paths. When multiple requests to import a
device are received, these unprotected code paths step all over each
other and drive fails with NULL-ptr deref and use-after-free errors.

The driver uses a table lock to protect the busid array for adding and
deleting busids to the table. However, the probe, disconnect and rebind
paths get the busid table entry and update the status without holding
the busid table lock. Add a new finer grain lock to protect the busid
entry. This new lock will be held to search and update the busid entry
fields from get_busid_idx(), add_match_busid() and del_match_busid().

match_busid_show() does the same to access the busid entry fields.

get_busid_priv() changed to return the pointer to the busid entry holding
the busid lock. stub_probe(), stub_disconnect() and stub_device_rebind()
call put_busid_priv() to release the busid lock before returning. This
changes fixes the unprotected code paths eliminating the race conditions
in updating the busid entries.

Signed-off-by: Shuah Khan (Samsung OSG) 
---
 drivers/usb/usbip/stub.h  |  2 ++
 drivers/usb/usbip/stub_dev.c  | 33 +++--
 drivers/usb/usbip/stub_main.c | 40 +++-
 3 files changed, 60 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/usbip/stub.h b/drivers/usb/usbip/stub.h
index 14a72357800a..35618ceb2791 100644
--- a/drivers/usb/usbip/stub.h
+++ b/drivers/usb/usbip/stub.h
@@ -73,6 +73,7 @@ struct bus_id_priv {
struct stub_device *sdev;
struct usb_device *udev;
char shutdown_busid;
+   spinlock_t busid_lock;
 };
 
 /* stub_priv is allocated from stub_priv_cache */
@@ -83,6 +84,7 @@ extern struct usb_device_driver stub_driver;
 
 /* stub_main.c */
 struct bus_id_priv *get_busid_priv(const char *busid);
+void put_busid_priv(struct bus_id_priv *bid);
 int del_match_busid(char *busid);
 void stub_device_cleanup_urbs(struct stub_device *sdev);
 
diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index 9d0425113c4b..c0d6ff1baa72 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -300,7 +300,7 @@ static int stub_probe(struct usb_device *udev)
struct stub_device *sdev = NULL;
const char *udev_busid = dev_name(>dev);
struct bus_id_priv *busid_priv;
-   int rc;
+   int rc = 0;
 
dev_dbg(>dev, "Enter probe\n");
 
@@ -317,13 +317,15 @@ static int stub_probe(struct usb_device *udev)
 * other matched drivers by the driver core.
 * See driver_probe_device() in driver/base/dd.c
 */
-   return -ENODEV;
+   rc = -ENODEV;
+   goto call_put_busid_priv;
}
 
if (udev->descriptor.bDeviceClass == USB_CLASS_HUB) {
dev_dbg(>dev, "%s is a usb hub device... skip!\n",
 udev_busid);
-   return -ENODEV;
+   rc = -ENODEV;
+   goto call_put_busid_priv;
}
 
if (!strcmp(udev->bus->bus_name, "vhci_hcd")) {
@@ -331,13 +333,16 @@ static int stub_probe(struct usb_device *udev)
"%s is attached on vhci_hcd... skip!\n",
udev_busid);
 
-   return -ENODEV;
+   rc = -ENODEV;
+   goto call_put_busid_priv;
}
 
/* ok, this is my device */
sdev = stub_device_alloc(udev);
-   if (!sdev)
-   return -ENOMEM;
+   if (!sdev) {
+   rc = -ENOMEM;
+   goto call_put_busid_priv;
+   }
 
dev_info(>dev,
"usbip-host: register new device (bus %u dev %u)\n",
@@ -369,7 +374,9 @@ static int stub_probe(struct usb_device *udev)
}
busid_priv->status = STUB_BUSID_ALLOC;
 
-   return 0;
+   rc = 0;
+   goto call_put_busid_priv;
+
 err_files:
usb_hub_release_port(udev->parent, udev->portnum,
 (struct usb_dev_state *) udev);
@@ -379,6 +386,9 @@ static int stub_probe(struct usb_device *udev)
 
busid_priv->sdev = NULL;
stub_device_free(sdev);
+
+call_put_busid_priv:
+   put_busid_priv(busid_priv);
return rc;
 }
 
@@ -417,7 +427,7 @@ static void stub_disconnect(struct usb_device *udev)
/* get stub_device */
if (!sdev) {
dev_err(>dev, "could not get device");
-   return;
+   goto call_put_busid_priv;
}
 
dev_set_drvdata(>dev, NULL);
@@ -432,12 +442,12 @@ static void stub_disconnect(struct usb_device *udev)
  (struct usb_dev_state *) udev);
if (rc) {
dev_dbg(>dev, "unable to release port\n");
-   return;
+   goto call_put_busid_priv;
}
 
/* If usb reset is called from event 

Re: [PATCH] scsi: clean up generated file scsi_devinfo_tbl.c

2018-05-14 Thread Martin K. Petersen

Randy,

> "make clean" should remove the generated file "scsi_devinfo_tbl.c", so
> list it in the clean-files variable so that the file gets cleaned up.

Applied to 4.17/scsi-fixes. Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH net 2/2] vmxnet3: use DMA memory barriers where required

2018-05-14 Thread David Miller
From: 
Date: Mon, 14 May 2018 08:14:49 -0400

> The gen bits must be read first from (resp. written last to) DMA memory.
> The proper way to enforce this on Linux is to call dma_rmb() (resp.
> dma_wmb()).
> 
> Signed-off-by: Regis Duchesne 
> Acked-by: Ronak Doshi 

Applied and queued up for -stable.


Re: [PATCH net 1/2] vmxnet3: set the DMA mask before the first DMA map operation

2018-05-14 Thread David Miller
From: 
Date: Mon, 14 May 2018 08:28:26 -0400

> The DMA mask must be set before, not after, the first DMA map operation, or
> the first DMA map operation could in theory fail on some systems.
> 
> Fixes: b0eb57cb97e78 ("VMXNET3: Add support for virtual IOMMU")
> Signed-off-by: Regis Duchesne 
> Acked-by: Ronak Doshi 

Applied and queued up for -stable.


Re: [PATCH] scsi: esas2r: fix spelling mistake: "requestss" -> "requests"

2018-05-14 Thread Martin K. Petersen

Colin,

> Trivial fix to spelling mistake in esas2r_debug message

Applied to 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


  1   2   3   4   5   6   7   8   9   10   >