Skip to contentSkip to conversation

5.10.171-rc1 review

PATCH In review Greg Kroah-Hartman 11 participants 33 messages Mar 1, 2023 – Mar 3, 2023

Subsystems (2)
lore
Share & tools
lore
author maintainer
#1 lore raw

PATCH 1/19 Fix XFRM-I support for nested ESP tunnels

In reply to Greg Kroah-Hartman

From: Benedict Wong <[email protected]>

[ Upstream commit b0355dbbf13c0052931dd14c38c789efed64d3de ]

This change adds support for nested IPsec tunnels by ensuring that XFRM-I verifies existing policies before decapsulating a subsequent policies. Addtionally, this clears the secpath entries after policies are verified, ensuring that previous tunnels with no-longer-valid do not pollute subsequent policy checks.

This is necessary especially for nested tunnels, as the IP addresses, protocol and ports may all change, thus not matching the previous policies. In order to ensure that packets match the relevant inbound templates, the xfrm_policy_check should be done before handing off to the inner XFRM protocol to decrypt and decapsulate.

Notably, raw ESP/AH packets did not perform policy checks inherently, whereas all other encapsulated packets (UDP, TCP encapsulated) do policy checks after calling xfrm_input handling in the respective encapsulation layer.

Test: Verified with additional Android Kernel Unit tests

---
 net/xfrm/xfrm_interface.c | 54 ++++++++++++++++++++++++++++++++++++---
 net/xfrm/xfrm_policy.c    |  3 +++
 2 files changed, 53 insertions(+), 4 deletions(-)
net/xfrm/xfrm_interface.c +50 -4
index da518b4ca84c6..e4f21a6924153 100644
@@ -207,6 +207,52 @@ static void xfrmi_scrub_packet(struct sk_buff *skb, bool xnet)
 	skb->mark = 0;
 }
 
+static int xfrmi_input(struct sk_buff *skb, int nexthdr, __be32 spi,
+		       int encap_type, unsigned short family)
+{
+	struct sec_path *sp;
+
+	sp = skb_sec_path(skb);
+	if (sp && (sp->len || sp->olen) &&
+	    !xfrm_policy_check(NULL, XFRM_POLICY_IN, skb, family))
+		goto discard;
+
+	XFRM_SPI_SKB_CB(skb)->family = family;
+	if (family == AF_INET) {
+		XFRM_SPI_SKB_CB(skb)->daddroff = offsetof(struct iphdr, daddr);
+		XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip4 = NULL;
+	} else {
+		XFRM_SPI_SKB_CB(skb)->daddroff = offsetof(struct ipv6hdr, daddr);
+		XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip6 = NULL;
+	}
+
+	return xfrm_input(skb, nexthdr, spi, encap_type);
+discard:
+	kfree_skb(skb);
+	return 0;
+}
+
+static int xfrmi4_rcv(struct sk_buff *skb)
+{
+	return xfrmi_input(skb, ip_hdr(skb)->protocol, 0, 0, AF_INET);
+}
+
+static int xfrmi6_rcv(struct sk_buff *skb)
+{
+	return xfrmi_input(skb, skb_network_header(skb)[IP6CB(skb)->nhoff],
+			   0, 0, AF_INET6);
+}
+
+static int xfrmi4_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
+{
+	return xfrmi_input(skb, nexthdr, spi, encap_type, AF_INET);
+}
+
+static int xfrmi6_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
+{
+	return xfrmi_input(skb, nexthdr, spi, encap_type, AF_INET6);
+}
+
 static int xfrmi_rcv_cb(struct sk_buff *skb, int err)
 {
 	const struct xfrm_mode *inner_mode;
@@ -780,8 +826,8 @@ static struct pernet_operations xfrmi_net_ops = {
 };
 
 static struct xfrm6_protocol xfrmi_esp6_protocol __read_mostly = {
-	.handler	=	xfrm6_rcv,
-	.input_handler	=	xfrm_input,
+	.handler	=	xfrmi6_rcv,
+	.input_handler	=	xfrmi6_input,
 	.cb_handler	=	xfrmi_rcv_cb,
 	.err_handler	=	xfrmi6_err,
 	.priority	=	10,
@@ -831,8 +877,8 @@ static struct xfrm6_tunnel xfrmi_ip6ip_handler __read_mostly = {
 #endif
 
 static struct xfrm4_protocol xfrmi_esp4_protocol __read_mostly = {
-	.handler	=	xfrm4_rcv,
-	.input_handler	=	xfrm_input,
+	.handler	=	xfrmi4_rcv,
+	.input_handler	=	xfrmi4_input,
 	.cb_handler	=	xfrmi_rcv_cb,
 	.err_handler	=	xfrmi4_err,
 	.priority	=	10,
net/xfrm/xfrm_policy.c +3 -0
index 0d12bdf59d4cc..d15aa62887de0 100644
@@ -3710,6 +3710,9 @@ int __xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb,
 			goto reject;
 		}
 
+		if (if_id)
+			secpath_reset(skb);
+
 		xfrm_pols_put(pols, npols);
 		return 1;
 	}
Signature · 1 line
2.39.0
author maintainer
#2 lore raw

PATCH 2/19 arm64: dts: rockchip: drop unused LED mode property from rk3328-roc-cc

In reply to Greg Kroah-Hartman

From: Krzysztof Kozlowski <[email protected]>

[ Upstream commit 1692bffec674551163a7a4be32f59fdde04ecd27 ]

GPIO LEDs do not have a 'mode' property:

rockchip/rk3328-roc-pc.dtb: leds: led-0: Unevaluated properties are not allowed ('mode' was unexpected)

---
 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 2 --
 1 file changed, 2 deletions(-)
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts +0 -2
index daa9a0c601a9f..22ab5e1d7319d 100644
@@ -91,7 +91,6 @@ power_led: led-0 {
 			linux,default-trigger = "heartbeat";
 			gpios = <&rk805 1 GPIO_ACTIVE_LOW>;
 			default-state = "on";
-			mode = <0x23>;
 		};
 
 		user_led: led-1 {
@@ -99,7 +98,6 @@ user_led: led-1 {
 			linux,default-trigger = "mmc1";
 			gpios = <&rk805 0 GPIO_ACTIVE_LOW>;
 			default-state = "off";
-			mode = <0x05>;
 		};
 	};
 };
Signature · 1 line
2.39.0
author maintainer
#3 lore raw

PATCH 3/19 ARM: dts: rockchip: add power-domains property to dp node on rk3288

In reply to Greg Kroah-Hartman

From: Johan Jonker <[email protected]>

[ Upstream commit 80422339a75088322b4d3884bd12fa0fe5d11050 ]

The clocks in the Rockchip rk3288 DisplayPort node are included in the power-domain@RK3288_PD_VIO logic, but the power-domains property in the dp node is missing, so fix it.

---
 arch/arm/boot/dts/rk3288.dtsi | 1 +
 1 file changed, 1 insertion(+)
arch/arm/boot/dts/rk3288.dtsi +1 -0
index 9051fb4a267d4..aab28161b9ae9 100644
@@ -1203,6 +1203,7 @@ edp: dp@ff970000 {
 		clock-names = "dp", "pclk";
 		phys = <&edp_phy>;
 		phy-names = "dp";
+		power-domains = <&power RK3288_PD_VIO>;
 		resets = <&cru SRST_EDP>;
 		reset-names = "dp";
 		rockchip,grf = <&grf>;
Signature · 1 line
2.39.0
author maintainer
#4 lore raw

PATCH 4/19 ACPI: NFIT: fix a potential deadlock during NFIT teardown

In reply to Greg Kroah-Hartman

From: Vishal Verma <[email protected]>

[ Upstream commit fb6df4366f86dd252bfa3049edffa52d17e7b895 ]

Lockdep reports that acpi_nfit_shutdown() may deadlock against an opportune acpi_nfit_scrub(). acpi_nfit_scrub () is run from inside a 'work' and therefore has already acquired workqueue-internal locks. It also acquiires acpi_desc->init_mutex. acpi_nfit_shutdown() first acquires init_mutex, and was subsequently attempting to cancel any pending workqueue items. This reversed locking order causes a potential deadlock:

    ======================================================
    WARNING: possible circular locking dependency detected
    6.2.0-rc3 #116 Tainted: G           O     N
    ------------------------------------------------------
    libndctl/1958 is trying to acquire lock:
    ffff888129b461c0 ((work_completion)(&(&acpi_desc->dwork)->work)){+.+.}-{0:0}, at: __flush_work+0x43/0x450

    but task is already holding lock:
    ffff888129b460e8 (&acpi_desc->init_mutex){+.+.}-{3:3}, at: acpi_nfit_shutdown+0x87/0xd0 [nfit]

    which lock already depends on the new lock.

    ...

    Possible unsafe locking scenario:

          CPU0                    CPU1
          ----                    ----
     lock(&acpi_desc->init_mutex);
                                  lock((work_completion)(&(&acpi_desc->dwork)->work));
                                  lock(&acpi_desc->init_mutex);
     lock((work_completion)(&(&acpi_desc->dwork)->work));

    *** DEADLOCK ***

Since the workqueue manipulation is protected by its own internal locking, the cancellation of pending work doesn't need to be done under acpi_desc->init_mutex. Move cancel_delayed_work_sync() outside the init_mutex to fix the deadlock. Any work that starts after acpi_nfit_shutdown() drops the lock will see ARS_CANCEL, and the cancel_delayed_work_sync() will safely flush it out.

---
 drivers/acpi/nfit/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/nfit/core.c +1 -1
index 99e23a5df0267..2306abb09f7f5 100644
@@ -3687,8 +3687,8 @@ void acpi_nfit_shutdown(void *data)
 
 	mutex_lock(&acpi_desc->init_mutex);
 	set_bit(ARS_CANCEL, &acpi_desc->scrub_flags);
-	cancel_delayed_work_sync(&acpi_desc->dwork);
 	mutex_unlock(&acpi_desc->init_mutex);
+	cancel_delayed_work_sync(&acpi_desc->dwork);
 
 	/*
 	 * Bounce the nvdimm bus lock to make sure any in-flight
Signature · 1 line
2.39.0
author maintainer
#5 lore raw

PATCH 5/19 btrfs: send: limit number of clones and allocated memory size

In reply to Greg Kroah-Hartman

From: David Sterba <[email protected]>

[ Upstream commit 33e17b3f5ab74af12aca58c515bc8424ff69a343 ]

The arg->clone_sources_count is u64 and can trigger a warning when a huge value is passed from user space and a huge array is allocated. Limit the allocated memory to 8MiB (can be increased if needed), which in turn limits the number of clone sources to 8M / sizeof(struct clone_root) = 8M / 40 = 209715. Real world number of clones is from tens to hundreds, so this is future proof.

---
 fs/btrfs/send.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
fs/btrfs/send.c +3 -3
index 4a6ba0997e399..b081b61e97c8d 100644
@@ -7276,10 +7276,10 @@ long btrfs_ioctl_send(struct file *mnt_file, struct btrfs_ioctl_send_args *arg)
 	/*
 	 * Check that we don't overflow at later allocations, we request
 	 * clone_sources_count + 1 items, and compare to unsigned long inside
-	 * access_ok.
+	 * access_ok. Also set an upper limit for allocation size so this can't
+	 * easily exhaust memory. Max number of clone sources is about 200K.
 	 */
-	if (arg->clone_sources_count >
-	    ULONG_MAX / sizeof(struct clone_root) - 1) {
+	if (arg->clone_sources_count > SZ_8M / sizeof(struct clone_root)) {
 		ret = -EINVAL;
 		goto out;
 	}
Signature · 1 line
2.39.0
author maintainer
#6 lore raw

PATCH 6/19 IB/hfi1: Assign npages earlier

In reply to Greg Kroah-Hartman

From: Dean Luick <[email protected]>

[ Upstream commit f9c47b2caa7ffc903ec950b454b59c209afe3182 ]

Improve code clarity and enable earlier use of
tidbuf->npages by moving its assignment to
structure creation time.

---
 drivers/infiniband/hw/hfi1/user_exp_rcv.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)
drivers/infiniband/hw/hfi1/user_exp_rcv.c +2 -7
index 897923981855d..0e0be6c62e3d1 100644
@@ -202,16 +202,11 @@ static void unpin_rcv_pages(struct hfi1_filedata *fd,
 static int pin_rcv_pages(struct hfi1_filedata *fd, struct tid_user_buf *tidbuf)
 {
 	int pinned;
-	unsigned int npages;
+	unsigned int npages = tidbuf->npages;
 	unsigned long vaddr = tidbuf->vaddr;
 	struct page **pages = NULL;
 	struct hfi1_devdata *dd = fd->uctxt->dd;
 
-	/* Get the number of pages the user buffer spans */
-	npages = num_user_pages(vaddr, tidbuf->length);
-	if (!npages)
-		return -EINVAL;
-
 	if (npages > fd->uctxt->expected_count) {
 		dd_dev_err(dd, "Expected buffer too big\n");
 		return -EINVAL;
@@ -238,7 +233,6 @@ static int pin_rcv_pages(struct hfi1_filedata *fd, struct tid_user_buf *tidbuf)
 		return pinned;
 	}
 	tidbuf->pages = pages;
-	tidbuf->npages = npages;
 	fd->tid_n_pinned += pinned;
 	return pinned;
 }
@@ -316,6 +310,7 @@ int hfi1_user_exp_rcv_setup(struct hfi1_filedata *fd,
 	mutex_init(&tidbuf->cover_mutex);
 	tidbuf->vaddr = tinfo->vaddr;
 	tidbuf->length = tinfo->length;
+	tidbuf->npages = num_user_pages(tidbuf->vaddr, tidbuf->length);
 	tidbuf->psets = kcalloc(uctxt->expected_count, sizeof(*tidbuf->psets),
 				GFP_KERNEL);
 	if (!tidbuf->psets) {
Signature · 1 line
2.39.0
author maintainer
#7 lore raw

PATCH 7/19 neigh: make sure used and confirmed times are valid

In reply to Greg Kroah-Hartman

From: Julian Anastasov <[email protected]>

[ Upstream commit c1d2ecdf5e38e3489ce8328238b558b3b2866fe1 ]

Entries can linger in cache without timer for days, thanks to the gc_thresh1 limit. As result, without traffic, the confirmed time can be outdated and to appear to be in the future. Later, on traffic, NUD_STALE entries can switch to NUD_DELAY and start the timer which can see the invalid confirmed time and wrongly switch to NUD_REACHABLE state instead of NUD_PROBE. As result, timer is set many days in the future. This is more visible on 32-bit platforms, with higher HZ value.

Why this is a problem? While we expect unused entries to expire, such entries stay in REACHABLE state for too long, locked in cache. They are not expired normally, only when cache is full.

Problem and the wrong state change reported by Zhang Changzhong:

172.16.1.18 dev bond0 lladdr 0a:0e:0f:01:12:01 ref 1 used 350521/15994171/350520 probes 4 REACHABLE

350520 seconds have elapsed since this entry was last updated, but it is still in the REACHABLE state (base_reachable_time_ms is 30000), preventing lladdr from being updated through probe.

Fix it by ensuring timer is started with valid used/confirmed times. Considering the valid time range is LONG_MAX jiffies, we try not to go too much in the past while we are in DELAY/PROBE state. There are also places that need used/updated times to be validated while timer is not running.

---
 net/core/neighbour.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)
net/core/neighbour.c +15 -3
index f6f580e9d2820..82ccc3eebe71d 100644
@@ -242,7 +242,7 @@ static int neigh_forced_gc(struct neigh_table *tbl)
 			    (n->nud_state == NUD_NOARP) ||
 			    (tbl->is_multicast &&
 			     tbl->is_multicast(n->primary_key)) ||
-			    time_after(tref, n->updated))
+			    !time_in_range(n->updated, tref, jiffies))
 				remove = true;
 			write_unlock(&n->lock);
 
@@ -262,7 +262,17 @@ static int neigh_forced_gc(struct neigh_table *tbl)
 
 static void neigh_add_timer(struct neighbour *n, unsigned long when)
 {
+	/* Use safe distance from the jiffies - LONG_MAX point while timer
+	 * is running in DELAY/PROBE state but still show to user space
+	 * large times in the past.
+	 */
+	unsigned long mint = jiffies - (LONG_MAX - 86400 * HZ);
+
 	neigh_hold(n);
+	if (!time_in_range(n->confirmed, mint, jiffies))
+		n->confirmed = mint;
+	if (time_before(n->used, n->confirmed))
+		n->used = n->confirmed;
 	if (unlikely(mod_timer(&n->timer, when))) {
 		printk("NEIGH: BUG, double timer add, state is %x\n",
 		       n->nud_state);
@@ -948,12 +958,14 @@ static void neigh_periodic_work(struct work_struct *work)
 				goto next_elt;
 			}
 
-			if (time_before(n->used, n->confirmed))
+			if (time_before(n->used, n->confirmed) &&
+			    time_is_before_eq_jiffies(n->confirmed))
 				n->used = n->confirmed;
 
 			if (refcount_read(&n->refcnt) == 1 &&
 			    (state == NUD_FAILED ||
-			     time_after(jiffies, n->used + NEIGH_VAR(n->parms, GC_STALETIME)))) {
+			     !time_in_range_open(jiffies, n->used,
+						 n->used + NEIGH_VAR(n->parms, GC_STALETIME)))) {
 				*np = n->next;
 				neigh_mark_dead(n);
 				write_unlock(&n->lock);
Signature · 1 line
2.39.0
author maintainer
#8 lore raw

PATCH 8/19 HID: core: Fix deadloop in hid_apply_multiplier.

In reply to Greg Kroah-Hartman

From: Xin Zhao <[email protected]>

[ Upstream commit ea427a222d8bdf2bc1a8a6da3ebe247f7dced70c ]

The initial value of hid->collection[].parent_idx if 0. When Report descriptor doesn't contain "HID Collection", the value remains as 0.

In the meanwhile, when the Report descriptor fullfill all following conditions, it will trigger hid_apply_multiplier function call.
1. Usage page is Generic Desktop Ctrls (0x01)
2. Usage is RESOLUTION_MULTIPLIER (0x48)
3. Contain any FEATURE items

The while loop in hid_apply_multiplier will search the top-most collection by searching parent_idx == -1. Because all parent_idx is 0. The loop will run forever.

There is a Report Descriptor triggerring the deadloop

0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)
0x09, 0x48,        // Usage (0x48)
0x95, 0x01,        // Report Count (1)
0x75, 0x08,        // Report Size (8)
0xB1, 0x01,        // Feature
---
 drivers/hid/hid-core.c | 3 +++
 1 file changed, 3 insertions(+)
drivers/hid/hid-core.c +3 -0
index baadead947c8b..5f9ec1d1464a2 100644
@@ -1197,6 +1197,7 @@ int hid_open_report(struct hid_device *device)
 	__u8 *end;
 	__u8 *next;
 	int ret;
+	int i;
 	static int (*dispatch_type[])(struct hid_parser *parser,
 				      struct hid_item *item) = {
 		hid_parser_main,
@@ -1247,6 +1248,8 @@ int hid_open_report(struct hid_device *device)
 		goto err;
 	}
 	device->collection_size = HID_DEFAULT_NUM_COLLECTIONS;
+	for (i = 0; i < HID_DEFAULT_NUM_COLLECTIONS; i++)
+		device->collection[i].parent_idx = -1;
 
 	ret = -EINVAL;
 	while ((next = fetch_item(start, end, &item)) != NULL) {
Signature · 1 line
2.39.0
author maintainer
#9 lore raw

PATCH 9/19 bpf: bpf_fib_lookup should not return neigh in NUD_FAILED state

In reply to Greg Kroah-Hartman

From: Martin KaFai Lau <[email protected]>

commit 1fe4850b34ab512ff911e2c035c75fb6438f7307 upstream.

The bpf_fib_lookup() helper does not only look up the fib (ie. route) but it also looks up the neigh. Before returning the neigh, the helper does not check for NUD_VALID. When a neigh state (neigh->nud_state) is in NUD_FAILED, its dmac (neigh->ha) could be all zeros. The helper still returns SUCCESS instead of NO_NEIGH in this case. Because of the SUCCESS return value, the bpf prog directly uses the returned dmac and ends up filling all zero in the eth header.

This patch checks for NUD_VALID and returns NO_NEIGH if the neigh is not valid.

---
 net/core/filter.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/core/filter.c +2 -2
@@ -5401,7 +5401,7 @@ static int bpf_ipv4_fib_lookup(struct ne
 		neigh = __ipv6_neigh_lookup_noref_stub(dev, dst);
 	}
 
-	if (!neigh)
+	if (!neigh || !(neigh->nud_state & NUD_VALID))
 		return BPF_FIB_LKUP_RET_NO_NEIGH;
 
 	return bpf_fib_set_fwd_params(params, neigh, dev);
@@ -5514,7 +5514,7 @@ static int bpf_ipv6_fib_lookup(struct ne
 	 * not needed here.
 	 */
 	neigh = __ipv6_neigh_lookup_noref_stub(dev, dst);
-	if (!neigh)
+	if (!neigh || !(neigh->nud_state & NUD_VALID))
 		return BPF_FIB_LKUP_RET_NO_NEIGH;
 
 	return bpf_fib_set_fwd_params(params, neigh, dev);

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 5.10.171-rc1 review

This is the start of the stable review cycle for the 5.10.171 release. There are 19 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 Fri, 03 Mar 2023 18:06:43 +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/v5.x/stable-review/patch-5.10.171-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

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

Greg Kroah-Hartman <[email protected]>

    Linux 5.10.171-rc1

Alan Stern <[email protected]>
USB: core: Don't hold device lock while reading the "descriptors" sysfs file

Prashanth K <[email protected]>
usb: gadget: u_serial: Add null pointer check in gserial_resume

Florian Zumbiehl <[email protected]>
USB: serial: option: add support for VW/Skoda "Carstick LTE"

Dmitry Osipenko <[email protected]>
drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling

Miaoqian Lin <[email protected]>
drm/virtio: Fix NULL vs IS_ERR checking in virtio_gpu_object_shmem_init

Carlos Llamas <[email protected]>
scripts/tags.sh: fix incompatibility with PCRE2

Cristian Ciocaltea <[email protected]>
scripts/tags.sh: Invoke 'realpath' via 'xargs'

David Sloan <[email protected]>
md: Flush workqueue md_rdev_misc_wq in md_alloc()

Thomas Weißschuh <[email protected]>
vc_screen: don't clobber return value in vcs_read

Kuniyuki Iwashima <[email protected]>

    net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues().

Martin KaFai Lau <[email protected]>
bpf: bpf_fib_lookup should not return neigh in NUD_FAILED state

Xin Zhao <[email protected]>
HID: core: Fix deadloop in hid_apply_multiplier.

Julian Anastasov <[email protected]>
neigh: make sure used and confirmed times are valid

Dean Luick <[email protected]>
IB/hfi1: Assign npages earlier

David Sterba <[email protected]>
btrfs: send: limit number of clones and allocated memory size

Vishal Verma <[email protected]>
ACPI: NFIT: fix a potential deadlock during NFIT teardown

Johan Jonker <[email protected]>
ARM: dts: rockchip: add power-domains property to dp node on rk3288

Krzysztof Kozlowski <[email protected]>
arm64: dts: rockchip: drop unused LED mode property from rk3328-roc-cc

Benedict Wong <[email protected]>
Fix XFRM-I support for nested ESP tunnels

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

Diffstat:

 Makefile                                       |  4 +-
 arch/arm/boot/dts/rk3288.dtsi                  |  1 +
 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts |  2 -
 drivers/acpi/nfit/core.c                       |  2 +-
 drivers/gpu/drm/virtio/virtgpu_object.c        |  5 ++-
 drivers/hid/hid-core.c                         |  3 ++
 drivers/infiniband/hw/hfi1/user_exp_rcv.c      |  9 +----
 drivers/md/md.c                                |  1 +
 drivers/tty/vt/vc_screen.c                     |  7 ++--
 drivers/usb/core/hub.c                         |  5 +--
 drivers/usb/core/sysfs.c                       |  5 ---
 drivers/usb/gadget/function/u_serial.c         | 23 +++++++++--
 drivers/usb/serial/option.c                    |  4 ++
 fs/btrfs/send.c                                |  6 +--
 net/caif/caif_socket.c                         |  1 +
 net/core/filter.c                              |  4 +-
 net/core/neighbour.c                           | 18 +++++++--
 net/core/stream.c                              |  1 -
 net/xfrm/xfrm_interface.c                      | 54 ++++++++++++++++++++++++--
 net/xfrm/xfrm_policy.c                         |  3 ++
 scripts/tags.sh                                | 11 ++++--
 21 files changed, 123 insertions(+), 46 deletions(-)
author maintainer
#11 lore raw

PATCH 11/19 vc_screen: dont clobber return value in vcs_read

From: Thomas Weißschuh <[email protected]>

commit ae3419fbac845b4d3f3a9fae4cc80c68d82cdf6e upstream.

Commit 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.

While doing this it also moved the unconditional assignment of

	ret = -ENXIO;

This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.

To avoid this only assign "ret = -ENXIO" when actually needed.

[ Also, the 'goto unlock_out" needs to be just a "break", so that it
does the right thing when it exits on later iterations when partial success has happened - Linus ]

---
 drivers/tty/vt/vc_screen.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/tty/vt/vc_screen.c +4 -3
@@ -403,10 +403,11 @@ vcs_read(struct file *file, char __user
 		unsigned int this_round, skip = 0;
 		int size;
 
-		ret = -ENXIO;
 		vc = vcs_vc(inode, &viewed);
-		if (!vc)
-			goto unlock_out;
+		if (!vc) {
+			ret = -ENXIO;
+			break;
+		}
 
 		/* Check whether we are above size each round,
 		 * as copy_to_user at the end of this loop
author maintainer
#12 lore raw

PATCH 12/19 md: Flush workqueue md_rdev_misc_wq in md_alloc()

In reply to Greg Kroah-Hartman

From: David Sloan <[email protected]>

commit 5e8daf906f890560df430d30617c692a794acb73 upstream.

A race condition still exists when removing and re-creating md devices in test cases. However, it is only seen on some setups.

The race condition was tracked down to a reference still being held to the kobject by the rdev in the md_rdev_misc_wq which will be released in rdev_delayed_delete().

md_alloc() waits for previous deletions by waiting on the md_misc_wq, but the md_rdev_misc_wq may still be holding a reference to a recently removed device.

To fix this, also flush the md_rdev_misc_wq in md_alloc().

---
 drivers/md/md.c |    1 +
 1 file changed, 1 insertion(+)
drivers/md/md.c +1 -0
@@ -5683,6 +5683,7 @@ static int md_alloc(dev_t dev, char *nam
 	 * completely removed (mddev_delayed_delete).
 	 */
 	flush_workqueue(md_misc_wq);
+	flush_workqueue(md_rdev_misc_wq);
 
 	mutex_lock(&disks_mutex);
 	error = -EEXIST;
author maintainer
#13 lore raw

PATCH 13/19 scripts/tags.sh: Invoke realpath via xargs

In reply to Greg Kroah-Hartman

From: Cristian Ciocaltea <[email protected]>

commit 7394d2ebb651a9f62e08c6ab864aac015d27c64d upstream.

When COMPILED_SOURCE is set, running

make ARCH=x86_64 COMPILED_SOURCE=1 cscope tags

could throw the following errors:

scripts/tags.sh: line 98: /usr/bin/realpath: Argument list too long
cscope: no source files found
scripts/tags.sh: line 98: /usr/bin/realpath: Argument list too long
ctags: No files specified. Try "ctags --help".

This is most likely to happen when the kernel is configured to build a large number of modules, which has the consequence of passing too many arguments when calling 'realpath' in 'all_compiled_sources()'.

Let's improve this by invoking 'realpath' through 'xargs', which takes care of properly limiting the argument list.

---
 scripts/tags.sh |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)
scripts/tags.sh +7 -4
@@ -95,10 +95,13 @@ all_sources()
 
 all_compiled_sources()
 {
-	realpath -es $([ -z "$KBUILD_ABS_SRCTREE" ] && echo --relative-to=.) \
-		include/generated/autoconf.h $(find $ignore -name "*.cmd" -exec \
-		grep -Poh '(?(?=^source_.* \K).*|(?=^  \K\S).*(?= \\))' {} \+ |
-		awk '!a[$0]++') | sort -u
+	{
+		echo include/generated/autoconf.h
+		find $ignore -name "*.cmd" -exec \
+			grep -Poh '(?(?=^source_.* \K).*|(?=^  \K\S).*(?= \\))' {} \+ |
+		awk '!a[$0]++'
+	} | xargs realpath -es $([ -z "$KBUILD_ABS_SRCTREE" ] && echo --relative-to=.) |
+	sort -u
 }
 
 all_target_sources()
author maintainer
#14 lore raw

PATCH 14/19 scripts/tags.sh: fix incompatibility with PCRE2

In reply to Greg Kroah-Hartman

From: Carlos Llamas <[email protected]>

commit 6ec363fc6142226b9ab5a6528f65333d729d2b6b upstream.

Starting with release 10.38 PCRE2 drops default support for using \K in lookaround patterns as described in [1]. Unfortunately, scripts/tags.sh relies on such functionality to collect all_compiled_soures() leading to the following error:

  $ make COMPILED_SOURCE=1 tags
    GEN     tags
  grep: \K is not allowed in lookarounds (but see PCRE2_EXTRA_ALLOW_LOOKAROUND_BSK)

The usage of \K for this pattern was introduced in commit 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") which speeds up the generation of tags significantly.

In order to fix this issue without compromising the performance we can switch over to an equivalent sed expression. The same matching pattern is preserved here except \K is replaced with a backreference \1.

[1] https://www.pcre.org/current/doc/html/pcre2syntax.html#SEC11

Cc Greg Kroah-Hartman <[email protected]>
Cc Cristian Ciocaltea <[email protected]>
Cc Masahiro Yamada <[email protected]>
Cc Jialu Xu <[email protected]>
Cc Vipin Sharma <[email protected]>
Fixes 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely")
---
 scripts/tags.sh |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
scripts/tags.sh +1 -1
@@ -98,7 +98,7 @@ all_compiled_sources()
 	{
 		echo include/generated/autoconf.h
 		find $ignore -name "*.cmd" -exec \
-			grep -Poh '(?(?=^source_.* \K).*|(?=^  \K\S).*(?= \\))' {} \+ |
+			sed -n -E 's/^source_.* (.*)/\1/p; s/^  (\S.*) \\/\1/p' {} \+ |
 		awk '!a[$0]++'
 	} | xargs realpath -es $([ -z "$KBUILD_ABS_SRCTREE" ] && echo --relative-to=.) |
 	sort -u
author maintainer
#15 lore raw

PATCH 15/19 drm/virtio: Fix NULL vs IS_ERR checking in virtio_gpu_object_shmem_init

In reply to Greg Kroah-Hartman

From: Miaoqian Lin <[email protected]>

commit c24968734abfed81c8f93dc5f44a7b7a9aecadfa upstream.

Since drm_prime_pages_to_sg() function return error pointers. The drm_gem_shmem_get_sg_table() function returns error pointers too. Using IS_ERR() to check the return value to fix this.

Fixes 2f2aa13724d5 ("drm/virtio: move virtio_gpu_mem_entry initialization to new function")
---
 drivers/gpu/drm/virtio/virtgpu_object.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/virtio/virtgpu_object.c +2 -2
@@ -157,9 +157,9 @@ static int virtio_gpu_object_shmem_init(
 	 * since virtio_gpu doesn't support dma-buf import from other devices.
 	 */
 	shmem->pages = drm_gem_shmem_get_sg_table(&bo->base.base);
-	if (!shmem->pages) {
+	if (IS_ERR(shmem->pages)) {
 		drm_gem_shmem_unpin(&bo->base.base);
-		return -EINVAL;
+		return PTR_ERR(shmem->pages);
 	}
 
 	if (use_dma_api) {
author maintainer
#16 lore raw

PATCH 16/19 drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling

In reply to Greg Kroah-Hartman

From: Dmitry Osipenko <[email protected]>

commit 64b88afbd92fbf434759d1896a7cf705e1c00e79 upstream.

Previous commit fixed checking of the ERR_PTR value returned by drm_gem_shmem_get_sg_table(), but it missed to zero out the shmem->pages, which will crash virtio_gpu_cleanup_object(). Add the missing zeroing of the shmem->pages.

Fixes c24968734abf ("drm/virtio: Fix NULL vs IS_ERR checking in virtio_gpu_object_shmem_init")
---
 drivers/gpu/drm/virtio/virtgpu_object.c |    1 +
 1 file changed, 1 insertion(+)
drivers/gpu/drm/virtio/virtgpu_object.c +1 -0
@@ -159,6 +159,7 @@ static int virtio_gpu_object_shmem_init(
 	shmem->pages = drm_gem_shmem_get_sg_table(&bo->base.base);
 	if (IS_ERR(shmem->pages)) {
 		drm_gem_shmem_unpin(&bo->base.base);
+		shmem->pages = NULL;
 		return PTR_ERR(shmem->pages);
 	}
 
author maintainer
#19 lore raw

PATCH 17/19 USB: serial: option: add support for VW/Skoda "Carstick LTE"

In reply to Greg Kroah-Hartman

From: Florian Zumbiehl <[email protected]>

commit 617c331d91077f896111044628c096802551dc66 upstream.

Add support for VW/Skoda "Carstick LTE"

D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1c9e ProdID=7605 Rev=02.00
S:  Manufacturer=USB Modem
S:  Product=USB Modem
C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

The stick has AT command interfaces on interfaces 1, 2, and 3, and does PPP on interface 3.

---
 drivers/usb/serial/option.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -402,6 +402,8 @@ static void option_instat_callback(struc
 #define LONGCHEER_VENDOR_ID			0x1c9e
 
 /* 4G Systems products */
+/* This one was sold as the VW and Skoda "Carstick LTE" */
+#define FOUR_G_SYSTEMS_PRODUCT_CARSTICK_LTE	0x7605
 /* This is the 4G XS Stick W14 a.k.a. Mobilcom Debitel Surf-Stick *
  * It seems to contain a Qualcomm QSC6240/6290 chipset            */
 #define FOUR_G_SYSTEMS_PRODUCT_W14		0x9603
@@ -1976,6 +1978,8 @@ static const struct usb_device_id option
 	  .driver_info = RSVD(2) },
 	{ USB_DEVICE(AIRPLUS_VENDOR_ID, AIRPLUS_PRODUCT_MCD650) },
 	{ USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) },
+	{ USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_CARSTICK_LTE),
+	  .driver_info = RSVD(0) },
 	{ USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14),
 	  .driver_info = NCTRL(0) | NCTRL(1) },
 	{ USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W100),
author maintainer
#20 lore raw

PATCH 18/19 usb: gadget: u_serial: Add null pointer check in gserial_resume

In reply to Greg Kroah-Hartman

From: Prashanth K <[email protected]>

commit 5ec63fdbca604568890c577753c6f66c5b3ef0b5 upstream.

Consider a case where gserial_disconnect has already cleared gser->ioport. And if a wakeup interrupt triggers afterwards, gserial_resume gets called, which will lead to accessing of gser->ioport and thus causing null pointer dereference.Add a null pointer check to prevent this.

Added a static spinlock to prevent gser->ioport from becoming null after the newly added check.

Fixes aba3a8d01d62 ("usb: gadget: u_serial: add suspend resume callbacks")
Cc stable <[email protected]>
---
 drivers/usb/gadget/function/u_serial.c |   23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)
drivers/usb/gadget/function/u_serial.c +19 -4
@@ -81,6 +81,9 @@
 #define WRITE_BUF_SIZE		8192		/* TX only */
 #define GS_CONSOLE_BUF_SIZE	8192
 
+/* Prevents race conditions while accessing gser->ioport */
+static DEFINE_SPINLOCK(serial_port_lock);
+
 /* console info */
 struct gs_console {
 	struct console		console;
@@ -1376,8 +1379,10 @@ void gserial_disconnect(struct gserial *
 	if (!port)
 		return;
 
+	spin_lock_irqsave(&serial_port_lock, flags);
+
 	/* tell the TTY glue not to do I/O here any more */
-	spin_lock_irqsave(&port->port_lock, flags);
+	spin_lock(&port->port_lock);
 
 	gs_console_disconnect(port);
 
@@ -1392,7 +1397,8 @@ void gserial_disconnect(struct gserial *
 			tty_hangup(port->port.tty);
 	}
 	port->suspended = false;
-	spin_unlock_irqrestore(&port->port_lock, flags);
+	spin_unlock(&port->port_lock);
+	spin_unlock_irqrestore(&serial_port_lock, flags);
 
 	/* disable endpoints, aborting down any active I/O */
 	usb_ep_disable(gser->out);
@@ -1426,10 +1432,19 @@ EXPORT_SYMBOL_GPL(gserial_suspend);
 
 void gserial_resume(struct gserial *gser)
 {
-	struct gs_port *port = gser->ioport;
+	struct gs_port *port;
 	unsigned long	flags;
 
-	spin_lock_irqsave(&port->port_lock, flags);
+	spin_lock_irqsave(&serial_port_lock, flags);
+	port = gser->ioport;
+
+	if (!port) {
+		spin_unlock_irqrestore(&serial_port_lock, flags);
+		return;
+	}
+
+	spin_lock(&port->port_lock);
+	spin_unlock(&serial_port_lock);
 	port->suspended = false;
 	if (!port->start_delayed) {
 		spin_unlock_irqrestore(&port->port_lock, flags);
author maintainer
#21 lore raw

PATCH 19/19 USB: core: Dont hold device lock while reading the "descriptors" sysfs file

In reply to Greg Kroah-Hartman

From: Alan Stern <[email protected]>

commit 45bf39f8df7f05efb83b302c65ae3b9bc92b7065 upstream.

Ever since commit 83e83ecb79a8 ("usb: core: get config and string descriptors for unauthorized devices") was merged in 2013, there has been no mechanism for reallocating the rawdescriptors buffers in struct usb_device after the initial enumeration. Before that commit, the buffers would be deallocated when a device was deauthorized and reallocated when it was authorized and enumerated.

This means that the locking in the read_descriptors() routine is not needed, since the buffers it reads will never be reallocated while the routine is running. This locking can interfere with user programs trying to read a hub's descriptors via sysfs while new child devices of the hub are being initialized, since the hub is locked during this procedure.

Since the locking in read_descriptors() hasn't been needed for over nine years, we can remove it.

---
 drivers/usb/core/hub.c   |    5 ++---
 drivers/usb/core/sysfs.c |    5 -----
 2 files changed, 2 insertions(+), 8 deletions(-)
drivers/usb/core/hub.c +2 -3
@@ -2380,9 +2380,8 @@ static int usb_enumerate_device_otg(stru
  * usb_enumerate_device - Read device configs/intfs/otg (usbcore-internal)
  * @udev: newly addressed device (in ADDRESS state)
  *
- * This is only called by usb_new_device() and usb_authorize_device()
- * and FIXME -- all comments that apply to them apply here wrt to
- * environment.
+ * This is only called by usb_new_device() -- all comments that apply there
+ * apply here wrt to environment.
  *
  * If the device is WUSB and not authorized, we don't attempt to read
  * the string descriptors, as they will be errored out by the device
drivers/usb/core/sysfs.c +0 -5
@@ -889,11 +889,7 @@ read_descriptors(struct file *filp, stru
 	size_t srclen, n;
 	int cfgno;
 	void *src;
-	int retval;
 
-	retval = usb_lock_device_interruptible(udev);
-	if (retval < 0)
-		return -EINTR;
 	/* The binary attribute begins with the device descriptor.
 	 * Following that are the raw descriptor entries for all the
 	 * configurations (config plus subsidiary descriptors).
@@ -918,7 +914,6 @@ read_descriptors(struct file *filp, stru
 			off -= srclen;
 		}
 	}
-	usb_unlock_device(udev);
 	return count - nleft;
 }
 
author maintainer
#10 lore raw

PATCH 10/19 net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues().

In reply to Greg Kroah-Hartman

From: Kuniyuki Iwashima <[email protected]>

commit 62ec33b44e0f7168ff2886520fec6fb62d03b5a3 upstream.

Christoph Paasch reported that commit b5fc29233d28 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().") started triggering WARN_ON_ONCE(sk->sk_forward_alloc) in sk_stream_kill_queues(). [0 - 2] Also, we can reproduce it by a program in [3].

In the commit, we delay freeing ipv6_pinfo.pktoptions from sk->destroy() to sk->sk_destruct(), so sk->sk_forward_alloc is no longer zero in inet_csk_destroy_sock().

The same check has been in inet_sock_destruct() from at least v2.6, we can just remove the WARN_ON_ONCE(). However, among the users of sk_stream_kill_queues(), only CAIF is not calling inet_sock_destruct(). Thus, we add the same WARN_ON_ONCE() to caif_sock_destructor().

[0]: https://lore.kernel.org/netdev/[email protected]/
[1]: https://github.com/multipath-tcp/mptcp_net-next/issues/341
[2]:

WARNING: CPU: 0 PID: 3232 at net/core/stream.c:212 sk_stream_kill_queues+0x2f9/0x3e0
Modules linked in:
CPU: 0 PID: 3232 Comm: syz-executor.0 Not tainted 6.2.0-rc5ab24eb4698afbe147b424149c529e2a43ec24eb5 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:sk_stream_kill_queues+0x2f9/0x3e0
Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ec 00 00 00 8b ab 08 01 00 00 e9 60 ff ff ff e8 d0 5f b6 fe 0f 0b eb 97 e8 c7 5f b6 fe <0f> 0b eb a0 e8 be 5f b6 fe 0f 0b e9 6a fe ff ff e8 02 07 e3 fe e9
RSP: 0018:ffff88810570fc68 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888101f38f40 RSI: ffffffff8285e529 RDI: 0000000000000005
RBP: 0000000000000ce0 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000ce0 R11: 0000000000000001 R12: ffff8881009e9488
R13: ffffffff84af2cc0 R14: 0000000000000000 R15: ffff8881009e9458
FS:  00007f7fdfbd5800(0000) GS:ffff88811b600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32923000 CR3: 00000001062fc006 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 inet_csk_destroy_sock+0x1a1/0x320
 __tcp_close+0xab6/0xe90
 tcp_close+0x30/0xc0
 inet_release+0xe9/0x1f0
 inet6_release+0x4c/0x70
 __sock_release+0xd2/0x280
 sock_close+0x15/0x20
 __fput+0x252/0xa20
 task_work_run+0x169/0x250
 exit_to_user_mode_prepare+0x113/0x120
 syscall_exit_to_user_mode+0x1d/0x40
 do_syscall_64+0x48/0x90
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f7fdf7ae28d
Code: c1 20 00 00 75 10 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 37 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00000000007dfbb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f7fdf7ae28d
RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 0000000000000003
RBP: 0000000000000000 R08: 000000007f338e0f R09: 0000000000000e0f
R10: 000000007f338e13 R11: 0000000000000293 R12: 00007f7fdefff000
R13: 00007f7fdefffcd8 R14: 00007f7fdefffce0 R15: 00007f7fdefffcd8
 </TASK>

[3]: https://lore.kernel.org/netdev/[email protected]/

Fixes b5fc29233d28 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().")
---
 net/caif/caif_socket.c |    1 +
 net/core/stream.c      |    1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
net/caif/caif_socket.c +1 -0
@@ -1020,6 +1020,7 @@ static void caif_sock_destructor(struct
 		return;
 	}
 	sk_stream_kill_queues(&cf_sk->sk);
+	WARN_ON(sk->sk_forward_alloc);
 	caif_free_client(&cf_sk->layer);
 }
 
net/core/stream.c +0 -1
@@ -209,7 +209,6 @@ void sk_stream_kill_queues(struct sock *
 	sk_mem_reclaim(sk);
 
 	WARN_ON(sk->sk_wmem_queued);
-	WARN_ON(sk->sk_forward_alloc);
 
 	/* It is _impossible_ for the backlog to contain anything
 	 * when we get here.  All user references to this socket
Tested-by on the v1 series
#22 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 5.10.171 release. There are 19 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 Fri, 03 Mar 2023 18:06:43 +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.171-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, build tested on BMIPS_GENERIC:

Signature · 1 line
Florian
Tested-by on the v1 series
#23 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.171 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Quoted 8 lines

Responses should be made by Fri, 03 Mar 2023 18:06:43 +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/v5.x/stable-review/patch-5.10.171-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.

5.10.171-rc1 compiled and booted on my x86_64 test system. No errors or regressions.

-- Slade

Tested-by on the v1 series
#24 lore raw
In reply to Greg Kroah-Hartman

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 5.10.171 release. There are 19 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.

AFAICT we should not need this patch -- we don't have b5fc29233d28 in 5.10, so the assertion seems to be at the correct place here.

Quoted 3 lines

Kuniyuki Iwashima <[email protected]>

    net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from
    sk_stream_kill_queues().

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Best regards,
Pavel

Signature · 2 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
#25 lore raw
Quoted 9 lines · Pavel Machek

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 5.10.171 release. There are 19 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.

AFAICT we should not need this patch -- we don't have b5fc29233d28 in 5.10, so the assertion seems to be at the correct place here.

This (b5fc29233d28be7a3322848ebe73ac327559cdb9) appears to be in linux-5.10.y, though?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=b5fc29233d28be7a3322848ebe73ac327559cdb9

Confused,
-- Slade

Quoted 8 lines
Quoted 4 lines

Kuniyuki Iwashima <[email protected]>

    net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from
    sk_stream_kill_queues().

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Tested-by on the v1 series
#28 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 5.10.171 release. There are 19 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 Fri, 03 Mar 2023 18:06:43 +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.171-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.

thanks,
-- Shuah

#26 lore raw
In reply to Slade Watkins
Quoted 11 lines · Slade Watkins
Quoted 9 lines · Pavel Machek

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 5.10.171 release. There are 19 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.

AFAICT we should not need this patch -- we don't have b5fc29233d28 in 5.10, so the assertion seems to be at the correct place here.

Quoted 7 lines

This (b5fc29233d28be7a3322848ebe73ac327559cdb9) appears to be in linux-5.10.y, though?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=b5fc29233d28be7a3322848ebe73ac327559cdb9

Confused,
-- Slade

Also confused. My script tells me that it is _not_ in v5.10.y, and that it isn't queued either.

Upstream commit b5fc29233d2 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().")
Integrated in v6.2-rc1
Not in 6.1.y
Not in 5.15.y
Not in 5.10.y
Not in 5.4.y
Not in 4.19.y
Not in 4.14.y

and:

$ git describe --contains b5fc29233d28be7a3322848ebe73ac327559cdb9
v6.2-rc1~99^2~393^2~4

However, it looks like 62ec33b44e0 is queued everywhere.

Upstream commit 62ec33b44e0 ("net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues().")
Integrated in v6.2
Expected to be fixed in 6.1.y with next stable release (sha 29d108dc216d)
Expected to be fixed in 5.15.y with next stable release (sha 07c26a42efc3)
Expected to be fixed in 5.10.y with next stable release (sha 3ecdc3798eb9)
Expected to be fixed in 5.4.y with next stable release (sha a88c26a1210e)
Expected to be fixed in 4.19.y with next stable release (sha 60b390c291e9)
Expected to be fixed in 4.14.y with next stable release (sha b53a2b4858c2)

Guenter

Quoted 9 lines
Quoted 8 lines
Quoted 4 lines

Kuniyuki Iwashima <[email protected]>

     net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from
     sk_stream_kill_queues().

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

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 5.10.171 release. There are 19 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 Fri, 03 Mar 2023 18:06:43 +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.171-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:

    11 builds:	11 pass, 0 fail
    28 boots:	28 pass, 0 fail
    75 tests:	75 pass, 0 fail

Linux version: 5.10.171-rc1-g032c569d266c
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

Jon

author maintainer
#27 lore raw
In reply to Guenter Roeck
Quoted 39 lines · Guenter Roeck
Quoted 11 lines · Slade Watkins
Quoted 9 lines · Pavel Machek

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 5.10.171 release. There are 19 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.

AFAICT we should not need this patch -- we don't have b5fc29233d28 in 5.10, so the assertion seems to be at the correct place here.

Quoted 7 lines

This (b5fc29233d28be7a3322848ebe73ac327559cdb9) appears to be in linux-5.10.y, though?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=b5fc29233d28be7a3322848ebe73ac327559cdb9

Confused,
-- Slade

Also confused. My script tells me that it is _not_ in v5.10.y, and that it isn't queued either.

Upstream commit b5fc29233d2 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().")
Integrated in v6.2-rc1
Not in 6.1.y
Not in 5.15.y
Not in 5.10.y
Not in 5.4.y
Not in 4.19.y
Not in 4.14.y

and:

$ git describe --contains b5fc29233d28be7a3322848ebe73ac327559cdb9
v6.2-rc1~99^2~393^2~4

However, it looks like 62ec33b44e0 is queued everywhere.

Quoted 8 lines

Upstream commit 62ec33b44e0 ("net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues().")
Integrated in v6.2
Expected to be fixed in 6.1.y with next stable release (sha 29d108dc216d)
Expected to be fixed in 5.15.y with next stable release (sha 07c26a42efc3)
Expected to be fixed in 5.10.y with next stable release (sha 3ecdc3798eb9)
Expected to be fixed in 5.4.y with next stable release (sha a88c26a1210e)
Expected to be fixed in 4.19.y with next stable release (sha 60b390c291e9)
Expected to be fixed in 4.14.y with next stable release (sha b53a2b4858c2)

Please see the email from Kuniyuki here:

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

that should explain this.

The backport to older kernels is here:

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

If you all think this should not be in any of these kernels, please let work with Kuniyuki to figure it out.

thanks,

greg k-h

Tested-by Sudip Mukherjee on the v1 series
#30 lore raw
In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.171 release. There are 19 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 Fri, 03 Mar 2023 18:06:43 +0000. Anything received after that time might be too late.

Build test (gcc version 11.3.1 20230210):
mips: 63 configs -> no failure
arm: 104 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure alpha allmodconfig -> no failure powerpc allmodconfig -> no failure riscv allmodconfig -> no failure s390 allmodconfig -> no failure xtensa allmodconfig -> no failure

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]

[1]. https://openqa.qa.codethink.co.uk/tests/2977
[2]. https://openqa.qa.codethink.co.uk/tests/2978

Signature · 2 lines
Regards
Sudip
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 5.10.171 release. There are 19 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 Fri, 03 Mar 2023 18:06:43 +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.171-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.

## Build
* kernel: 5.10.171-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: 032c569d266c83563696ed018f5679bf7b5afe45
* git describe: v5.10.170-20-g032c569d266c
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.170-20-g032c569d266c

## Test Regressions (compared to v5.10.170)

## Metric Regressions (compared to v5.10.170)

## Test Fixes (compared to v5.10.170)

## Metric Fixes (compared to v5.10.170)

## Test result summary
total: 134470, pass: 112238, fail: 3614, skip: 18316, xfail: 302

## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 112 total, 111 passed, 1 failed
* arm64: 39 total, 37 passed, 2 failed
* i386: 30 total, 28 passed, 2 failed
* mips: 24 total, 24 passed, 0 failed
* parisc: 6 total, 6 passed, 0 failed
* powerpc: 23 total, 18 passed, 5 failed
* riscv: 9 total, 9 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 12 total, 12 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 33 total, 31 passed, 2 failed

## Test suites summary
* boot
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* rcutorture
* v4l2-compliance
* vdso

--
Linaro LKFT
https://lkft.linaro.org

#17 lore raw

Re: [PATCH 5.10 16/19] drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling

In reply to Greg Kroah-Hartman

Hi,

Quoted 23 lines · Greg Kroah-Hartman

From: Dmitry Osipenko <[email protected]>

commit 64b88afbd92fbf434759d1896a7cf705e1c00e79 upstream.

Previous commit fixed checking of the ERR_PTR value returned by drm_gem_shmem_get_sg_table(), but it missed to zero out the shmem->pages, which will crash virtio_gpu_cleanup_object(). Add the missing zeroing of the shmem->pages.

---
  drivers/gpu/drm/virtio/virtgpu_object.c |    1 +
  1 file changed, 1 insertion(+)

drivers/gpu/drm/virtio/virtgpu_object.c static int virtio_gpu_object_shmem_init( · line 164

Quoted 6 lines
drivers/gpu/drm/virtio/virtgpu_object.c +1 -0
@@ -159,6 +159,7 @@ static int virtio_gpu_object_shmem_init(
  	shmem->pages = drm_gem_shmem_get_sg_table(&bo->base.base);
  	if (IS_ERR(shmem->pages)) {
  		drm_gem_shmem_unpin(&bo->base.base);
+		shmem->pages = NULL;
  		return PTR_ERR(shmem->pages);
  	}

While doing static analysis with smatch on LTS-rc series I found this bug.

PTR_ERR(NULL) is 1/success, so we are returning success in this case, which looks wrong.

Only 5.10.y and 5.15.y are effected. Upstream commit b5c9ed70d1a9 ("drm/virtio: Improve DMA API usage for shmem BOs") deleted this code, is present in linux-6.1.y and
linux-6.2.y, so this problem is not in 6.1.y and 6.2.y stable releases.

I have prepared a patch for fixing this, will send it out.

Thanks,
Harshit

Quoted 3 lines
#18 lore raw

Re: [PATCH 5.10 16/19] drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling

Quoted 40 lines · Harshit Mogalapalli

Hi,

Quoted 25 lines · Greg Kroah-Hartman

From: Dmitry Osipenko <[email protected]>

commit 64b88afbd92fbf434759d1896a7cf705e1c00e79 upstream.

Previous commit fixed checking of the ERR_PTR value returned by drm_gem_shmem_get_sg_table(), but it missed to zero out the shmem->pages, which will crash virtio_gpu_cleanup_object(). Add the missing zeroing of the shmem->pages.

Fixes c24968734abf ("drm/virtio: Fix NULL vs IS_ERR checking in

virtio_gpu_object_shmem_init")

Link:
https://urldefense.com/v3/__http://patchwork.freedesktop.org/patch/msgid/[email protected]__;!!ACWV5N9M2RV99hQ!KAxF_UJ7x6SleCxrpYd8Huyt4Zj4e08fd9IUL6fl1Wneipk6_LKBnYuqQ2LK0bnvWHC6dxungVXptuvz5-4QQ2zjcq_JT1ub$

---
  drivers/gpu/drm/virtio/virtgpu_object.c |    1 +

  1 file changed, 1 insertion(+)

drivers/gpu/drm/virtio/virtgpu_object.c static int virtio_gpu_object_shmem_init( · line 164

Quoted 6 lines
drivers/gpu/drm/virtio/virtgpu_object.c +1 -0
@@ -159,6 +159,7 @@ static int virtio_gpu_object_shmem_init(
       shmem->pages = drm_gem_shmem_get_sg_table(&bo->base.base);
       if (IS_ERR(shmem->pages)) {
           drm_gem_shmem_unpin(&bo->base.base);
+        shmem->pages = NULL;
           return PTR_ERR(shmem->pages);
       }

While doing static analysis with smatch on LTS-rc series I found this bug.

PTR_ERR(NULL) is 1/success, so we are returning success in this case, which looks wrong.

Quoted 6 lines

Only 5.10.y and 5.15.y are effected. Upstream commit b5c9ed70d1a9 ("drm/virtio: Improve DMA API usage for shmem BOs")
deleted this code, is present in linux-6.1.y and linux-6.2.y, so this problem is not in 6.1.y and 6.2.y stable releases.

I have prepared a patch for fixing this, will send it out.

Thanks, that's a good catch!

Signature · 2 lines
Best regards,
Dmitry
Tested-by on the v1 series
#32 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 5.10.171 release. There are 19 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 Fri, 03 Mar 2023 18:06:43 +0000. Anything received after that time might be too late.

Build results:

	total: 162 pass: 162 fail: 0
Qemu test results:
	total: 478 pass: 478 fail: 0

Guenter