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

[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)) {
> 

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

[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()

[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

[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 v3 3/8] PCI: Rename device node parameter of of_pci_get_host_bridge_resources()

[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

[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, ,
+   );
if (ret)
return ret;
 
diff --git a/drivers/pci/host/pcie-altera.c 

[PATCH] cpufreq: add imx8mq-cpufreq driver

[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;
+
+   

[PATCH] cpufreq: add imx8mq-cpufreq driver

[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;
+
+   return ret;
+}
+

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

[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

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

[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

[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 v3 4/6] ALSA: xen-front: Implement handling of shared buffers

[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()

[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: [PATCH v5 11/13] mm: Iterate only over charged shrinkers during memcg shrink_slab()

[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 gfp_mask, int nid,
>  

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

[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
>

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

[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)/

[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

[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: Put generated linker scripts to $(obj)/

[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

[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

[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

[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
* 

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

[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

[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
* ltp-fs_bind-tests - pass: 2
* 

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

[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 v4 0/4] ALSA: usb: UAC3 new features.

[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

[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 4.14 00/62] 4.14.41-stable review

[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
* ltp-cap_bounds-tests - pass: 2,
* 

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

[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 

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

[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 SEC("maps") decoder_state_map 

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

[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

[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

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

[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;
}
 
return NULL;

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

[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()

[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

[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: CONFIG_KCOV causing crash in svm_vcpu_run()

[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

[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:~#

Best Regards
-Anand

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

[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 4.16 00/72] 4.16.9-stable review

[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
* ltp-fs_bind-tests - pass: 2
* 

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

[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 3/4] media: rc bpf: move ir_raw_event to uapi

[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

[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)
> +   

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

[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)
> +   return -EINVAL;
> +
> +   

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

[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] x86: add the flag -fno-reorder-blocks-and-partition

[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

[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

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

[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?

[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: printk feature for syzbot?

[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

[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: possible deadlock in sk_diag_fill

[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

[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

[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 v9 06/11] arm64: kexec_file: allow for loading Image-format kernel

[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

[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

[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 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[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

[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

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

[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

[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(+)

[git pull] drm fix for mmap regression

[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

[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 v1 1/4] media: rc: introduce BPF_PROG_IR_DECODER

[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 bpf_insn_access_aux *info)
> +{
> +   if (type == 

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

[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] driver core: Respect all error codes from dev_pm_domain_attach()

[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

[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 v7] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

[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

[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

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

[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

[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 v2] arm64: dts: qcom: sdm845: Sort nodes in the reserved mem by address

[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

[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] vsprintf: Add command line option debug_boot_weak_hash

[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

[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

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

[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

[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: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

[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

[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: cpu stopper threads and load balancing leads to deadlock

[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

[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] media: dvb-frontends: add Socionext SC1501A ISDB-S/T demodulator driver

[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

[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] rcu: Report a quiescent state of TASKS_RCU on a tick from user

[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

[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 14/14] dt: qcom: Add qcom-cpufreq-kryo driver configuration

[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

[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 v6 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

[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

[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

[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] rcu: Report a quiescent state of TASKS_RCU on a tick from user

[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

[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

[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 v5 10/13] mm: Set bit in memcg shrinker bitmap on first list_lru item apearance

[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

[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 11/14] dt: qcom: Add SAW regulator for 8x96 CPUs

[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

[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

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

[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

[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>;
-

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

[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>;
-   };
-
-   apss_shared: