4.9.129-stable review

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/emulex/benet/be_cmds.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/emulex/benet/be_cmds.c +1 -1

@@ -4500,7 +4500,7 @@ int be_cmd_get_profile_config(struct be_
 				port_res->max_vfs += le16_to_cpu(pcie->num_vfs);
 			}
 		}
-		return status;
+		goto err;
 	}
 
 	pcie = be_get_pcie_desc(resp->func_param, desc_count,

Greg Kroah-Hartman

author maintainer

2018-09-24 11:59 UTC #2 lore raw

PATCH 2/111 rds: fix two RCU related problems

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Cong Wang <[email protected]>

[ Upstream commit cc4dfb7f70a344f24c1c71e298deea0771dadcb2 ]

When a rds sock is bound, it is inserted into the bind_hash_table which is protected by RCU. But when releasing rds sock, after it is removed from this hash table, it is freed immediately without respecting RCU grace period. This could cause some use-after-free as reported by syzbot.

Mark the rds sock with SOCK_RCU_FREE before inserting it into the bind_hash_table, so that it would be always freed after a RCU grace period.

The other problem is in rds_find_bound(), the rds sock could be freed in between rhashtable_lookup_fast() and rds_sock_addref(), so we need to extend RCU read lock protection in rds_find_bound() to close this race condition.

Reported-and-tested-by [email protected]

Reported-by [email protected]

Cc Sowmini Varadhan <[email protected]>

Cc Santosh Shilimkar <[email protected]>

Signed-off-by Cong Wang <[email protected]>

Acked-by Santosh Shilimkar <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/rds/bind.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

net/rds/bind.c +4 -1

@@ -60,11 +60,13 @@ struct rds_sock *rds_find_bound(__be32 a
 	u64 key = ((u64)addr << 32) | port;
 	struct rds_sock *rs;
 
-	rs = rhashtable_lookup_fast(&bind_hash_table, &key, ht_parms);
+	rcu_read_lock();
+	rs = rhashtable_lookup(&bind_hash_table, &key, ht_parms);
 	if (rs && !sock_flag(rds_rs_to_sk(rs), SOCK_DEAD))
 		rds_sock_addref(rs);
 	else
 		rs = NULL;
+	rcu_read_unlock();
 
 	rdsdebug("returning rs %p for %pI4:%u\n", rs, &addr,
 		ntohs(port));

@@ -157,6 +159,7 @@ int rds_bind(struct socket *sock, struct
 		goto out;
 	}
 
+	sock_set_flag(sk, SOCK_RCU_FREE);
 	ret = rds_add_bound(rs, sin->sin_addr.s_addr, &sin->sin_port);
 	if (ret)
 		goto out;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:00 UTC #3 lore raw

PATCH 3/111 net/mlx5: Fix use-after-free in self-healing flow

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jack Morgenstein <[email protected]>

[ Upstream commit 76d5581c870454be5f1f1a106c57985902e7ea20 ]

When the mlx5 health mechanism detects a problem while the driver is in the middle of init_one or remove_one, the driver needs to prevent the health mechanism from scheduling future work; if future work is scheduled, there is a problem with use-after-free: the system WQ tries to run the work item (which has been freed) at the scheduled future time.

Prevent this by disabling work item scheduling in the health mechanism when the driver is in the middle of init_one() or remove_one().

Fixes e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")

Signed-off-by Jack Morgenstein <[email protected]>

Reviewed-by Feras Daoud <[email protected]>

Signed-off-by Saeed Mahameed <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx5/core/health.c |   10 +++++++++-
 drivers/net/ethernet/mellanox/mlx5/core/main.c   |    4 ++--
 include/linux/mlx5/driver.h                      |    2 +-
 3 files changed, 12 insertions(+), 4 deletions(-)

drivers/net/ethernet/mellanox/mlx5/core/health.c +9 -1

@@ -339,9 +339,17 @@ void mlx5_start_health_poll(struct mlx5_
 	add_timer(&health->timer);
 }
 
-void mlx5_stop_health_poll(struct mlx5_core_dev *dev)
+void mlx5_stop_health_poll(struct mlx5_core_dev *dev, bool disable_health)
 {
 	struct mlx5_core_health *health = &dev->priv.health;
+	unsigned long flags;
+
+	if (disable_health) {
+		spin_lock_irqsave(&health->wq_lock, flags);
+		set_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags);
+		set_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags);
+		spin_unlock_irqrestore(&health->wq_lock, flags);
+	}
 
 	del_timer_sync(&health->timer);
 }

drivers/net/ethernet/mellanox/mlx5/core/main.c +2 -2

@@ -1130,7 +1130,7 @@ err_cleanup_once:
 		mlx5_cleanup_once(dev);
 
 err_stop_poll:
-	mlx5_stop_health_poll(dev);
+	mlx5_stop_health_poll(dev, boot);
 	if (mlx5_cmd_teardown_hca(dev)) {
 		dev_err(&dev->pdev->dev, "tear_down_hca failed, skip cleanup\n");
 		goto out_err;

@@ -1187,7 +1187,7 @@ static int mlx5_unload_one(struct mlx5_c
 	mlx5_disable_msix(dev);
 	if (cleanup)
 		mlx5_cleanup_once(dev);
-	mlx5_stop_health_poll(dev);
+	mlx5_stop_health_poll(dev, cleanup);
 	err = mlx5_cmd_teardown_hca(dev);
 	if (err) {
 		dev_err(&dev->pdev->dev, "tear_down_hca failed, skip cleanup\n");

include/linux/mlx5/driver.h +1 -1

@@ -786,7 +786,7 @@ void mlx5_unmap_free_uar(struct mlx5_cor
 void mlx5_health_cleanup(struct mlx5_core_dev *dev);
 int mlx5_health_init(struct mlx5_core_dev *dev);
 void mlx5_start_health_poll(struct mlx5_core_dev *dev);
-void mlx5_stop_health_poll(struct mlx5_core_dev *dev);
+void mlx5_stop_health_poll(struct mlx5_core_dev *dev, bool disable_health);
 void mlx5_drain_health_wq(struct mlx5_core_dev *dev);
 void mlx5_drain_health_recovery(struct mlx5_core_dev *dev);
 int mlx5_buf_alloc_node(struct mlx5_core_dev *dev, int size,

Greg Kroah-Hartman

author maintainer

2018-09-24 12:00 UTC #4 lore raw

PATCH 4/111 net/mlx5: Fix debugfs cleanup in the device init/remove flow

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jack Morgenstein <[email protected]>

[ Upstream commit 5df816e7f43f1297c40021ef17ec6e722b45c82f ]

When initializing the device (procedure init_one), the driver calls mlx5_pci_init to perform pci initialization. As part of this initialization, mlx5_pci_init creates a debugfs directory. If this creation fails, init_one aborts, returning failure to the caller (which is the probe method caller).

The main reason for such a failure to occur is if the debugfs directory already exists. This can happen if the last time mlx5_pci_close was called, debugfs_remove (silently) failed due to the debugfs directory not being empty.

Guarantee that such a debugfs_remove failure will not occur by instead calling debugfs_remove_recursive in procedure mlx5_pci_close.

Fixes 59211bd3b632 ("net/mlx5: Split the load/unload flow into hardware and software flows")

Signed-off-by Jack Morgenstein <[email protected]>

Reviewed-by Daniel Jurgens <[email protected]>

Signed-off-by Saeed Mahameed <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx5/core/main.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/net/ethernet/mellanox/mlx5/core/main.c +4 -2

@@ -787,8 +787,10 @@ static int mlx5_pci_init(struct mlx5_cor
 	priv->numa_node = dev_to_node(&dev->pdev->dev);
 
 	priv->dbg_root = debugfs_create_dir(dev_name(&pdev->dev), mlx5_debugfs_root);
-	if (!priv->dbg_root)
+	if (!priv->dbg_root) {
+		dev_err(&pdev->dev, "Cannot create debugfs dir, aborting\n");
 		return -ENOMEM;
+	}
 
 	err = mlx5_pci_enable_device(dev);
 	if (err) {

@@ -837,7 +839,7 @@ static void mlx5_pci_close(struct mlx5_c
 	pci_clear_master(dev->pdev);
 	release_bar(dev->pdev);
 	mlx5_pci_disable_device(dev);
-	debugfs_remove(priv->dbg_root);
+	debugfs_remove_recursive(priv->dbg_root);
 }
 
 static int mlx5_init_once(struct mlx5_core_dev *dev, struct mlx5_priv *priv)

Greg Kroah-Hartman

author maintainer

2018-09-24 12:00 UTC #5 lore raw

PATCH 5/111 iommu/arm-smmu-v3: sync the OVACKFLG to PRIQ consumer register

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Miao Zhong <[email protected]>

[ Upstream commit 0d535967ac658966c6ade8f82b5799092f7d5441 ]

When PRI queue occurs overflow, driver should update the OVACKFLG to the PRIQ consumer register, otherwise subsequent PRI requests will not be processed.

Cc Will Deacon <[email protected]>

Cc Robin Murphy <[email protected]>

Signed-off-by Miao Zhong <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iommu/arm-smmu-v3.c |    1 +
 1 file changed, 1 insertion(+)

drivers/iommu/arm-smmu-v3.c +1 -0

@@ -1233,6 +1233,7 @@ static irqreturn_t arm_smmu_priq_thread(
 
 	/* Sync our overflow flag, as we believe we're up to speed */
 	q->cons = Q_OVF(q, q->prod) | Q_WRP(q, q->cons) | Q_IDX(q, q->cons);
+	writel(q->cons, q->cons_reg);
 	return IRQ_HANDLED;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 11:51 UTC #6 lore raw

PATCH 6/111 ALSA: msnd: Fix the default sample sizes

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <[email protected]>

[ Upstream commit 7c500f9ea139d0c9b80fdea5a9c911db3166ea54 ]

The default sample sizes set by msnd driver are bogus; it sets ALSA PCM format, not the actual bit width.

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/isa/msnd/msnd_pinnacle.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

sound/isa/msnd/msnd_pinnacle.c +2 -2

@@ -82,10 +82,10 @@
 
 static void set_default_audio_parameters(struct snd_msnd *chip)
 {
-	chip->play_sample_size = DEFSAMPLESIZE;
+	chip->play_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
 	chip->play_sample_rate = DEFSAMPLERATE;
 	chip->play_channels = DEFCHANNELS;
-	chip->capture_sample_size = DEFSAMPLESIZE;
+	chip->capture_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
 	chip->capture_sample_rate = DEFSAMPLERATE;
 	chip->capture_channels = DEFCHANNELS;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 12:00 UTC #7 lore raw

PATCH 7/111 ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <[email protected]>

[ Upstream commit bd1cd0eb2ce9141100628d476ead4de485501b29 ]

AU0828_DEVICE() macro in quirks-table.h uses USB_DEVICE_VENDOR_SPEC() for expanding idVendor and idProduct fields. However, the latter macro adds also match_flags and bInterfaceClass, which are different from the values AU0828_DEVICE() macro sets after that.

For fixing them, just expand idVendor and idProduct fields manually in AU0828_DEVICE().

This fixes sparse warnings like:
sound/usb/quirks-table.h:2892:1: warning: Initializer entry defined twice

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/usb/quirks-table.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

sound/usb/quirks-table.h +2 -1

@@ -2875,7 +2875,8 @@ YAMAHA_DEVICE(0x7010, "UB99"),
  */
 
 #define AU0828_DEVICE(vid, pid, vname, pname) { \
-	USB_DEVICE_VENDOR_SPEC(vid, pid), \
+	.idVendor = vid, \
+	.idProduct = pid, \
 	.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
 		       USB_DEVICE_ID_MATCH_INT_CLASS | \
 		       USB_DEVICE_ID_MATCH_INT_SUBCLASS, \

Greg Kroah-Hartman

author maintainer

2018-09-24 11:51 UTC #8 lore raw

PATCH 8/111 xfrm: fix passing zero to ERR_PTR() warning

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: YueHaibing <[email protected]>

[ Upstream commit 934ffce1343f22ed5e2d0bd6da4440f4848074de ]

Fix a static code checker warning:

net/xfrm/xfrm_policy.c:1836 xfrm_resolve_and_create_bundle() warn: passing zero to 'ERR_PTR'

xfrm_tmpl_resolve return 0 just means no xdst found, return NULL instead of passing zero to ERR_PTR.

Fixes d809ec895505 ("xfrm: do not assume that template resolving always returns xfrms")

Signed-off-by YueHaibing <[email protected]>

Signed-off-by Steffen Klassert <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/xfrm/xfrm_policy.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

net/xfrm/xfrm_policy.c +4 -1

@@ -1873,7 +1873,10 @@ xfrm_resolve_and_create_bundle(struct xf
 	/* Try to instantiate a bundle */
 	err = xfrm_tmpl_resolve(pols, num_pols, fl, xfrm, family);
 	if (err <= 0) {
-		if (err != 0 && err != -EAGAIN)
+		if (err == 0)
+			return NULL;
+
+		if (err != -EAGAIN)
 			XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTPOLERROR);
 		return ERR_PTR(err);
 	}

Greg Kroah-Hartman

author maintainer

2018-09-24 11:51 UTC #9 lore raw

PATCH 9/111 gfs2: Special-case rindex for gfs2_grow

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andreas Gruenbacher <[email protected]>

[ Upstream commit 776125785a87ff05d49938bd5b9f336f2a05bff6 ]

To speed up the common case of appending to a file, gfs2_write_alloc_required presumes that writing beyond the end of a file will always require additional blocks to be allocated. This assumption is incorrect for preallocates files, but there are no negative consequences as long as *some* space is still left on the filesystem.

One special file that always has some space preallocated beyond the end of the file is the rindex: when growing a filesystem, gfs2_grow adds one or more new resource groups and appends records describing those resource groups to the rindex; the preallocated space ensures that this is always possible.

However, when a filesystem is completely full, gfs2_write_alloc_required will indicate that an additional allocation is required, and appending the next record to the rindex will fail even though space for that record has already been preallocated. To fix that, skip the incorrect optimization in gfs2_write_alloc_required, but for the rindex only. Other writes to preallocated space beyond the end of the file are still allowed to fail on completely full filesystems.

Signed-off-by Andreas Gruenbacher <[email protected]>

Reviewed-by Bob Peterson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/gfs2/bmap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/gfs2/bmap.c +1 -1

@@ -1472,7 +1472,7 @@ int gfs2_write_alloc_required(struct gfs
 	end_of_file = (i_size_read(&ip->i_inode) + sdp->sd_sb.sb_bsize - 1) >> shift;
 	lblock = offset >> shift;
 	lblock_stop = (offset + len + sdp->sd_sb.sb_bsize - 1) >> shift;
-	if (lblock_stop > end_of_file)
+	if (lblock_stop > end_of_file && ip != GFS2_I(sdp->sd_rindex))
 		return 1;
 
 	size = (lblock_stop - lblock) << shift;

Greg Kroah-Hartman

author maintainer

2018-09-24 11:58 UTC #10 lore raw

PATCH 10/111 clk: imx6ul: fix missing of_node_put()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nicholas Mc Guire <[email protected]>

[ Upstream commit 11177e7a7aaef95935592072985526ebf0a3df43 ]

of_find_compatible_node() is returning a device node with refcount incremented and must be explicitly decremented after the last use which is right after the us in of_iomap() here.

Signed-off-by Nicholas Mc Guire <[email protected]>

Fixes 787b4271a6a0 ("clk: imx: add imx6ul clk tree support")

Signed-off-by Stephen Boyd <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/clk/imx/clk-imx6ul.c |    1 +
 1 file changed, 1 insertion(+)

drivers/clk/imx/clk-imx6ul.c +1 -0

@@ -120,6 +120,7 @@ static void __init imx6ul_clocks_init(st
 
 	np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-anatop");
 	base = of_iomap(np, 0);
+	of_node_put(np);
 	WARN_ON(!base);
 
 	clks[IMX6UL_PLL1_BYPASS_SRC] = imx_clk_mux("pll1_bypass_src", base + 0x00, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));

Greg Kroah-Hartman

author maintainer

2018-09-24 11:59 UTC #11 lore raw

PATCH 11/111 clk: clk-fixed-factor: Clear OF_POPULATED flag in case of failure

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Rajan Vaja <[email protected]>

[ Upstream commit f6dab4233d6b64d719109040503b567f71fbfa01 ]

Fixed factor clock has two initializations at of_clk_init() time and during platform driver probe. Before of_clk_init() call, node is marked as populated and so its probe never gets called.

During of_clk_init() fixed factor clock registration may fail if any of its parent clock is not registered. In this case, it doesn't get chance to retry registration from probe. Clear OF_POPULATED flag if fixed factor clock registration fails so that clock registration is attempted again from probe.

Signed-off-by Rajan Vaja <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/clk/clk-fixed-factor.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

drivers/clk/clk-fixed-factor.c +8 -1

@@ -177,8 +177,15 @@ static struct clk *_of_fixed_factor_clk_
 
 	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, flags,
 					mult, div);
-	if (IS_ERR(clk))
+	if (IS_ERR(clk)) {
+		/*
+		 * If parent clock is not registered, registration would fail.
+		 * Clear OF_POPULATED flag so that clock registration can be
+		 * attempted again from probe function.
+		 */
+		of_node_clear_flag(node, OF_POPULATED);
 		return clk;
+	}
 
 	ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
 	if (ret) {

Greg Kroah-Hartman

author maintainer

2018-09-24 11:59 UTC #12 lore raw

PATCH 12/111 kbuild: add .DELETE_ON_ERROR special target

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Masahiro Yamada <[email protected]>

[ Upstream commit 9c2af1c7377a8a6ef86e5cabf80978f3dbbb25c0 ]

If Make gets a fatal signal while a shell is executing, it may delete the target file that the recipe was supposed to update. This is needed to make sure that it is remade from scratch when Make is next run; if Make is interrupted after the recipe has begun to write the target file, it results in an incomplete file whose time stamp is newer than that of the prerequisites files. Make automatically deletes the incomplete file on interrupt unless the target is marked .PRECIOUS.

The situation is just the same as when the shell fails for some reasons. Usually when a recipe line fails, if it has changed the target file at all, the file is corrupted, or at least it is not completely updated. Yet the file’s time stamp says that it is now up to date, so the next time Make runs, it will not try to update that file.

However, Make does not cater to delete the incomplete target file in this case. We need to add .DELETE_ON_ERROR somewhere in the Makefile to request it.

scripts/Kbuild.include seems a suitable place to add it because it is included from almost all sub-makes.

Please note .DELETE_ON_ERROR is not effective for phony targets.

The external module building should never ever touch the kernel tree. The following recipe fails if include/generated/autoconf.h is missing. However, include/config/auto.conf is not deleted since it is a phony target.

PHONY += include/config/auto.conf

include/config/auto.conf:

         $(Q)test -e include/generated/autoconf.h -a -e $@ || (          \
         echo >&2;                                                       \
         echo >&2 "  ERROR: Kernel configuration is invalid.";           \
         echo >&2 "         include/generated/autoconf.h or $@ are missing.";\
         echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it."; \
         echo >&2 ;                                                      \
         /bin/false)

Signed-off-by Masahiro Yamada <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 scripts/Kbuild.include |    3 +++
 1 file changed, 3 insertions(+)

scripts/Kbuild.include +3 -0

@@ -394,3 +394,6 @@ endif
 endef
 #
 ###############################################################################
+
+# delete partially updated (i.e. corrupted) files on error
+.DELETE_ON_ERROR:

Greg Kroah-Hartman

author maintainer

2018-09-24 11:51 UTC #13 lore raw

PATCH 13/111 media: tw686x: Fix oops on buffer alloc failure

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Krzysztof Ha?asa <[email protected]>

[ Upstream commit 5a1a2f63d840dc2631505b607e11ff65ac1b7d3c ]

The error path currently calls tw686x_video_free() which requires vc->dev to be initialized, causing a NULL dereference on uninitizalized channels.

Fix this by setting the vc->dev fields for all the channels first.

Fixes f8afaa8dbc0d ("[media] tw686x: Introduce an interface to support multiple DMA modes")

Signed-off-by Krzysztof Ha?asa <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/pci/tw686x/tw686x-video.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

drivers/media/pci/tw686x/tw686x-video.c +8 -3

@@ -1190,6 +1190,14 @@ int tw686x_video_init(struct tw686x_dev
 			return err;
 	}
 
+	/* Initialize vc->dev and vc->ch for the error path */
+	for (ch = 0; ch < max_channels(dev); ch++) {
+		struct tw686x_video_channel *vc = &dev->video_channels[ch];
+
+		vc->dev = dev;
+		vc->ch = ch;
+	}
+
 	for (ch = 0; ch < max_channels(dev); ch++) {
 		struct tw686x_video_channel *vc = &dev->video_channels[ch];
 		struct video_device *vdev;

@@ -1198,9 +1206,6 @@ int tw686x_video_init(struct tw686x_dev
 		spin_lock_init(&vc->qlock);
 		INIT_LIST_HEAD(&vc->vidq_queued);
 
-		vc->dev = dev;
-		vc->ch = ch;
-
 		/* default settings */
 		err = tw686x_set_standard(vc, V4L2_STD_NTSC);
 		if (err)

Greg Kroah-Hartman

author maintainer

2018-09-24 11:59 UTC #14 lore raw

PATCH 14/111 dmaengine: pl330: fix irq race with terminate_all

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: John Keeping <[email protected]>

[ Upstream commit e49756544a21f5625b379b3871d27d8500764670 ]

In pl330_update() when checking if a channel has been aborted, the channel's lock is not taken, only the overall pl330_dmac lock. But in pl330_terminate_all() the aborted flag (req_running==-1) is set under the channel lock and not the pl330_dmac lock.

With threaded interrupts, this leads to a potential race:

    pl330_terminate_all	        pl330_update
    -------------------         ------------
    lock channel
                                entry
    lock pl330
    _stop channel
    unlock pl330
                                lock pl330
                                check req_running != -1
    req_running = -1
                                _start channel

Signed-off-by John Keeping <[email protected]>

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/dma/pl330.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/dma/pl330.c +3 -2

@@ -2167,13 +2167,14 @@ static int pl330_terminate_all(struct dm
 
 	pm_runtime_get_sync(pl330->ddma.dev);
 	spin_lock_irqsave(&pch->lock, flags);
+
 	spin_lock(&pl330->lock);
 	_stop(pch->thread);
-	spin_unlock(&pl330->lock);
-
 	pch->thread->req[0].desc = NULL;
 	pch->thread->req[1].desc = NULL;
 	pch->thread->req_running = -1;
+	spin_unlock(&pl330->lock);
+
 	power_down = pch->active;
 	pch->active = false;

Greg Kroah-Hartman

author maintainer

2018-09-24 11:59 UTC #15 lore raw

PATCH 15/111 MIPS: ath79: fix system restart

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Felix Fietkau <[email protected]>

[ Upstream commit f8a7bfe1cb2c1ebfa07775c9c8ac0ad3ba8e5ff5 ]

This patch disables irq on reboot to fix hang issues that were observed due to pending interrupts.

Signed-off-by Felix Fietkau <[email protected]>

Signed-off-by John Crispin <[email protected]>

Signed-off-by Paul Burton <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/19913/

Cc James Hogan <[email protected]>

Cc Ralf Baechle <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/ath79/setup.c                  |    1 +
 arch/mips/include/asm/mach-ath79/ath79.h |    1 +
 2 files changed, 2 insertions(+)

arch/mips/ath79/setup.c +1 -0

@@ -40,6 +40,7 @@ static char ath79_sys_type[ATH79_SYS_TYP
 
 static void ath79_restart(char *command)
 {
+	local_irq_disable();
 	ath79_device_reset_set(AR71XX_RESET_FULL_CHIP);
 	for (;;)
 		if (cpu_wait)

arch/mips/include/asm/mach-ath79/ath79.h +1 -0

@@ -134,6 +134,7 @@ static inline u32 ath79_pll_rr(unsigned
 static inline void ath79_reset_wr(unsigned reg, u32 val)
 {
 	__raw_writel(val, ath79_reset_base + reg);
+	(void) __raw_readl(ath79_reset_base + reg); /* flush */
 }
 
 static inline u32 ath79_reset_rr(unsigned reg)

Greg Kroah-Hartman

author maintainer

2018-09-24 11:59 UTC #16 lore raw

PATCH 16/111 media: videobuf2-core: check for q->error in vb2_core_qbuf()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans Verkuil <[email protected]>

[ Upstream commit b509d733d337417bcb7fa4a35be3b9a49332b724 ]

The vb2_core_qbuf() function didn't check if q->error was set. It is checked in __buf_prepare(), but that function isn't called if the buffer was already prepared before with VIDIOC_PREPARE_BUF.

So check it at the start of vb2_core_qbuf() as well.

Signed-off-by Hans Verkuil <[email protected]>

Acked-by Sakari Ailus <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/v4l2-core/videobuf2-core.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/media/v4l2-core/videobuf2-core.c +5 -0

@@ -1375,6 +1375,11 @@ int vb2_core_qbuf(struct vb2_queue *q, u
 	struct vb2_buffer *vb;
 	int ret;
 
+	if (q->error) {
+		dprintk(1, "fatal error occurred on queue\n");
+		return -EIO;
+	}
+
 	vb = q->bufs[index];
 
 	switch (vb->state) {

Greg Kroah-Hartman

author maintainer

2018-09-24 11:51 UTC #17 lore raw

PATCH 17/111 IB/rxe: Drop QP0 silently

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zhu Yanjun <[email protected]>

[ Upstream commit 536ca245c512aedfd84cde072d7b3ca14b6e1792 ]

According to "Annex A16: RDMA over Converged Ethernet (RoCE)":

A16.4.3 MANAGEMENT INTERFACES

As defined in the base specification, a special Queue Pair, QP0 is defined solely for communication between subnet manager(s) and subnet management agents. Since such an IB-defined subnet management architecture is outside the scope of this annex, it follows that there is also no requirement that a port which conforms to this annex be associated with a QP0. Thus, for end nodes designed to conform to this annex, the concept of QP0 is undefined and unused for any port connected to an Ethernet network.

CA16-8: A packet arriving at a RoCE port containing a BTH with the destination QP field set to QP0 shall be silently dropped.

Signed-off-by Zhu Yanjun <[email protected]>

Acked-by Moni Shoua <[email protected]>

Reviewed-by Yuval Shaia <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/sw/rxe/rxe_recv.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

drivers/infiniband/sw/rxe/rxe_recv.c +7 -2

@@ -225,9 +225,14 @@ static int hdr_check(struct rxe_pkt_info
 		goto err1;
 	}
 
+	if (unlikely(qpn == 0)) {
+		pr_warn_once("QP 0 not supported");
+		goto err1;
+	}
+
 	if (qpn != IB_MULTICAST_QPN) {
-		index = (qpn == 0) ? port->qp_smi_index :
-			((qpn == 1) ? port->qp_gsi_index : qpn);
+		index = (qpn == 1) ? port->qp_gsi_index : qpn;
+
 		qp = rxe_pool_get_index(&rxe->qp_pool, index);
 		if (unlikely(!qp)) {
 			pr_warn_ratelimited("no qp matches qpn 0x%x\n", qpn);

Greg Kroah-Hartman

author maintainer

2018-09-24 11:51 UTC #18 lore raw

PATCH 18/111 mtd/maps: fix solutionengine.c printk format warnings

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Randy Dunlap <[email protected]>

[ Upstream commit 1d25e3eeed1d987404e2d2e451eebac8c15cecc1 ]

Fix 2 printk format warnings (this driver is currently only used by arch/sh/) by using "%pap" instead of "%lx".

Fixes these build warnings:

../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka 'unsigned int'} [-Wformat=] ../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",

                                                  ~~~~^
                                                  %08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka 'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
  printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
                                                                    ~~~~^
                                                                    %08x

Cc David Woodhouse <[email protected]>

Cc Brian Norris <[email protected]>

Cc Boris Brezillon <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Richard Weinberger <[email protected]>

Cc Yoshinori Sato <[email protected]>

Cc Rich Felker <[email protected]>

Cc Sergei Shtylyov <[email protected]>

Signed-off-by Randy Dunlap <[email protected]>

Signed-off-by Boris Brezillon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mtd/maps/solutionengine.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/mtd/maps/solutionengine.c +3 -3

@@ -59,9 +59,9 @@ static int __init init_soleng_maps(void)
 			return -ENXIO;
 		}
 	}
-	printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
-	       soleng_flash_map.phys & 0x1fffffff,
-	       soleng_eprom_map.phys & 0x1fffffff);
+	printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at 0x%pap\n",
+	       &soleng_flash_map.phys,
+	       &soleng_eprom_map.phys);
 	flash_mtd->owner = THIS_MODULE;
 
 	eprom_mtd = do_map_probe("map_rom", &soleng_eprom_map);

Greg Kroah-Hartman

author maintainer

2018-09-24 11:51 UTC #19 lore raw

PATCH 19/111 perf test: Fix subtest number when showing results

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Richter <[email protected]>

[ Upstream commit 9ef0112442bdddef5fb55adf20b3a5464b33de75 ]

Perf test 40 for example has several subtests numbered 1-4 when displaying the start of the subtest. When the subtest results are displayed the subtests are numbered 0-3.

Use this command to generate trace output:

[root@s35lp76 perf]# ./perf test -Fv 40 2>/tmp/bpf1

Fix this by adjusting the subtest number when show the subtest result.

Output before:

[root@s35lp76 perf]# egrep '(^40\.[0-4]| subtest [0-4]:)' /tmp/bpf1
40.1: Basic BPF filtering :
BPF filter subtest 0: Ok
40.2: BPF pinning :
BPF filter subtest 1: Ok
40.3: BPF prologue generation :
BPF filter subtest 2: Ok
40.4: BPF relocation checker :
BPF filter subtest 3: Ok
[root@s35lp76 perf]#

Output after:

root@s35lp76 ~]# egrep '(^40\.[0-4]| subtest [0-4]:)' /tmp/bpf1
40.1: Basic BPF filtering :
BPF filter subtest 1: Ok
40.2: BPF pinning :
BPF filter subtest 2: Ok
40.3: BPF prologue generation :
BPF filter subtest 3: Ok
40.4: BPF relocation checker :
BPF filter subtest 4: Ok
[root@s35lp76 ~]#

Signed-off-by Thomas Richter <[email protected]>

Reviewed-by Hendrik Brueckner <[email protected]>

Cc Heiko Carstens <[email protected]>

Cc Martin Schwidefsky <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/perf/tests/builtin-test.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/perf/tests/builtin-test.c +1 -1

@@ -413,7 +413,7 @@ static int __cmd_test(int argc, const ch
 			for (subi = 0; subi < subn; subi++) {
 				pr_info("%2d.%1d: %-*s:", i, subi + 1, subw,
 					t->subtest.get_desc(subi));
-				err = test_and_print(t, skip, subi);
+				err = test_and_print(t, skip, subi + 1);
 				if (err != TEST_OK && t->subtest.skip_if_fail)
 					skip = true;
 			}

Greg Kroah-Hartman

author maintainer

2018-09-24 11:59 UTC #20 lore raw

PATCH 20/111 gfs2: Dont reject a supposedly full bitmap if we have blocks reserved

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bob Peterson <[email protected]>

[ Upstream commit e79e0e1428188b24c3b57309ffa54a33c4ae40c4 ]

Before this patch, you could get into situations like this:

1. Process 1 searches for X free blocks, finds them, makes a reservation
2. Process 2 searches for free blocks in the same rgrp, but now the bitmap is full because process 1's reservation is skipped over. So it marks the bitmap as GBF_FULL.
3. Process 1 tries to allocate blocks from its own reservation, but since the GBF_FULL bit is set, it skips over the rgrp and searches elsewhere, thus not using its own reservation.

This patch adds an additional check to allow processes to use their own reservations.

Signed-off-by Bob Peterson <[email protected]>

Signed-off-by Andreas Gruenbacher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/gfs2/rgrp.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

fs/gfs2/rgrp.c +2 -1

@@ -1675,7 +1675,8 @@ static int gfs2_rbm_find(struct gfs2_rbm
 
 	while(1) {
 		bi = rbm_bi(rbm);
-		if (test_bit(GBF_FULL, &bi->bi_flags) &&
+		if ((ip == NULL || !gfs2_rs_active(&ip->i_res)) &&
+		    test_bit(GBF_FULL, &bi->bi_flags) &&
 		    (state == GFS2_BLKST_FREE))
 			goto next_bitmap;

Greg Kroah-Hartman

author maintainer

2018-09-24 11:59 UTC #21 lore raw

PATCH 21/111 fbdev: omapfb: off by one in omapfb_register_client()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit 5ec1ec35b2979b59d0b33381e7c9aac17e159d16 ]

The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the

Quoted 1 line

should be >= or we are one element beyond the end of the array.

Fixes 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")

Cc Imre Deak <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/omap/omapfb_main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/video/fbdev/omap/omapfb_main.c +1 -1

@@ -956,7 +956,7 @@ int omapfb_register_client(struct omapfb
 {
 	int r;
 
-	if ((unsigned)omapfb_nb->plane_idx > OMAPFB_PLANE_NUM)
+	if ((unsigned)omapfb_nb->plane_idx >= OMAPFB_PLANE_NUM)
 		return -EINVAL;
 
 	if (!notifier_inited) {

Greg Kroah-Hartman

author maintainer

2018-09-24 11:59 UTC #22 lore raw

PATCH 22/111 video: goldfishfb: fix memory leak on driver remove

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Anton Vasilyev <[email protected]>

[ Upstream commit 5958fde72d04e7b8c6de3669d1f794a90997e3eb ]

goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does not have deallocation of fb, which leads to memory leak on probe/remove.

The patch adds deallocation into goldfish_fb_remove().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by Anton Vasilyev <[email protected]>

Cc Aleksandar Markovic <[email protected]>

Cc Miodrag Dinic <[email protected]>

Cc Goran Ferenc <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/goldfishfb.c |    1 +
 1 file changed, 1 insertion(+)

drivers/video/fbdev/goldfishfb.c +1 -0

@@ -301,6 +301,7 @@ static int goldfish_fb_remove(struct pla
 	dma_free_coherent(&pdev->dev, framesize, (void *)fb->fb.screen_base,
 						fb->fb.fix.smem_start);
 	iounmap(fb->reg_base);
+	kfree(fb);
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 12:00 UTC #23 lore raw

PATCH 23/111 fbdev/via: fix defined but not used warning

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Randy Dunlap <[email protected]>

[ Upstream commit b6566b47a67e07fdca44cf51abb14e2fbe17d3eb ]

Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled by marking the unused function as __maybe_unused.

../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: 'viafb_sup_odev_proc_show' defined but not used [-Wunused-function]

Signed-off-by Randy Dunlap <[email protected]>

Cc Florian Tobias Schandinat <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/via/viafbdev.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/video/fbdev/via/viafbdev.c +2 -1

@@ -19,6 +19,7 @@
  * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
 
+#include <linux/compiler.h>
 #include <linux/module.h>
 #include <linux/seq_file.h>
 #include <linux/slab.h>

@@ -1468,7 +1469,7 @@ static const struct file_operations viaf
 
 #endif /* CONFIG_FB_VIA_DIRECT_PROCFS */
 
-static int viafb_sup_odev_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused viafb_sup_odev_proc_show(struct seq_file *m, void *v)
 {
 	via_odev_to_seq(m, supported_odev_map[
 		viaparinfo->shared->chip_info.gfx_chip_name]);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:00 UTC #24 lore raw

PATCH 24/111 perf powerpc: Fix callchain ip filtering when return address is in a register

Link http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandipan@linux.ibm.com open here

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sandipan Das <[email protected]>

[ Upstream commit 9068533e4f470daf2b0f29c71d865990acd8826e ]

For powerpc64, perf will filter out the second entry in the callchain, i.e. the LR value, if the return address of the function corresponding to the probed location has already been saved on its caller's stack.

The state of the return address is determined using debug information. At any point within a function, if the return address is already saved somewhere, a DWARF expression can tell us about its location. If the return address in still in LR only, no DWARF expression would exist.

Typically, the instructions in a function's prologue first copy the LR value to R0 and then pushes R0 on to the stack. If LR has already been copied to R0 but R0 is yet to be pushed to the stack, we can still get a DWARF expression that says that the return address is in R0. This is indicating that getting a DWARF expression for the return address does not guarantee the fact that it has already been saved on the stack.

This can be observed on a powerpc64le system running Fedora 27 as shown below.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  000000000015af20 <inet_pton>:
    15af20:       0b 00 4c 3c     addis   r2,r12,11
    15af24:       e0 c1 42 38     addi    r2,r2,-15904
    15af28:       a6 02 08 7c     mflr    r0
    15af2c:       f0 ff c1 fb     std     r30,-16(r1)
    15af30:       f8 ff e1 fb     std     r31,-8(r1)
    15af34:       78 1b 7f 7c     mr      r31,r3
    15af38:       78 23 83 7c     mr      r3,r4
    15af3c:       78 2b be 7c     mr      r30,r5
    15af40:       10 00 01 f8     std     r0,16(r1)
    15af44:       c1 ff 21 f8     stdu    r1,-64(r1)
    15af48:       28 00 81 f8     std     r4,40(r1)
  ...

  # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less
  ...
  00027024 0000000000000024 00027028 FDE cie=00000000 pc=000000000015af20..000000000015af88
     LOC           CFA      r30   r31   ra
  000000000015af20 r1+0     u     u     u
  000000000015af34 r1+0     c-16  c-8   r0
  000000000015af48 r1+64    c-16  c-8   c+16
  000000000015af5c r1+0     c-16  c-8   c+16
  000000000015af78 r1+0     u     u
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

ping 2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)

              7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
              7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                 12f152d70 _init+0xbfc (/usr/bin/ping)
              7fff7e1836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
              7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                         0 [unknown] ([unknown])

After:

ping 2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)

              7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
              7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
              7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                 12f152d70 _init+0xbfc (/usr/bin/ping)
              7fff7e1836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
              7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                         0 [unknown] ([unknown])

Reported-by Ravi Bangoria <[email protected]>

Signed-off-by Sandipan Das <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Maynard Johnson <[email protected]>

Cc Naveen N. Rao <[email protected]>

Cc Ravi Bangoria <[email protected]>

Cc Sukadev Bhattiprolu <[email protected]>

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

tools/perf/arch/powerpc/util/skip-callchain-idx.c +6 -2

@@ -58,9 +58,13 @@ static int check_return_reg(int ra_regno
 	}
 
 	/*
-	 * Check if return address is on the stack.
+	 * Check if return address is on the stack. If return address
+	 * is in a register (typically R0), it is yet to be saved on
+	 * the stack.
 	 */
-	if (nops != 0 || ops != NULL)
+	if ((nops != 0 || ops != NULL) &&
+		!(nops == 1 && ops[0].atom == DW_OP_regx &&
+			ops[0].number2 == 0 && ops[0].offset == 0))
 		return 0;
 
 	/*

Greg Kroah-Hartman

author maintainer

2018-09-24 12:00 UTC #25 lore raw

PATCH 25/111 video: fbdev: pxafb: clear allocated memory for video modes

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel Mack <[email protected]>

[ Upstream commit b951d80aaf224b1f774e10def672f5e37488e4ee ]

When parsing the video modes from DT properties, make sure to zero out memory before using it. This is important because not all fields in the mode struct are explicitly initialized, even though they are used later on.

Fixes 420a488278e86 ("video: fbdev: pxafb: initial devicetree conversion")

Reviewed-by Robert Jarzmik <[email protected]>

Signed-off-by Daniel Mack <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/pxafb.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/video/fbdev/pxafb.c +2 -2

@@ -2128,8 +2128,8 @@ static int of_get_pxafb_display(struct d
 		return -EINVAL;
 
 	ret = -ENOMEM;
-	info->modes = kmalloc_array(timings->num_timings,
-				    sizeof(info->modes[0]), GFP_KERNEL);
+	info->modes = kcalloc(timings->num_timings, sizeof(info->modes[0]),
+			      GFP_KERNEL);
 	if (!info->modes)
 		goto out;
 	info->num_modes = timings->num_timings;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:00 UTC #26 lore raw

PATCH 26/111 fbdev: Distinguish between interlaced and progressive modes

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Fredrik Noring <[email protected]>

[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]

I discovered the problem when developing a frame buffer driver for the PlayStation 2 (not yet merged), using the following video modes for the PlayStation 3 in drivers/video/fbdev/ps3fb.c:

    }, {
        /* 1080if */
        "1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
        FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
    }, {
        /* 1080pf */
        "1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
        FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
    },

In ps3fb_probe, the mode_option module parameter is used with fb_find_mode but it can only select the interlaced variant of 1920x1080 since the loop matching the modes does not take the difference between interlaced and progressive modes into account.

In short, without the patch, progressive 1920x1080 cannot be chosen as a mode_option parameter since fb_find_mode (falsely) thinks interlace is a perfect match.

Signed-off-by Fredrik Noring <[email protected]>

Cc "Maciej W. Rozycki" <[email protected]>

[b.zolnierkie: updated patch description]

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/core/modedb.c |   41 +++++++++++++++++++++++++++-----------
 1 file changed, 30 insertions(+), 11 deletions(-)

drivers/video/fbdev/core/modedb.c +30 ~~-11~~

@@ -644,7 +644,7 @@ static int fb_try_mode(struct fb_var_scr
  *
  *     Valid mode specifiers for @mode_option:
  *
- *     <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m] or
+ *     <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][p][m] or
  *     <name>[-<bpp>][@<refresh>]
  *
  *     with <xres>, <yres>, <bpp> and <refresh> decimal numbers and

@@ -653,10 +653,10 @@ static int fb_try_mode(struct fb_var_scr
  *      If 'M' is present after yres (and before refresh/bpp if present),
  *      the function will compute the timings using VESA(tm) Coordinated
  *      Video Timings (CVT).  If 'R' is present after 'M', will compute with
- *      reduced blanking (for flatpanels).  If 'i' is present, compute
- *      interlaced mode.  If 'm' is present, add margins equal to 1.8%
- *      of xres rounded down to 8 pixels, and 1.8% of yres. The char
- *      'i' and 'm' must be after 'M' and 'R'. Example:
+ *      reduced blanking (for flatpanels).  If 'i' or 'p' are present, compute
+ *      interlaced or progressive mode.  If 'm' is present, add margins equal
+ *      to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ *      'i', 'p' and 'm' must be after 'M' and 'R'. Example:
  *
  *      1024x768MR-8@60m - Reduced blank with margins at 60Hz.
  *

@@ -697,7 +697,8 @@ int fb_find_mode(struct fb_var_screeninf
 		unsigned int namelen = strlen(name);
 		int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
 		unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
-		int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+		int yres_specified = 0, cvt = 0, rb = 0;
+		int interlace_specified = 0, interlace = 0;
 		int margins = 0;
 		u32 best, diff, tdiff;

@@ -748,9 +749,17 @@ int fb_find_mode(struct fb_var_screeninf
 				if (!cvt)
 					margins = 1;
 				break;
+			case 'p':
+				if (!cvt) {
+					interlace = 0;
+					interlace_specified = 1;
+				}
+				break;
 			case 'i':
-				if (!cvt)
+				if (!cvt) {
 					interlace = 1;
+					interlace_specified = 1;
+				}
 				break;
 			default:
 				goto done;

@@ -819,11 +828,21 @@ done:
 			if ((name_matches(db[i], name, namelen) ||
 			     (res_specified && res_matches(db[i], xres, yres))) &&
 			    !fb_try_mode(var, info, &db[i], bpp)) {
-				if (refresh_specified && db[i].refresh == refresh)
-					return 1;
+				const int db_interlace = (db[i].vmode &
+					FB_VMODE_INTERLACED ? 1 : 0);
+				int score = abs(db[i].refresh - refresh);
+
+				if (interlace_specified)
+					score += abs(db_interlace - interlace);
+
+				if (!interlace_specified ||
+				    db_interlace == interlace)
+					if (refresh_specified &&
+					    db[i].refresh == refresh)
+						return 1;
 
-				if (abs(db[i].refresh - refresh) < diff) {
-					diff = abs(db[i].refresh - refresh);
+				if (score < diff) {
+					diff = score;
 					best = i;
 				}
 			}

Greg Kroah-Hartman

author maintainer

2018-09-24 12:10 UTC #27 lore raw

PATCH 27/111 ARM: exynos: Clear global variable on init error path

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Krzysztof Kozlowski <[email protected]>

[ Upstream commit cd4806911cee3901bc2b5eb95603cf1958720b57 ]

For most of Exynos SoCs, Power Management Unit (PMU) address space is mapped into global variable 'pmu_base_addr' very early when initializing PMU interrupt controller. A lot of other machine code depends on it so when doing iounmap() on this address, clear the global as well to avoid usage of invalid value (pointing to unmapped memory region).

Properly mapped PMU address space is a requirement for all other machine code so this fix is purely theoretical. Boot will fail immediately in many other places after following this error path.

Signed-off-by Krzysztof Kozlowski <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/mach-exynos/suspend.c |    1 +
 1 file changed, 1 insertion(+)

arch/arm/mach-exynos/suspend.c +1 -0

@@ -252,6 +252,7 @@ static int __init exynos_pmu_irq_init(st
 					  NULL);
 	if (!domain) {
 		iounmap(pmu_base_addr);
+		pmu_base_addr = NULL;
 		return -ENOMEM;
 	}

Greg Kroah-Hartman

author maintainer

2018-09-24 11:51 UTC #28 lore raw

PATCH 28/111 perf powerpc: Fix callchain ip filtering

Link http://lkml.kernel.org/r/24bb726d91ed173aebc972ec3f41a2ef2249434e.1530724939.git.sandipan@linux.ibm.com open here

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sandipan Das <[email protected]>

[ Upstream commit c715fcfda5a08edabaa15508742be926b7ee51db ]

For powerpc64, redundant entries in the callchain are filtered out by determining the state of the return address and the stack frame using DWARF debug information.

For making these filtering decisions we must analyze the debug information for the location corresponding to the program counter value, i.e. the first entry in the callchain, and not the LR value; otherwise, perf may filter out either the second or the third entry in the callchain incorrectly.

This can be observed on a powerpc64le system running Fedora 27 as shown below.

Case 1 - Attaching a probe at inet_pton+0x8 (binary offset 0x15af28).
Return address is still in LR and a new stack frame is not yet allocated. The LR value, i.e. the second entry, should not be filtered out.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  000000000010eb10 <gaih_inet.constprop.7>:
  ...
    10fa48:       78 bb e4 7e     mr      r4,r23
    10fa4c:       0a 00 60 38     li      r3,10
    10fa50:       d9 b4 04 48     bl      15af28 <inet_pton+0x8>
    10fa54:       00 00 00 60     nop
    10fa58:       ac f4 ff 4b     b       10ef04 <gaih_inet.constprop.7+0x3f4>
  ...
  0000000000110450 <getaddrinfo>:
  ...
    1105a8:       54 00 ff 38     addi    r7,r31,84
    1105ac:       58 00 df 38     addi    r6,r31,88
    1105b0:       69 e5 ff 4b     bl      10eb18 <gaih_inet.constprop.7+0x8>
    1105b4:       78 1b 71 7c     mr      r17,r3
    1105b8:       50 01 7f e8     ld      r3,336(r31)
  ...
  000000000015af20 <inet_pton>:
    15af20:       0b 00 4c 3c     addis   r2,r12,11
    15af24:       e0 c1 42 38     addi    r2,r2,-15904
    15af28:       a6 02 08 7c     mflr    r0
    15af2c:       f0 ff c1 fb     std     r30,-16(r1)
    15af30:       f8 ff e1 fb     std     r31,-8(r1)
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x8
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

ping 4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)

              7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
              7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                 13fb52d70 _init+0xbfc (/usr/bin/ping)
              7fffa7c836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
              7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                         0 [unknown] ([unknown])

After:

ping 4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)

              7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
              7fffa7d6fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
              7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                 13fb52d70 _init+0xbfc (/usr/bin/ping)
              7fffa7c836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
              7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                         0 [unknown] ([unknown])

Case 2 - Attaching a probe at _int_malloc+0x180 (binary offset 0x9cf10).
Return address in still in LR and a new stack frame has already been allocated but not used. The caller's caller, i.e. the third entry, is invalid and should be filtered out and not the second one.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  000000000009cd90 <_int_malloc>:
     9cd90:       17 00 4c 3c     addis   r2,r12,23
     9cd94:       70 a3 42 38     addi    r2,r2,-23696
     9cd98:       26 00 80 7d     mfcr    r12
     9cd9c:       f8 ff e1 fb     std     r31,-8(r1)
     9cda0:       17 00 e4 3b     addi    r31,r4,23
     9cda4:       d8 ff 61 fb     std     r27,-40(r1)
     9cda8:       78 23 9b 7c     mr      r27,r4
     9cdac:       1f 00 bf 2b     cmpldi  cr7,r31,31
     9cdb0:       f0 ff c1 fb     std     r30,-16(r1)
     9cdb4:       b0 ff c1 fa     std     r22,-80(r1)
     9cdb8:       78 1b 7e 7c     mr      r30,r3
     9cdbc:       08 00 81 91     stw     r12,8(r1)
     9cdc0:       11 ff 21 f8     stdu    r1,-240(r1)
     9cdc4:       4c 01 9d 41     bgt     cr7,9cf10 <_int_malloc+0x180>
     9cdc8:       20 00 a4 2b     cmpldi  cr7,r4,32
  ...
     9cf08:       00 00 00 60     nop
     9cf0c:       00 00 42 60     ori     r2,r2,0
     9cf10:       e4 06 ff 7b     rldicr  r31,r31,0,59
     9cf14:       40 f8 a4 7f     cmpld   cr7,r4,r31
     9cf18:       68 05 9d 41     bgt     cr7,9d480 <_int_malloc+0x6f0>
  ...
  000000000009e3c0 <tcache_init.part.4>:
  ...
     9e420:       40 02 80 38     li      r4,576
     9e424:       78 fb e3 7f     mr      r3,r31
     9e428:       71 e9 ff 4b     bl      9cd98 <_int_malloc+0x8>
     9e42c:       00 00 a3 2f     cmpdi   cr7,r3,0
     9e430:       78 1b 7e 7c     mr      r30,r3
  ...
  000000000009f7a0 <__libc_malloc>:
  ...
     9f8f8:       00 00 89 2f     cmpwi   cr7,r9,0
     9f8fc:       1c ff 9e 40     bne     cr7,9f818 <__libc_malloc+0x78>
     9f900:       c9 ea ff 4b     bl      9e3c8 <tcache_init.part.4+0x8>
     9f904:       00 00 00 60     nop
     9f908:       e8 90 22 e9     ld      r9,-28440(r2)
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a _int_malloc+0x180
  # perf record -e probe_libc:_int_malloc -g ./test-malloc
  # perf script

Before:

test-malloc 6554 [009] 515975.797403: probe_libc:_int_malloc: (7fffa6e6cf10)

              7fffa6e6cf10 _int_malloc+0x180 (/usr/lib64/libc-2.26.so)
              7fffa6dd0000 [unknown] (/usr/lib64/libc-2.26.so)
              7fffa6e6f904 malloc+0x164 (/usr/lib64/libc-2.26.so)
              7fffa6e6f9fc malloc+0x25c (/usr/lib64/libc-2.26.so)
                  100006b4 main+0x38 (/home/testuser/test-malloc)
              7fffa6df36a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
              7fffa6df3898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                         0 [unknown] ([unknown])

After:

test-malloc 6554 [009] 515975.797403: probe_libc:_int_malloc: (7fffa6e6cf10)

              7fffa6e6cf10 _int_malloc+0x180 (/usr/lib64/libc-2.26.so)
              7fffa6e6e42c tcache_init.part.4+0x6c (/usr/lib64/libc-2.26.so)
              7fffa6e6f904 malloc+0x164 (/usr/lib64/libc-2.26.so)
              7fffa6e6f9fc malloc+0x25c (/usr/lib64/libc-2.26.so)
                  100006b4 main+0x38 (/home/sandipan/test-malloc)
              7fffa6df36a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
              7fffa6df3898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                         0 [unknown] ([unknown])

Signed-off-by Sandipan Das <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Maynard Johnson <[email protected]>

Cc Naveen N. Rao <[email protected]>

Cc Ravi Bangoria <[email protected]>

Cc Sukadev Bhattiprolu <[email protected]>

Fixes a60335ba3298 ("perf tools powerpc: Adjust callchain based on DWARF debug info")

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/perf/arch/powerpc/util/skip-callchain-idx.c +1 -1

@@ -250,7 +250,7 @@ int arch_skip_callchain_idx(struct threa
 	if (!chain || chain->nr < 3)
 		return skip_slot;
 
-	ip = chain->ips[2];
+	ip = chain->ips[1];
 
 	thread__find_addr_location(thread, PERF_RECORD_MISC_USER,
 			MAP__FUNCTION, ip, &al);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:01 UTC #29 lore raw

PATCH 29/111 powerpc/powernv: opal_put_chars partial write fix

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nicholas Piggin <[email protected]>

[ Upstream commit bd90284cc6c1c9e8e48c8eadd0c79574fcce0b81 ]

The intention here is to consume and discard the remaining buffer upon error. This works if there has not been a previous partial write. If there has been, then total_len is no longer total number of bytes to copy. total_len is always "bytes left to copy", so it should be added to written bytes.

This code may not be exercised any more if partial writes will not be hit, but this is a small bugfix before a larger change.

Reviewed-by Benjamin Herrenschmidt <[email protected]>

Signed-off-by Nicholas Piggin <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/platforms/powernv/opal.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/powerpc/platforms/powernv/opal.c +1 -1

@@ -369,7 +369,7 @@ int opal_put_chars(uint32_t vtermno, con
 		/* Closed or other error drop */
 		if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
 		    rc != OPAL_BUSY_EVENT) {
-			written = total_len;
+			written += total_len;
 			break;
 		}
 		if (rc == OPAL_SUCCESS) {

Greg Kroah-Hartman

author maintainer

2018-09-24 11:51 UTC #30 lore raw

PATCH 30/111 MIPS: jz4740: Bump zload address

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Cercueil <[email protected]>

[ Upstream commit c6ea7e9747318e5a6774995f4f8e3e0f7c0fa8ba ]

Having the zload address at 0x8060.0000 means the size of the uncompressed kernel cannot be bigger than around 6 MiB, as it is deflated at address 0x8001.0000.

This limit is too small; a kernel with some built-in drivers and things like debugfs enabled will already be over 6 MiB in size, and so will fail to extract properly.

To fix this, we bump the zload address from 0x8060.0000 to 0x8100.0000.

This is fine, as all the boards featuring Ingenic JZ SoCs have at least 32 MiB of RAM, and use u-boot or compatible bootloaders which won't hardcode the load address but read it from the uImage's header.

Signed-off-by Paul Cercueil <[email protected]>

Signed-off-by Paul Burton <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/19787/

Cc Ralf Baechle <[email protected]>

Cc James Hogan <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/jz4740/Platform |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/mips/jz4740/Platform +1 -1

@@ -1,4 +1,4 @@
 platform-$(CONFIG_MACH_INGENIC)	+= jz4740/
 cflags-$(CONFIG_MACH_INGENIC)	+= -I$(srctree)/arch/mips/include/asm/mach-jz4740
 load-$(CONFIG_MACH_INGENIC)	+= 0xffffffff80010000
-zload-$(CONFIG_MACH_INGENIC)	+= 0xffffffff80600000
+zload-$(CONFIG_MACH_INGENIC)	+= 0xffffffff81000000

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #31 lore raw

PATCH 31/111 mac80211: restrict delayed tailroom needed decrement

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Manikanta Pubbisetty <[email protected]>

[ Upstream commit 133bf90dbb8b873286f8ec2e81ba26e863114b8c ]

As explained in ieee80211_delayed_tailroom_dec(), during roam, keys of the old AP will be destroyed and new keys will be installed. Deletion of the old key causes crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key installation causes a transition from 0 to 1.

Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1, we invoke synchronize_net(); the reason for doing this is to avoid a race in the TX path as explained in increment_tailroom_need_count(). This synchronize_net() operation can be slow and can affect the station roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt is delayed for a while so that upon installation of new key the transition would be from 1 to 2 instead of 0 to 1 and thereby improving the roam time.

This is all correct for a STA iftype, but deferring the tailroom_needed decrement for other iftypes may be unnecessary.

For example, let's consider the case of a 4-addr client connecting to an AP for which AP_VLAN interface is also created, let the initial value for tailroom_needed on the AP be 1.

* 4-addr client connects to the AP (AP: tailroom_needed = 1)
* AP will clear old keys, delay decrement of tailroom_needed count
* AP_VLAN is created, it takes the tailroom count from master (AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
* Install new key for the station, assume key is plumbed in the HW, there won't be any change in tailroom_needed count on AP iface
* Delayed decrement of tailroom_needed count on AP
(AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)

Because of the delayed decrement on AP iface, tailroom_needed count goes out of sync between AP(master iface) and AP_VLAN(slave iface) and there would be unnecessary tailroom created for the packets going through AP_VLAN iface.

Also, WARN_ONs were observed while trying to bring down the AP_VLAN interface:
(warn_slowpath_common) (warn_slowpath_null+0x18/0x20) (warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4) (ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850) (ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c) (ieee80211_stop) (__dev_close_many+0x94/0xb8) (__dev_close_many) (dev_close_many+0x5c/0xc8)

Restricting delayed decrement to station interface alone fixes the problem and it makes sense to do so because delayed decrement is done to improve roam time which is applicable only for client devices.

Signed-off-by Manikanta Pubbisetty <[email protected]>

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/mac80211/cfg.c |    2 +-
 net/mac80211/key.c |   24 +++++++++++++++---------
 2 files changed, 16 insertions(+), 10 deletions(-)

net/mac80211/cfg.c +1 -1

@@ -454,7 +454,7 @@ static int ieee80211_del_key(struct wiph
 		goto out_unlock;
 	}
 
-	ieee80211_key_free(key, true);
+	ieee80211_key_free(key, sdata->vif.type == NL80211_IFTYPE_STATION);
 
 	ret = 0;
  out_unlock:

net/mac80211/key.c +15 -9

@@ -648,11 +648,15 @@ int ieee80211_key_link(struct ieee80211_
 {
 	struct ieee80211_local *local = sdata->local;
 	struct ieee80211_key *old_key;
-	int idx, ret;
-	bool pairwise;
-
-	pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
-	idx = key->conf.keyidx;
+	int idx = key->conf.keyidx;
+	bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+	/*
+	 * We want to delay tailroom updates only for station - in that
+	 * case it helps roaming speed, but in other cases it hurts and
+	 * can cause warnings to appear.
+	 */
+	bool delay_tailroom = sdata->vif.type == NL80211_IFTYPE_STATION;
+	int ret;
 
 	mutex_lock(&sdata->local->key_mtx);

@@ -680,14 +684,14 @@ int ieee80211_key_link(struct ieee80211_
 	increment_tailroom_need_count(sdata);
 
 	ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
-	ieee80211_key_destroy(old_key, true);
+	ieee80211_key_destroy(old_key, delay_tailroom);
 
 	ieee80211_debugfs_key_add(key);
 
 	if (!local->wowlan) {
 		ret = ieee80211_key_enable_hw_accel(key);
 		if (ret)
-			ieee80211_key_free(key, true);
+			ieee80211_key_free(key, delay_tailroom);
 	} else {
 		ret = 0;
 	}

@@ -922,7 +926,8 @@ void ieee80211_free_sta_keys(struct ieee
 		ieee80211_key_replace(key->sdata, key->sta,
 				key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE,
 				key, NULL);
-		__ieee80211_key_destroy(key, true);
+		__ieee80211_key_destroy(key, key->sdata->vif.type ==
+					NL80211_IFTYPE_STATION);
 	}
 
 	for (i = 0; i < NUM_DEFAULT_KEYS; i++) {

@@ -932,7 +937,8 @@ void ieee80211_free_sta_keys(struct ieee
 		ieee80211_key_replace(key->sdata, key->sta,
 				key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE,
 				key, NULL);
-		__ieee80211_key_destroy(key, true);
+		__ieee80211_key_destroy(key, key->sdata->vif.type ==
+					NL80211_IFTYPE_STATION);
 	}
 
 	mutex_unlock(&local->key_mtx);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:04 UTC #32 lore raw

PATCH 32/111 Smack: Fix handling of IPv4 traffic received by PF_INET6 sockets

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Piotr Sawicki <[email protected]>

[ Upstream commit 129a99890936766f4b69b9da7ed88366313a9210 ]

A socket which has sk_family set to PF_INET6 is able to receive not only IPv6 but also IPv4 traffic (IPv4-mapped IPv6 addresses).

Prior to this patch, the smk_skb_to_addr_ipv6() could have been called for socket buffers containing IPv4 packets, in result such traffic was allowed.

Signed-off-by Piotr Sawicki <[email protected]>

Signed-off-by Casey Schaufler <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 security/smack/smack_lsm.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

security/smack/smack_lsm.c +9 -5

@@ -3966,15 +3966,19 @@ static int smack_socket_sock_rcv_skb(str
 	struct smack_known *skp = NULL;
 	int rc = 0;
 	struct smk_audit_info ad;
+	u16 family = sk->sk_family;
 #ifdef CONFIG_AUDIT
 	struct lsm_network_audit net;
 #endif
 #if IS_ENABLED(CONFIG_IPV6)
 	struct sockaddr_in6 sadd;
 	int proto;
+
+	if (family == PF_INET6 && skb->protocol == htons(ETH_P_IP))
+		family = PF_INET;
 #endif /* CONFIG_IPV6 */
 
-	switch (sk->sk_family) {
+	switch (family) {
 	case PF_INET:
 #ifdef CONFIG_SECURITY_SMACK_NETFILTER
 		/*

@@ -3992,7 +3996,7 @@ static int smack_socket_sock_rcv_skb(str
 		 */
 		netlbl_secattr_init(&secattr);
 
-		rc = netlbl_skbuff_getattr(skb, sk->sk_family, &secattr);
+		rc = netlbl_skbuff_getattr(skb, family, &secattr);
 		if (rc == 0)
 			skp = smack_from_secattr(&secattr, ssp);
 		else

@@ -4005,7 +4009,7 @@ access_check:
 #endif
 #ifdef CONFIG_AUDIT
 		smk_ad_init_net(&ad, __func__, LSM_AUDIT_DATA_NET, &net);
-		ad.a.u.net->family = sk->sk_family;
+		ad.a.u.net->family = family;
 		ad.a.u.net->netif = skb->skb_iif;
 		ipv4_skb_to_auditdata(skb, &ad.a, NULL);
 #endif

@@ -4019,7 +4023,7 @@ access_check:
 		rc = smk_bu_note("IPv4 delivery", skp, ssp->smk_in,
 					MAY_WRITE, rc);
 		if (rc != 0)
-			netlbl_skbuff_err(skb, sk->sk_family, rc, 0);
+			netlbl_skbuff_err(skb, family, rc, 0);
 		break;
 #if IS_ENABLED(CONFIG_IPV6)
 	case PF_INET6:

@@ -4035,7 +4039,7 @@ access_check:
 			skp = smack_net_ambient;
 #ifdef CONFIG_AUDIT
 		smk_ad_init_net(&ad, __func__, LSM_AUDIT_DATA_NET, &net);
-		ad.a.u.net->family = sk->sk_family;
+		ad.a.u.net->family = family;
 		ad.a.u.net->netif = skb->skb_iif;
 		ipv6_skb_to_auditdata(skb, &ad.a, NULL);
 #endif /* CONFIG_AUDIT */

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #33 lore raw

PATCH 33/111 wan/fsl_ucc_hdlc: use IS_ERR_VALUE() to check return value of qe_muram_alloc

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: YueHaibing <[email protected]>

[ Upstream commit fd800f646402c0f85547166b59ca065175928b7b ]

qe_muram_alloc return a unsigned long integer,which should not compared with zero. check it using IS_ERR_VALUE() to fix this.

Fixes c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")

Signed-off-by YueHaibing <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wan/fsl_ucc_hdlc.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/net/wan/fsl_ucc_hdlc.c +3 -3

@@ -161,7 +161,7 @@ static int uhdlc_init(struct ucc_hdlc_pr
 	priv->ucc_pram_offset = qe_muram_alloc(sizeof(struct ucc_hdlc_param),
 				ALIGNMENT_OF_UCC_HDLC_PRAM);
 
-	if (priv->ucc_pram_offset < 0) {
+	if (IS_ERR_VALUE(priv->ucc_pram_offset)) {
 		dev_err(priv->dev, "Can not allocate MURAM for hdlc parameter.\n");
 		ret = -ENOMEM;
 		goto free_tx_bd;

@@ -197,14 +197,14 @@ static int uhdlc_init(struct ucc_hdlc_pr
 
 	/* Alloc riptr, tiptr */
 	riptr = qe_muram_alloc(32, 32);
-	if (riptr < 0) {
+	if (IS_ERR_VALUE(riptr)) {
 		dev_err(priv->dev, "Cannot allocate MURAM mem for Receive internal temp data pointer\n");
 		ret = -ENOMEM;
 		goto free_tx_skbuff;
 	}
 
 	tiptr = qe_muram_alloc(32, 32);
-	if (tiptr < 0) {
+	if (IS_ERR_VALUE(tiptr)) {
 		dev_err(priv->dev, "Cannot allocate MURAM mem for Transmit internal temp data pointer\n");
 		ret = -ENOMEM;
 		goto free_riptr;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #34 lore raw

PATCH 34/111 efi/arm: preserve early mapping of UEFI memory map longer for BGRT

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ard Biesheuvel <[email protected]>

[ Upstream commit 3ea86495aef2f6de26b7cb1599ba350dd6a0c521 ]

The BGRT code validates the contents of the table against the UEFI memory map, and so it expects it to be mapped when the code runs.

On ARM, this is currently not the case, since we tear down the early mapping after efi_init() completes, and only create the permanent mapping in arm_enable_runtime_services(), which executes as an early initcall, but still leaves a window where the UEFI memory map is not mapped.

So move the call to efi_memmap_unmap() from efi_init() to arm_enable_runtime_services().

Signed-off-by Ard Biesheuvel <[email protected]>

[will: fold in EFI_MEMMAP attribute check from Ard]

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/firmware/efi/arm-init.c    |    1 -
 drivers/firmware/efi/arm-runtime.c |    4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

drivers/firmware/efi/arm-init.c +0 -1

@@ -250,7 +250,6 @@ void __init efi_init(void)
 	reserve_regions();
 	efi_memattr_init();
 	efi_esrt_init();
-	efi_memmap_unmap();
 
 	memblock_reserve(params.mmap & PAGE_MASK,
 			 PAGE_ALIGN(params.mmap_size +

drivers/firmware/efi/arm-runtime.c +3 -1

@@ -118,11 +118,13 @@ static int __init arm_enable_runtime_ser
 {
 	u64 mapsize;
 
-	if (!efi_enabled(EFI_BOOT)) {
+	if (!efi_enabled(EFI_BOOT) || !efi_enabled(EFI_MEMMAP)) {
 		pr_info("EFI services will not be available.\n");
 		return 0;
 	}
 
+	efi_memmap_unmap();
+
 	if (efi_runtime_disabled()) {
 		pr_info("EFI runtime services will be disabled.\n");
 		return 0;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #35 lore raw

PATCH 35/111 nfp: avoid buffer leak when FW communication fails

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jakub Kicinski <[email protected]>

[ Upstream commit 07300f774fec9519663a597987a4083225588be4 ]

After device is stopped we reset the rings by moving all free buffers to positions [0, cnt - 2], and clear the position cnt - 1 in the ring. We then proceed to clear the read/write pointers. This means that if we try to reset the ring again the code will assume that the next to fill buffer is at position 0 and swap it with cnt - 1. Since we previously cleared position cnt - 1 it will lead to leaking the first buffer and leaving ring in a bad state.

This scenario can only happen if FW communication fails, in which case the ring will never be used again, so the fact it's in a bad state will not be noticed. Buffer leak is the only problem. Don't try to move buffers in the ring if the read/write pointers indicate the ring was never used or have already been reset.

nfp_net_clear_config_and_disable() is now fully idempotent.

Found by code inspection, FW communication failures are very rare, and reconfiguring a live device is not common either, so it's unlikely anyone has ever noticed the leak.

Signed-off-by Jakub Kicinski <[email protected]>

Reviewed-by Dirk van der Merwe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/netronome/nfp/nfp_net_common.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

drivers/net/ethernet/netronome/nfp/nfp_net_common.c +10 -3

@@ -990,7 +990,7 @@ static void nfp_net_tx_complete(struct n
  * @nn:		NFP Net device
  * @tx_ring:	TX ring structure
  *
- * Assumes that the device is stopped
+ * Assumes that the device is stopped, must be idempotent.
  */
 static void
 nfp_net_tx_ring_reset(struct nfp_net *nn, struct nfp_net_tx_ring *tx_ring)

@@ -1144,13 +1144,18 @@ static void nfp_net_rx_give_one(struct n
  * nfp_net_rx_ring_reset() - Reflect in SW state of freelist after disable
  * @rx_ring:	RX ring structure
  *
- * Warning: Do *not* call if ring buffers were never put on the FW freelist
- *	    (i.e. device was not enabled)!
+ * Assumes that the device is stopped, must be idempotent.
  */
 static void nfp_net_rx_ring_reset(struct nfp_net_rx_ring *rx_ring)
 {
 	unsigned int wr_idx, last_idx;
 
+	/* wr_p == rd_p means ring was never fed FL bufs.  RX rings are always
+	 * kept at cnt - 1 FL bufs.
+	 */
+	if (rx_ring->wr_p == 0 && rx_ring->rd_p == 0)
+		return;
+
 	/* Move the empty entry to the end of the list */
 	wr_idx = rx_ring->wr_p % rx_ring->cnt;
 	last_idx = rx_ring->cnt - 1;

@@ -1919,6 +1924,8 @@ static void nfp_net_vec_clear_ring_data(
 /**
  * nfp_net_clear_config_and_disable() - Clear control BAR and disable NFP
  * @nn:      NFP Net device to reconfigure
+ *
+ * Warning: must be fully idempotent.
  */
 static void nfp_net_clear_config_and_disable(struct nfp_net *nn)
 {

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #36 lore raw

PATCH 36/111 xen-netfront: fix queue name setting

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vitaly Kuznetsov <[email protected]>

[ Upstream commit 2d408c0d4574b01b9ed45e02516888bf925e11a9 ]

Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and open") changed the initialization order: xennet_create_queues() now happens before we do register_netdev() so using netdev->name in xennet_init_queue() is incorrect, we end up with the following in /proc/interrupts:

 60:        139          0   xen-dyn    -event     eth%d-q0-tx
 61:        265          0   xen-dyn    -event     eth%d-q0-rx
 62:        234          0   xen-dyn    -event     eth%d-q1-tx
 63:          1          0   xen-dyn    -event     eth%d-q1-rx

and this looks ugly. Actually, using early netdev name (even when it's already set) is also not ideal: nowadays we tend to rename eth devices and queue name may end up not corresponding to the netdev name.

Use nodename from xenbus device for queue naming: this can't change in VM's lifetime. Now /proc/interrupts looks like

 62:        202          0   xen-dyn    -event     device/vif/0-q0-tx
 63:        317          0   xen-dyn    -event     device/vif/0-q0-rx
 64:        262          0   xen-dyn    -event     device/vif/0-q1-tx
 65:         17          0   xen-dyn    -event     device/vif/0-q1-rx

Fixes f599c64fdf7d ("xen-netfront: Fix race between device setup and open")

Signed-off-by Vitaly Kuznetsov <[email protected]>

Reviewed-by Ross Lagerwall <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/xen-netfront.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/xen-netfront.c +1 -1

@@ -1630,7 +1630,7 @@ static int xennet_init_queue(struct netf
 		    (unsigned long)queue);
 
 	snprintf(queue->name, sizeof(queue->name), "%s-q%u",
-		 queue->info->netdev->name, queue->id);
+		 queue->info->xbdev->nodename, queue->id);
 
 	/* Initialise tx_skbs as a free chain containing every entry. */
 	queue->tx_skb_freelist = 0;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #37 lore raw

PATCH 37/111 arm64: dts: qcom: db410c: Fix Bluetooth LED trigger

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Loic Poulain <[email protected]>

[ Upstream commit e53db018315b7660bb7000a29e79faff2496c2c2 ]

Current LED trigger, 'bt', is not known/used by any existing driver. Fix this by renaming it to 'bluetooth-power' trigger which is controlled by the Bluetooth subsystem.

Fixes 9943230c8860 ("arm64: dts: qcom: Add apq8016-sbc board LED's related device nodes")

Signed-off-by Loic Poulain <[email protected]>

Signed-off-by Andy Gross <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi +1 -1

@@ -170,7 +170,7 @@
 			led@6 {
 				label = "apq8016-sbc:blue:bt";
 				gpios = <&pm8916_mpps 3 GPIO_ACTIVE_HIGH>;
-				linux,default-trigger = "bt";
+				linux,default-trigger = "bluetooth-power";
 				default-state = "off";
 			};
 		};

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #38 lore raw

PATCH 38/111 ARM: dts: qcom: msm8974-hammerhead: increase load on l20 for sdhci

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bhushan Shah <[email protected]>

[ Upstream commit 03864e57770a9541e7ff3990bacf2d9a2fffcd5d ]

The kernel would not boot on the hammerhead hardware due to the following error:

mmc0: Timeout waiting for hardware interrupt.
mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
mmc0: sdhci: Sys addr: 0x00000200 | Version: 0x00003802
mmc0: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000200
mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000023
mmc0: sdhci: Present: 0x03e80000 | Host ctl: 0x00000034
mmc0: sdhci: Power: 0x00000001 | Blk gap: 0x00000000
mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
mmc0: sdhci: Timeout: 0x0000000e | Int stat: 0x00000000
mmc0: sdhci: Int enab: 0x02ff900b | Sig enab: 0x02ff100b
mmc0: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
mmc0: sdhci: Caps: 0x642dc8b2 | Caps_1: 0x00008007
mmc0: sdhci: Cmd: 0x00000c1b | Max curr: 0x00000000
mmc0: sdhci: Resp[0]: 0x00000c00 | Resp[1]: 0x00000000
mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
mmc0: sdhci: Host ctl2: 0x00000008
mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x70040220
mmc0: sdhci: ============================================
mmc0: Card stuck in wrong state! mmcblk0 card_busy_detect status: 0xe00
mmc0: cache flush error -110
mmc0: Reset 0x1 never completed.

This patch increases the load on l20 to 0.2 amps for the sdhci and allows the device to boot normally.

Signed-off-by Bhushan Shah <[email protected]>

Signed-off-by Brian Masney <[email protected]>

Tested-by Brian Masney <[email protected]>

Signed-off-by Andy Gross <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts |    2 ++
 1 file changed, 2 insertions(+)

arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts +2 -0

@@ -188,6 +188,8 @@
 						regulator-max-microvolt = <2950000>;
 
 						regulator-boot-on;
+						regulator-system-load = <200000>;
+						regulator-allow-set-load;
 					};
 
 					l21 {

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #39 lore raw

PATCH 39/111 s390/qeth: fix race in used-buffer accounting

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Julian Wiedmann <[email protected]>

[ Upstream commit a702349a4099cd5a7bab0904689d8e0bf8dcd622 ]

By updating q->used_buffers only _after_ do_QDIO() has completed, there is a potential race against the buffer's TX completion. In the unlikely case that the TX completion path wins, qeth_qdio_output_handler() would decrement the counter before qeth_flush_buffers() even incremented it.

Signed-off-by Julian Wiedmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/s390/net/qeth_core_main.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/s390/net/qeth_core_main.c +2 -1

@@ -3499,13 +3499,14 @@ static void qeth_flush_buffers(struct qe
 	qdio_flags = QDIO_FLAG_SYNC_OUTPUT;
 	if (atomic_read(&queue->set_pci_flags_count))
 		qdio_flags |= QDIO_FLAG_PCI_OUT;
+	atomic_add(count, &queue->used_buffers);
+
 	rc = do_QDIO(CARD_DDEV(queue->card), qdio_flags,
 		     queue->queue_no, index, count);
 	if (queue->card->options.performance_stats)
 		queue->card->perf_stats.outbound_do_qdio_time +=
 			qeth_get_micros() -
 			queue->card->perf_stats.outbound_do_qdio_start_time;
-	atomic_add(count, &queue->used_buffers);
 	if (rc) {
 		queue->card->stats.tx_errors += count;
 		/* ignore temporary SIGA errors without busy condition */

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #40 lore raw

PATCH 40/111 s390/qeth: reset layer2 attribute on layer switch

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Julian Wiedmann <[email protected]>

[ Upstream commit 70551dc46ffa3555a0b5f3545b0cd87ab67fd002 ]

After the subdriver's remove() routine has completed, the card's layer mode is undetermined again. Reflect this in the layer2 field.

If qeth_dev_layer2_store() hits an error after remove() was called, the card _always_ requires a setup(), even if the previous layer mode is requested again.
But qeth_dev_layer2_store() bails out early if the requested layer mode still matches the current one. So unless we reset the layer2 field, re-probing the card back to its previous mode is currently not possible.

Signed-off-by Julian Wiedmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/s390/net/qeth_core_sys.c |    1 +
 1 file changed, 1 insertion(+)

drivers/s390/net/qeth_core_sys.c +1 -0

@@ -423,6 +423,7 @@ static ssize_t qeth_dev_layer2_store(str
 	if (card->discipline) {
 		card->discipline->remove(card->gdev);
 		qeth_core_free_discipline(card);
+		card->options.layer2 = -1;
 	}
 
 	rc = qeth_core_load_discipline(card, newdis);

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #41 lore raw

PATCH 41/111 platform/x86: toshiba_acpi: Fix defined but not used build warnings

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Randy Dunlap <[email protected]>

[ Upstream commit c2e2a618eb7104e18fdcf739d4d911563812a81c ]

Fix a build warning in toshiba_acpi.c when CONFIG_PROC_FS is not enabled by marking the unused function as __maybe_unused.

../drivers/platform/x86/toshiba_acpi.c:1685:12: warning: 'version_proc_show' defined but not used [-Wunused-function]

Signed-off-by Randy Dunlap <[email protected]>

Cc Azael Avalos <[email protected]>

Cc Andy Shevchenko <[email protected]>

Signed-off-by Darren Hart (VMware) <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/platform/x86/toshiba_acpi.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/platform/x86/toshiba_acpi.c +2 -1

@@ -34,6 +34,7 @@
 #define TOSHIBA_ACPI_VERSION	"0.24"
 #define PROC_INTERFACE_VERSION	1
 
+#include <linux/compiler.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/moduleparam.h>

@@ -1687,7 +1688,7 @@ static const struct file_operations keys
 	.write		= keys_proc_write,
 };
 
-static int version_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused version_proc_show(struct seq_file *m, void *v)
 {
 	seq_printf(m, "driver:                  %s\n", TOSHIBA_ACPI_VERSION);
 	seq_printf(m, "proc_interface:          %d\n", PROC_INTERFACE_VERSION);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:01 UTC #42 lore raw

PATCH 42/111 KVM: arm/arm64: Fix vgic init race

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christoffer Dall <[email protected]>

[ Upstream commit 1d47191de7e15900f8fbfe7cccd7c6e1c2d7c31a ]

The vgic_init function can race with kvm_arch_vcpu_create() which does not hold kvm_lock() and we therefore have no synchronization primitives to ensure we're doing the right thing.

As the user is trying to initialize or run the VM while at the same time creating more VCPUs, we just have to refuse to initialize the VGIC in this case rather than silently failing with a broken VCPU.

Reviewed-by Eric Auger <[email protected]>

Signed-off-by Christoffer Dall <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 virt/kvm/arm/vgic/vgic-init.c |    4 ++++
 1 file changed, 4 insertions(+)

virt/kvm/arm/vgic/vgic-init.c +4 -0

@@ -241,6 +241,10 @@ int vgic_init(struct kvm *kvm)
 	if (vgic_initialized(kvm))
 		return 0;
 
+	/* Are we also in the middle of creating a VCPU? */
+	if (kvm->created_vcpus != atomic_read(&kvm->online_vcpus))
+		return -EBUSY;
+
 	/* freeze the number of spis */
 	if (!dist->nr_spis)
 		dist->nr_spis = VGIC_NR_IRQS_LEGACY - VGIC_NR_PRIVATE_IRQS;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:01 UTC #43 lore raw

PATCH 43/111 drivers/base: stop new probing during shutdown

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pingfan Liu <[email protected]>

[ Upstream commit 3297c8fc65af5d40501ea7cddff1b195cae57e4e ]

There is a race window in device_shutdown(), which may cause -1. parent device shut down before child or
-2. no shutdown on a new probing device.

For 1st, taking the following scenario:
device_shutdown new plugin device
list_del_init(parent_dev);
spin_unlock(list_lock);
device_add(child) probe child
shutdown parent_dev

       --> now child is on the tail of devices_kset

For 2nd, taking the following scenario:
device_shutdown new plugin device
device_add(dev)
device_lock(dev);
...

  device_unlock(dev);
                                                  probe dev
       --> now, the new occurred dev has no opportunity to shutdown

To fix this race issue, just prevent the new probing request. With this logic, device_shutdown() is more similar to dpm_prepare().

Signed-off-by Pingfan Liu <[email protected]>

Reviewed-by Rafael J. Wysocki <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/base/core.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/base/core.c +3 -0

@@ -2072,6 +2072,9 @@ void device_shutdown(void)
 {
 	struct device *dev, *parent;
 
+	wait_for_device_probe();
+	device_block_probing();
+
 	spin_lock(&devices_kset->list_lock);
 	/*
 	 * Walk the devices list backward, shutting down each in turn.

Greg Kroah-Hartman

author maintainer

2018-09-24 12:01 UTC #44 lore raw

PATCH 44/111 dmaengine: mv_xor_v2: kill the tasklets upon exit

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hanna Hawa <[email protected]>

[ Upstream commit 8bbafed8dd5cfa81071b50ead5cb60367fdef3a9 ]

The mv_xor_v2 driver uses a tasklet, initialized during the probe() routine. However, it forgets to cleanup the tasklet using tasklet_kill() function during the remove() routine, which this patch fixes. This prevents the tasklet from potentially running after the module has been removed.

Fixes 19a340b1a820 ("dmaengine: mv_xor_v2: new driver")

Signed-off-by Hanna Hawa <[email protected]>

Reviewed-by Thomas Petazzoni <[email protected]>

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/dma/mv_xor_v2.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/dma/mv_xor_v2.c +2 -0

@@ -844,6 +844,8 @@ static int mv_xor_v2_remove(struct platf
 
 	platform_msi_domain_free_irqs(&pdev->dev);
 
+	tasklet_kill(&xor_dev->irq_tasklet);
+
 	clk_disable_unprepare(xor_dev->clk);
 
 	return 0;

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #45 lore raw

PATCH 45/111 crypto: sharah - Unregister correct algorithms for SAHARA 3

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Michael Müller <[email protected]>

[ Upstream commit 0e7d4d932ffc23f75efb31a8c2ac2396c1b81c55 ]

This patch fixes two typos related to unregistering algorithms supported by SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered in case of an error. In sahara_unregister_algs the wrong array is used to determine the iteration count.

Signed-off-by Michael Müller <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/crypto/sahara.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/crypto/sahara.c +2 -2

@@ -1352,7 +1352,7 @@ err_sha_v4_algs:
 
 err_sha_v3_algs:
 	for (j = 0; j < k; j++)
-		crypto_unregister_ahash(&sha_v4_algs[j]);
+		crypto_unregister_ahash(&sha_v3_algs[j]);
 
 err_aes_algs:
 	for (j = 0; j < i; j++)

@@ -1368,7 +1368,7 @@ static void sahara_unregister_algs(struc
 	for (i = 0; i < ARRAY_SIZE(aes_algs); i++)
 		crypto_unregister_alg(&aes_algs[i]);
 
-	for (i = 0; i < ARRAY_SIZE(sha_v4_algs); i++)
+	for (i = 0; i < ARRAY_SIZE(sha_v3_algs); i++)
 		crypto_unregister_ahash(&sha_v3_algs[i]);
 
 	if (dev->version > SAHARA_VERSION_3)

Greg Kroah-Hartman

author maintainer

2018-09-24 12:01 UTC #46 lore raw

PATCH 46/111 xen-netfront: fix warn message as irq device name has /

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Xiao Liang <[email protected]>

[ Upstream commit 21f2706b20100bb3db378461ab9b8e2035309b5b ]

There is a call trace generated after commit 2d408c0d4574b01b9ed45e02516888bf925e11a9(
xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file found under /proc/irq/xx/.

This patch only picks up device type and id as its name.

With the patch, now /proc/interrupts looks like below and the warning message gone:

 70:         21          0          0          0   xen-dyn    -event     vif0-q0-tx
 71:         15          0          0          0   xen-dyn    -event     vif0-q0-rx
 72:         14          0          0          0   xen-dyn    -event     vif0-q1-tx
 73:         33          0          0          0   xen-dyn    -event     vif0-q1-rx
 74:         12          0          0          0   xen-dyn    -event     vif0-q2-tx
 75:         24          0          0          0   xen-dyn    -event     vif0-q2-rx
 76:         19          0          0          0   xen-dyn    -event     vif0-q3-tx
 77:         21          0          0          0   xen-dyn    -event     vif0-q3-rx

Below is call trace information without this patch:

name 'device/vif/0-q0-tx'

WARNING: CPU: 2 PID: 37 at fs/proc/generic.c:174 __xlate_proc_name+0x85/0xa0
RIP: 0010:__xlate_proc_name+0x85/0xa0
RSP: 0018:ffffb85c40473c18 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000000006
RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff984c7f516930
RBP: ffffb85c40473cb8 R08: 000000000000002c R09: 0000000000000229
R10: 0000000000000000 R11: 0000000000000001 R12: ffffb85c40473c98
R13: ffffb85c40473cb8 R14: ffffb85c40473c50 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff984c7f500000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f69b6899038 CR3: 000000001c20a006 CR4: 00000000001606e0
Call Trace:
__proc_create+0x45/0x230
? snprintf+0x49/0x60
proc_mkdir_data+0x35/0x90
register_handler_proc+0xef/0x110
? proc_register+0xfc/0x110
? proc_create_data+0x70/0xb0
__setup_irq+0x39b/0x660
? request_threaded_irq+0xad/0x160
request_threaded_irq+0xf5/0x160
? xennet_tx_buf_gc+0x1d0/0x1d0 [xen_netfront]
bind_evtchn_to_irqhandler+0x3d/0x70
? xenbus_alloc_evtchn+0x41/0xa0
netback_changed+0xa46/0xcda [xen_netfront]
? find_watch+0x40/0x40
xenwatch_thread+0xc5/0x160
? finish_wait+0x80/0x80
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
Code: 81 5c 00 48 85 c0 75 cc 5b 49 89 2e 31 c0 5d 4d 89 3c 24 41 5c 41 5d 41 5e 41 5f c3 4c 89 ee 48 c7 c7 40 4f 0e b4 e8 65 ea d8 ff <0f> 0b b8 fe ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 0f 1f
---[ end trace 650e5561b0caab3a ]---

Signed-off-by Xiao Liang <[email protected]>

Reviewed-by Juergen Gross <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/xen-netfront.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/net/xen-netfront.c +4 -2

@@ -1622,6 +1622,7 @@ static int xennet_init_queue(struct netf
 {
 	unsigned short i;
 	int err = 0;
+	char *devid;
 
 	spin_lock_init(&queue->tx_lock);
 	spin_lock_init(&queue->rx_lock);

@@ -1629,8 +1630,9 @@ static int xennet_init_queue(struct netf
 	setup_timer(&queue->rx_refill_timer, rx_refill_timeout,
 		    (unsigned long)queue);
 
-	snprintf(queue->name, sizeof(queue->name), "%s-q%u",
-		 queue->info->xbdev->nodename, queue->id);
+	devid = strrchr(queue->info->xbdev->nodename, '/') + 1;
+	snprintf(queue->name, sizeof(queue->name), "vif%s-q%u",
+		 devid, queue->id);
 
 	/* Initialise tx_skbs as a free chain containing every entry. */
 	queue->tx_skb_freelist = 0;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #47 lore raw

PATCH 47/111 RDMA/cma: Protect cma dev list with lock

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Parav Pandit <[email protected]>

commit 954a8e3aea87e896e320cf648c1a5bbe47de443e upstream.

When AF_IB addresses are used during rdma_resolve_addr() a lock is not held. A cma device can get removed while list traversal is in progress which may lead to crash. ie

        CPU0                                     CPU1
        ====                                     ====
rdma_resolve_addr()
 cma_resolve_ib_dev()
  list_for_each()                         cma_remove_one()
    cur_dev->device                        mutex_lock(&lock)
                                            list_del();
                                           mutex_unlock(&lock);
                                           cma_process_remove();

Therefore, hold a lock while traversing the list which avoids such situation.

Cc <[email protected]> # 3.10

Fixes f17df3b0dede ("RDMA/cma: Add support for AF_IB to rdma_resolve_addr()")

Signed-off-by Parav Pandit <[email protected]>

Reviewed-by Daniel Jurgens <[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

Reviewed-by Dennis Dalessandro <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/core/cma.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

drivers/infiniband/core/cma.c +7 -5

@@ -673,6 +673,7 @@ static int cma_resolve_ib_dev(struct rdm
 	dgid = (union ib_gid *) &addr->sib_addr;
 	pkey = ntohs(addr->sib_pkey);
 
+	mutex_lock(&lock);
 	list_for_each_entry(cur_dev, &dev_list, list) {
 		for (p = 1; p <= cur_dev->device->phys_port_cnt; ++p) {
 			if (!rdma_cap_af_ib(cur_dev->device, p))

@@ -696,18 +697,19 @@ static int cma_resolve_ib_dev(struct rdm
 					cma_dev = cur_dev;
 					sgid = gid;
 					id_priv->id.port_num = p;
+					goto found;
 				}
 			}
 		}
 	}
-
-	if (!cma_dev)
-		return -ENODEV;
+	mutex_unlock(&lock);
+	return -ENODEV;
 
 found:
 	cma_attach_to_dev(id_priv, cma_dev);
-	addr = (struct sockaddr_ib *) cma_src_addr(id_priv);
-	memcpy(&addr->sib_addr, &sgid, sizeof sgid);
+	mutex_unlock(&lock);
+	addr = (struct sockaddr_ib *)cma_src_addr(id_priv);
+	memcpy(&addr->sib_addr, &sgid, sizeof(sgid));
 	cma_translate_ib(addr, &id_priv->id.route.addr.dev_addr);
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #48 lore raw

PATCH 48/111 pstore: Fix incorrect persistent ram buffer mapping

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bin Yang <[email protected]>

commit 831b624df1b420c8f9281ed1307a8db23afb72df upstream.

persistent_ram_vmap() returns the page start vaddr. persistent_ram_iomap() supports non-page-aligned mapping.

persistent_ram_buffer_map() always adds offset-in-page to the vaddr returned from these two functions, which causes incorrect mapping of non-page-aligned persistent ram buffer.

By default ftrace_size is 4096 and max_ftrace_cnt is nr_cpu_ids. Without this patch, the zone_sz in ramoops_init_przs() is 4096/nr_cpu_ids which might not be page aligned. If the offset-in-page > 2048, the vaddr will be in next page. If the next page is not mapped, it will cause kernel panic:

[    0.074231] BUG: unable to handle kernel paging request at ffffa19e0081b000
...
[    0.075000] RIP: 0010:persistent_ram_new+0x1f8/0x39f
...
[    0.075000] Call Trace:
[    0.075000]  ramoops_init_przs.part.10.constprop.15+0x105/0x260
[    0.075000]  ramoops_probe+0x232/0x3a0
[    0.075000]  platform_drv_probe+0x3e/0xa0
[    0.075000]  driver_probe_device+0x2cd/0x400
[    0.075000]  __driver_attach+0xe4/0x110
[    0.075000]  ? driver_probe_device+0x400/0x400
[    0.075000]  bus_for_each_dev+0x70/0xa0
[    0.075000]  driver_attach+0x1e/0x20
[    0.075000]  bus_add_driver+0x159/0x230
[    0.075000]  ? do_early_param+0x95/0x95
[    0.075000]  driver_register+0x70/0xc0
[    0.075000]  ? init_pstore_fs+0x4d/0x4d
[    0.075000]  __platform_driver_register+0x36/0x40
[    0.075000]  ramoops_init+0x12f/0x131
[    0.075000]  do_one_initcall+0x4d/0x12c
[    0.075000]  ? do_early_param+0x95/0x95
[    0.075000]  kernel_init_freeable+0x19b/0x222
[    0.075000]  ? rest_init+0xbb/0xbb
[    0.075000]  kernel_init+0xe/0xfc
[    0.075000]  ret_from_fork+0x3a/0x50

Signed-off-by Bin Yang <[email protected]>

[kees: add comments describing the mapping differences, updated commit log]

Fixes 24c3d2f342ed ("staging: android: persistent_ram: Make it possible to use memory outside of bootmem")

Signed-off-by Kees Cook <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/pstore/ram_core.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

fs/pstore/ram_core.c +14 -3

@@ -421,7 +421,12 @@ static void *persistent_ram_vmap(phys_ad
 	vaddr = vmap(pages, page_count, VM_MAP, prot);
 	kfree(pages);
 
-	return vaddr;
+	/*
+	 * Since vmap() uses page granularity, we must add the offset
+	 * into the page here, to get the byte granularity address
+	 * into the mapping to represent the actual "start" location.
+	 */
+	return vaddr + offset_in_page(start);
 }
 
 static void *persistent_ram_iomap(phys_addr_t start, size_t size,

@@ -440,6 +445,11 @@ static void *persistent_ram_iomap(phys_a
 	else
 		va = ioremap_wc(start, size);
 
+	/*
+	 * Since request_mem_region() and ioremap() are byte-granularity
+	 * there is no need handle anything special like we do when the
+	 * vmap() case in persistent_ram_vmap() above.
+	 */
 	return va;
 }

@@ -460,7 +470,7 @@ static int persistent_ram_buffer_map(phy
 		return -ENOMEM;
 	}
 
-	prz->buffer = prz->vaddr + offset_in_page(start);
+	prz->buffer = prz->vaddr;
 	prz->buffer_size = size - sizeof(struct persistent_ram_buffer);
 
 	return 0;

@@ -507,7 +517,8 @@ void persistent_ram_free(struct persiste
 
 	if (prz->vaddr) {
 		if (pfn_valid(prz->paddr >> PAGE_SHIFT)) {
-			vunmap(prz->vaddr);
+			/* We must vunmap() at page-granularity. */
+			vunmap(prz->vaddr - offset_in_page(prz->paddr));
 		} else {
 			iounmap(prz->vaddr);
 			release_mem_region(prz->paddr, prz->size);

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #49 lore raw

PATCH 49/111 xen/netfront: fix waiting for xenbus state change

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Juergen Gross <[email protected]>

commit 8edfe2e992b75aee3da9316e9697c531194c2f53 upstream.

Commit 822fb18a82aba ("xen-netfront: wait xenbus state change when load module manually") added a new wait queue to wait on for a state change when the module is loaded manually. Unfortunately there is no wakeup anywhere to stop that waiting.

Instead of introducing a new wait queue rename the existing module_unload_q to module_wq and use it for both purposes (loading and unloading).

As any state change of the backend might be intended to stop waiting do the wake_up_all() in any case when netback_changed() is called.

Fixes 822fb18a82aba ("xen-netfront: wait xenbus state change when load module manually")

Cc <[email protected]> #4.18

Signed-off-by Juergen Gross <[email protected]>

Reviewed-by Boris Ostrovsky <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/xen-netfront.c |   24 ++++++++++--------------
 1 file changed, 10 insertions(+), 14 deletions(-)

drivers/net/xen-netfront.c +10 ~~-14~~

@@ -86,8 +86,7 @@ struct netfront_cb {
 /* IRQ name is queue name with "-tx" or "-rx" appended */
 #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
 
-static DECLARE_WAIT_QUEUE_HEAD(module_load_q);
-static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
+static DECLARE_WAIT_QUEUE_HEAD(module_wq);
 
 struct netfront_stats {
 	u64			packets;

@@ -1350,11 +1349,11 @@ static struct net_device *xennet_create_
 	netif_carrier_off(netdev);
 
 	xenbus_switch_state(dev, XenbusStateInitialising);
-	wait_event(module_load_q,
-			   xenbus_read_driver_state(dev->otherend) !=
-			   XenbusStateClosed &&
-			   xenbus_read_driver_state(dev->otherend) !=
-			   XenbusStateUnknown);
+	wait_event(module_wq,
+		   xenbus_read_driver_state(dev->otherend) !=
+		   XenbusStateClosed &&
+		   xenbus_read_driver_state(dev->otherend) !=
+		   XenbusStateUnknown);
 	return netdev;
 
  exit:

@@ -2039,15 +2038,14 @@ static void netback_changed(struct xenbu
 
 	dev_dbg(&dev->dev, "%s\n", xenbus_strstate(backend_state));
 
+	wake_up_all(&module_wq);
+
 	switch (backend_state) {
 	case XenbusStateInitialising:
 	case XenbusStateInitialised:
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
-		break;
-
 	case XenbusStateUnknown:
-		wake_up_all(&module_unload_q);
 		break;
 
 	case XenbusStateInitWait:

@@ -2063,12 +2061,10 @@ static void netback_changed(struct xenbu
 		break;
 
 	case XenbusStateClosed:
-		wake_up_all(&module_unload_q);
 		if (dev->state == XenbusStateClosed)
 			break;
 		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
-		wake_up_all(&module_unload_q);
 		xenbus_frontend_closed(dev);
 		break;
 	}

@@ -2176,14 +2172,14 @@ static int xennet_remove(struct xenbus_d
 
 	if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) {
 		xenbus_switch_state(dev, XenbusStateClosing);
-		wait_event(module_unload_q,
+		wait_event(module_wq,
 			   xenbus_read_driver_state(dev->otherend) ==
 			   XenbusStateClosing ||
 			   xenbus_read_driver_state(dev->otherend) ==
 			   XenbusStateUnknown);
 
 		xenbus_switch_state(dev, XenbusStateClosed);
-		wait_event(module_unload_q,
+		wait_event(module_wq,
 			   xenbus_read_driver_state(dev->otherend) ==
 			   XenbusStateClosed ||
 			   xenbus_read_driver_state(dev->otherend) ==

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #50 lore raw

PATCH 50/111 IB/ipoib: Avoid a race condition between start_xmit and cm_rep_handler

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Aaron Knister <[email protected]>

commit 816e846c2eb9129a3e0afa5f920c8bbc71efecaa upstream.

Inside of start_xmit() the call to check if the connection is up and the queueing of the packets for later transmission is not atomic which leaves a window where cm_rep_handler can run, set the connection up, dequeue pending packets and leave the subsequently queued packets by start_xmit() sitting on neigh->queue until they're dropped when the connection is torn down. This only applies to connected mode. These dropped packets can really upset TCP, for example, and cause multi-minute delays in transmission for open connections.

Here's the code in start_xmit where we check to see if the connection is up:

       if (ipoib_cm_get(neigh)) {
               if (ipoib_cm_up(neigh)) {
                       ipoib_cm_send(dev, skb, ipoib_cm_get(neigh));
                       goto unref;
               }
       }

The race occurs if cm_rep_handler execution occurs after the above connection check (specifically if it gets to the point where it acquires priv->lock to dequeue pending skb's) but before the below code snippet in start_xmit where packets are queued.

       if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
               push_pseudo_header(skb, phdr->hwaddr);
               spin_lock_irqsave(&priv->lock, flags);
               __skb_queue_tail(&neigh->queue, skb);
               spin_unlock_irqrestore(&priv->lock, flags);
       } else {
               ++dev->stats.tx_dropped;
               dev_kfree_skb_any(skb);
       }

The patch acquires the netif tx lock in cm_rep_handler for the section where it sets the connection up and dequeues and retransmits deferred skb's.

Fixes 839fcaba355a ("IPoIB: Connected mode experimental support")

Signed-off-by Aaron Knister <[email protected]>

Tested-by Ira Weiny <[email protected]>

Reviewed-by Ira Weiny <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/ulp/ipoib/ipoib_cm.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/infiniband/ulp/ipoib/ipoib_cm.c +2 -0

@@ -1009,12 +1009,14 @@ static int ipoib_cm_rep_handler(struct i
 
 	skb_queue_head_init(&skqueue);
 
+	netif_tx_lock_bh(p->dev);
 	spin_lock_irq(&priv->lock);
 	set_bit(IPOIB_FLAG_OPER_UP, &p->flags);
 	if (p->neigh)
 		while ((skb = __skb_dequeue(&p->neigh->queue)))
 			__skb_queue_tail(&skqueue, skb);
 	spin_unlock_irq(&priv->lock);
+	netif_tx_unlock_bh(p->dev);
 
 	while ((skb = __skb_dequeue(&skqueue))) {
 		skb->dev = p->dev;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #51 lore raw

PATCH 51/111 mmc: omap_hsmmc: fix wakeirq handling on removal

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andreas Kemnade <[email protected]>

commit 3c398f3c3bef21961eaaeb93227fa66d440dc83d upstream.

after unbinding mmc I get things like this:

[  185.294067] mmc1: card 0001 removed
[  185.305206] omap_hsmmc 480b4000.mmc: wake IRQ with no resume: -13

The wakeirq stays in /proc-interrupts

rebinding shows this:

[  289.795959] genirq: Flags mismatch irq 112. 0000200a (480b4000.mmc:wakeup) vs. 0000200a (480b4000.mmc:wakeup)
[  289.808959] omap_hsmmc 480b4000.mmc: Unable to request wake IRQ
[  289.815338] omap_hsmmc 480b4000.mmc: no SDIO IRQ support, falling back to polling

That bug seems to be introduced by switching from devm_request_irq() to generic wakeirq handling.

So let us cleanup at removal.

Signed-off-by Andreas Kemnade <[email protected]>

Fixes 5b83b2234be6 ("mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq")

Cc [email protected] # v4.2+

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/host/omap_hsmmc.c |    1 +
 1 file changed, 1 insertion(+)

drivers/mmc/host/omap_hsmmc.c +1 -0

@@ -2215,6 +2215,7 @@ static int omap_hsmmc_remove(struct plat
 	dma_release_channel(host->tx_chan);
 	dma_release_channel(host->rx_chan);
 
+	dev_pm_clear_wake_irq(host->dev);
 	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #52 lore raw

PATCH 52/111 Tools: hv: Fix a bug in the key delete code

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: K. Y. Srinivasan <[email protected]>

commit 86503bd35dec0ce363e9fdbf5299927422ed3899 upstream.

Fix a bug in the key delete code - the num_records range from 0 to num_records-1.

Signed-off-by K. Y. Srinivasan <[email protected]>

Reported-by David Binderman <[email protected]>

Reviewed-by Michael Kelley <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/hv/hv_kvp_daemon.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/hv/hv_kvp_daemon.c +1 -1

@@ -286,7 +286,7 @@ static int kvp_key_delete(int pool, cons
 		 * Found a match; just move the remaining
 		 * entries up.
 		 */
-		if (i == num_records) {
+		if (i == (num_records - 1)) {
 			kvp_file_info[pool].num_records--;
 			kvp_update_file(pool);
 			return 0;

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #53 lore raw

PATCH 53/111 misc: hmc6352: fix potential Spectre v1

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

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gustavo A. R. Silva <[email protected]>

commit de916736aaaadddbd6061472969f667b14204aa9 upstream.

val is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/misc/hmc6352.c:54 compass_store() warn: potential spectre issue 'map' [r]

Fix this by sanitizing val before using it to index map

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

Signed-off-by Gustavo A. R. Silva <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/hmc6352.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/misc/hmc6352.c +2 -0

@@ -27,6 +27,7 @@
 #include <linux/err.h>
 #include <linux/delay.h>
 #include <linux/sysfs.h>
+#include <linux/nospec.h>
 
 static DEFINE_MUTEX(compass_mutex);

@@ -50,6 +51,7 @@ static int compass_store(struct device *
 		return ret;
 	if (val >= strlen(map))
 		return -EINVAL;
+	val = array_index_nospec(val, strlen(map));
 	mutex_lock(&compass_mutex);
 	ret = compass_command(c, map[val]);
 	mutex_unlock(&compass_mutex);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #54 lore raw

PATCH 54/111 usb: Dont die twice if PCI xhci host is not responding in resume

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit f3dc41c5d22b2ca14a0802a65d8cdc33a3882d4e upstream.

usb_hc_died() should only be called once, and with the primary HCD as parameter. It will mark both primary and secondary hcd's dead.

Remove the extra call to usb_cd_died with the shared hcd as parameter.

Fixes ff9d78b36f76 ("USB: Set usb_hcd->state and flags for shared roothubs")

Signed-off-by Mathias Nyman <[email protected]>

Cc stable <[email protected]>

Acked-by Alan Stern <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/hcd-pci.c |    2 --
 1 file changed, 2 deletions(-)

drivers/usb/core/hcd-pci.c +0 -2

@@ -528,8 +528,6 @@ static int resume_common(struct device *
 				event == PM_EVENT_RESTORE);
 		if (retval) {
 			dev_err(dev, "PCI post-resume error %d!\n", retval);
-			if (hcd->shared_hcd)
-				usb_hc_died(hcd->shared_hcd);
 			usb_hc_died(hcd);
 		}
 	}

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #55 lore raw

PATCH 55/111 mei: ignore not found client in the enumeration

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexander Usyskin <[email protected]>

commit 8d2d8935d30cc2acc57a3196dc10dfa8d5cbcdab upstream.

Some of the ME clients are available only for BIOS operation and are removed during hand off to an OS. However the removal is not instant. A client may be visible on the client list when the mei driver requests for enumeration, while the subsequent request for properties will be answered with client not found error value. The default behavior for an error is to perform client reset while this error is harmless and the link reset should be prevented. This issue started to be visible due to suspend/resume timing changes. Currently reported only on the Haswell based system.

Fixes:

[33.564957] mei_me 0000:00:16.0: hbm: properties response: wrong status = 1 CLIENT_NOT_FOUND
[33.564978] mei_me 0000:00:16.0: mei_irq_read_handler ret = -71.
[33.565270] mei_me 0000:00:16.0: unexpected reset: dev_state = INIT_CLIENTS fw status = 1E000255 60002306 00000200 00004401 00000000 00000010

Reported-by Heiner Kallweit <[email protected]>

Signed-off-by Alexander Usyskin <[email protected]>

Signed-off-by Tomas Winkler <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/mei/hbm.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

drivers/misc/mei/hbm.c +6 -3

@@ -1137,15 +1137,18 @@ int mei_hbm_dispatch(struct mei_device *
 
 		props_res = (struct hbm_props_response *)mei_msg;
 
-		if (props_res->status) {
+		if (props_res->status == MEI_HBMS_CLIENT_NOT_FOUND) {
+			dev_dbg(dev->dev, "hbm: properties response: %d CLIENT_NOT_FOUND\n",
+				props_res->me_addr);
+		} else if (props_res->status) {
 			dev_err(dev->dev, "hbm: properties response: wrong status = %d %s\n",
 				props_res->status,
 				mei_hbm_status_str(props_res->status));
 			return -EPROTO;
+		} else {
+			mei_hbm_me_cl_add(dev, props_res);
 		}
 
-		mei_hbm_me_cl_add(dev, props_res);
-
 		/* request property for the next client */
 		if (mei_hbm_prop_req(dev, props_res->me_addr + 1))
 			return -EIO;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #56 lore raw

PATCH 56/111 USB: Add quirk to support DJI CineSSD

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tim Anderson <[email protected]>

commit f45681f9becaa65111ed0a691ccf080a0cd5feb8 upstream.

This device does not correctly handle the LPM operations.

Also, the device cannot handle ATA pass-through commands and locks up when attempted while running in super speed.

This patch adds the equivalent quirk logic as found in uas.

Signed-off-by Tim Anderson <[email protected]>

Acked-by Alan Stern <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/quirks.c          |    3 +++
 drivers/usb/storage/scsiglue.c     |    9 +++++++++
 drivers/usb/storage/unusual_devs.h |    7 +++++++
 3 files changed, 19 insertions(+)

drivers/usb/core/quirks.c +3 -0

@@ -259,6 +259,9 @@ static const struct usb_device_id usb_qu
 	{ USB_DEVICE(0x2040, 0x7200), .driver_info =
 			USB_QUIRK_CONFIG_INTF_STRINGS },
 
+	/* DJI CineSSD */
+	{ USB_DEVICE(0x2ca3, 0x0031), .driver_info = USB_QUIRK_NO_LPM },
+
 	/* INTEL VALUE SSD */
 	{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },

drivers/usb/storage/scsiglue.c +9 -0

@@ -392,6 +392,15 @@ static int queuecommand_lck(struct scsi_
 		return 0;
 	}
 
+	if ((us->fflags & US_FL_NO_ATA_1X) &&
+			(srb->cmnd[0] == ATA_12 || srb->cmnd[0] == ATA_16)) {
+		memcpy(srb->sense_buffer, usb_stor_sense_invalidCDB,
+		       sizeof(usb_stor_sense_invalidCDB));
+		srb->result = SAM_STAT_CHECK_CONDITION;
+		done(srb);
+		return 0;
+	}
+
 	/* enqueue the command and wake up the control thread */
 	srb->scsi_done = done;
 	us->srb = srb;

drivers/usb/storage/unusual_devs.h +7 -0

@@ -2307,6 +2307,13 @@ UNUSUAL_DEV(  0x2735, 0x100b, 0x0000, 0x
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_GO_SLOW ),
 
+/* Reported-by: Tim Anderson <[email protected]> */
+UNUSUAL_DEV(  0x2ca3, 0x0031, 0x0000, 0x9999,
+		"DJI",
+		"CineSSD",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_NO_ATA_1X),
+
 /*
  * Reported by Frederic Marchal <[email protected]>
  * Mio Moov 330

Greg Kroah-Hartman

author maintainer

2018-09-24 12:02 UTC #57 lore raw

PATCH 57/111 usb: uas: add support for more quirk flags

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oliver Neukum <[email protected]>

commit 42d1c6d4a06a77b3ab206a919b9050c3080f3a71 upstream.

The hope that UAS devices would be less broken than old style storage devices has turned out to be unfounded. Make UAS support more of the quirk flags of the old driver.

Signed-off-by Oliver Neukum <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/storage/uas.c |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

drivers/usb/storage/uas.c +21 -0

@@ -842,6 +842,27 @@ static int uas_slave_configure(struct sc
 		sdev->skip_ms_page_8 = 1;
 		sdev->wce_default_on = 1;
 	}
+
+	/*
+	 * Some disks return the total number of blocks in response
+	 * to READ CAPACITY rather than the highest block number.
+	 * If this device makes that mistake, tell the sd driver.
+	 */
+	if (devinfo->flags & US_FL_FIX_CAPACITY)
+		sdev->fix_capacity = 1;
+
+	/*
+	 * Some devices don't like MODE SENSE with page=0x3f,
+	 * which is the command used for checking if a device
+	 * is write-protected.  Now that we tell the sd driver
+	 * to do a 192-byte transfer with this command the
+	 * majority of devices work fine, but a few still can't
+	 * handle it.  The sd driver will simply assume those
+	 * devices are write-enabled.
+	 */
+	if (devinfo->flags & US_FL_NO_WP_DETECT)
+		sdev->skip_ms_page_3f = 1;
+
 	scsi_change_queue_depth(sdev, devinfo->qdepth - 2);
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 12:04 UTC #58 lore raw

PATCH 58/111 usb: Avoid use-after-free by flushing endpoints early in usb_set_interface()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit f9a5b4f58b280c1d26255376713c132f93837621 upstream.

The steps taken by usb core to set a new interface is very different from what is done on the xHC host side.

xHC hardware will do everything in one go. One command is used to set up new endpoints, free old endpoints, check bandwidth, and run the new endpoints.

All this is done by xHC when usb core asks the hcd to check for available bandwidth. At this point usb core has not yet flushed the old endpoints, which will cause use-after-free issues in xhci driver as queued URBs are cancelled on a re-allocated endpoint.

To resolve this add a call to usb_disable_interface() which will flush the endpoints before calling usb_hcd_alloc_bandwidth()

Additional checks in xhci driver will also be implemented to gracefully handle stale URB cancel on freed and re-allocated endpoints

Reported-by Sudip Mukherjee <[email protected]>

Signed-off-by Mathias Nyman <[email protected]>

Acked-by Alan Stern <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/message.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/usb/core/message.c +11 -0

@@ -1279,6 +1279,11 @@ void usb_enable_interface(struct usb_dev
  * is submitted that needs that bandwidth.  Some other operating systems
  * allocate bandwidth early, when a configuration is chosen.
  *
+ * xHCI reserves bandwidth and configures the alternate setting in
+ * usb_hcd_alloc_bandwidth(). If it fails the original interface altsetting
+ * may be disabled. Drivers cannot rely on any particular alternate
+ * setting being in effect after a failure.
+ *
  * This call is synchronous, and may not be used in an interrupt context.
  * Also, drivers must not change altsettings while urbs are scheduled for
  * endpoints in that interface; all such urbs must first be completed

@@ -1314,6 +1319,12 @@ int usb_set_interface(struct usb_device
 			 alternate);
 		return -EINVAL;
 	}
+	/*
+	 * usb3 hosts configure the interface in usb_hcd_alloc_bandwidth,
+	 * including freeing dropped endpoint ring buffers.
+	 * Make sure the interface endpoints are flushed before that
+	 */
+	usb_disable_interface(dev, iface, false);
 
 	/* Make sure we have enough bandwidth for this alternate interface.
 	 * Remove the current alt setting and add the new alt setting.

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #59 lore raw

PATCH 59/111 usb: host: u132-hcd: Fix a sleep-in-atomic-context bug in u132_get_frame()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jia-Ju Bai <[email protected]>

commit 6d4f268fa132742fe96dad22307c68d237356d88 upstream.

i_usX2Y_subs_startup in usbusx2yaudio.c is a completion handler function for the USB driver. So it should not sleep, but it is can sleep according to the function call paths (from bottom to top) in Linux-4.16.

[FUNC] msleep
drivers/usb/host/u132-hcd.c, 2558:
msleep in u132_get_frame
drivers/usb/core/hcd.c, 2231:
[FUNC_PTR]u132_get_frame in usb_hcd_get_frame_number
drivers/usb/core/usb.c, 822:
usb_hcd_get_frame_number in usb_get_current_frame_number
sound/usb/usx2y/usbusx2yaudio.c, 303:
usb_get_current_frame_number in i_usX2Y_urb_complete
sound/usb/usx2y/usbusx2yaudio.c, 366:
i_usX2Y_urb_complete in i_usX2Y_subs_startup

Note that [FUNC_PTR] means a function pointer call is used.

To fix this bug, msleep() is replaced with mdelay().

This bug is found by my static analysis tool DSAC.

Signed-off-by Jia-Ju Bai <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/u132-hcd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/host/u132-hcd.c +1 -1

@@ -2559,7 +2559,7 @@ static int u132_get_frame(struct usb_hcd
 	} else {
 		int frame = 0;
 		dev_err(&u132->platform_dev->dev, "TODO: u132_get_frame\n");
-		msleep(100);
+		mdelay(100);
 		return frame;
 	}
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 12:04 UTC #60 lore raw

PATCH 60/111 USB: add quirk for WORLDE Controller KS49 or Prodipe MIDI 49C USB controller

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Maxence Duprès <[email protected]>

commit 9b83a1c301ad6d24988a128c69b42cbaaf537d82 upstream.

WORLDE Controller KS49 or Prodipe MIDI 49C USB controller cause a -EPROTO error, a communication restart and loop again.

This issue has already been fixed for KS25.
https://lore.kernel.org/patchwork/patch/753077/

I just add device 201 for KS49 in quirks.c to get it works.

Signed-off-by Laurent Roux <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/quirks.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/usb/core/quirks.c +4 -0

@@ -37,6 +37,10 @@ static const struct usb_device_id usb_qu
 	/* CBM - Flash disk */
 	{ USB_DEVICE(0x0204, 0x6025), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* WORLDE Controller KS49 or Prodipe MIDI 49C USB controller */
+	{ USB_DEVICE(0x0218, 0x0201), .driver_info =
+			USB_QUIRK_CONFIG_INTF_STRINGS },
+
 	/* WORLDE easy key (easykey.25) MIDI controller  */
 	{ USB_DEVICE(0x0218, 0x0401), .driver_info =
 			USB_QUIRK_CONFIG_INTF_STRINGS },

Greg Kroah-Hartman

author maintainer

2018-09-24 12:04 UTC #61 lore raw

PATCH 61/111 usb: gadget: udc: renesas_usb3: fix maxpacket size of ep0

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yoshihiro Shimoda <[email protected]>

commit dfe1a51d2a36647f74cbad478801efa7cf394376 upstream.

This patch fixes an issue that maxpacket size of ep0 is incorrect for SuperSpeed. Otherwise, CDC NCM class with SuperSpeed doesn't work correctly on this driver because its control read data size is more than 64 bytes.

Reported-by Junki Kato <[email protected]>

Fixes 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")

Cc <[email protected]> # v4.5+

Signed-off-by Yoshihiro Shimoda <[email protected]>

Tested-by Junki Kato <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/udc/renesas_usb3.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/usb/gadget/udc/renesas_usb3.c +4 -1

@@ -628,12 +628,15 @@ static void usb3_irq_epc_int_1_speed(str
 	switch (speed) {
 	case USB_STA_SPEED_SS:
 		usb3->gadget.speed = USB_SPEED_SUPER;
+		usb3->gadget.ep0->maxpacket = USB3_EP0_SS_MAX_PACKET_SIZE;
 		break;
 	case USB_STA_SPEED_HS:
 		usb3->gadget.speed = USB_SPEED_HIGH;
+		usb3->gadget.ep0->maxpacket = USB3_EP0_HSFS_MAX_PACKET_SIZE;
 		break;
 	case USB_STA_SPEED_FS:
 		usb3->gadget.speed = USB_SPEED_FULL;
+		usb3->gadget.ep0->maxpacket = USB3_EP0_HSFS_MAX_PACKET_SIZE;
 		break;
 	default:
 		usb3->gadget.speed = USB_SPEED_UNKNOWN;

@@ -1858,7 +1861,7 @@ static int renesas_usb3_init_ep(struct r
 			/* for control pipe */
 			usb3->gadget.ep0 = &usb3_ep->ep;
 			usb_ep_set_maxpacket_limit(&usb3_ep->ep,
-						USB3_EP0_HSFS_MAX_PACKET_SIZE);
+						USB3_EP0_SS_MAX_PACKET_SIZE);
 			usb3_ep->ep.caps.type_control = true;
 			usb3_ep->ep.caps.dir_in = true;
 			usb3_ep->ep.caps.dir_out = true;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:04 UTC #62 lore raw

PATCH 62/111 USB: net2280: Fix erroneous synchronization change

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Stern <[email protected]>

commit dec3c23c9aa1815f07d98ae0375b4cbc10971e13 upstream.

Commit f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks") was based on a serious misunderstanding. It introduced regressions into both the dummy-hcd and net2280 drivers.

The problem in dummy-hcd was fixed by commit 7dbd8f4cabd9 ("USB:
dummy-hcd: Fix erroneous synchronization change"), but the problem in net2280 remains. Namely: the ->disconnect(), ->suspend(), ->resume(), and ->reset() callbacks must be invoked without the private lock held; otherwise a deadlock will occur when the callback routine tries to interact with the UDC driver.

This patch largely is a reversion of the relevant parts of f16443a034c7. It also drops the private lock around the calls to ->suspend() and ->resume() (something the earlier patch forgot to do). This is safe from races with device interrupts because it occurs within the interrupt handler.

Finally, the patch changes where the ->disconnect() callback is invoked when net2280_pullup() turns the pullup off. Rather than making the callback from within stop_activity() at a time when dropping the private lock could be unsafe, the callback is moved to a point after the lock has already been dropped.

Signed-off-by Alan Stern <[email protected]>

Fixes f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")

Reported-by D. Ziesche <[email protected]>

Tested-by D. Ziesche <[email protected]>

CC <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/udc/net2280.c |   16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

drivers/usb/gadget/udc/net2280.c +14 -2

@@ -1549,11 +1549,14 @@ static int net2280_pullup(struct usb_gad
 		writel(tmp | BIT(USB_DETECT_ENABLE), &dev->usb->usbctl);
 	} else {
 		writel(tmp & ~BIT(USB_DETECT_ENABLE), &dev->usb->usbctl);
-		stop_activity(dev, dev->driver);
+		stop_activity(dev, NULL);
 	}
 
 	spin_unlock_irqrestore(&dev->lock, flags);
 
+	if (!is_on && dev->driver)
+		dev->driver->disconnect(&dev->gadget);
+
 	return 0;
 }

@@ -2470,8 +2473,11 @@ static void stop_activity(struct net2280
 		nuke(&dev->ep[i]);
 
 	/* report disconnect; the driver is already quiesced */
-	if (driver)
+	if (driver) {
+		spin_unlock(&dev->lock);
 		driver->disconnect(&dev->gadget);
+		spin_lock(&dev->lock);
+	}
 
 	usb_reinit(dev);
 }

@@ -3345,6 +3351,8 @@ next_endpoints:
 		BIT(PCI_RETRY_ABORT_INTERRUPT))
 
 static void handle_stat1_irqs(struct net2280 *dev, u32 stat)
+__releases(dev->lock)
+__acquires(dev->lock)
 {
 	struct net2280_ep	*ep;
 	u32			tmp, num, mask, scratch;

@@ -3385,12 +3393,14 @@ static void handle_stat1_irqs(struct net
 			if (disconnect || reset) {
 				stop_activity(dev, dev->driver);
 				ep0_start(dev);
+				spin_unlock(&dev->lock);
 				if (reset)
 					usb_gadget_udc_reset
 						(&dev->gadget, dev->driver);
 				else
 					(dev->driver->disconnect)
 						(&dev->gadget);
+				spin_lock(&dev->lock);
 				return;
 			}
 		}

@@ -3409,6 +3419,7 @@ static void handle_stat1_irqs(struct net
 	tmp = BIT(SUSPEND_REQUEST_CHANGE_INTERRUPT);
 	if (stat & tmp) {
 		writel(tmp, &dev->regs->irqstat1);
+		spin_unlock(&dev->lock);
 		if (stat & BIT(SUSPEND_REQUEST_INTERRUPT)) {
 			if (dev->driver->suspend)
 				dev->driver->suspend(&dev->gadget);

@@ -3419,6 +3430,7 @@ static void handle_stat1_irqs(struct net
 				dev->driver->resume(&dev->gadget);
 			/* at high speed, note erratum 0133 */
 		}
+		spin_lock(&dev->lock);
 		stat &= ~tmp;
 	}

Greg Kroah-Hartman

author maintainer

2018-09-24 12:09 UTC #63 lore raw

PATCH 63/111 USB: serial: io_ti: fix array underflow in completion handler

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

commit 691a03cfe8ca483f9c48153b869d354e4ae3abef upstream.

As reported by Dan Carpenter, a malicious USB device could set port_number to a negative value and we would underflow the port array in the interrupt completion handler.

As these devices only have one or two ports, fix this by making sure we only consider the seventh bit when determining the port number (and ignore bits 0xb0 which are typically set to 0x30).

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Cc stable <[email protected]>

Reported-by Dan Carpenter <[email protected]>

Signed-off-by Johan Hovold <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/serial/io_ti.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/serial/io_ti.h +1 -1

@@ -178,7 +178,7 @@ struct ump_interrupt {
 }  __attribute__((packed));
 
 
-#define TIUMP_GET_PORT_FROM_CODE(c)	(((c) >> 4) - 3)
+#define TIUMP_GET_PORT_FROM_CODE(c)	(((c) >> 6) & 0x01)
 #define TIUMP_GET_FUNC_FROM_CODE(c)	((c) & 0x0f)
 #define TIUMP_INTERRUPT_CODE_LSR	0x03
 #define TIUMP_INTERRUPT_CODE_MSR	0x04

Greg Kroah-Hartman

author maintainer

2018-09-24 12:04 UTC #64 lore raw

PATCH 64/111 usb: misc: uss720: Fix two sleep-in-atomic-context bugs

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jia-Ju Bai <[email protected]>

commit bc8acc214d3f1cafebcbcd101a695bbac716595d upstream.

async_complete() in uss720.c is a completion handler function for the USB driver. So it should not sleep, but it is can sleep according to the function call paths (from bottom to top) in Linux-4.16.

[FUNC] set_1284_register(GFP_KERNEL) drivers/usb/misc/uss720.c, 372:
set_1284_register in parport_uss720_frob_control
drivers/parport/ieee1284.c, 560:
[FUNC_PTR]parport_uss720_frob_control in parport_ieee1284_ack_data_avail
drivers/parport/ieee1284.c, 577:
parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt
./include/linux/parport.h, 474:
parport_ieee1284_interrupt in parport_generic_irq
drivers/usb/misc/uss720.c, 116:
parport_generic_irq in async_complete

[FUNC] get_1284_register(GFP_KERNEL) drivers/usb/misc/uss720.c, 382:
get_1284_register in parport_uss720_read_status
drivers/parport/ieee1284.c, 555:
[FUNC_PTR]parport_uss720_read_status in parport_ieee1284_ack_data_avail
drivers/parport/ieee1284.c, 577:
parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt
./include/linux/parport.h, 474:
parport_ieee1284_interrupt in parport_generic_irq
drivers/usb/misc/uss720.c, 116:
parport_generic_irq in async_complete

Note that [FUNC_PTR] means a function pointer call is used.

To fix these bugs, GFP_KERNEL is replaced with GFP_ATOMIC.

These bugs are found by my static analysis tool DSAC.

Signed-off-by Jia-Ju Bai <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/misc/uss720.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/usb/misc/uss720.c +2 -2

@@ -385,7 +385,7 @@ static unsigned char parport_uss720_frob
 	mask &= 0x0f;
 	val &= 0x0f;
 	d = (priv->reg[1] & (~mask)) ^ val;
-	if (set_1284_register(pp, 2, d, GFP_KERNEL))
+	if (set_1284_register(pp, 2, d, GFP_ATOMIC))
 		return 0;
 	priv->reg[1] = d;
 	return d & 0xf;

@@ -395,7 +395,7 @@ static unsigned char parport_uss720_read
 {
 	unsigned char ret;
 
-	if (get_1284_register(pp, 1, &ret, GFP_KERNEL))
+	if (get_1284_register(pp, 1, &ret, GFP_ATOMIC))
 		return 0;
 	return ret & 0xf8;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 12:04 UTC #65 lore raw

PATCH 65/111 USB: serial: ti_usb_3410_5052: fix array underflow in completion handler

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

commit 5dfdd24eb3d39d815bc952ae98128e967c9bba49 upstream.

Similarly to a recently reported bug in io_ti, a malicious USB device could set port_number to a negative value and we would underflow the port array in the interrupt completion handler.

As these devices only have one or two ports, fix this by making sure we only consider the seventh bit when determining the port number (and ignore bits 0xb0 which are typically set to 0x30).

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Cc stable <[email protected]>

Signed-off-by Johan Hovold <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/serial/ti_usb_3410_5052.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/serial/ti_usb_3410_5052.c +1 -1

@@ -1129,7 +1129,7 @@ static void ti_break(struct tty_struct *
 
 static int ti_get_port_from_code(unsigned char code)
 {
-	return (code >> 4) - 3;
+	return (code >> 6) & 0x01;
 }
 
 static int ti_get_func_from_code(unsigned char code)

Greg Kroah-Hartman

author maintainer

2018-09-24 12:04 UTC #66 lore raw

PATCH 66/111 USB: yurex: Fix buffer over-read in yurex_write()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ben Hutchings <[email protected]>

commit 7e10f14ebface44a48275c8d6dc1caae3668d5a9 upstream.

If the written data starts with a digit, yurex_write() tries to parse it as an integer using simple_strtoull(). This requires a null- terminator, and currently there's no guarantee that there is one.

(The sample program at
https://github.com/NeoCat/YUREX-driver-for-Linux/blob/master/sample/yurex_clock.pl
writes an integer without a null terminator. It seems like it must have worked by chance!)

Always add a null byte after the written data. Enlarge the buffer to allow for this.

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/misc/yurex.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/usb/misc/yurex.c +3 -2

@@ -431,13 +431,13 @@ static ssize_t yurex_write(struct file *
 {
 	struct usb_yurex *dev;
 	int i, set = 0, retval = 0;
-	char buffer[16];
+	char buffer[16 + 1];
 	char *data = buffer;
 	unsigned long long c, c2 = 0;
 	signed long timeout = 0;
 	DEFINE_WAIT(wait);
 
-	count = min(sizeof(buffer), count);
+	count = min(sizeof(buffer) - 1, count);
 	dev = file->private_data;
 
 	/* verify that we actually have some data to write */

@@ -456,6 +456,7 @@ static ssize_t yurex_write(struct file *
 		retval = -EFAULT;
 		goto error;
 	}
+	buffer[count] = 0;
 	memset(dev->cntl_buffer, CMD_PADDING, YUREX_BUF_SIZE);
 
 	switch (buffer[0]) {

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #67 lore raw

PATCH 67/111 usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jia-Ju Bai <[email protected]>

commit 6e22e3af7bb3a7b9dc53cb4687659f6e63fca427 upstream.

wdm_in_callback() is a completion handler function for the USB driver. So it should not sleep. But it calls service_outstanding_interrupt(), which calls usb_submit_urb() with GFP_KERNEL.

To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.

This bug is found by my static analysis tool DSAC.

Signed-off-by Jia-Ju Bai <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/class/cdc-wdm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/class/cdc-wdm.c +1 -1

@@ -470,7 +470,7 @@ static int service_outstanding_interrupt
 
 	set_bit(WDM_RESPONDING, &desc->flags);
 	spin_unlock_irq(&desc->iuspin);
-	rv = usb_submit_urb(desc->response, GFP_KERNEL);
+	rv = usb_submit_urb(desc->response, GFP_ATOMIC);
 	spin_lock_irq(&desc->iuspin);
 	if (rv) {
 		dev_err(&desc->intf->dev,

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #68 lore raw

PATCH 68/111 Revert "cdc-acm: implement put_char() and flush_chars()"

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oliver Neukum <[email protected]>

commit df3aa13c7bbb307e172c37f193f9a7aa058d4739 upstream.

This reverts commit a81cf9799ad7299b03a4dff020d9685f9ac5f3e0.

The patch causes a regression, which I cannot find the reason for. So let's revert for now, as a revert hurts only performance.

Original report:
I was trying to resolve the problem with Oliver but we don't get any conclusion for 5 months, so I am now sending this to mail list and cdc_acm authors.

I am using simple request-response protocol to obtain the boiller parameters in constant intervals.

A simple one transaction is:
1. opening the /dev/ttyACM0
2. sending the following 10-bytes request to the device:
unsigned char req[] = {0x02, 0xfe, 0x01, 0x05, 0x08, 0x02, 0x01, 0x69, 0xab, 0x03};
3. reading response (frame of 74 bytes length).
4. closing the descriptor
I am doing this transaction with 5 seconds intervals.

Before the bad commit everything was working correctly: I've got a requests and a responses in a timely manner.

After the bad commit more time I am using the kernel module, more problems I have. The graph [2] is showing the problem.

As you can see after module load all seems fine but after about 30 minutes I've got a plenty of EAGAINs when doing read()'s and trying to read back the data.

When I rmmod and insmod the cdc_acm module again, then the situation is starting over again: running ok shortly after load, and more time it is running, more EAGAINs I have when calling read().

As a bonus I can see the problem on the device itself:
The device is configured as you can see here on this screen [3]. It has two transmision LEDs: TX and RX. Blink duration is set for 100ms. This is a recording before the bad commit when all is working fine: [4] And this is with the bad commit: [5]
As you can see the TX led is blinking wrongly long (indicating transmission?) and I have problems doing read() calls (EAGAIN).

Reported-by Mariusz Bialonczyk <[email protected]>

Signed-off-by Oliver Neukum <[email protected]>

Fixes a81cf9799ad7 ("cdc-acm: implement put_char() and flush_chars()")

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/class/cdc-acm.c |   73 --------------------------------------------
 drivers/usb/class/cdc-acm.h |    1 
 2 files changed, 74 deletions(-)

drivers/usb/class/cdc-acm.c +0 ~~-73~~

@@ -705,20 +705,9 @@ static int acm_tty_write(struct tty_stru
 	}
 
 	if (acm->susp_count) {
-		if (acm->putbuffer) {
-			/* now to preserve order */
-			usb_anchor_urb(acm->putbuffer->urb, &acm->delayed);
-			acm->putbuffer = NULL;
-		}
 		usb_anchor_urb(wb->urb, &acm->delayed);
 		spin_unlock_irqrestore(&acm->write_lock, flags);
 		return count;
-	} else {
-		if (acm->putbuffer) {
-			/* at this point there is no good way to handle errors */
-			acm_start_wb(acm, acm->putbuffer);
-			acm->putbuffer = NULL;
-		}
 	}
 
 	stat = acm_start_wb(acm, wb);

@@ -729,66 +718,6 @@ static int acm_tty_write(struct tty_stru
 	return count;
 }
 
-static void acm_tty_flush_chars(struct tty_struct *tty)
-{
-	struct acm *acm = tty->driver_data;
-	struct acm_wb *cur;
-	int err;
-	unsigned long flags;
-
-	spin_lock_irqsave(&acm->write_lock, flags);
-
-	cur = acm->putbuffer;
-	if (!cur) /* nothing to do */
-		goto out;
-
-	acm->putbuffer = NULL;
-	err = usb_autopm_get_interface_async(acm->control);
-	if (err < 0) {
-		cur->use = 0;
-		acm->putbuffer = cur;
-		goto out;
-	}
-
-	if (acm->susp_count)
-		usb_anchor_urb(cur->urb, &acm->delayed);
-	else
-		acm_start_wb(acm, cur);
-out:
-	spin_unlock_irqrestore(&acm->write_lock, flags);
-	return;
-}
-
-static int acm_tty_put_char(struct tty_struct *tty, unsigned char ch)
-{
-	struct acm *acm = tty->driver_data;
-	struct acm_wb *cur;
-	int wbn;
-	unsigned long flags;
-
-overflow:
-	cur = acm->putbuffer;
-	if (!cur) {
-		spin_lock_irqsave(&acm->write_lock, flags);
-		wbn = acm_wb_alloc(acm);
-		if (wbn >= 0) {
-			cur = &acm->wb[wbn];
-			acm->putbuffer = cur;
-		}
-		spin_unlock_irqrestore(&acm->write_lock, flags);
-		if (!cur)
-			return 0;
-	}
-
-	if (cur->len == acm->writesize) {
-		acm_tty_flush_chars(tty);
-		goto overflow;
-	}
-
-	cur->buf[cur->len++] = ch;
-	return 1;
-}
-
 static int acm_tty_write_room(struct tty_struct *tty)
 {
 	struct acm *acm = tty->driver_data;

@@ -1940,8 +1869,6 @@ static const struct tty_operations acm_o
 	.cleanup =		acm_tty_cleanup,
 	.hangup =		acm_tty_hangup,
 	.write =		acm_tty_write,
-	.put_char =		acm_tty_put_char,
-	.flush_chars =		acm_tty_flush_chars,
 	.write_room =		acm_tty_write_room,
 	.ioctl =		acm_tty_ioctl,
 	.throttle =		acm_tty_throttle,

drivers/usb/class/cdc-acm.h +0 -1

@@ -94,7 +94,6 @@ struct acm {
 	unsigned long read_urbs_free;
 	struct urb *read_urbs[ACM_NR];
 	struct acm_rb read_buffers[ACM_NR];
-	struct acm_wb *putbuffer;			/* for acm_tty_put_char() */
 	int rx_buflimit;
 	spinlock_t read_lock;
 	int write_used;					/* number of non-empty write buffers */

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #69 lore raw

PATCH 69/111 cifs: prevent integer overflow in nxt_dir_entry()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit 8ad8aa353524d89fa2e09522f3078166ff78ec42 upstream.

The "old_entry + le32_to_cpu(pDirInfo->NextEntryOffset)" can wrap around so I have added a check for integer overflow.

Reported-by Dr Silvio Cesare of InfoSect <[email protected]>

Reviewed-by Ronnie Sahlberg <[email protected]>

Reviewed-by Aurelien Aptel <[email protected]>

Signed-off-by Steve French <[email protected]>

CC Stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/readdir.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

fs/cifs/readdir.c +9 -2

@@ -376,8 +376,15 @@ static char *nxt_dir_entry(char *old_ent
 
 		new_entry = old_entry + sizeof(FIND_FILE_STANDARD_INFO) +
 				pfData->FileNameLength;
-	} else
-		new_entry = old_entry + le32_to_cpu(pDirInfo->NextEntryOffset);
+	} else {
+		u32 next_offset = le32_to_cpu(pDirInfo->NextEntryOffset);
+
+		if (old_entry + next_offset < old_entry) {
+			cifs_dbg(VFS, "invalid offset %u\n", next_offset);
+			return NULL;
+		}
+		new_entry = old_entry + next_offset;
+	}
 	cifs_dbg(FYI, "new entry %p old entry %p\n", new_entry, old_entry);
 	/* validate that new_entry is not past end of SMB */
 	if (new_entry >= end_of_smb) {

Greg Kroah-Hartman

author maintainer

2018-09-24 12:12 UTC #70 lore raw

PATCH 70/111 CIFS: fix wrapping bugs in num_entries()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit 56446f218af1133c802dad8e9e116f07f381846c upstream.

The problem is that "entryptr + next_offset" and "entryptr + len + size" can wrap. I ended up changing the type of "entryptr" because it makes the math easier when we don't have to do so much casting.

Signed-off-by Steve French <[email protected]>

Reviewed-by Aurelien Aptel <[email protected]>

Reviewed-by Pavel Shilovsky <[email protected]>

CC Stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/smb2pdu.c |   25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

fs/cifs/smb2pdu.c +15 ~~-10~~

@@ -2565,33 +2565,38 @@ num_entries(char *bufstart, char *end_of
 	int len;
 	unsigned int entrycount = 0;
 	unsigned int next_offset = 0;
-	FILE_DIRECTORY_INFO *entryptr;
+	char *entryptr;
+	FILE_DIRECTORY_INFO *dir_info;
 
 	if (bufstart == NULL)
 		return 0;
 
-	entryptr = (FILE_DIRECTORY_INFO *)bufstart;
+	entryptr = bufstart;
 
 	while (1) {
-		entryptr = (FILE_DIRECTORY_INFO *)
-					((char *)entryptr + next_offset);
-
-		if ((char *)entryptr + size > end_of_buf) {
+		if (entryptr + next_offset < entryptr ||
+		    entryptr + next_offset > end_of_buf ||
+		    entryptr + next_offset + size > end_of_buf) {
 			cifs_dbg(VFS, "malformed search entry would overflow\n");
 			break;
 		}
 
-		len = le32_to_cpu(entryptr->FileNameLength);
-		if ((char *)entryptr + len + size > end_of_buf) {
+		entryptr = entryptr + next_offset;
+		dir_info = (FILE_DIRECTORY_INFO *)entryptr;
+
+		len = le32_to_cpu(dir_info->FileNameLength);
+		if (entryptr + len < entryptr ||
+		    entryptr + len > end_of_buf ||
+		    entryptr + len + size > end_of_buf) {
 			cifs_dbg(VFS, "directory entry name would overflow frame end of buf %p\n",
 				 end_of_buf);
 			break;
 		}
 
-		*lastentry = (char *)entryptr;
+		*lastentry = entryptr;
 		entrycount++;
 
-		next_offset = le32_to_cpu(entryptr->NextEntryOffset);
+		next_offset = le32_to_cpu(dir_info->NextEntryOffset);
 		if (!next_offset)
 			break;
 	}

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #71 lore raw

PATCH 71/111 perf/core: Force USER_DS when recording user stack data

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yabin Cui <[email protected]>

commit 02e184476eff848273826c1d6617bb37e5bcc7ad upstream.

Perf can record user stack data in response to a synchronous request, such as a tracepoint firing. If this happens under set_fs(KERNEL_DS), then we end up reading user stack data using __copy_from_user_inatomic() under set_fs(KERNEL_DS). I think this conflicts with the intention of using set_fs(KERNEL_DS). And it is explicitly forbidden by hardware on ARM64 when both CONFIG_ARM64_UAO and CONFIG_ARM64_PAN are used.

So fix this by forcing USER_DS when recording user stack data.

Signed-off-by Yabin Cui <[email protected]>

Acked-by Peter Zijlstra (Intel) <[email protected]>

Cc Alexander Shishkin <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Fixes 88b0193d9418 ("perf/callchain: Force USER_DS when invoking perf_callchain_user()")

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/events/core.c |    4 ++++
 1 file changed, 4 insertions(+)

kernel/events/core.c +4 -0

@@ -5563,6 +5563,7 @@ perf_output_sample_ustack(struct perf_ou
 		unsigned long sp;
 		unsigned int rem;
 		u64 dyn_size;
+		mm_segment_t fs;
 
 		/*
 		 * We dump:

@@ -5580,7 +5581,10 @@ perf_output_sample_ustack(struct perf_ou
 
 		/* Data. */
 		sp = perf_user_stack_pointer(regs);
+		fs = get_fs();
+		set_fs(USER_DS);
 		rem = __output_copy_user(handle, (void *) sp, dump_size);
+		set_fs(fs);
 		dyn_size = dump_size - rem;
 
 		perf_output_skip(handle, rem);

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #72 lore raw

PATCH 72/111 NFSv4.1 fix infinite loop on I/O.

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Trond Myklebust <[email protected]>

commit 994b15b983a72e1148a173b61e5b279219bb45ae upstream.

The previous fix broke recovery of delegated stateids because it assumes that if we did not mark the delegation as suspect, then the delegation has effectively been revoked, and so it removes that delegation irrespectively of whether or not it is valid and still in use. While this is "mostly harmless" for ordinary I/O, we've seen pNFS fail with LAYOUTGET spinning in an infinite loop while complaining that we're using an invalid stateid (in this case the all-zero stateid).

What we rather want to do here is ensure that the delegation is always correctly marked as needing testing when that is the case. So we want to close the loophole offered by nfs4_schedule_stateid_recovery(), which marks the state as needing to be reclaimed, but not the delegation that may be backing it.

Fixes 0e3d3e5df07dc ("NFSv4.1 fix infinite loop on IO BAD_STATEID error")

Signed-off-by Trond Myklebust <[email protected]>

Cc [email protected] # v4.11+

Signed-off-by Anna Schumaker <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/nfs/nfs4proc.c  |   10 +++++++---
 fs/nfs/nfs4state.c |    2 ++
 2 files changed, 9 insertions(+), 3 deletions(-)

fs/nfs/nfs4proc.c +7 -3

@@ -2539,14 +2539,18 @@ static void nfs41_check_delegation_state
 	}
 
 	nfs4_stateid_copy(&stateid, &delegation->stateid);
-	if (test_bit(NFS_DELEGATION_REVOKED, &delegation->flags) ||
-		!test_and_clear_bit(NFS_DELEGATION_TEST_EXPIRED,
-			&delegation->flags)) {
+	if (test_bit(NFS_DELEGATION_REVOKED, &delegation->flags)) {
 		rcu_read_unlock();
 		nfs_finish_clear_delegation_stateid(state, &stateid);
 		return;
 	}
 
+	if (!test_and_clear_bit(NFS_DELEGATION_TEST_EXPIRED,
+				&delegation->flags)) {
+		rcu_read_unlock();
+		return;
+	}
+
 	cred = get_rpccred(delegation->cred);
 	rcu_read_unlock();
 	status = nfs41_test_and_free_expired_stateid(server, &stateid, cred);

fs/nfs/nfs4state.c +2 -0

@@ -1336,6 +1336,8 @@ int nfs4_schedule_stateid_recovery(const
 
 	if (!nfs4_state_mark_reclaim_nograce(clp, state))
 		return -EBADF;
+	nfs_inode_find_delegation_state_and_recover(state->inode,
+			&state->stateid);
 	dprintk("%s: scheduling stateid recovery for server %s\n", __func__,
 			clp->cl_hostname);
 	nfs4_schedule_state_manager(clp);

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #73 lore raw

PATCH 73/111 binfmt_elf: Respect error return from `regset->active

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: "Maciej W. Rozycki" <[email protected]>

[ Upstream commit 2f819db565e82e5f73cd42b39925098986693378 ]

The regset API documented in <linux/regset.h> defines -ENODEV as the result of the ->active' handler to be used where the feature requested is not available on the hardware found. However code handling core file note generation in fill_thread_core_info' interpretes any non-zero result from the `->active' handler as the regset requested being active. Consequently processing continues (and hopefully gracefully fails later on) rather than being abandoned right away for the regset requested.

Fix the problem then by making the code proceed only if a positive result is returned from the `->active' handler.

Signed-off-by Maciej W. Rozycki <[email protected]>

Signed-off-by Paul Burton <[email protected]>

Fixes 4206d3aa1978 ("elf core dump: notes user_regset")

Patchwork: https://patchwork.linux-mips.org/patch/19332/

Cc Alexander Viro <[email protected]>

Cc James Hogan <[email protected]>

Cc Ralf Baechle <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/binfmt_elf.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/binfmt_elf.c +1 -1

@@ -1706,7 +1706,7 @@ static int fill_thread_core_info(struct
 		const struct user_regset *regset = &view->regsets[i];
 		do_thread_regset_writeback(t->task, regset);
 		if (regset->core_note_type && regset->get &&
-		    (!regset->active || regset->active(t->task, regset))) {
+		    (!regset->active || regset->active(t->task, regset) > 0)) {
 			int ret;
 			size_t size = regset->n * regset->size;
 			void *data = kmalloc(size, GFP_KERNEL);

Greg Kroah-Hartman

author maintainer

2018-09-24 13:00 UTC #74 lore raw

PATCH 74/111 audit: fix use-after-free in audit_add_watch

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ronny Chevalier <[email protected]>

[ Upstream commit baa2a4fdd525c8c4b0f704d20457195b29437839 ]

audit_add_watch stores locally krule->watch without taking a reference on watch. Then, it calls audit_add_to_parent, and uses the watch stored locally.

Unfortunately, it is possible that audit_add_to_parent updates krule->watch.
When it happens, it also drops a reference of watch which could free the watch.

How to reproduce (with KASAN enabled):

auditctl -w /etc/passwd -F success=0 -k test_passwd auditctl -w /etc/passwd -F success=1 -k test_passwd2

The second call to auditctl triggers the use-after-free, because audit_to_parent updates krule->watch to use a previous existing watch and drops the reference to the newly created watch.

To fix the issue, we grab a reference of watch and we release it at the end of the function.

Signed-off-by Ronny Chevalier <[email protected]>

Reviewed-by Richard Guy Briggs <[email protected]>

Signed-off-by Paul Moore <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/audit_watch.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

kernel/audit_watch.c +11 -1

@@ -419,6 +419,13 @@ int audit_add_watch(struct audit_krule *
 	struct path parent_path;
 	int h, ret = 0;
 
+	/*
+	 * When we will be calling audit_add_to_parent, krule->watch might have
+	 * been updated and watch might have been freed.
+	 * So we need to keep a reference of watch.
+	 */
+	audit_get_watch(watch);
+
 	mutex_unlock(&audit_filter_mutex);
 
 	/* Avoid calling path_lookup under audit_filter_mutex. */

@@ -427,8 +434,10 @@ int audit_add_watch(struct audit_krule *
 	/* caller expects mutex locked */
 	mutex_lock(&audit_filter_mutex);
 
-	if (ret)
+	if (ret) {
+		audit_put_watch(watch);
 		return ret;
+	}
 
 	/* either find an old parent or attach a new one */
 	parent = audit_find_parent(d_backing_inode(parent_path.dentry));

@@ -446,6 +455,7 @@ int audit_add_watch(struct audit_krule *
 	*list = &audit_inode_hash[h];
 error:
 	path_put(&parent_path);
+	audit_put_watch(watch);
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 12:11 UTC #75 lore raw

PATCH 75/111 mtdchar: fix overflows in adjustment of `count`

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jann Horn <[email protected]>

[ Upstream commit 6c6bc9ea84d0008024606bf5ba10519e20d851bf ]

The first checks in mtdchar_read() and mtdchar_write() attempt to limit count such that *ppos + count <= mtd->size. However, they ignore the possibility of *ppos > mtd->size, allowing the calculation of count to wrap around. mtdchar_lseek() prevents seeking beyond mtd->size, but the pread/pwrite syscalls bypass this.

I haven't found any codepath on which this actually causes dangerous behavior, but it seems like a sensible change anyway.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Signed-off-by Jann Horn <[email protected]>

Signed-off-by Boris Brezillon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mtd/mtdchar.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

drivers/mtd/mtdchar.c +7 -3

@@ -160,8 +160,12 @@ static ssize_t mtdchar_read(struct file
 
 	pr_debug("MTD_read\n");
 
-	if (*ppos + count > mtd->size)
-		count = mtd->size - *ppos;
+	if (*ppos + count > mtd->size) {
+		if (*ppos < mtd->size)
+			count = mtd->size - *ppos;
+		else
+			count = 0;
+	}
 
 	if (!count)
 		return 0;

@@ -246,7 +250,7 @@ static ssize_t mtdchar_write(struct file
 
 	pr_debug("MTD_write\n");
 
-	if (*ppos == mtd->size)
+	if (*ppos >= mtd->size)
 		return -ENOSPC;
 
 	if (*ppos + count > mtd->size)

Greg Kroah-Hartman

author maintainer

2018-09-24 12:11 UTC #76 lore raw

PATCH 76/111 evm: Dont deadlock if a crypto algorithm is unavailable

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matthew Garrett <[email protected]>

[ Upstream commit e2861fa71641c6414831d628a1f4f793b6562580 ]

When EVM attempts to appraise a file signed with a crypto algorithm the kernel doesn't have support for, it will cause the kernel to trigger a module load. If the EVM policy includes appraisal of kernel modules this will in turn call back into EVM - since EVM is holding a lock until the crypto initialisation is complete, this triggers a deadlock. Add a CRYPTO_NOLOAD flag and skip module loading if it's set, and add that flag in the EVM case in order to fail gracefully with an error message instead of deadlocking.

Signed-off-by Matthew Garrett <[email protected]>

Acked-by Herbert Xu <[email protected]>

Signed-off-by Mimi Zohar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 crypto/api.c                        |    2 +-
 include/linux/crypto.h              |    5 +++++
 security/integrity/evm/evm_crypto.c |    3 ++-
 3 files changed, 8 insertions(+), 2 deletions(-)

crypto/api.c +1 -1

@@ -215,7 +215,7 @@ struct crypto_alg *crypto_larval_lookup(
 	type &= mask;
 
 	alg = crypto_alg_lookup(name, type, mask);
-	if (!alg) {
+	if (!alg && !(mask & CRYPTO_NOLOAD)) {
 		request_module("crypto-%s", name);
 
 		if (!((type ^ CRYPTO_ALG_NEED_FALLBACK) & mask &

include/linux/crypto.h +5 -0

@@ -109,6 +109,11 @@
 #define CRYPTO_ALG_OPTIONAL_KEY		0x00004000
 
 /*
+ * Don't trigger module loading
+ */
+#define CRYPTO_NOLOAD			0x00008000
+
+/*
  * Transform masks and values (for crt_flags).
  */
 #define CRYPTO_TFM_NEED_KEY		0x00000001

security/integrity/evm/evm_crypto.c +2 -1

@@ -94,7 +94,8 @@ static struct shash_desc *init_desc(char
 		mutex_lock(&mutex);
 		if (*tfm)
 			goto out;
-		*tfm = crypto_alloc_shash(algo, 0, CRYPTO_ALG_ASYNC);
+		*tfm = crypto_alloc_shash(algo, 0,
+					  CRYPTO_ALG_ASYNC | CRYPTO_NOLOAD);
 		if (IS_ERR(*tfm)) {
 			rc = PTR_ERR(*tfm);
 			pr_err("Can not allocate %s (reason: %ld)\n", algo, rc);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:11 UTC #77 lore raw

PATCH 77/111 MIPS: loongson64: cs5536: Fix PCI_OHCI_INT_REG reads

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Burton <[email protected]>

[ Upstream commit cd87668d601f622e0ebcfea4f78d116d5f572f4d ]

The PCI_OHCI_INT_REG case in pci_ohci_read_reg() contains the following if statement:

if ((lo & 0x00000f00) == CS5536_USB_INTR)

CS5536_USB_INTR expands to the constant 11, which gives us the following condition which can never evaluate true:

if ((lo & 0xf00) == 11)

At least when using GCC 8.1.0 this falls foul of the tautoligcal-compare warning, and since the code is built with the -Werror flag the build fails.

Fix this by shifting lo right by 8 bits in order to match the corresponding PCI_OHCI_INT_REG case in pci_ohci_write_reg().

Signed-off-by Paul Burton <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/19861/

Cc Huacai Chen <[email protected]>

Cc James Hogan <[email protected]>

Cc Ralf Baechle <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/loongson64/common/cs5536/cs5536_ohci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/mips/loongson64/common/cs5536/cs5536_ohci.c +1 -1

@@ -138,7 +138,7 @@ u32 pci_ohci_read_reg(int reg)
 		break;
 	case PCI_OHCI_INT_REG:
 		_rdmsr(DIVIL_MSR_REG(PIC_YSEL_LOW), &hi, &lo);
-		if ((lo & 0x00000f00) == CS5536_USB_INTR)
+		if (((lo >> PIC_YSEL_LOW_USB_SHIFT) & 0xf) == CS5536_USB_INTR)
 			conf_data = 1;
 		break;
 	default:

Greg Kroah-Hartman

author maintainer

2018-09-24 12:11 UTC #78 lore raw

PATCH 78/111 configfs: fix registered group removal

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mike Christie <[email protected]>

[ Upstream commit cc57c07343bd071cdf1915a91a24ab7d40c9b590 ]

This patch fixes a bug where configfs_register_group had added
a group in a tree, and userspace has done a rmdir on a dir somewhere above that group and we hit a kernel crash. The problem is configfs_rmdir will detach everything under it and unlink groups on the default_groups list. It will not unlink groups added with configfs_register_group so when configfs_unregister_group is called to drop its references to the group/items we crash when we try to access the freed dentrys.

The patch just adds a check for if a rmdir has been done above us and if so just does the unlink part of unregistration.

Sorry if you are getting this multiple times. I thouhgt I sent this to some of you and lkml, but I do not see it.

Signed-off-by Mike Christie <[email protected]>

Cc Christoph Hellwig <[email protected]>

Cc Joel Becker <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/configfs/dir.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

fs/configfs/dir.c +11 -0

@@ -1777,6 +1777,16 @@ void configfs_unregister_group(struct co
 	struct dentry *dentry = group->cg_item.ci_dentry;
 	struct dentry *parent = group->cg_item.ci_parent->ci_dentry;
 
+	mutex_lock(&subsys->su_mutex);
+	if (!group->cg_item.ci_parent->ci_group) {
+		/*
+		 * The parent has already been unlinked and detached
+		 * due to a rmdir.
+		 */
+		goto unlink_group;
+	}
+	mutex_unlock(&subsys->su_mutex);
+
 	inode_lock_nested(d_inode(parent), I_MUTEX_PARENT);
 	spin_lock(&configfs_dirent_lock);
 	configfs_detach_prep(dentry, NULL);

@@ -1791,6 +1801,7 @@ void configfs_unregister_group(struct co
 	dput(dentry);
 
 	mutex_lock(&subsys->su_mutex);
+unlink_group:
 	unlink_group(group);
 	mutex_unlock(&subsys->su_mutex);
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #79 lore raw

PATCH 79/111 efi/esrt: Only call efi_mem_reserve() for boot services memory

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ard Biesheuvel <[email protected]>

[ Upstream commit 61f0d55569463a1af897117ff47d202b0ccb2e24 ]

The following commit:

7e1550b8f208 ("efi: Drop type and attribute checks in efi_mem_desc_lookup()")

refactored the implementation of efi_mem_desc_lookup() so that the type check is moved to the callers, one of which is the x86 version of efi_arch_mem_reserve(), where we added a modified check that only takes EFI_BOOT_SERVICES_DATA regions into account.

This is reasonable, since it is the only memory type that requires this, but doing so uncovered some unexpected behavior in the ESRT code, which permits the ESRT table to reside in other types of memory than what the UEFI spec mandates (i.e., EFI_BOOT_SERVICES_DATA), and unconditionally calls efi_mem_reserve() on the region in question. This may result in errors such as

esrt: Reserving ESRT space from 0x000000009c810318 to 0x000000009c810350.
efi: Failed to lookup EFI memory descriptor for 0x000000009c810318

when the ESRT table is not in EFI_BOOT_SERVICES_DATA memory, but we try to reserve it nonetheless.

So make the call to efi_mem_reserve() conditional on the memory type.

Signed-off-by Ard Biesheuvel <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Jones <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/firmware/efi/esrt.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/firmware/efi/esrt.c +2 -1

@@ -333,7 +333,8 @@ void __init efi_esrt_init(void)
 
 	end = esrt_data + size;
 	pr_info("Reserving ESRT space from %pa to %pa.\n", &esrt_data, &end);
-	efi_mem_reserve(esrt_data, esrt_data_size);
+	if (md.type == EFI_BOOT_SERVICES_DATA)
+		efi_mem_reserve(esrt_data, esrt_data_size);
 
 	pr_debug("esrt-init: loaded.\n");
 err_memunmap:

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #80 lore raw

PATCH 80/111 ARM: hisi: handle of_iomap and fix missing of_node_put

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nicholas Mc Guire <[email protected]>

[ Upstream commit d396cb185c0337aae5664b250cdd9a73f6eb1503 ]

Relying on an unchecked of_iomap() which can return NULL is problematic here, an explicit check seems mandatory. Also the call to of_find_compatible_node() returns a device node with refcount incremented therefor an explicit of_node_put() is needed here.

Signed-off-by Nicholas Mc Guire <[email protected]>

Fixes commit 22bae4290457 ("ARM: hi3xxx: add hotplug support")

Signed-off-by Wei Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/mach-hisi/hotplug.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

arch/arm/mach-hisi/hotplug.c +13 -6

@@ -148,13 +148,20 @@ static int hi3xxx_hotplug_init(void)
 	struct device_node *node;
 
 	node = of_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
-	if (node) {
-		ctrl_base = of_iomap(node, 0);
-		id = HI3620_CTRL;
-		return 0;
+	if (!node) {
+		id = ERROR_CTRL;
+		return -ENOENT;
 	}
-	id = ERROR_CTRL;
-	return -ENOENT;
+
+	ctrl_base = of_iomap(node, 0);
+	of_node_put(node);
+	if (!ctrl_base) {
+		id = ERROR_CTRL;
+		return -ENOMEM;
+	}
+
+	id = HI3620_CTRL;
+	return 0;
 }
 
 void hi3xxx_set_cpu(int cpu, bool enable)

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #81 lore raw

PATCH 81/111 ARM: hisi: fix error handling and missing of_node_put

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nicholas Mc Guire <[email protected]>

[ Upstream commit 9f30b5ae0585ca5234fe979294b8f897299dec99 ]

of_iomap() can return NULL which seems critical here and thus should be explicitly flagged so that the cause of system halting can be understood. As of_find_compatible_node() is returning a device node with refcount incremented it must be explicitly decremented here.

Signed-off-by Nicholas Mc Guire <[email protected]>

Fixes commit 7fda91e73155 ("ARM: hisi: enable smp for HiP01")

Signed-off-by Wei Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/mach-hisi/hotplug.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm/mach-hisi/hotplug.c +4 -4

@@ -226,10 +226,10 @@ void hip01_set_cpu(int cpu, bool enable)
 
 	if (!ctrl_base) {
 		np = of_find_compatible_node(NULL, NULL, "hisilicon,hip01-sysctrl");
-		if (np)
-			ctrl_base = of_iomap(np, 0);
-		else
-			BUG();
+		BUG_ON(!np);
+		ctrl_base = of_iomap(np, 0);
+		of_node_put(np);
+		BUG_ON(!ctrl_base);
 	}
 
 	if (enable) {

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #82 lore raw

PATCH 82/111 ARM: hisi: check of_iomap and fix missing of_node_put

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nicholas Mc Guire <[email protected]>

[ Upstream commit 81646a3d39ef14749301374a3a0b8311384cd412 ]

of_find_compatible_node() returns a device node with refcount incremented and thus needs an explicit of_node_put(). Further relying on an unchecked of_iomap() which can return NULL is problematic here, after all ctrl_base is critical enough for hix5hd2_set_cpu() to call BUG() if not available so a check seems mandated here.

Signed-off-by Nicholas Mc Guire <[email protected]>

0002 Fixes: commit 06cc5c1d4d73 ("ARM: hisi: enable hix5hd2 SoC")

Signed-off-by Wei Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/mach-hisi/hotplug.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

arch/arm/mach-hisi/hotplug.c +9 -5

@@ -180,11 +180,15 @@ static bool hix5hd2_hotplug_init(void)
 	struct device_node *np;
 
 	np = of_find_compatible_node(NULL, NULL, "hisilicon,cpuctrl");
-	if (np) {
-		ctrl_base = of_iomap(np, 0);
-		return true;
-	}
-	return false;
+	if (!np)
+		return false;
+
+	ctrl_base = of_iomap(np, 0);
+	of_node_put(np);
+	if (!ctrl_base)
+		return false;
+
+	return true;
 }
 
 void hix5hd2_set_cpu(int cpu, bool enable)

Greg Kroah-Hartman

author maintainer

2018-09-24 12:05 UTC #83 lore raw

PATCH 83/111 gpu: ipu-v3: csi: pass back mbus_code_to_bus_cfg error codes

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Enrico Scholz <[email protected]>

[ Upstream commit d36d0e6309dd8137cf438cbb680e72eb63c81425 ]

mbus_code_to_bus_cfg() can fail on unknown mbus codes; pass back the error to the caller.

Signed-off-by Enrico Scholz <[email protected]>

Signed-off-by Jan Luebbe <[email protected]>

[[email protected] - renamed rc to ret for consistency]

Signed-off-by Philipp Zabel <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/ipu-v3/ipu-csi.c |   20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

drivers/gpu/ipu-v3/ipu-csi.c +16 -4

@@ -316,13 +316,17 @@ static int mbus_code_to_bus_cfg(struct i
 /*
  * Fill a CSI bus config struct from mbus_config and mbus_framefmt.
  */
-static void fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
+static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
 				 struct v4l2_mbus_config *mbus_cfg,
 				 struct v4l2_mbus_framefmt *mbus_fmt)
 {
+	int ret;
+
 	memset(csicfg, 0, sizeof(*csicfg));
 
-	mbus_code_to_bus_cfg(csicfg, mbus_fmt->code);
+	ret = mbus_code_to_bus_cfg(csicfg, mbus_fmt->code);
+	if (ret < 0)
+		return ret;
 
 	switch (mbus_cfg->type) {
 	case V4L2_MBUS_PARALLEL:

@@ -353,6 +357,8 @@ static void fill_csi_bus_cfg(struct ipu_
 		/* will never get here, keep compiler quiet */
 		break;
 	}
+
+	return 0;
 }
 
 int ipu_csi_init_interface(struct ipu_csi *csi,

@@ -362,8 +368,11 @@ int ipu_csi_init_interface(struct ipu_cs
 	struct ipu_csi_bus_config cfg;
 	unsigned long flags;
 	u32 width, height, data = 0;
+	int ret;
 
-	fill_csi_bus_cfg(&cfg, mbus_cfg, mbus_fmt);
+	ret = fill_csi_bus_cfg(&cfg, mbus_cfg, mbus_fmt);
+	if (ret < 0)
+		return ret;
 
 	/* set default sensor frame width and height */
 	width = mbus_fmt->width;

@@ -567,11 +576,14 @@ int ipu_csi_set_mipi_datatype(struct ipu
 	struct ipu_csi_bus_config cfg;
 	unsigned long flags;
 	u32 temp;
+	int ret;
 
 	if (vc > 3)
 		return -EINVAL;
 
-	mbus_code_to_bus_cfg(&cfg, mbus_fmt->code);
+	ret = mbus_code_to_bus_cfg(&cfg, mbus_fmt->code);
+	if (ret < 0)
+		return ret;
 
 	spin_lock_irqsave(&csi->lock, flags);

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #84 lore raw

PATCH 84/111 mmc: tegra: prevent HS200 on Tegra 3

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefan Agner <[email protected]>

[ Upstream commit 127407e36f4fe3a1d5e8b9998b479956ce83a7dc ]

The stack assumes that SDHC controller which support SD3.0 (SDR104) do support HS200. This is not the case for Tegra 3, which does support SD 3.0
but only supports eMMC spec 4.41.

Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not support HS200.

Note that commit 156e14b126ff ("mmc: sdhci: fix caps2 for HS200") added the tie between SD3.0 (SDR104) and HS200. I don't think that this is necessarly true. It is fully legitimate to support SD3.0 and not support HS200. The quirk naming suggests something is broken in the controller, but this is not the case: The controller simply does not support HS200.

Fixes 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes")

Signed-off-by Stefan Agner <[email protected]>

Tested-by Marcel Ziswiler <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/host/sdhci-tegra.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/mmc/host/sdhci-tegra.c +2 -1

@@ -350,7 +350,8 @@ static const struct sdhci_pltfm_data sdh
 		  SDHCI_QUIRK_NO_HISPD_BIT |
 		  SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
 		  SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
-	.quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+	.quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN |
+		   SDHCI_QUIRK2_BROKEN_HS200,
 	.ops  = &tegra_sdhci_ops,
 };

Greg Kroah-Hartman

author maintainer

2018-09-24 12:06 UTC #85 lore raw

PATCH 85/111 mmc: sdhci: do not try to use 3.3V signaling if not supported

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefan Agner <[email protected]>

[ Upstream commit 1b5190c2e74c47ebe4bcecf7a072358ad9f1feaa ]

For eMMC devices it is valid to only support 1.8V signaling. When vqmmc is set to a fixed 1.8V regulator the stack tries to set 3.3V initially and prints the following warning:
mmc1: Switching to 3.3V signalling voltage failed

Clear the MMC_SIGNAL_VOLTAGE_330 flag in case 3.3V is signaling is not available. This prevents the stack from even trying to use 3.3V signaling and avoids the above warning.

Signed-off-by Stefan Agner <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/host/sdhci.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

drivers/mmc/host/sdhci.c +8 -1

@@ -3328,14 +3328,21 @@ int sdhci_setup_host(struct sdhci_host *
 	    mmc_gpio_get_cd(host->mmc) < 0)
 		mmc->caps |= MMC_CAP_NEEDS_POLL;
 
-	/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
 	if (!IS_ERR(mmc->supply.vqmmc)) {
 		ret = regulator_enable(mmc->supply.vqmmc);
+
+		/* If vqmmc provides no 1.8V signalling, then there's no UHS */
 		if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 1700000,
 						    1950000))
 			host->caps1 &= ~(SDHCI_SUPPORT_SDR104 |
 					 SDHCI_SUPPORT_SDR50 |
 					 SDHCI_SUPPORT_DDR50);
+
+		/* In eMMC case vqmmc might be a fixed 1.8V regulator */
+		if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 2700000,
+						    3600000))
+			host->flags &= ~SDHCI_SIGNALING_330;
+
 		if (ret) {
 			pr_warn("%s: Failed to enable vqmmc regulator: %d\n",
 				mmc_hostname(mmc), ret);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:06 UTC #86 lore raw

PATCH 86/111 drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thierry Reding <[email protected]>

[ Upstream commit b59fb482b52269977ee5de205308e5b236a03917 ]

Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the memory controller). Transparently backing DMA memory with an IOMMU prevents Nouveau from properly handling such memory accesses and causes memory access faults.

As a side-note: buffers other than those allocated in instance memory don't need to be physically contiguous from the GPU's perspective since the GPU can map them into contiguous buffers using its own MMU. Mapping these buffers through the IOMMU is unnecessary and will even lead to performance degradation because of the additional translation. One exception to this are compressible buffers which need large pages. In order to enable these large pages, multiple small pages will have to be combined into one large (I/O virtually contiguous) mapping via the IOMMU. However, that is a topic outside the scope of this fix and isn't currently supported. An implementation will want to explicitly create these large pages in the Nouveau driver, so detaching from a DMA/IOMMU mapping would still be required.

Signed-off-by Thierry Reding <[email protected]>

Acked-by Christoph Hellwig <[email protected]>

Reviewed-by Robin Murphy <[email protected]>

Tested-by Nicolas Chauvet <[email protected]>

Signed-off-by Ben Skeggs <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c +13 -0

@@ -23,6 +23,10 @@
 #ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
 #include "priv.h"
 
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+#include <asm/dma-iommu.h>
+#endif
+
 static int
 nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
 {

@@ -95,6 +99,15 @@ nvkm_device_tegra_probe_iommu(struct nvk
 	unsigned long pgsize_bitmap;
 	int ret;
 
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+	if (dev->archdata.mapping) {
+		struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+
+		arm_iommu_detach_device(dev);
+		arm_iommu_release_mapping(mapping);
+	}
+#endif
+
 	if (!tdev->func->iommu_bit)
 		return;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:06 UTC #87 lore raw

PATCH 87/111 parport: sunbpp: fix error return code

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Julia Lawall <[email protected]>

[ Upstream commit faa1a47388b33623e4d504c23569188907b039a0 ]

Return an error code on failure. Change leading spaces to tab on the first if.

Problem found using Coccinelle.

Signed-off-by Julia Lawall <[email protected]>

Signed-off-by Sudip Mukherjee <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/parport/parport_sunbpp.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/parport/parport_sunbpp.c +6 -2

@@ -286,12 +286,16 @@ static int bpp_probe(struct platform_dev
 
 	ops = kmemdup(&parport_sunbpp_ops, sizeof(struct parport_operations),
 		      GFP_KERNEL);
-        if (!ops)
+	if (!ops) {
+		err = -ENOMEM;
 		goto out_unmap;
+	}
 
 	dprintk(("register_port\n"));
-	if (!(p = parport_register_port((unsigned long)base, irq, dma, ops)))
+	if (!(p = parport_register_port((unsigned long)base, irq, dma, ops))) {
+		err = -ENOMEM;
 		goto out_free_ops;
+	}
 
 	p->size = size;
 	p->dev = &op->dev;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:06 UTC #88 lore raw

PATCH 88/111 coresight: Handle errors in finding input/output ports

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Suzuki K Poulose <[email protected]>

[ Upstream commit fe470f5f7f684ed15bc49b6183a64237547910ff ]

If we fail to find the input / output port for a LINK component while enabling a path, we should fail gracefully rather than assuming port "0".

Cc Mathieu Poirier <[email protected]>

Signed-off-by Suzuki K Poulose <[email protected]>

Signed-off-by Mathieu Poirier <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hwtracing/coresight/coresight.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/hwtracing/coresight/coresight.c +5 -2

@@ -107,7 +107,7 @@ static int coresight_find_link_inport(st
 	dev_err(&csdev->dev, "couldn't find inport, parent: %s, child: %s\n",
 		dev_name(&parent->dev), dev_name(&csdev->dev));
 
-	return 0;
+	return -ENODEV;
 }
 
 static int coresight_find_link_outport(struct coresight_device *csdev,

@@ -125,7 +125,7 @@ static int coresight_find_link_outport(s
 	dev_err(&csdev->dev, "couldn't find outport, parent: %s, child: %s\n",
 		dev_name(&csdev->dev), dev_name(&child->dev));
 
-	return 0;
+	return -ENODEV;
 }
 
 static int coresight_enable_sink(struct coresight_device *csdev, u32 mode)

@@ -178,6 +178,9 @@ static int coresight_enable_link(struct
 	else
 		refport = 0;
 
+	if (refport < 0)
+		return refport;
+
 	if (atomic_inc_return(&csdev->refcnt[refport]) == 1) {
 		if (link_ops(csdev)->enable) {
 			ret = link_ops(csdev)->enable(csdev, inport, outport);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:06 UTC #89 lore raw

PATCH 89/111 coresight: tpiu: Fix disabling timeouts

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Robin Murphy <[email protected]>

[ Upstream commit ccff2dfaceaca4517432f5c149594215fe9098cc ]

Probing the TPIU driver under UBSan triggers an out-of-bounds shift warning in coresight_timeout():

...

[    5.677530] UBSAN: Undefined behaviour in drivers/hwtracing/coresight/coresight.c:929:16
[    5.685542] shift exponent 64 is too large for 64-bit type 'long unsigned int'

...

On closer inspection things are exponentially out of whack because we're passing a bitmask where a bit number should be. Amusingly, it seems that both calls will find their expected values by sheer luck and appear to
succeed: 1 << FFCR_FON_MAN ends up at bit 64 which whilst undefined evaluates as zero in practice, while 1 << FFSR_FT_STOPPED finds bit 2 (TCPresent) which apparently is usually tied high.

Following the examples of other drivers, define separate FOO and FOO_BIT macros for masks vs. indices, and put things right.

CC Robert Walker <[email protected]>

CC Mike Leach <[email protected]>

CC Mathieu Poirier <[email protected]>

Fixes 11595db8e17f ("coresight: Fix disabling of CoreSight TPIU")

Signed-off-by Robin Murphy <[email protected]>

Signed-off-by Mathieu Poirier <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hwtracing/coresight/coresight-tpiu.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

drivers/hwtracing/coresight/coresight-tpiu.c +4 -3

@@ -47,8 +47,9 @@
 
 /** register definition **/
 /* FFSR - 0x300 */
-#define FFSR_FT_STOPPED		BIT(1)
+#define FFSR_FT_STOPPED_BIT	1
 /* FFCR - 0x304 */
+#define FFCR_FON_MAN_BIT	6
 #define FFCR_FON_MAN		BIT(6)
 #define FFCR_STOP_FI		BIT(12)

@@ -93,9 +94,9 @@ static void tpiu_disable_hw(struct tpiu_
 	/* Generate manual flush */
 	writel_relaxed(FFCR_STOP_FI | FFCR_FON_MAN, drvdata->base + TPIU_FFCR);
 	/* Wait for flush to complete */
-	coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN, 0);
+	coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN_BIT, 0);
 	/* Wait for formatter to stop */
-	coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED, 1);
+	coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED_BIT, 1);
 
 	CS_LOCK(drvdata->base);
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 11:52 UTC #90 lore raw

PATCH 90/111 gpio: pxa: Fix potential NULL dereference

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Wei Yongjun <[email protected]>

[ Upstream commit 9506755633d0b32ef76f67c345000178e9b0dfc4 ]

platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference a bit later in the code.

This is detected by Coccinelle semantic patch.

@@
expression pdev, res, n, t, e, e1, e2;
@@

res = platform_get_resource(pdev, t, n);
+ if (!res)
+ return -EINVAL;
... when != res == NULL
e = devm_ioremap(e1, res->start, e2);

Signed-off-by Wei Yongjun <[email protected]>

Acked-by Robert Jarzmik <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpio-pxa.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/gpio/gpio-pxa.c +2 -0

@@ -660,6 +660,8 @@ static int pxa_gpio_probe(struct platfor
 	pchip->irq0 = irq0;
 	pchip->irq1 = irq1;
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -EINVAL;
 	gpio_reg_base = devm_ioremap(&pdev->dev, res->start,
 				     resource_size(res));
 	if (!gpio_reg_base)

Greg Kroah-Hartman

author maintainer

2018-09-24 12:06 UTC #91 lore raw

PATCH 91/111 gpiolib: Mark gpio_suffixes array with __maybe_unused

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andy Shevchenko <[email protected]>

[ Upstream commit b23ec59926faf05b0c43680d05671c484e810ac4 ]

Since we put static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it.

Mark gpio_suffixes array with __maybe_unused to hide a compiler warning:

In file included from
drivers/gpio/gpiolib-legacy.c:6:0:
drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]

 static const char * const gpio_suffixes[] = { "gpios", "gpio" };
                           ^~~~~~~~~~~~~
In file included from drivers/gpio/gpiolib-devprop.c:17:0:
drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]
 static const char * const gpio_suffixes[] = { "gpios", "gpio" };
                           ^~~~~~~~~~~~~

Signed-off-by Andy Shevchenko <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpio/gpiolib.h +1 -1

@@ -85,7 +85,7 @@ struct acpi_gpio_info {
 };
 
 /* gpio suffixes used for ACPI and device tree lookup */
-static const char * const gpio_suffixes[] = { "gpios", "gpio" };
+static __maybe_unused const char * const gpio_suffixes[] = { "gpios", "gpio" };
 
 #ifdef CONFIG_OF_GPIO
 struct gpio_desc *of_find_gpio(struct device *dev,

Greg Kroah-Hartman

author maintainer

2018-09-24 12:06 UTC #92 lore raw

PATCH 92/111 mfd: 88pm860x-i2c: switch to i2c_lock_bus(..., I2C_LOCK_SEGMENT)

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Rosin <[email protected]>

[ Upstream commit 8c8f74f327a76604a499fad8c54c15e1c0ee8051 ]

Locking the root adapter for __i2c_transfer will deadlock if the device sits behind a mux-locked I2C mux. Switch to the finer-grained i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not sit behind a mux-locked mux, the two locking variants are equivalent.

Signed-off-by Peter Rosin <[email protected]>

Acked-by Lee Jones <[email protected]>

Signed-off-by Wolfram Sang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mfd/88pm860x-i2c.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/mfd/88pm860x-i2c.c +4 -4

@@ -146,14 +146,14 @@ int pm860x_page_reg_write(struct i2c_cli
 	unsigned char zero;
 	int ret;
 
-	i2c_lock_adapter(i2c->adapter);
+	i2c_lock_bus(i2c->adapter, I2C_LOCK_SEGMENT);
 	read_device(i2c, 0xFA, 0, &zero);
 	read_device(i2c, 0xFB, 0, &zero);
 	read_device(i2c, 0xFF, 0, &zero);
 	ret = write_device(i2c, reg, 1, &data);
 	read_device(i2c, 0xFE, 0, &zero);
 	read_device(i2c, 0xFC, 0, &zero);
-	i2c_unlock_adapter(i2c->adapter);
+	i2c_unlock_bus(i2c->adapter, I2C_LOCK_SEGMENT);
 	return ret;
 }
 EXPORT_SYMBOL(pm860x_page_reg_write);

@@ -164,14 +164,14 @@ int pm860x_page_bulk_read(struct i2c_cli
 	unsigned char zero = 0;
 	int ret;
 
-	i2c_lock_adapter(i2c->adapter);
+	i2c_lock_bus(i2c->adapter, I2C_LOCK_SEGMENT);
 	read_device(i2c, 0xfa, 0, &zero);
 	read_device(i2c, 0xfb, 0, &zero);
 	read_device(i2c, 0xff, 0, &zero);
 	ret = read_device(i2c, reg, count, buf);
 	read_device(i2c, 0xFE, 0, &zero);
 	read_device(i2c, 0xFC, 0, &zero);
-	i2c_unlock_adapter(i2c->adapter);
+	i2c_unlock_bus(i2c->adapter, I2C_LOCK_SEGMENT);
 	return ret;
 }
 EXPORT_SYMBOL(pm860x_page_bulk_read);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:06 UTC #93 lore raw

PATCH 93/111 input: rohm_bu21023: switch to i2c_lock_bus(..., I2C_LOCK_SEGMENT)

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Rosin <[email protected]>

[ Upstream commit 193c2a07cfaacb9249ab0e3d34bce32490879355 ]

Signed-off-by Peter Rosin <[email protected]>

Acked-by Dmitry Torokhov <[email protected]>

Signed-off-by Wolfram Sang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/input/touchscreen/rohm_bu21023.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/input/touchscreen/rohm_bu21023.c +2 -2

@@ -304,7 +304,7 @@ static int rohm_i2c_burst_read(struct i2
 	msg[1].len = len;
 	msg[1].buf = buf;
 
-	i2c_lock_adapter(adap);
+	i2c_lock_bus(adap, I2C_LOCK_SEGMENT);
 
 	for (i = 0; i < 2; i++) {
 		if (__i2c_transfer(adap, &msg[i], 1) < 0) {

@@ -313,7 +313,7 @@ static int rohm_i2c_burst_read(struct i2
 		}
 	}
 
-	i2c_unlock_adapter(adap);
+	i2c_unlock_bus(adap, I2C_LOCK_SEGMENT);
 
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 11:53 UTC #94 lore raw

PATCH 94/111 rcu: Fix grace-period hangs due to race with CPU offline

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: "Paul E. McKenney" <[email protected]>

[ Upstream commit 1e64b15a4b102e1cd059d4d798b7a78f93341333 ]

Without special fail-safe quiescent-state-propagation checks, grace-period hangs can result from the following scenario:

1. CPU 1 goes offline.

2. Because CPU 1 is the only CPU in the system blocking the current
grace period, the grace period ends as soon as rcu_cleanup_dying_idle_cpu()'s call to rcu_report_qs_rnp() returns.

3. At this point, the leaf rcu_node structure's ->lock is no longer
held: rcu_report_qs_rnp() has released it, as it must in order to awaken the RCU grace-period kthread.

4. At this point, that same leaf rcu_node structure's ->qsmaskinitnext
field still records CPU 1 as being online. This is absolutely necessary because the scheduler uses RCU (in this case on the wake-up path while awakening RCU's grace-period kthread), and ->qsmaskinitnext contains RCU's idea as to which CPUs are online. Therefore, invoking rcu_report_qs_rnp() after clearing CPU 1's bit from ->qsmaskinitnext would result in a lockdep-RCU splat due to RCU being used from an offline CPU.

5. RCU's grace-period kthread awakens, sees that the old grace period
has completed and that a new one is needed. It therefore starts a new grace period, but because CPU 1's leaf rcu_node structure's ->qsmaskinitnext field still shows CPU 1 as being online, this new grace period is initialized to wait for a quiescent state from the now-offline CPU 1.

6. Without the fail-safe force-quiescent-state checks, there would
be no quiescent state from the now-offline CPU 1, which would eventually result in RCU CPU stall warnings and memory exhaustion.

It would be good to get rid of the special fail-safe quiescent-state propagation checks, and thus it would be good to fix things so that the above scenario cannot happen. This commit therefore adds a new ->ofl_lock to the rcu_state structure. This lock is held by rcu_gp_init() across the applying of buffered online and offline operations to the rcu_node tree, and it is also held by rcu_cleanup_dying_idle_cpu() when buffering a new offline operation. This prevents rcu_gp_init() from acquiring the leaf rcu_node structure's lock during the interval between when rcu_cleanup_dying_idle_cpu() invokes rcu_report_qs_rnp(), which releases ->lock and the re-acquisition of that same lock. This in turn prevents the failure scenario outlined above, and will hopefully eventually allow removal of the offline-CPU checks from the force-quiescent-state code path.

Signed-off-by Paul E. McKenney <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/rcu/tree.c |    6 ++++++
 kernel/rcu/tree.h |    4 ++++
 2 files changed, 10 insertions(+)

kernel/rcu/tree.c +6 -0

@@ -102,6 +102,7 @@ struct rcu_state sname##_state = { \
 	.abbr = sabbr, \
 	.exp_mutex = __MUTEX_INITIALIZER(sname##_state.exp_mutex), \
 	.exp_wake_mutex = __MUTEX_INITIALIZER(sname##_state.exp_wake_mutex), \
+	.ofl_lock = __SPIN_LOCK_UNLOCKED(sname##_state.ofl_lock), \
 }
 
 RCU_STATE_INITIALIZER(rcu_sched, 's', call_rcu_sched);

@@ -1966,11 +1967,13 @@ static bool rcu_gp_init(struct rcu_state
 	 */
 	rcu_for_each_leaf_node(rsp, rnp) {
 		rcu_gp_slow(rsp, gp_preinit_delay);
+		spin_lock(&rsp->ofl_lock);
 		raw_spin_lock_irq_rcu_node(rnp);
 		if (rnp->qsmaskinit == rnp->qsmaskinitnext &&
 		    !rnp->wait_blkd_tasks) {
 			/* Nothing to do on this leaf rcu_node structure. */
 			raw_spin_unlock_irq_rcu_node(rnp);
+			spin_unlock(&rsp->ofl_lock);
 			continue;
 		}

@@ -2005,6 +2008,7 @@ static bool rcu_gp_init(struct rcu_state
 		}
 
 		raw_spin_unlock_irq_rcu_node(rnp);
+		spin_unlock(&rsp->ofl_lock);
 	}
 
 	/*

@@ -3915,9 +3919,11 @@ static void rcu_cleanup_dying_idle_cpu(i
 
 	/* Remove outgoing CPU from mask in the leaf rcu_node structure. */
 	mask = rdp->grpmask;
+	spin_lock(&rsp->ofl_lock);
 	raw_spin_lock_irqsave_rcu_node(rnp, flags); /* Enforce GP memory-order guarantee. */
 	rnp->qsmaskinitnext &= ~mask;
 	raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
+	spin_unlock(&rsp->ofl_lock);
 }
 
 void rcu_report_dead(unsigned int cpu)

kernel/rcu/tree.h +4 -0

@@ -550,6 +550,10 @@ struct rcu_state {
 	const char *name;			/* Name of structure. */
 	char abbr;				/* Abbreviated name. */
 	struct list_head flavors;		/* List of RCU flavors. */
+
+	spinlock_t ofl_lock ____cacheline_internodealigned_in_smp;
+						/* Synchronize offline with */
+						/*  GP pre-initialization. */
 };
 
 /* Values for rcu_state structure's gp_flags field. */

Paul E. McKenney

2018-09-24 16:45 UTC #95 lore raw

Re: [PATCH 4.9 094/111] rcu: Fix grace-period hangs due to race with CPU offline

Quoted 1 line · Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

And here as well...

This should not be needed in 4.18 because of a number of crude but effective grace-period forward-progress failsafes. I have not tested it in isolation. It looks harmless enough, but all testing has been in conjunction with a large number of preceding patches.

I therefore strongly recommend against backporting this one.

Thanx, Paul

Quoted 121 lines

------------------
From: "Paul E. McKenney" <[email protected]>
[ Upstream commit 1e64b15a4b102e1cd059d4d798b7a78f93341333 ]
Without special fail-safe quiescent-state-propagation checks, grace-period hangs can result from the following scenario:
1. CPU 1 goes offline.
2. Because CPU 1 is the only CPU in the system blocking the current
grace period, the grace period ends as soon as rcu_cleanup_dying_idle_cpu()'s call to rcu_report_qs_rnp() returns.
3. At this point, the leaf rcu_node structure's ->lock is no longer
held: rcu_report_qs_rnp() has released it, as it must in order to awaken the RCU grace-period kthread.
4. At this point, that same leaf rcu_node structure's ->qsmaskinitnext
field still records CPU 1 as being online. This is absolutely necessary because the scheduler uses RCU (in this case on the wake-up path while awakening RCU's grace-period kthread), and ->qsmaskinitnext contains RCU's idea as to which CPUs are online. Therefore, invoking rcu_report_qs_rnp() after clearing CPU 1's bit from ->qsmaskinitnext would result in a lockdep-RCU splat due to RCU being used from an offline CPU.
5. RCU's grace-period kthread awakens, sees that the old grace period
has completed and that a new one is needed. It therefore starts a new grace period, but because CPU 1's leaf rcu_node structure's ->qsmaskinitnext field still shows CPU 1 as being online, this new grace period is initialized to wait for a quiescent state from the now-offline CPU 1.
6. Without the fail-safe force-quiescent-state checks, there would
be no quiescent state from the now-offline CPU 1, which would eventually result in RCU CPU stall warnings and memory exhaustion.
It would be good to get rid of the special fail-safe quiescent-state propagation checks, and thus it would be good to fix things so that the above scenario cannot happen. This commit therefore adds a new ->ofl_lock to the rcu_state structure. This lock is held by rcu_gp_init() across the applying of buffered online and offline operations to the rcu_node tree, and it is also held by rcu_cleanup_dying_idle_cpu() when buffering a new offline operation. This prevents rcu_gp_init() from acquiring the leaf rcu_node structure's lock during the interval between when rcu_cleanup_dying_idle_cpu() invokes rcu_report_qs_rnp(), which releases ->lock and the re-acquisition of that same lock. This in turn prevents the failure scenario outlined above, and will hopefully eventually allow removal of the offline-CPU checks from the force-quiescent-state code path.
Signed-off-by Paul E. McKenney <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 kernel/rcu/tree.c |    6 ++++++
 kernel/rcu/tree.h |    4 ++++
 2 files changed, 10 insertions(+)
kernel/rcu/tree.c +6 -0
@@ -102,6 +102,7 @@ struct rcu_state sname##_state = { \
 	.abbr = sabbr, \
 	.exp_mutex = __MUTEX_INITIALIZER(sname##_state.exp_mutex), \
 	.exp_wake_mutex = __MUTEX_INITIALIZER(sname##_state.exp_wake_mutex), \
+	.ofl_lock = __SPIN_LOCK_UNLOCKED(sname##_state.ofl_lock), \
 }
 
 RCU_STATE_INITIALIZER(rcu_sched, 's', call_rcu_sched);
@@ -1966,11 +1967,13 @@ static bool rcu_gp_init(struct rcu_state
 	 */
 	rcu_for_each_leaf_node(rsp, rnp) {
 		rcu_gp_slow(rsp, gp_preinit_delay);
+		spin_lock(&rsp->ofl_lock);
 		raw_spin_lock_irq_rcu_node(rnp);
 		if (rnp->qsmaskinit == rnp->qsmaskinitnext &&
 		    !rnp->wait_blkd_tasks) {
 			/* Nothing to do on this leaf rcu_node structure. */
 			raw_spin_unlock_irq_rcu_node(rnp);
+			spin_unlock(&rsp->ofl_lock);
 			continue;
 		}
 
@@ -2005,6 +2008,7 @@ static bool rcu_gp_init(struct rcu_state
 		}
 
 		raw_spin_unlock_irq_rcu_node(rnp);
+		spin_unlock(&rsp->ofl_lock);
 	}
 
 	/*
@@ -3915,9 +3919,11 @@ static void rcu_cleanup_dying_idle_cpu(i
 
 	/* Remove outgoing CPU from mask in the leaf rcu_node structure. */
 	mask = rdp->grpmask;
+	spin_lock(&rsp->ofl_lock);
 	raw_spin_lock_irqsave_rcu_node(rnp, flags); /* Enforce GP memory-order guarantee. */
 	rnp->qsmaskinitnext &= ~mask;
 	raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
+	spin_unlock(&rsp->ofl_lock);
 }
 
 void rcu_report_dead(unsigned int cpu)
kernel/rcu/tree.h +4 -0
@@ -550,6 +550,10 @@ struct rcu_state {
 	const char *name;			/* Name of structure. */
 	char abbr;				/* Abbreviated name. */
 	struct list_head flavors;		/* List of RCU flavors. */
+
+	spinlock_t ofl_lock ____cacheline_internodealigned_in_smp;
+						/* Synchronize offline with */
+						/*  GP pre-initialization. */
 };
 
 /* Values for rcu_state structure's gp_flags field. */

Greg Kroah-Hartman

author maintainer

2018-09-24 12:06 UTC #96 lore raw

PATCH 95/111 drm/amdkfd: Fix error codes in kfd_get_process

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Wei Lu <[email protected]>

[ Upstream commit e47cb828eb3fca3e8999a0b9aa053dda18552071 ]

Return ERR_PTR(-EINVAL) if kfd_get_process fails to find the process. This fixes kernel oopses when a child process calls KFD ioctls with a file descriptor inherited from the parent process.

Signed-off-by Wei Lu <[email protected]>

Reviewed-by Felix Kuehling <[email protected]>

Signed-off-by Felix Kuehling <[email protected]>

Acked-by Christian König <[email protected]>

Signed-off-by Oded Gabbay <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/amd/amdkfd/kfd_process.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/gpu/drm/amd/amdkfd/kfd_process.c +2 -0

@@ -124,6 +124,8 @@ struct kfd_process *kfd_get_process(cons
 		return ERR_PTR(-EINVAL);
 
 	process = find_process(thread);
+	if (!process)
+		return ERR_PTR(-EINVAL);
 
 	return process;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 12:07 UTC #97 lore raw

PATCH 96/111 rtc: bq4802: add error handling for devm_ioremap

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zhouyang Jia <[email protected]>

[ Upstream commit 7874b919866ba91bac253fa219d3d4c82bb944df ]

When devm_ioremap fails, the lack of error-handling code may cause unexpected results.

This patch adds error-handling code after calling devm_ioremap.

Signed-off-by Zhouyang Jia <[email protected]>

Signed-off-by Alexandre Belloni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/rtc/rtc-bq4802.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/rtc/rtc-bq4802.c +4 -0

@@ -164,6 +164,10 @@ static int bq4802_probe(struct platform_
 	} else if (p->r->flags & IORESOURCE_MEM) {
 		p->regs = devm_ioremap(&pdev->dev, p->r->start,
 					resource_size(p->r));
+		if (!p->regs){
+			err = -ENOMEM;
+			goto out;
+		}
 		p->read = bq4802_read_mem;
 		p->write = bq4802_write_mem;
 	} else {

Greg Kroah-Hartman

author maintainer

2018-09-24 12:07 UTC #98 lore raw

PATCH 97/111 ALSA: pcm: Fix snd_interval_refine first/last with open min/max

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Timo Wischer <[email protected]>

[ Upstream commit ff2d6acdf6f13d9f8fdcd890844c6d7535ac1f10 ]

Without this commit the following intervals [x y), (x y) were be replaced to (y-1 y) by snd_interval_refine_last(). This was also done if y-1 is part of the previous interval.
With this changes it will be replaced with [y-1 y) in case of y-1 is part of the previous interval. A similar behavior will be used for snd_interval_refine_first().

This commit adapts the changes for alsa-lib of commit 9bb985c ("pcm: snd_interval_refine_first/last: exclude value only if also excluded before")

Signed-off-by Timo Wischer <[email protected]>

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/core/pcm_lib.c |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

sound/core/pcm_lib.c +10 -4

@@ -648,27 +648,33 @@ EXPORT_SYMBOL(snd_interval_refine);
 
 static int snd_interval_refine_first(struct snd_interval *i)
 {
+	const unsigned int last_max = i->max;
+
 	if (snd_BUG_ON(snd_interval_empty(i)))
 		return -EINVAL;
 	if (snd_interval_single(i))
 		return 0;
 	i->max = i->min;
-	i->openmax = i->openmin;
-	if (i->openmax)
+	if (i->openmin)
 		i->max++;
+	/* only exclude max value if also excluded before refine */
+	i->openmax = (i->openmax && i->max >= last_max);
 	return 1;
 }
 
 static int snd_interval_refine_last(struct snd_interval *i)
 {
+	const unsigned int last_min = i->min;
+
 	if (snd_BUG_ON(snd_interval_empty(i)))
 		return -EINVAL;
 	if (snd_interval_single(i))
 		return 0;
 	i->min = i->max;
-	i->openmin = i->openmax;
-	if (i->openmin)
+	if (i->openmax)
 		i->min--;
+	/* only exclude min value if also excluded before refine */
+	i->openmin = (i->openmin && i->min <= last_min);
 	return 1;
 }

Greg Kroah-Hartman

author maintainer

2018-09-24 11:53 UTC #99 lore raw

PATCH 98/111 selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET/other clock adjustments are in progress

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: John Stultz <john.stultz at linaro.org>

[ Upstream commit 1416270f4a1ae83ea84156ceba19a66a8f88be1f ]

In the past we've warned when ADJ_OFFSET was in progress, usually caused by ntpd or some other time adjusting daemon running in non steady sate, which can cause the skew calculations to be incorrect.

Thus, this patch checks to see if the clock was being adjusted when we fail so that we don't cause false negatives.

Cc Thomas Gleixner <tglx at linutronix.de>

Cc Ingo Molnar <mingo at kernel.org>

Cc Miroslav Lichvar <mlichvar at redhat.com>

Cc Richard Cochran <richardcochran at gmail.com>

Cc Prarit Bhargava <prarit at redhat.com>

Cc Stephen Boyd <sboyd at kernel.org>

Cc Shuah Khan <shuah at kernel.org>

Cc linux-kselftest at vger.kernel.org

Suggested-by Miroslav Lichvar <mlichvar at redhat.com>

Signed-off-by John Stultz <john.stultz at linaro.org>

Signed-off-by Greg Kroah-Hartman <gregkh at linuxfoundation.org>

---
v2: Widened the checks to look for other clock adjustments that
could happen, as suggested by Miroslav
v3: Fixed up commit message
Signed-off-by: Sasha Levin <alexander.levin at microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

---
 tools/testing/selftests/timers/raw_skew.c |    5 +++++
 1 file changed, 5 insertions(+)

tools/testing/selftests/timers/raw_skew.c +5 -0

@@ -146,6 +146,11 @@ int main(int argv, char **argc)
 	printf(" %lld.%i(act)", ppm/1000, abs((int)(ppm%1000)));
 
 	if (llabs(eppm - ppm) > 1000) {
+		if (tx1.offset || tx2.offset ||
+		    tx1.freq != tx2.freq || tx1.tick != tx2.tick) {
+			printf("	[SKIP]\n");
+			return ksft_exit_skip("The clock was adjusted externally. Shutdown NTPd or other time sync daemons\n");
+		}
 		printf("	[FAILED]\n");
 		return ksft_exit_fail();
 	}

Greg Kroah-Hartman

author maintainer

2018-09-24 11:53 UTC #100 lore raw

PATCH 99/111 drm/panel: type promotion bug in s6e8aa0_read_mtp_id()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit cd0e0ca69109d025b1a1b6609f70682db62138b0 ]

The ARRAY_SIZE() macro is type size_t. If s6e8aa0_dcs_read() returns a negative error code, then "ret < ARRAY_SIZE(id)" is false because the negative error code is type promoted to a high positive value.

Fixes 02051ca06371 ("drm/panel: add S6E8AA0 driver")

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Reviewed-by Andrzej Hajda <[email protected]>

Signed-off-by Thierry Reding <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c +1 -1

@@ -823,7 +823,7 @@ static void s6e8aa0_read_mtp_id(struct s
 	int ret, i;
 
 	ret = s6e8aa0_dcs_read(ctx, 0xd1, id, ARRAY_SIZE(id));
-	if (ret < ARRAY_SIZE(id) || id[0] == 0x00) {
+	if (ret < 0 || ret < ARRAY_SIZE(id) || id[0] == 0x00) {
 		dev_err(ctx->dev, "read id failed\n");
 		ctx->error = -EIO;
 		return;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:07 UTC #101 lore raw

PATCH 100/111 IB/nes: Fix a compiler warning

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bart Van Assche <[email protected]>

[ Upstream commit 4c5743bc4fe3233cecc1c184a773c79c8ee45bbe ]

Avoid that the following compiler warning is reported when building with W=1:

drivers/infiniband/hw/nes/nes_hw.c:646:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]

Signed-off-by Bart Van Assche <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/hw/nes/nes.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/infiniband/hw/nes/nes.h +1 -1

@@ -156,7 +156,7 @@ do { \
 
 #define NES_EVENT_TIMEOUT   1200000
 #else
-#define nes_debug(level, fmt, args...)
+#define nes_debug(level, fmt, args...) do {} while (0)
 #define assert(expr)          do {} while (0)
 
 #define NES_EVENT_TIMEOUT   100000

Greg Kroah-Hartman

author maintainer

2018-09-24 12:07 UTC #102 lore raw

PATCH 101/111 gpiolib: Respect error code of ->get_direction()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andy Shevchenko <[email protected]>

[ Upstream commit 36b312792b97933dc07abe074f50941199bd357c ]

In case we try to lock GPIO pin as IRQ when something going wrong we print a misleading message.

Correct this by checking an error code from ->get_direction() in gpiochip_lock_as_irq() and printing a corresponding message.

Signed-off-by Andy Shevchenko <[email protected]>

Cc Mika Westerberg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/gpio/gpiolib.c +6 -0

@@ -2749,6 +2749,12 @@ int gpiochip_lock_as_irq(struct gpio_chi
 	if (!chip->can_sleep && chip->get_direction) {
 		int dir = chip->get_direction(chip, offset);
 
+		if (dir < 0) {
+			chip_err(chip, "%s: cannot get GPIO direction\n",
+				 __func__);
+			return dir;
+		}
+
 		if (dir)
 			clear_bit(FLAG_IS_OUT, &desc->flags);
 		else

Greg Kroah-Hartman

author maintainer

2018-09-24 12:07 UTC #103 lore raw

PATCH 102/111 pinctrl: qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Douglas Anderson <[email protected]>

[ Upstream commit 1cf86bc21257a330e3af51f2a4e885f1a705f6a5 ]

If you do this on an sdm845 board:
grep "" /sys/kernel/debug/pinctrl/*spmi:pmic*/pinconf-groups

...it looks like nonsense. For every pin you see listed:
input bias disabled, input bias high impedance, input bias pull down, input bias pull up, ...

That's because pmic_gpio_config_get() isn't complying with the rules that pinconf_generic_dump_one() expects. Specifically for boolean parameters (anything with a "struct pin_config_item" where has_arg is false) the function expects that the function should return its value not through the "config" parameter but should return "0" if the value is set and "-EINVAL" if the value isn't set.

Let's fix this.

Quoted 1 line

From a quick sample of other pinctrl drivers, it appears to be

tradition to also return 1 through the config parameter for these boolean parameters when they exist. I'm not one to knock tradition, so I'll follow tradition and return 1 in these cases. While I'm at it, I'll also continue searching for four leaf clovers, kocking on wood three times, and trying not to break mirrors.

NOTE: This also fixes an apparent typo for reading PIN_CONFIG_BIAS_DISABLE where the old driver was accidentally using "=" instead of "==" and thus was setting some internal state when you tried to query PIN_CONFIG_BIAS_DISABLE. Oops.

Fixes eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver")

Signed-off-by Douglas Anderson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c |   32 +++++++++++++++++++++++--------
 1 file changed, 24 insertions(+), 8 deletions(-)

drivers/pinctrl/qcom/pinctrl-spmi-gpio.c +24 -8

@@ -287,31 +287,47 @@ static int pmic_gpio_config_get(struct p
 
 	switch (param) {
 	case PIN_CONFIG_DRIVE_PUSH_PULL:
-		arg = pad->buffer_type == PMIC_GPIO_OUT_BUF_CMOS;
+		if (pad->buffer_type != PMIC_GPIO_OUT_BUF_CMOS)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_DRIVE_OPEN_DRAIN:
-		arg = pad->buffer_type == PMIC_GPIO_OUT_BUF_OPEN_DRAIN_NMOS;
+		if (pad->buffer_type != PMIC_GPIO_OUT_BUF_OPEN_DRAIN_NMOS)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_DRIVE_OPEN_SOURCE:
-		arg = pad->buffer_type == PMIC_GPIO_OUT_BUF_OPEN_DRAIN_PMOS;
+		if (pad->buffer_type != PMIC_GPIO_OUT_BUF_OPEN_DRAIN_PMOS)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_PULL_DOWN:
-		arg = pad->pullup == PMIC_GPIO_PULL_DOWN;
+		if (pad->pullup != PMIC_GPIO_PULL_DOWN)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_DISABLE:
-		arg = pad->pullup = PMIC_GPIO_PULL_DISABLE;
+		if (pad->pullup != PMIC_GPIO_PULL_DISABLE)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_PULL_UP:
-		arg = pad->pullup == PMIC_GPIO_PULL_UP_30;
+		if (pad->pullup != PMIC_GPIO_PULL_UP_30)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
-		arg = !pad->is_enabled;
+		if (pad->is_enabled)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_POWER_SOURCE:
 		arg = pad->power_source;
 		break;
 	case PIN_CONFIG_INPUT_ENABLE:
-		arg = pad->input_enabled;
+		if (!pad->input_enabled)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_OUTPUT:
 		arg = pad->out_value;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:07 UTC #104 lore raw

PATCH 103/111 mei: bus: type promotion bug in mei_nfc_if_version()

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit b40b3e9358fbafff6a4ba0f4b9658f6617146f9c upstream.

We accidentally removed the check for negative returns without considering the issue of type promotion.
The "if_version_length" variable is type size_t so if __mei_cl_recv() returns a negative then "bytes_recv" is type promoted
to a high positive value and treated as success.

Fixes 582ab27a063a ("mei: bus: fix received data size check in NFC fixup")

Signed-off-by Tomas Winkler <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/mei/bus-fixup.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/misc/mei/bus-fixup.c +1 -1

@@ -178,7 +178,7 @@ static int mei_nfc_if_version(struct mei
 
 	ret = 0;
 	bytes_recv = __mei_cl_recv(cl, (u8 *)reply, if_version_length);
-	if (bytes_recv < if_version_length) {
+	if (bytes_recv < 0 || bytes_recv < if_version_length) {
 		dev_err(bus->dev, "Could not read IF version\n");
 		ret = -EIO;
 		goto err;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:07 UTC #105 lore raw

PATCH 104/111 MIPS: VDSO: Match data page cache colouring when D$ aliases

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Burton <[email protected]>

commit 0f02cfbc3d9e413d450d8d0fd660077c23f67eff upstream.

When a system suffers from dcache aliasing a user program may observe stale VDSO data from an aliased cache line. Notably this can break the expectation that clock_gettime(CLOCK_MONOTONIC, ...) is, as its name suggests, monotonic.

In order to ensure that users observe updates to the VDSO data page as intended, align the user mappings of the VDSO data page such that their cache colouring matches that of the virtual address range which the kernel will use to update the data page - typically its unmapped address within kseg0.

This ensures that we don't introduce aliasing cache lines for the VDSO data page, and therefore that userland will observe updates without requiring cache invalidation.

Signed-off-by Paul Burton <[email protected]>

Reported-by Hauke Mehrtens <[email protected]>

Reported-by Rene Nielsen <[email protected]>

Reported-by Alexandre Belloni <[email protected]>

Fixes ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")

Patchwork: https://patchwork.linux-mips.org/patch/20344/

Tested-by Alexandre Belloni <[email protected]>

Tested-by Hauke Mehrtens <[email protected]>

Cc James Hogan <[email protected]>

Cc [email protected] # v4.4+

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/kernel/vdso.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

arch/mips/kernel/vdso.c +20 -0

@@ -14,12 +14,14 @@
 #include <linux/init.h>
 #include <linux/ioport.h>
 #include <linux/irqchip/mips-gic.h>
+#include <linux/kernel.h>
 #include <linux/mm.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/timekeeper_internal.h>
 
 #include <asm/abi.h>
+#include <asm/page.h>
 #include <asm/vdso.h>
 
 /* Kernel-provided data used by the VDSO. */

@@ -129,12 +131,30 @@ int arch_setup_additional_pages(struct l
 	vvar_size = gic_size + PAGE_SIZE;
 	size = vvar_size + image->size;
 
+	/*
+	 * Find a region that's large enough for us to perform the
+	 * colour-matching alignment below.
+	 */
+	if (cpu_has_dc_aliases)
+		size += shm_align_mask + 1;
+
 	base = get_unmapped_area(NULL, 0, size, 0, 0);
 	if (IS_ERR_VALUE(base)) {
 		ret = base;
 		goto out;
 	}
 
+	/*
+	 * If we suffer from dcache aliasing, ensure that the VDSO data page
+	 * mapping is coloured the same as the kernel's mapping of that memory.
+	 * This ensures that when the kernel updates the VDSO data userland
+	 * will observe it without requiring cache invalidations.
+	 */
+	if (cpu_has_dc_aliases) {
+		base = __ALIGN_MASK(base, shm_align_mask);
+		base += ((unsigned long)&vdso_data - gic_size) & shm_align_mask;
+	}
+
 	data_addr = base + gic_size;
 	vdso_addr = data_addr + PAGE_SIZE;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:07 UTC #106 lore raw

PATCH 105/111 e1000e: Remove Other from EIAC

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Poirier <[email protected]>

commit 745d0bd3af99ccc8c5f5822f808cd133eadad6ac upstream.

It was reported that emulated e1000e devices in vmware esxi 6.5 Build 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts", v4.15-rc1). Some tracing shows that after e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other() on emulated e1000e devices. In comparison, on real e1000e 82574 hardware, icr=0x80000004 (_INT_ASSERTED | _LSC) in the same situation.

Some experimentation showed that this flaw in vmware e1000e emulation can be worked around by not setting Other in EIAC. This is how it was before 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1).

Fixes 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")

[bwh: Backported to 4.9: adjust context]

Cc Yanhui He <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

drivers/net/ethernet/intel/e1000e/netdev.c +3 -2

@@ -1915,6 +1915,8 @@ static irqreturn_t e1000_msix_other(int
 	bool enable = true;
 
 	icr = er32(ICR);
+	ew32(ICR, E1000_ICR_OTHER);
+
 	if (icr & E1000_ICR_RXO) {
 		ew32(ICR, E1000_ICR_RXO);
 		enable = false;

@@ -2037,7 +2039,6 @@ static void e1000_configure_msix(struct
 		       hw->hw_addr + E1000_EITR_82574(vector));
 	else
 		writel(1, hw->hw_addr + E1000_EITR_82574(vector));
-	adapter->eiac_mask |= E1000_IMS_OTHER;
 
 	/* Cause Tx interrupts on every write back */
 	ivar |= BIT(31);

@@ -2262,7 +2263,7 @@ static void e1000_irq_enable(struct e100
 
 	if (adapter->msix_entries) {
 		ew32(EIAC_82574, adapter->eiac_mask & E1000_EIAC_MASK_82574);
-		ew32(IMS, adapter->eiac_mask | E1000_IMS_LSC);
+		ew32(IMS, adapter->eiac_mask | E1000_IMS_OTHER | E1000_IMS_LSC);
 	} else if ((hw->mac.type == e1000_pch_lpt) ||
 		   (hw->mac.type == e1000_pch_spt)) {
 		ew32(IMS, IMS_ENABLE_MASK | E1000_IMS_ECCER);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:07 UTC #107 lore raw

PATCH 106/111 Partial revert "e1000e: Avoid receiver overrun interrupt bursts"

Link https://www.spinics.net/lists/netdev/msg480675.html

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Poirier <[email protected]>

commit 1f0ea19722ef9dfa229a9540f70b8d1c34a98a6a upstream.

This partially reverts commit 4aea7a5c5e940c1723add439f4088844cd26196d.

We keep the fix for the first part of the problem (1) described in the log of that commit, that is to read ICR in the other interrupt handler. We remove the fix for the second part of the problem (2), Other interrupt throttling.

Bursts of "Other" interrupts may once again occur during rxo (receive overflow) traffic conditions. This is deemed acceptable in the interest of avoiding unforeseen fallout from changes that are not strictly necessary. As discussed, the e1000e driver should be in "maintenance mode".

Cc Yanhui He <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/e1000e/netdev.c |   16 ++--------------
 1 file changed, 2 insertions(+), 14 deletions(-)

drivers/net/ethernet/intel/e1000e/netdev.c +2 ~~-14~~

@@ -1912,21 +1912,10 @@ static irqreturn_t e1000_msix_other(int
 	struct e1000_adapter *adapter = netdev_priv(netdev);
 	struct e1000_hw *hw = &adapter->hw;
 	u32 icr;
-	bool enable = true;
 
 	icr = er32(ICR);
 	ew32(ICR, E1000_ICR_OTHER);
 
-	if (icr & E1000_ICR_RXO) {
-		ew32(ICR, E1000_ICR_RXO);
-		enable = false;
-		/* napi poll will re-enable Other, make sure it runs */
-		if (napi_schedule_prep(&adapter->napi)) {
-			adapter->total_rx_bytes = 0;
-			adapter->total_rx_packets = 0;
-			__napi_schedule(&adapter->napi);
-		}
-	}
 	if (icr & E1000_ICR_LSC) {
 		ew32(ICR, E1000_ICR_LSC);
 		hw->mac.get_link_status = true;

@@ -1935,7 +1924,7 @@ static irqreturn_t e1000_msix_other(int
 			mod_timer(&adapter->watchdog_timer, jiffies + 1);
 	}
 
-	if (enable && !test_bit(__E1000_DOWN, &adapter->state))
+	if (!test_bit(__E1000_DOWN, &adapter->state))
 		ew32(IMS, E1000_IMS_OTHER);
 
 	return IRQ_HANDLED;

@@ -2706,8 +2695,7 @@ static int e1000e_poll(struct napi_struc
 		napi_complete_done(napi, work_done);
 		if (!test_bit(__E1000_DOWN, &adapter->state)) {
 			if (adapter->msix_entries)
-				ew32(IMS, adapter->rx_ring->ims_val |
-				     E1000_IMS_OTHER);
+				ew32(IMS, adapter->rx_ring->ims_val);
 			else
 				e1000_irq_enable(adapter);
 		}

Greg Kroah-Hartman

author maintainer

2018-09-24 12:08 UTC #108 lore raw

PATCH 107/111 e1000e: Fix queue interrupt re-raising in Other interrupt

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Poirier <[email protected]>

commit 361a954e6a7215de11a6179ad9bdc07d7e394b04 upstream.

Restores the ICS write for Rx/Tx queue interrupts which was present before commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1) but was not restored in commit 4aea7a5c5e94
("e1000e: Avoid receiver overrun interrupt bursts", v4.15-rc1).

This re-raises the queue interrupts in case the txq or rxq bits were set in ICR and the Other interrupt handler read and cleared ICR before the queue interrupt was raised.

Fixes 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")

Cc Yanhui He <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/e1000e/netdev.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/net/ethernet/intel/e1000e/netdev.c +3 -0

@@ -1916,6 +1916,9 @@ static irqreturn_t e1000_msix_other(int
 	icr = er32(ICR);
 	ew32(ICR, E1000_ICR_OTHER);
 
+	if (icr & adapter->eiac_mask)
+		ew32(ICS, (icr & adapter->eiac_mask));
+
 	if (icr & E1000_ICR_LSC) {
 		ew32(ICR, E1000_ICR_LSC);
 		hw->mac.get_link_status = true;

Greg Kroah-Hartman

author maintainer

2018-09-24 12:08 UTC #109 lore raw

PATCH 108/111 e1000e: Avoid missed interrupts following ICR read

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Poirier <[email protected]>

commit 116f4a640b3197401bc93b8adc6c35040308ceff upstream.

The 82574 specification update errata 12 states that interrupts may be missed if ICR is read while INT_ASSERTED is not set. Avoid that problem by setting all bits related to events that can trigger the Other interrupt in IMS.

The Other interrupt is raised for such events regardless of whether or not they are set in IMS. However, only when they are set is the INT_ASSERTED bit also set in ICR.

By doing this, we ensure that INT_ASSERTED is always set when we read ICR in e1000_msix_other() and steer clear of the errata. This also ensures that ICR will automatically be cleared on read, therefore we no longer need to clear bits explicitly.

[bwh: Backported to 4.9: adjust context]

Cc Yanhui He <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/e1000e/defines.h |   21 ++++++++++++++++++++-
 drivers/net/ethernet/intel/e1000e/netdev.c  |   11 ++++-------
 2 files changed, 24 insertions(+), 8 deletions(-)

drivers/net/ethernet/intel/e1000e/defines.h +20 -1

@@ -400,6 +400,10 @@
 #define E1000_ICR_RXDMT0        0x00000010 /* Rx desc min. threshold (0) */
 #define E1000_ICR_RXO           0x00000040 /* Receiver Overrun */
 #define E1000_ICR_RXT0          0x00000080 /* Rx timer intr (ring 0) */
+#define E1000_ICR_MDAC          0x00000200 /* MDIO Access Complete */
+#define E1000_ICR_SRPD          0x00010000 /* Small Receive Packet Detected */
+#define E1000_ICR_ACK           0x00020000 /* Receive ACK Frame Detected */
+#define E1000_ICR_MNG           0x00040000 /* Manageability Event Detected */
 #define E1000_ICR_ECCER         0x00400000 /* Uncorrectable ECC Error */
 /* If this bit asserted, the driver should claim the interrupt */
 #define E1000_ICR_INT_ASSERTED	0x80000000

@@ -407,7 +411,7 @@
 #define E1000_ICR_RXQ1          0x00200000 /* Rx Queue 1 Interrupt */
 #define E1000_ICR_TXQ0          0x00400000 /* Tx Queue 0 Interrupt */
 #define E1000_ICR_TXQ1          0x00800000 /* Tx Queue 1 Interrupt */
-#define E1000_ICR_OTHER         0x01000000 /* Other Interrupts */
+#define E1000_ICR_OTHER         0x01000000 /* Other Interrupt */
 
 /* PBA ECC Register */
 #define E1000_PBA_ECC_COUNTER_MASK  0xFFF00000 /* ECC counter mask */

@@ -431,12 +435,27 @@
 	E1000_IMS_RXSEQ  |    \
 	E1000_IMS_LSC)
 
+/* These are all of the events related to the OTHER interrupt.
+ */
+#define IMS_OTHER_MASK ( \
+	E1000_IMS_LSC  | \
+	E1000_IMS_RXO  | \
+	E1000_IMS_MDAC | \
+	E1000_IMS_SRPD | \
+	E1000_IMS_ACK  | \
+	E1000_IMS_MNG)
+
 /* Interrupt Mask Set */
 #define E1000_IMS_TXDW      E1000_ICR_TXDW      /* Transmit desc written back */
 #define E1000_IMS_LSC       E1000_ICR_LSC       /* Link Status Change */
 #define E1000_IMS_RXSEQ     E1000_ICR_RXSEQ     /* Rx sequence error */
 #define E1000_IMS_RXDMT0    E1000_ICR_RXDMT0    /* Rx desc min. threshold */
+#define E1000_IMS_RXO       E1000_ICR_RXO       /* Receiver Overrun */
 #define E1000_IMS_RXT0      E1000_ICR_RXT0      /* Rx timer intr */
+#define E1000_IMS_MDAC      E1000_ICR_MDAC      /* MDIO Access Complete */
+#define E1000_IMS_SRPD      E1000_ICR_SRPD      /* Small Receive Packet */
+#define E1000_IMS_ACK       E1000_ICR_ACK       /* Receive ACK Frame Detected */
+#define E1000_IMS_MNG       E1000_ICR_MNG       /* Manageability Event */
 #define E1000_IMS_ECCER     E1000_ICR_ECCER     /* Uncorrectable ECC Error */
 #define E1000_IMS_RXQ0      E1000_ICR_RXQ0      /* Rx Queue 0 Interrupt */
 #define E1000_IMS_RXQ1      E1000_ICR_RXQ1      /* Rx Queue 1 Interrupt */

drivers/net/ethernet/intel/e1000e/netdev.c +4 -7

@@ -1911,16 +1911,12 @@ static irqreturn_t e1000_msix_other(int
 	struct net_device *netdev = data;
 	struct e1000_adapter *adapter = netdev_priv(netdev);
 	struct e1000_hw *hw = &adapter->hw;
-	u32 icr;
-
-	icr = er32(ICR);
-	ew32(ICR, E1000_ICR_OTHER);
+	u32 icr = er32(ICR);
 
 	if (icr & adapter->eiac_mask)
 		ew32(ICS, (icr & adapter->eiac_mask));
 
 	if (icr & E1000_ICR_LSC) {
-		ew32(ICR, E1000_ICR_LSC);
 		hw->mac.get_link_status = true;
 		/* guard against interrupt when we're going down */
 		if (!test_bit(__E1000_DOWN, &adapter->state))

@@ -1928,7 +1924,7 @@ static irqreturn_t e1000_msix_other(int
 	}
 
 	if (!test_bit(__E1000_DOWN, &adapter->state))
-		ew32(IMS, E1000_IMS_OTHER);
+		ew32(IMS, E1000_IMS_OTHER | IMS_OTHER_MASK);
 
 	return IRQ_HANDLED;
 }

@@ -2255,7 +2251,8 @@ static void e1000_irq_enable(struct e100
 
 	if (adapter->msix_entries) {
 		ew32(EIAC_82574, adapter->eiac_mask & E1000_EIAC_MASK_82574);
-		ew32(IMS, adapter->eiac_mask | E1000_IMS_OTHER | E1000_IMS_LSC);
+		ew32(IMS, adapter->eiac_mask | E1000_IMS_OTHER |
+		     IMS_OTHER_MASK);
 	} else if ((hw->mac.type == e1000_pch_lpt) ||
 		   (hw->mac.type == e1000_pch_spt)) {
 		ew32(IMS, IMS_ENABLE_MASK | E1000_IMS_ECCER);

Greg Kroah-Hartman

author maintainer

2018-09-24 12:08 UTC #110 lore raw

PATCH 109/111 Revert "e1000e: Separate signaling for link check/link up"

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Poirier <[email protected]>

commit 3016e0a0c91246e55418825ba9aae271be267522 upstream.

This reverts commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013. This reverts commit 4110e02eb45ea447ec6f5459c9934de0a273fb91. This reverts commit d3604515c9eda464a92e8e67aae82dfe07fe3c98.

Commit 19110cfbb34d ("e1000e: Separate signaling for link check/link up") changed what happens to the link status when there is an error which happens after "get_link_status = false" in the copper check_for_link callbacks. Previously, such an error would be ignored and the link considered up. After that commit, any error implies that the link is down.

Revert commit 19110cfbb34d ("e1000e: Separate signaling for link check/link up") and its followups. After reverting, the race condition described in the log of commit 19110cfbb34d is reintroduced. It may still be triggered by LSC events but this should keep the link down in case the link is electrically unstable, as discussed. The race may no longer be triggered by RXO events because commit 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts") restored reading icr in the Other handler.

Link https://lkml.org/lkml/2018/3/1/789

Cc Yanhui He <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/e1000e/ich8lan.c |   13 ++++---------
 drivers/net/ethernet/intel/e1000e/mac.c     |   13 ++++---------
 drivers/net/ethernet/intel/e1000e/netdev.c  |    2 +-
 3 files changed, 9 insertions(+), 19 deletions(-)

drivers/net/ethernet/intel/e1000e/ich8lan.c +4 -9

@@ -1364,9 +1364,6 @@ out:
  *  Checks to see of the link status of the hardware has changed.  If a
  *  change in link status has been detected, then we read the PHY registers
  *  to get the current speed/duplex if link exists.
- *
- *  Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link
- *  up).
  **/
 static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
 {

@@ -1382,7 +1379,7 @@ static s32 e1000_check_for_copper_link_i
 	 * Change or Rx Sequence Error interrupt.
 	 */
 	if (!mac->get_link_status)
-		return 1;
+		return 0;
 
 	/* First we want to see if the MII Status Register reports
 	 * link.  If so, then we want to get the current speed/duplex

@@ -1600,7 +1597,7 @@ static s32 e1000_check_for_copper_link_i
 	 * we have already determined whether we have link or not.
 	 */
 	if (!mac->autoneg)
-		return 1;
+		return -E1000_ERR_CONFIG;
 
 	/* Auto-Neg is enabled.  Auto Speed Detection takes care
 	 * of MAC speed/duplex configuration.  So we only need to

@@ -1614,12 +1611,10 @@ static s32 e1000_check_for_copper_link_i
 	 * different link partner.
 	 */
 	ret_val = e1000e_config_fc_after_link_up(hw);
-	if (ret_val) {
+	if (ret_val)
 		e_dbg("Error configuring flow control\n");
-		return ret_val;
-	}
 
-	return 1;
+	return ret_val;
 }
 
 static s32 e1000_get_variants_ich8lan(struct e1000_adapter *adapter)

drivers/net/ethernet/intel/e1000e/mac.c +4 -9

@@ -410,9 +410,6 @@ void e1000e_clear_hw_cntrs_base(struct e
  *  Checks to see of the link status of the hardware has changed.  If a
  *  change in link status has been detected, then we read the PHY registers
  *  to get the current speed/duplex if link exists.
- *
- *  Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link
- *  up).
  **/
 s32 e1000e_check_for_copper_link(struct e1000_hw *hw)
 {

@@ -426,7 +423,7 @@ s32 e1000e_check_for_copper_link(struct
 	 * Change or Rx Sequence Error interrupt.
 	 */
 	if (!mac->get_link_status)
-		return 1;
+		return 0;
 
 	/* First we want to see if the MII Status Register reports
 	 * link.  If so, then we want to get the current speed/duplex

@@ -450,7 +447,7 @@ s32 e1000e_check_for_copper_link(struct
 	 * we have already determined whether we have link or not.
 	 */
 	if (!mac->autoneg)
-		return 1;
+		return -E1000_ERR_CONFIG;
 
 	/* Auto-Neg is enabled.  Auto Speed Detection takes care
 	 * of MAC speed/duplex configuration.  So we only need to

@@ -464,12 +461,10 @@ s32 e1000e_check_for_copper_link(struct
 	 * different link partner.
 	 */
 	ret_val = e1000e_config_fc_after_link_up(hw);
-	if (ret_val) {
+	if (ret_val)
 		e_dbg("Error configuring flow control\n");
-		return ret_val;
-	}
 
-	return 1;
+	return ret_val;
 }
 
 /**

drivers/net/ethernet/intel/e1000e/netdev.c +1 -1

@@ -5074,7 +5074,7 @@ static bool e1000e_has_link(struct e1000
 	case e1000_media_type_copper:
 		if (hw->mac.get_link_status) {
 			ret_val = hw->mac.ops.check_for_link(hw);
-			link_active = ret_val > 0;
+			link_active = !hw->mac.get_link_status;
 		} else {
 			link_active = true;
 		}

Greg Kroah-Hartman

author maintainer

2018-09-24 12:11 UTC #111 lore raw

PATCH 110/111 e1000e: Fix link check race condition

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Poirier <[email protected]>

commit e2710dbf0dc1e37d85368e2404049dadda848d5a upstream.

Alex reported the following race condition:

/* link goes up... interrupt... schedule watchdog */ \ e1000_watchdog_task

	\ e1000e_has_link
		\ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
			\ e1000e_phy_has_link_generic(..., &link)
				link = true

					 /* link goes down... interrupt */
					 \ e1000_msix_other
						 hw->mac.get_link_status = true

			/* link is up */
			mac->get_link_status = false

		link_active = true
		/* link_active is true, wrongly, and stays so because
		 * get_link_status is false */

Avoid this problem by making sure that we don't set get_link_status = false after having checked the link.

It seems this problem has been present since the introduction of e1000e.

Link https://lkml.org/lkml/2018/1/29/338

Reported-by Alexander Duyck <[email protected]>

Cc Yanhui He <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/e1000e/ich8lan.c |   31 +++++++++++++++-------------
 drivers/net/ethernet/intel/e1000e/mac.c     |   14 ++++++------
 2 files changed, 24 insertions(+), 21 deletions(-)

drivers/net/ethernet/intel/e1000e/ich8lan.c +17 ~~-14~~

@@ -1380,6 +1380,7 @@ static s32 e1000_check_for_copper_link_i
 	 */
 	if (!mac->get_link_status)
 		return 0;
+	mac->get_link_status = false;
 
 	/* First we want to see if the MII Status Register reports
 	 * link.  If so, then we want to get the current speed/duplex

@@ -1387,12 +1388,12 @@ static s32 e1000_check_for_copper_link_i
 	 */
 	ret_val = e1000e_phy_has_link_generic(hw, 1, 0, &link);
 	if (ret_val)
-		return ret_val;
+		goto out;
 
 	if (hw->mac.type == e1000_pchlan) {
 		ret_val = e1000_k1_gig_workaround_hv(hw, link);
 		if (ret_val)
-			return ret_val;
+			goto out;
 	}
 
 	/* When connected at 10Mbps half-duplex, some parts are excessively

@@ -1427,7 +1428,7 @@ static s32 e1000_check_for_copper_link_i
 
 		ret_val = hw->phy.ops.acquire(hw);
 		if (ret_val)
-			return ret_val;
+			goto out;
 
 		if (hw->mac.type == e1000_pch2lan)
 			emi_addr = I82579_RX_CONFIG;

@@ -1450,7 +1451,7 @@ static s32 e1000_check_for_copper_link_i
 		hw->phy.ops.release(hw);
 
 		if (ret_val)
-			return ret_val;
+			goto out;
 
 		if (hw->mac.type == e1000_pch_spt) {
 			u16 data;

@@ -1459,14 +1460,14 @@ static s32 e1000_check_for_copper_link_i
 			if (speed == SPEED_1000) {
 				ret_val = hw->phy.ops.acquire(hw);
 				if (ret_val)
-					return ret_val;
+					goto out;
 
 				ret_val = e1e_rphy_locked(hw,
 							  PHY_REG(776, 20),
 							  &data);
 				if (ret_val) {
 					hw->phy.ops.release(hw);
-					return ret_val;
+					goto out;
 				}
 
 				ptr_gap = (data & (0x3FF << 2)) >> 2;

@@ -1480,18 +1481,18 @@ static s32 e1000_check_for_copper_link_i
 				}
 				hw->phy.ops.release(hw);
 				if (ret_val)
-					return ret_val;
+					goto out;
 			} else {
 				ret_val = hw->phy.ops.acquire(hw);
 				if (ret_val)
-					return ret_val;
+					goto out;
 
 				ret_val = e1e_wphy_locked(hw,
 							  PHY_REG(776, 20),
 							  0xC023);
 				hw->phy.ops.release(hw);
 				if (ret_val)
-					return ret_val;
+					goto out;
 
 			}
 		}

@@ -1518,7 +1519,7 @@ static s32 e1000_check_for_copper_link_i
 	    (hw->adapter->pdev->device == E1000_DEV_ID_PCH_I218_V3)) {
 		ret_val = e1000_k1_workaround_lpt_lp(hw, link);
 		if (ret_val)
-			return ret_val;
+			goto out;
 	}
 	if ((hw->mac.type == e1000_pch_lpt) ||
 	    (hw->mac.type == e1000_pch_spt)) {

@@ -1527,7 +1528,7 @@ static s32 e1000_check_for_copper_link_i
 		 */
 		ret_val = e1000_platform_pm_pch_lpt(hw, link);
 		if (ret_val)
-			return ret_val;
+			goto out;
 	}
 
 	/* Clear link partner's EEE ability */

@@ -1547,9 +1548,7 @@ static s32 e1000_check_for_copper_link_i
 	}
 
 	if (!link)
-		return 0;	/* No link detected */
-
-	mac->get_link_status = false;
+		goto out;
 
 	switch (hw->mac.type) {
 	case e1000_pch2lan:

@@ -1615,6 +1614,10 @@ static s32 e1000_check_for_copper_link_i
 		e_dbg("Error configuring flow control\n");
 
 	return ret_val;
+
+out:
+	mac->get_link_status = true;
+	return ret_val;
 }
 
 static s32 e1000_get_variants_ich8lan(struct e1000_adapter *adapter)

drivers/net/ethernet/intel/e1000e/mac.c +7 -7

@@ -424,19 +424,15 @@ s32 e1000e_check_for_copper_link(struct
 	 */
 	if (!mac->get_link_status)
 		return 0;
+	mac->get_link_status = false;
 
 	/* First we want to see if the MII Status Register reports
 	 * link.  If so, then we want to get the current speed/duplex
 	 * of the PHY.
 	 */
 	ret_val = e1000e_phy_has_link_generic(hw, 1, 0, &link);
-	if (ret_val)
-		return ret_val;
-
-	if (!link)
-		return 0;	/* No link detected */
-
-	mac->get_link_status = false;
+	if (ret_val || !link)
+		goto out;
 
 	/* Check if there was DownShift, must be checked
 	 * immediately after link-up

@@ -465,6 +461,10 @@ s32 e1000e_check_for_copper_link(struct
 		e_dbg("Error configuring flow control\n");
 
 	return ret_val;
+
+out:
+	mac->get_link_status = true;
+	return ret_val;
 }
 
 /**

Greg Kroah-Hartman

author maintainer

2018-09-24 11:53 UTC #112 lore raw

PATCH 111/111 MIPS: VDSO: Drop gic_get_usm_range() usage

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Burton <[email protected]>

commit 00578cd864d45ae4b8fa3f684f8d6f783dd8d15d upstream.

We don't really need gic_get_usm_range() to abstract discovery of the address of the GIC user-visible section now that we have access to its base address globally.

Switch to calculating it ourselves, which will allow us to stop requiring the irqchip driver to care about a counter exposed to userland for use via the VDSO.

Signed-off-by Paul Burton <[email protected]>

Cc Jason Cooper <[email protected]>

Cc Marc Zyngier <[email protected]>

Cc Thomas Gleixner <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/17040/

Signed-off-by Ralf Baechle <[email protected]>

Signed-off-by SZ Lin (林上智) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/kernel/vdso.c |   15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

arch/mips/kernel/vdso.c +5 ~~-10~~

@@ -13,7 +13,6 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/ioport.h>
-#include <linux/irqchip/mips-gic.h>
 #include <linux/kernel.h>
 #include <linux/mm.h>
 #include <linux/sched.h>

@@ -21,6 +20,7 @@
 #include <linux/timekeeper_internal.h>
 
 #include <asm/abi.h>
+#include <asm/mips-cps.h>
 #include <asm/page.h>
 #include <asm/vdso.h>

@@ -101,9 +101,8 @@ int arch_setup_additional_pages(struct l
 {
 	struct mips_vdso_image *image = current->thread.abi->vdso;
 	struct mm_struct *mm = current->mm;
-	unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr;
+	unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr, gic_pfn;
 	struct vm_area_struct *vma;
-	struct resource gic_res;
 	int ret;
 
 	if (down_write_killable(&mm->mmap_sem))

@@ -127,7 +126,7 @@ int arch_setup_additional_pages(struct l
 	 * only map a page even though the total area is 64K, as we only need
 	 * the counter registers at the start.
 	 */
-	gic_size = gic_present ? PAGE_SIZE : 0;
+	gic_size = mips_gic_present() ? PAGE_SIZE : 0;
 	vvar_size = gic_size + PAGE_SIZE;
 	size = vvar_size + image->size;

@@ -168,13 +167,9 @@ int arch_setup_additional_pages(struct l
 
 	/* Map GIC user page. */
 	if (gic_size) {
-		ret = gic_get_usm_range(&gic_res);
-		if (ret)
-			goto out;
+		gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >> PAGE_SHIFT;
 
-		ret = io_remap_pfn_range(vma, base,
-					 gic_res.start >> PAGE_SHIFT,
-					 gic_size,
+		ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
 					 pgprot_noncached(PAGE_READONLY));
 		if (ret)
 			goto out;

Guenter Roeck

2018-09-25 01:36 UTC #113 lore raw

Re: [PATCH 4.9 111/111] MIPS: VDSO: Drop gic_get_usm_range() usage

Quoted 2 lines · Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

This patch breaks v4.4.y and v4.9.y builds.
It includes asm/mips-cps.h which doesn't exist in those releases.

Building mips:malta_defconfig:smp:initrd ... failed
------------
Error log:
arch/mips/kernel/vdso.c:23:26: fatal error: asm/mips-cps.h: No such file or directory

Guenter

Quoted 83 lines

------------------

From: Paul Burton <[email protected]>

commit 00578cd864d45ae4b8fa3f684f8d6f783dd8d15d upstream.

We don't really need gic_get_usm_range() to abstract discovery of the address of the GIC user-visible section now that we have access to its base address globally.

Switch to calculating it ourselves, which will allow us to stop requiring the irqchip driver to care about a counter exposed to userland for use via the VDSO.

Signed-off-by Paul Burton <[email protected]>

Cc Jason Cooper <[email protected]>

Cc Marc Zyngier <[email protected]>

Cc Thomas Gleixner <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/17040/

Signed-off-by Ralf Baechle <[email protected]>

Signed-off-by SZ Lin (林上智) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/kernel/vdso.c |   15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

arch/mips/kernel/vdso.c +5 ~~-10~~

@@ -13,7 +13,6 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/ioport.h>
-#include <linux/irqchip/mips-gic.h>
 #include <linux/kernel.h>
 #include <linux/mm.h>
 #include <linux/sched.h>

@@ -21,6 +20,7 @@
 #include <linux/timekeeper_internal.h>
 
 #include <asm/abi.h>
+#include <asm/mips-cps.h>
 #include <asm/page.h>
 #include <asm/vdso.h>

@@ -101,9 +101,8 @@ int arch_setup_additional_pages(struct l
 {
 	struct mips_vdso_image *image = current->thread.abi->vdso;
 	struct mm_struct *mm = current->mm;
-	unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr;
+	unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr, gic_pfn;
 	struct vm_area_struct *vma;
-	struct resource gic_res;
 	int ret;
 
 	if (down_write_killable(&mm->mmap_sem))

@@ -127,7 +126,7 @@ int arch_setup_additional_pages(struct l
 	 * only map a page even though the total area is 64K, as we only need
 	 * the counter registers at the start.
 	 */
-	gic_size = gic_present ? PAGE_SIZE : 0;
+	gic_size = mips_gic_present() ? PAGE_SIZE : 0;
 	vvar_size = gic_size + PAGE_SIZE;
 	size = vvar_size + image->size;

@@ -168,13 +167,9 @@ int arch_setup_additional_pages(struct l
 
 	/* Map GIC user page. */
 	if (gic_size) {
-		ret = gic_get_usm_range(&gic_res);
-		if (ret)
-			goto out;
+		gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >> PAGE_SHIFT;
 
-		ret = io_remap_pfn_range(vma, base,
-					 gic_res.start >> PAGE_SHIFT,
-					 gic_size,
+		ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
 					 pgprot_noncached(PAGE_READONLY));
 		if (ret)
 			goto out;

SZ Lin (林上智)

2018-09-25 03:38 UTC #114 lore raw

Re: [PATCH 4.9 111/111] MIPS: VDSO: Drop gic_get_usm_range() usage

Hi,

Guenter Roeck <[email protected]> 於 2018年9月25日週二上午9:36寫道：

Quoted 7 lines · Greg Kroah-Hartman

Quoted 2 lines
4.9-stable review patch. If anyone has any objections, please let me know.
This patch breaks v4.4.y and v4.9.y builds.
It includes asm/mips-cps.h which doesn't exist in those releases.

I am sorry for my fault, thanks for your report.

Since the patch b025d51873d5fe6 "MIPS: CM: Specify register size when generating accessors" which created asm/mips-cps.h is not a bug-fixed patch, hence I will not backport this header.

Hi Greg,

Could you please help to revert this commit? This commit was intended to fix dependency of 70d7783 "MIPS: VDSO: Match data page cache colouring when D$ aliases", but I saw 70d7783 was merged before this commit; therefore, I don't think it is necessary to keep this commit.

I apology for any inconvenience caused, and I will be more careful next time.

SZ Lin (林上智)

Quoted 91 lines

Building mips:malta_defconfig:smp:initrd ... failed
------------
Error log:
arch/mips/kernel/vdso.c:23:26: fatal error: asm/mips-cps.h: No such file or directory

Guenter

Quoted 83 lines

------------------

From: Paul Burton <[email protected]>

commit 00578cd864d45ae4b8fa3f684f8d6f783dd8d15d upstream.

We don't really need gic_get_usm_range() to abstract discovery of the address of the GIC user-visible section now that we have access to its base address globally.

Switch to calculating it ourselves, which will allow us to stop requiring the irqchip driver to care about a counter exposed to userland for use via the VDSO.

Signed-off-by Paul Burton <[email protected]>

Cc Jason Cooper <[email protected]>

Cc Marc Zyngier <[email protected]>

Cc Thomas Gleixner <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/17040/

Signed-off-by Ralf Baechle <[email protected]>

Signed-off-by SZ Lin (林上智) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/kernel/vdso.c |   15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

arch/mips/kernel/vdso.c +5 ~~-10~~

@@ -13,7 +13,6 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/ioport.h>
-#include <linux/irqchip/mips-gic.h>
 #include <linux/kernel.h>
 #include <linux/mm.h>
 #include <linux/sched.h>

@@ -21,6 +20,7 @@
 #include <linux/timekeeper_internal.h>
 
 #include <asm/abi.h>
+#include <asm/mips-cps.h>
 #include <asm/page.h>
 #include <asm/vdso.h>

@@ -101,9 +101,8 @@ int arch_setup_additional_pages(struct l
 {
      struct mips_vdso_image *image = current->thread.abi->vdso;
      struct mm_struct *mm = current->mm;
-     unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr;
+     unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr, gic_pfn;
      struct vm_area_struct *vma;
-     struct resource gic_res;
      int ret;
 
      if (down_write_killable(&mm->mmap_sem))

@@ -127,7 +126,7 @@ int arch_setup_additional_pages(struct l
       * only map a page even though the total area is 64K, as we only need
       * the counter registers at the start.
       */
-     gic_size = gic_present ? PAGE_SIZE : 0;
+     gic_size = mips_gic_present() ? PAGE_SIZE : 0;
      vvar_size = gic_size + PAGE_SIZE;
      size = vvar_size + image->size;

@@ -168,13 +167,9 @@ int arch_setup_additional_pages(struct l
 
      /* Map GIC user page. */
      if (gic_size) {
-             ret = gic_get_usm_range(&gic_res);
-             if (ret)
-                     goto out;
+             gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >> PAGE_SHIFT;
 
-             ret = io_remap_pfn_range(vma, base,
-                                      gic_res.start >> PAGE_SHIFT,
-                                      gic_size,
+             ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
                                       pgprot_noncached(PAGE_READONLY));
              if (ret)
                      goto out;

Greg Kroah-Hartman

author maintainer

2018-09-25 08:57 UTC #115 lore raw

Re: [PATCH 4.9 111/111] MIPS: VDSO: Drop gic_get_usm_range() usage

Quoted 17 lines · SZ Lin (林上智)

Hi,
Guenter Roeck <[email protected]> 於 2018年9月25日週二上午9:36寫道：
Quoted 7 lines · Greg Kroah-Hartman
Quoted 2 lines
4.9-stable review patch. If anyone has any objections, please let me know.
This patch breaks v4.4.y and v4.9.y builds.
It includes asm/mips-cps.h which doesn't exist in those releases.
I am sorry for my fault, thanks for your report.
Since the patch b025d51873d5fe6 "MIPS: CM: Specify register size when generating accessors" which created asm/mips-cps.h is not a bug-fixed patch, hence I will not backport this header.

Quoted 8 lines

Hi Greg,
Could you please help to revert this commit? This commit was intended to fix dependency of 70d7783 "MIPS: VDSO: Match data page cache colouring when D$ aliases", but I saw 70d7783 was merged before this commit; therefore, I don't think it is necessary to keep this commit.
I apology for any inconvenience caused, and I will be more careful next time.

Now dropped from the 4.4 and 4.9 queues, thanks.

greg k-h

Nathan Chancellor

2018-09-24 18:06 UTC #116 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.129 release. There are 111 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 Sep 26 11:30:16 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 9 lines

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.129-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

Merged, compiled with -Werror, and installed onto my OnePlus 6.

No initial issues noticed in dmesg or general usage.

Thanks!
Nathan

Shuah Khan

maintainer

2018-09-24 22:21 UTC #117 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.129 release. There are 111 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 Sep 26 11:30:16 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 9 lines

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.129-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

Compiled and booted on my test system. No dmesg regressions since the last release I tested.

thanks,
-- Shuah

Dan Rue

2018-09-24 22:25 UTC #118 lore raw

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.129 release. There are 111 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 Sep 26 11:30:16 UTC 2018. Anything received after that time might be too late.

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

Summary
------------------------------------------------------------------------

kernel: 4.9.129-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: fa7826f765a24004014c272daf1a64462966c5ed
git describe: v4.9.128-112-gfa7826f765a2
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.128-112-gfa7826f765a2

No regressions (compared to build v4.9.128)

Ran 20268 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

Signature · 2 lines

Linaro LKFT
https://lkft.linaro.org

Greg Kroah-Hartman

author maintainer

2018-09-25 09:07 UTC #119 lore raw

Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.129 release. There are 111 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.

Quoted 8 lines

Responses should be made by Wed Sep 26 11:30:16 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.129-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.

-rc2 is out to resolve some reported problems:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.129-rc2.gz

Guenter Roeck

2018-09-25 20:42 UTC #120 lore raw