Skip to contentSkip to conversation

4.14.216-rc1 review

PATCH In review Greg Kroah-Hartman 4 participants 32 messages Jan 15, 2021 – Jan 16, 2021

Subsystems (3)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.14.216-rc1 review

This is the start of the stable review cycle for the 4.14.216 release. There are 28 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 Sun, 17 Jan 2021 12:19:42 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.216-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.14.216-rc1

Vasily Averin <[email protected]>
net: drop bogus skb with CHECKSUM_PARTIAL and offset beyond end of trimmed packet

Ming Lei <[email protected]>
block: fix use-after-free in disk_part_iter_next

Marc Zyngier <[email protected]>
KVM: arm64: Don't access PMCR_EL0 when no PMU is available

Arnd Bergmann <[email protected]>
wan: ds26522: select CONFIG_BITREVERSE

Dinghao Liu <[email protected]>
net/mlx5e: Fix two double free cases

Dinghao Liu <[email protected]>
net/mlx5e: Fix memleak in mlx5e_create_l2_table_groups

Dinghao Liu <[email protected]>
iommu/intel: Fix memleak in intel_irq_remapping_alloc

Arnd Bergmann <[email protected]>
block: rsxx: select CONFIG_CRC32

Arnd Bergmann <[email protected]>

    wil6210: select CONFIG_CRC32

Shravya Kumbham <[email protected]>
dmaengine: xilinx_dma: fix mixed_enum_type coverity warning

Shravya Kumbham <[email protected]>
dmaengine: xilinx_dma: check dma_async_device_register return value

Roman Guskov <[email protected]>
spi: stm32: FIFO threshold level - fix align packet size

Colin Ian King <[email protected]>
cpufreq: powernow-k8: pass policy rather than use cpufreq_cpu_get()

Chunyan Zhang <[email protected]>
i2c: sprd: use a specific timeout to avoid system hang up issue

Andreas Kemnade <[email protected]>
ARM: OMAP2+: omap_device: fix idling of devices during probe

Lorenzo Bianconi <[email protected]>
iio: imu: st_lsm6dsx: fix edge-trigger interrupts

Sean Nyekjaer <[email protected]>
iio: imu: st_lsm6dsx: flip irq return logic

Lukas Wunner <[email protected]>
spi: pxa2xx: Fix use-after-free on unbind

Richard Weinberger <[email protected]>
ubifs: wbuf: Don't leak kernel memory to flash

Chris Wilson <[email protected]>
drm/i915: Fix mismatch between misplaced vma check and vma insert

Nick Desaulniers <[email protected]>
vmlinux.lds.h: Add PGO and AutoFDO input sections

Fenghua Yu <[email protected]>
x86/resctrl: Don't move a task to the same resource group

Fenghua Yu <[email protected]>
x86/resctrl: Use an IPI instead of task_work_add() to update PQR_ASSOC MSR

Florian Westphal <[email protected]>
net: fix pmtu check in nopmtudisc mode

Florian Westphal <[email protected]>
net: ip: always refragment ip defragmented packets

Jakub Kicinski <[email protected]>
net: vlan: avoid leaks on register_vlan_dev() failures

Jouni K. Seppänen <[email protected]>
net: cdc_ncm: correct overhead in delayed_ndp_size

Mathieu Desnoyers <[email protected]>
powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at

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

Diffstat:

 Makefile                                        |   4 +-
 arch/arm/mach-omap2/omap_device.c               |   8 +-
 arch/arm64/kvm/sys_regs.c                       |   4 +
 arch/powerpc/include/asm/book3s/32/pgtable.h    |   4 +-
 arch/powerpc/include/asm/nohash/pgtable.h       |   4 +-
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c        | 110 +++++++++++-------------
 block/genhd.c                                   |   9 +-
 drivers/block/Kconfig                           |   1 +
 drivers/cpufreq/powernow-k8.c                   |   9 +-
 drivers/dma/xilinx/xilinx_dma.c                 |   8 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c      |   2 +-
 drivers/i2c/busses/i2c-sprd.c                   |   8 +-
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c  |  26 ++++--
 drivers/iommu/intel_irq_remapping.c             |   2 +
 drivers/net/ethernet/mellanox/mlx5/core/en_fs.c |   3 +
 drivers/net/usb/cdc_ncm.c                       |   8 +-
 drivers/net/wan/Kconfig                         |   1 +
 drivers/net/wireless/ath/wil6210/Kconfig        |   1 +
 drivers/spi/spi-pxa2xx.c                        |   3 +-
 drivers/spi/spi-stm32.c                         |   4 +-
 fs/ubifs/io.c                                   |  13 ++-
 include/asm-generic/vmlinux.lds.h               |   5 +-
 net/8021q/vlan.c                                |   3 +-
 net/core/skbuff.c                               |   6 ++
 net/ipv4/ip_output.c                            |   2 +-
 net/ipv4/ip_tunnel.c                            |  10 +--
 26 files changed, 153 insertions(+), 105 deletions(-)
author maintainer
#1 lore raw

PATCH 1/28 powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at

From: Mathieu Desnoyers <[email protected]>

[ Upstream commit d85be8a49e733dcd23674aa6202870d54bf5600d ]

The placeholder for instruction selection should use the second argument's operand, which is %1, not %0. This could generate incorrect assembly code if the memory addressing of operand %0 is a different form from that of operand %1.

Also remove the %Un placeholder because having %Un placeholders for two operands which are based on the same local var (ptep) doesn't make much sense. By the way, it doesn't change the current behaviour because "<>" constraint is missing for the associated "=m".

[chleroy: revised commit log iaw segher's comments and removed %U0]

---
 arch/powerpc/include/asm/book3s/32/pgtable.h | 4 ++--
 arch/powerpc/include/asm/nohash/pgtable.h    | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
arch/powerpc/include/asm/book3s/32/pgtable.h +2 -2
index 016579ef16d3d..ec98abca0df03 100644
@@ -414,9 +414,9 @@ static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
 	if (pte_val(*ptep) & _PAGE_HASHPTE)
 		flush_hash_entry(mm, ptep, addr);
 	__asm__ __volatile__("\
-		stw%U0%X0 %2,%0\n\
+		stw%X0 %2,%0\n\
 		eieio\n\
-		stw%U0%X0 %L2,%1"
+		stw%X1 %L2,%1"
 	: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
 	: "r" (pte) : "memory");
 
arch/powerpc/include/asm/nohash/pgtable.h +2 -2
index 5c68f4a59f758..e9171b8242e4b 100644
@@ -157,9 +157,9 @@ static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
 		flush_hash_entry(mm, ptep, addr);
 #endif
 	__asm__ __volatile__("\
-		stw%U0%X0 %2,%0\n\
+		stw%X0 %2,%0\n\
 		eieio\n\
-		stw%U0%X0 %L2,%1"
+		stw%X1 %L2,%1"
 	: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
 	: "r" (pte) : "memory");
 
Signature · 1 line
2.27.0
author maintainer
#2 lore raw

PATCH 2/28 net: cdc_ncm: correct overhead in delayed_ndp_size

In reply to Greg Kroah-Hartman

From: "Jouni K. Sepp�nen" <[email protected]>

[ Upstream commit 7a68d725e4ea384977445e0bcaed3d7de83ab5b3 ]

Aligning to tx_ndp_modulus is not sufficient because the next align call can be cdc_ncm_align_tail, which can add up to ctx->tx_modulus + ctx->tx_remainder - 1 bytes. This used to lead to occasional crashes on a Huawei 909s-120 LTE module as follows:

- the condition marked /* if there is a remaining skb [...] */ is true so the swaps happen
- skb_out is set from ctx->tx_curr_skb
- skb_out->len is exactly 0x3f52
- ctx->tx_curr_size is 0x4000 and delayed_ndp_size is 0xac (note that the sum of skb_out->len and delayed_ndp_size is 0x3ffe)
- the for loop over n is executed once
- the cdc_ncm_align_tail call marked /* align beginning of next frame */ increases skb_out->len to 0x3f56 (the sum is now 0x4002)
- the condition marked /* check if we had enough room left [...] */ is false so we break out of the loop
- the condition marked /* If requested, put NDP at end of frame. */ is true so the NDP is written into skb_out
- now skb_out->len is 0x4002, so padding_count is minus two interpreted as an unsigned number, which is used as the length argument to memset, leading to a crash with various symptoms but usually including

Quoted 5 lines
Call Trace:
 <IRQ>
 cdc_ncm_fill_tx_frame+0x83a/0x970 [cdc_ncm]
 cdc_mbim_tx_fixup+0x1d9/0x240 [cdc_mbim]
 usbnet_start_xmit+0x5d/0x720 [usbnet]

The cdc_ncm_align_tail call first aligns on a ctx->tx_modulus boundary (adding at most ctx->tx_modulus-1 bytes), then adds ctx->tx_remainder bytes. Alternatively, the next alignment call can occur in cdc_ncm_ndp16 or cdc_ncm_ndp32, in which case at most ctx->tx_ndp_modulus-1 bytes are added.

A similar problem has occurred before, and the code is nontrivial to reason about, so add a guard before the crashing call. By that time it is too late to prevent any memory corruption (we'll have written past the end of the buffer already) but we can at least try to get a warning written into an on-disk log by avoiding the hard crash caused by padding past the buffer with a huge number of zeros.

---
 drivers/net/usb/cdc_ncm.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/net/usb/cdc_ncm.c +6 -2
@@ -1128,7 +1128,10 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev
 	 * accordingly. Otherwise, we should check here.
 	 */
 	if (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END)
-		delayed_ndp_size = ALIGN(ctx->max_ndp_size, ctx->tx_ndp_modulus);
+		delayed_ndp_size = ctx->max_ndp_size +
+			max_t(u32,
+			      ctx->tx_ndp_modulus,
+			      ctx->tx_modulus + ctx->tx_remainder) - 1;
 	else
 		delayed_ndp_size = 0;
 
@@ -1309,7 +1312,8 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev
 	if (!(dev->driver_info->flags & FLAG_SEND_ZLP) &&
 	    skb_out->len > ctx->min_tx_pkt) {
 		padding_count = ctx->tx_curr_size - skb_out->len;
-		skb_put_zero(skb_out, padding_count);
+		if (!WARN_ON(padding_count > ctx->tx_curr_size))
+			skb_put_zero(skb_out, padding_count);
 	} else if (skb_out->len < ctx->tx_curr_size &&
 		   (skb_out->len % dev->maxpacket) == 0) {
 		skb_put_u8(skb_out, 0);	/* force short packet */
author maintainer
#3 lore raw

PATCH 3/28 net: vlan: avoid leaks on register_vlan_dev() failures

In reply to Greg Kroah-Hartman

From: Jakub Kicinski <[email protected]>

[ Upstream commit 55b7ab1178cbf41f979ff83236d3321ad35ed2ad ]

VLAN checks for NETREG_UNINITIALIZED to distinguish between registration failure and unregistration in progress.

Since commit cb626bf566eb ("net-sysfs: Fix reference count leak") registration failure may, however, result in NETREG_UNREGISTERED as well as NETREG_UNINITIALIZED.

This fix is similer to cebb69754f37 ("rtnetlink: Fix memory(net_device) leak when ->newlink fails")

Fixes cb626bf566eb ("net-sysfs: Fix reference count leak")
---
 net/8021q/vlan.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
net/8021q/vlan.c +2 -1
@@ -272,7 +272,8 @@ static int register_vlan_device(struct n
 	return 0;
 
 out_free_newdev:
-	if (new_dev->reg_state == NETREG_UNINITIALIZED)
+	if (new_dev->reg_state == NETREG_UNINITIALIZED ||
+	    new_dev->reg_state == NETREG_UNREGISTERED)
 		free_netdev(new_dev);
 	return err;
 }
author maintainer
#4 lore raw

PATCH 4/28 net: ip: always refragment ip defragmented packets

In reply to Greg Kroah-Hartman

From: Florian Westphal <[email protected]>

[ Upstream commit bb4cc1a18856a73f0ff5137df0c2a31f4c50f6cf ]

Conntrack reassembly records the largest fragment size seen in IPCB. However, when this gets forwarded/transmitted, fragmentation will only be forced if one of the fragmented packets had the DF bit set.

In that case, a flag in IPCB will force fragmentation even if the MTU is large enough.

This should work fine, but this breaks with ip tunnels. Consider client that sends a UDP datagram of size X to another host.

The client fragments the datagram, so two packets, of size y and z, are sent. DF bit is not set on any of these packets.

Middlebox netfilter reassembles those packets back to single size-X packet, before routing decision.

packet-size-vs-mtu checks in ip_forward are irrelevant, because DF bit isn't set. At output time, ip refragmentation is skipped as well because x is still smaller than the mtu of the output device.

If ttransmit device is an ip tunnel, the packet size increases to x+overhead.

Also, tunnel might be configured to force DF bit on outer header.

In this case, packet will be dropped (exceeds MTU) and an ICMP error is generated back to sender.

But sender already respects the announced MTU, all the packets that it sent did fit the announced mtu.

Force refragmentation as per original sizes unconditionally so ip tunnel will encapsulate the fragments instead.

The only other solution I see is to place ip refragmentation in the ip_tunnel code to handle this case.

Fixes d6b915e29f4ad ("ip_fragment: don't forward defragmented DF packet")
---
 net/ipv4/ip_output.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/ip_output.c +1 -1
@@ -312,7 +312,7 @@ static int ip_finish_output(struct net *
 	if (skb_is_gso(skb))
 		return ip_finish_output_gso(net, sk, skb, mtu);
 
-	if (skb->len > mtu || (IPCB(skb)->flags & IPSKB_FRAG_PMTU))
+	if (skb->len > mtu || IPCB(skb)->frag_max_size)
 		return ip_fragment(net, sk, skb, mtu, ip_finish_output2);
 
 	return ip_finish_output2(net, sk, skb);
author maintainer
#5 lore raw

PATCH 5/28 net: fix pmtu check in nopmtudisc mode

In reply to Greg Kroah-Hartman

From: Florian Westphal <[email protected]>

[ Upstream commit 50c661670f6a3908c273503dfa206dfc7aa54c07 ]

For some reason ip_tunnel insist on setting the DF bit anyway when the inner header has the DF bit set, EVEN if the tunnel was configured with 'nopmtudisc'.

This means that the script added in the previous commit cannot be made to work by adding the 'nopmtudisc' flag to the ip tunnel configuration. Doing so breaks connectivity even for the without-conntrack/netfilter scenario.

When nopmtudisc is set, the tunnel will skip the mtu check, so no icmp error is sent to client. Then, because inner header has DF set, the outer header gets added with DF bit set as well.

IP stack then sends an error to itself because the packet exceeds the device MTU.

Fixes 23a3647bc4f93 ("ip_tunnels: Use skb-len to PMTU check.")
Cc Stefano Brivio <[email protected]>
---
 net/ipv4/ip_tunnel.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
net/ipv4/ip_tunnel.c +5 -5
@@ -752,7 +752,11 @@ void ip_tunnel_xmit(struct sk_buff *skb,
 		goto tx_error;
 	}
 
-	if (tnl_update_pmtu(dev, skb, rt, tnl_params->frag_off, inner_iph)) {
+	df = tnl_params->frag_off;
+	if (skb->protocol == htons(ETH_P_IP) && !tunnel->ignore_df)
+		df |= (inner_iph->frag_off & htons(IP_DF));
+
+	if (tnl_update_pmtu(dev, skb, rt, df, inner_iph)) {
 		ip_rt_put(rt);
 		goto tx_error;
 	}
@@ -780,10 +784,6 @@ void ip_tunnel_xmit(struct sk_buff *skb,
 			ttl = ip4_dst_hoplimit(&rt->dst);
 	}
 
-	df = tnl_params->frag_off;
-	if (skb->protocol == htons(ETH_P_IP) && !tunnel->ignore_df)
-		df |= (inner_iph->frag_off&htons(IP_DF));
-
 	max_headroom = LL_RESERVED_SPACE(rt->dst.dev) + sizeof(struct iphdr)
 			+ rt->dst.header_len + ip_encap_hlen(&tunnel->encap);
 	if (max_headroom > dev->needed_headroom)
author maintainer
#6 lore raw

PATCH 6/28 x86/resctrl: Use an IPI instead of task_work_add() to update PQR_ASSOC MSR

In reply to Greg Kroah-Hartman

From: Fenghua Yu <[email protected]>

commit ae28d1aae48a1258bd09a6f707ebb4231d79a761 upstream

Currently, when moving a task to a resource group the PQR_ASSOC MSR is updated with the new closid and rmid in an added task callback. If the task is running, the work is run as soon as possible. If the task is not running, the work is executed later in the kernel exit path when the kernel returns to the task again.

Updating the PQR_ASSOC MSR as soon as possible on the CPU a moved task is running is the right thing to do. Queueing work for a task that is not running is unnecessary (the PQR_ASSOC MSR is already updated when the task is scheduled in) and causing system resource waste with the way in which it is implemented: Work to update the PQR_ASSOC register is queued every time the user writes a task id to the "tasks" file, even if the task already belongs to the resource group.

This could result in multiple pending work items associated with a single task even if they are all identical and even though only a single update with most recent values is needed. Specifically, even if a task is moved between different resource groups while it is sleeping then it is only the last move that is relevant but yet a work item is queued during each move.

This unnecessary queueing of work items could result in significant system resource waste, especially on tasks sleeping for a long time. For example, as demonstrated by Shakeel Butt in [1] writing the same task id to the "tasks" file can quickly consume significant memory. The same problem (wasted system resources) occurs when moving a task between different resource groups.

As pointed out by Valentin Schneider in [2] there is an additional issue with the way in which the queueing of work is done in that the task_struct update is currently done after the work is queued, resulting in a race with the register update possibly done before the data needed by the update is available.

To solve these issues, update the PQR_ASSOC MSR in a synchronous way right after the new closid and rmid are ready during the task movement, only if the task is running. If a moved task is not running nothing is done since the PQR_ASSOC MSR will be updated next time the task is scheduled. This is the same way used to update the register when tasks are moved as part of resource group removal.

[1] https://lore.kernel.org/lkml/CALvZod7E9zzHwenzf7objzGKsdBmVwTgEJ0nPgs0LUFU3SN5Pw@mail.gmail.com/
[2] https://lore.kernel.org/lkml/[email protected]

[ bp: Massage commit message and drop the two update_task_closid_rmid()
variants. ]

Backporting notes:

Since upstream commit fa7d949337cc ("x86/resctrl: Rename and move rdt files to a separate directory"), the file arch/x86/kernel/cpu/intel_rdt_rdtgroup.c has been renamed and moved to arch/x86/kernel/cpu/resctrl/rdtgroup.c.
Apply the change against file arch/x86/kernel/cpu/intel_rdt_rdtgroup.c for older stable trees.

Since upstream commit 352940ececaca ("x86/resctrl: Rename the RDT functions and definitions"), resctrl functions received more generic names. Specifically related to this backport, intel_rdt_sched_in() was renamed to rescrl_sched_in().

---
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c |  105 ++++++++++++-------------------
 1 file changed, 42 insertions(+), 63 deletions(-)
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c +42 -63
@@ -411,82 +411,61 @@ static void rdtgroup_remove(struct rdtgr
 	kfree(rdtgrp);
 }
 
-struct task_move_callback {
-	struct callback_head	work;
-	struct rdtgroup		*rdtgrp;
-};
-
-static void move_myself(struct callback_head *head)
+static void _update_task_closid_rmid(void *task)
 {
-	struct task_move_callback *callback;
-	struct rdtgroup *rdtgrp;
-
-	callback = container_of(head, struct task_move_callback, work);
-	rdtgrp = callback->rdtgrp;
-
 	/*
-	 * If resource group was deleted before this task work callback
-	 * was invoked, then assign the task to root group and free the
-	 * resource group.
+	 * If the task is still current on this CPU, update PQR_ASSOC MSR.
+	 * Otherwise, the MSR is updated when the task is scheduled in.
 	 */
-	if (atomic_dec_and_test(&rdtgrp->waitcount) &&
-	    (rdtgrp->flags & RDT_DELETED)) {
-		current->closid = 0;
-		current->rmid = 0;
-		rdtgroup_remove(rdtgrp);
-	}
-
-	preempt_disable();
-	/* update PQR_ASSOC MSR to make resource group go into effect */
-	intel_rdt_sched_in();
-	preempt_enable();
+	if (task == current)
+		intel_rdt_sched_in();
+}
 
-	kfree(callback);
+static void update_task_closid_rmid(struct task_struct *t)
+{
+	if (IS_ENABLED(CONFIG_SMP) && task_curr(t))
+		smp_call_function_single(task_cpu(t), _update_task_closid_rmid, t, 1);
+	else
+		_update_task_closid_rmid(t);
 }
 
 static int __rdtgroup_move_task(struct task_struct *tsk,
 				struct rdtgroup *rdtgrp)
 {
-	struct task_move_callback *callback;
-	int ret;
-
-	callback = kzalloc(sizeof(*callback), GFP_KERNEL);
-	if (!callback)
-		return -ENOMEM;
-	callback->work.func = move_myself;
-	callback->rdtgrp = rdtgrp;
-
 	/*
-	 * Take a refcount, so rdtgrp cannot be freed before the
-	 * callback has been invoked.
+	 * Set the task's closid/rmid before the PQR_ASSOC MSR can be
+	 * updated by them.
+	 *
+	 * For ctrl_mon groups, move both closid and rmid.
+	 * For monitor groups, can move the tasks only from
+	 * their parent CTRL group.
 	 */
-	atomic_inc(&rdtgrp->waitcount);
-	ret = task_work_add(tsk, &callback->work, true);
-	if (ret) {
-		/*
-		 * Task is exiting. Drop the refcount and free the callback.
-		 * No need to check the refcount as the group cannot be
-		 * deleted before the write function unlocks rdtgroup_mutex.
-		 */
-		atomic_dec(&rdtgrp->waitcount);
-		kfree(callback);
-	} else {
-		/*
-		 * For ctrl_mon groups move both closid and rmid.
-		 * For monitor groups, can move the tasks only from
-		 * their parent CTRL group.
-		 */
-		if (rdtgrp->type == RDTCTRL_GROUP) {
-			tsk->closid = rdtgrp->closid;
+
+	if (rdtgrp->type == RDTCTRL_GROUP) {
+		tsk->closid = rdtgrp->closid;
+		tsk->rmid = rdtgrp->mon.rmid;
+	} else if (rdtgrp->type == RDTMON_GROUP) {
+		if (rdtgrp->mon.parent->closid == tsk->closid)
 			tsk->rmid = rdtgrp->mon.rmid;
-		} else if (rdtgrp->type == RDTMON_GROUP) {
-			if (rdtgrp->mon.parent->closid == tsk->closid)
-				tsk->rmid = rdtgrp->mon.rmid;
-			else
-				ret = -EINVAL;
-		}
+		else
+			return -EINVAL;
 	}
-	return ret;
+
+	/*
+	 * Ensure the task's closid and rmid are written before determining if
+	 * the task is current that will decide if it will be interrupted.
+	 */
+	barrier();
+
+	/*
+	 * By now, the task's closid and rmid are set. If the task is current
+	 * on a CPU, the PQR_ASSOC MSR needs to be updated to make the resource
+	 * group go into effect. If the task is not current, the MSR will be
+	 * updated when the task is scheduled in.
+	 */
+	update_task_closid_rmid(tsk);
+
+	return 0;
 }
 
 static int rdtgroup_task_write_permission(struct task_struct *task,
author maintainer
#7 lore raw

PATCH 7/28 x86/resctrl: Dont move a task to the same resource group

In reply to Greg Kroah-Hartman

From: Fenghua Yu <[email protected]>

commit a0195f314a25582b38993bf30db11c300f4f4611 upstream

Shakeel Butt reported in [1] that a user can request a task to be moved to a resource group even if the task is already in the group. It just wastes time to do the move operation which could be costly to send IPI to a different CPU.

Add a sanity check to ensure that the move operation only happens when the task is not already in the resource group.

[1] https://lore.kernel.org/lkml/CALvZod7E9zzHwenzf7objzGKsdBmVwTgEJ0nPgs0LUFU3SN5Pw@mail.gmail.com/

Backporting notes:

Since upstream commit fa7d949337cc ("x86/resctrl: Rename and move rdt files to a separate directory"), the file arch/x86/kernel/cpu/intel_rdt_rdtgroup.c has been renamed and moved to arch/x86/kernel/cpu/resctrl/rdtgroup.c.
Apply the change against file arch/x86/kernel/cpu/intel_rdt_rdtgroup.c for older stable trees.

---
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c |    7 +++++++
 1 file changed, 7 insertions(+)
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c +7 -0
@@ -432,6 +432,13 @@ static void update_task_closid_rmid(stru
 static int __rdtgroup_move_task(struct task_struct *tsk,
 				struct rdtgroup *rdtgrp)
 {
+	/* If the task is already in rdtgrp, no need to move the task. */
+	if ((rdtgrp->type == RDTCTRL_GROUP && tsk->closid == rdtgrp->closid &&
+	     tsk->rmid == rdtgrp->mon.rmid) ||
+	    (rdtgrp->type == RDTMON_GROUP && tsk->rmid == rdtgrp->mon.rmid &&
+	     tsk->closid == rdtgrp->mon.parent->closid))
+		return 0;
+
 	/*
 	 * Set the task's closid/rmid before the PQR_ASSOC MSR can be
 	 * updated by them.
author maintainer
#8 lore raw

PATCH 8/28 vmlinux.lds.h: Add PGO and AutoFDO input sections

In reply to Greg Kroah-Hartman

From: Nick Desaulniers <[email protected]>

commit eff8728fe69880d3f7983bec3fb6cea4c306261f upstream.

Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too.

When compiling with profiling information (collected via PGO instrumentations or AutoFDO sampling), Clang will separate code into .text.hot, .text.unlikely, or .text.unknown sections based on profiling information. After D79600 (clang-11), these sections will have a trailing . suffix, ie. .text.hot., .text.unlikely., .text.unknown..

When using -ffunction-sections together with profiling infomation, either explicitly (FGKASLR) or implicitly (LTO), code may be placed in sections following the convention:
.text.hot.<foo>, .text.unlikely.<bar>, .text.unknown.<baz> where <foo>, <bar>, and <baz> are functions. (This produces one section per function; we generally try to merge these all back via linker script so that we don't have 50k sections).

For the above cases, we need to teach our linker scripts that such sections might exist and that we'd explicitly like them grouped together, otherwise we can wind up with code outside of the _stext/_etext boundaries that might not be mapped properly for some architectures, resulting in boot failures.

If the linker script is not told about possible input sections, then where the section is placed as output is a heuristic-laiden mess that's non-portable between linkers (ie. BFD and LLD), and has resulted in many hard to debug bugs. Kees Cook is working on cleaning this up by adding --orphan-handling=warn linker flag used in ARCH=powerpc to additional architectures. In the case of linker scripts, borrowing from the Zen of
Python: explicit is better than implicit.

Also, ld.bfd's internal linker script considers .text.hot AND .text.hot.* to be part of .text, as well as .text.unlikely and .text.unlikely.*. I didn't see support for .text.unknown.*, and didn't see Clang producing such code in our kernel builds, but I see code in LLVM that can produce such section names if profiling information is missing. That may point to a larger issue with generating or collecting profiles, but I would much rather be safe and explicit than have to debug yet another issue related to orphan section placement.

[nc: Resolve small conflict due to lack of NOINSTR_TEXT]
---
 include/asm-generic/vmlinux.lds.h |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
include/asm-generic/vmlinux.lds.h +4 -1
@@ -459,7 +459,10 @@
  */
 #define TEXT_TEXT							\
 		ALIGN_FUNCTION();					\
-		*(.text.hot TEXT_MAIN .text.fixup .text.unlikely)	\
+		*(.text.hot .text.hot.*)				\
+		*(TEXT_MAIN .text.fixup)				\
+		*(.text.unlikely .text.unlikely.*)			\
+		*(.text.unknown .text.unknown.*)			\
 		*(.text..refcount)					\
 		*(.ref.text)						\
 	MEM_KEEP(init.text)						\
author maintainer
#9 lore raw

PATCH 9/28 drm/i915: Fix mismatch between misplaced vma check and vma insert

In reply to Greg Kroah-Hartman

From: Chris Wilson <[email protected]>

commit 0e53656ad8abc99e0a80c3de611e593ebbf55829 upstream

When inserting a VMA, we restrict the placement to the low 4G unless the caller opts into using the full range. This was done to allow usersapce the opportunity to transition slowly from a 32b address space, and to avoid breaking inherent 32b assumptions of some commands.

However, for insert we limited ourselves to 4G-4K, but on verification we allowed the full 4G. This causes some attempts to bind a new buffer to sporadically fail with -ENOSPC, but at other times be bound successfully.

commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page") suggests that there is a genuine problem with stateless addressing that cannot utilize the last page in 4G and so we purposefully excluded it. This means that the quick pin pass may cause us to utilize a buggy placement.

Testcase: igt/gem_exec_params/larger-than-life-batch

Fixes 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
Cc CQ Tang <[email protected]>
Cc <[email protected]> # v4.5+
(cherry picked from commit 5f22cc0b134ab702d7f64b714e26018f7288ffee)
[sudip: use file from old path]
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_gem_execbuffer.c +1 -1
@@ -341,7 +341,7 @@ eb_vma_misplaced(const struct drm_i915_g
 		return true;
 
 	if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
-	    (vma->node.start + vma->node.size - 1) >> 32)
+	    (vma->node.start + vma->node.size + 4095) >> 32)
 		return true;
 
 	if (flags & __EXEC_OBJECT_NEEDS_MAP &&
author maintainer
#10 lore raw

PATCH 10/28 ubifs: wbuf: Dont leak kernel memory to flash

In reply to Greg Kroah-Hartman

From: Richard Weinberger <[email protected]>

commit 20f1431160c6b590cdc269a846fc5a448abf5b98 upstream

Write buffers use a kmalloc()'ed buffer, they can leak up to seven bytes of kernel memory to flash if writes are not aligned.
So use ubifs_pad() to fill these gaps with padding bytes. This was never a problem while scanning because the scanner logic manually aligns node lengths and skips over these gaps.

Fixes 1e51764a3c2ac05a2 ("UBIFS: add new flash file system")
[sudip: adjust context]
---
 fs/ubifs/io.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
fs/ubifs/io.c +11 -2
@@ -331,7 +331,7 @@ void ubifs_pad(const struct ubifs_info *
 {
 	uint32_t crc;
 
-	ubifs_assert(pad >= 0 && !(pad & 7));
+	ubifs_assert(pad >= 0);
 
 	if (pad >= UBIFS_PAD_NODE_SZ) {
 		struct ubifs_ch *ch = buf;
@@ -727,6 +727,10 @@ int ubifs_wbuf_write_nolock(struct ubifs
 		 * write-buffer.
 		 */
 		memcpy(wbuf->buf + wbuf->used, buf, len);
+		if (aligned_len > len) {
+			ubifs_assert(aligned_len - len < 8);
+			ubifs_pad(c, wbuf->buf + wbuf->used + len, aligned_len - len);
+		}
 
 		if (aligned_len == wbuf->avail) {
 			dbg_io("flush jhead %s wbuf to LEB %d:%d",
@@ -819,13 +823,18 @@ int ubifs_wbuf_write_nolock(struct ubifs
 	}
 
 	spin_lock(&wbuf->lock);
-	if (aligned_len)
+	if (aligned_len) {
 		/*
 		 * And now we have what's left and what does not take whole
 		 * max. write unit, so write it to the write-buffer and we are
 		 * done.
 		 */
 		memcpy(wbuf->buf, buf + written, len);
+		if (aligned_len > len) {
+			ubifs_assert(aligned_len - len < 8);
+			ubifs_pad(c, wbuf->buf + len, aligned_len - len);
+		}
+	}
 
 	if (c->leb_size - wbuf->offs >= c->max_write_size)
 		wbuf->size = c->max_write_size;
author maintainer
#11 lore raw

PATCH 11/28 spi: pxa2xx: Fix use-after-free on unbind

In reply to Greg Kroah-Hartman

From: Lukas Wunner <[email protected]>

commit 5626308bb94d9f930aa5f7c77327df4c6daa7759 upstream

pxa2xx_spi_remove() accesses the driver's private data after calling spi_unregister_controller() even though that function releases the last reference on the spi_controller and thereby frees the private data.

Fix by switching over to the new devm_spi_alloc_master/slave() helper which keeps the private data accessible until the driver has unbound.

Fixes 32e5b57232c0 ("spi: pxa2xx: Fix controller unregister order")
Cc <[email protected]> # v2.6.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
Cc <[email protected]> # v2.6.17+: 32e5b57232c0: spi: pxa2xx: Fix controller unregister order
Cc <[email protected]> # v2.6.17+
[sudip: adjust context]
---
 drivers/spi/spi-pxa2xx.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/spi/spi-pxa2xx.c +1 -2
@@ -1660,7 +1660,7 @@ static int pxa2xx_spi_probe(struct platf
 		return -ENODEV;
 	}
 
-	master = spi_alloc_master(dev, sizeof(struct driver_data));
+	master = devm_spi_alloc_master(dev, sizeof(*drv_data));
 	if (!master) {
 		dev_err(&pdev->dev, "cannot alloc spi_master\n");
 		pxa_ssp_free(ssp);
@@ -1841,7 +1841,6 @@ out_error_clock_enabled:
 	free_irq(ssp->irq, drv_data);
 
 out_error_master_alloc:
-	spi_master_put(master);
 	pxa_ssp_free(ssp);
 	return status;
 }
author maintainer
#12 lore raw

PATCH 12/28 iio: imu: st_lsm6dsx: flip irq return logic

In reply to Greg Kroah-Hartman

From: Sean Nyekjaer <[email protected]>

commit ec76d918f23034f9f662539ca9c64e2ae3ba9fba upstream

No need for using reverse logic in the irq return, fix this by flip things around.

---
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c +1 -1
@@ -401,7 +401,7 @@ static irqreturn_t st_lsm6dsx_handler_th
 	count = st_lsm6dsx_read_fifo(hw);
 	mutex_unlock(&hw->fifo_lock);
 
-	return !count ? IRQ_NONE : IRQ_HANDLED;
+	return count ? IRQ_HANDLED : IRQ_NONE;
 }
 
 static int st_lsm6dsx_buffer_preenable(struct iio_dev *iio_dev)
author maintainer
#13 lore raw

PATCH 13/28 iio: imu: st_lsm6dsx: fix edge-trigger interrupts

In reply to Greg Kroah-Hartman

From: Lorenzo Bianconi <[email protected]>

commit 3f9bce7a22a3f8ac9d885c9d75bc45569f24ac8b upstream

If we are using edge IRQs, new samples can arrive while processing current interrupt since there are no hw guarantees the irq line stays "low" long enough to properly detect the new interrupt. In this case the new sample will be missed.
Polling FIFO status register in st_lsm6dsx_handler_thread routine allow us to read new samples even if the interrupt arrives while processing previous data and the timeslot where the line is "low" is too short to be properly detected.

Fixes 89ca88a7cdf2 ("iio: imu: st_lsm6dsx: support active-low interrupts")
Fixes 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver")
[sudip: manual backport to old irq handler path]
---
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c |   26 ++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c +21 -5
@@ -395,13 +395,29 @@ static irqreturn_t st_lsm6dsx_handler_ir
 static irqreturn_t st_lsm6dsx_handler_thread(int irq, void *private)
 {
 	struct st_lsm6dsx_hw *hw = private;
-	int count;
+	int fifo_len = 0, len;
 
-	mutex_lock(&hw->fifo_lock);
-	count = st_lsm6dsx_read_fifo(hw);
-	mutex_unlock(&hw->fifo_lock);
+	/*
+	 * If we are using edge IRQs, new samples can arrive while
+	 * processing current interrupt since there are no hw
+	 * guarantees the irq line stays "low" long enough to properly
+	 * detect the new interrupt. In this case the new sample will
+	 * be missed.
+	 * Polling FIFO status register allow us to read new
+	 * samples even if the interrupt arrives while processing
+	 * previous data and the timeslot where the line is "low" is
+	 * too short to be properly detected.
+	 */
+	do {
+		mutex_lock(&hw->fifo_lock);
+		len = st_lsm6dsx_read_fifo(hw);
+		mutex_unlock(&hw->fifo_lock);
 
-	return count ? IRQ_HANDLED : IRQ_NONE;
+		if (len > 0)
+			fifo_len += len;
+	} while (len > 0);
+
+	return fifo_len ? IRQ_HANDLED : IRQ_NONE;
 }
 
 static int st_lsm6dsx_buffer_preenable(struct iio_dev *iio_dev)
author maintainer
#14 lore raw

PATCH 14/28 ARM: OMAP2+: omap_device: fix idling of devices during probe

In reply to Greg Kroah-Hartman

From: Andreas Kemnade <[email protected]>

commit ec76c2eea903947202098090bbe07a739b5246e9 upstream.

On the GTA04A5 od->_driver_status was not set to BUS_NOTIFY_BIND_DRIVER during probe of the second mmc used for wifi. Therefore omap_device_late_idle idled the device during probing causing oopses when accessing the registers.

It was not set because od->_state was set to OMAP_DEVICE_STATE_IDLE in the notifier callback. Therefore set od->_driver_status also in that case.

This came apparent after commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4") causing this oops:

omap_hsmmc 480b4000.mmc: omap_device_late_idle: enabled but no driver. Idling 8<--- cut here ---
Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0b402c
...
(omap_hsmmc_set_bus_width) from [<c07996bc>] (omap_hsmmc_set_ios+0x11c/0x258) (omap_hsmmc_set_ios) from [<c077b2b0>] (mmc_power_up.part.8+0x3c/0xd0) (mmc_power_up.part.8) from [<c077c14c>] (mmc_start_host+0x88/0x9c) (mmc_start_host) from [<c077d284>] (mmc_add_host+0x58/0x84) (mmc_add_host) from [<c0799190>] (omap_hsmmc_probe+0x5fc/0x8c0) (omap_hsmmc_probe) from [<c0666728>] (platform_drv_probe+0x48/0x98) (platform_drv_probe) from [<c066457c>] (really_probe+0x1dc/0x3b4)

Fixes 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer")
Fixes 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
[[email protected]: left out extra parens, trimmed description stack trace]
---
 arch/arm/mach-omap2/omap_device.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
arch/arm/mach-omap2/omap_device.c +5 -3
@@ -224,10 +224,12 @@ static int _omap_device_notifier_call(st
 		break;
 	case BUS_NOTIFY_BIND_DRIVER:
 		od = to_omap_device(pdev);
-		if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED) &&
-		    pm_runtime_status_suspended(dev)) {
+		if (od) {
 			od->_driver_status = BUS_NOTIFY_BIND_DRIVER;
-			pm_runtime_set_active(dev);
+			if (od->_state == OMAP_DEVICE_STATE_ENABLED &&
+			    pm_runtime_status_suspended(dev)) {
+				pm_runtime_set_active(dev);
+			}
 		}
 		break;
 	case BUS_NOTIFY_ADD_DEVICE:
author maintainer
#15 lore raw

PATCH 15/28 i2c: sprd: use a specific timeout to avoid system hang up issue

In reply to Greg Kroah-Hartman

From: Chunyan Zhang <[email protected]>

commit 0b884fe71f9ee6a5df35e677154256ea2099ebb8 upstream.

If the i2c device SCL bus being pulled up due to some exception before message transfer done, the system cannot receive the completing interrupt signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOUT jiffies eclipse, that would make the system seemed hang up. To avoid that happen, this patch adds a specific timeout for message transfer.

Fixes 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver")
[wsa: changed errno to ETIMEDOUT]
---
 drivers/i2c/busses/i2c-sprd.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/i2c/busses/i2c-sprd.c +7 -1
@@ -71,6 +71,8 @@
 
 /* timeout (ms) for pm runtime autosuspend */
 #define SPRD_I2C_PM_TIMEOUT	1000
+/* timeout (ms) for transfer message */
+#define I2C_XFER_TIMEOUT	1000
 
 /* SPRD i2c data structure */
 struct sprd_i2c {
@@ -244,6 +246,7 @@ static int sprd_i2c_handle_msg(struct i2
 			       struct i2c_msg *msg, bool is_last_msg)
 {
 	struct sprd_i2c *i2c_dev = i2c_adap->algo_data;
+	unsigned long time_left;
 
 	i2c_dev->msg = msg;
 	i2c_dev->buf = msg->buf;
@@ -273,7 +276,10 @@ static int sprd_i2c_handle_msg(struct i2
 
 	sprd_i2c_opt_start(i2c_dev);
 
-	wait_for_completion(&i2c_dev->complete);
+	time_left = wait_for_completion_timeout(&i2c_dev->complete,
+				msecs_to_jiffies(I2C_XFER_TIMEOUT));
+	if (!time_left)
+		return -ETIMEDOUT;
 
 	return i2c_dev->err;
 }
author maintainer
#16 lore raw

PATCH 16/28 cpufreq: powernow-k8: pass policy rather than use cpufreq_cpu_get()

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

commit 943bdd0cecad06da8392a33093230e30e501eccc upstream.

Currently there is an unlikely case where cpufreq_cpu_get() returns a NULL policy and this will cause a NULL pointer dereference later on.

Fix this by passing the policy to transition_frequency_fidvid() from the caller and hence eliminating the need for the cpufreq_cpu_get() and cpufreq_cpu_put().

Thanks to Viresh Kumar for suggesting the fix.

Addresses-Coverity: ("Dereference null return")

Fixes b43a7ffbf33b ("cpufreq: Notify all policy->cpus in cpufreq_notify_transition()")
---
 drivers/cpufreq/powernow-k8.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/cpufreq/powernow-k8.c +3 -6
@@ -887,9 +887,9 @@ static int get_transition_latency(struct
 
 /* Take a frequency, and issue the fid/vid transition command */
 static int transition_frequency_fidvid(struct powernow_k8_data *data,
-		unsigned int index)
+		unsigned int index,
+		struct cpufreq_policy *policy)
 {
-	struct cpufreq_policy *policy;
 	u32 fid = 0;
 	u32 vid = 0;
 	int res;
@@ -921,9 +921,6 @@ static int transition_frequency_fidvid(s
 	freqs.old = find_khz_freq_from_fid(data->currfid);
 	freqs.new = find_khz_freq_from_fid(fid);
 
-	policy = cpufreq_cpu_get(smp_processor_id());
-	cpufreq_cpu_put(policy);
-
 	cpufreq_freq_transition_begin(policy, &freqs);
 	res = transition_fid_vid(data, fid, vid);
 	cpufreq_freq_transition_end(policy, &freqs, res);
@@ -978,7 +975,7 @@ static long powernowk8_target_fn(void *a
 
 	powernow_k8_acpi_pst_values(data, newstate);
 
-	ret = transition_frequency_fidvid(data, newstate);
+	ret = transition_frequency_fidvid(data, newstate, pol);
 
 	if (ret) {
 		pr_err("transition frequency failed\n");
author maintainer
#17 lore raw

PATCH 17/28 spi: stm32: FIFO threshold level - fix align packet size

In reply to Greg Kroah-Hartman

From: Roman Guskov <[email protected]>

commit a590370d918fc66c62df6620445791fbe840344a upstream.

if cur_bpw <= 8 and xfer_len < 4 then the value of fthlv will be 1 and SPI registers content may have been lost.

* If SPI data register is accessed as a 16-bit register and DSIZE <= 8bit, better to select FTHLV = 2, 4, 6 etc

* If SPI data register is accessed as a 32-bit register and DSIZE > 8bit, better to select FTHLV = 2, 4, 6 etc, while if DSIZE <= 8bit, better to select FTHLV = 4, 8, 12 etc

---
 drivers/spi/spi-stm32.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/spi/spi-stm32.c +2 -2
@@ -299,9 +299,9 @@ static u32 stm32_spi_prepare_fthlv(struc
 
 	/* align packet size with data registers access */
 	if (spi->cur_bpw > 8)
-		fthlv -= (fthlv % 2); /* multiple of 2 */
+		fthlv += (fthlv % 2) ? 1 : 0;
 	else
-		fthlv -= (fthlv % 4); /* multiple of 4 */
+		fthlv += (fthlv % 4) ? (4 - (fthlv % 4)) : 0;
 
 	return fthlv;
 }
author maintainer
#18 lore raw

PATCH 18/28 dmaengine: xilinx_dma: check dma_async_device_register return value

In reply to Greg Kroah-Hartman

From: Shravya Kumbham <[email protected]>

commit 99974aedbd73523969afb09f33c6e3047cd0ddae upstream.

dma_async_device_register() can return non-zero error code. Add condition to check the return value of dma_async_device_register function and handle the error path.

Addresses-Coverity: Event check_return.

Fixes 9cd4360de609 ("dma: Add Xilinx AXI Video Direct Memory Access Engine driver support")
---
 drivers/dma/xilinx/xilinx_dma.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/dma/xilinx/xilinx_dma.c +5 -1
@@ -2637,7 +2637,11 @@ static int xilinx_dma_probe(struct platf
 	}
 
 	/* Register the DMA engine with the core */
-	dma_async_device_register(&xdev->common);
+	err = dma_async_device_register(&xdev->common);
+	if (err) {
+		dev_err(xdev->dev, "failed to register the dma device\n");
+		goto error;
+	}
 
 	err = of_dma_controller_register(node, of_dma_xilinx_xlate,
 					 xdev);
author maintainer
#19 lore raw

PATCH 19/28 dmaengine: xilinx_dma: fix mixed_enum_type coverity warning

In reply to Greg Kroah-Hartman

From: Shravya Kumbham <[email protected]>

commit 2d5efea64472469117dc1a9a39530069e95b21e9 upstream.

Typecast the fls(width -1) with (enum dmaengine_alignment) in xilinx_dma_chan_probe function to fix the coverity warning.

Addresses-Coverity: Event mixed_enum_type.

Fixes 9cd4360de609 ("dma: Add Xilinx AXI Video Direct Memory Access Engine driver support")
---
 drivers/dma/xilinx/xilinx_dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dma/xilinx/xilinx_dma.c +1 -1
@@ -2360,7 +2360,7 @@ static int xilinx_dma_chan_probe(struct
 		has_dre = false;
 
 	if (!has_dre)
-		xdev->common.copy_align = fls(width - 1);
+		xdev->common.copy_align = (enum dmaengine_alignment)fls(width - 1);
 
 	if (of_device_is_compatible(node, "xlnx,axi-vdma-mm2s-channel") ||
 	    of_device_is_compatible(node, "xlnx,axi-dma-mm2s-channel") ||
author maintainer
#20 lore raw

PATCH 20/28 wil6210: select CONFIG_CRC32

In reply to Greg Kroah-Hartman

From: Arnd Bergmann <[email protected]>

commit e186620d7bf11b274b985b839c38266d7918cc05 upstream.

Without crc32, the driver fails to link:

arm-linux-gnueabi-ld: drivers/net/wireless/ath/wil6210/fw.o: in function `wil_fw_verify':
fw.c:(.text+0x74c): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/wireless/ath/wil6210/fw.o:fw.c:(.text+0x758): more undefined references to `crc32_le' follow

Fixes 151a9706503f ("wil6210: firmware download")
---
 drivers/net/wireless/ath/wil6210/Kconfig |    1 +
 1 file changed, 1 insertion(+)
drivers/net/wireless/ath/wil6210/Kconfig +1 -0
@@ -1,6 +1,7 @@
 config WIL6210
 	tristate "Wilocity 60g WiFi card wil6210 support"
 	select WANT_DEV_COREDUMP
+	select CRC32
 	depends on CFG80211
 	depends on PCI
 	default n
author maintainer
#21 lore raw

PATCH 21/28 block: rsxx: select CONFIG_CRC32

In reply to Greg Kroah-Hartman

From: Arnd Bergmann <[email protected]>

commit 36a106a4c1c100d55ba3d32a21ef748cfcd4fa99 upstream.

Without crc32, the driver fails to link:

arm-linux-gnueabi-ld: drivers/block/rsxx/config.o: in function `rsxx_load_config':
config.c:(.text+0x124): undefined reference to `crc32_le'

Fixes 8722ff8cdbfa ("block: IBM RamSan 70/80 device driver")
---
 drivers/block/Kconfig |    1 +
 1 file changed, 1 insertion(+)
drivers/block/Kconfig +1 -0
@@ -477,6 +477,7 @@ config BLK_DEV_RBD
 config BLK_DEV_RSXX
 	tristate "IBM Flash Adapter 900GB Full Height PCIe Device Driver"
 	depends on PCI
+	select CRC32
 	help
 	  Device driver for IBM's high speed PCIe SSD
 	  storage device: Flash Adapter 900GB Full Height.
author maintainer
#22 lore raw

PATCH 22/28 iommu/intel: Fix memleak in intel_irq_remapping_alloc

In reply to Greg Kroah-Hartman

From: Dinghao Liu <[email protected]>

commit ff2b46d7cff80d27d82f7f3252711f4ca1666129 upstream.

When irq_domain_get_irq_data() or irqd_cfg() fails at i == 0, data allocated by kzalloc() has not been freed before returning, which leads to memleak.

Fixes b106ee63abcc ("irq_remapping/vt-d: Enhance Intel IR driver to support hierarchical irqdomains")
---
 drivers/iommu/intel_irq_remapping.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/iommu/intel_irq_remapping.c +2 -0
@@ -1367,6 +1367,8 @@ static int intel_irq_remapping_alloc(str
 		irq_data = irq_domain_get_irq_data(domain, virq + i);
 		irq_cfg = irqd_cfg(irq_data);
 		if (!irq_data || !irq_cfg) {
+			if (!i)
+				kfree(data);
 			ret = -EINVAL;
 			goto out_free_data;
 		}
author maintainer
#23 lore raw

PATCH 23/28 net/mlx5e: Fix memleak in mlx5e_create_l2_table_groups

In reply to Greg Kroah-Hartman

From: Dinghao Liu <[email protected]>

commit 5b0bb12c58ac7d22e05b5bfdaa30a116c8c32e32 upstream.

When mlx5_create_flow_group() fails, ft->g should be freed just like when kvzalloc() fails. The caller of mlx5e_create_l2_table_groups() does not catch this issue on failure, which leads to memleak.

Fixes 33cfaaa8f36f ("net/mlx5e: Split the main flow steering table")
---
 drivers/net/ethernet/mellanox/mlx5/core/en_fs.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/ethernet/mellanox/mlx5/core/en_fs.c +1 -0
@@ -1226,6 +1226,7 @@ err_destroy_groups:
 	ft->g[ft->num_groups] = NULL;
 	mlx5e_destroy_groups(ft);
 	kvfree(in);
+	kfree(ft->g);
 
 	return err;
 }
author maintainer
#24 lore raw

PATCH 24/28 net/mlx5e: Fix two double free cases

In reply to Greg Kroah-Hartman

From: Dinghao Liu <[email protected]>

commit 7a6eb072a9548492ead086f3e820e9aac71c7138 upstream.

mlx5e_create_ttc_table_groups() frees ft->g on failure of kvzalloc(), but such failure will be caught by its caller in mlx5e_create_ttc_table() and ft->g will be freed again in mlx5e_destroy_flow_table(). The same issue also occurs in mlx5e_create_ttc_table_groups(). Set ft->g to NULL after kfree() to avoid double free.

Fixes 7b3722fa9ef6 ("net/mlx5e: Support RSS for GRE tunneled packets")
Fixes 33cfaaa8f36f ("net/mlx5e: Split the main flow steering table")
---
 drivers/net/ethernet/mellanox/mlx5/core/en_fs.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/en_fs.c +2 -0
@@ -961,6 +961,7 @@ static int mlx5e_create_inner_ttc_table_
 	in = kvzalloc(inlen, GFP_KERNEL);
 	if (!in) {
 		kfree(ft->g);
+		ft->g = NULL;
 		return -ENOMEM;
 	}
 
@@ -1181,6 +1182,7 @@ static int mlx5e_create_l2_table_groups(
 	in = kvzalloc(inlen, GFP_KERNEL);
 	if (!in) {
 		kfree(ft->g);
+		ft->g = NULL;
 		return -ENOMEM;
 	}
 
author maintainer
#25 lore raw

PATCH 25/28 wan: ds26522: select CONFIG_BITREVERSE

In reply to Greg Kroah-Hartman

From: Arnd Bergmann <[email protected]>

commit 69931e11288520c250152180ecf9b6ac5e6e40ed upstream.

Without this, the driver runs into a link failure

arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_ds26522_probe':
slic_ds26522.c:(.text+0x100c): undefined reference to `byte_rev_table'
arm-linux-gnueabi-ld: slic_ds26522.c:(.text+0x1cdc): undefined reference to `byte_rev_table'
arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_write':
slic_ds26522.c:(.text+0x1e4c): undefined reference to `byte_rev_table'

Fixes c37d4a0085c5 ("Maxim/driver: Add driver for maxim ds26522")
---
 drivers/net/wan/Kconfig |    1 +
 1 file changed, 1 insertion(+)
drivers/net/wan/Kconfig +1 -0
@@ -295,6 +295,7 @@ config SLIC_DS26522
 	tristate "Slic Maxim ds26522 card support"
 	depends on SPI
 	depends on FSL_SOC || ARCH_MXC || ARCH_LAYERSCAPE || COMPILE_TEST
+	select BITREVERSE
 	help
 	  This module initializes and configures the slic maxim card
 	  in T1 or E1 mode.
author maintainer
#26 lore raw

PATCH 26/28 KVM: arm64: Dont access PMCR_EL0 when no PMU is available

In reply to Greg Kroah-Hartman

From: Marc Zyngier <[email protected]>

commit 2a5f1b67ec577fb1544b563086e0377f095f88e2 upstream.

We reset the guest's view of PMCR_EL0 unconditionally, based on the host's view of this register. It is however legal for an implementation not to provide any PMU, resulting in an UNDEF.

The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!

It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.

Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCR register")
---
 arch/arm64/kvm/sys_regs.c |    4 ++++
 1 file changed, 4 insertions(+)
arch/arm64/kvm/sys_regs.c +4 -0
@@ -470,6 +470,10 @@ static void reset_pmcr(struct kvm_vcpu *
 {
 	u64 pmcr, val;
 
+	/* No PMU available, PMCR_EL0 may UNDEF... */
+	if (!kvm_arm_support_pmu_v3())
+		return;
+
 	pmcr = read_sysreg(pmcr_el0);
 	/*
 	 * Writable bits of PMCR_EL0 (ARMV8_PMU_PMCR_MASK) are reset to UNKNOWN
author maintainer
#27 lore raw

PATCH 27/28 block: fix use-after-free in disk_part_iter_next

In reply to Greg Kroah-Hartman

From: Ming Lei <[email protected]>

commit aebf5db917055b38f4945ed6d621d9f07a44ff30 upstream.

Make sure that bdgrab() is done on the 'block_device' instance before referring to it for avoiding use-after-free.

---
 block/genhd.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
block/genhd.c +6 -3
@@ -208,14 +208,17 @@ struct hd_struct *disk_part_iter_next(st
 		part = rcu_dereference(ptbl->part[piter->idx]);
 		if (!part)
 			continue;
+		get_device(part_to_dev(part));
+		piter->part = part;
 		if (!part_nr_sects_read(part) &&
 		    !(piter->flags & DISK_PITER_INCL_EMPTY) &&
 		    !(piter->flags & DISK_PITER_INCL_EMPTY_PART0 &&
-		      piter->idx == 0))
+		      piter->idx == 0)) {
+			put_device(part_to_dev(part));
+			piter->part = NULL;
 			continue;
+		}
 
-		get_device(part_to_dev(part));
-		piter->part = part;
 		piter->idx += inc;
 		break;
 	}
author maintainer
#28 lore raw

PATCH 28/28 net: drop bogus skb with CHECKSUM_PARTIAL and offset beyond end of trimmed packet

In reply to Greg Kroah-Hartman

From: Vasily Averin <[email protected]>

commit 54970a2fbb673f090b7f02d7f57b10b2e0707155 upstream.

syzbot reproduces BUG_ON in skb_checksum_help():
tun creates (bogus) skb with huge partial-checksummed area and small ip packet inside. Then ip_rcv trims the skb based on size of internal ip packet, after that csum offset points beyond of trimmed skb. Then checksum_tg() called via netfilter hook triggers BUG_ON:

        offset = skb_checksum_start_offset(skb);
        BUG_ON(offset >= skb_headlen(skb));

To work around the problem this patch forces pskb_trim_rcsum_slow() to return -EINVAL in described scenario. It allows its callers to drop such kind of packets.

---
 net/core/skbuff.c |    6 ++++++
 1 file changed, 6 insertions(+)
net/core/skbuff.c +6 -0
@@ -1850,6 +1850,12 @@ int pskb_trim_rcsum_slow(struct sk_buff
 		skb->csum = csum_block_sub(skb->csum,
 					   skb_checksum(skb, len, delta, 0),
 					   len);
+	} else if (skb->ip_summed == CHECKSUM_PARTIAL) {
+		int hdlen = (len > skb_headlen(skb)) ? skb_headlen(skb) : len;
+		int offset = skb_checksum_start_offset(skb) + skb->csum_offset;
+
+		if (offset + sizeof(__sum16) > hdlen)
+			return -EINVAL;
 	}
 	return __pskb_trim(skb, len);
 }
maintainer Tested-by on the v1 series
#29 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.216 release. There are 28 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 Sun, 17 Jan 2021 12:19:42 +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/v4.x/stable-review/patch-4.14.216-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.

thanks,

greg k-h

All tests passing for Tegra ...

Test results for stable-v4.14:

    8 builds:	8 pass, 0 fail
    16 boots:	16 pass, 0 fail
    30 tests:	30 pass, 0 fail

Linux version: 4.14.216-rc1-g4cfcf012355f
Boards tested: tegra124-jetson-tk1, tegra20-ventana,

                tegra210-p2371-2180, tegra30-cardhu-a04

Jon

Tested-by on the v1 series
#30 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.216 release. There are 28 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 Sun, 17 Jan 2021 12:19:42 +0000. Anything received after that time might be too late.

Build results:

	total: 168 pass: 168 fail: 0
Qemu test results:
	total: 404 pass: 404 fail: 0

Guenter

Tested-by Linux Kernel Functional Testing on the v1 series
#31 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.216 release. There are 28 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 Sun, 17 Jan 2021 12:19:42 +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/v4.x/stable-review/patch-4.14.216-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.

thanks,

greg k-h

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

Summary
------------------------------------------------------------------------

kernel: 4.14.216-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 4cfcf012355fcec6a76068a773208220deebc337
git describe: v4.14.215-29-g4cfcf012355f
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.215-29-g4cfcf012355f

No regressions (compared to build v4.14.215)

No fixes (compared to build v4.14.215)

Ran 40410 total tests in the following environments and test suites.

Environments
--------------
- arm
- arm64
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- mips
- qemu-arm64-kasan
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- sparc
- x15 - arm
- x86_64
- x86-kasan
- x86_64

Test Suites
-----------
* build
* linux-log-parser
* install-android-platform-tools-r2600
* ltp-containers-tests
* ltp-cve-tests
* ltp-syscalls-tests
* perf
* v4l2-compliance
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-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-pty-tests
* ltp-securebits-tests
* ltp-tracing-tests
* network-basic-tests
* ltp-open-posix-tests
* ltp-sched-tests
* kvm-unit-tests
* rcutorture
* fwts

Signature · 2 lines
Linaro LKFT
https://lkft.linaro.org