5.10.40-rc1 review

From: Christophe JAILLET <[email protected]>

[ Upstream commit c019d92457826bb7b2091c86f36adb5de08405f9 ]

'setup_find_cpu_node()' take a reference on the node it returns. This reference must be decremented when not needed anymore, or there will be a leak.

Add the missing 'of_node_put(cpu)'.

Note that 'setup_cpuinfo()' that also calls this function already has a correct 'of_node_put(cpu)' at its end.

Fixes 9d02a4283e9c ("OpenRISC: Boot code")

Signed-off-by Christophe JAILLET <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

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

---
 arch/openrisc/kernel/setup.c | 2 ++
 1 file changed, 2 insertions(+)

arch/openrisc/kernel/setup.c +2 -0

index 2416a9f91533..c6f9e7b9f7cb 100644
@@ -278,6 +278,8 @@ void calibrate_delay(void)
 	pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n",
 		loops_per_jiffy / (500000 / HZ),
 		(loops_per_jiffy / (5000 / HZ)) % 100, loops_per_jiffy);
+
+	of_node_put(cpu);
 }
 
 void __init setup_arch(char **cmdline_p)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #3 lore raw

PATCH 3/104 tee: amdtee: unload TA only when its refcount becomes 0

From: Rijo Thomas <[email protected]>

[ Upstream commit 9f015b3765bf593b3ed5d3b588e409dc0ffa9f85 ]

Same Trusted Application (TA) can be loaded in multiple TEE contexts.

If it is a single instance TA, the TA should not get unloaded from AMD Secure Processor, while it is still in use in another TEE context.

Therefore reference count TA and unload it when the count becomes zero.

Fixes 757cc3e9ff1d ("tee: add AMD-TEE driver")

Reviewed-by Devaraj Rangasamy <[email protected]>

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

Acked-by Dan Carpenter <[email protected]>

Signed-off-by Jens Wiklander <[email protected]>

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

---
 drivers/tee/amdtee/amdtee_private.h | 13 ++++
 drivers/tee/amdtee/call.c           | 94 ++++++++++++++++++++++++++---
 drivers/tee/amdtee/core.c           | 15 +++--
 3 files changed, 106 insertions(+), 16 deletions(-)

drivers/tee/amdtee/amdtee_private.h +13 -0

index 337c8d82f74e..6d0f7062bb87 100644
@@ -21,6 +21,7 @@
 #define TEEC_SUCCESS			0x00000000
 #define TEEC_ERROR_GENERIC		0xFFFF0000
 #define TEEC_ERROR_BAD_PARAMETERS	0xFFFF0006
+#define TEEC_ERROR_OUT_OF_MEMORY	0xFFFF000C
 #define TEEC_ERROR_COMMUNICATION	0xFFFF000E
 
 #define TEEC_ORIGIN_COMMS		0x00000002

@@ -93,6 +94,18 @@ struct amdtee_shm_data {
 	u32     buf_id;
 };
 
+/**
+ * struct amdtee_ta_data - Keeps track of all TAs loaded in AMD Secure
+ *			   Processor
+ * @ta_handle:	Handle to TA loaded in TEE
+ * @refcount:	Reference count for the loaded TA
+ */
+struct amdtee_ta_data {
+	struct list_head list_node;
+	u32 ta_handle;
+	u32 refcount;
+};
+
 #define LOWER_TWO_BYTE_MASK	0x0000FFFF
 
 /**

drivers/tee/amdtee/call.c +84 ~~-10~~

135 lines not on this page · raw message

drivers/tee/amdtee/core.c +9 -6

index 8a6a8f30bb42..da6b88e80dc0 100644
@@ -59,10 +59,9 @@ static void release_session(struct amdtee_session *sess)
 			continue;
 
 		handle_close_session(sess->ta_handle, sess->session_info[i]);
+		handle_unload_ta(sess->ta_handle);
 	}
 
-	/* Unload Trusted Application once all sessions are closed */
-	handle_unload_ta(sess->ta_handle);
 	kfree(sess);
 }

@@ -224,8 +223,6 @@ static void destroy_session(struct kref *ref)
 	struct amdtee_session *sess = container_of(ref, struct amdtee_session,
 						   refcount);
 
-	/* Unload the TA from TEE */
-	handle_unload_ta(sess->ta_handle);
 	mutex_lock(&session_list_mutex);
 	list_del(&sess->list_node);
 	mutex_unlock(&session_list_mutex);

@@ -238,7 +235,7 @@ int amdtee_open_session(struct tee_context *ctx,
 {
 	struct amdtee_context_data *ctxdata = ctx->data;
 	struct amdtee_session *sess = NULL;
-	u32 session_info;
+	u32 session_info, ta_handle;
 	size_t ta_size;
 	int rc, i;
 	void *ta;

@@ -259,11 +256,14 @@ int amdtee_open_session(struct tee_context *ctx,
 	if (arg->ret != TEEC_SUCCESS)
 		goto out;
 
+	ta_handle = get_ta_handle(arg->session);
+
 	mutex_lock(&session_list_mutex);
 	sess = alloc_session(ctxdata, arg->session);
 	mutex_unlock(&session_list_mutex);
 
 	if (!sess) {
+		handle_unload_ta(ta_handle);
 		rc = -ENOMEM;
 		goto out;
 	}

@@ -277,6 +277,7 @@ int amdtee_open_session(struct tee_context *ctx,
 
 	if (i >= TEE_NUM_SESSIONS) {
 		pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS);
+		handle_unload_ta(ta_handle);
 		kref_put(&sess->refcount, destroy_session);
 		rc = -ENOMEM;
 		goto out;

@@ -289,12 +290,13 @@ int amdtee_open_session(struct tee_context *ctx,
 		spin_lock(&sess->lock);
 		clear_bit(i, sess->sess_mask);
 		spin_unlock(&sess->lock);
+		handle_unload_ta(ta_handle);
 		kref_put(&sess->refcount, destroy_session);
 		goto out;
 	}
 
 	sess->session_info[i] = session_info;
-	set_session_id(sess->ta_handle, i, &arg->session);
+	set_session_id(ta_handle, i, &arg->session);
 out:
 	free_pages((u64)ta, get_order(ta_size));
 	return rc;

@@ -329,6 +331,7 @@ int amdtee_close_session(struct tee_context *ctx, u32 session)
 
 	/* Close the session */
 	handle_close_session(ta_handle, session_info);
+	handle_unload_ta(ta_handle);
 
 	kref_put(&sess->refcount, destroy_session);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #4 lore raw

PATCH 4/104 RDMA/siw: Properly check send and receive CQ pointers

Link https://lore.kernel.org/r/a7535a82925f6f4c1f062abaa294f3ae6e54bdd2.1620560310.git.leonro@nvidia.com open here

From: Leon Romanovsky <[email protected]>

[ Upstream commit a568814a55a0e82bbc7c7b51333d0c38e8fb5520 ]

The check for the NULL of pointer received from container_of() is incorrect by definition as it points to some offset from NULL.

Change such check with proper NULL check of SIW QP attributes.

Fixes 303ae1cdfdf7 ("rdma/siw: application interface")

Reviewed-by Bernard Metzler <[email protected]>

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

---
 drivers/infiniband/sw/siw/siw_verbs.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

drivers/infiniband/sw/siw/siw_verbs.c +3 -6

index fb25e8011f5a..11bd3205dbc6 100644
@@ -300,7 +300,6 @@ struct ib_qp *siw_create_qp(struct ib_pd *pd,
 	struct siw_ucontext *uctx =
 		rdma_udata_to_drv_context(udata, struct siw_ucontext,
 					  base_ucontext);
-	struct siw_cq *scq = NULL, *rcq = NULL;
 	unsigned long flags;
 	int num_sqe, num_rqe, rv = 0;
 	size_t length;

@@ -340,10 +339,8 @@ struct ib_qp *siw_create_qp(struct ib_pd *pd,
 		rv = -EINVAL;
 		goto err_out;
 	}
-	scq = to_siw_cq(attrs->send_cq);
-	rcq = to_siw_cq(attrs->recv_cq);
 
-	if (!scq || (!rcq && !attrs->srq)) {
+	if (!attrs->send_cq || (!attrs->recv_cq && !attrs->srq)) {
 		siw_dbg(base_dev, "send CQ or receive CQ invalid\n");
 		rv = -EINVAL;
 		goto err_out;

@@ -398,8 +395,8 @@ struct ib_qp *siw_create_qp(struct ib_pd *pd,
 		}
 	}
 	qp->pd = pd;
-	qp->scq = scq;
-	qp->rcq = rcq;
+	qp->scq = to_siw_cq(attrs->send_cq);
+	qp->rcq = to_siw_cq(attrs->recv_cq);
 
 	if (attrs->srq) {
 		/*

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #5 lore raw

PATCH 5/104 RDMA/siw: Release xarray entry

Link https://lore.kernel.org/r/f070b59d5a1114d5a4e830346755c2b3f141cde5.1620560472.git.leonro@nvidia.com open here

From: Leon Romanovsky <[email protected]>

[ Upstream commit a3d83276d98886879b5bf7b30b7c29882754e4df ]

The xarray entry is allocated in siw_qp_add(), but release was missed in case zero-sized SQ was discovered.

Fixes 661f385961f0 ("RDMA/siw: Fix handling of zero-sized Read and Receive Queues.")

Reviewed-by Bernard Metzler <[email protected]>

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

---
 drivers/infiniband/sw/siw/siw_verbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/infiniband/sw/siw/siw_verbs.c +1 -1

index 11bd3205dbc6..34e847a91eb8 100644
@@ -372,7 +372,7 @@ struct ib_qp *siw_create_qp(struct ib_pd *pd,
 	else {
 		/* Zero sized SQ is not supported */
 		rv = -EINVAL;
-		goto err_out;
+		goto err_out_xa;
 	}
 	if (num_rqe)
 		num_rqe = roundup_pow_of_two(num_rqe);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #6 lore raw

PATCH 6/104 RDMA/core: Prevent divide-by-zero error triggered by the user

Link https://lore.kernel.org/r/b971cc70a8b240a8b5eda33c99fa0558a0071be2.1620657876.git.leonro@nvidia.com open here

From: Leon Romanovsky <[email protected]>

[ Upstream commit 54d87913f147a983589923c7f651f97de9af5be1 ]

The user_entry_size is supplied by the user and later used as a denominator to calculate number of entries. The zero supplied by the user will trigger the following divide-by-zero error:

divide error: 0000 [#1] SMP KASAN PTI

 CPU: 4 PID: 497 Comm: c_repro Not tainted 5.13.0-rc1+ #281
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 RIP: 0010:ib_uverbs_handler_UVERBS_METHOD_QUERY_GID_TABLE+0x1b1/0x510
 Code: 87 59 03 00 00 e8 9f ab 1e ff 48 8d bd a8 00 00 00 e8 d3 70 41 ff 44 0f b7 b5 a8 00 00 00 e8 86 ab 1e ff 31 d2 4c 89 f0 31 ff <49> f7 f5 48 89 d6 48 89 54 24 10 48 89 04 24 e8 1b ad 1e ff 48 8b
 RSP: 0018:ffff88810416f828 EFLAGS: 00010246
 RAX: 0000000000000008 RBX: 1ffff1102082df09 RCX: ffffffff82183f3d
 RDX: 0000000000000000 RSI: ffff888105f2da00 RDI: 0000000000000000
 RBP: ffff88810416fa98 R08: 0000000000000001 R09: ffffed102082df5f
 R10: ffff88810416faf7 R11: ffffed102082df5e R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000000008 R15: ffff88810416faf0
 FS:  00007f5715efa740(0000) GS:ffff88811a700000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000020000840 CR3: 000000010c2e0001 CR4: 0000000000370ea0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  ? ib_uverbs_handler_UVERBS_METHOD_INFO_HANDLES+0x4b0/0x4b0
  ib_uverbs_cmd_verbs+0x1546/0x1940
  ib_uverbs_ioctl+0x186/0x240
  __x64_sys_ioctl+0x38a/0x1220
  do_syscall_64+0x3f/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

Fixes 9f85cbe50aa0 ("RDMA/uverbs: Expose the new GID query API to user space")

Reviewed-by Jason Gunthorpe <[email protected]>

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

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

drivers/infiniband/core/uverbs_std_types_device.c +3 -0

index 9ec6971056fa..a03021d94e11 100644
@@ -331,6 +331,9 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_GID_TABLE)(
 	if (ret)
 		return ret;
 
+	if (!user_entry_size)
+		return -EINVAL;
+
 	max_entries = uverbs_attr_ptr_get_array_size(
 		attrs, UVERBS_ATTR_QUERY_GID_TABLE_RESP_ENTRIES,
 		user_entry_size);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #7 lore raw

PATCH 7/104 RDMA/rxe: Clear all QP fields if creation failed

Link https://lore.kernel.org/r/7bf8d548764d406dbbbaf4b574960ebfd5af8387.1620717918.git.leonro@nvidia.com open here

From: Leon Romanovsky <[email protected]>

[ Upstream commit 67f29896fdc83298eed5a6576ff8f9873f709228 ]

rxe_qp_do_cleanup() relies on valid pointer values in QP for the properly created ones, but in case rxe_qp_from_init() failed it was filled with garbage and caused tot the following error.

refcount_t: underflow; use-after-free.

  WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28 refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28
  Modules linked in:
  CPU: 1 PID: 12560 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28
  Code: e9 db fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01 e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55
  RSP: 0018:ffffc900097ceba8 EFLAGS: 00010286
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67
  RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
  R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800
  R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000
  FS:  00007f6eb2be3700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   __refcount_sub_and_test include/linux/refcount.h:283 [inline]
   __refcount_dec_and_test include/linux/refcount.h:315 [inline]
   refcount_dec_and_test include/linux/refcount.h:333 [inline]
   kref_put include/linux/kref.h:64 [inline]
   rxe_qp_do_cleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxe_qp.c:805
   execute_in_process_context+0x37/0x150 kernel/workqueue.c:3327
   rxe_elem_release+0x9f/0x180 drivers/infiniband/sw/rxe/rxe_pool.c:391
   kref_put include/linux/kref.h:65 [inline]
   rxe_create_qp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxe_verbs.c:425
   _ib_create_qp drivers/infiniband/core/core_priv.h:331 [inline]
   ib_create_named_qp+0x2ad/0x1370 drivers/infiniband/core/verbs.c:1231
   ib_create_qp include/rdma/ib_verbs.h:3644 [inline]
   create_mad_qp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920
   ib_mad_port_open drivers/infiniband/core/mad.c:3001 [inline]
   ib_mad_init_device+0xd6f/0x1400 drivers/infiniband/core/mad.c:3092
   add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:717
   enable_device_and_get+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331
   ib_register_device drivers/infiniband/core/device.c:1413 [inline]
   ib_register_device+0x7c7/0xa50 drivers/infiniband/core/device.c:1365
   rxe_register_device+0x3d5/0x4a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1147
   rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247
   rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:503
   rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline]
   rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250
   nldev_newlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555
   rdma_nl_rcv_msg+0x36d/0x690 drivers/infiniband/core/netlink.c:195
   rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
   rdma_nl_rcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259
   netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
   netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
   netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
   sock_sendmsg_nosec net/socket.c:654 [inline]
   sock_sendmsg+0xcf/0x120 net/socket.c:674
   ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
   ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
   __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
   do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Fixes 8700e3e7c485 ("Soft RoCE driver")

Reported-by [email protected]

Reviewed-by Zhu Yanjun <[email protected]>

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

---
 drivers/infiniband/sw/rxe/rxe_qp.c | 7 +++++++
 1 file changed, 7 insertions(+)

drivers/infiniband/sw/rxe/rxe_qp.c +7 -0

index 656a5b4be847..1e716fe7014c 100644
@@ -231,6 +231,7 @@ static int rxe_qp_init_req(struct rxe_dev *rxe, struct rxe_qp *qp,
 	if (err) {
 		vfree(qp->sq.queue->buf);
 		kfree(qp->sq.queue);
+		qp->sq.queue = NULL;
 		return err;
 	}

@@ -284,6 +285,7 @@ static int rxe_qp_init_resp(struct rxe_dev *rxe, struct rxe_qp *qp,
 		if (err) {
 			vfree(qp->rq.queue->buf);
 			kfree(qp->rq.queue);
+			qp->rq.queue = NULL;
 			return err;
 		}
 	}

@@ -344,6 +346,11 @@ int rxe_qp_from_init(struct rxe_dev *rxe, struct rxe_qp *qp, struct rxe_pd *pd,
 err2:
 	rxe_queue_cleanup(qp->sq.queue);
 err1:
+	qp->pd = NULL;
+	qp->rcq = NULL;
+	qp->scq = NULL;
+	qp->srq = NULL;
+
 	if (srq)
 		rxe_drop_ref(srq);
 	rxe_drop_ref(scq);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #8 lore raw

PATCH 8/104 scsi: ufs: core: Increase the usable queue depth

From: Bart Van Assche <[email protected]>

[ Upstream commit d0b2b70eb12e9ffaf95e11b16b230a4e015a536c ]

With the current implementation of the UFS driver active_queues is 1 instead of 0 if all UFS request queues are idle. That causes hctx_may_queue() to divide the queue depth by 2 when queueing a request and hence reduces the usable queue depth.

The shared tag set code in the block layer keeps track of the number of active request queues. blk_mq_tag_busy() is called before a request is queued onto a hwq and blk_mq_tag_idle() is called some time after the hwq became idle. blk_mq_tag_idle() is called from inside blk_mq_timeout_work(). Hence, blk_mq_tag_idle() is only called if a timer is associated with each request that is submitted to a request queue that shares a tag set with another request queue.

Adds a blk_mq_start_request() call in ufshcd_exec_dev_cmd(). This doubles the queue depth on my test setup from 16 to 32.

In addition to increasing the usable queue depth, also fix the documentation of the 'timeout' parameter in the header above ufshcd_exec_dev_cmd().

Link https://lore.kernel.org/r/[email protected] open here

Fixes 7252a3603015 ("scsi: ufs: Avoid busy-waiting by eliminating tag conflicts")

Cc Can Guo <[email protected]>

Cc Alim Akhtar <[email protected]>

Cc Avri Altman <[email protected]>

Cc Stanley Chu <[email protected]>

Cc Bean Huo <[email protected]>

Cc Adrian Hunter <[email protected]>

Reviewed-by Can Guo <[email protected]>

Signed-off-by Bart Van Assche <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

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

---
 drivers/scsi/ufs/ufshcd.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/scsi/ufs/ufshcd.c +4 -1

index 08d4d40c510e..854c96e63007 100644
@@ -2768,7 +2768,7 @@ static int ufshcd_wait_for_dev_cmd(struct ufs_hba *hba,
  * ufshcd_exec_dev_cmd - API for sending device management requests
  * @hba: UFS hba
  * @cmd_type: specifies the type (NOP, Query...)
- * @timeout: time in seconds
+ * @timeout: timeout in milliseconds
  *
  * NOTE: Since there is only one available tag for device management commands,
  * it is expected you hold the hba->dev_cmd.lock mutex.

@@ -2798,6 +2798,9 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
 	}
 	tag = req->tag;
 	WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag));
+	/* Set the timeout such that the SCSI error handler is not activated. */
+	req->timeout = msecs_to_jiffies(2 * timeout);
+	blk_mq_start_request(req);
 
 	init_completion(&wait);
 	lrbp = &hba->lrb[tag];

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #9 lore raw

PATCH 9/104 scsi: qedf: Add pointer checks in qedf_update_link_speed()

From: Javed Hasan <[email protected]>

[ Upstream commit 73578af92a0fae6609b955fcc9113e50e413c80f ]

The following trace was observed:

 [   14.042059] Call Trace:
 [   14.042061]  <IRQ>
 [   14.042068]  qedf_link_update+0x144/0x1f0 [qedf]
 [   14.042117]  qed_link_update+0x5c/0x80 [qed]
 [   14.042135]  qed_mcp_handle_link_change+0x2d2/0x410 [qed]
 [   14.042155]  ? qed_set_ptt+0x70/0x80 [qed]
 [   14.042170]  ? qed_set_ptt+0x70/0x80 [qed]
 [   14.042186]  ? qed_rd+0x13/0x40 [qed]
 [   14.042205]  qed_mcp_handle_events+0x437/0x690 [qed]
 [   14.042221]  ? qed_set_ptt+0x70/0x80 [qed]
 [   14.042239]  qed_int_sp_dpc+0x3a6/0x3e0 [qed]
 [   14.042245]  tasklet_action_common.isra.14+0x5a/0x100
 [   14.042250]  __do_softirq+0xe4/0x2f8
 [   14.042253]  irq_exit+0xf7/0x100
 [   14.042255]  do_IRQ+0x7f/0xd0
 [   14.042257]  common_interrupt+0xf/0xf
 [   14.042259]  </IRQ>

API qedf_link_update() is getting called from QED but by that time shost_data is not initialised. This results in a NULL pointer dereference when we try to dereference shost_data while updating supported_speeds.

Add a NULL pointer check before dereferencing shost_data.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.")

Reviewed-by Himanshu Madhani <[email protected]>

Signed-off-by Javed Hasan <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

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

---
 drivers/scsi/qedf/qedf_main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/scsi/qedf/qedf_main.c +3 -1

index 46d185cb9ea8..a464d0a4f465 100644
@@ -536,7 +536,9 @@ static void qedf_update_link_speed(struct qedf_ctx *qedf,
 	if (linkmode_intersects(link->supported_caps, sup_caps))
 		lport->link_supported_speeds |= FC_PORTSPEED_20GBIT;
 
-	fc_host_supported_speeds(lport->host) = lport->link_supported_speeds;
+	if (lport->host && lport->host->shost_data)
+		fc_host_supported_speeds(lport->host) =
+			lport->link_supported_speeds;
 }
 
 static void qedf_bw_update(void *dev)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #10 lore raw

PATCH 10/104 scsi: qla2xxx: Fix error return code in qla82xx_write_flash_dword()

From: Zhen Lei <[email protected]>

[ Upstream commit 5cb289bf2d7c34ca1abd794ce116c4f19185a1d4 ]

Fix to return a negative error code from the error handling case instead of 0 as done elsewhere in this function.

Link https://lore.kernel.org/r/[email protected] open here

Fixes a9083016a531 ("[SCSI] qla2xxx: Add ISP82XX support.")

Reported-by Hulk Robot <[email protected]>

Reviewed-by Himanshu Madhani <[email protected]>

Signed-off-by Zhen Lei <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

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

---
 drivers/scsi/qla2xxx/qla_nx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/scsi/qla2xxx/qla_nx.c +2 -1

index b3ba0de5d4fb..0563c9530dca 100644
@@ -1066,7 +1066,8 @@ qla82xx_write_flash_dword(struct qla_hw_data *ha, uint32_t flashaddr,
 		return ret;
 	}
 
-	if (qla82xx_flash_set_write_enable(ha))
+	ret = qla82xx_flash_set_write_enable(ha);
+	if (ret < 0)
 		goto done_write;
 
 	qla82xx_wr_32(ha, QLA82XX_ROMUSB_ROM_WDATA, data);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #11 lore raw

PATCH 11/104 RDMA/mlx5: Recover from fatal event in dual port mode

Link https://lore.kernel.org/r/8906754455bb23019ef223c725d2c0d38acfb80b.1620711734.git.leonro@nvidia.com open here

From: Maor Gottlieb <[email protected]>

[ Upstream commit 97f30d324ce6645a4de4ffb71e4ae9b8ca36ff04 ]

When there is fatal event on the slave port, the device is marked as not active. We need to mark it as active again when the slave is recovered to regain full functionality.

Fixes d69a24e03659 ("IB/mlx5: Move IB event processing onto a workqueue")

Signed-off-by Maor Gottlieb <[email protected]>

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

---
 drivers/infiniband/hw/mlx5/main.c | 1 +
 1 file changed, 1 insertion(+)

drivers/infiniband/hw/mlx5/main.c +1 -0

index beec0d7c0d6e..b19506707e45 100644
@@ -4762,6 +4762,7 @@ static void *mlx5_ib_add_slave_port(struct mlx5_core_dev *mdev)
 
 		if (bound) {
 			rdma_roce_rescan_device(&dev->ib_dev);
+			mpi->ibdev->ib_active = true;
 			break;
 		}
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #12 lore raw

PATCH 12/104 RDMA/core: Dont access cm_id after its destruction

Link https://lore.kernel.org/r/3352ee288fe34f2b44220457a29bfc0548686363.1620711734.git.leonro@nvidia.com open here

From: Shay Drory <[email protected]>

[ Upstream commit 889d916b6f8a48b8c9489fffcad3b78eedd01a51 ]

restrack should only be attached to a cm_id while the ID has a valid device pointer. It is set up when the device is first loaded, but not cleared when the device is removed. There is also two copies of the device pointer, one private and one in the public API, and these were left out of sync.

Make everything go to NULL together and manipulate restrack right around the device assignments.

Found by syzcaller:

BUG: KASAN: wild-memory-access in __list_del include/linux/list.h:112 [inline]
BUG: KASAN: wild-memory-access in __list_del_entry include/linux/list.h:135 [inline]
BUG: KASAN: wild-memory-access in list_del include/linux/list.h:146 [inline]
BUG: KASAN: wild-memory-access in cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline]
BUG: KASAN: wild-memory-access in cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline]
BUG: KASAN: wild-memory-access in cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783
Write of size 8 at addr dead000000000108 by task syz-executor716/334

CPU: 0 PID: 334 Comm: syz-executor716 Not tainted 5.11.0+ #271
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0xbe/0xf9 lib/dump_stack.c:120
 __kasan_report mm/kasan/report.c:400 [inline]
 kasan_report.cold+0x5f/0xd5 mm/kasan/report.c:413
 __list_del include/linux/list.h:112 [inline]
 __list_del_entry include/linux/list.h:135 [inline]
 list_del include/linux/list.h:146 [inline]
 cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline]
 cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline]
 cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783
 _destroy_id+0x29/0x460 drivers/infiniband/core/cma.c:1862
 ucma_close_id+0x36/0x50 drivers/infiniband/core/ucma.c:185
 ucma_destroy_private_ctx+0x58d/0x5b0 drivers/infiniband/core/ucma.c:576
 ucma_close+0x91/0xd0 drivers/infiniband/core/ucma.c:1797
 __fput+0x169/0x540 fs/file_table.c:280
 task_work_run+0xb7/0x100 kernel/task_work.c:140
 exit_task_work include/linux/task_work.h:30 [inline]
 do_exit+0x7da/0x17f0 kernel/exit.c:825
 do_group_exit+0x9e/0x190 kernel/exit.c:922
 __do_sys_exit_group kernel/exit.c:933 [inline]
 __se_sys_exit_group kernel/exit.c:931 [inline]
 __x64_sys_exit_group+0x2d/0x30 kernel/exit.c:931
 do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes 255d0c14b375 ("RDMA/cma: rdma_bind_addr() leaks a cma_dev reference count")

Signed-off-by Shay Drory <[email protected]>

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

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

drivers/infiniband/core/cma.c +3 -2

index 6af066a2c8c0..d1e94147fb16 100644
@@ -482,6 +482,7 @@ static void cma_release_dev(struct rdma_id_private *id_priv)
 	list_del(&id_priv->list);
 	cma_dev_put(id_priv->cma_dev);
 	id_priv->cma_dev = NULL;
+	id_priv->id.device = NULL;
 	if (id_priv->id.route.addr.dev_addr.sgid_attr) {
 		rdma_put_gid_attr(id_priv->id.route.addr.dev_addr.sgid_attr);
 		id_priv->id.route.addr.dev_addr.sgid_attr = NULL;

@@ -1864,6 +1865,7 @@ static void _destroy_id(struct rdma_id_private *id_priv,
 				iw_destroy_cm_id(id_priv->cm_id.iw);
 		}
 		cma_leave_mc_groups(id_priv);
+		rdma_restrack_del(&id_priv->res);
 		cma_release_dev(id_priv);
 	}

@@ -1877,7 +1879,6 @@ static void _destroy_id(struct rdma_id_private *id_priv,
 	kfree(id_priv->id.route.path_rec);
 
 	put_net(id_priv->id.route.addr.dev_addr.net);
-	rdma_restrack_del(&id_priv->res);
 	kfree(id_priv);
 }

@@ -3740,7 +3741,7 @@ int rdma_listen(struct rdma_cm_id *id, int backlog)
 	}
 
 	id_priv->backlog = backlog;
-	if (id->device) {
+	if (id_priv->cma_dev) {
 		if (rdma_cap_ib_cm(id->device, 1)) {
 			ret = cma_ib_listen(id_priv);
 			if (ret)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #13 lore raw

PATCH 13/104 nvmet: remove unused ctrl->cqs

From: Amit <[email protected]>

[ Upstream commit 6d65aeab7bf6e83e75f53cfdbdb84603e52e1182 ]

remove unused cqs from nvmet_ctrl struct
this will reduce the allocated memory.

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

Signed-off-by Christoph Hellwig <[email protected]>

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

---
 drivers/nvme/target/core.c  | 15 ++-------------
 drivers/nvme/target/nvmet.h |  1 -
 2 files changed, 2 insertions(+), 14 deletions(-)

drivers/nvme/target/core.c +2 ~~-13~~

index 1e79d33c1df7..870d06cfd815 100644
@@ -757,8 +757,6 @@ void nvmet_cq_setup(struct nvmet_ctrl *ctrl, struct nvmet_cq *cq,
 {
 	cq->qid = qid;
 	cq->size = size;
-
-	ctrl->cqs[qid] = cq;
 }
 
 void nvmet_sq_setup(struct nvmet_ctrl *ctrl, struct nvmet_sq *sq,

@@ -1355,20 +1353,14 @@ u16 nvmet_alloc_ctrl(const char *subsysnqn, const char *hostnqn,
 	if (!ctrl->changed_ns_list)
 		goto out_free_ctrl;
 
-	ctrl->cqs = kcalloc(subsys->max_qid + 1,
-			sizeof(struct nvmet_cq *),
-			GFP_KERNEL);
-	if (!ctrl->cqs)
-		goto out_free_changed_ns_list;
-
 	ctrl->sqs = kcalloc(subsys->max_qid + 1,
 			sizeof(struct nvmet_sq *),
 			GFP_KERNEL);
 	if (!ctrl->sqs)
-		goto out_free_cqs;
+		goto out_free_changed_ns_list;
 
 	if (subsys->cntlid_min > subsys->cntlid_max)
-		goto out_free_cqs;
+		goto out_free_changed_ns_list;
 
 	ret = ida_simple_get(&cntlid_ida,
 			     subsys->cntlid_min, subsys->cntlid_max,

@@ -1406,8 +1398,6 @@ u16 nvmet_alloc_ctrl(const char *subsysnqn, const char *hostnqn,
 
 out_free_sqs:
 	kfree(ctrl->sqs);
-out_free_cqs:
-	kfree(ctrl->cqs);
 out_free_changed_ns_list:
 	kfree(ctrl->changed_ns_list);
 out_free_ctrl:

@@ -1437,7 +1427,6 @@ static void nvmet_ctrl_free(struct kref *ref)
 
 	nvmet_async_events_free(ctrl);
 	kfree(ctrl->sqs);
-	kfree(ctrl->cqs);
 	kfree(ctrl->changed_ns_list);
 	kfree(ctrl);

drivers/nvme/target/nvmet.h +0 -1

index bc91336080e0..ea96487b5424 100644
@@ -164,7 +164,6 @@ static inline struct nvmet_port *ana_groups_to_port(
 
 struct nvmet_ctrl {
 	struct nvmet_subsys	*subsys;
-	struct nvmet_cq		**cqs;
 	struct nvmet_sq		**sqs;
 
 	bool			cmd_seen;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #14 lore raw

PATCH 14/104 nvmet: fix memory leak in nvmet_alloc_ctrl()

From: Wu Bo <[email protected]>

[ Upstream commit fec356a61aa3d3a66416b4321f1279e09e0f256f ]

When creating ctrl in nvmet_alloc_ctrl(), if the cntlid_min is larger than cntlid_max of the subsystem, and jumps to the "out_free_changed_ns_list" label, but the ctrl->sqs lack of be freed. Fix this by jumping to the "out_free_sqs" label.

Fixes 94a39d61f80f ("nvmet: make ctrl-id configurable")

Signed-off-by Wu Bo <[email protected]>

Reviewed-by Chaitanya Kulkarni <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

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

---
 drivers/nvme/target/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/nvme/target/core.c +1 -1

index 870d06cfd815..46e4f7ea34c8 100644
@@ -1360,7 +1360,7 @@ u16 nvmet_alloc_ctrl(const char *subsysnqn, const char *hostnqn,
 		goto out_free_changed_ns_list;
 
 	if (subsys->cntlid_min > subsys->cntlid_max)
-		goto out_free_changed_ns_list;
+		goto out_free_sqs;
 
 	ret = ida_simple_get(&cntlid_ida,
 			     subsys->cntlid_min, subsys->cntlid_max,

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #15 lore raw

PATCH 15/104 nvme-loop: fix memory leak in nvme_loop_create_ctrl()

From: Wu Bo <[email protected]>

[ Upstream commit 03504e3b54cc8118cc26c064e60a0b00c2308708 ]

When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl() fails, the loop ctrl should be freed before jumping to the "out" label.

Fixes 3a85a5de29ea ("nvme-loop: add a NVMe loopback host driver")

Signed-off-by Wu Bo <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

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

---
 drivers/nvme/target/loop.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/nvme/target/loop.c +3 -1

index f6d81239be21..b869b686e962 100644
@@ -578,8 +578,10 @@ static struct nvme_ctrl *nvme_loop_create_ctrl(struct device *dev,
 
 	ret = nvme_init_ctrl(&ctrl->ctrl, dev, &nvme_loop_ctrl_ops,
 				0 /* no quirks, we're perfect! */);
-	if (ret)
+	if (ret) {
+		kfree(ctrl);
 		goto out;
+	}
 
 	if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_CONNECTING))
 		WARN_ON_ONCE(1);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #16 lore raw

PATCH 16/104 nvme-tcp: rerun io_work if req_list is not empty

From: Keith Busch <[email protected]>

[ Upstream commit a0fdd1418007f83565d3f2e04b47923ba93a9b8c ]

A possible race condition exists where the request to send data is enqueued from nvme_tcp_handle_r2t()'s will not be observed by nvme_tcp_send_all() if it happens to be running. The driver relies on io_work to send the enqueued request when it is runs again, but the concurrently running nvme_tcp_send_all() may not have released the send_mutex at that time. If no future commands are enqueued to re-kick the io_work, the request will timeout in the SEND_H2C state, resulting in a timeout error like:

nvme nvme0: queue 1: timeout request 0x3 type 6

Ensure the io_work continues to run as long as the req_list is not empty.

Fixes db5ad6b7f8cdd ("nvme-tcp: try to send request in queue_rq context")

Signed-off-by Keith Busch <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

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

---
 drivers/nvme/host/tcp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/nvme/host/tcp.c +2 -1

index 4cf81f3841ae..7346a05d395b 100644
@@ -1140,7 +1140,8 @@ static void nvme_tcp_io_work(struct work_struct *w)
 				pending = true;
 			else if (unlikely(result < 0))
 				break;
-		}
+		} else
+			pending = !llist_empty(&queue->req_list);
 
 		result = nvme_tcp_try_recv(queue);
 		if (result > 0)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #17 lore raw

PATCH 17/104 nvme-fc: clear q_live at beginning of association teardown

From: James Smart <[email protected]>

[ Upstream commit a7d139145a6640172516b193abf6d2398620aa14 ]

The __nvmf_check_ready() routine used to bounce all filesystem io if the controller state isn't LIVE. However, a later patch changed the logic so that it rejection ends up being based on the Q live check. The FC transport has a slightly different sequence from rdma and tcp for shutting down queues/marking them non-live. FC marks its queue non-live after aborting all ios and waiting for their termination, leaving a rather large window for filesystem io to continue to hit the transport. Unfortunately this resulted in filesystem I/O or applications seeing I/O errors.

Change the FC transport to mark the queues non-live at the first sign of teardown for the association (when I/O is initially terminated).

Fixes 73a5379937ec ("nvme-fabrics: allow to queue requests for live queues")

Signed-off-by James Smart <[email protected]>

Reviewed-by Himanshu Madhani <[email protected]>

Reviewed-by Hannes Reinecke <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

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

---
 drivers/nvme/host/fc.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/nvme/host/fc.c +12 -0

index 41257daf7464..a0bcec33b020 100644
@@ -2460,6 +2460,18 @@ nvme_fc_terminate_exchange(struct request *req, void *data, bool reserved)
 static void
 __nvme_fc_abort_outstanding_ios(struct nvme_fc_ctrl *ctrl, bool start_queues)
 {
+	int q;
+
+	/*
+	 * if aborting io, the queues are no longer good, mark them
+	 * all as not live.
+	 */
+	if (ctrl->ctrl.queue_count > 1) {
+		for (q = 1; q < ctrl->ctrl.queue_count; q++)
+			clear_bit(NVME_FC_Q_LIVE, &ctrl->queues[q].flags);
+	}
+	clear_bit(NVME_FC_Q_LIVE, &ctrl->queues[0].flags);
+
 	/*
 	 * If io queues are present, stop them and terminate all outstanding
 	 * ios on them. As FC allocates FC exchange for each io, the

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #18 lore raw

PATCH 18/104 platform/mellanox: mlxbf-tmfifo: Fix a memory barrier issue

From: Liming Sun <[email protected]>

[ Upstream commit 1c0e5701c5e792c090aef0e5b9b8923c334d9324 ]

The virtio framework uses wmb() when updating avail->idx. It guarantees the write order, but not necessarily loading order for the code accessing the memory. This commit adds a load barrier after reading the avail->idx to make sure all the data in the descriptor is visible. It also adds a barrier when returning the packet to virtio framework to make sure read/writes are visible to the virtio code.

Fixes 1357dfd7261f ("platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc")

Signed-off-by Liming Sun <[email protected]>

Reviewed-by Vadim Pasternak <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Hans de Goede <[email protected]>

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

---
 drivers/platform/mellanox/mlxbf-tmfifo.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

drivers/platform/mellanox/mlxbf-tmfifo.c +10 -1

index bbc4e71a16ff..38800e86ed8a 100644
@@ -294,6 +294,9 @@ mlxbf_tmfifo_get_next_desc(struct mlxbf_tmfifo_vring *vring)
 	if (vring->next_avail == virtio16_to_cpu(vdev, vr->avail->idx))
 		return NULL;
 
+	/* Make sure 'avail->idx' is visible already. */
+	virtio_rmb(false);
+
 	idx = vring->next_avail % vr->num;
 	head = virtio16_to_cpu(vdev, vr->avail->ring[idx]);
 	if (WARN_ON(head >= vr->num))

@@ -322,7 +325,7 @@ static void mlxbf_tmfifo_release_desc(struct mlxbf_tmfifo_vring *vring,
 	 * done or not. Add a memory barrier here to make sure the update above
 	 * completes before updating the idx.
 	 */
-	mb();
+	virtio_mb(false);
 	vr->used->idx = cpu_to_virtio16(vdev, vr_idx + 1);
 }

@@ -733,6 +736,12 @@ static bool mlxbf_tmfifo_rxtx_one_desc(struct mlxbf_tmfifo_vring *vring,
 		desc = NULL;
 		fifo->vring[is_rx] = NULL;
 
+		/*
+		 * Make sure the load/store are in order before
+		 * returning back to virtio.
+		 */
+		virtio_mb(false);
+
 		/* Notify upper layer that packet is done. */
 		spin_lock_irqsave(&fifo->spin_lock[is_rx], flags);
 		vring_interrupt(0, vring->vq);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #19 lore raw

PATCH 19/104 platform/x86: intel_int0002_vgpio: Only call enable_irq_wake() when using s2idle

From: Hans de Goede <[email protected]>

[ Upstream commit b68e182a3062e326b891f47152a3a1b84abccf0f ]

Commit 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") stopped passing irq_set_wake requests on to the parents IRQ because this was breaking suspend (causing immediate wakeups) on an Asus E202SA.

This workaround for the Asus E202SA is causing wakeup by USB keyboard to not work on other devices with Airmont CPU cores such as the Medion Akoya E1239T. In hindsight the problem with the Asus E202SA has nothing to do with Silvermont vs Airmont CPU cores, so the differentiation between the 2 types of CPU cores introduced by the previous fix is wrong.

The real issue at hand is s2idle vs S3 suspend where the suspend is mostly handled by firmware. The parent IRQ for the INT0002 device is shared with the ACPI SCI and the real problem is that the INT0002 code should not be messing with the wakeup settings of that IRQ when suspend/resume is being handled by the firmware.

Note that on systems which support both s2idle and S3 suspend, which suspend method to use can be changed at runtime.

This patch fixes both the Asus E202SA spurious wakeups issue as well as the wakeup by USB keyboard not working on the Medion Akoya E1239T issue.

These are both fixed by replacing the old workaround with delaying the enable_irq_wake(parent_irq) call till system-suspend time and protecting it with a !pm_suspend_via_firmware() check so that we still do not call it on devices using firmware-based (S3) suspend such as the Asus E202SA.

Note rather then adding #ifdef CONFIG_PM_SLEEP, this commit simply adds a "depends on PM_SLEEP" to the Kconfig since this drivers whole purpose is to deal with wakeup events, so using it without CONFIG_PM_SLEEP makes no sense.

Cc Maxim Mikityanskiy <[email protected]>

Fixes 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail")

Signed-off-by Hans de Goede <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

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

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/platform/x86/Kconfig               |  2 +-
 drivers/platform/x86/intel_int0002_vgpio.c | 80 +++++++++++++++-------
 2 files changed, 57 insertions(+), 25 deletions(-)

drivers/platform/x86/Kconfig +1 -1

index 0d91d136bc3b..a1858689d6e1 100644
@@ -821,7 +821,7 @@ config INTEL_HID_EVENT
 
 config INTEL_INT0002_VGPIO
 	tristate "Intel ACPI INT0002 Virtual GPIO driver"
-	depends on GPIOLIB && ACPI
+	depends on GPIOLIB && ACPI && PM_SLEEP
 	select GPIOLIB_IRQCHIP
 	help
 	  Some peripherals on Bay Trail and Cherry Trail platforms signal a

drivers/platform/x86/intel_int0002_vgpio.c +56 ~~-24~~

147 lines not on this page · raw message

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #20 lore raw

PATCH 20/104 platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios

From: Hans de Goede <[email protected]>

[ Upstream commit 3a53587423d25c87af4b4126a806a0575104b45e ]

init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally, this leads to the following oops:

[  175.722921] ------------[ cut here ]------------
[  175.722925] Unexpected driver unregister!
[  175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40
...
[  175.723089] Call Trace:
[  175.723094]  cleanup_module+0x5/0xedd [dell_smbios]
...
[  175.723148] ---[ end trace 064c34e1ad49509d ]---

Make the unregister happen on the same condition the register happens to fix this.

Cc Mario Limonciello <[email protected]>

Fixes 1a258e670434 ("platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver")

Signed-off-by Hans de Goede <[email protected]>

Reviewed-by Mario Limonciello <[email protected]>

Reviewed-by Mark Gross <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

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

drivers/platform/x86/dell-smbios-wmi.c +2 -1

index 27a298b7c541..c97bd4a45242 100644
@@ -271,7 +271,8 @@ int init_dell_smbios_wmi(void)
 
 void exit_dell_smbios_wmi(void)
 {
-	wmi_driver_unregister(&dell_smbios_wmi_driver);
+	if (wmi_supported)
+		wmi_driver_unregister(&dell_smbios_wmi_driver);
 }
 
 MODULE_DEVICE_TABLE(wmi, dell_smbios_wmi_id_table);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #21 lore raw

PATCH 21/104 RDMA/mlx5: Fix query DCT via DEVX

Link https://lore.kernel.org/r/6eee15d63f09bb70787488e0cf96216e2957f5aa.1621413654.git.leonro@nvidia.com open here

From: Maor Gottlieb <[email protected]>

[ Upstream commit cfa3b797118eda7d68f9ede9b1a0279192aca653 ]

When executing DEVX command to query QP object, we need to take the QP type from the mlx5_ib_qp struct which hold the driver specific QP types as well, such as DC.

Fixes 34613eb1d2ad ("IB/mlx5: Enable modify and query verbs objects via DEVX")

Reviewed-by Yishai Hadas <[email protected]>

Signed-off-by Maor Gottlieb <[email protected]>

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

---
 drivers/infiniband/hw/mlx5/devx.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

drivers/infiniband/hw/mlx5/devx.c +2 -4

index efb9ec99b68b..06a873257619 100644
@@ -559,9 +559,8 @@ static bool devx_is_valid_obj_id(struct uverbs_attr_bundle *attrs,
 	case UVERBS_OBJECT_QP:
 	{
 		struct mlx5_ib_qp *qp = to_mqp(uobj->object);
-		enum ib_qp_type	qp_type = qp->ibqp.qp_type;
 
-		if (qp_type == IB_QPT_RAW_PACKET ||
+		if (qp->type == IB_QPT_RAW_PACKET ||
 		    (qp->flags & IB_QP_CREATE_SOURCE_QPN)) {
 			struct mlx5_ib_raw_packet_qp *raw_packet_qp =
 							 &qp->raw_packet_qp;

@@ -578,10 +577,9 @@ static bool devx_is_valid_obj_id(struct uverbs_attr_bundle *attrs,
 					       sq->tisn) == obj_id);
 		}
 
-		if (qp_type == MLX5_IB_QPT_DCT)
+		if (qp->type == MLX5_IB_QPT_DCT)
 			return get_enc_obj_id(MLX5_CMD_OP_CREATE_DCT,
 					      qp->dct.mdct.mqp.qpn) == obj_id;
-
 		return get_enc_obj_id(MLX5_CMD_OP_CREATE_QP,
 				      qp->ibqp.qp_num) == obj_id;
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #22 lore raw

PATCH 22/104 RDMA/uverbs: Fix a NULL vs IS_ERR() bug

Link https://lore.kernel.org/r/YJ6Got+U7lz+3n9a@mwanda open here

From: Dan Carpenter <[email protected]>

[ Upstream commit 463a3f66473b58d71428a1c3ce69ea52c05440e5 ]

The uapi_get_object() function returns error pointers, it never returns NULL.

Fixes 149d3845f4a5 ("RDMA/uverbs: Add a method to introspect handles in a context")

Signed-off-by Dan Carpenter <[email protected]>

Reviewed-by Leon Romanovsky <[email protected]>

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

---
 drivers/infiniband/core/uverbs_std_types_device.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/infiniband/core/uverbs_std_types_device.c +2 -2

index a03021d94e11..049684880ae0 100644
@@ -117,8 +117,8 @@ static int UVERBS_HANDLER(UVERBS_METHOD_INFO_HANDLES)(
 		return ret;
 
 	uapi_object = uapi_get_object(attrs->ufile->device->uapi, object_id);
-	if (!uapi_object)
-		return -EINVAL;
+	if (IS_ERR(uapi_object))
+		return PTR_ERR(uapi_object);
 
 	handles = gather_objects_handle(attrs->ufile, uapi_object, attrs,
 					out_len, &total);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #23 lore raw

PATCH 23/104 tools/testing/selftests/exec: fix link error

From: Yang Yingliang <[email protected]>

[ Upstream commit 4d1cd3b2c5c1c32826454de3a18c6183238d47ed ]

Fix the link error by adding '-static':

gcc -Wall -Wl,-z,max-page-size=0x1000 -pie load_address.c -o /home/yang/linux/tools/testing/selftests/exec/load_address_4096
/usr/bin/ld: /tmp/ccopEGun.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `stderr@@GLIBC_2.17' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccopEGun.o(.text+0x158): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `stderr@@GLIBC_2.17'
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make: *** [Makefile:25: tools/testing/selftests/exec/load_address_4096] Error 1

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

Fixes 206e22f01941 ("tools/testing/selftests: add self-test for verifying load alignment")

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

Cc Chris Kennelly <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

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

---
 tools/testing/selftests/exec/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

tools/testing/selftests/exec/Makefile +3 -3

index cf69b2fcce59..dd61118df66e 100644
@@ -28,8 +28,8 @@ $(OUTPUT)/execveat.denatured: $(OUTPUT)/execveat
 	cp $< $@
 	chmod -x $@
 $(OUTPUT)/load_address_4096: load_address.c
-	$(CC) $(CFLAGS) $(LDFLAGS) -Wl,-z,max-page-size=0x1000 -pie $< -o $@
+	$(CC) $(CFLAGS) $(LDFLAGS) -Wl,-z,max-page-size=0x1000 -pie -static $< -o $@
 $(OUTPUT)/load_address_2097152: load_address.c
-	$(CC) $(CFLAGS) $(LDFLAGS) -Wl,-z,max-page-size=0x200000 -pie $< -o $@
+	$(CC) $(CFLAGS) $(LDFLAGS) -Wl,-z,max-page-size=0x200000 -pie -static $< -o $@
 $(OUTPUT)/load_address_16777216: load_address.c
-	$(CC) $(CFLAGS) $(LDFLAGS) -Wl,-z,max-page-size=0x1000000 -pie $< -o $@
+	$(CC) $(CFLAGS) $(LDFLAGS) -Wl,-z,max-page-size=0x1000000 -pie -static $< -o $@

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #24 lore raw

PATCH 24/104 powerpc/pseries: Fix hcall tracing recursion in pv queued spinlocks

From: Nicholas Piggin <[email protected]>

[ Upstream commit 2c8c89b95831f46a2fb31a8d0fef4601694023ce ]

The paravit queued spinlock slow path adds itself to the queue then calls pv_wait to wait for the lock to become free. This is implemented by calling H_CONFER to donate cycles.

When hcall tracing is enabled, this H_CONFER call can lead to a spin lock being taken in the tracing code, which will result in the lock to be taken again, which will also go to the slow path because it queues behind itself and so won't ever make progress.

An example trace of a deadlock:

__pv_queued_spin_lock_slowpath
trace_clock_global
ring_buffer_lock_reserve
trace_event_buffer_lock_reserve
trace_event_buffer_reserve
trace_event_raw_event_hcall_exit
__trace_hcall_exit
plpar_hcall_norets_trace
__pv_queued_spin_lock_slowpath
trace_clock_global
ring_buffer_lock_reserve
trace_event_buffer_lock_reserve
trace_event_buffer_reserve
trace_event_raw_event_rcu_dyntick
rcu_irq_exit
irq_exit
__do_irq
call_do_irq
do_IRQ
hardware_interrupt_common_virt

Fix this by introducing plpar_hcall_norets_notrace(), and using that to make SPLPAR virtual processor dispatching hcalls by the paravirt spinlock code.

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

Reviewed-by Naveen N. Rao <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 arch/powerpc/include/asm/hvcall.h       |  3 +++
 arch/powerpc/include/asm/paravirt.h     | 22 +++++++++++++++++++---
 arch/powerpc/platforms/pseries/hvCall.S | 10 ++++++++++
 arch/powerpc/platforms/pseries/lpar.c   |  3 +--
 4 files changed, 33 insertions(+), 5 deletions(-)

arch/powerpc/include/asm/hvcall.h +3 -0

index c1fbccb04390..3e8e19f5746c 100644
@@ -437,6 +437,9 @@
  */
 long plpar_hcall_norets(unsigned long opcode, ...);
 
+/* Variant which does not do hcall tracing */
+long plpar_hcall_norets_notrace(unsigned long opcode, ...);
+
 /**
  * plpar_hcall: - Make a pseries hypervisor call
  * @opcode: The hypervisor call to make.

arch/powerpc/include/asm/paravirt.h +19 -3

index 9362c94fe3aa..588bfb9a0579 100644
@@ -24,19 +24,35 @@ static inline u32 yield_count_of(int cpu)
 	return be32_to_cpu(yield_count);
 }
 
+/*
+ * Spinlock code confers and prods, so don't trace the hcalls because the
+ * tracing code takes spinlocks which can cause recursion deadlocks.
+ *
+ * These calls are made while the lock is not held: the lock slowpath yields if
+ * it can not acquire the lock, and unlock slow path might prod if a waiter has
+ * yielded). So this may not be a problem for simple spin locks because the
+ * tracing does not technically recurse on the lock, but we avoid it anyway.
+ *
+ * However the queued spin lock contended path is more strictly ordered: the
+ * H_CONFER hcall is made after the task has queued itself on the lock, so then
+ * recursing on that lock will cause the task to then queue up again behind the
+ * first instance (or worse: queued spinlocks use tricks that assume a context
+ * never waits on more than one spinlock, so such recursion may cause random
+ * corruption in the lock code).
+ */
 static inline void yield_to_preempted(int cpu, u32 yield_count)
 {
-	plpar_hcall_norets(H_CONFER, get_hard_smp_processor_id(cpu), yield_count);
+	plpar_hcall_norets_notrace(H_CONFER, get_hard_smp_processor_id(cpu), yield_count);
 }
 
 static inline void prod_cpu(int cpu)
 {
-	plpar_hcall_norets(H_PROD, get_hard_smp_processor_id(cpu));
+	plpar_hcall_norets_notrace(H_PROD, get_hard_smp_processor_id(cpu));
 }
 
 static inline void yield_to_any(void)
 {
-	plpar_hcall_norets(H_CONFER, -1, 0);
+	plpar_hcall_norets_notrace(H_CONFER, -1, 0);
 }
 #else
 static inline bool is_shared_processor(void)

arch/powerpc/platforms/pseries/hvCall.S +10 -0

index 2136e42833af..8a2b8d64265b 100644
@@ -102,6 +102,16 @@ END_FTR_SECTION(0, 1);						\
 #define HCALL_BRANCH(LABEL)
 #endif
 
+_GLOBAL_TOC(plpar_hcall_norets_notrace)
+	HMT_MEDIUM
+
+	mfcr	r0
+	stw	r0,8(r1)
+	HVSC				/* invoke the hypervisor */
+	lwz	r0,8(r1)
+	mtcrf	0xff,r0
+	blr				/* return r3 = status */
+
 _GLOBAL_TOC(plpar_hcall_norets)
 	HMT_MEDIUM

arch/powerpc/platforms/pseries/lpar.c +1 -2

index 764170fdb0f7..1c3ac0f66336 100644
@@ -1827,8 +1827,7 @@ void hcall_tracepoint_unregfunc(void)
 
 /*
  * Since the tracing code might execute hcalls we need to guard against
- * recursion. One example of this are spinlocks calling H_YIELD on
- * shared processor partitions.
+ * recursion.
  */
 static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #25 lore raw

PATCH 25/104 ptrace: make ptrace() fail if the tracee changed its pid unexpectedly

From: Oleg Nesterov <[email protected]>

[ Upstream commit dbb5afad100a828c97e012c6106566d99f041db6 ]

Suppose we have 2 threads, the group-leader L and a sub-theread T, both parked in ptrace_stop(). Debugger tries to resume both threads and does

	ptrace(PTRACE_CONT, T);
	ptrace(PTRACE_CONT, L);

If the sub-thread T execs in between, the 2nd PTRACE_CONT doesn not resume the old leader L, it resumes the post-exec thread T which was actually now stopped in PTHREAD_EVENT_EXEC. In this case the PTHREAD_EVENT_EXEC event is lost, and the tracer can't know that the tracee changed its pid.

This patch makes ptrace() fail in this case until debugger does wait() and consumes PTHREAD_EVENT_EXEC which reports old_pid. This affects all ptrace requests except the "asynchronous" PTRACE_INTERRUPT/KILL.

The patch doesn't add the new PTRACE_ option to not complicate the API, and I _hope_ this won't cause any noticeable regression:

- If debugger uses PTRACE_O_TRACEEXEC and the thread did an exec and the tracer does a ptrace request without having consumed the exec event, it's 100% sure that the thread the ptracer thinks it is targeting does not exist anymore, or isn't the same as the one it thinks it is targeting.

- To some degree this patch adds nothing new. In the scenario above ptrace(L) can fail with -ESRCH if it is called after the execing sub-thread wakes the leader up and before it "steals" the leader's pid.

Test-case:

	#include <stdio.h>
	#include <unistd.h>
	#include <signal.h>
	#include <sys/ptrace.h>
	#include <sys/wait.h>
	#include <errno.h>
	#include <pthread.h>
	#include <assert.h>

	void *tf(void *arg)
	{
		execve("/usr/bin/true", NULL, NULL);
		assert(0);

		return NULL;
	}

	int main(void)
	{
		int leader = fork();
		if (!leader) {
			kill(getpid(), SIGSTOP);

			pthread_t th;
			pthread_create(&th, NULL, tf, NULL);
			for (;;)
				pause();

			return 0;
		}

		waitpid(leader, NULL, WSTOPPED);

		ptrace(PTRACE_SEIZE, leader, 0,
				PTRACE_O_TRACECLONE | PTRACE_O_TRACEEXEC);
		waitpid(leader, NULL, 0);

		ptrace(PTRACE_CONT, leader, 0,0);
		waitpid(leader, NULL, 0);

		int status, thread = waitpid(-1, &status, 0);
		assert(thread > 0 && thread != leader);
		assert(status == 0x80137f);

		ptrace(PTRACE_CONT, thread, 0,0);
		/*
		 * waitid() because waitpid(leader, &status, WNOWAIT) does not
		 * report status. Why ????
		 *
		 * Why WEXITED? because we have another kernel problem connected
		 * to mt-exec.
		 */
		siginfo_t info;
		assert(waitid(P_PID, leader, &info, WSTOPPED|WEXITED|WNOWAIT) == 0);
		assert(info.si_pid == leader && info.si_status == 0x0405);

		/* OK, it sleeps in ptrace(PTRACE_EVENT_EXEC == 0x04) */
		assert(ptrace(PTRACE_CONT, leader, 0,0) == -1);
		assert(errno == ESRCH);

		assert(leader == waitpid(leader, &status, WNOHANG));
		assert(status == 0x04057f);

		assert(ptrace(PTRACE_CONT, leader, 0,0) == 0);

		return 0;
	}

Signed-off-by Oleg Nesterov <[email protected]>

Reported-by Simon Marchi <[email protected]>

Acked-by "Eric W. Biederman" <[email protected]>

Acked-by Pedro Alves <[email protected]>

Acked-by Simon Marchi <[email protected]>

Acked-by Jan Kratochvil <[email protected]>

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

---
 kernel/ptrace.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

kernel/ptrace.c +17 -1

index 79de1294f8eb..eb4d04cb3aaf 100644
@@ -169,6 +169,21 @@ void __ptrace_unlink(struct task_struct *child)
 	spin_unlock(&child->sighand->siglock);
 }
 
+static bool looks_like_a_spurious_pid(struct task_struct *task)
+{
+	if (task->exit_code != ((PTRACE_EVENT_EXEC << 8) | SIGTRAP))
+		return false;
+
+	if (task_pid_vnr(task) == task->ptrace_message)
+		return false;
+	/*
+	 * The tracee changed its pid but the PTRACE_EVENT_EXEC event
+	 * was not wait()'ed, most probably debugger targets the old
+	 * leader which was destroyed in de_thread().
+	 */
+	return true;
+}
+
 /* Ensure that nothing can wake it up, even SIGKILL */
 static bool ptrace_freeze_traced(struct task_struct *task)
 {

@@ -179,7 +194,8 @@ static bool ptrace_freeze_traced(struct task_struct *task)
 		return ret;
 
 	spin_lock_irq(&task->sighand->siglock);
-	if (task_is_traced(task) && !__fatal_signal_pending(task)) {
+	if (task_is_traced(task) && !looks_like_a_spurious_pid(task) &&
+	    !__fatal_signal_pending(task)) {
 		task->state = __TASK_TRACED;
 		ret = true;
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #26 lore raw

PATCH 26/104 nvmet: seset ns->file when open fails

From: Daniel Wagner <[email protected]>

[ Upstream commit 85428beac80dbcace5b146b218697c73e367dcf5 ]

Reset the ns->file value to NULL also in the error case in nvmet_file_ns_enable().

The ns->file variable points either to file object or contains the error code after the filp_open() call. This can lead to following problem:

When the user first setups an invalid file backend and tries to enable the ns, it will fail. Then the user switches over to a bdev backend and enables successfully the ns. The first received I/O will crash the system because the IO backend is chosen based on the ns->file value:

static u16 nvmet_parse_io_cmd(struct nvmet_req *req)

{
	[...]

	if (req->ns->file)
		return nvmet_file_parse_io_cmd(req);

	return nvmet_bdev_parse_io_cmd(req);
}

Reported-by Enzo Matsumiya <[email protected]>

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

Signed-off-by Christoph Hellwig <[email protected]>

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

---
 drivers/nvme/target/io-cmd-file.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

drivers/nvme/target/io-cmd-file.c +5 -3

index 0abbefd9925e..b57599724448 100644
@@ -49,9 +49,11 @@ int nvmet_file_ns_enable(struct nvmet_ns *ns)
 
 	ns->file = filp_open(ns->device_path, flags, 0);
 	if (IS_ERR(ns->file)) {
-		pr_err("failed to open file %s: (%ld)\n",
-				ns->device_path, PTR_ERR(ns->file));
-		return PTR_ERR(ns->file);
+		ret = PTR_ERR(ns->file);
+		pr_err("failed to open file %s: (%d)\n",
+			ns->device_path, ret);
+		ns->file = NULL;
+		return ret;
 	}
 
 	ret = nvmet_file_ns_revalidate(ns);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #27 lore raw

PATCH 27/104 perf/x86: Avoid touching LBR_TOS MSR for Arch LBR

From: Like Xu <[email protected]>

[ Upstream commit 3317c26a4b413b41364f2c4b83c778c6aba1576d ]

The Architecture LBR does not have MSR_LBR_TOS (0x000001c9). In a guest that should support Architecture LBR, check_msr() will be a non-related check for the architecture MSR 0x0 (IA32_P5_MC_ADDR) that is also not supported by KVM.

The failure will cause x86_pmu.lbr_nr = 0, thereby preventing the initialization of the guest Arch LBR. Fix it by avoiding this extraneous check in intel_pmu_init() for Arch LBR.

Fixes 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")

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

[peterz: simpler still]

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

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

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

---
 arch/x86/events/intel/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/events/intel/core.c +1 -1

index 0b9975200ae3..ee659b5faf71 100644
@@ -5563,7 +5563,7 @@ __init int intel_pmu_init(void)
 	 * Check all LBT MSR here.
 	 * Disable LBR access if any LBR MSRs can not be accessed.
 	 */
-	if (x86_pmu.lbr_nr && !check_msr(x86_pmu.lbr_tos, 0x3UL))
+	if (x86_pmu.lbr_tos && !check_msr(x86_pmu.lbr_tos, 0x3UL))
 		x86_pmu.lbr_nr = 0;
 	for (i = 0; i < x86_pmu.lbr_nr; i++) {
 		if (!(check_msr(x86_pmu.lbr_from + i, 0xffffUL) &&

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #28 lore raw

PATCH 28/104 locking/lockdep: Correct calling tracepoints

From: Leo Yan <[email protected]>

[ Upstream commit 89e70d5c583c55088faa2201d397ee30a15704aa ]

The commit eb1f00237aca ("lockdep,trace: Expose tracepoints") reverses tracepoints for lock_contended() and lock_acquired(), thus the ftrace log shows the wrong locking sequence that "acquired" event is prior to "contended" event:

  <idle>-0       [001] d.s3 20803.501685: lock_acquire: 0000000008b91ab4 &sg_policy->update_lock
  <idle>-0       [001] d.s3 20803.501686: lock_acquired: 0000000008b91ab4 &sg_policy->update_lock
  <idle>-0       [001] d.s3 20803.501689: lock_contended: 0000000008b91ab4 &sg_policy->update_lock
  <idle>-0       [001] d.s3 20803.501690: lock_release: 0000000008b91ab4 &sg_policy->update_lock

This patch fixes calling tracepoints for lock_contended() and lock_acquired().

Fixes eb1f00237aca ("lockdep,trace: Expose tracepoints")

Signed-off-by Leo Yan <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

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

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

---
 kernel/locking/lockdep.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

kernel/locking/lockdep.c +2 -2

index 38d7c03e694c..858b96b438ce 100644
@@ -5664,7 +5664,7 @@ void lock_contended(struct lockdep_map *lock, unsigned long ip)
 {
 	unsigned long flags;
 
-	trace_lock_acquired(lock, ip);
+	trace_lock_contended(lock, ip);
 
 	if (unlikely(!lock_stat || !lockdep_enabled()))
 		return;

@@ -5682,7 +5682,7 @@ void lock_acquired(struct lockdep_map *lock, unsigned long ip)
 {
 	unsigned long flags;
 
-	trace_lock_contended(lock, ip);
+	trace_lock_acquired(lock, ip);
 
 	if (unlikely(!lock_stat || !lockdep_enabled()))
 		return;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #29 lore raw

PATCH 29/104 locking/mutex: clear MUTEX_FLAGS if wait_list is empty due to signal

From: Zqiang <[email protected]>

[ Upstream commit 3a010c493271f04578b133de977e0e5dd2848cea ]

When a interruptible mutex locker is interrupted by a signal without acquiring this lock and removed from the wait queue. if the mutex isn't contended enough to have a waiter put into the wait queue again, the setting of the WAITER bit will force mutex locker to go into the slowpath to acquire the lock every time, so if the wait queue is empty, the WAITER bit need to be clear.

Fixes 040a0a371005 ("mutex: Add support for wound/wait style locks")

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

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

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

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

---
 kernel/locking/mutex-debug.c |  4 ++--
 kernel/locking/mutex-debug.h |  2 +-
 kernel/locking/mutex.c       | 18 +++++++++++++-----
 kernel/locking/mutex.h       |  4 +---
 4 files changed, 17 insertions(+), 11 deletions(-)

kernel/locking/mutex-debug.c +2 -2

index a7276aaf2abc..db9301591e3f 100644
@@ -57,7 +57,7 @@ void debug_mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
 	task->blocked_on = waiter;
 }
 
-void mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter,
+void debug_mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter,
 			 struct task_struct *task)
 {
 	DEBUG_LOCKS_WARN_ON(list_empty(&waiter->list));

@@ -65,7 +65,7 @@ void mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter,
 	DEBUG_LOCKS_WARN_ON(task->blocked_on != waiter);
 	task->blocked_on = NULL;
 
-	list_del_init(&waiter->list);
+	INIT_LIST_HEAD(&waiter->list);
 	waiter->task = NULL;
 }

kernel/locking/mutex-debug.h +1 -1

index 1edd3f45a4ec..53e631e1d76d 100644
@@ -22,7 +22,7 @@ extern void debug_mutex_free_waiter(struct mutex_waiter *waiter);
 extern void debug_mutex_add_waiter(struct mutex *lock,
 				   struct mutex_waiter *waiter,
 				   struct task_struct *task);
-extern void mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter,
+extern void debug_mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter,
 				struct task_struct *task);
 extern void debug_mutex_unlock(struct mutex *lock);
 extern void debug_mutex_init(struct mutex *lock, const char *name,

kernel/locking/mutex.c +13 -5

index 2c25b830203c..15ac7c4bb111 100644
@@ -204,7 +204,7 @@ static inline bool __mutex_waiter_is_first(struct mutex *lock, struct mutex_wait
  * Add @waiter to a given location in the lock wait_list and set the
  * FLAG_WAITERS flag if it's the first waiter.
  */
-static void __sched
+static void
 __mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
 		   struct list_head *list)
 {

@@ -215,6 +215,16 @@ __mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
 		__mutex_set_flag(lock, MUTEX_FLAG_WAITERS);
 }
 
+static void
+__mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter)
+{
+	list_del(&waiter->list);
+	if (likely(list_empty(&lock->wait_list)))
+		__mutex_clear_flag(lock, MUTEX_FLAGS);
+
+	debug_mutex_remove_waiter(lock, waiter, current);
+}
+
 /*
  * Give up ownership to a specific task, when @task = NULL, this is equivalent
  * to a regular unlock. Sets PICKUP on a handoff, clears HANDOF, preserves

@@ -1071,9 +1081,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 			__ww_mutex_check_waiters(lock, ww_ctx);
 	}
 
-	mutex_remove_waiter(lock, &waiter, current);
-	if (likely(list_empty(&lock->wait_list)))
-		__mutex_clear_flag(lock, MUTEX_FLAGS);
+	__mutex_remove_waiter(lock, &waiter);
 
 	debug_mutex_free_waiter(&waiter);

@@ -1090,7 +1098,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 
 err:
 	__set_current_state(TASK_RUNNING);
-	mutex_remove_waiter(lock, &waiter, current);
+	__mutex_remove_waiter(lock, &waiter);
 err_early_kill:
 	spin_unlock(&lock->wait_lock);
 	debug_mutex_free_waiter(&waiter);

kernel/locking/mutex.h +1 -3

index 1c2287d3fa71..f0c710b1d192 100644
@@ -10,12 +10,10 @@
  * !CONFIG_DEBUG_MUTEXES case. Most of them are NOPs:
  */
 
-#define mutex_remove_waiter(lock, waiter, task) \
-		__list_del((waiter)->list.prev, (waiter)->list.next)
-
 #define debug_mutex_wake_waiter(lock, waiter)		do { } while (0)
 #define debug_mutex_free_waiter(waiter)			do { } while (0)
 #define debug_mutex_add_waiter(lock, waiter, ti)	do { } while (0)
+#define debug_mutex_remove_waiter(lock, waiter, ti)     do { } while (0)
 #define debug_mutex_unlock(lock)			do { } while (0)
 #define debug_mutex_init(lock, name, key)		do { } while (0)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #30 lore raw

PATCH 30/104 powerpc: Fix early setup to make early_ioremap() work

From: Alexey Kardashevskiy <[email protected]>

[ Upstream commit e2f5efd0f0e229bd110eab513e7c0331d61a4649 ]

The immediate problem is that after commit
0bd3f9e953bd ("powerpc/legacy_serial: Use early_ioremap()") the kernel silently reboots on some systems.

The reason is that early_ioremap() returns broken addresses as it uses slot_virt[] array which initialized with offsets from FIXADDR_TOP == IOREMAP_END+FIXADDR_SIZE == KERN_IO_END - FIXADDR_SIZ + FIXADDR_SIZE == __kernel_io_end which is 0 when early_ioremap_setup() is called. __kernel_io_end is initialized little bit later in early_init_mmu().

This fixes the initialization by swapping early_ioremap_setup() and early_init_mmu().

Fixes 265c3491c4bc ("powerpc: Add support for GENERIC_EARLY_IOREMAP")

Signed-off-by Alexey Kardashevskiy <[email protected]>

Reviewed-by Christophe Leroy <[email protected]>

[mpe: Drop unrelated cleanup & cleanup change log]

Link https://lore.kernel.org/r/[email protected] open here

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

---
 arch/powerpc/kernel/setup_64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/powerpc/kernel/setup_64.c +2 -2

index 3b871ecb3a92..3f8426bccd16 100644
@@ -368,11 +368,11 @@ void __init early_setup(unsigned long dt_ptr)
 	apply_feature_fixups();
 	setup_feature_keys();
 
-	early_ioremap_setup();
-
 	/* Initialize the hash table or TLB handling */
 	early_init_mmu();
 
+	early_ioremap_setup();
+
 	/*
 	 * After firmware and early platform setup code has set things up,
 	 * we note the SPR values for configurable control/performance

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #31 lore raw

PATCH 31/104 btrfs: avoid RCU stalls while running delayed iputs

From: Josef Bacik <[email protected]>

commit 71795ee590111e3636cc3c148289dfa9fa0a5fc3 upstream.

Generally a delayed iput is added when we might do the final iput, so usually we'll end up sleeping while processing the delayed iputs naturally. However there's no guarantee of this, especially for small files. In production we noticed 5 instances of RCU stalls while testing a kernel release overnight across 1000 machines, so this is relatively common:

host count: 5

  rcu: INFO: rcu_sched self-detected stall on CPU
  rcu: ....: (20998 ticks this GP) idle=59e/1/0x4000000000000002 softirq=12333372/12333372 fqs=3208
   	(t=21031 jiffies g=27810193 q=41075) NMI backtrace for cpu 1
  CPU: 1 PID: 1713 Comm: btrfs-cleaner Kdump: loaded Not tainted 5.6.13-0_fbk12_rc1_5520_gec92bffc1ec9 #1
  Call Trace:
    <IRQ> dump_stack+0x50/0x70
    nmi_cpu_backtrace.cold.6+0x30/0x65
    ? lapic_can_unplug_cpu.cold.30+0x40/0x40
    nmi_trigger_cpumask_backtrace+0xba/0xca
    rcu_dump_cpu_stacks+0x99/0xc7
    rcu_sched_clock_irq.cold.90+0x1b2/0x3a3
    ? trigger_load_balance+0x5c/0x200
    ? tick_sched_do_timer+0x60/0x60
    ? tick_sched_do_timer+0x60/0x60
    update_process_times+0x24/0x50
    tick_sched_timer+0x37/0x70
    __hrtimer_run_queues+0xfe/0x270
    hrtimer_interrupt+0xf4/0x210
    smp_apic_timer_interrupt+0x5e/0x120
    apic_timer_interrupt+0xf/0x20 </IRQ>
   RIP: 0010:queued_spin_lock_slowpath+0x17d/0x1b0
   RSP: 0018:ffffc9000da5fe48 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
   RAX: 0000000000000000 RBX: ffff889fa81d0cd8 RCX: 0000000000000029
   RDX: ffff889fff86c0c0 RSI: 0000000000080000 RDI: ffff88bfc2da7200
   RBP: ffff888f2dcdd768 R08: 0000000001040000 R09: 0000000000000000
   R10: 0000000000000001 R11: ffffffff82a55560 R12: ffff88bfc2da7200
   R13: 0000000000000000 R14: ffff88bff6c2a360 R15: ffffffff814bd870
   ? kzalloc.constprop.57+0x30/0x30
   list_lru_add+0x5a/0x100
   inode_lru_list_add+0x20/0x40
   iput+0x1c1/0x1f0
   run_delayed_iput_locked+0x46/0x90
   btrfs_run_delayed_iputs+0x3f/0x60
   cleaner_kthread+0xf2/0x120
   kthread+0x10b/0x130

Fix this by adding a cond_resched_lock() to the loop processing delayed iputs so we can avoid these sort of stalls.

CC [email protected] # 4.9+

Reviewed-by Rik van Riel <[email protected]>

Signed-off-by Josef Bacik <[email protected]>

Reviewed-by David Sterba <[email protected]>

Signed-off-by David Sterba <[email protected]>

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

---
 fs/btrfs/inode.c |    1 +
 1 file changed, 1 insertion(+)

fs/btrfs/inode.c +1 -0

@@ -2967,6 +2967,7 @@ void btrfs_run_delayed_iputs(struct btrf
 		inode = list_first_entry(&fs_info->delayed_iputs,
 				struct btrfs_inode, delayed_iput);
 		run_delayed_iput_locked(fs_info, inode);
+		cond_resched_lock(&fs_info->delayed_iput_lock);
 	}
 	spin_unlock(&fs_info->delayed_iput_lock);
 }

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #32 lore raw

PATCH 32/104 cifs: fix memory leak in smb2_copychunk_range

From: Ronnie Sahlberg <[email protected]>

commit d201d7631ca170b038e7f8921120d05eec70d7c5 upstream.

When using smb2_copychunk_range() for large ranges we will run through several iterations of a loop calling SMB2_ioctl() but never actually free the returned buffer except for the final iteration.
This leads to memory leaks everytime a large copychunk is requested.

Fixes 9bf0c9cd4314 ("CIFS: Fix SMB2/SMB3 Copy offload support (refcopy) for large files")

Reviewed-by Aurelien Aptel <[email protected]>

Signed-off-by Ronnie Sahlberg <[email protected]>

Signed-off-by Steve French <[email protected]>

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

---
 fs/cifs/smb2ops.c |    2 ++
 1 file changed, 2 insertions(+)

fs/cifs/smb2ops.c +2 -0

@@ -1764,6 +1764,8 @@ smb2_copychunk_range(const unsigned int
 			cpu_to_le32(min_t(u32, len, tcon->max_bytes_chunk));
 
 		/* Request server copy to target from src identified by key */
+		kfree(retbuf);
+		retbuf = NULL;
 		rc = SMB2_ioctl(xid, tcon, trgtfile->fid.persistent_fid,
 			trgtfile->fid.volatile_fid, FSCTL_SRV_COPYCHUNK_WRITE,
 			true /* is_fsctl */, (char *)pcchunk,

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #33 lore raw

PATCH 33/104 misc: eeprom: at24: check suspend status before disable regulator

From: Hsin-Yi Wang <[email protected]>

commit 2962484dfef8dbb7f9059822bc26ce8a04d0e47c upstream.

cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") disables regulator in runtime suspend. If runtime suspend is called before regulator disable, it will results in regulator unbalanced disabling.

Fixes cd5676db0574 ("misc: eeprom: at24: support pm_runtime control")

Cc stable <[email protected]>

Acked-by Bartosz Golaszewski <[email protected]>

Signed-off-by Hsin-Yi Wang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/misc/eeprom/at24.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/misc/eeprom/at24.c +4 -2

@@ -763,7 +763,8 @@ static int at24_probe(struct i2c_client
 	at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
 	if (IS_ERR(at24->nvmem)) {
 		pm_runtime_disable(dev);
-		regulator_disable(at24->vcc_reg);
+		if (!pm_runtime_status_suspended(dev))
+			regulator_disable(at24->vcc_reg);
 		return PTR_ERR(at24->nvmem);
 	}

@@ -774,7 +775,8 @@ static int at24_probe(struct i2c_client
 	err = at24_read(at24, 0, &test_byte, 1);
 	if (err) {
 		pm_runtime_disable(dev);
-		regulator_disable(at24->vcc_reg);
+		if (!pm_runtime_status_suspended(dev))
+			regulator_disable(at24->vcc_reg);
 		return -ENODEV;
 	}

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #34 lore raw

PATCH 34/104 ALSA: dice: fix stream format for TC Electronic Konnekt Live at high sampling transfer frequency

From: Takashi Sakamoto <[email protected]>

commit 4c6fe8c547e3c9e8c15dabdd23c569ee0df3adb1 upstream.

At high sampling transfer frequency, TC Electronic Konnekt Live transfers/receives 6 audio data frames in multi bit linear audio data channel of data block in CIP payload. Current hard-coded stream format is wrong.

Fixes f1f0f330b1d0 ("ALSA: dice: add parameters of stream formats for models produced by TC Electronic")

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/firewire/dice/dice-tcelectronic.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

sound/firewire/dice/dice-tcelectronic.c +2 -2

@@ -38,8 +38,8 @@ static const struct dice_tc_spec konnekt
 };
 
 static const struct dice_tc_spec konnekt_live = {
-	.tx_pcm_chs = {{16, 16, 16}, {0, 0, 0} },
-	.rx_pcm_chs = {{16, 16, 16}, {0, 0, 0} },
+	.tx_pcm_chs = {{16, 16, 6}, {0, 0, 0} },
+	.rx_pcm_chs = {{16, 16, 6}, {0, 0, 0} },
 	.has_midi = true,
 };

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #35 lore raw

PATCH 35/104 ALSA: intel8x0: Dont update period unless prepared

From: Takashi Iwai <[email protected]>

commit c1f0616124c455c5c762b6f123e40bba5df759e6 upstream.

The interrupt handler of intel8x0 calls snd_intel8x0_update() whenever the hardware sets the corresponding status bit for each stream. This works fine for most cases as long as the hardware behaves properly. But when the hardware gives a wrong bit set, this leads to a zero- division Oops, and reportedly, this seems what happened on a VM.

For fixing the crash, this patch adds a internal flag indicating that the stream is ready to be updated, and check it (as well as the flag being in suspended) to ignore such spurious update.

Reported-and-tested-by Sergey Senozhatsky <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/pci/intel8x0.c |    7 +++++++
 1 file changed, 7 insertions(+)

sound/pci/intel8x0.c +7 -0

@@ -354,6 +354,7 @@ struct ichdev {
 	unsigned int ali_slot;			/* ALI DMA slot */
 	struct ac97_pcm *pcm;
 	int pcm_open_flag;
+	unsigned int prepared:1;
 	unsigned int suspended: 1;
 };

@@ -714,6 +715,9 @@ static inline void snd_intel8x0_update(s
 	int status, civ, i, step;
 	int ack = 0;
 
+	if (!ichdev->prepared || ichdev->suspended)
+		return;
+
 	spin_lock_irqsave(&chip->reg_lock, flags);
 	status = igetbyte(chip, port + ichdev->roff_sr);
 	civ = igetbyte(chip, port + ICH_REG_OFF_CIV);

@@ -904,6 +908,7 @@ static int snd_intel8x0_hw_params(struct
 	if (ichdev->pcm_open_flag) {
 		snd_ac97_pcm_close(ichdev->pcm);
 		ichdev->pcm_open_flag = 0;
+		ichdev->prepared = 0;
 	}
 	err = snd_ac97_pcm_open(ichdev->pcm, params_rate(hw_params),
 				params_channels(hw_params),

@@ -925,6 +930,7 @@ static int snd_intel8x0_hw_free(struct s
 	if (ichdev->pcm_open_flag) {
 		snd_ac97_pcm_close(ichdev->pcm);
 		ichdev->pcm_open_flag = 0;
+		ichdev->prepared = 0;
 	}
 	return 0;
 }

@@ -999,6 +1005,7 @@ static int snd_intel8x0_pcm_prepare(stru
 			ichdev->pos_shift = (runtime->sample_bits > 16) ? 2 : 1;
 	}
 	snd_intel8x0_setup_periods(chip, ichdev);
+	ichdev->prepared = 1;
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #36 lore raw

PATCH 36/104 ALSA: firewire-lib: fix amdtp_packet tracepoints event for packet_index field

From: Takashi Sakamoto <[email protected]>

commit 814b43127f4ac69332e809152e30773941438aff upstream.

The snd_firewire_lib:amdtp_packet tracepoints event includes index of packet processed in a context handling. However in IR context, it is not calculated as expected.

Fixes 753e717986c2 ("ALSA: firewire-lib: use packet descriptor for IR context")

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/firewire/amdtp-stream-trace.h |    6 +++---
 sound/firewire/amdtp-stream.c       |   15 +++++++++------
 2 files changed, 12 insertions(+), 9 deletions(-)

sound/firewire/amdtp-stream-trace.h +3 -3

@@ -14,8 +14,8 @@
 #include <linux/tracepoint.h>
 
 TRACE_EVENT(amdtp_packet,
-	TP_PROTO(const struct amdtp_stream *s, u32 cycles, const __be32 *cip_header, unsigned int payload_length, unsigned int data_blocks, unsigned int data_block_counter, unsigned int index),
-	TP_ARGS(s, cycles, cip_header, payload_length, data_blocks, data_block_counter, index),
+	TP_PROTO(const struct amdtp_stream *s, u32 cycles, const __be32 *cip_header, unsigned int payload_length, unsigned int data_blocks, unsigned int data_block_counter, unsigned int packet_index, unsigned int index),
+	TP_ARGS(s, cycles, cip_header, payload_length, data_blocks, data_block_counter, packet_index, index),
 	TP_STRUCT__entry(
 		__field(unsigned int, second)
 		__field(unsigned int, cycle)

@@ -48,7 +48,7 @@ TRACE_EVENT(amdtp_packet,
 		__entry->payload_quadlets = payload_length / sizeof(__be32);
 		__entry->data_blocks = data_blocks;
 		__entry->data_block_counter = data_block_counter,
-		__entry->packet_index = s->packet_index;
+		__entry->packet_index = packet_index;
 		__entry->irq = !!in_interrupt();
 		__entry->index = index;
 	),

sound/firewire/amdtp-stream.c +9 -6

@@ -526,7 +526,7 @@ static void build_it_pkt_header(struct a
 	}
 
 	trace_amdtp_packet(s, cycle, cip_header, payload_length, data_blocks,
-			   data_block_counter, index);
+			   data_block_counter, s->packet_index, index);
 }
 
 static int check_cip_header(struct amdtp_stream *s, const __be32 *buf,

@@ -630,7 +630,7 @@ static int parse_ir_ctx_header(struct am
 			       unsigned int *payload_length,
 			       unsigned int *data_blocks,
 			       unsigned int *data_block_counter,
-			       unsigned int *syt, unsigned int index)
+			       unsigned int *syt, unsigned int packet_index, unsigned int index)
 {
 	const __be32 *cip_header;
 	int err;

@@ -662,7 +662,7 @@ static int parse_ir_ctx_header(struct am
 	}
 
 	trace_amdtp_packet(s, cycle, cip_header, *payload_length, *data_blocks,
-			   *data_block_counter, index);
+			   *data_block_counter, packet_index, index);
 
 	return err;
 }

@@ -701,12 +701,13 @@ static int generate_device_pkt_descs(str
 				     unsigned int packets)
 {
 	unsigned int dbc = s->data_block_counter;
+	unsigned int packet_index = s->packet_index;
+	unsigned int queue_size = s->queue_size;
 	int i;
 	int err;
 
 	for (i = 0; i < packets; ++i) {
 		struct pkt_desc *desc = descs + i;
-		unsigned int index = (s->packet_index + i) % s->queue_size;
 		unsigned int cycle;
 		unsigned int payload_length;
 		unsigned int data_blocks;

@@ -715,7 +716,7 @@ static int generate_device_pkt_descs(str
 		cycle = compute_cycle_count(ctx_header[1]);
 
 		err = parse_ir_ctx_header(s, cycle, ctx_header, &payload_length,
-					  &data_blocks, &dbc, &syt, i);
+					  &data_blocks, &dbc, &syt, packet_index, i);
 		if (err < 0)
 			return err;

@@ -723,13 +724,15 @@ static int generate_device_pkt_descs(str
 		desc->syt = syt;
 		desc->data_blocks = data_blocks;
 		desc->data_block_counter = dbc;
-		desc->ctx_payload = s->buffer.packets[index].buffer;
+		desc->ctx_payload = s->buffer.packets[packet_index].buffer;
 
 		if (!(s->flags & CIP_DBC_IS_END_EVENT))
 			dbc = (dbc + desc->data_blocks) & 0xff;
 
 		ctx_header +=
 			s->ctx_data.tx.ctx_header_size / sizeof(*ctx_header);
+
+		packet_index = (packet_index + 1) % queue_size;
 	}
 
 	s->data_block_counter = dbc;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #37 lore raw

PATCH 37/104 ALSA: line6: Fix racy initialization of LINE6 MIDI

Link https://lore.kernel.org/r/20210517132725.GA50495@hyeyoo open here

From: Takashi Iwai <[email protected]>

commit 05ca447630334c323c9e2b788b61133ab75d60d3 upstream.

The initialization of MIDI devices that are found on some LINE6 drivers are currently done in a racy way; namely, the MIDI buffer instance is allocated and initialized in each private_init callback while the communication with the interface is already started via line6_init_cap_control() call before that point. This may lead to Oops in line6_data_received() when a spurious event is received, as reported by syzkaller.

This patch moves the MIDI initialization to line6_init_cap_control() as well instead of the too-lately-called private_init for avoiding the race. Also this reduces slightly more lines, so it's a win-win change.

Reported-by [email protected]

Link https://lore.kernel.org/r/[email protected] open here

Cc Hyeonggon Yoo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/usb/line6/driver.c |    4 ++++
 sound/usb/line6/pod.c    |    5 -----
 sound/usb/line6/variax.c |    6 ------
 3 files changed, 4 insertions(+), 11 deletions(-)

sound/usb/line6/driver.c +4 -0

@@ -699,6 +699,10 @@ static int line6_init_cap_control(struct
 		line6->buffer_message = kmalloc(LINE6_MIDI_MESSAGE_MAXLEN, GFP_KERNEL);
 		if (!line6->buffer_message)
 			return -ENOMEM;
+
+		ret = line6_init_midi(line6);
+		if (ret < 0)
+			return ret;
 	} else {
 		ret = line6_hwdep_init(line6);
 		if (ret < 0)

sound/usb/line6/pod.c +0 -5

@@ -376,11 +376,6 @@ static int pod_init(struct usb_line6 *li
 	if (err < 0)
 		return err;
 
-	/* initialize MIDI subsystem: */
-	err = line6_init_midi(line6);
-	if (err < 0)
-		return err;
-
 	/* initialize PCM subsystem: */
 	err = line6_init_pcm(line6, &pod_pcm_properties);
 	if (err < 0)

sound/usb/line6/variax.c +0 -6

@@ -159,7 +159,6 @@ static int variax_init(struct usb_line6
 		       const struct usb_device_id *id)
 {
 	struct usb_line6_variax *variax = line6_to_variax(line6);
-	int err;
 
 	line6->process_message = line6_variax_process_message;
 	line6->disconnect = line6_variax_disconnect;

@@ -172,11 +171,6 @@ static int variax_init(struct usb_line6
 	if (variax->buffer_activate == NULL)
 		return -ENOMEM;
 
-	/* initialize MIDI subsystem: */
-	err = line6_init_midi(&variax->line6);
-	if (err < 0)
-		return err;
-
 	/* initiate startup procedure: */
 	schedule_delayed_work(&line6->startup_work,
 			      msecs_to_jiffies(VARIAX_STARTUP_DELAY1));

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #38 lore raw

PATCH 38/104 ALSA: dice: fix stream format at middle sampling rate for Alesis iO 26

From: Takashi Sakamoto <[email protected]>

commit 1b6604896e78969baffc1b6cc6bc175f95929ac4 upstream.

Alesis iO 26 FireWire has two pairs of digital optical interface. It delivers PCM frames from the interfaces by second isochronous packet streaming. Although both of the interfaces are available at 44.1/48.0 kHz, first one of them is only available at 88.2/96.0 kHz. It reduces the number of PCM samples to 4 in Multi Bit Linear Audio data channel of data blocks on the second isochronous packet streaming.

This commit fixes hardcoded stream formats.

Fixes 28b208f600a3 ("ALSA: dice: add parameters of stream formats for models produced by Alesis")

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/firewire/dice/dice-alesis.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/firewire/dice/dice-alesis.c +1 -1

@@ -16,7 +16,7 @@ alesis_io14_tx_pcm_chs[MAX_STREAMS][SND_
 static const unsigned int
 alesis_io26_tx_pcm_chs[MAX_STREAMS][SND_DICE_RATE_MODE_COUNT] = {
 	{10, 10, 4},	/* Tx0 = Analog + S/PDIF. */
-	{16, 8, 0},	/* Tx1 = ADAT1 + ADAT2. */
+	{16, 4, 0},	/* Tx1 = ADAT1 + ADAT2 (available at low rate). */
 };
 
 int snd_dice_detect_alesis_formats(struct snd_dice *dice)

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #39 lore raw

PATCH 39/104 ALSA: firewire-lib: fix calculation for size of IR context payload

From: Takashi Sakamoto <[email protected]>

commit 1be4f21d9984fa9835fae5411a29465dc5aece6f upstream.

The quadlets for CIP header is handled as a part of IR context header, thus it doesn't join in IR context payload. However current calculation includes the quadlets in IR context payload.

Fixes f11453c7cc01 ("ALSA: firewire-lib: use 16 bytes IR context header to separate CIP header")

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/firewire/amdtp-stream.c |   13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

sound/firewire/amdtp-stream.c +6 -7

@@ -1068,23 +1068,22 @@ static int amdtp_stream_start(struct amd
 		s->data_block_counter = 0;
 	}
 
-	/* initialize packet buffer */
+	// initialize packet buffer.
+	max_ctx_payload_size = amdtp_stream_get_max_payload(s);
 	if (s->direction == AMDTP_IN_STREAM) {
 		dir = DMA_FROM_DEVICE;
 		type = FW_ISO_CONTEXT_RECEIVE;
-		if (!(s->flags & CIP_NO_HEADER))
+		if (!(s->flags & CIP_NO_HEADER)) {
+			max_ctx_payload_size -= 8;
 			ctx_header_size = IR_CTX_HEADER_SIZE_CIP;
-		else
+		} else {
 			ctx_header_size = IR_CTX_HEADER_SIZE_NO_CIP;
-
-		max_ctx_payload_size = amdtp_stream_get_max_payload(s) -
-				       ctx_header_size;
+		}
 	} else {
 		dir = DMA_TO_DEVICE;
 		type = FW_ISO_CONTEXT_TRANSMIT;
 		ctx_header_size = 0;	// No effect for IT context.
 
-		max_ctx_payload_size = amdtp_stream_get_max_payload(s);
 		if (!(s->flags & CIP_NO_HEADER))
 			max_ctx_payload_size -= IT_PKT_HEADER_SIZE_CIP;
 	}

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #40 lore raw

PATCH 40/104 ALSA: usb-audio: Validate MS endpoint descriptors

From: Takashi Iwai <[email protected]>

commit e84749a78dc82bc545f12ce009e3dbcc2c5a8a91 upstream.

snd_usbmidi_get_ms_info() may access beyond the border when a malformed descriptor is passed. This patch adds the sanity checks of the given MS endpoint descriptors, and skips invalid ones.

Reported-by [email protected]

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/usb/midi.c |    4 ++++
 1 file changed, 4 insertions(+)

sound/usb/midi.c +4 -0

@@ -1889,8 +1889,12 @@ static int snd_usbmidi_get_ms_info(struc
 		ms_ep = find_usb_ms_endpoint_descriptor(hostep);
 		if (!ms_ep)
 			continue;
+		if (ms_ep->bLength <= sizeof(*ms_ep))
+			continue;
 		if (ms_ep->bNumEmbMIDIJack > 0x10)
 			continue;
+		if (ms_ep->bLength < sizeof(*ms_ep) + ms_ep->bNumEmbMIDIJack)
+			continue;
 		if (usb_endpoint_dir_out(ep)) {
 			if (endpoints[epidx].out_ep) {
 				if (++epidx >= MIDI_MAX_ENDPOINTS) {

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #41 lore raw

PATCH 41/104 ALSA: bebob/oxfw: fix Kconfig entry for Mackie d.2 Pro

From: Takashi Sakamoto <[email protected]>

commit 0edabdfe89581669609eaac5f6a8d0ae6fe95e7f upstream.

Mackie d.2 has an extension card for IEEE 1394 communication, which uses BridgeCo DM1000 ASIC. On the other hand, Mackie d.4 Pro has built-in function for IEEE 1394 communication by Oxford Semiconductor OXFW971, according to schematic diagram available in Mackie website. Although I misunderstood that Mackie d.2 Pro would be also a model with OXFW971, it's wrong. Mackie d.2 Pro is a model which includes the extension card as factory settings.

This commit fixes entries in Kconfig and comment in ALSA OXFW driver.

Fixes fd6f4b0dc167 ("ALSA: bebob: Add skelton for BeBoB based devices")

Fixes ec4dba5053e1 ("ALSA: oxfw: Add support for Behringer/Mackie devices")

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/firewire/Kconfig       |    4 ++--
 sound/firewire/bebob/bebob.c |    2 +-
 sound/firewire/oxfw/oxfw.c   |    1 -
 3 files changed, 3 insertions(+), 4 deletions(-)

sound/firewire/Kconfig +2 -2

@@ -38,7 +38,7 @@ config SND_OXFW
 	   * Mackie(Loud) Onyx 1640i (former model)
 	   * Mackie(Loud) Onyx Satellite
 	   * Mackie(Loud) Tapco Link.Firewire
-	   * Mackie(Loud) d.2 pro/d.4 pro
+	   * Mackie(Loud) d.4 pro
 	   * Mackie(Loud) U.420/U.420d
 	   * TASCAM FireOne
 	   * Stanton Controllers & Systems 1 Deck/Mixer

@@ -84,7 +84,7 @@ config SND_BEBOB
 	  * PreSonus FIREBOX/FIREPOD/FP10/Inspire1394
 	  * BridgeCo RDAudio1/Audio5
 	  * Mackie Onyx 1220/1620/1640 (FireWire I/O Card)
-	  * Mackie d.2 (FireWire Option)
+	  * Mackie d.2 (FireWire Option) and d.2 Pro
 	  * Stanton FinalScratch 2 (ScratchAmp)
 	  * Tascam IF-FW/DM
 	  * Behringer XENIX UFX 1204/1604

sound/firewire/bebob/bebob.c +1 -1

@@ -387,7 +387,7 @@ static const struct ieee1394_device_id b
 	SND_BEBOB_DEV_ENTRY(VEN_BRIDGECO, 0x00010049, &spec_normal),
 	/* Mackie, Onyx 1220/1620/1640 (Firewire I/O Card) */
 	SND_BEBOB_DEV_ENTRY(VEN_MACKIE2, 0x00010065, &spec_normal),
-	/* Mackie, d.2 (Firewire Option) */
+	// Mackie, d.2 (Firewire option card) and d.2 Pro (the card is built-in).
 	SND_BEBOB_DEV_ENTRY(VEN_MACKIE1, 0x00010067, &spec_normal),
 	/* Stanton, ScratchAmp */
 	SND_BEBOB_DEV_ENTRY(VEN_STANTON, 0x00000001, &spec_normal),

sound/firewire/oxfw/oxfw.c +0 -1

@@ -355,7 +355,6 @@ static const struct ieee1394_device_id o
 	 *  Onyx-i series (former models):	0x081216
 	 *  Mackie Onyx Satellite:		0x00200f
 	 *  Tapco LINK.firewire 4x6:		0x000460
-	 *  d.2 pro:				Unknown
 	 *  d.4 pro:				Unknown
 	 *  U.420:				Unknown
 	 *  U.420d:				Unknown

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #42 lore raw

PATCH 42/104 ALSA: hda: fixup headset for ASUS GU502 laptop

From: Daniel Cordova A <[email protected]>

commit c1b55029493879f5bd585ff79f326e71f0bc05e3 upstream.

The GU502 requires a few steps to make headset i/o works properly:
pincfg, verbs to unmute headphone out and callback to toggle output between speakers and headphone using jack.

Signed-off-by Daniel Cordova A <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/pci/hda/patch_realtek.c |   62 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

sound/pci/hda/patch_realtek.c +62 -0

@@ -6232,6 +6232,35 @@ static void alc294_fixup_gx502_hp(struct
 	}
 }
 
+static void alc294_gu502_toggle_output(struct hda_codec *codec,
+				       struct hda_jack_callback *cb)
+{
+	/* Windows sets 0x10 to 0x8420 for Node 0x20 which is
+	 * responsible from changes between speakers and headphones
+	 */
+	if (snd_hda_jack_detect_state(codec, 0x21) == HDA_JACK_PRESENT)
+		alc_write_coef_idx(codec, 0x10, 0x8420);
+	else
+		alc_write_coef_idx(codec, 0x10, 0x0a20);
+}
+
+static void alc294_fixup_gu502_hp(struct hda_codec *codec,
+				  const struct hda_fixup *fix, int action)
+{
+	if (!is_jack_detectable(codec, 0x21))
+		return;
+
+	switch (action) {
+	case HDA_FIXUP_ACT_PRE_PROBE:
+		snd_hda_jack_detect_enable_callback(codec, 0x21,
+				alc294_gu502_toggle_output);
+		break;
+	case HDA_FIXUP_ACT_INIT:
+		alc294_gu502_toggle_output(codec, NULL);
+		break;
+	}
+}
+
 static void  alc285_fixup_hp_gpio_amp_init(struct hda_codec *codec,
 			      const struct hda_fixup *fix, int action)
 {

@@ -6449,6 +6478,9 @@ enum {
 	ALC294_FIXUP_ASUS_GX502_HP,
 	ALC294_FIXUP_ASUS_GX502_PINS,
 	ALC294_FIXUP_ASUS_GX502_VERBS,
+	ALC294_FIXUP_ASUS_GU502_HP,
+	ALC294_FIXUP_ASUS_GU502_PINS,
+	ALC294_FIXUP_ASUS_GU502_VERBS,
 	ALC285_FIXUP_HP_GPIO_LED,
 	ALC285_FIXUP_HP_MUTE_LED,
 	ALC236_FIXUP_HP_GPIO_LED,

@@ -7687,6 +7719,35 @@ static const struct hda_fixup alc269_fix
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc294_fixup_gx502_hp,
 	},
+	[ALC294_FIXUP_ASUS_GU502_PINS] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x19, 0x01a11050 }, /* rear HP mic */
+			{ 0x1a, 0x01a11830 }, /* rear external mic */
+			{ 0x21, 0x012110f0 }, /* rear HP out */
+			{ }
+		},
+		.chained = true,
+		.chain_id = ALC294_FIXUP_ASUS_GU502_VERBS
+	},
+	[ALC294_FIXUP_ASUS_GU502_VERBS] = {
+		.type = HDA_FIXUP_VERBS,
+		.v.verbs = (const struct hda_verb[]) {
+			/* set 0x15 to HP-OUT ctrl */
+			{ 0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, 0xc0 },
+			/* unmute the 0x15 amp */
+			{ 0x15, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000 },
+			/* set 0x1b to HP-OUT */
+			{ 0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 },
+			{ }
+		},
+		.chained = true,
+		.chain_id = ALC294_FIXUP_ASUS_GU502_HP
+	},
+	[ALC294_FIXUP_ASUS_GU502_HP] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc294_fixup_gu502_hp,
+	},
 	[ALC294_FIXUP_ASUS_COEF_1B] = {
 		.type = HDA_FIXUP_VERBS,
 		.v.verbs = (const struct hda_verb[]) {

@@ -8198,6 +8259,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1043, 0x1ccd, "ASUS X555UB", ALC256_FIXUP_ASUS_MIC),
 	SND_PCI_QUIRK(0x1043, 0x1d4e, "ASUS TM420", ALC256_FIXUP_ASUS_HPE),
 	SND_PCI_QUIRK(0x1043, 0x1e11, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA502),
+	SND_PCI_QUIRK(0x1043, 0x1e51, "ASUS Zephyrus M15", ALC294_FIXUP_ASUS_GU502_PINS),
 	SND_PCI_QUIRK(0x1043, 0x1e8e, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA401),
 	SND_PCI_QUIRK(0x1043, 0x1f11, "ASUS Zephyrus G14", ALC289_FIXUP_ASUS_GA401),
 	SND_PCI_QUIRK(0x1043, 0x3030, "ASUS ZN270IE", ALC256_FIXUP_ASUS_AIO_GPIO2),

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #43 lore raw

PATCH 43/104 Revert "ALSA: sb8: add a check for request_region"

From: Greg Kroah-Hartman <[email protected]>

commit 94f88309f201821073f57ae6005caefa61bf7b7e upstream.

This reverts commit dcd0feac9bab901d5739de51b3f69840851f8919.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

The original commit message for this change was incorrect as the code path can never result in a NULL dereference, alluding to the fact that whatever tool was used to "find this" is broken. It's just an optional resource reservation, so removing this check is fine.

Cc Kangjie Lu <[email protected]>

Acked-by Takashi Iwai <[email protected]>

Fixes dcd0feac9bab ("ALSA: sb8: add a check for request_region")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/isa/sb/sb8.c |    4 ----
 1 file changed, 4 deletions(-)

sound/isa/sb/sb8.c +0 -4

@@ -96,10 +96,6 @@ static int snd_sb8_probe(struct device *
 
 	/* block the 0x388 port to avoid PnP conflicts */
 	acard->fm_res = request_region(0x388, 4, "SoundBlaster FM");
-	if (!acard->fm_res) {
-		err = -EBUSY;
-		goto _err;
-	}
 
 	if (port[dev] != SNDRV_AUTO_PORT) {
 		if ((err = snd_sbdsp_create(card, port[dev], irq[dev],

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #44 lore raw

PATCH 44/104 ALSA: firewire-lib: fix check for the size of isochronous packet payload

From: Takashi Sakamoto <[email protected]>

commit 395f41e2cdac63e7581fb9574e5ac0f02556e34a upstream.

The check for size of isochronous packet payload just cares of the size of IR context payload without the size of CIP header.

Fixes f11453c7cc01 ("ALSA: firewire-lib: use 16 bytes IR context header to separate CIP header")

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/firewire/amdtp-stream.c |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

sound/firewire/amdtp-stream.c +10 -4

@@ -633,18 +633,24 @@ static int parse_ir_ctx_header(struct am
 			       unsigned int *syt, unsigned int packet_index, unsigned int index)
 {
 	const __be32 *cip_header;
+	unsigned int cip_header_size;
 	int err;
 
 	*payload_length = be32_to_cpu(ctx_header[0]) >> ISO_DATA_LENGTH_SHIFT;
-	if (*payload_length > s->ctx_data.tx.ctx_header_size +
-					s->ctx_data.tx.max_ctx_payload_length) {
+
+	if (!(s->flags & CIP_NO_HEADER))
+		cip_header_size = 8;
+	else
+		cip_header_size = 0;
+
+	if (*payload_length > cip_header_size + s->ctx_data.tx.max_ctx_payload_length) {
 		dev_err(&s->unit->device,
 			"Detect jumbo payload: %04x %04x\n",
-			*payload_length, s->ctx_data.tx.max_ctx_payload_length);
+			*payload_length, cip_header_size + s->ctx_data.tx.max_ctx_payload_length);
 		return -EIO;
 	}
 
-	if (!(s->flags & CIP_NO_HEADER)) {
+	if (cip_header_size > 0) {
 		cip_header = ctx_header + 2;
 		err = check_cip_header(s, cip_header, *payload_length,
 				       data_blocks, data_block_counter, syt);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #45 lore raw

PATCH 45/104 ALSA: hda/realtek: reset eapd coeff to default value for alc287

From: Hui Wang <[email protected]>

commit 8822702f6e4c8917c83ba79e0ebf2c8c218910d4 upstream.

Ubuntu users reported an audio bug on the Lenovo Yoga Slim 7 14IIL05, he installed dual OS (Windows + Linux), if he booted to the Linux from Windows, the Speaker can't work well, it has crackling noise, if he poweroff the machine first after Windows, the Speaker worked well.

Before rebooting or shutdown from Windows, the Windows changes the codec eapd coeff value, but the BIOS doesn't re-initialize its value, when booting into the Linux from Windows, the eapd coeff value is not correct. To fix it, set the codec default value to that coeff register in the alsa driver.

BugLink http://bugs.launchpad.net/bugs/1925057

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

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/pci/hda/patch_realtek.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

sound/pci/hda/patch_realtek.c +4 -1

@@ -395,7 +395,6 @@ static void alc_fill_eapd_coef(struct hd
 	case 0x10ec0282:
 	case 0x10ec0283:
 	case 0x10ec0286:
-	case 0x10ec0287:
 	case 0x10ec0288:
 	case 0x10ec0285:
 	case 0x10ec0298:

@@ -406,6 +405,10 @@ static void alc_fill_eapd_coef(struct hd
 	case 0x10ec0275:
 		alc_update_coef_idx(codec, 0xe, 0, 1<<0);
 		break;
+	case 0x10ec0287:
+		alc_update_coef_idx(codec, 0x10, 1<<9, 0);
+		alc_write_coef_idx(codec, 0x8, 0x4ab7);
+		break;
 	case 0x10ec0293:
 		alc_update_coef_idx(codec, 0xa, 1<<13, 0);
 		break;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #46 lore raw

PATCH 46/104 ALSA: hda/realtek: Add some CLOVE SSIDs of ALC293

From: PeiSen Hou <[email protected]>

commit 1d5cfca286178ce81fb0c8a5f5777ef123cd69e4 upstream.

Fix "use as headset mic, without its own jack detect" problen.

Signed-off-by PeiSen Hou <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/pci/hda/patch_realtek.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

sound/pci/hda/patch_realtek.c +15 -0

@@ -8319,12 +8319,19 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1558, 0x50b8, "Clevo NK50SZ", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x50d5, "Clevo NP50D5", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x50f0, "Clevo NH50A[CDF]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0x50f2, "Clevo NH50E[PR]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x50f3, "Clevo NH58DPQ", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0x50f5, "Clevo NH55EPY", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0x50f6, "Clevo NH55DPQ", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x5101, "Clevo S510WU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x5157, "Clevo W517GU1", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x51a1, "Clevo NS50MU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x70a1, "Clevo NB70T[HJK]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x70b3, "Clevo NK70SB", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0x70f2, "Clevo NH79EPY", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0x70f3, "Clevo NH77DPQ", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0x70f4, "Clevo NH77EPY", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0x70f6, "Clevo NH77DPQ-Y", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x8228, "Clevo NR40BU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x8520, "Clevo NH50D[CD]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x8521, "Clevo NH77D[CD]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),

@@ -8342,9 +8349,17 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1558, 0x8a51, "Clevo NH70RCQ-Y", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x8d50, "Clevo NH55RCQ-M", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x951d, "Clevo N950T[CDF]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0x9600, "Clevo N960K[PR]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x961d, "Clevo N960S[CDF]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x971d, "Clevo N970T[CDF]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0xa500, "Clevo NL53RU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0xa600, "Clevo NL5XNU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0xb018, "Clevo NP50D[BE]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0xb019, "Clevo NH77D[BE]Q", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0xb022, "Clevo NH77D[DC][QW]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0xc018, "Clevo NP50D[BE]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0xc019, "Clevo NH77D[BE]Q", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0xc022, "Clevo NH77[DC][QW]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x17aa, 0x1036, "Lenovo P520", ALC233_FIXUP_LENOVO_MULTI_CODECS),
 	SND_PCI_QUIRK(0x17aa, 0x1048, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC),
 	SND_PCI_QUIRK(0x17aa, 0x20f2, "Thinkpad SL410/510", ALC269_FIXUP_SKU_IGNORE),

Greg Kroah-Hartman

author maintainer

2021-05-24 15:53 UTC #47 lore raw

PATCH 47/104 ALSA: hda/realtek: Fix silent headphone output on ASUS UX430UA

From: Takashi Iwai <[email protected]>

commit 8eedd3a70a70f51fa963f3ad7fa97afd0c75bd44 upstream.

It was reported that the headphone output on ASUS UX430UA (SSID 1043:1740) with ALC295 codec is silent while the speaker works. After the investigation, it turned out that the DAC assignment has to be fixed on this machine; unlike others, it expects DAC 0x02 to be assigned to the speaker pin 0x07 while DAC 0x03 to headphone pin 0x21.

This patch provides a fixup for the fixed DAC/pin mapping for this device.

BugLink https://bugzilla.kernel.org/show_bug.cgi?id=212933

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/pci/hda/patch_realtek.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

sound/pci/hda/patch_realtek.c +18 -0

@@ -5720,6 +5720,18 @@ static void alc_fixup_tpt470_dacs(struct
 		spec->gen.preferred_dacs = preferred_pairs;
 }
 
+static void alc295_fixup_asus_dacs(struct hda_codec *codec,
+				   const struct hda_fixup *fix, int action)
+{
+	static const hda_nid_t preferred_pairs[] = {
+		0x17, 0x02, 0x21, 0x03, 0
+	};
+	struct alc_spec *spec = codec->spec;
+
+	if (action == HDA_FIXUP_ACT_PRE_PROBE)
+		spec->gen.preferred_dacs = preferred_pairs;
+}
+
 static void alc_shutup_dell_xps13(struct hda_codec *codec)
 {
 	struct alc_spec *spec = codec->spec;

@@ -6520,6 +6532,7 @@ enum {
 	ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
 	ALC256_FIXUP_ACER_HEADSET_MIC,
 	ALC285_FIXUP_IDEAPAD_S740_COEF,
+	ALC295_FIXUP_ASUS_DACS,
 };
 
 static const struct hda_fixup alc269_fixups[] = {

@@ -8047,6 +8060,10 @@ static const struct hda_fixup alc269_fix
 		.chained = true,
 		.chain_id = ALC269_FIXUP_THINKPAD_ACPI,
 	},
+	[ALC295_FIXUP_ASUS_DACS] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc295_fixup_asus_dacs,
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {

@@ -8245,6 +8262,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK),
 	SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
 	SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
+	SND_PCI_QUIRK(0x1043, 0x1740, "ASUS UX430UA", ALC295_FIXUP_ASUS_DACS),
 	SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL", ALC294_FIXUP_ASUS_DUAL_SPK),
 	SND_PCI_QUIRK(0x1043, 0x1881, "ASUS Zephyrus S/M", ALC294_FIXUP_ASUS_GX502_PINS),
 	SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA", ALC256_FIXUP_ASUS_HEADSET_MIC),

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #48 lore raw

PATCH 48/104 ALSA: hda/realtek: Add fixup for HP OMEN laptop

From: Takashi Iwai <[email protected]>

commit 5d84b5318d860c9d80ca5dfae0e971ede53b4921 upstream.

HP OMEN dc0019-ur with codec SSID 103c:84da requires the pin config overrides and the existing mic/mute LED setup. This patch implements those in the fixup table.

BugLink https://bugzilla.kernel.org/show_bug.cgi?id=212733

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/pci/hda/patch_realtek.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

sound/pci/hda/patch_realtek.c +23 -0

@@ -6533,6 +6533,7 @@ enum {
 	ALC256_FIXUP_ACER_HEADSET_MIC,
 	ALC285_FIXUP_IDEAPAD_S740_COEF,
 	ALC295_FIXUP_ASUS_DACS,
+	ALC295_FIXUP_HP_OMEN,
 };
 
 static const struct hda_fixup alc269_fixups[] = {

@@ -8064,6 +8065,26 @@ static const struct hda_fixup alc269_fix
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc295_fixup_asus_dacs,
 	},
+	[ALC295_FIXUP_HP_OMEN] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x12, 0xb7a60130 },
+			{ 0x13, 0x40000000 },
+			{ 0x14, 0x411111f0 },
+			{ 0x16, 0x411111f0 },
+			{ 0x17, 0x90170110 },
+			{ 0x18, 0x411111f0 },
+			{ 0x19, 0x02a11030 },
+			{ 0x1a, 0x411111f0 },
+			{ 0x1b, 0x04a19030 },
+			{ 0x1d, 0x40600001 },
+			{ 0x1e, 0x411111f0 },
+			{ 0x21, 0x03211020 },
+			{}
+		},
+		.chained = true,
+		.chain_id = ALC269_FIXUP_HP_LINE1_MIC1_LED,
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {

@@ -8222,6 +8243,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x103c, 0x82c0, "HP G3 mini premium", ALC221_FIXUP_HP_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x103c, 0x83b9, "HP Spectre x360", ALC269_FIXUP_HP_MUTE_LED_MIC3),
 	SND_PCI_QUIRK(0x103c, 0x8497, "HP Envy x360", ALC269_FIXUP_HP_MUTE_LED_MIC3),
+	SND_PCI_QUIRK(0x103c, 0x84da, "HP OMEN dc0019-ur", ALC295_FIXUP_HP_OMEN),
 	SND_PCI_QUIRK(0x103c, 0x84e7, "HP Pavilion 15", ALC269_FIXUP_HP_MUTE_LED_MIC3),
 	SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x86c7, "HP Envy AiO 32", ALC274_FIXUP_HP_ENVY_GPIO),

@@ -8642,6 +8664,7 @@ static const struct hda_model_fixup alc2
 	{.id = ALC255_FIXUP_XIAOMI_HEADSET_MIC, .name = "alc255-xiaomi-headset"},
 	{.id = ALC274_FIXUP_HP_MIC, .name = "alc274-hp-mic-detect"},
 	{.id = ALC245_FIXUP_HP_X360_AMP, .name = "alc245-hp-x360-amp"},
+	{.id = ALC295_FIXUP_HP_OMEN, .name = "alc295-hp-omen"},
 	{}
 };
 #define ALC225_STANDARD_PINS \

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #49 lore raw

PATCH 49/104 ALSA: hda/realtek: Add fixup for HP Spectre x360 15-df0xxx

From: Elia Devito <[email protected]>

commit f2be77fee648ddd6d0d259d3527344ba0120e314 upstream.

Fixup to enable all 4 speaker on HP Spectre x360 15-df0xxx and probably on similar models.

0x14 pin config override is required to enable all speakers and alc285-speaker2-to-dac1 fixup to enable volume adjustment.

BugLink https://bugzilla.kernel.org/show_bug.cgi?id=189331

Signed-off-by Elia Devito <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 sound/pci/hda/patch_realtek.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

sound/pci/hda/patch_realtek.c +12 -0

@@ -6534,6 +6534,7 @@ enum {
 	ALC285_FIXUP_IDEAPAD_S740_COEF,
 	ALC295_FIXUP_ASUS_DACS,
 	ALC295_FIXUP_HP_OMEN,
+	ALC285_FIXUP_HP_SPECTRE_X360,
 };
 
 static const struct hda_fixup alc269_fixups[] = {

@@ -8085,6 +8086,15 @@ static const struct hda_fixup alc269_fix
 		.chained = true,
 		.chain_id = ALC269_FIXUP_HP_LINE1_MIC1_LED,
 	},
+	[ALC285_FIXUP_HP_SPECTRE_X360] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x14, 0x90170110 }, /* enable top speaker */
+			{}
+		},
+		.chained = true,
+		.chain_id = ALC285_FIXUP_SPEAKER2_TO_DAC1,
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {

@@ -8245,6 +8255,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x103c, 0x8497, "HP Envy x360", ALC269_FIXUP_HP_MUTE_LED_MIC3),
 	SND_PCI_QUIRK(0x103c, 0x84da, "HP OMEN dc0019-ur", ALC295_FIXUP_HP_OMEN),
 	SND_PCI_QUIRK(0x103c, 0x84e7, "HP Pavilion 15", ALC269_FIXUP_HP_MUTE_LED_MIC3),
+	SND_PCI_QUIRK(0x103c, 0x8519, "HP Spectre x360 15-df0xxx", ALC285_FIXUP_HP_SPECTRE_X360),
 	SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x86c7, "HP Envy AiO 32", ALC274_FIXUP_HP_ENVY_GPIO),
 	SND_PCI_QUIRK(0x103c, 0x8724, "HP EliteBook 850 G7", ALC285_FIXUP_HP_GPIO_LED),

@@ -8665,6 +8676,7 @@ static const struct hda_model_fixup alc2
 	{.id = ALC274_FIXUP_HP_MIC, .name = "alc274-hp-mic-detect"},
 	{.id = ALC245_FIXUP_HP_X360_AMP, .name = "alc245-hp-x360-amp"},
 	{.id = ALC295_FIXUP_HP_OMEN, .name = "alc295-hp-omen"},
+	{.id = ALC285_FIXUP_HP_SPECTRE_X360, .name = "alc285-hp-spectre-x360"},
 	{}
 };
 #define ALC225_STANDARD_PINS \

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #50 lore raw

PATCH 50/104 uio_hv_generic: Fix a memory leak in error handling paths

Link https://lore.kernel.org/r/4fdaff557deef6f0475d02ba7922ddbaa1ab08a6.1620544055.git.christophe.jaillet@wanadoo.fr open here

From: Christophe JAILLET <[email protected]>

commit 3ee098f96b8b6c1a98f7f97915f8873164e6af9d upstream.

If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be updated and 'hv_uio_cleanup()' in the error handling path will not be able to free the corresponding buffer.

In such a case, we need to free the buffer explicitly.

Fixes cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use")

Cc stable <[email protected]>

Signed-off-by Christophe JAILLET <[email protected]>

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

---
 drivers/uio/uio_hv_generic.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/uio/uio_hv_generic.c +6 -2

@@ -296,8 +296,10 @@ hv_uio_probe(struct hv_device *dev,
 
 	ret = vmbus_establish_gpadl(channel, pdata->recv_buf,
 				    RECV_BUFFER_SIZE, &pdata->recv_gpadl);
-	if (ret)
+	if (ret) {
+		vfree(pdata->recv_buf);
 		goto fail_close;
+	}
 
 	/* put Global Physical Address Label in name */
 	snprintf(pdata->recv_name, sizeof(pdata->recv_name),

@@ -316,8 +318,10 @@ hv_uio_probe(struct hv_device *dev,
 
 	ret = vmbus_establish_gpadl(channel, pdata->send_buf,
 				    SEND_BUFFER_SIZE, &pdata->send_gpadl);
-	if (ret)
+	if (ret) {
+		vfree(pdata->send_buf);
 		goto fail_close;
+	}
 
 	snprintf(pdata->send_name, sizeof(pdata->send_name),
 		 "send:%u", pdata->send_gpadl);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #51 lore raw

PATCH 51/104 Revert "rapidio: fix a NULL pointer dereference when create_workqueue() fails"

From: Greg Kroah-Hartman <[email protected]>

commit 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb upstream.

This reverts commit 23015b22e47c5409620b1726a677d69e5cd032ba.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

The original commit has a memory leak on the error path here, it does not clean up everything properly.

Cc Kangjie Lu <[email protected]>

Cc Alexandre Bounine <[email protected]>

Cc Matt Porter <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Linus Torvalds <[email protected]>

Fixes 23015b22e47c ("rapidio: fix a NULL pointer dereference when create_workqueue() fails")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/rapidio/rio_cm.c |    8 --------
 1 file changed, 8 deletions(-)

drivers/rapidio/rio_cm.c +0 -8

@@ -2138,14 +2138,6 @@ static int riocm_add_mport(struct device
 	mutex_init(&cm->rx_lock);
 	riocm_rx_fill(cm, RIOCM_RX_RING_SIZE);
 	cm->rx_wq = create_workqueue(DRV_NAME "/rxq");
-	if (!cm->rx_wq) {
-		riocm_error("failed to allocate IBMBOX_%d on %s",
-			    cmbox, mport->name);
-		rio_release_outb_mbox(mport, cmbox);
-		kfree(cm);
-		return -ENOMEM;
-	}
-
 	INIT_WORK(&cm->rx_work, rio_ibmsg_handler);
 
 	cm->tx_slot = 0;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #52 lore raw

PATCH 52/104 rapidio: handle create_workqueue() failure

From: Anirudh Rayabharam <[email protected]>

commit 69ce3ae36dcb03cdf416b0862a45369ddbf50fdf upstream.

In case create_workqueue() fails, release all resources and return -ENOMEM to caller to avoid potential NULL pointer deref later. Move up the create_workequeue() call to return early and avoid unwinding the call to riocm_rx_fill().

Cc Alexandre Bounine <[email protected]>

Cc Matt Porter <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc stable <[email protected]>

Signed-off-by Anirudh Rayabharam <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/rapidio/rio_cm.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

drivers/rapidio/rio_cm.c +8 -1

@@ -2127,6 +2127,14 @@ static int riocm_add_mport(struct device
 		return -ENODEV;
 	}
 
+	cm->rx_wq = create_workqueue(DRV_NAME "/rxq");
+	if (!cm->rx_wq) {
+		rio_release_inb_mbox(mport, cmbox);
+		rio_release_outb_mbox(mport, cmbox);
+		kfree(cm);
+		return -ENOMEM;
+	}
+
 	/*
 	 * Allocate and register inbound messaging buffers to be ready
 	 * to receive channel and system management requests

@@ -2137,7 +2145,6 @@ static int riocm_add_mport(struct device
 	cm->rx_slots = RIOCM_RX_RING_SIZE;
 	mutex_init(&cm->rx_lock);
 	riocm_rx_fill(cm, RIOCM_RX_RING_SIZE);
-	cm->rx_wq = create_workqueue(DRV_NAME "/rxq");
 	INIT_WORK(&cm->rx_work, rio_ibmsg_handler);
 
 	cm->tx_slot = 0;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #53 lore raw

PATCH 53/104 Revert "serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference"

From: Greg Kroah-Hartman <[email protected]>

commit 754f39158441f4c0d7a8255209dd9a939f08ce80 upstream.

This reverts commit 32f47179833b63de72427131169809065db6745e.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be not be needed at all as the change was useless because this function can only be called when of_match_device matched on something. So it should be reverted.

Cc Aditya Pakki <[email protected]>

Cc stable <[email protected]>

Fixes 32f47179833b ("serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference")

Acked-by Jiri Slaby <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/tty/serial/mvebu-uart.c |    3 ---
 1 file changed, 3 deletions(-)

drivers/tty/serial/mvebu-uart.c +0 -3

@@ -818,9 +818,6 @@ static int mvebu_uart_probe(struct platf
 		return -EINVAL;
 	}
 
-	if (!match)
-		return -ENODEV;
-
 	/* Assume that all UART ports have a DT alias or none has */
 	id = of_alias_get_id(pdev->dev.of_node, "serial");
 	if (!pdev->dev.of_node || id < 0)

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #54 lore raw

PATCH 54/104 nvme-tcp: fix possible use-after-completion

From: Sagi Grimberg <[email protected]>

commit 825619b09ad351894d2c6fb6705f5b3711d145c7 upstream.

Commit db5ad6b7f8cd ("nvme-tcp: try to send request in queue_rq context") added a second context that may perform a network send. This means that now RX and TX are not serialized in nvme_tcp_io_work and can run concurrently.

While there is correct mutual exclusion in the TX path (where the send_mutex protect the queue socket send activity) RX activity, and more specifically request completion may run concurrently.

This means we must guarantee that any mutation of the request state related to its lifetime, bytes sent must not be accessed when a completion may have possibly arrived back (and processed).

The race may trigger when a request completion arrives, processed _and_ reused as a fresh new request, exactly in the (relatively short) window between the last data payload sent and before the request iov_iter is advanced.

Consider the following race:
1. 16K write request is queued
2. The nvme command and the data is sent to the controller (in-capsule or solicited by r2t)
3. After the last payload is sent but before the req.iter is advanced, the controller sends back a completion.
4. The completion is processed, the request is completed, and reused to transfer a new request (write or read)
5. The new request is queued, and the driver reset the request parameters (nvme_tcp_setup_cmd_pdu).
6. Now context in (2) resumes execution and advances the req.iter

==> use-after-completion as this is already a new request.

Fix this by making sure the request is not advanced after the last data payload send, knowing that a completion may have arrived already.

An alternative solution would have been to delay the request completion or state change waiting for reference counting on the TX path, but besides adding atomic operations to the hot-path, it may present challenges in multi-stage R2T scenarios where a r2t handler needs to be deferred to an async execution.

Reported-by Narayan Ayalasomayajula <[email protected]>

Tested-by Anil Mishra <[email protected]>

Reviewed-by Keith Busch <[email protected]>

Cc [email protected] # v5.8+

Signed-off-by Sagi Grimberg <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

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

---
 drivers/nvme/host/tcp.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/nvme/host/tcp.c +1 -1

@@ -940,7 +940,6 @@ static int nvme_tcp_try_send_data(struct
 		if (ret <= 0)
 			return ret;
 
-		nvme_tcp_advance_req(req, ret);
 		if (queue->data_digest)
 			nvme_tcp_ddgst_update(queue->snd_hash, page,
 					offset, ret);

@@ -957,6 +956,7 @@ static int nvme_tcp_try_send_data(struct
 			}
 			return 1;
 		}
+		nvme_tcp_advance_req(req, ret);
 	}
 	return -EAGAIN;
 }

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #55 lore raw

PATCH 55/104 x86/sev-es: Move sev_es_put_ghcb() in prep for follow on patch

From: Tom Lendacky <[email protected]>

commit fea63d54f7a3e74f8ab489a8b82413a29849a594 upstream.

Move the location of sev_es_put_ghcb() in preparation for an update to it in a follow-on patch. This will better highlight the changes being made to the function.

No functional change.

Fixes 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler")

Signed-off-by Tom Lendacky <[email protected]>

Link https://lkml.kernel.org/r/8c07662ec17d3d82e5c53841a1d9e766d3bdbab6.1621273353.git.thomas.lendacky@amd.com open here

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

---
 arch/x86/kernel/sev-es.c |   36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

arch/x86/kernel/sev-es.c +18 ~~-18~~

@@ -209,24 +209,6 @@ static __always_inline struct ghcb *sev_
 	return ghcb;
 }
 
-static __always_inline void sev_es_put_ghcb(struct ghcb_state *state)
-{
-	struct sev_es_runtime_data *data;
-	struct ghcb *ghcb;
-
-	data = this_cpu_read(runtime_data);
-	ghcb = &data->ghcb_page;
-
-	if (state->ghcb) {
-		/* Restore GHCB from Backup */
-		*ghcb = *state->ghcb;
-		data->backup_ghcb_active = false;
-		state->ghcb = NULL;
-	} else {
-		data->ghcb_active = false;
-	}
-}
-
 /* Needed in vc_early_forward_exception */
 void do_early_exception(struct pt_regs *regs, int trapnr);

@@ -434,6 +416,24 @@ static enum es_result vc_slow_virt_to_ph
 /* Include code shared with pre-decompression boot stage */
 #include "sev-es-shared.c"
 
+static __always_inline void sev_es_put_ghcb(struct ghcb_state *state)
+{
+	struct sev_es_runtime_data *data;
+	struct ghcb *ghcb;
+
+	data = this_cpu_read(runtime_data);
+	ghcb = &data->ghcb_page;
+
+	if (state->ghcb) {
+		/* Restore GHCB from Backup */
+		*ghcb = *state->ghcb;
+		data->backup_ghcb_active = false;
+		state->ghcb = NULL;
+	} else {
+		data->ghcb_active = false;
+	}
+}
+
 void noinstr __sev_es_nmi_complete(void)
 {
 	struct ghcb_state state;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #56 lore raw

PATCH 56/104 x86/sev-es: Invalidate the GHCB after completing VMGEXIT

From: Tom Lendacky <[email protected]>

commit a50c5bebc99c525e7fbc059988c6a5ab8680cb76 upstream.

Since the VMGEXIT instruction can be issued from userspace, invalidate the GHCB after performing VMGEXIT processing in the kernel.

Invalidation is only required after userspace is available, so call vc_ghcb_invalidate() from sev_es_put_ghcb(). Update vc_ghcb_invalidate() to additionally clear the GHCB exit code so that it is always presented as 0 when VMGEXIT has been issued by anything else besides the kernel.

Fixes 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler")

Signed-off-by Tom Lendacky <[email protected]>

Link https://lkml.kernel.org/r/5a8130462e4f0057ee1184509cd056eedd78742b.1621273353.git.thomas.lendacky@amd.com open here

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

---
 arch/x86/kernel/sev-es-shared.c |    1 +
 arch/x86/kernel/sev-es.c        |    5 +++++
 2 files changed, 6 insertions(+)

arch/x86/kernel/sev-es-shared.c +1 -0

@@ -63,6 +63,7 @@ static bool sev_es_negotiate_protocol(vo
 
 static __always_inline void vc_ghcb_invalidate(struct ghcb *ghcb)
 {
+	ghcb->save.sw_exit_code = 0;
 	memset(ghcb->save.valid_bitmap, 0, sizeof(ghcb->save.valid_bitmap));
 }

arch/x86/kernel/sev-es.c +5 -0

@@ -430,6 +430,11 @@ static __always_inline void sev_es_put_g
 		data->backup_ghcb_active = false;
 		state->ghcb = NULL;
 	} else {
+		/*
+		 * Invalidate the GHCB so a VMGEXIT instruction issued
+		 * from userspace won't appear to be valid.
+		 */
+		vc_ghcb_invalidate(ghcb);
 		data->ghcb_active = false;
 	}
 }

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #57 lore raw

PATCH 57/104 x86/sev-es: Dont return NULL from sev_es_get_ghcb()

From: Joerg Roedel <[email protected]>

commit b250f2f7792d15bcde98e0456781e2835556d5fa upstream.

sev_es_get_ghcb() is called from several places but only one of them checks the return value. The reaction to returning NULL is always the
same: calling panic() and kill the machine.

Instead of adding checks to all call sites, move the panic() into the function itself so that it will no longer return NULL.

Fixes 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler")

Cc [email protected] # v5.10+

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

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

---
 arch/x86/kernel/sev-es.c |   25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

arch/x86/kernel/sev-es.c +12 ~~-13~~

@@ -191,8 +191,18 @@ static __always_inline struct ghcb *sev_
 	if (unlikely(data->ghcb_active)) {
 		/* GHCB is already in use - save its contents */
 
-		if (unlikely(data->backup_ghcb_active))
-			return NULL;
+		if (unlikely(data->backup_ghcb_active)) {
+			/*
+			 * Backup-GHCB is also already in use. There is no way
+			 * to continue here so just kill the machine. To make
+			 * panic() work, mark GHCBs inactive so that messages
+			 * can be printed out.
+			 */
+			data->ghcb_active        = false;
+			data->backup_ghcb_active = false;
+
+			panic("Unable to handle #VC exception! GHCB and Backup GHCB are already in use");
+		}
 
 		/* Mark backup_ghcb active before writing to it */
 		data->backup_ghcb_active = true;

@@ -1262,7 +1272,6 @@ static __always_inline bool on_vc_fallba
  */
 DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication)
 {
-	struct sev_es_runtime_data *data = this_cpu_read(runtime_data);
 	irqentry_state_t irq_state;
 	struct ghcb_state state;
 	struct es_em_ctxt ctxt;

@@ -1288,16 +1297,6 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_co
 	 */
 
 	ghcb = sev_es_get_ghcb(&state);
-	if (!ghcb) {
-		/*
-		 * Mark GHCBs inactive so that panic() is able to print the
-		 * message.
-		 */
-		data->ghcb_active        = false;
-		data->backup_ghcb_active = false;
-
-		panic("Unable to handle #VC exception! GHCB and Backup GHCB are already in use");
-	}
 
 	vc_ghcb_invalidate(ghcb);
 	result = vc_init_em_ctxt(&ctxt, regs, error_code);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #58 lore raw

PATCH 58/104 x86/sev-es: Use __put_user()/__get_user() for data accesses

From: Joerg Roedel <[email protected]>

commit 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 upstream.

The put_user() and get_user() functions do checks on the address which is passed to them. They check whether the address is actually a user-space address and whether its fine to access it. They also call might_fault() to indicate that they could fault and possibly sleep.

All of these checks are neither wanted nor needed in the #VC exception handler, which can be invoked from almost any context and also for MMIO instructions from kernel space on kernel memory. All the #VC handler wants to know is whether a fault happened when the access was tried.

This is provided by __put_user()/__get_user(), which just do the access no matter what. Also add comments explaining why __get_user() and __put_user() are the best choice here and why it is safe to use them in this context. Also explain why copy_to/from_user can't be used.

In addition, also revert commit

7024f60d6552 ("x86/sev-es: Handle string port IO to kernel memory properly")

because using __get_user()/__put_user() fixes the same problem while the above commit introduced several problems:

1) It uses access_ok() which is only allowed in task context.

2) It uses memcpy() which has no fault handling at all and is thus unsafe to use here.

[ bp: Fix up commit ID of the reverted commit above. ]

Fixes f980f9c31a92 ("x86/sev-es: Compile early handler code into kernel image")

Cc [email protected] # v5.10+

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

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

---
 arch/x86/kernel/sev-es.c |   66 ++++++++++++++++++++++++++++++++---------------
 1 file changed, 46 insertions(+), 20 deletions(-)

arch/x86/kernel/sev-es.c +46 ~~-20~~

@@ -288,31 +288,44 @@ static enum es_result vc_write_mem(struc
 	u16 d2;
 	u8  d1;
 
-	/* If instruction ran in kernel mode and the I/O buffer is in kernel space */
-	if (!user_mode(ctxt->regs) && !access_ok(target, size)) {
-		memcpy(dst, buf, size);
-		return ES_OK;
-	}
-
+	/*
+	 * This function uses __put_user() independent of whether kernel or user
+	 * memory is accessed. This works fine because __put_user() does no
+	 * sanity checks of the pointer being accessed. All that it does is
+	 * to report when the access failed.
+	 *
+	 * Also, this function runs in atomic context, so __put_user() is not
+	 * allowed to sleep. The page-fault handler detects that it is running
+	 * in atomic context and will not try to take mmap_sem and handle the
+	 * fault, so additional pagefault_enable()/disable() calls are not
+	 * needed.
+	 *
+	 * The access can't be done via copy_to_user() here because
+	 * vc_write_mem() must not use string instructions to access unsafe
+	 * memory. The reason is that MOVS is emulated by the #VC handler by
+	 * splitting the move up into a read and a write and taking a nested #VC
+	 * exception on whatever of them is the MMIO access. Using string
+	 * instructions here would cause infinite nesting.
+	 */
 	switch (size) {
 	case 1:
 		memcpy(&d1, buf, 1);
-		if (put_user(d1, target))
+		if (__put_user(d1, target))
 			goto fault;
 		break;
 	case 2:
 		memcpy(&d2, buf, 2);
-		if (put_user(d2, target))
+		if (__put_user(d2, target))
 			goto fault;
 		break;
 	case 4:
 		memcpy(&d4, buf, 4);
-		if (put_user(d4, target))
+		if (__put_user(d4, target))
 			goto fault;
 		break;
 	case 8:
 		memcpy(&d8, buf, 8);
-		if (put_user(d8, target))
+		if (__put_user(d8, target))
 			goto fault;
 		break;
 	default:

@@ -343,30 +356,43 @@ static enum es_result vc_read_mem(struct
 	u16 d2;
 	u8  d1;
 
-	/* If instruction ran in kernel mode and the I/O buffer is in kernel space */
-	if (!user_mode(ctxt->regs) && !access_ok(s, size)) {
-		memcpy(buf, src, size);
-		return ES_OK;
-	}
-
+	/*
+	 * This function uses __get_user() independent of whether kernel or user
+	 * memory is accessed. This works fine because __get_user() does no
+	 * sanity checks of the pointer being accessed. All that it does is
+	 * to report when the access failed.
+	 *
+	 * Also, this function runs in atomic context, so __get_user() is not
+	 * allowed to sleep. The page-fault handler detects that it is running
+	 * in atomic context and will not try to take mmap_sem and handle the
+	 * fault, so additional pagefault_enable()/disable() calls are not
+	 * needed.
+	 *
+	 * The access can't be done via copy_from_user() here because
+	 * vc_read_mem() must not use string instructions to access unsafe
+	 * memory. The reason is that MOVS is emulated by the #VC handler by
+	 * splitting the move up into a read and a write and taking a nested #VC
+	 * exception on whatever of them is the MMIO access. Using string
+	 * instructions here would cause infinite nesting.
+	 */
 	switch (size) {
 	case 1:
-		if (get_user(d1, s))
+		if (__get_user(d1, s))
 			goto fault;
 		memcpy(buf, &d1, 1);
 		break;
 	case 2:
-		if (get_user(d2, s))
+		if (__get_user(d2, s))
 			goto fault;
 		memcpy(buf, &d2, 2);
 		break;
 	case 4:
-		if (get_user(d4, s))
+		if (__get_user(d4, s))
 			goto fault;
 		memcpy(buf, &d4, 4);
 		break;
 	case 8:
-		if (get_user(d8, s))
+		if (__get_user(d8, s))
 			goto fault;
 		memcpy(buf, &d8, 8);
 		break;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #59 lore raw

PATCH 59/104 x86/sev-es: Forward page-faults which happen during emulation

From: Joerg Roedel <[email protected]>

commit c25bbdb564060adaad5c3a8a10765c13487ba6a3 upstream.

When emulating guest instructions for MMIO or IOIO accesses, the #VC handler might get a page-fault and will not be able to complete. Forward the page-fault in this case to the correct handler instead of killing the machine.

Fixes 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler")

Cc [email protected] # v5.10+

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

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

---
 arch/x86/kernel/sev-es.c |    4 ++++
 1 file changed, 4 insertions(+)

arch/x86/kernel/sev-es.c +4 -0

@@ -1269,6 +1269,10 @@ static __always_inline void vc_forward_e
 	case X86_TRAP_UD:
 		exc_invalid_op(ctxt->regs);
 		break;
+	case X86_TRAP_PF:
+		write_cr2(ctxt->fi.cr2);
+		exc_page_fault(ctxt->regs, error_code);
+		break;
 	case X86_TRAP_AC:
 		exc_alignment_check(ctxt->regs, error_code);
 		break;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #60 lore raw

PATCH 60/104 drm/amdgpu: Fix GPU TLB update error when PAGE_SIZE > AMDGPU_PAGE_SIZE

From: Yi Li <[email protected]>

commit d53751568359e5b3ffb859b13cbd79dc77a571f1 upstream.

When PAGE_SIZE is larger than AMDGPU_PAGE_SIZE, the number of GPU TLB entries which need to update in amdgpu_map_buffer() should be multiplied by AMDGPU_GPU_PAGES_IN_CPU_PAGE (PAGE_SIZE / AMDGPU_PAGE_SIZE).

Reviewed-by Christian König <[email protected]>

Signed-off-by Yi Li <[email protected]>

Signed-off-by Huacai Chen <[email protected]>

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

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +1 -1

@@ -267,7 +267,7 @@ static int amdgpu_ttm_map_buffer(struct
 	*addr += offset & ~PAGE_MASK;
 
 	num_dw = ALIGN(adev->mman.buffer_funcs->copy_num_dw, 8);
-	num_bytes = num_pages * 8;
+	num_bytes = num_pages * 8 * AMDGPU_GPU_PAGES_IN_CPU_PAGE;
 
 	r = amdgpu_job_alloc_with_ib(adev, num_dw * 4 + num_bytes,
 				     AMDGPU_IB_POOL_DELAYED, &job);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #61 lore raw

PATCH 61/104 drm/amdgpu: disable 3DCGCG on picasso/raven1 to avoid compute hang

From: Changfeng <[email protected]>

commit dbd1003d1252db5973dddf20b24bb0106ac52aa2 upstream.

There is problem with 3DCGCG firmware and it will cause compute test hang on picasso/raven1. It needs to disable 3DCGCG in driver to avoid compute hang.

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

Reviewed-by Alex Deucher <[email protected]>

Reviewed-by Huang Rui <[email protected]>

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

---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c |   10 +++++++---
 drivers/gpu/drm/amd/amdgpu/soc15.c    |    2 --
 2 files changed, 7 insertions(+), 5 deletions(-)

drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +7 -3

@@ -4859,7 +4859,7 @@ static void gfx_v9_0_update_3d_clock_gat
 	amdgpu_gfx_rlc_enter_safe_mode(adev);
 
 	/* Enable 3D CGCG/CGLS */
-	if (enable && (adev->cg_flags & AMD_CG_SUPPORT_GFX_3D_CGCG)) {
+	if (enable) {
 		/* write cmd to clear cgcg/cgls ov */
 		def = data = RREG32_SOC15(GC, 0, mmRLC_CGTT_MGCG_OVERRIDE);
 		/* unset CGCG override */

@@ -4871,8 +4871,12 @@ static void gfx_v9_0_update_3d_clock_gat
 		/* enable 3Dcgcg FSM(0x0000363f) */
 		def = RREG32_SOC15(GC, 0, mmRLC_CGCG_CGLS_CTRL_3D);
 
-		data = (0x36 << RLC_CGCG_CGLS_CTRL_3D__CGCG_GFX_IDLE_THRESHOLD__SHIFT) |
-			RLC_CGCG_CGLS_CTRL_3D__CGCG_EN_MASK;
+		if (adev->cg_flags & AMD_CG_SUPPORT_GFX_3D_CGCG)
+			data = (0x36 << RLC_CGCG_CGLS_CTRL_3D__CGCG_GFX_IDLE_THRESHOLD__SHIFT) |
+				RLC_CGCG_CGLS_CTRL_3D__CGCG_EN_MASK;
+		else
+			data = 0x0 << RLC_CGCG_CGLS_CTRL_3D__CGCG_GFX_IDLE_THRESHOLD__SHIFT;
+
 		if (adev->cg_flags & AMD_CG_SUPPORT_GFX_3D_CGLS)
 			data |= (0x000F << RLC_CGCG_CGLS_CTRL_3D__CGLS_REP_COMPANSAT_DELAY__SHIFT) |
 				RLC_CGCG_CGLS_CTRL_3D__CGLS_EN_MASK;

drivers/gpu/drm/amd/amdgpu/soc15.c +0 -2

@@ -1183,7 +1183,6 @@ static int soc15_common_early_init(void
 			adev->cg_flags = AMD_CG_SUPPORT_GFX_MGCG |
 				AMD_CG_SUPPORT_GFX_MGLS |
 				AMD_CG_SUPPORT_GFX_CP_LS |
-				AMD_CG_SUPPORT_GFX_3D_CGCG |
 				AMD_CG_SUPPORT_GFX_3D_CGLS |
 				AMD_CG_SUPPORT_GFX_CGCG |
 				AMD_CG_SUPPORT_GFX_CGLS |

@@ -1203,7 +1202,6 @@ static int soc15_common_early_init(void
 				AMD_CG_SUPPORT_GFX_MGLS |
 				AMD_CG_SUPPORT_GFX_RLC_LS |
 				AMD_CG_SUPPORT_GFX_CP_LS |
-				AMD_CG_SUPPORT_GFX_3D_CGCG |
 				AMD_CG_SUPPORT_GFX_3D_CGLS |
 				AMD_CG_SUPPORT_GFX_CGCG |
 				AMD_CG_SUPPORT_GFX_CGLS |

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #62 lore raw

PATCH 62/104 drm/amdgpu: update gc golden setting for Navi12

From: Guchun Chen <[email protected]>

commit 99c45ba5799d6b938bd9bd20edfeb6f3e3e039b9 upstream.

Current golden setting is out of date.

Signed-off-by Guchun Chen <[email protected]>

Reviewed-by Kenneth Feng <[email protected]>

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

---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +4 -2

@@ -1334,9 +1334,10 @@ static const struct soc15_reg_golden gol
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG, 0xffffffff, 0x20000000),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG2, 0xffffffff, 0x00000420),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG3, 0xffffffff, 0x00000200),
-	SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG4, 0xffffffff, 0x04800000),
+	SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG4, 0xffffffff, 0x04900000),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DFSM_TILES_IN_FLIGHT, 0x0000ffff, 0x0000003f),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_LAST_OF_BURST_CONFIG, 0xffffffff, 0x03860204),
+	SOC15_REG_GOLDEN_VALUE(GC, 0, mmGB_ADDR_CONFIG, 0x0c1800ff, 0x00000044),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmGCR_GENERAL_CNTL, 0x1ff0ffff, 0x00000500),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmGE_PRIV_CONTROL, 0x00007fff, 0x000001fe),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmGL1_PIPE_STEER, 0xffffffff, 0xe4e4e4e4),

@@ -1354,12 +1355,13 @@ static const struct soc15_reg_golden gol
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmPA_SC_ENHANCE_2, 0x00000820, 0x00000820),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmPA_SC_LINE_STIPPLE_STATE, 0x0000ff0f, 0x00000000),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmRMI_SPARE, 0xffffffff, 0xffff3101),
+	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSPI_CONFIG_CNTL_1, 0x001f0000, 0x00070104),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSQ_ALU_CLK_CTRL, 0xffffffff, 0xffffffff),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSQ_ARB_CONFIG, 0x00000133, 0x00000130),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSQ_LDS_CLK_CTRL, 0xffffffff, 0xffffffff),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmTA_CNTL_AUX, 0xfff7ffff, 0x01030000),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmTCP_CNTL, 0xffdf80ff, 0x479c0010),
-	SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0xffffffff, 0x00800000)
+	SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0xffffffff, 0x00c00000)
 };
 
 static void gfx_v10_rlcg_wreg(struct amdgpu_device *adev, u32 offset, u32 v)

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #63 lore raw

PATCH 63/104 drm/amdgpu: update sdma golden setting for Navi12

From: Guchun Chen <[email protected]>

commit 77194d8642dd4cb7ea8ced77bfaea55610574c38 upstream.

Current golden setting is out of date.

Signed-off-by Guchun Chen <[email protected]>

Reviewed-by Kenneth Feng <[email protected]>

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

---
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c +4 -0

@@ -124,6 +124,10 @@ static const struct soc15_reg_golden gol
 
 static const struct soc15_reg_golden golden_settings_sdma_nv12[] = {
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA0_RLC3_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000),
+	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA0_GB_ADDR_CONFIG, 0x001877ff, 0x00000044),
+	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA0_GB_ADDR_CONFIG_READ, 0x001877ff, 0x00000044),
+	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA1_GB_ADDR_CONFIG, 0x001877ff, 0x00000044),
+	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA1_GB_ADDR_CONFIG_READ, 0x001877ff, 0x00000044),
 	SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA1_RLC3_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000),
 };

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #64 lore raw

PATCH 64/104 powerpc/64s/syscall: Use pt_regs.trap to distinguish syscall ABI difference between sc and scv syscalls

From: Nicholas Piggin <[email protected]>

commit 5665bc35c1ed917ac8fd06cb651317bb47a65b10 upstream.

The sc and scv 0 system calls have different ABI conventions, and ptracers need to know which system call type is being used if they want to look at the syscall registers.

Document that pt_regs.trap can be used for this, and fix one in-tree user to work with scv 0 syscalls.

Fixes 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")

Cc [email protected] # v5.9+

Reported-by "Dmitry V. Levin" <[email protected]>

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

Link https://lore.kernel.org/r/[email protected] open here

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

---
 Documentation/powerpc/syscall64-abi.rst       |   10 +++++++++
 tools/testing/selftests/seccomp/seccomp_bpf.c |   27 +++++++++++++++++---------
 2 files changed, 28 insertions(+), 9 deletions(-)

Documentation/powerpc/syscall64-abi.rst +10 -0

@@ -96,6 +96,16 @@ auxiliary vector.
 
 scv 0 syscalls will always behave as PPC_FEATURE2_HTM_NOSC.
 
+ptrace
+------
+When ptracing system calls (PTRACE_SYSCALL), the pt_regs.trap value contains
+the system call type that can be used to distinguish between sc and scv 0
+system calls, and the different register conventions can be accounted for.
+
+If the value of (pt_regs.trap & 0xfff0) is 0xc00 then the system call was
+performed with the sc instruction, if it is 0x3000 then the system call was
+performed with the scv 0 instruction.
+
 vsyscall
 ========

tools/testing/selftests/seccomp/seccomp_bpf.c +18 -9

@@ -1753,16 +1753,25 @@ TEST_F(TRACE_poke, getpid_runs_normally)
 # define SYSCALL_RET_SET(_regs, _val)				\
 	do {							\
 		typeof(_val) _result = (_val);			\
-		/*						\
-		 * A syscall error is signaled by CR0 SO bit	\
-		 * and the code is stored as a positive value.	\
-		 */						\
-		if (_result < 0) {				\
-			SYSCALL_RET(_regs) = -_result;		\
-			(_regs).ccr |= 0x10000000;		\
-		} else {					\
+		if ((_regs.trap & 0xfff0) == 0x3000) {		\
+			/*					\
+			 * scv 0 system call uses -ve result	\
+			 * for error, so no need to adjust.	\
+			 */					\
 			SYSCALL_RET(_regs) = _result;		\
-			(_regs).ccr &= ~0x10000000;		\
+		} else {					\
+			/*					\
+			 * A syscall error is signaled by the	\
+			 * CR0 SO bit and the code is stored as	\
+			 * a positive value.			\
+			 */					\
+			if (_result < 0) {			\
+				SYSCALL_RET(_regs) = -_result;	\
+				(_regs).ccr |= 0x10000000;	\
+			} else {				\
+				SYSCALL_RET(_regs) = _result;	\
+				(_regs).ccr &= ~0x10000000;	\
+			}					\
 		}						\
 	} while (0)
 # define SYSCALL_RET_SET_ON_PTRACE_EXIT

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #65 lore raw

PATCH 65/104 powerpc/64s/syscall: Fix ptrace syscall info with scv syscalls

From: Nicholas Piggin <[email protected]>

commit d72500f992849d31ebae8f821a023660ddd0dcc2 upstream.

The scv implementation missed updating syscall return value and error value get/set functions to deal with the changed register ABI. This broke ptrace PTRACE_GET_SYSCALL_INFO as well as some kernel auditing and tracing functions.

Fix. tools/testing/selftests/ptrace/get_syscall_info now passes when scv is used.

Fixes 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")

Cc [email protected] # v5.9+

Reported-by "Dmitry V. Levin" <[email protected]>

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

Reviewed-by Dmitry V. Levin <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 arch/powerpc/include/asm/ptrace.h  |   45 +++++++++++++++++++++----------------
 arch/powerpc/include/asm/syscall.h |   42 +++++++++++++++++++++-------------
 2 files changed, 52 insertions(+), 35 deletions(-)

arch/powerpc/include/asm/ptrace.h +26 ~~-19~~

@@ -19,6 +19,7 @@
 #ifndef _ASM_POWERPC_PTRACE_H
 #define _ASM_POWERPC_PTRACE_H
 
+#include <linux/err.h>
 #include <uapi/asm/ptrace.h>
 #include <asm/asm-const.h>

@@ -144,25 +145,6 @@ extern unsigned long profile_pc(struct p
 long do_syscall_trace_enter(struct pt_regs *regs);
 void do_syscall_trace_leave(struct pt_regs *regs);
 
-#define kernel_stack_pointer(regs) ((regs)->gpr[1])
-static inline int is_syscall_success(struct pt_regs *regs)
-{
-	return !(regs->ccr & 0x10000000);
-}
-
-static inline long regs_return_value(struct pt_regs *regs)
-{
-	if (is_syscall_success(regs))
-		return regs->gpr[3];
-	else
-		return -regs->gpr[3];
-}
-
-static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
-{
-	regs->gpr[3] = rc;
-}
-
 #ifdef __powerpc64__
 #define user_mode(regs) ((((regs)->msr) >> MSR_PR_LG) & 0x1)
 #else

@@ -245,6 +227,31 @@ static inline void set_trap_norestart(st
 	regs->trap |= 0x10;
 }
 
+#define kernel_stack_pointer(regs) ((regs)->gpr[1])
+static inline int is_syscall_success(struct pt_regs *regs)
+{
+	if (trap_is_scv(regs))
+		return !IS_ERR_VALUE((unsigned long)regs->gpr[3]);
+	else
+		return !(regs->ccr & 0x10000000);
+}
+
+static inline long regs_return_value(struct pt_regs *regs)
+{
+	if (trap_is_scv(regs))
+		return regs->gpr[3];
+
+	if (is_syscall_success(regs))
+		return regs->gpr[3];
+	else
+		return -regs->gpr[3];
+}
+
+static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
+{
+	regs->gpr[3] = rc;
+}
+
 #define arch_has_single_step()	(1)
 #define arch_has_block_step()	(true)
 #define ARCH_HAS_USER_SINGLE_STEP_REPORT

arch/powerpc/include/asm/syscall.h +26 ~~-16~~

55 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #66 lore raw

PATCH 66/104 mmc: sdhci-pci-gli: increase 1.8V regulator wait

From: Daniel Beer <[email protected]>

commit a1149a6c06ee094a6e62886b0c0e8e66967a728a upstream.

Inserting an SD-card on an Intel NUC10i3FNK4 (which contains a GL9755) results in the message:

mmc0: 1.8V regulator output did not become stable

Following this message, some cards work (sometimes), but most cards fail with EILSEQ. This behaviour is observed on Debian 10 running kernel 4.19.188, but also with 5.8.18 and 5.11.15.

The driver currently waits 5ms after switching on the 1.8V regulator for it to become stable. Increasing this to 10ms gets rid of the warning about stability, but most cards still fail. Increasing it to 20ms gets some cards working (a 32GB Samsung micro SD works, a 128GB ADATA doesn't). At 50ms, the ADATA works most of the time, and at 100ms both cards work reliably.

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

Acked-by Ben Chuang <[email protected]>

Fixes e51df6ce668a ("mmc: host: sdhci-pci: Add Genesys Logic GL975x support")

Link https://lore.kernel.org/r/[email protected] open here

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

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

---
 drivers/mmc/host/sdhci-pci-gli.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/mmc/host/sdhci-pci-gli.c +6 -1

@@ -555,8 +555,13 @@ static void sdhci_gli_voltage_switch(str
 	 *
 	 * Wait 5ms after set 1.8V signal enable in Host Control 2 register
 	 * to ensure 1.8V signal enable bit is set by GL9750/GL9755.
+	 *
+	 * ...however, the controller in the NUC10i3FNK4 (a 9755) requires
+	 * slightly longer than 5ms before the control register reports that
+	 * 1.8V is ready, and far longer still before the card will actually
+	 * work reliably.
 	 */
-	usleep_range(5000, 5500);
+	usleep_range(100000, 110000);
 }
 
 static void sdhci_gl9750_reset(struct sdhci_host *host, u8 mask)

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #67 lore raw

PATCH 67/104 xen-pciback: redo VF placement in the virtual topology

From: Jan Beulich <[email protected]>

commit 4ba50e7c423c29639878c00573288869aa627068 upstream.

The commit referenced below was incomplete: It merely affected what would get written to the vdev-<N> xenstore node. The guest would still find the function at the original function number as long as __xen_pcibk_get_pci_dev() wouldn't be in sync. The same goes for AER wrt __xen_pcibk_get_pcifront_dev().

Undo overriding the function to zero and instead make sure that VFs at function zero remain alone in their slot. This has the added benefit of improving overall capacity, considering that there's only a total of 32 slots available right now (PCI segment and bus can both only ever be zero at present).

Fixes 8a5248fe10b1 ("xen PV passthru: assign SR-IOV virtual functions to separate virtual slots")

Signed-off-by Jan Beulich <[email protected]>

Reviewed-by Boris Ostrovsky <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

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

---
 drivers/xen/xen-pciback/vpci.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

drivers/xen/xen-pciback/vpci.c +8 -6

@@ -70,7 +70,7 @@ static int __xen_pcibk_add_pci_dev(struc
 				   struct pci_dev *dev, int devid,
 				   publish_pci_dev_cb publish_cb)
 {
-	int err = 0, slot, func = -1;
+	int err = 0, slot, func = PCI_FUNC(dev->devfn);
 	struct pci_dev_entry *t, *dev_entry;
 	struct vpci_dev_data *vpci_dev = pdev->pci_dev_data;

@@ -95,22 +95,25 @@ static int __xen_pcibk_add_pci_dev(struc
 
 	/*
 	 * Keep multi-function devices together on the virtual PCI bus, except
-	 * virtual functions.
+	 * that we want to keep virtual functions at func 0 on their own. They
+	 * aren't multi-function devices and hence their presence at func 0
+	 * may cause guests to not scan the other functions.
 	 */
-	if (!dev->is_virtfn) {
+	if (!dev->is_virtfn || func) {
 		for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
 			if (list_empty(&vpci_dev->dev_list[slot]))
 				continue;
 
 			t = list_entry(list_first(&vpci_dev->dev_list[slot]),
 				       struct pci_dev_entry, list);
+			if (t->dev->is_virtfn && !PCI_FUNC(t->dev->devfn))
+				continue;
 
 			if (match_slot(dev, t->dev)) {
 				dev_info(&dev->dev, "vpci: assign to virtual slot %d func %d\n",
-					 slot, PCI_FUNC(dev->devfn));
+					 slot, func);
 				list_add_tail(&dev_entry->list,
 					      &vpci_dev->dev_list[slot]);
-				func = PCI_FUNC(dev->devfn);
 				goto unlock;
 			}
 		}

@@ -123,7 +126,6 @@ static int __xen_pcibk_add_pci_dev(struc
 				 slot);
 			list_add_tail(&dev_entry->list,
 				      &vpci_dev->dev_list[slot]);
-			func = dev->is_virtfn ? 0 : PCI_FUNC(dev->devfn);
 			goto unlock;
 		}
 	}

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #68 lore raw

PATCH 68/104 xen-pciback: reconfigure also from backend watch handler

From: Jan Beulich <[email protected]>

commit c81d3d24602540f65256f98831d0a25599ea6b87 upstream.

When multiple PCI devices get assigned to a guest right at boot, libxl incrementally populates the backend tree. The writes for the first of the devices trigger the backend watch. In turn xen_pcibk_setup_backend() will set the XenBus state to Initialised, at which point no further reconfigures would happen unless a device got hotplugged. Arrange for reconfigure to also get triggered from the backend watch handler.

Signed-off-by Jan Beulich <[email protected]>

Reviewed-by Boris Ostrovsky <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

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

---
 drivers/xen/xen-pciback/xenbus.c |   22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

drivers/xen/xen-pciback/xenbus.c +17 -5

@@ -359,7 +359,8 @@ out:
 	return err;
 }
 
-static int xen_pcibk_reconfigure(struct xen_pcibk_device *pdev)
+static int xen_pcibk_reconfigure(struct xen_pcibk_device *pdev,
+				 enum xenbus_state state)
 {
 	int err = 0;
 	int num_devs;

@@ -373,9 +374,7 @@ static int xen_pcibk_reconfigure(struct
 	dev_dbg(&pdev->xdev->dev, "Reconfiguring device ...\n");
 
 	mutex_lock(&pdev->dev_lock);
-	/* Make sure we only reconfigure once */
-	if (xenbus_read_driver_state(pdev->xdev->nodename) !=
-	    XenbusStateReconfiguring)
+	if (xenbus_read_driver_state(pdev->xdev->nodename) != state)
 		goto out;
 
 	err = xenbus_scanf(XBT_NIL, pdev->xdev->nodename, "num_devs", "%d",

@@ -500,6 +499,10 @@ static int xen_pcibk_reconfigure(struct
 		}
 	}
 
+	if (state != XenbusStateReconfiguring)
+		/* Make sure we only reconfigure once. */
+		goto out;
+
 	err = xenbus_switch_state(pdev->xdev, XenbusStateReconfigured);
 	if (err) {
 		xenbus_dev_fatal(pdev->xdev, err,

@@ -525,7 +528,7 @@ static void xen_pcibk_frontend_changed(s
 		break;
 
 	case XenbusStateReconfiguring:
-		xen_pcibk_reconfigure(pdev);
+		xen_pcibk_reconfigure(pdev, XenbusStateReconfiguring);
 		break;
 
 	case XenbusStateConnected:

@@ -664,6 +667,15 @@ static void xen_pcibk_be_watch(struct xe
 		xen_pcibk_setup_backend(pdev);
 		break;
 
+	case XenbusStateInitialised:
+		/*
+		 * We typically move to Initialised when the first device was
+		 * added. Hence subsequent devices getting added may need
+		 * reconfiguring.
+		 */
+		xen_pcibk_reconfigure(pdev, XenbusStateInitialised);
+		break;
+
 	default:
 		break;
 	}

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #69 lore raw

PATCH 69/104 ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry

From: Varad Gautam <[email protected]>

commit a11ddb37bf367e6b5239b95ca759e5389bb46048 upstream.

do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send.

This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash:

  RIP: 0010:wake_q_add_safe+0x13/0x60
  Call Trace:
   __x64_sys_mq_timedsend+0x2a9/0x490
   do_syscall_64+0x80/0x680
   entry_SYSCALL_64_after_hwframe+0x44/0xa9
  RIP: 0033:0x7f5928e40343

The race occurs as:

1. do_mq_timedreceive calls wq_sleep with the address of struct ext_wait_queue on function stack (aliased as ewq_addr here) - it holds a valid struct ext_wait_queue * as long as the stack has not been overwritten.

2. ewq_addr gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op.

3. Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. (this is ewq_addr.)

4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it will see state == STATE_READY and break.

5. do_mq_timedreceive returns, and ewq_addr is no longer guaranteed to be a struct ext_wait_queue * since it was on do_mq_timedreceive's stack. (Although the address may not get overwritten until another function happens to touch it, which means it can persist around for an indefinite time.)

6. do_mq_timedsend::__pipelined_op() still believes ewq_addr is a struct ext_wait_queue *, and uses it to find a task_struct to pass to the wake_q_add_safe call. In the lucky case where nothing has overwritten ewq_addr yet, ewq_addr->task is the right task_struct. In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a bogus address as the receiver's task_struct causing the crash.

do_mq_timedsend::__pipelined_op() should not dereference this after setting STATE_READY, as the receiver counterpart is now free to return. Change __pipelined_op to call wake_q_add_safe on the receiver's task_struct returned by get_task_struct, instead of dereferencing this which sits on the receiver's stack.

As Manfred pointed out, the race potentially also exists in ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix those in the same way.

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

Fixes c5b2cbdbdac563 ("ipc/mqueue.c: update/document memory barriers")

Fixes 8116b54e7e23ef ("ipc/sem.c: document and update memory barriers")

Fixes 0d97a82ba830d8 ("ipc/msg.c: update and document memory barriers")

Signed-off-by Varad Gautam <[email protected]>

Reported-by Matthias von Faber <[email protected]>

Acked-by Davidlohr Bueso <[email protected]>

Acked-by Manfred Spraul <[email protected]>

Cc Christian Brauner <[email protected]>

Cc Oleg Nesterov <[email protected]>

Cc "Eric W. Biederman" <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

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

---
 ipc/mqueue.c |    6 ++++--
 ipc/msg.c    |    6 ++++--
 ipc/sem.c    |    6 ++++--
 3 files changed, 12 insertions(+), 6 deletions(-)

ipc/mqueue.c +4 -2

@@ -1003,12 +1003,14 @@ static inline void __pipelined_op(struct
 				  struct mqueue_inode_info *info,
 				  struct ext_wait_queue *this)
 {
+	struct task_struct *task;
+
 	list_del(&this->list);
-	get_task_struct(this->task);
+	task = get_task_struct(this->task);
 
 	/* see MQ_BARRIER for purpose/pairing */
 	smp_store_release(&this->state, STATE_READY);
-	wake_q_add_safe(wake_q, this->task);
+	wake_q_add_safe(wake_q, task);
 }
 
 /* pipelined_send() - send a message directly to the task waiting in

ipc/msg.c +4 -2

@@ -251,11 +251,13 @@ static void expunge_all(struct msg_queue
 	struct msg_receiver *msr, *t;
 
 	list_for_each_entry_safe(msr, t, &msq->q_receivers, r_list) {
-		get_task_struct(msr->r_tsk);
+		struct task_struct *r_tsk;
+
+		r_tsk = get_task_struct(msr->r_tsk);
 
 		/* see MSG_BARRIER for purpose/pairing */
 		smp_store_release(&msr->r_msg, ERR_PTR(res));
-		wake_q_add_safe(wake_q, msr->r_tsk);
+		wake_q_add_safe(wake_q, r_tsk);
 	}
 }

ipc/sem.c +4 -2

@@ -784,12 +784,14 @@ would_block:
 static inline void wake_up_sem_queue_prepare(struct sem_queue *q, int error,
 					     struct wake_q_head *wake_q)
 {
-	get_task_struct(q->sleeper);
+	struct task_struct *sleeper;
+
+	sleeper = get_task_struct(q->sleeper);
 
 	/* see SEM_BARRIER_2 for purpuse/pairing */
 	smp_store_release(&q->status, error);
 
-	wake_q_add_safe(wake_q, q->sleeper);
+	wake_q_add_safe(wake_q, sleeper);
 }
 
 static void unlink_queue(struct sem_array *sma, struct sem_queue *q)

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #70 lore raw

PATCH 70/104 dm snapshot: fix a crash when an origin has no snapshots

From: Mikulas Patocka <[email protected]>

commit 7ee06ddc4038f936b0d4459d37a7d4d844fb03db upstream.

If an origin target has no snapshots, o->split_boundary is set to 0. This causes BUG_ON(sectors <= 0) in block/bio.c:bio_split().

Fix this by initializing chunk_size, and in turn split_boundary, to rounddown_pow_of_two(UINT_MAX) -- the largest power of two that fits into "unsigned" type.

Reported-by Michael Tokarev <[email protected]>

Tested-by Michael Tokarev <[email protected]>

Signed-off-by Mikulas Patocka <[email protected]>

Signed-off-by Mike Snitzer <[email protected]>

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

---
 drivers/md/dm-snap.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

drivers/md/dm-snap.c +2 -3

@@ -854,12 +854,11 @@ static int dm_add_exception(void *contex
 static uint32_t __minimum_chunk_size(struct origin *o)
 {
 	struct dm_snapshot *snap;
-	unsigned chunk_size = 0;
+	unsigned chunk_size = rounddown_pow_of_two(UINT_MAX);
 
 	if (o)
 		list_for_each_entry(snap, &o->snapshots, list)
-			chunk_size = min_not_zero(chunk_size,
-						  snap->store->chunk_size);
+			chunk_size = min(chunk_size, snap->store->chunk_size);
 
 	return (uint32_t) chunk_size;
 }

Mikulas Patocka

2021-05-25 11:37 UTC #71 lore raw

Patch regression - Re: [PATCH 5.10 070/104] dm snapshot: fix a crash when an origin has no snapshots

Hi Greg

I'd like to ask you to drop this patch from all stable branches.

It causes regression with snapshot merging and the regression is much worse than the bug that it fixes.

Mikulas

Quoted 40 lines · Greg Kroah-Hartman

From: Mikulas Patocka <[email protected]>
commit 7ee06ddc4038f936b0d4459d37a7d4d844fb03db upstream.
If an origin target has no snapshots, o->split_boundary is set to 0. This causes BUG_ON(sectors <= 0) in block/bio.c:bio_split().
Fix this by initializing chunk_size, and in turn split_boundary, to rounddown_pow_of_two(UINT_MAX) -- the largest power of two that fits into "unsigned" type.
Reported-by Michael Tokarev <[email protected]>
Tested-by Michael Tokarev <[email protected]>
Cc [email protected]
Signed-off-by Mikulas Patocka <[email protected]>
Signed-off-by Mike Snitzer <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/md/dm-snap.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/md/dm-snap.c +2 -3
@@ -854,12 +854,11 @@ static int dm_add_exception(void *contex
 static uint32_t __minimum_chunk_size(struct origin *o)
 {
 	struct dm_snapshot *snap;
-	unsigned chunk_size = 0;
+	unsigned chunk_size = rounddown_pow_of_two(UINT_MAX);
 
 	if (o)
 		list_for_each_entry(snap, &o->snapshots, list)
-			chunk_size = min_not_zero(chunk_size,
-						  snap->store->chunk_size);
+			chunk_size = min(chunk_size, snap->store->chunk_size);
 
 	return (uint32_t) chunk_size;
 }

Greg Kroah-Hartman

author maintainer

2021-05-25 11:52 UTC #72 lore raw

Re: Patch regression - Re: [PATCH 5.10 070/104] dm snapshot: fix a crash when an origin has no snapshots

Quoted 6 lines · Mikulas Patocka

Hi Greg
I'd like to ask you to drop this patch from all stable branches.
It causes regression with snapshot merging and the regression is much worse than the bug that it fixes.

Sure, but is there a fix in Linus's branch for this that I should take instead, or is it reverted in linux-next already?

thanks,

greg k-h

Mikulas Patocka

2021-05-25 11:58 UTC #73 lore raw

Re: Patch regression - Re: [PATCH 5.10 070/104] dm snapshot: fix a crash when an origin has no snapshots

Quoted 8 lines · Greg Kroah-Hartman

Quoted 6 lines · Mikulas Patocka
Hi Greg
I'd like to ask you to drop this patch from all stable branches.
It causes regression with snapshot merging and the regression is much worse than the bug that it fixes.

Quoted 6 lines

Sure, but is there a fix in Linus's branch for this that I should take instead, or is it reverted in linux-next already?
thanks,
greg k-h

There is no fix now - but the bug that this fixed is minor (it fixes a crash in a configuration that is never set by lvm2) - and the regression is major (snapshot merging doesn't work).

I'll work with Mike on reverting it a providing a proper fix.

Mikulas

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #74 lore raw

PATCH 71/104 dm snapshot: fix crash with transient storage and zero chunk size

From: Mikulas Patocka <[email protected]>

commit c699a0db2d62e3bbb7f0bf35c87edbc8d23e3062 upstream.

The following commands will crash the kernel:

modprobe brd rd_size=1048576
dmsetup create o --table "0 blockdev --getsize /dev/ram0 snapshot-origin /dev/ram0" dmsetup create s --table "0 blockdev --getsize /dev/ram0 snapshot /dev/ram0 /dev/ram1 N 0"

The reason is that when we test for zero chunk size, we jump to the label bad_read_metadata without setting the "r" variable. The function snapshot_ctr destroys all the structures and then exits with "r == 0". The kernel then crashes because it falsely believes that snapshot_ctr succeeded.

In order to fix the bug, we set the variable "r" to -EINVAL.

Signed-off-by Mikulas Patocka <[email protected]>

Signed-off-by Mike Snitzer <[email protected]>

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

---
 drivers/md/dm-snap.c |    1 +
 1 file changed, 1 insertion(+)

drivers/md/dm-snap.c +1 -0

@@ -1407,6 +1407,7 @@ static int snapshot_ctr(struct dm_target
 
 	if (!s->store->chunk_size) {
 		ti->error = "Chunk size not set";
+		r = -EINVAL;
 		goto bad_read_metadata;
 	}

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #75 lore raw

PATCH 72/104 kcsan: Fix debugfs initcall return type

From: Arnd Bergmann <[email protected]>

commit 976aac5f882989e4f6c1b3a7224819bf0e801c6a upstream.

clang with CONFIG_LTO_CLANG points out that an initcall function should return an 'int' due to the changes made to the initcall macros in commit 3578ad11f3fb ("init: lto: fix PREL32 relocations"):

kernel/kcsan/debugfs.c:274:15: error: returning 'void' from a function with incompatible result type 'int' late_initcall(kcsan_debugfs_init);
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
include/linux/init.h:292:46: note: expanded from macro 'late_initcall'
#define late_initcall(fn) __define_initcall(fn, 7)

Fixes e36299efe7d7 ("kcsan, debugfs: Move debugfs file creation out of early init")

Cc stable <[email protected]>

Reviewed-by Greg Kroah-Hartman <[email protected]>

Reviewed-by Marco Elver <[email protected]>

Reviewed-by Nathan Chancellor <[email protected]>

Reviewed-by Miguel Ojeda <[email protected]>

Signed-off-by Arnd Bergmann <[email protected]>

Signed-off-by Paul E. McKenney <[email protected]>

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

---
 kernel/kcsan/debugfs.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

kernel/kcsan/debugfs.c +2 -1

@@ -261,9 +261,10 @@ static const struct file_operations debu
 	.release = single_release
 };
 
-static void __init kcsan_debugfs_init(void)
+static int __init kcsan_debugfs_init(void)
 {
 	debugfs_create_file("kcsan", 0644, NULL, NULL, &debugfs_ops);
+	return 0;
 }
 
 late_initcall(kcsan_debugfs_init);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #76 lore raw

PATCH 73/104 Revert "video: hgafb: fix potential NULL pointer dereference"

From: Greg Kroah-Hartman <[email protected]>

commit 58c0cc2d90f1e37c4eb63ae7f164c83830833f78 upstream.

This reverts commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

This patch "looks" correct, but the driver keeps on running and will fail horribly right afterward if this error condition ever trips.

So points for trying to resolve an issue, but a huge NEGATIVE value for providing a "fake" fix for the problem as nothing actually got resolved at all. I'll go fix this up properly...

Cc Kangjie Lu <[email protected]>

Cc Aditya Pakki <[email protected]>

Cc Ferenc Bakonyi <[email protected]>

Cc Bartlomiej Zolnierkiewicz <[email protected]>

Fixes ec7f6aad57ad ("video: hgafb: fix potential NULL pointer dereference")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/video/fbdev/hgafb.c |    2 --
 1 file changed, 2 deletions(-)

drivers/video/fbdev/hgafb.c +0 -2

@@ -285,8 +285,6 @@ static int hga_card_detect(void)
 	hga_vram_len  = 0x08000;
 
 	hga_vram = ioremap(0xb0000, hga_vram_len);
-	if (!hga_vram)
-		goto error;
 
 	if (request_region(0x3b0, 12, "hgafb"))
 		release_io_ports = 1;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #77 lore raw

PATCH 74/104 Revert "net: stmicro: fix a missing check of clk_prepare"

From: Greg Kroah-Hartman <[email protected]>

commit bee1b0511844c8c79fccf1f2b13472393b6b91f7 upstream.

This reverts commit f86a3b83833e7cfe558ca4d70b64ebc48903efec.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

The original commit causes a memory leak when it is trying to claim it is properly handling errors. Revert this change and fix it up properly in a follow-on commit.

Cc Kangjie Lu <[email protected]>

Cc David S. Miller <[email protected]>

Fixes f86a3b83833e ("net: stmicro: fix a missing check of clk_prepare")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c +1 -3

@@ -50,9 +50,7 @@ static int sun7i_gmac_init(struct platfo
 		gmac->clk_enabled = 1;
 	} else {
 		clk_set_rate(gmac->tx_clk, SUN7I_GMAC_MII_RATE);
-		ret = clk_prepare(gmac->tx_clk);
-		if (ret)
-			return ret;
+		clk_prepare(gmac->tx_clk);
 	}
 
 	return 0;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #78 lore raw

PATCH 75/104 Revert "leds: lp5523: fix a missing check of return value of lp55xx_read"

From: Greg Kroah-Hartman <[email protected]>

commit 8d1beda5f11953ffe135a5213287f0b25b4da41b upstream.

This reverts commit 248b57015f35c94d4eae2fdd8c6febf5cd703900.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

The original commit does not properly unwind if there is an error condition so it needs to be reverted at this point in time.

Cc Kangjie Lu <[email protected]>

Cc Jacek Anaszewski <[email protected]>

Cc stable <[email protected]>

Fixes 248b57015f35 ("leds: lp5523: fix a missing check of return value of lp55xx_read")

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/leds/leds-lp5523.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

drivers/leds/leds-lp5523.c +1 -3

@@ -305,9 +305,7 @@ static int lp5523_init_program_engine(st
 
 	/* Let the programs run for couple of ms and check the engine status */
 	usleep_range(3000, 6000);
-	ret = lp55xx_read(chip, LP5523_REG_STATUS, &status);
-	if (ret)
-		return ret;
+	lp55xx_read(chip, LP5523_REG_STATUS, &status);
 	status &= LP5523_ENG_STATUS_MASK;
 
 	if (status != LP5523_ENG_STATUS_MASK) {

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #79 lore raw

PATCH 76/104 Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"

From: Greg Kroah-Hartman <[email protected]>

commit 99ae3417672a6d4a3bf68d4fc43d7c6ca074d477 upstream.

This reverts commit 9aa3aa15f4c2f74f47afd6c5db4b420fadf3f315.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, it was determined that this commit is not needed at all so just revert it. Also, the call to lm80_init_client() was not properly handled, so if error handling is needed in the lm80_probe() function, then it should be done properly, not half-baked like the commit being reverted here did.

Cc Kangjie Lu <[email protected]>

Fixes 9aa3aa15f4c2 ("hwmon: (lm80) fix a missing check of bus read in lm80 probe")

Cc stable <[email protected]>

Acked-by Guenter Roeck <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/hwmon/lm80.c |   11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

drivers/hwmon/lm80.c +2 -9

@@ -596,7 +596,6 @@ static int lm80_probe(struct i2c_client
 	struct device *dev = &client->dev;
 	struct device *hwmon_dev;
 	struct lm80_data *data;
-	int rv;
 
 	data = devm_kzalloc(dev, sizeof(struct lm80_data), GFP_KERNEL);
 	if (!data)

@@ -609,14 +608,8 @@ static int lm80_probe(struct i2c_client
 	lm80_init_client(client);
 
 	/* A few vars need to be filled upon startup */
-	rv = lm80_read_value(client, LM80_REG_FAN_MIN(1));
-	if (rv < 0)
-		return rv;
-	data->fan[f_min][0] = rv;
-	rv = lm80_read_value(client, LM80_REG_FAN_MIN(2));
-	if (rv < 0)
-		return rv;
-	data->fan[f_min][1] = rv;
+	data->fan[f_min][0] = lm80_read_value(client, LM80_REG_FAN_MIN(1));
+	data->fan[f_min][1] = lm80_read_value(client, LM80_REG_FAN_MIN(2));
 
 	hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
 							   data, lm80_groups);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #80 lore raw

PATCH 77/104 Revert "video: imsttfb: fix potential NULL pointer dereferences"

From: Greg Kroah-Hartman <[email protected]>

commit ed04fe8a0e87d7b5ea17d47f4ac9ec962b24814a upstream.

This reverts commit 1d84353d205a953e2381044953b7fa31c8c9702d.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

The original commit here, while technically correct, did not fully handle all of the reported issues that the commit stated it was fixing, so revert it until it can be "fixed" fully.

Note, ioremap() probably will never fail for old hardware like this, and if anyone actually used this hardware (a PowerMac era PCI display card), they would not be using fbdev anymore.

Cc Kangjie Lu <[email protected]>

Cc Aditya Pakki <[email protected]>

Cc Finn Thain <[email protected]>

Cc Bartlomiej Zolnierkiewicz <[email protected]>

Reviewed-by Rob Herring <[email protected]>

Fixes 1d84353d205a ("video: imsttfb: fix potential NULL pointer dereferences")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/video/fbdev/imsttfb.c |    5 -----
 1 file changed, 5 deletions(-)

drivers/video/fbdev/imsttfb.c +0 -5

@@ -1512,11 +1512,6 @@ static int imsttfb_probe(struct pci_dev
 	info->fix.smem_start = addr;
 	info->screen_base = (__u8 *)ioremap(addr, par->ramdac == IBM ?
 					    0x400000 : 0x800000);
-	if (!info->screen_base) {
-		release_mem_region(addr, size);
-		framebuffer_release(info);
-		return -ENOMEM;
-	}
 	info->fix.mmio_start = addr + 0x800000;
 	par->dc_regs = ioremap(addr + 0x800000, 0x1000);
 	par->cmap_regs_phys = addr + 0x840000;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #81 lore raw

PATCH 78/104 Revert "ecryptfs: replace BUG_ON with error handling code"

From: Greg Kroah-Hartman <[email protected]>

commit e1436df2f2550bc89d832ffd456373fdf5d5b5d7 upstream.

This reverts commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

The original commit log for this change was incorrect, no "error handling code" was added, things will blow up just as badly as before if any of these cases ever were true. As this BUG_ON() never fired, and most of these checks are "obviously" never going to be true, let's just revert to the original code for now until this gets unwound to be done correctly in the future.

Cc Aditya Pakki <[email protected]>

Fixes 2c2a7552dd64 ("ecryptfs: replace BUG_ON with error handling code")

Cc stable <[email protected]>

Acked-by Tyler Hicks <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 fs/ecryptfs/crypto.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

fs/ecryptfs/crypto.c +2 -4

@@ -296,10 +296,8 @@ static int crypt_scatterlist(struct ecry
 	struct extent_crypt_result ecr;
 	int rc = 0;
 
-	if (!crypt_stat || !crypt_stat->tfm
-	       || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED))
-		return -EINVAL;
-
+	BUG_ON(!crypt_stat || !crypt_stat->tfm
+	       || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED));
 	if (unlikely(ecryptfs_verbosity > 0)) {
 		ecryptfs_printk(KERN_DEBUG, "Key size [%zd]; key:\n",
 				crypt_stat->key_size);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #82 lore raw

PATCH 79/104 Revert "scsi: ufs: fix a missing check of devm_reset_control_get"

From: Greg Kroah-Hartman <[email protected]>

commit 4d427b408c4c2ff1676966c72119a3a559f8e39b upstream.

This reverts commit 63a06181d7ce169d09843645c50fea1901bc9f0a.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

The original commit is incorrect, it does not properly clean up on the error path, so I'll keep the revert and fix it up properly with a follow-on patch.

Cc Kangjie Lu <[email protected]>

Cc Avri Altman <[email protected]>

Cc Martin K. Petersen <[email protected]>

Fixes 63a06181d7ce ("scsi: ufs: fix a missing check of devm_reset_control_get")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/scsi/ufs/ufs-hisi.c |    4 ----
 1 file changed, 4 deletions(-)

drivers/scsi/ufs/ufs-hisi.c +0 -4

@@ -479,10 +479,6 @@ static int ufs_hisi_init_common(struct u
 	ufshcd_set_variant(hba, host);
 
 	host->rst  = devm_reset_control_get(dev, "rst");
-	if (IS_ERR(host->rst)) {
-		dev_err(dev, "%s: failed to get reset control\n", __func__);
-		return PTR_ERR(host->rst);
-	}
 
 	ufs_hisi_set_pm_lvl(hba);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #83 lore raw

PATCH 80/104 Revert "gdrom: fix a memory leak bug"

From: Greg Kroah-Hartman <[email protected]>

commit 257343d3ed557f11d580d0b7c515dc154f64a42b upstream.

This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

Because of this, all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix. Until that work is complete, remove this change to ensure that no problems are being introduced into the codebase.

Cc Wenwen Wang <[email protected]>

Cc Peter Rosin <[email protected]>

Cc Jens Axboe <[email protected]>

Fixes 093c48213ee3 ("gdrom: fix a memory leak bug")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/cdrom/gdrom.c |    1 -
 1 file changed, 1 deletion(-)

drivers/cdrom/gdrom.c +0 -1

@@ -863,7 +863,6 @@ static void __exit exit_gdrom(void)
 	platform_device_unregister(pd);
 	platform_driver_unregister(&gdrom_driver);
 	kfree(gd.toc);
-	kfree(gd.cd_info);
 }
 
 module_init(init_gdrom);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #84 lore raw

PATCH 81/104 cdrom: gdrom: deallocate struct gdrom_unit fields in remove_gdrom

From: Atul Gopinathan <[email protected]>

commit d03d1021da6fe7f46efe9f2a7335564e7c9db5ab upstream.

The fields, "toc" and "cd_info", of "struct gdrom_unit gd" are allocated in "probe_gdrom()". Prevent a memory leak by making sure "gd.cd_info" is deallocated in the "remove_gdrom()" function.

Also prevent double free of the field "gd.toc" by moving it from the module's exit function to "remove_gdrom()". This is because, in "probe_gdrom()", the function makes sure to deallocate "gd.toc" in case of any errors, so the exit function invoked later would again free "gd.toc".

The patch also maintains consistency by deallocating the above mentioned fields in "remove_gdrom()" along with another memory allocated field "gd.disk".

Cc Peter Rosin <[email protected]>

Cc stable <[email protected]>

Signed-off-by Atul Gopinathan <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/cdrom/gdrom.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/cdrom/gdrom.c +2 -1

@@ -831,6 +831,8 @@ static int remove_gdrom(struct platform_
 	if (gdrom_major)
 		unregister_blkdev(gdrom_major, GDROM_DEV_NAME);
 	unregister_cdrom(gd.cd_info);
+	kfree(gd.cd_info);
+	kfree(gd.toc);
 
 	return 0;
 }

@@ -862,7 +864,6 @@ static void __exit exit_gdrom(void)
 {
 	platform_device_unregister(pd);
 	platform_driver_unregister(&gdrom_driver);
-	kfree(gd.toc);
 }
 
 module_init(init_gdrom);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #85 lore raw

PATCH 82/104 cdrom: gdrom: initialize global variable at init time

From: Greg Kroah-Hartman <[email protected]>

commit 9183f01b5e6e32eb3f17b5f3f8d5ad5ac9786c49 upstream.

As Peter points out, if we were to disconnect and then reconnect this driver from a device, the "global" state of the device would contain odd values and could cause problems. Fix this up by just initializing the whole thing to 0 at probe() time.

Ideally this would be a per-device variable, but given the age and the total lack of users of it, that would require a lot of s/./->/g changes for really no good reason.

Reported-by Peter Rosin <[email protected]>

Cc Jens Axboe <[email protected]>

Reviewed-by Peter Rosin <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/cdrom/gdrom.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

drivers/cdrom/gdrom.c +8 -1

@@ -743,6 +743,13 @@ static const struct blk_mq_ops gdrom_mq_
 static int probe_gdrom(struct platform_device *devptr)
 {
 	int err;
+
+	/*
+	 * Ensure our "one" device is initialized properly in case of previous
+	 * usages of it
+	 */
+	memset(&gd, 0, sizeof(gd));
+
 	/* Start the device */
 	if (gdrom_execute_diagnostic() != 1) {
 		pr_warn("ATA Probe for GDROM failed\n");

@@ -848,7 +855,7 @@ static struct platform_driver gdrom_driv
 static int __init init_gdrom(void)
 {
 	int rc;
-	gd.toc = NULL;
+
 	rc = platform_driver_register(&gdrom_driver);
 	if (rc)
 		return rc;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #86 lore raw

PATCH 83/104 Revert "media: rcar_drif: fix a memory disclosure"

From: Greg Kroah-Hartman <[email protected]>

commit 3e465fc3846734e9489273d889f19cc17b4cf4bd upstream.

This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, it was determined that this commit is not needed at all as the media core already prevents memory disclosure on this codepath, so just drop the extra memset happening here.

Cc Kangjie Lu <[email protected]>

Cc Geert Uytterhoeven <[email protected]>

Cc Hans Verkuil <[email protected]>

Cc Mauro Carvalho Chehab <[email protected]>

Fixes d39083234c60 ("media: rcar_drif: fix a memory disclosure")

Cc stable <[email protected]>

Reviewed-by Mauro Carvalho Chehab <[email protected]>

Reviewed-by Fabrizio Castro <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/media/platform/rcar_drif.c |    1 -
 1 file changed, 1 deletion(-)

drivers/media/platform/rcar_drif.c +0 -1

@@ -915,7 +915,6 @@ static int rcar_drif_g_fmt_sdr_cap(struc
 {
 	struct rcar_drif_sdr *sdr = video_drvdata(file);
 
-	memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
 	f->fmt.sdr.pixelformat = sdr->fmt->pixelformat;
 	f->fmt.sdr.buffersize = sdr->fmt->buffersize;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #87 lore raw

PATCH 84/104 Revert "rtlwifi: fix a potential NULL pointer dereference"

From: Greg Kroah-Hartman <[email protected]>

commit 68c5634c4a7278672a3bed00eb5646884257c413 upstream.

This reverts commit 765976285a8c8db3f0eb7f033829a899d0c2786e.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

This commit is not correct, it should not have used unlikely() and is not propagating the error properly to the calling function, so it should be reverted at this point in time. Also, if the check failed, the work queue was still assumed to be allocated, so further accesses would have continued to fail, meaning this patch does nothing to solve the root issues at all.

Cc Kangjie Lu <[email protected]>

Cc Kalle Valo <[email protected]>

Cc Bryan Brattlof <[email protected]>

Fixes 765976285a8c ("rtlwifi: fix a potential NULL pointer dereference")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/net/wireless/realtek/rtlwifi/base.c |    5 -----
 1 file changed, 5 deletions(-)

drivers/net/wireless/realtek/rtlwifi/base.c +0 -5

@@ -452,11 +452,6 @@ static void _rtl_init_deferred_work(stru
 	/* <2> work queue */
 	rtlpriv->works.hw = hw;
 	rtlpriv->works.rtl_wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
-	if (unlikely(!rtlpriv->works.rtl_wq)) {
-		pr_err("Failed to allocate work queue\n");
-		return;
-	}
-
 	INIT_DELAYED_WORK(&rtlpriv->works.watchdog_wq,
 			  rtl_watchdog_wq_callback);
 	INIT_DELAYED_WORK(&rtlpriv->works.ips_nic_off_wq,

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #88 lore raw

PATCH 85/104 Revert "qlcnic: Avoid potential NULL pointer dereference"

From: Greg Kroah-Hartman <[email protected]>

commit b95b57dfe7a142bf2446548eb7f49340fd73e78b upstream.

This reverts commit 5bf7295fe34a5251b1d241b9736af4697b590670.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

This commit does not properly detect if an error happens because the logic after this loop will not detect that there was a failed allocation.

Cc Aditya Pakki <[email protected]>

Cc David S. Miller <[email protected]>

Fixes 5bf7295fe34a ("qlcnic: Avoid potential NULL pointer dereference")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c |    2 --
 1 file changed, 2 deletions(-)

drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c +0 -2

@@ -1047,8 +1047,6 @@ int qlcnic_do_lb_test(struct qlcnic_adap
 
 	for (i = 0; i < QLCNIC_NUM_ILB_PKT; i++) {
 		skb = netdev_alloc_skb(adapter->netdev, QLCNIC_ILB_PKT_SIZE);
-		if (!skb)
-			break;
 		qlcnic_create_loopback_buff(skb->data, adapter->mac_addr);
 		skb_put(skb, QLCNIC_ILB_PKT_SIZE);
 		adapter->ahw->diag_cnt = 0;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #89 lore raw

PATCH 86/104 Revert "niu: fix missing checks of niu_pci_eeprom_read"

From: Greg Kroah-Hartman <[email protected]>

commit 7930742d6a0ff091c85b92ef4e076432d8d8cb79 upstream.

This reverts commit 26fd962bde0b15e54234fe762d86bc0349df1de4.

Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not.

Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change.

The change here was incorrect. While it is nice to check if niu_pci_eeprom_read() succeeded or not when using the data, any error that might have happened was not propagated upwards properly, causing the kernel to assume that these reads were successful, which results in invalid data in the buffer that was to contain the successfully read data.

Cc Kangjie Lu <[email protected]>

Cc Shannon Nelson <[email protected]>

Cc David S. Miller <[email protected]>

Fixes 26fd962bde0b ("niu: fix missing checks of niu_pci_eeprom_read")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/net/ethernet/sun/niu.c |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

drivers/net/ethernet/sun/niu.c +2 -8

@@ -8097,8 +8097,6 @@ static int niu_pci_vpd_scan_props(struct
 		start += 3;
 
 		prop_len = niu_pci_eeprom_read(np, start + 4);
-		if (prop_len < 0)
-			return prop_len;
 		err = niu_pci_vpd_get_propname(np, start + 5, namebuf, 64);
 		if (err < 0)
 			return err;

@@ -8143,12 +8141,8 @@ static int niu_pci_vpd_scan_props(struct
 			netif_printk(np, probe, KERN_DEBUG, np->dev,
 				     "VPD_SCAN: Reading in property [%s] len[%d]\n",
 				     namebuf, prop_len);
-			for (i = 0; i < prop_len; i++) {
-				err = niu_pci_eeprom_read(np, off + i);
-				if (err >= 0)
-					*prop_buf = err;
-				++prop_buf;
-			}
+			for (i = 0; i < prop_len; i++)
+				*prop_buf++ = niu_pci_eeprom_read(np, off + i);
 		}
 
 		start += len;

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #90 lore raw

PATCH 87/104 ethernet: sun: niu: fix missing checks of niu_pci_eeprom_read()

From: Du Cheng <[email protected]>

commit e6e337708c22f80824b82d4af645f20715730ad0 upstream.

niu_pci_eeprom_read() may fail, so add checks to its return value and propagate the error up the callstack.

An examination of the callstack up to niu_pci_eeprom_read shows that:

niu_pci_eeprom_read() // returns int
niu_pci_vpd_scan_props() // returns int
niu_pci_vpd_fetch() // returns *void*
niu_get_invariants() // returns int

since niu_pci_vpd_fetch() returns void which breaks the bubbling up, change its return type to int so that error is propagated upwards.

Signed-off-by Du Cheng <[email protected]>

Cc Shannon Nelson <[email protected]>

Cc David S. Miller <[email protected]>

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/net/ethernet/sun/niu.c |   34 ++++++++++++++++++++++++----------
 1 file changed, 24 insertions(+), 10 deletions(-)

drivers/net/ethernet/sun/niu.c +24 ~~-10~~

@@ -8097,6 +8097,8 @@ static int niu_pci_vpd_scan_props(struct
 		start += 3;
 
 		prop_len = niu_pci_eeprom_read(np, start + 4);
+		if (prop_len < 0)
+			return prop_len;
 		err = niu_pci_vpd_get_propname(np, start + 5, namebuf, 64);
 		if (err < 0)
 			return err;

@@ -8141,8 +8143,12 @@ static int niu_pci_vpd_scan_props(struct
 			netif_printk(np, probe, KERN_DEBUG, np->dev,
 				     "VPD_SCAN: Reading in property [%s] len[%d]\n",
 				     namebuf, prop_len);
-			for (i = 0; i < prop_len; i++)
-				*prop_buf++ = niu_pci_eeprom_read(np, off + i);
+			for (i = 0; i < prop_len; i++) {
+				err =  niu_pci_eeprom_read(np, off + i);
+				if (err < 0)
+					return err;
+				*prop_buf++ = err;
+			}
 		}
 
 		start += len;

@@ -8152,14 +8158,14 @@ static int niu_pci_vpd_scan_props(struct
 }
 
 /* ESPC_PIO_EN_ENABLE must be set */
-static void niu_pci_vpd_fetch(struct niu *np, u32 start)
+static int niu_pci_vpd_fetch(struct niu *np, u32 start)
 {
 	u32 offset;
 	int err;
 
 	err = niu_pci_eeprom_read16_swp(np, start + 1);
 	if (err < 0)
-		return;
+		return err;
 
 	offset = err + 3;

@@ -8168,12 +8174,14 @@ static void niu_pci_vpd_fetch(struct niu
 		u32 end;
 
 		err = niu_pci_eeprom_read(np, here);
+		if (err < 0)
+			return err;
 		if (err != 0x90)
-			return;
+			return -EINVAL;
 
 		err = niu_pci_eeprom_read16_swp(np, here + 1);
 		if (err < 0)
-			return;
+			return err;
 
 		here = start + offset + 3;
 		end = start + offset + err;

@@ -8181,9 +8189,12 @@ static void niu_pci_vpd_fetch(struct niu
 		offset += err;
 
 		err = niu_pci_vpd_scan_props(np, here, end);
-		if (err < 0 || err == 1)
-			return;
+		if (err < 0)
+			return err;
+		if (err == 1)
+			return -EINVAL;
 	}
+	return 0;
 }
 
 /* ESPC_PIO_EN_ENABLE must be set */

@@ -9274,8 +9285,11 @@ static int niu_get_invariants(struct niu
 		offset = niu_pci_vpd_offset(np);
 		netif_printk(np, probe, KERN_DEBUG, np->dev,
 			     "%s() VPD offset [%08x]\n", __func__, offset);
-		if (offset)
-			niu_pci_vpd_fetch(np, offset);
+		if (offset) {
+			err = niu_pci_vpd_fetch(np, offset);
+			if (err < 0)
+				return err;
+		}
 		nw64(ESPC_PIO_EN, 0);
 
 		if (np->flags & NIU_FLAGS_VPD_VALID) {

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #91 lore raw

PATCH 88/104 net: stmicro: handle clk_prepare() failure during init

From: Anirudh Rayabharam <[email protected]>

commit 0c32a96d000f260b5ebfabb4145a86ae1cd71847 upstream.

In case clk_prepare() fails, capture and propagate the error code up the stack. If regulator_enable() was called earlier, properly unwind it by calling regulator_disable().

Signed-off-by Anirudh Rayabharam <[email protected]>

Cc David S. Miller <[email protected]>

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

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

drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c +5 -3

@@ -30,7 +30,7 @@ struct sunxi_priv_data {
 static int sun7i_gmac_init(struct platform_device *pdev, void *priv)
 {
 	struct sunxi_priv_data *gmac = priv;
-	int ret;
+	int ret = 0;
 
 	if (gmac->regulator) {
 		ret = regulator_enable(gmac->regulator);

@@ -50,10 +50,12 @@ static int sun7i_gmac_init(struct platfo
 		gmac->clk_enabled = 1;
 	} else {
 		clk_set_rate(gmac->tx_clk, SUN7I_GMAC_MII_RATE);
-		clk_prepare(gmac->tx_clk);
+		ret = clk_prepare(gmac->tx_clk);
+		if (ret && gmac->regulator)
+			regulator_disable(gmac->regulator);
 	}
 
-	return 0;
+	return ret;
 }
 
 static void sun7i_gmac_exit(struct platform_device *pdev, void *priv)

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #92 lore raw

PATCH 89/104 scsi: ufs: handle cleanup correctly on devm_reset_control_get error

From: Phillip Potter <[email protected]>

commit 2f4a784f40f8d337d6590e2e93f46429052e15ac upstream.

Move ufshcd_set_variant call in ufs_hisi_init_common to common error section at end of the function, and then jump to this from the error checking statements for both devm_reset_control_get and ufs_hisi_get_resource. This fixes the original commit (63a06181d7ce) which was reverted due to the University of Minnesota problems.

Cc Avri Altman <[email protected]>

Cc Martin K. Petersen <[email protected]>

Cc stable <[email protected]>

Signed-off-by Phillip Potter <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/scsi/ufs/ufs-hisi.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

drivers/scsi/ufs/ufs-hisi.c +12 -5

@@ -478,17 +478,24 @@ static int ufs_hisi_init_common(struct u
 	host->hba = hba;
 	ufshcd_set_variant(hba, host);
 
-	host->rst  = devm_reset_control_get(dev, "rst");
+	host->rst = devm_reset_control_get(dev, "rst");
+	if (IS_ERR(host->rst)) {
+		dev_err(dev, "%s: failed to get reset control\n", __func__);
+		err = PTR_ERR(host->rst);
+		goto error;
+	}
 
 	ufs_hisi_set_pm_lvl(hba);
 
 	err = ufs_hisi_get_resource(host);
-	if (err) {
-		ufshcd_set_variant(hba, NULL);
-		return err;
-	}
+	if (err)
+		goto error;
 
 	return 0;
+
+error:
+	ufshcd_set_variant(hba, NULL);
+	return err;
 }
 
 static int ufs_hi3660_init(struct ufs_hba *hba)

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #93 lore raw

PATCH 90/104 net: rtlwifi: properly check for alloc_workqueue() failure

From: Greg Kroah-Hartman <[email protected]>

commit 30b0e0ee9d02b97b68705c46b41444786effc40c upstream.

If alloc_workqueue() fails, properly catch this and propagate the error to the calling functions, so that the devuce initialization will properly error out.

Cc Kalle Valo <[email protected]>

Cc Bryan Brattlof <[email protected]>

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/net/wireless/realtek/rtlwifi/base.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

drivers/net/wireless/realtek/rtlwifi/base.c +10 -5

@@ -440,9 +440,14 @@ static void rtl_watchdog_wq_callback(str
 static void rtl_fwevt_wq_callback(struct work_struct *work);
 static void rtl_c2hcmd_wq_callback(struct work_struct *work);
 
-static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
+static int _rtl_init_deferred_work(struct ieee80211_hw *hw)
 {
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
+	struct workqueue_struct *wq;
+
+	wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
+	if (!wq)
+		return -ENOMEM;
 
 	/* <1> timer */
 	timer_setup(&rtlpriv->works.watchdog_timer,

@@ -451,7 +456,8 @@ static void _rtl_init_deferred_work(stru
 		    rtl_easy_concurrent_retrytimer_callback, 0);
 	/* <2> work queue */
 	rtlpriv->works.hw = hw;
-	rtlpriv->works.rtl_wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
+	rtlpriv->works.rtl_wq = wq;
+
 	INIT_DELAYED_WORK(&rtlpriv->works.watchdog_wq,
 			  rtl_watchdog_wq_callback);
 	INIT_DELAYED_WORK(&rtlpriv->works.ips_nic_off_wq,

@@ -461,6 +467,7 @@ static void _rtl_init_deferred_work(stru
 			  rtl_swlps_rfon_wq_callback);
 	INIT_DELAYED_WORK(&rtlpriv->works.fwevt_wq, rtl_fwevt_wq_callback);
 	INIT_DELAYED_WORK(&rtlpriv->works.c2hcmd_wq, rtl_c2hcmd_wq_callback);
+	return 0;
 }
 
 void rtl_deinit_deferred_work(struct ieee80211_hw *hw, bool ips_wq)

@@ -560,9 +567,7 @@ int rtl_init_core(struct ieee80211_hw *h
 	rtlmac->link_state = MAC80211_NOLINK;
 
 	/* <6> init deferred work */
-	_rtl_init_deferred_work(hw);
-
-	return 0;
+	return _rtl_init_deferred_work(hw);
 }
 EXPORT_SYMBOL_GPL(rtl_init_core);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #94 lore raw

PATCH 91/104 ics932s401: fix broken handling of errors when word reading fails

Link https://lore.kernel.org/r/20210428222534.GJ3122264@magnolia open here

From: Darrick J. Wong <[email protected]>

commit a73b6a3b4109ce2ed01dbc51a6c1551a6431b53c upstream.

In commit b05ae01fdb89, someone tried to make the driver handle i2c read errors by simply zeroing out the register contents, but for some reason left unaltered the code that sets the cached register value the function call return value.

The original patch was authored by a member of the Underhanded Mangle-happy Nerds, I'm not terribly surprised. I don't have the hardware anymore so I can't test this, but it seems like a pretty obvious API usage fix to me...

Fixes b05ae01fdb89 ("misc/ics932s401: Add a missing check to i2c_smbus_read_word_data")

Signed-off-by Darrick J. Wong <[email protected]>

Cc stable <[email protected]>

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

---
 drivers/misc/ics932s401.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/misc/ics932s401.c +1 -1

@@ -134,7 +134,7 @@ static struct ics932s401_data *ics932s40
 	for (i = 0; i < NUM_MIRRORED_REGS; i++) {
 		temp = i2c_smbus_read_word_data(client, regs_to_copy[i]);
 		if (temp < 0)
-			data->regs[regs_to_copy[i]] = 0;
+			temp = 0;
 		data->regs[regs_to_copy[i]] = temp >> 8;
 	}

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #95 lore raw

PATCH 92/104 leds: lp5523: check return value of lp5xx_read and jump to cleanup code

From: Phillip Potter <[email protected]>

commit 6647f7a06eb030a2384ec71f0bb2e78854afabfe upstream.

Check return value of lp5xx_read and if non-zero, jump to code at end of the function, causing lp5523_stop_all_engines to be executed before returning the error value up the call chain. This fixes the original commit (248b57015f35) which was reverted due to the University of Minnesota problems.

Cc stable <[email protected]>

Acked-by Jacek Anaszewski <[email protected]>

Signed-off-by Phillip Potter <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/leds/leds-lp5523.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/leds/leds-lp5523.c +3 -1

@@ -305,7 +305,9 @@ static int lp5523_init_program_engine(st
 
 	/* Let the programs run for couple of ms and check the engine status */
 	usleep_range(3000, 6000);
-	lp55xx_read(chip, LP5523_REG_STATUS, &status);
+	ret = lp55xx_read(chip, LP5523_REG_STATUS, &status);
+	if (ret)
+		goto out;
 	status &= LP5523_ENG_STATUS_MASK;
 
 	if (status != LP5523_ENG_STATUS_MASK) {

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #96 lore raw

PATCH 93/104 qlcnic: Add null check after calling netdev_alloc_skb

From: Tom Seewald <[email protected]>

commit 84460f01cba382553199bc1361f69a872d5abed4 upstream.

The function qlcnic_dl_lb_test() currently calls netdev_alloc_skb() without checking afterwards that the allocation succeeded. Fix this by checking if the skb is NULL and returning an error in such a case. Breaking out of the loop if the skb is NULL is not correct as no error would be reported to the caller and no message would be printed for the user.

Cc David S. Miller <[email protected]>

Cc stable <[email protected]>

Signed-off-by Tom Seewald <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c +3 -0

@@ -1047,6 +1047,8 @@ int qlcnic_do_lb_test(struct qlcnic_adap
 
 	for (i = 0; i < QLCNIC_NUM_ILB_PKT; i++) {
 		skb = netdev_alloc_skb(adapter->netdev, QLCNIC_ILB_PKT_SIZE);
+		if (!skb)
+			goto error;
 		qlcnic_create_loopback_buff(skb->data, adapter->mac_addr);
 		skb_put(skb, QLCNIC_ILB_PKT_SIZE);
 		adapter->ahw->diag_cnt = 0;

@@ -1070,6 +1072,7 @@ int qlcnic_do_lb_test(struct qlcnic_adap
 			cnt++;
 	}
 	if (cnt != i) {
+error:
 		dev_err(&adapter->pdev->dev,
 			"LB Test: failed, TX[%d], RX[%d]\n", i, cnt);
 		if (mode != QLCNIC_ILB_MODE)

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #97 lore raw

PATCH 94/104 video: hgafb: fix potential NULL pointer dereference

From: Igor Matheus Andrade Torrente <[email protected]>

commit dc13cac4862cc68ec74348a80b6942532b7735fa upstream.

The return of ioremap if not checked, and can lead to a NULL to be assigned to hga_vram. Potentially leading to a NULL pointer dereference.

The fix adds code to deal with this case in the error label and changes how the hgafb_probe handles the return of hga_card_detect.

Cc Ferenc Bakonyi <[email protected]>

Cc Bartlomiej Zolnierkiewicz <[email protected]>

Cc stable <[email protected]>

Signed-off-by Igor Matheus Andrade Torrente <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/video/fbdev/hgafb.c |   21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

drivers/video/fbdev/hgafb.c +13 -8

@@ -285,6 +285,8 @@ static int hga_card_detect(void)
 	hga_vram_len  = 0x08000;
 
 	hga_vram = ioremap(0xb0000, hga_vram_len);
+	if (!hga_vram)
+		return -ENOMEM;
 
 	if (request_region(0x3b0, 12, "hgafb"))
 		release_io_ports = 1;

@@ -344,13 +346,18 @@ static int hga_card_detect(void)
 			hga_type_name = "Hercules";
 			break;
 	}
-	return 1;
+	return 0;
 error:
 	if (release_io_ports)
 		release_region(0x3b0, 12);
 	if (release_io_port)
 		release_region(0x3bf, 1);
-	return 0;
+
+	iounmap(hga_vram);
+
+	pr_err("hgafb: HGA card not detected.\n");
+
+	return -EINVAL;
 }
 
 /**

@@ -548,13 +555,11 @@ static const struct fb_ops hgafb_ops = {
 static int hgafb_probe(struct platform_device *pdev)
 {
 	struct fb_info *info;
+	int ret;
 
-	if (! hga_card_detect()) {
-		printk(KERN_INFO "hgafb: HGA card not detected.\n");
-		if (hga_vram)
-			iounmap(hga_vram);
-		return -EINVAL;
-	}
+	ret = hga_card_detect();
+	if (!ret)
+		return ret;
 
 	printk(KERN_INFO "hgafb: %s with %ldK of memory detected.\n",
 		hga_type_name, hga_vram_len/1024);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #98 lore raw

PATCH 95/104 vgacon: Record video mode changes with VT_RESIZEX

From: Maciej W. Rozycki <[email protected]>

commit d4d0ad57b3865795c4cde2fb5094c594c2e8f469 upstream.

Fix an issue with VGA console font size changes made after the initial video text mode has been changed with a user tool like `svgatextmode' calling the VT_RESIZEX ioctl. As it stands in that case the original screen geometry continues being used to validate further VT resizing.

Consequently when the video adapter is firstly reprogrammed from the original say 80x25 text mode using a 9x16 character cell (720x400 pixel resolution) to say 80x37 text mode and the same character cell (720x592 pixel resolution), and secondly the CRTC character cell updated to 9x8 (by loading a suitable font with the KD_FONT_OP_SET request of the KDFONTOP ioctl), the VT geometry does not get further updated from 80x37 and only upper half of the screen is used for the VT, with the lower half showing rubbish corresponding to whatever happens to be there in the video memory that maps to that part of the screen. Of course the proportions change according to text mode geometries and font sizes chosen.

Address the problem then, by updating the text mode geometry defaults rather than checking against them whenever the VT is resized via a user ioctl.

Signed-off-by Maciej W. Rozycki <[email protected]>

Fixes e400b6ec4ede ("vt/vgacon: Check if screen resize request comes from userspace")

Cc [email protected] # v2.6.24+

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

---
 drivers/video/console/vgacon.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

drivers/video/console/vgacon.c +11 -3

@@ -1108,12 +1108,20 @@ static int vgacon_resize(struct vc_data
 	if ((width << 1) * height > vga_vram_size)
 		return -EINVAL;
 
+	if (user) {
+		/*
+		 * Ho ho!  Someone (svgatextmode, eh?) may have reprogrammed
+		 * the video mode!  Set the new defaults then and go away.
+		 */
+		screen_info.orig_video_cols = width;
+		screen_info.orig_video_lines = height;
+		vga_default_font_height = c->vc_font.height;
+		return 0;
+	}
 	if (width % 2 || width > screen_info.orig_video_cols ||
 	    height > (screen_info.orig_video_lines * vga_default_font_height)/
 	    c->vc_font.height)
-		/* let svgatextmode tinker with video timings and
-		   return success */
-		return (user) ? 0 : -EINVAL;
+		return -EINVAL;
 
 	if (con_is_visible(c) && !vga_is_gfx) /* who knows */
 		vgacon_doresize(c, width, height);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #99 lore raw

PATCH 96/104 vt_ioctl: Revert VT_RESIZEX parameter handling removal

From: Maciej W. Rozycki <[email protected]>

commit a90c275eb144c1b755f04769e1f29d832d6daeaf upstream.

Revert the removal of code handling extra VT_RESIZEX ioctl's parameters beyond those that VT_RESIZE supports, fixing a functional regression causing `svgatextmode' not to resize the VT anymore.

As a consequence of the reverted change when the video adapter is reprogrammed from the original say 80x25 text mode using a 9x16 character cell (720x400 pixel resolution) to say 80x37 text mode and the same character cell (720x592 pixel resolution), the VT geometry does not get updated and only upper two thirds of the screen are used for the VT, and the lower part remains blank. The proportions change according to text mode geometries chosen.

Revert the change verbatim then, bringing back previous VT resizing.

Signed-off-by Maciej W. Rozycki <[email protected]>

Fixes 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE")

Cc [email protected] # v5.10+

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

---
 drivers/tty/vt/vt_ioctl.c |   57 +++++++++++++++++++++++++++++++++++++---------
 1 file changed, 47 insertions(+), 10 deletions(-)

drivers/tty/vt/vt_ioctl.c +47 ~~-10~~

@@ -771,21 +771,58 @@ static int vt_resizex(struct vc_data *vc
 	if (copy_from_user(&v, cs, sizeof(struct vt_consize)))
 		return -EFAULT;
 
-	if (v.v_vlin)
-		pr_info_once("\"struct vt_consize\"->v_vlin is ignored. Please report if you need this.\n");
-	if (v.v_clin)
-		pr_info_once("\"struct vt_consize\"->v_clin is ignored. Please report if you need this.\n");
+	/* FIXME: Should check the copies properly */
+	if (!v.v_vlin)
+		v.v_vlin = vc->vc_scan_lines;
+
+	if (v.v_clin) {
+		int rows = v.v_vlin / v.v_clin;
+		if (v.v_rows != rows) {
+			if (v.v_rows) /* Parameters don't add up */
+				return -EINVAL;
+			v.v_rows = rows;
+		}
+	}
+
+	if (v.v_vcol && v.v_ccol) {
+		int cols = v.v_vcol / v.v_ccol;
+		if (v.v_cols != cols) {
+			if (v.v_cols)
+				return -EINVAL;
+			v.v_cols = cols;
+		}
+	}
+
+	if (v.v_clin > 32)
+		return -EINVAL;
 
-	console_lock();
 	for (i = 0; i < MAX_NR_CONSOLES; i++) {
-		vc = vc_cons[i].d;
+		struct vc_data *vcp;
+
+		if (!vc_cons[i].d)
+			continue;
+		console_lock();
+		vcp = vc_cons[i].d;
+		if (vcp) {
+			int ret;
+			int save_scan_lines = vcp->vc_scan_lines;
+			int save_font_height = vcp->vc_font.height;
 
-		if (vc) {
-			vc->vc_resize_user = 1;
-			vc_resize(vc, v.v_cols, v.v_rows);
+			if (v.v_vlin)
+				vcp->vc_scan_lines = v.v_vlin;
+			if (v.v_clin)
+				vcp->vc_font.height = v.v_clin;
+			vcp->vc_resize_user = 1;
+			ret = vc_resize(vcp, v.v_cols, v.v_rows);
+			if (ret) {
+				vcp->vc_scan_lines = save_scan_lines;
+				vcp->vc_font.height = save_font_height;
+				console_unlock();
+				return ret;
+			}
 		}
+		console_unlock();
 	}
-	console_unlock();
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2021-05-24 15:54 UTC #100 lore raw

PATCH 97/104 vt: Fix character height handling with VT_RESIZEX

[1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837
[2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3

From: Maciej W. Rozycki <[email protected]>

commit 860dafa902595fb5f1d23bbcce1215188c3341e6 upstream.

Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used.

For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded.

The v_clin' parameter is used by the vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new vc_cell_height' struct member of vc_data', set it instead of vc_font.height' from v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting.

This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"):

"syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2],
for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data."

The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git>
as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows:

if (clin)
- video_font_height = clin;
+ vc->vc_font.height = clin;

making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity.

Signed-off-by Maciej W. Rozycki <[email protected]>

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Cc [email protected] # v2.6.12+

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

---
 drivers/tty/vt/vt_ioctl.c      |    6 ++---
 drivers/video/console/vgacon.c |   44 ++++++++++++++++++++---------------------
 include/linux/console_struct.h |    1 
 3 files changed, 26 insertions(+), 25 deletions(-)

drivers/tty/vt/vt_ioctl.c +3 -3

@@ -806,17 +806,17 @@ static int vt_resizex(struct vc_data *vc
 		if (vcp) {
 			int ret;
 			int save_scan_lines = vcp->vc_scan_lines;
-			int save_font_height = vcp->vc_font.height;
+			int save_cell_height = vcp->vc_cell_height;
 
 			if (v.v_vlin)
 				vcp->vc_scan_lines = v.v_vlin;
 			if (v.v_clin)
-				vcp->vc_font.height = v.v_clin;
+				vcp->vc_cell_height = v.v_clin;
 			vcp->vc_resize_user = 1;
 			ret = vc_resize(vcp, v.v_cols, v.v_rows);
 			if (ret) {
 				vcp->vc_scan_lines = save_scan_lines;
-				vcp->vc_font.height = save_font_height;
+				vcp->vc_cell_height = save_cell_height;
 				console_unlock();
 				return ret;
 			}

drivers/video/console/vgacon.c +22 ~~-22~~

109 lines not on this page · raw message

include/linux/console_struct.h +1 -0

@@ -101,6 +101,7 @@ struct vc_data {
 	unsigned int	vc_rows;
 	unsigned int	vc_size_row;		/* Bytes per row */
 	unsigned int	vc_scan_lines;		/* # of scan lines */
+	unsigned int	vc_cell_height;		/* CRTC character cell height */
 	unsigned long	vc_origin;		/* [!] Start of real screen */
 	unsigned long	vc_scr_end;		/* [!] End of real screen */
 	unsigned long	vc_visible_origin;	/* [!] Top of visible window */

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #101 lore raw

PATCH 98/104 tty: vt: always invoke vc->vc_sw->con_resize callback

From: Tetsuo Handa <[email protected]>

commit ffb324e6f874121f7dce5bdae5e05d02baae7269 upstream.

syzbot is reporting OOB write at vga16fb_imageblit() [1], for resize_screen() from ioctl(VT_RESIZE) returns 0 without checking whether requested rows/columns fit the amount of memory reserved for the graphical screen if current mode is KD_GRAPHICS.

----------
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/kd.h>
#include <linux/vt.h>

  int main(int argc, char *argv[])
  {
        const int fd = open("/dev/char/4:1", O_RDWR);
        struct vt_sizes vt = { 0x4100, 2 };

        ioctl(fd, KDSETMODE, KD_GRAPHICS);
        ioctl(fd, VT_RESIZE, &vt);
        ioctl(fd, KDSETMODE, KD_TEXT);
        return 0;

}
----------

Allow framebuffer drivers to return -EINVAL, by moving vc->vc_mode != KD_GRAPHICS check from resize_screen() to fbcon_resize().

Link https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3 [1]

Reported-by syzbot <[email protected]>

Signed-off-by Tetsuo Handa <[email protected]>

Tested-by syzbot <[email protected]>

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

---
 drivers/tty/vt/vt.c              |    2 +-
 drivers/video/fbdev/core/fbcon.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

drivers/tty/vt/vt.c +1 -1

@@ -1172,7 +1172,7 @@ static inline int resize_screen(struct v
 	/* Resizes the resolution of the display adapater */
 	int err = 0;
 
-	if (vc->vc_mode != KD_GRAPHICS && vc->vc_sw->con_resize)
+	if (vc->vc_sw->con_resize)
 		err = vc->vc_sw->con_resize(vc, width, height, user);
 
 	return err;

drivers/video/fbdev/core/fbcon.c +1 -1

@@ -2031,7 +2031,7 @@ static int fbcon_resize(struct vc_data *
 			return -EINVAL;
 
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
-		if (con_is_visible(vc)) {
+		if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
 			var.activate = FB_ACTIVATE_NOW |
 				FB_ACTIVATE_FORCE;
 			fb_set_var(info, &var);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #102 lore raw

PATCH 99/104 drm/i915/gt: Disable HiZ Raw Stall Optimization on broken gen7

Link https://patchwork.freedesktop.org/patch/msgid/20210426161124.2b7fd708@dellnichtsogutkiste

From: Simon Rettberg <[email protected]>

commit 023dfa9602f561952c0e19d74f66614a56d7e57a upstream.

When resetting CACHE_MODE registers, don't enable HiZ Raw Stall Optimization on Ivybridge GT1 and Baytrail, as it causes severe glitches when rendering any kind of 3D accelerated content.
This optimization is disabled on these platforms by default according to official documentation from 01.org.

Fixes ef99a60ffd9b ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals")

BugLink https://gitlab.freedesktop.org/drm/intel/-/issues/3081

BugLink https://gitlab.freedesktop.org/drm/intel/-/issues/3404

BugLink https://gitlab.freedesktop.org/drm/intel/-/issues/3071

Reviewed-by Manuel Bentele <[email protected]>

Signed-off-by Simon Rettberg <[email protected]>

Reviewed-by Dave Airlie <[email protected]>

Signed-off-by Rodrigo Vivi <[email protected]>

[Rodrigo removed invalid Fixes line]

(cherry picked from commit 929b734ad34b717d6a1b8de97f53bb5616040147)

Signed-off-by Jani Nikula <[email protected]>

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

---
 drivers/gpu/drm/i915/gt/gen7_renderclear.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/gpu/drm/i915/gt/gen7_renderclear.c +4 -1

@@ -397,7 +397,10 @@ static void emit_batch(struct i915_vma *
 	gen7_emit_pipeline_invalidate(&cmds);
 	batch_add(&cmds, MI_LOAD_REGISTER_IMM(2));
 	batch_add(&cmds, i915_mmio_reg_offset(CACHE_MODE_0_GEN7));
-	batch_add(&cmds, 0xffff0000);
+	batch_add(&cmds, 0xffff0000 |
+			((IS_IVB_GT1(i915) || IS_VALLEYVIEW(i915)) ?
+			 HIZ_RAW_STALL_OPT_DISABLE :
+			 0));
 	batch_add(&cmds, i915_mmio_reg_offset(CACHE_MODE_1));
 	batch_add(&cmds, 0xffff0000 | PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
 	gen7_emit_pipeline_invalidate(&cmds);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #103 lore raw

PATCH 100/104 openrisc: mm/init.c: remove unused memblock_region variable in map_ram()

From: Mike Rapoport <[email protected]>

commit 4eff124347191d1548eb4e14e20e77513dcbd0fe upstream.

Kernel test robot reports:

cppcheck possible warnings: (new ones prefixed by >>, may not real problems)

Quoted 1 line

Quoted 1 line
arch/openrisc/mm/init.c:125:10: warning: Uninitialized variable: region [uninitvar]

            region->base, region->base + region->size);
            ^

Replace usage of memblock_region fields with 'start' and 'end' variables that are initialized in for_each_mem_range() and remove the declaration of region.

Fixes b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()")

Reported-by kernel test robot <[email protected]>

Signed-off-by Mike Rapoport <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

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

---
 arch/openrisc/mm/init.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

arch/openrisc/mm/init.c +1 -2

@@ -76,7 +76,6 @@ static void __init map_ram(void)
 	/* These mark extents of read-only kernel pages...
 	 * ...from vmlinux.lds.S
 	 */
-	struct memblock_region *region;
 
 	v = PAGE_OFFSET;

@@ -122,7 +121,7 @@ static void __init map_ram(void)
 		}
 
 		printk(KERN_INFO "%s: Memory: 0x%x-0x%x\n", __func__,
-		       region->base, region->base + region->size);
+		       start, end);
 	}
 }

Greg Kroah-Hartman

author maintainer

2021-05-24 16:02 UTC #104 lore raw

PATCH 101/104 x86/Xen: swap NX determination and GDT setup on BSP

From: Jan Beulich <[email protected]>

commit ae897fda4f507e4b239f0bdfd578b3688ca96fb4 upstream.

xen_setup_gdt(), via xen_load_gdt_boot(), wants to adjust page tables. For this to work when NX is not available, x86_configure_nx() needs to be called first.

[jgross] Note that this is a revert of 36104cb9012a82e73 ("x86/xen:
Delay get_cpu_cap until stack canary is established"), which is possible now that we no longer support running as PV guest in 32-bit mode.

Cc <stable.vger.kernel.org> # 5.9

Fixes 36104cb9012a82e73 ("x86/xen: Delay get_cpu_cap until stack canary is established")

Reported-by Olaf Hering <[email protected]>

Signed-off-by Jan Beulich <[email protected]>

Reviewed-by Juergen Gross <[email protected]>

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

Link https://lore.kernel.org/r/[email protected] open here

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

---
 arch/x86/xen/enlighten_pv.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/x86/xen/enlighten_pv.c +4 -4

@@ -1262,16 +1262,16 @@ asmlinkage __visible void __init xen_sta
 	/* Get mfn list */
 	xen_build_dynamic_phys_to_machine();
 
+	/* Work out if we support NX */
+	get_cpu_cap(&boot_cpu_data);
+	x86_configure_nx();
+
 	/*
 	 * Set up kernel GDT and segment registers, mainly so that
 	 * -fstack-protector code can be executed.
 	 */
 	xen_setup_gdt(0);
 
-	/* Work out if we support NX */
-	get_cpu_cap(&boot_cpu_data);
-	x86_configure_nx();
-
 	/* Determine virtual and physical address sizes */
 	get_cpu_address_sizes(&boot_cpu_data);

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #105 lore raw

PATCH 102/104 nvme-multipath: fix double initialization of ANA state

From: Christoph Hellwig <[email protected]>

commit 5e1f689913a4498e3081093670ef9d85b2c60920 upstream.

nvme_init_identify and thus nvme_mpath_init can be called multiple times and thus must not overwrite potentially initialized or in-use fields. Split out a helper for the basic initialization when the controller is initialized and make sure the init_identify path does not blindly change in-use data structures.

Fixes 0d0b660f214d ("nvme: add ANA support")

Reported-by Martin Wilck <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

Reviewed-by Keith Busch <[email protected]>

Reviewed-by Hannes Reinecke <[email protected]>

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

---
 drivers/nvme/host/core.c      |    3 +-
 drivers/nvme/host/multipath.c |   55 ++++++++++++++++++++++--------------------
 drivers/nvme/host/nvme.h      |    8 ++++--
 3 files changed, 37 insertions(+), 29 deletions(-)

drivers/nvme/host/core.c +2 -1

@@ -3131,7 +3131,7 @@ int nvme_init_identify(struct nvme_ctrl
 		ctrl->hmmaxd = le16_to_cpu(id->hmmaxd);
 	}
 
-	ret = nvme_mpath_init(ctrl, id);
+	ret = nvme_mpath_init_identify(ctrl, id);
 	kfree(id);
 
 	if (ret < 0)

@@ -4517,6 +4517,7 @@ int nvme_init_ctrl(struct nvme_ctrl *ctr
 		min(default_ps_max_latency_us, (unsigned long)S32_MAX));
 
 	nvme_fault_inject_init(&ctrl->fault_inject, dev_name(ctrl->device));
+	nvme_mpath_init_ctrl(ctrl);
 
 	return 0;
 out_free_name:

drivers/nvme/host/multipath.c +29 ~~-26~~

75 lines not on this page · raw message

drivers/nvme/host/nvme.h +6 -2

@@ -654,7 +654,8 @@ void nvme_kick_requeue_lists(struct nvme
 int nvme_mpath_alloc_disk(struct nvme_ctrl *ctrl,struct nvme_ns_head *head);
 void nvme_mpath_add_disk(struct nvme_ns *ns, struct nvme_id_ns *id);
 void nvme_mpath_remove_disk(struct nvme_ns_head *head);
-int nvme_mpath_init(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id);
+int nvme_mpath_init_identify(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id);
+void nvme_mpath_init_ctrl(struct nvme_ctrl *ctrl);
 void nvme_mpath_uninit(struct nvme_ctrl *ctrl);
 void nvme_mpath_stop(struct nvme_ctrl *ctrl);
 bool nvme_mpath_clear_current_path(struct nvme_ns *ns);

@@ -730,7 +731,10 @@ static inline void nvme_trace_bio_comple
         blk_status_t status)
 {
 }
-static inline int nvme_mpath_init(struct nvme_ctrl *ctrl,
+static inline void nvme_mpath_init_ctrl(struct nvme_ctrl *ctrl)
+{
+}
+static inline int nvme_mpath_init_identify(struct nvme_ctrl *ctrl,
 		struct nvme_id_ctrl *id)
 {
 	if (ctrl->subsys->cmic & (1 << 3))

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #106 lore raw

PATCH 103/104 rtc: pcf85063: fallback to parent of_node

From: Francois Gervais <[email protected]>

commit 03531606ef4cda25b629f500d1ffb6173b805c05 upstream.

The rtc device node is always NULL.

Since v5.12-rc1-dontuse/3c9ea42802a1fbf7ef29660ff8c6e526c58114f6 this will lead to a NULL pointer dereference.

To fix this use the parent node which is the i2c client node as set by devm_rtc_allocate_device().

Using the i2c client node seems to be what other similar drivers do e.g. rtc-pcf8563.c.

Signed-off-by Francois Gervais <[email protected]>

Signed-off-by Alexandre Belloni <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

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

---
 drivers/rtc/rtc-pcf85063.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

drivers/rtc/rtc-pcf85063.c +3 -4

@@ -486,6 +486,7 @@ static struct clk *pcf85063_clkout_regis
 {
 	struct clk *clk;
 	struct clk_init_data init;
+	struct device_node *node = pcf85063->rtc->dev.parent->of_node;
 
 	init.name = "pcf85063-clkout";
 	init.ops = &pcf85063_clkout_ops;

@@ -495,15 +496,13 @@ static struct clk *pcf85063_clkout_regis
 	pcf85063->clkout_hw.init = &init;
 
 	/* optional override of the clockname */
-	of_property_read_string(pcf85063->rtc->dev.of_node,
-				"clock-output-names", &init.name);
+	of_property_read_string(node, "clock-output-names", &init.name);
 
 	/* register the clock */
 	clk = devm_clk_register(&pcf85063->rtc->dev, &pcf85063->clkout_hw);
 
 	if (!IS_ERR(clk))
-		of_clk_add_provider(pcf85063->rtc->dev.of_node,
-				    of_clk_src_simple_get, clk);
+		of_clk_add_provider(node, of_clk_src_simple_get, clk);
 
 	return clk;
 }

Greg Kroah-Hartman

author maintainer

2021-05-24 15:55 UTC #107 lore raw

PATCH 104/104 x86/boot/compressed/64: Check SEV encryption in the 32-bit boot-path

From: Joerg Roedel <[email protected]>

commit fef81c86262879d4b1176ef51a834c15b805ebb9 upstream.

Check whether the hypervisor reported the correct C-bit when running as an SEV guest. Using a wrong C-bit position could be used to leak sensitive data from the guest to the hypervisor.

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

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

---
 arch/x86/boot/compressed/head_64.S |   85 +++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)

arch/x86/boot/compressed/head_64.S +85 -0

@@ -172,11 +172,21 @@ SYM_FUNC_START(startup_32)
 	 */
 	call	get_sev_encryption_bit
 	xorl	%edx, %edx
+#ifdef	CONFIG_AMD_MEM_ENCRYPT
 	testl	%eax, %eax
 	jz	1f
 	subl	$32, %eax	/* Encryption bit is always above bit 31 */
 	bts	%eax, %edx	/* Set encryption mask for page tables */
+	/*
+	 * Mark SEV as active in sev_status so that startup32_check_sev_cbit()
+	 * will do a check. The sev_status memory will be fully initialized
+	 * with the contents of MSR_AMD_SEV_STATUS later in
+	 * set_sev_encryption_mask(). For now it is sufficient to know that SEV
+	 * is active.
+	 */
+	movl	$1, rva(sev_status)(%ebp)
 1:
+#endif
 
 	/* Initialize Page tables to 0 */
 	leal	rva(pgtable)(%ebx), %edi

@@ -261,6 +271,9 @@ SYM_FUNC_START(startup_32)
 	movl	%esi, %edx
 1:
 #endif
+	/* Check if the C-bit position is correct when SEV is active */
+	call	startup32_check_sev_cbit
+
 	pushl	$__KERNEL_CS
 	pushl	%eax

@@ -787,6 +800,78 @@ SYM_DATA_END(loaded_image_proto)
 #endif
 
 /*
+ * Check for the correct C-bit position when the startup_32 boot-path is used.
+ *
+ * The check makes use of the fact that all memory is encrypted when paging is
+ * disabled. The function creates 64 bits of random data using the RDRAND
+ * instruction. RDRAND is mandatory for SEV guests, so always available. If the
+ * hypervisor violates that the kernel will crash right here.
+ *
+ * The 64 bits of random data are stored to a memory location and at the same
+ * time kept in the %eax and %ebx registers. Since encryption is always active
+ * when paging is off the random data will be stored encrypted in main memory.
+ *
+ * Then paging is enabled. When the C-bit position is correct all memory is
+ * still mapped encrypted and comparing the register values with memory will
+ * succeed. An incorrect C-bit position will map all memory unencrypted, so that
+ * the compare will use the encrypted random data and fail.
+ */
+	__HEAD
+	.code32
+SYM_FUNC_START(startup32_check_sev_cbit)
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+	pushl	%eax
+	pushl	%ebx
+	pushl	%ecx
+	pushl	%edx
+
+	/* Check for non-zero sev_status */
+	movl	rva(sev_status)(%ebp), %eax
+	testl	%eax, %eax
+	jz	4f
+
+	/*
+	 * Get two 32-bit random values - Don't bail out if RDRAND fails
+	 * because it is better to prevent forward progress if no random value
+	 * can be gathered.
+	 */
+1:	rdrand	%eax
+	jnc	1b
+2:	rdrand	%ebx
+	jnc	2b
+
+	/* Store to memory and keep it in the registers */
+	movl	%eax, rva(sev_check_data)(%ebp)
+	movl	%ebx, rva(sev_check_data+4)(%ebp)
+
+	/* Enable paging to see if encryption is active */
+	movl	%cr0, %edx			 /* Backup %cr0 in %edx */
+	movl	$(X86_CR0_PG | X86_CR0_PE), %ecx /* Enable Paging and Protected mode */
+	movl	%ecx, %cr0
+
+	cmpl	%eax, rva(sev_check_data)(%ebp)
+	jne	3f
+	cmpl	%ebx, rva(sev_check_data+4)(%ebp)
+	jne	3f
+
+	movl	%edx, %cr0	/* Restore previous %cr0 */
+
+	jmp	4f
+
+3:	/* Check failed - hlt the machine */
+	hlt
+	jmp	3b
+
+4:
+	popl	%edx
+	popl	%ecx
+	popl	%ebx
+	popl	%eax
+#endif
+	ret
+SYM_FUNC_END(startup32_check_sev_cbit)
+
+/*
  * Stack and heap for uncompression
  */
 	.bss

Fox Chen

Tested-by on the v1 series

2021-05-24 21:27 UTC #108 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.40 release. There are 104 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, 26 May 2021 15:23:11 +0000. 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/v5.x/stable-review/patch-5.10.40-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-5.10.y
and the diffstat can be found below.
thanks,
greg k-h

5.10.40-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)

Tested-by Fox Chen <[email protected]>

Florian Fainelli

Tested-by on the v1 series

2021-05-24 21:58 UTC #109 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.40 release. There are 104 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, 26 May 2021 15:23:11 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 8 lines

	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.40-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-5.10.y
and the diffstat can be found below.
thanks,
greg k-h

On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels:

Tested-by Florian Fainelli <[email protected]>

Signature · 1 line

Florian

Shuah Khan

Tested-by on the v1 series

2021-05-24 22:04 UTC #110 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.40 release. There are 104 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, 26 May 2021 15:23:11 +0000. 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/v5.x/stable-review/patch-5.10.40-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-5.10.y
and the diffstat can be found below.
thanks,
greg k-h

Compiled and booted on my test system. No dmesg regressions.

Tested-by Shuah Khan <[email protected]>

thanks,
-- Shuah

Naresh Kamboju

Tested-by Linux Kernel Functional Testing on the v1 series

2021-05-25 07:23 UTC #111 lore raw

Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.40 release. There are 104 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, 26 May 2021 15:23:11 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 8 lines

        https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.40-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-5.10.y
and the diffstat can be found below.
thanks,
greg k-h

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

Tested-by Linux Kernel Functional Testing <[email protected]>

## Build
* kernel: 5.10.40-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.10.y
* git commit: d8d2794a2bd357476a82c4d315ba323557fd5c80
* git describe: v5.10.39-105-gd8d2794a2bd3
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.39-105-gd8d2794a2bd3

## No regressions (compared to v5.10.39-105-gd60ecece01f3)

## No fixes (compared to v5.10.39-105-gd60ecece01f3)

## Test result summary
total: 82881, pass: 68064, fail: 2523, skip: 11584, xfail: 710,

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 193 total, 193 passed, 0 failed
* arm64: 27 total, 27 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 26 total, 26 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 45 total, 45 passed, 0 failed
* parisc: 9 total, 9 passed, 0 failed
* powerpc: 27 total, 27 passed, 0 failed
* riscv: 21 total, 21 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 18 total, 18 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 27 total, 27 passed, 0 failed

## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-
* kselftest-android
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-vsyscall-mode-native-
* kselftest-vsyscall-mode-none-
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-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-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

Jon Hunter

maintainer Tested-by on the v1 series

2021-05-25 08:28 UTC #112 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.40 release. There are 104 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, 26 May 2021 15:23:11 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 8 lines

	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.40-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-5.10.y
and the diffstat can be found below.
thanks,
greg k-h

All tests passing for Tegra ...

Test results for stable-v5.10:

    12 builds:	12 pass, 0 fail
    28 boots:	28 pass, 0 fail
    70 tests:	70 pass, 0 fail

Linux version: 5.10.40-rc1-gd8d2794a2bd3
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,

                tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
                tegra20-ventana, tegra210-p2371-2180,
                tegra210-p3450-0000, tegra30-cardhu-a04

Tested-by Jon Hunter <[email protected]>

Jon

Sudip Mukherjee

Tested-by on the v1 series

2021-05-25 14:26 UTC #113 lore raw

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.40 release. There are 104 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, 26 May 2021 15:23:11 +0000. Anything received after that time might be too late.

Build test:
mips (gcc version 11.1.1 20210523): 63 configs -> no failure arm (gcc version 11.1.1 20210523): 105 configs -> no new failure arm64 (gcc version 11.1.1 20210523): 2 configs -> no failure x86_64 (gcc version 10.2.1 20210110): 2 configs -> no failure

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression.
arm64: Booted on rpi4b(4GB). No regression.

Tested-by Sudip Mukherjee <[email protected]>

--
Regards
Sudip

Pavel Machek

Tested-by on the v1 series

2021-05-25 14:32 UTC #114 lore raw

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 5.10.40 release. There are 104 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.

CIP testing did not find any problems here:

Tested-by Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel

Signature · 2 lines

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Guenter Roeck

Tested-by on the v1 series

2021-05-25 21:26 UTC #115 lore raw

Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.40 release. There are 104 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, 26 May 2021 15:23:11 +0000. Anything received after that time might be too late.

Build results:

	total: 156 pass: 156 fail: 0
Qemu test results:
	total: 455 pass: 455 fail: 0

Tested-by Guenter Roeck <[email protected]>

Guenter

Samuel Zou

Tested-by Hulk Robot on the v1 series

2021-05-26 01:01 UTC #116 lore raw