5.15.61-rc1 review

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

---
 Makefile |    5 +++++
 1 file changed, 5 insertions(+)

Makefile +5 -0

@@ -1078,6 +1078,11 @@ KBUILD_CFLAGS   += $(KCFLAGS)
 KBUILD_LDFLAGS_MODULE += --build-id=sha1
 LDFLAGS_vmlinux += --build-id=sha1
 
+KBUILD_LDFLAGS	+= -z noexecstack
+ifeq ($(CONFIG_LD_IS_BFD),y)
+KBUILD_LDFLAGS	+= $(call ld-option,--no-warn-rwx-segments)
+endif
+
 ifeq ($(CONFIG_STRIP_ASM_SYMS),y)
 LDFLAGS_vmlinux	+= $(call ld-option, -X,)
 endif

Greg Kroah-Hartman

author maintainer

2022-08-15 18:14 UTC #2 lore raw

PATCH 2/779 x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments

Link https://lore.kernel.org/linux-block/[email protected]/ open here

From: Nick Desaulniers <[email protected]>

commit ffcf9c5700e49c0aee42dcba9a12ba21338e8136 upstream.

Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instances of a new warning when linking kernels in the form:

ld: warning: arch/x86/boot/pmjump.o: missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
ld: warning: arch/x86/boot/compressed/vmlinux has a LOAD segment with RWX permissions

While the kernel makes extensive usage of ELF sections, it doesn't use permissions from ELF segments.

Link https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107

Link https://github.com/llvm/llvm-project/issues/57009

Reported-and-tested-by Jens Axboe <[email protected]>

Signed-off-by Nick Desaulniers <[email protected]>

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

---
 arch/x86/boot/Makefile            |    2 +-
 arch/x86/boot/compressed/Makefile |    4 ++++
 arch/x86/entry/vdso/Makefile      |    2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

arch/x86/boot/Makefile +1 -1

@@ -103,7 +103,7 @@ $(obj)/zoffset.h: $(obj)/compressed/vmli
 AFLAGS_header.o += -I$(objtree)/$(obj)
 $(obj)/header.o: $(obj)/zoffset.h
 
-LDFLAGS_setup.elf	:= -m elf_i386 -T
+LDFLAGS_setup.elf	:= -m elf_i386 -z noexecstack -T
 $(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
 	$(call if_changed,ld)

arch/x86/boot/compressed/Makefile +4 -0

@@ -69,6 +69,10 @@ LDFLAGS_vmlinux := -pie $(call ld-option
 ifdef CONFIG_LD_ORPHAN_WARN
 LDFLAGS_vmlinux += --orphan-handling=warn
 endif
+LDFLAGS_vmlinux += -z noexecstack
+ifeq ($(CONFIG_LD_IS_BFD),y)
+LDFLAGS_vmlinux += $(call ld-option,--no-warn-rwx-segments)
+endif
 LDFLAGS_vmlinux += -T
 
 hostprogs	:= mkpiggy

arch/x86/entry/vdso/Makefile +1 -1

@@ -179,7 +179,7 @@ quiet_cmd_vdso = VDSO    $@
 		 sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
 
 VDSO_LDFLAGS = -shared --hash-style=both --build-id=sha1 \
-	$(call ld-option, --eh-frame-hdr) -Bsymbolic
+	$(call ld-option, --eh-frame-hdr) -Bsymbolic -z noexecstack
 GCOV_PROFILE := n
 
 quiet_cmd_vdso_and_check = VDSO    $@

Greg Kroah-Hartman

author maintainer

2022-08-15 18:14 UTC #3 lore raw

PATCH 3/779 Revert "pNFS: nfs3_set_ds_client should set NFS_CS_NOPING"

From: Trond Myklebust <[email protected]>

commit 9597152d98840c2517230740952df97cfcc07e2f upstream.

This reverts commit c6eb58435b98bd843d3179664a0195ff25adb2c3. If a transport is down, then we want to fail over to other transports if they are listed in the GETDEVICEINFO reply.

Fixes c6eb58435b98 ("pNFS: nfs3_set_ds_client should set NFS_CS_NOPING")

Cc [email protected] # 5.11.x

Signed-off-by Trond Myklebust <[email protected]>

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

---
 fs/nfs/nfs3client.c |    1 -
 1 file changed, 1 deletion(-)

fs/nfs/nfs3client.c +0 -1

@@ -108,7 +108,6 @@ struct nfs_client *nfs3_set_ds_client(st
 	if (mds_srv->flags & NFS_MOUNT_NORESVPORT)
 		__set_bit(NFS_CS_NORESVPORT, &cl_init.init_flags);
 
-	__set_bit(NFS_CS_NOPING, &cl_init.init_flags);
 	__set_bit(NFS_CS_DS, &cl_init.init_flags);
 
 	/* Use the MDS nfs_client cl_ipaddr. */

Greg Kroah-Hartman

author maintainer

2022-08-15 18:14 UTC #4 lore raw

PATCH 4/779 scsi: Revert "scsi: qla2xxx: Fix disk failure to rediscover"

From: Nilesh Javali <[email protected]>

commit 5bc7b01c513a4a9b4cfe306e8d1720cfcfd3b8a3 upstream.

This fixes the regression of NVMe discovery failure during driver load time.

This reverts commit 6a45c8e137d4e2c72eecf1ac7cf64f2fdfcead99.

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

Reviewed-by Himanshu Madhani <[email protected]>

Signed-off-by Nilesh Javali <[email protected]>

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

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

---
 drivers/scsi/qla2xxx/qla_init.c |    5 ++---
 drivers/scsi/qla2xxx/qla_nvme.c |    5 -----
 2 files changed, 2 insertions(+), 8 deletions(-)

drivers/scsi/qla2xxx/qla_init.c +2 -3

@@ -5749,8 +5749,6 @@ qla2x00_reg_remote_port(scsi_qla_host_t
 	if (atomic_read(&fcport->state) == FCS_ONLINE)
 		return;
 
-	qla2x00_set_fcport_state(fcport, FCS_ONLINE);
-
 	rport_ids.node_name = wwn_to_u64(fcport->node_name);
 	rport_ids.port_name = wwn_to_u64(fcport->port_name);
 	rport_ids.port_id = fcport->d_id.b.domain << 16 |

@@ -5858,7 +5856,6 @@ qla2x00_update_fcport(scsi_qla_host_t *v
 		qla2x00_reg_remote_port(vha, fcport);
 		break;
 	case MODE_TARGET:
-		qla2x00_set_fcport_state(fcport, FCS_ONLINE);
 		if (!vha->vha_tgt.qla_tgt->tgt_stop &&
 			!vha->vha_tgt.qla_tgt->tgt_stopped)
 			qlt_fc_port_added(vha, fcport);

@@ -5873,6 +5870,8 @@ qla2x00_update_fcport(scsi_qla_host_t *v
 		break;
 	}
 
+	qla2x00_set_fcport_state(fcport, FCS_ONLINE);
+
 	if (IS_IIDMA_CAPABLE(vha->hw) && vha->hw->flags.gpsc_supported) {
 		if (fcport->id_changed) {
 			fcport->id_changed = 0;

drivers/scsi/qla2xxx/qla_nvme.c +0 -5

@@ -35,11 +35,6 @@ int qla_nvme_register_remote(struct scsi
 		(fcport->nvme_flag & NVME_FLAG_REGISTERED))
 		return 0;
 
-	if (atomic_read(&fcport->state) == FCS_ONLINE)
-		return 0;
-
-	qla2x00_set_fcport_state(fcport, FCS_ONLINE);
-
 	fcport->nvme_flag &= ~NVME_FLAG_RESETTING;
 
 	memset(&req, 0, sizeof(struct nvme_fc_port_info));

Greg Kroah-Hartman

author maintainer

2022-08-15 18:14 UTC #5 lore raw

PATCH 5/779 pNFS/flexfiles: Report RDMA connection errors to the server

From: Trond Myklebust <[email protected]>

commit 7836d75467e9d214bdf5c693b32721de729a6e38 upstream.

The RPC/RDMA driver will return -EPROTO and -ENODEV as connection errors under certain circumstances. Make sure that we handle them and report them to the server. If not, we can end up cycling forever in a LAYOUTGET/LAYOUTRETURN loop.

Fixes a12f996d3413 ("NFSv4/pNFS: Use connections to a DS that are all of the same protocol family")

Cc [email protected] # 5.11.x

Signed-off-by Trond Myklebust <[email protected]>

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

---
 fs/nfs/flexfilelayout/flexfilelayout.c |    4 ++++
 1 file changed, 4 insertions(+)

fs/nfs/flexfilelayout/flexfilelayout.c +4 -0

@@ -1140,6 +1140,8 @@ static int ff_layout_async_handle_error_
 	case -EIO:
 	case -ETIMEDOUT:
 	case -EPIPE:
+	case -EPROTO:
+	case -ENODEV:
 		dprintk("%s DS connection error %d\n", __func__,
 			task->tk_status);
 		nfs4_delete_deviceid(devid->ld, devid->nfs_client,

@@ -1245,6 +1247,8 @@ static void ff_layout_io_track_ds_error(
 		case -ENOBUFS:
 		case -EPIPE:
 		case -EPERM:
+		case -EPROTO:
+		case -ENODEV:
 			*op_status = status = NFS4ERR_NXIO;
 			break;
 		case -EACCES:

Greg Kroah-Hartman

author maintainer

2022-08-15 18:14 UTC #6 lore raw

PATCH 6/779 NFSD: Clean up the show_nf_flags() macro

From: Chuck Lever <[email protected]>

commit bb283ca18d1e67c82d22a329c96c9d6036a74790 upstream.

The flags are defined using C macros, so TRACE_DEFINE_ENUM is unnecessary.

Signed-off-by Chuck Lever <[email protected]>

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

---
 fs/nfsd/trace.h |    6 ------
 1 file changed, 6 deletions(-)

fs/nfsd/trace.h +0 -6

@@ -636,12 +636,6 @@ DEFINE_CLID_EVENT(confirmed_r);
 /*
  * from fs/nfsd/filecache.h
  */
-TRACE_DEFINE_ENUM(NFSD_FILE_HASHED);
-TRACE_DEFINE_ENUM(NFSD_FILE_PENDING);
-TRACE_DEFINE_ENUM(NFSD_FILE_BREAK_READ);
-TRACE_DEFINE_ENUM(NFSD_FILE_BREAK_WRITE);
-TRACE_DEFINE_ENUM(NFSD_FILE_REFERENCED);
-
 #define show_nf_flags(val)						\
 	__print_flags(val, "|",						\
 		{ 1 << NFSD_FILE_HASHED,	"HASHED" },		\

Greg Kroah-Hartman

author maintainer

2022-08-15 18:14 UTC #7 lore raw

PATCH 7/779 nfsd: eliminate the NFSD_FILE_BREAK_* flags

Link https://bugzilla.redhat.com/show_bug.cgi?id=2107360

From: Jeff Layton <[email protected]>

commit 23ba98de6dcec665e15c0ca19244379bb0d30932 upstream.

We had a report from the spring Bake-a-thon of data corruption in some nfstest_interop tests. Looking at the traces showed the NFS server allowing a v3 WRITE to proceed while a read delegation was still outstanding.

Currently, we only set NFSD_FILE_BREAK_* flags if NFSD_MAY_NOT_BREAK_LEASE was set when we call nfsd_file_alloc. NFSD_MAY_NOT_BREAK_LEASE was intended to be set when finding files for COMMIT ops, where we need a writeable filehandle but don't need to break read leases.

It doesn't make any sense to consult that flag when allocating a file since the file may be used on subsequent calls where we do want to break the lease (and the usage of it here seems to be reverse from what it should be anyway).

Also, after calling nfsd_open_break_lease, we don't want to clear the BREAK_* bits. A lease could end up being set on it later (more than once) and we need to be able to break those leases as well.

This means that the NFSD_FILE_BREAK_* flags now just mirror NFSD_MAY_{READ,WRITE} flags, so there's no need for them at all. Just drop those flags and unconditionally call nfsd_open_break_lease every time.

Reported-by Olga Kornieskaia <[email protected]>

Fixes 65294c1f2c5e (nfsd: add a new struct file caching facility to nfsd)

Cc <[email protected]> # 5.4.x : bb283ca18d1e NFSD: Clean up the show_nf_flags() macro

Cc <[email protected]> # 5.4.x

Signed-off-by Jeff Layton <[email protected]>

Signed-off-by Chuck Lever <[email protected]>

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

---
 fs/nfsd/filecache.c |   22 +---------------------
 fs/nfsd/filecache.h |    4 +---
 fs/nfsd/trace.h     |    2 --
 3 files changed, 2 insertions(+), 26 deletions(-)

fs/nfsd/filecache.c +1 ~~-21~~

@@ -187,12 +187,6 @@ nfsd_file_alloc(struct inode *inode, uns
 		nf->nf_hashval = hashval;
 		refcount_set(&nf->nf_ref, 1);
 		nf->nf_may = may & NFSD_FILE_MAY_MASK;
-		if (may & NFSD_MAY_NOT_BREAK_LEASE) {
-			if (may & NFSD_MAY_WRITE)
-				__set_bit(NFSD_FILE_BREAK_WRITE, &nf->nf_flags);
-			if (may & NFSD_MAY_READ)
-				__set_bit(NFSD_FILE_BREAK_READ, &nf->nf_flags);
-		}
 		nf->nf_mark = NULL;
 		trace_nfsd_file_alloc(nf);
 	}

@@ -990,21 +984,7 @@ wait_for_construction:
 
 	this_cpu_inc(nfsd_file_cache_hits);
 
-	if (!(may_flags & NFSD_MAY_NOT_BREAK_LEASE)) {
-		bool write = (may_flags & NFSD_MAY_WRITE);
-
-		if (test_bit(NFSD_FILE_BREAK_READ, &nf->nf_flags) ||
-		    (test_bit(NFSD_FILE_BREAK_WRITE, &nf->nf_flags) && write)) {
-			status = nfserrno(nfsd_open_break_lease(
-					file_inode(nf->nf_file), may_flags));
-			if (status == nfs_ok) {
-				clear_bit(NFSD_FILE_BREAK_READ, &nf->nf_flags);
-				if (write)
-					clear_bit(NFSD_FILE_BREAK_WRITE,
-						  &nf->nf_flags);
-			}
-		}
-	}
+	status = nfserrno(nfsd_open_break_lease(file_inode(nf->nf_file), may_flags));
 out:
 	if (status == nfs_ok) {
 		*pnf = nf;

fs/nfsd/filecache.h +1 -3

@@ -37,9 +37,7 @@ struct nfsd_file {
 	struct net		*nf_net;
 #define NFSD_FILE_HASHED	(0)
 #define NFSD_FILE_PENDING	(1)
-#define NFSD_FILE_BREAK_READ	(2)
-#define NFSD_FILE_BREAK_WRITE	(3)
-#define NFSD_FILE_REFERENCED	(4)
+#define NFSD_FILE_REFERENCED	(2)
 	unsigned long		nf_flags;
 	struct inode		*nf_inode;
 	unsigned int		nf_hashval;

fs/nfsd/trace.h +0 -2

@@ -640,8 +640,6 @@ DEFINE_CLID_EVENT(confirmed_r);
 	__print_flags(val, "|",						\
 		{ 1 << NFSD_FILE_HASHED,	"HASHED" },		\
 		{ 1 << NFSD_FILE_PENDING,	"PENDING" },		\
-		{ 1 << NFSD_FILE_BREAK_READ,	"BREAK_READ" },		\
-		{ 1 << NFSD_FILE_BREAK_WRITE,	"BREAK_WRITE" },	\
 		{ 1 << NFSD_FILE_REFERENCED,	"REFERENCED"})
 
 DECLARE_EVENT_CLASS(nfsd_file_class,

Greg Kroah-Hartman

author maintainer

2022-08-15 18:14 UTC #8 lore raw

PATCH 8/779 ALSA: usb-audio: Add quirk for Behringer UMC202HD

From: Takashi Iwai <[email protected]>

commit e086c37f876fd1f551e2b4f9be97d4a1923cd219 upstream.

Just like other Behringer models, UMC202HD (USB ID 1397:0507) requires the quirk for the stable streaming, too.

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

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

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

---
 sound/usb/quirks.c |    2 ++
 1 file changed, 2 insertions(+)

sound/usb/quirks.c +2 -0

@@ -1843,6 +1843,8 @@ static const struct usb_audio_quirk_flag
 		   QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
 	DEVICE_FLG(0x1395, 0x740a, /* Sennheiser DECT */
 		   QUIRK_FLAG_GET_SAMPLE_RATE),
+	DEVICE_FLG(0x1397, 0x0507, /* Behringer UMC202HD */
+		   QUIRK_FLAG_PLAYBACK_FIRST | QUIRK_FLAG_GENERIC_IMPLICIT_FB),
 	DEVICE_FLG(0x1397, 0x0508, /* Behringer UMC204HD */
 		   QUIRK_FLAG_PLAYBACK_FIRST | QUIRK_FLAG_GENERIC_IMPLICIT_FB),
 	DEVICE_FLG(0x1397, 0x0509, /* Behringer UMC404HD */

Greg Kroah-Hartman

author maintainer

2022-08-15 18:14 UTC #9 lore raw

PATCH 9/779 ALSA: bcd2000: Fix a UAF bug on the error path of probing

From: Zheyu Ma <[email protected]>

commit ffb2759df7efbc00187bfd9d1072434a13a54139 upstream.

When the driver fails in snd_card_register() at probe time, it will free the 'bcd2k->midi_out_urb' before killing it, which may cause a UAF bug.

The following log can reveal it:

[   50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]
[   50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0
[   50.729530] Call Trace:
[   50.732899]  bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]

Fix this by adding usb_kill_urb() before usb_free_urb().

Fixes b47a22290d58 ("ALSA: MIDI driver for Behringer BCD2000 USB device")

Signed-off-by Zheyu Ma <[email protected]>

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

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

---
 sound/usb/bcd2000/bcd2000.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

sound/usb/bcd2000/bcd2000.c +2 -1

@@ -348,7 +348,8 @@ static int bcd2000_init_midi(struct bcd2
 static void bcd2000_free_usb_related_resources(struct bcd2000 *bcd2k,
 						struct usb_interface *interface)
 {
-	/* usb_kill_urb not necessary, urb is aborted automatically */
+	usb_kill_urb(bcd2k->midi_out_urb);
+	usb_kill_urb(bcd2k->midi_in_urb);
 
 	usb_free_urb(bcd2k->midi_out_urb);
 	usb_free_urb(bcd2k->midi_in_urb);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:13 UTC #10 lore raw

PATCH 10/779 ALSA: hda/realtek: Add quirk for Clevo NV45PZ

From: Tim Crawford <[email protected]>

commit be561ffad708f0cee18aee4231f80ffafaf7a419 upstream.

Fixes headset detection on Clevo NV45PZ.

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

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

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

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

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

@@ -8992,6 +8992,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1558, 0x4018, "Clevo NV40M[BE]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x4019, "Clevo NV40MZ", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x4020, "Clevo NV40MB", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1558, 0x4041, "Clevo NV4[15]PZ", ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x40a1, "Clevo NL40GU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x40c1, "Clevo NL40[CZ]U", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1558, 0x40d1, "Clevo NL41DU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),

Greg Kroah-Hartman

author maintainer

2022-08-15 18:13 UTC #11 lore raw

PATCH 11/779 ALSA: hda/realtek: Add quirk for HP Spectre x360 15-eb0xxx

From: Ivan Hasenkampf <[email protected]>

commit 24df5428ef9d1ca1edd54eca7eb667110f2dfae3 upstream.

Fixes speaker output on HP Spectre x360 15-eb0xxx

[ re-sorted in SSID order by tiwai ]

Signed-off-by Ivan Hasenkampf <[email protected]>

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

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

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

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

@@ -8852,6 +8852,8 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x103c, 0x861f, "HP Elite Dragonfly G1", ALC285_FIXUP_HP_GPIO_AMP_INIT),
 	SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x86c7, "HP Envy AiO 32", ALC274_FIXUP_HP_ENVY_GPIO),
+	SND_PCI_QUIRK(0x103c, 0x86e7, "HP Spectre x360 15-eb0xxx", ALC285_FIXUP_HP_SPECTRE_X360_EB1),
+	SND_PCI_QUIRK(0x103c, 0x86e8, "HP Spectre x360 15-eb0xxx", ALC285_FIXUP_HP_SPECTRE_X360_EB1),
 	SND_PCI_QUIRK(0x103c, 0x8716, "HP Elite Dragonfly G2 Notebook PC", ALC285_FIXUP_HP_GPIO_AMP_INIT),
 	SND_PCI_QUIRK(0x103c, 0x8720, "HP EliteBook x360 1040 G8 Notebook PC", ALC285_FIXUP_HP_GPIO_AMP_INIT),
 	SND_PCI_QUIRK(0x103c, 0x8724, "HP EliteBook 850 G7", ALC285_FIXUP_HP_GPIO_LED),

Greg Kroah-Hartman

author maintainer

2022-08-15 18:13 UTC #12 lore raw

PATCH 12/779 wifi: mac80211_hwsim: fix race condition in pending packet

From: Jeongik Cha <[email protected]>

commit 4ee186fa7e40ae06ebbfbad77e249e3746e14114 upstream.

A pending packet uses a cookie as an unique key, but it can be duplicated because it didn't use atomic operators.

And also, a pending packet can be null in hwsim_tx_info_frame_received_nl due to race condition with mac80211_hwsim_stop.

For this,
* Use an atomic type and operator for a cookie
* Add a lock around the loop for pending packets

Signed-off-by Jeongik Cha <[email protected]>

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

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

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

---
 drivers/net/wireless/mac80211_hwsim.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

drivers/net/wireless/mac80211_hwsim.c +8 -6

@@ -663,7 +663,7 @@ struct mac80211_hwsim_data {
 	bool ps_poll_pending;
 	struct dentry *debugfs;
 
-	uintptr_t pending_cookie;
+	atomic64_t pending_cookie;
 	struct sk_buff_head pending;	/* packets pending */
 	/*
 	 * Only radios in the same group can communicate together (the

@@ -1270,7 +1270,7 @@ static void mac80211_hwsim_tx_frame_nl(s
 	int i;
 	struct hwsim_tx_rate tx_attempts[IEEE80211_TX_MAX_RATES];
 	struct hwsim_tx_rate_flag tx_attempts_flags[IEEE80211_TX_MAX_RATES];
-	uintptr_t cookie;
+	u64 cookie;
 
 	if (data->ps != PS_DISABLED)
 		hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_PM);

@@ -1339,8 +1339,7 @@ static void mac80211_hwsim_tx_frame_nl(s
 		goto nla_put_failure;
 
 	/* We create a cookie to identify this skb */
-	data->pending_cookie++;
-	cookie = data->pending_cookie;
+	cookie = (u64)atomic64_inc_return(&data->pending_cookie);
 	info->rate_driver_data[0] = (void *)cookie;
 	if (nla_put_u64_64bit(skb, HWSIM_ATTR_COOKIE, cookie, HWSIM_ATTR_PAD))
 		goto nla_put_failure;

@@ -3582,6 +3581,7 @@ static int hwsim_tx_info_frame_received_
 	const u8 *src;
 	unsigned int hwsim_flags;
 	int i;
+	unsigned long flags;
 	bool found = false;
 
 	if (!info->attrs[HWSIM_ATTR_ADDR_TRANSMITTER] ||

@@ -3609,18 +3609,20 @@ static int hwsim_tx_info_frame_received_
 	}
 
 	/* look for the skb matching the cookie passed back from user */
+	spin_lock_irqsave(&data2->pending.lock, flags);
 	skb_queue_walk_safe(&data2->pending, skb, tmp) {
 		u64 skb_cookie;
 
 		txi = IEEE80211_SKB_CB(skb);
-		skb_cookie = (u64)(uintptr_t)txi->rate_driver_data[0];
+		skb_cookie = (u64)txi->rate_driver_data[0];
 
 		if (skb_cookie == ret_skb_cookie) {
-			skb_unlink(skb, &data2->pending);
+			__skb_unlink(skb, &data2->pending);
 			found = true;
 			break;
 		}
 	}
+	spin_unlock_irqrestore(&data2->pending.lock, flags);
 
 	/* not found */
 	if (!found)

Greg Kroah-Hartman

author maintainer

2022-08-15 18:13 UTC #13 lore raw

PATCH 13/779 wifi: mac80211_hwsim: add back erroneously removed cast

From: Johannes Berg <[email protected]>

commit 58b6259d820d63c2adf1c7541b54cce5a2ae6073 upstream.

The robots report that we're now casting to a differently sized integer, which is correct, and the previous patch had erroneously removed it.

Fixes 4ee186fa7e40 ("wifi: mac80211_hwsim: fix race condition in pending packet")

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

Cc Jeongik Cha <[email protected]>

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

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

drivers/net/wireless/mac80211_hwsim.c +1 -1

@@ -3614,7 +3614,7 @@ static int hwsim_tx_info_frame_received_
 		u64 skb_cookie;
 
 		txi = IEEE80211_SKB_CB(skb);
-		skb_cookie = (u64)txi->rate_driver_data[0];
+		skb_cookie = (u64)(uintptr_t)txi->rate_driver_data[0];
 
 		if (skb_cookie == ret_skb_cookie) {
 			__skb_unlink(skb, &data2->pending);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:13 UTC #14 lore raw

PATCH 14/779 wifi: mac80211_hwsim: use 32-bit skb cookie

From: Johannes Berg <[email protected]>

commit cc5250cdb43d444061412df7fae72d2b4acbdf97 upstream.

We won't really have enough skbs to need a 64-bit cookie, and on 32-bit platforms storing the 64-bit cookie into the void *rate_driver_data doesn't work anyway. Switch back to using just a 32-bit cookie and uintptr_t for the type to avoid compiler warnings about all this.

Fixes 4ee186fa7e40 ("wifi: mac80211_hwsim: fix race condition in pending packet")

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

Cc Jeongik Cha <[email protected]>

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

---
 drivers/net/wireless/mac80211_hwsim.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/net/wireless/mac80211_hwsim.c +5 -5

@@ -663,7 +663,7 @@ struct mac80211_hwsim_data {
 	bool ps_poll_pending;
 	struct dentry *debugfs;
 
-	atomic64_t pending_cookie;
+	atomic_t pending_cookie;
 	struct sk_buff_head pending;	/* packets pending */
 	/*
 	 * Only radios in the same group can communicate together (the

@@ -1270,7 +1270,7 @@ static void mac80211_hwsim_tx_frame_nl(s
 	int i;
 	struct hwsim_tx_rate tx_attempts[IEEE80211_TX_MAX_RATES];
 	struct hwsim_tx_rate_flag tx_attempts_flags[IEEE80211_TX_MAX_RATES];
-	u64 cookie;
+	uintptr_t cookie;
 
 	if (data->ps != PS_DISABLED)
 		hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_PM);

@@ -1339,7 +1339,7 @@ static void mac80211_hwsim_tx_frame_nl(s
 		goto nla_put_failure;
 
 	/* We create a cookie to identify this skb */
-	cookie = (u64)atomic64_inc_return(&data->pending_cookie);
+	cookie = atomic_inc_return(&data->pending_cookie);
 	info->rate_driver_data[0] = (void *)cookie;
 	if (nla_put_u64_64bit(skb, HWSIM_ATTR_COOKIE, cookie, HWSIM_ATTR_PAD))
 		goto nla_put_failure;

@@ -3611,10 +3611,10 @@ static int hwsim_tx_info_frame_received_
 	/* look for the skb matching the cookie passed back from user */
 	spin_lock_irqsave(&data2->pending.lock, flags);
 	skb_queue_walk_safe(&data2->pending, skb, tmp) {
-		u64 skb_cookie;
+		uintptr_t skb_cookie;
 
 		txi = IEEE80211_SKB_CB(skb);
-		skb_cookie = (u64)(uintptr_t)txi->rate_driver_data[0];
+		skb_cookie = (uintptr_t)txi->rate_driver_data[0];
 
 		if (skb_cookie == ret_skb_cookie) {
 			__skb_unlink(skb, &data2->pending);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:13 UTC #15 lore raw

PATCH 15/779 add barriers to buffer_uptodate and set_buffer_uptodate

From: Mikulas Patocka <[email protected]>

commit d4252071b97d2027d246f6a82cbee4d52f618b47 upstream.

Let's have a look at this piece of code in __bread_slow:

	get_bh(bh);
	bh->b_end_io = end_buffer_read_sync;
	submit_bh(REQ_OP_READ, 0, bh);
	wait_on_buffer(bh);
	if (buffer_uptodate(bh))
		return bh;

Neither wait_on_buffer nor buffer_uptodate contain any memory barrier. Consequently, if someone calls sb_bread and then reads the buffer data, the read of buffer data may be executed before wait_on_buffer(bh) on architectures with weak memory ordering and it may return invalid data.

Fix this bug by adding a memory barrier to set_buffer_uptodate and an acquire barrier to buffer_uptodate (in a similar way as folio_test_uptodate and folio_mark_uptodate).

Signed-off-by Mikulas Patocka <[email protected]>

Reviewed-by Matthew Wilcox (Oracle) <[email protected]>

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

---
 include/linux/buffer_head.h |   25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

include/linux/buffer_head.h +24 -1

@@ -117,7 +117,6 @@ static __always_inline int test_clear_bu
  * of the form "mark_buffer_foo()".  These are higher-level functions which
  * do something in addition to setting a b_state bit.
  */
-BUFFER_FNS(Uptodate, uptodate)
 BUFFER_FNS(Dirty, dirty)
 TAS_BUFFER_FNS(Dirty, dirty)
 BUFFER_FNS(Lock, locked)

@@ -135,6 +134,30 @@ BUFFER_FNS(Meta, meta)
 BUFFER_FNS(Prio, prio)
 BUFFER_FNS(Defer_Completion, defer_completion)
 
+static __always_inline void set_buffer_uptodate(struct buffer_head *bh)
+{
+	/*
+	 * make it consistent with folio_mark_uptodate
+	 * pairs with smp_load_acquire in buffer_uptodate
+	 */
+	smp_mb__before_atomic();
+	set_bit(BH_Uptodate, &bh->b_state);
+}
+
+static __always_inline void clear_buffer_uptodate(struct buffer_head *bh)
+{
+	clear_bit(BH_Uptodate, &bh->b_state);
+}
+
+static __always_inline int buffer_uptodate(const struct buffer_head *bh)
+{
+	/*
+	 * make it consistent with folio_test_uptodate
+	 * pairs with smp_mb__before_atomic in set_buffer_uptodate
+	 */
+	return (smp_load_acquire(&bh->b_state) & (1UL << BH_Uptodate)) != 0;
+}
+
 #define bh_offset(bh)		((unsigned long)(bh)->b_data & ~PAGE_MASK)
 
 /* If we *know* page->private refers to buffer_heads */

Greg Kroah-Hartman

author maintainer

2022-08-15 18:14 UTC #16 lore raw

PATCH 16/779 lockd: detect and reject lock arguments that overflow

Link https://bugzilla.linux-nfs.org/show_bug.cgi?id=392

From: Jeff Layton <[email protected]>

commit 6930bcbfb6ceda63e298c6af6d733ecdf6bd4cde upstream.

lockd doesn't currently vet the start and length in nlm4 requests like it should, and can end up generating lock requests with arguments that overflow when passed to the filesystem.

The NLM4 protocol uses unsigned 64-bit arguments for both start and length, whereas struct file_lock tracks the start and end as loff_t values. By the time we get around to calling nlm4svc_retrieve_args, we've lost the information that would allow us to determine if there was an overflow.

Start tracking the actual start and len for NLM4 requests in the nlm_lock. In nlm4svc_retrieve_args, vet these values to ensure they won't cause an overflow, and return NLM4_FBIG if they do.

Reported-by Jan Kasiak <[email protected]>

Signed-off-by Jeff Layton <[email protected]>

Signed-off-by Chuck Lever <[email protected]>

Cc <[email protected]> # 5.14+

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

---
 fs/lockd/svc4proc.c       |  8 ++++++++
 fs/lockd/xdr4.c           | 19 ++-----------------
 include/linux/lockd/xdr.h |  2 ++
 3 files changed, 12 insertions(+), 17 deletions(-)

fs/lockd/svc4proc.c +8 -0

index 4f247ab8be61..bf274f23969b 100644
@@ -32,6 +32,10 @@ nlm4svc_retrieve_args(struct svc_rqst *rqstp, struct nlm_args *argp,
 	if (!nlmsvc_ops)
 		return nlm_lck_denied_nolocks;
 
+	if (lock->lock_start > OFFSET_MAX ||
+	    (lock->lock_len && ((lock->lock_len - 1) > (OFFSET_MAX - lock->lock_start))))
+		return nlm4_fbig;
+
 	/* Obtain host handle */
 	if (!(host = nlmsvc_lookup_host(rqstp, lock->caller, lock->len))
 	 || (argp->monitor && nsm_monitor(host) < 0))

@@ -50,6 +54,10 @@ nlm4svc_retrieve_args(struct svc_rqst *rqstp, struct nlm_args *argp,
 		/* Set up the missing parts of the file_lock structure */
 		lock->fl.fl_file  = file->f_file[mode];
 		lock->fl.fl_pid = current->tgid;
+		lock->fl.fl_start = (loff_t)lock->lock_start;
+		lock->fl.fl_end = lock->lock_len ?
+				   (loff_t)(lock->lock_start + lock->lock_len - 1) :
+				   OFFSET_MAX;
 		lock->fl.fl_lmops = &nlmsvc_lock_operations;
 		nlmsvc_locks_init_private(&lock->fl, host, (pid_t)lock->svid);
 		if (!lock->fl.fl_owner) {

fs/lockd/xdr4.c +2 ~~-17~~

index 856267c0864b..712fdfeb8ef0 100644
@@ -20,13 +20,6 @@
 
 #include "svcxdr.h"
 
-static inline loff_t
-s64_to_loff_t(__s64 offset)
-{
-	return (loff_t)offset;
-}
-
-
 static inline s64
 loff_t_to_s64(loff_t offset)
 {

@@ -70,8 +63,6 @@ static bool
 svcxdr_decode_lock(struct xdr_stream *xdr, struct nlm_lock *lock)
 {
 	struct file_lock *fl = &lock->fl;
-	u64 len, start;
-	s64 end;
 
 	if (!svcxdr_decode_string(xdr, &lock->caller, &lock->len))
 		return false;

@@ -81,20 +72,14 @@ svcxdr_decode_lock(struct xdr_stream *xdr, struct nlm_lock *lock)
 		return false;
 	if (xdr_stream_decode_u32(xdr, &lock->svid) < 0)
 		return false;
-	if (xdr_stream_decode_u64(xdr, &start) < 0)
+	if (xdr_stream_decode_u64(xdr, &lock->lock_start) < 0)
 		return false;
-	if (xdr_stream_decode_u64(xdr, &len) < 0)
+	if (xdr_stream_decode_u64(xdr, &lock->lock_len) < 0)
 		return false;
 
 	locks_init_lock(fl);
 	fl->fl_flags = FL_POSIX;
 	fl->fl_type  = F_RDLCK;
-	end = start + len - 1;
-	fl->fl_start = s64_to_loff_t(start);
-	if (len == 0 || end < 0)
-		fl->fl_end = OFFSET_MAX;
-	else
-		fl->fl_end = s64_to_loff_t(end);
 
 	return true;
 }

include/linux/lockd/xdr.h +2 -0

index 398f70093cd3..67e4a2c5500b 100644
@@ -41,6 +41,8 @@ struct nlm_lock {
 	struct nfs_fh		fh;
 	struct xdr_netobj	oh;
 	u32			svid;
+	u64			lock_start;
+	u64			lock_len;
 	struct file_lock	fl;
 };

Signature · 1 line

2.37.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:19 UTC #17 lore raw

PATCH 17/779 HID: hid-input: add Surface Go battery quirk

From: Maximilian Luz <[email protected]>

commit db925d809011c37b246434fdce71209fc2e6c0c2 upstream.

Similar to the Surface Go (1), the (Elantech) touchscreen/digitizer in the Surface Go 2 mistakenly reports the battery of the stylus. Instead of over the touchscreen device, battery information is provided via bluetooth and the touchscreen device reports an empty battery.

Apply the HID_BATTERY_QUIRK_IGNORE quirk to ignore this battery and prevent the erroneous low battery warnings.

Signed-off-by Maximilian Luz <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

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

---
 drivers/hid/hid-ids.h   |    1 +
 drivers/hid/hid-input.c |    2 ++
 2 files changed, 3 insertions(+)

drivers/hid/hid-ids.h +1 -0

@@ -398,6 +398,7 @@
 #define USB_DEVICE_ID_ASUS_UX550VE_TOUCHSCREEN	0x2544
 #define USB_DEVICE_ID_ASUS_UX550_TOUCHSCREEN	0x2706
 #define I2C_DEVICE_ID_SURFACE_GO_TOUCHSCREEN	0x261A
+#define I2C_DEVICE_ID_SURFACE_GO2_TOUCHSCREEN	0x2A1C
 
 #define USB_VENDOR_ID_ELECOM		0x056e
 #define USB_DEVICE_ID_ELECOM_BM084	0x0061

drivers/hid/hid-input.c +2 -0

@@ -333,6 +333,8 @@ static const struct hid_device_id hid_ba
 	  HID_BATTERY_QUIRK_IGNORE },
 	{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_SURFACE_GO_TOUCHSCREEN),
 	  HID_BATTERY_QUIRK_IGNORE },
+	{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_SURFACE_GO2_TOUCHSCREEN),
+	  HID_BATTERY_QUIRK_IGNORE },
 	{}
 };

Greg Kroah-Hartman

author maintainer

2022-08-15 18:15 UTC #18 lore raw

PATCH 18/779 HID: wacom: Only report rotation for art pen

From: Ping Cheng <[email protected]>

commit 7ccced33a0ba39b0103ae1dfbf7f1dffdc0a1bc2 upstream.

The generic routine, wacom_wac_pen_event, turns rotation value 90 degree anti-clockwise before posting the events. This non-zero event trggers a non-zero ABS_Z event for non art pen tools. However, HID_DG_TWIST is only supported by art pen.

[[email protected]: fix build: add missing brace]

Signed-off-by Ping Cheng <[email protected]>

Reviewed-by Jason Gerecke <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

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

---
 drivers/hid/wacom_wac.c |   29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)

drivers/hid/wacom_wac.c +21 -8

@@ -638,9 +638,26 @@ static int wacom_intuos_id_mangle(int to
 	return (tool_id & ~0xFFF) << 4 | (tool_id & 0xFFF);
 }
 
+static bool wacom_is_art_pen(int tool_id)
+{
+	bool is_art_pen = false;
+
+	switch (tool_id) {
+	case 0x885:	/* Intuos3 Marker Pen */
+	case 0x804:	/* Intuos4/5 13HD/24HD Marker Pen */
+	case 0x10804:	/* Intuos4/5 13HD/24HD Art Pen */
+		is_art_pen = true;
+		break;
+	}
+	return is_art_pen;
+}
+
 static int wacom_intuos_get_tool_type(int tool_id)
 {
-	int tool_type;
+	int tool_type = BTN_TOOL_PEN;
+
+	if (wacom_is_art_pen(tool_id))
+		return tool_type;
 
 	switch (tool_id) {
 	case 0x812: /* Inking pen */

@@ -655,12 +672,9 @@ static int wacom_intuos_get_tool_type(in
 	case 0x852:
 	case 0x823: /* Intuos3 Grip Pen */
 	case 0x813: /* Intuos3 Classic Pen */
-	case 0x885: /* Intuos3 Marker Pen */
 	case 0x802: /* Intuos4/5 13HD/24HD General Pen */
-	case 0x804: /* Intuos4/5 13HD/24HD Marker Pen */
 	case 0x8e2: /* IntuosHT2 pen */
 	case 0x022:
-	case 0x10804: /* Intuos4/5 13HD/24HD Art Pen */
 	case 0x10842: /* MobileStudio Pro Pro Pen slim */
 	case 0x14802: /* Intuos4/5 13HD/24HD Classic Pen */
 	case 0x16802: /* Cintiq 13HD Pro Pen */

@@ -718,10 +732,6 @@ static int wacom_intuos_get_tool_type(in
 	case 0x10902: /* Intuos4/5 13HD/24HD Airbrush */
 		tool_type = BTN_TOOL_AIRBRUSH;
 		break;
-
-	default: /* Unknown tool */
-		tool_type = BTN_TOOL_PEN;
-		break;
 	}
 	return tool_type;
 }

@@ -2323,6 +2333,9 @@ static void wacom_wac_pen_event(struct h
 		}
 		return;
 	case HID_DG_TWIST:
+		/* don't modify the value if the pen doesn't support the feature */
+		if (!wacom_is_art_pen(wacom_wac->id[0])) return;
+
 		/*
 		 * Userspace expects pen twist to have its zero point when
 		 * the buttons/finger is on the tablet's left. HID values

Greg Kroah-Hartman

author maintainer

2022-08-15 18:17 UTC #19 lore raw

PATCH 19/779 HID: wacom: Dont register pad_input for touch switch

From: Ping Cheng <[email protected]>

commit d6b675687a4ab4dba684716d97c8c6f81bf10905 upstream.

Touch switch state is received through WACOM_PAD_FIELD. However, it is reported by touch_input. Don't register pad_input if no other pad events require the interface.

Signed-off-by Ping Cheng <[email protected]>

Reviewed-by Jason Gerecke <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

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

---
 drivers/hid/wacom_sys.c |    2 +-
 drivers/hid/wacom_wac.c |   43 +++++++++++++++++++++++++------------------
 2 files changed, 26 insertions(+), 19 deletions(-)

drivers/hid/wacom_sys.c +1 -1

@@ -2124,7 +2124,7 @@ static int wacom_register_inputs(struct
 
 	error = wacom_setup_pad_input_capabilities(pad_input_dev, wacom_wac);
 	if (error) {
-		/* no pad in use on this interface */
+		/* no pad events using this interface */
 		input_free_device(pad_input_dev);
 		wacom_wac->pad_input = NULL;
 		pad_input_dev = NULL;

drivers/hid/wacom_wac.c +25 ~~-18~~

67 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #20 lore raw

PATCH 20/779 KVM: nVMX: Snapshot pre-VM-Enter BNDCFGS for !nested_run_pending case

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

From: Sean Christopherson <[email protected]>

commit fa578398a0ba2c079fa1170da21fa5baae0cedb2 upstream.

If a nested run isn't pending, snapshot vmcs01.GUEST_BNDCFGS irrespective of whether or not VM_ENTRY_LOAD_BNDCFGS is set in vmcs12. When restoring nested state, e.g. after migration, without a nested run pending, prepare_vmcs02() will propagate nested.vmcs01_guest_bndcfgs to vmcs02, i.e. will load garbage/zeros into vmcs02.GUEST_BNDCFGS.

If userspace restores nested state before MSRs, then loading garbage is a non-issue as loading BNDCFGS will also update vmcs02. But if usersepace restores MSRs first, then KVM is responsible for propagating L2's value, which is actually thrown into vmcs01, into vmcs02.

Restoring L2 MSRs into vmcs01, i.e. loading all MSRs before nested state is all kinds of bizarre and ideally would not be supported. Sadly, some VMMs do exactly that and rely on KVM to make things work.

Note, there's still a lurking SMM bug, as propagating vmcs01.GUEST_BNDFGS to vmcs02 across RSM may corrupt L2's BNDCFGS. But KVM's entire VMX+SMM emulation is flawed as SMI+RSM should not toouch _any_ VMCS when use the "default treatment of SMIs", i.e. when not using an SMI Transfer Monitor.

Fixes 62cf9bd8118c ("KVM: nVMX: Fix emulation of VM_ENTRY_LOAD_BNDCFGS")

Cc Lei Wang <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

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

---
 arch/x86/kvm/vmx/nested.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/x86/kvm/vmx/nested.c +2 -1

@@ -3367,7 +3367,8 @@ enum nvmx_vmentry_status nested_vmx_ente
 	if (!(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_DEBUG_CONTROLS))
 		vmx->nested.vmcs01_debugctl = vmcs_read64(GUEST_IA32_DEBUGCTL);
 	if (kvm_mpx_supported() &&
-		!(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))
+	    (!vmx->nested.nested_run_pending ||
+	     !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS)))
 		vmx->nested.vmcs01_guest_bndcfgs = vmcs_read64(GUEST_BNDCFGS);
 
 	/*

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #21 lore raw

PATCH 21/779 KVM: nVMX: Snapshot pre-VM-Enter DEBUGCTL for !nested_run_pending case

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

From: Sean Christopherson <[email protected]>

commit 764643a6be07445308e492a528197044c801b3ba upstream.

If a nested run isn't pending, snapshot vmcs01.GUEST_IA32_DEBUGCTL irrespective of whether or not VM_ENTRY_LOAD_DEBUG_CONTROLS is set in vmcs12. When restoring nested state, e.g. after migration, without a nested run pending, prepare_vmcs02() will propagate nested.vmcs01_debugctl to vmcs02, i.e. will load garbage/zeros into vmcs02.GUEST_IA32_DEBUGCTL.

If userspace restores nested state before MSRs, then loading garbage is a non-issue as loading DEBUGCTL will also update vmcs02. But if usersepace restores MSRs first, then KVM is responsible for propagating L2's value, which is actually thrown into vmcs01, into vmcs02.

Note, there's still a lurking SMM bug, as propagating vmcs01's DEBUGCTL to vmcs02 across RSM may corrupt L2's DEBUGCTL. But KVM's entire VMX+SMM emulation is flawed as SMI+RSM should not toouch _any_ VMCS when use the "default treatment of SMIs", i.e. when not using an SMI Transfer Monitor.

Fixes 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

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

---
 arch/x86/kvm/vmx/nested.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/x86/kvm/vmx/nested.c +2 -1

@@ -3364,7 +3364,8 @@ enum nvmx_vmentry_status nested_vmx_ente
 	if (likely(!evaluate_pending_interrupts) && kvm_vcpu_apicv_active(vcpu))
 		evaluate_pending_interrupts |= vmx_has_apicv_interrupt(vcpu);
 
-	if (!(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_DEBUG_CONTROLS))
+	if (!vmx->nested.nested_run_pending ||
+	    !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_DEBUG_CONTROLS))
 		vmx->nested.vmcs01_debugctl = vmcs_read64(GUEST_IA32_DEBUGCTL);
 	if (kvm_mpx_supported() &&
 	    (!vmx->nested.nested_run_pending ||

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #22 lore raw

PATCH 22/779 KVM: SVM: Dont BUG if userspace injects an interrupt with GIF=0

From: Maciej S. Szmigiero <[email protected]>

commit f17c31c48e5cde9895a491d91c424eeeada3e134 upstream.

Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct for KVM internally generated injections).

kernel BUG at arch/x86/kvm/svm/svm.c:3386!
invalid opcode: 0000 [#1] SMP

  CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd]
  Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53
  RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006
  RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0
  RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
  R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000
  FS:  0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0
  Call Trace:
   <TASK>
   inject_pending_event+0x2f7/0x4c0 [kvm]
   kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm]
   kvm_vcpu_ioctl+0x26d/0x650 [kvm]
   __x64_sys_ioctl+0x82/0xb0
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
   </TASK>

Fixes 219b65dcf6c0 ("KVM: SVM: Improve nested interrupt injection")

Co-developed-by Sean Christopherson <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Signed-off-by Maciej S. Szmigiero <[email protected]>

Message-Id: <35426af6e123cbe91ec7ce5132ce72521f02b1b5.1651440202.git.maciej.szmigiero@oracle.com>

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

---
 arch/x86/kvm/svm/svm.c |    2 --
 1 file changed, 2 deletions(-)

arch/x86/kvm/svm/svm.c +0 -2

@@ -3417,8 +3417,6 @@ static void svm_set_irq(struct kvm_vcpu
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
 
-	BUG_ON(!(gif_set(svm)));
-
 	trace_kvm_inj_virq(vcpu->arch.interrupt.nr);
 	++vcpu->stat.irq_injections;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:19 UTC #23 lore raw

PATCH 23/779 KVM: s390: pv: dont present the ecall interrupt twice

From: Nico Boehr <[email protected]>

commit c3f0e5fd2d33d80c5a5a8b5e5d2bab2841709cc8 upstream.

When the SIGP interpretation facility is present and a VCPU sends an ecall to another VCPU in enabled wait, the sending VCPU receives a 56 intercept (partial execution), so KVM can wake up the receiving CPU. Note that the SIGP interpretation facility will take care of the interrupt delivery and KVM's only job is to wake the receiving VCPU.

For PV, the sending VCPU will receive a 108 intercept (pv notify) and should continue like in the non-PV case, i.e. wake the receiving VCPU.

For PV and non-PV guests the interrupt delivery will occur through the SIGP interpretation facility on SIE entry when SIE finds the X bit in the status field set.

However, in handle_pv_notification(), there was no special handling for SIGP, which leads to interrupt injection being requested by KVM for the next SIE entry. This results in the interrupt being delivered twice:
once by the SIGP interpretation facility and once by KVM through the IICTL.

Add the necessary special handling in handle_pv_notification(), similar to handle_partial_execution(), which simply wakes the receiving VCPU and leave interrupt delivery to the SIGP interpretation facility.

In contrast to external calls, emergency calls are not interpreted but also cause a 108 intercept, which is why we still need to call handle_instruction() for SIGP orders other than ecall.

Since kvm_s390_handle_sigp_pei() is now called for all SIGP orders which cause a 108 intercept - even if they are actually handled by handle_instruction() - move the tracepoint in kvm_s390_handle_sigp_pei() to avoid possibly confusing trace messages.

Signed-off-by Nico Boehr <[email protected]>

Cc <[email protected]> # 5.7

Fixes da24a0cc58ed ("KVM: s390: protvirt: Instruction emulation")

Reviewed-by Claudio Imbrenda <[email protected]>

Reviewed-by Janosch Frank <[email protected]>

Reviewed-by Christian Borntraeger <[email protected]>

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

Message-Id: <[email protected]>

Signed-off-by Claudio Imbrenda <[email protected]>

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

---
 arch/s390/kvm/intercept.c |   15 +++++++++++++++
 arch/s390/kvm/sigp.c      |    4 ++--
 2 files changed, 17 insertions(+), 2 deletions(-)

arch/s390/kvm/intercept.c +15 -0

@@ -523,12 +523,27 @@ static int handle_pv_uvc(struct kvm_vcpu
 
 static int handle_pv_notification(struct kvm_vcpu *vcpu)
 {
+	int ret;
+
 	if (vcpu->arch.sie_block->ipa == 0xb210)
 		return handle_pv_spx(vcpu);
 	if (vcpu->arch.sie_block->ipa == 0xb220)
 		return handle_pv_sclp(vcpu);
 	if (vcpu->arch.sie_block->ipa == 0xb9a4)
 		return handle_pv_uvc(vcpu);
+	if (vcpu->arch.sie_block->ipa >> 8 == 0xae) {
+		/*
+		 * Besides external call, other SIGP orders also cause a
+		 * 108 (pv notify) intercept. In contrast to external call,
+		 * these orders need to be emulated and hence the appropriate
+		 * place to handle them is in handle_instruction().
+		 * So first try kvm_s390_handle_sigp_pei() and if that isn't
+		 * successful, go on with handle_instruction().
+		 */
+		ret = kvm_s390_handle_sigp_pei(vcpu);
+		if (!ret)
+			return ret;
+	}
 
 	return handle_instruction(vcpu);
 }

arch/s390/kvm/sigp.c +2 -2

@@ -492,9 +492,9 @@ int kvm_s390_handle_sigp_pei(struct kvm_
 	struct kvm_vcpu *dest_vcpu;
 	u8 order_code = kvm_s390_get_base_disp_rs(vcpu, NULL);
 
-	trace_kvm_s390_handle_sigp_pei(vcpu, order_code, cpu_addr);
-
 	if (order_code == SIGP_EXTERNAL_CALL) {
+		trace_kvm_s390_handle_sigp_pei(vcpu, order_code, cpu_addr);
+
 		dest_vcpu = kvm_get_vcpu_by_id(vcpu->kvm, cpu_addr);
 		BUG_ON(dest_vcpu == NULL);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #24 lore raw

PATCH 24/779 KVM: x86: Split kvm_is_valid_cr4() and export only the non-vendor bits

From: Sean Christopherson <[email protected]>

commit c33f6f2228fe8517e38941a508e9f905f99ecba9 upstream.

Split the common x86 parts of kvm_is_valid_cr4(), i.e. the reserved bits checks, into a separate helper, __kvm_is_valid_cr4(), and export only the inner helper to vendor code in order to prevent nested VMX from calling back into vmx_is_valid_cr4() via kvm_is_valid_cr4().

On SVM, this is a nop as SVM doesn't place any additional restrictions on CR4.

On VMX, this is also currently a nop, but only because nested VMX is missing checks on reserved CR4 bits for nested VM-Enter. That bug will be fixed in a future patch, and could simply use kvm_is_valid_cr4() as-is, but nVMX has _another_ bug where VMXON emulation doesn't enforce VMX's restrictions on CR0/CR4. The cleanest and most intuitive way to fix the VMXON bug is to use nested_host_cr{0,4}_valid(). If the CR4 variant routes through kvm_is_valid_cr4(), using nested_host_cr4_valid() won't do the right thing for the VMXON case as vmx_is_valid_cr4() enforces VMX's restrictions if and only if the vCPU is post-VMXON.

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

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

---
 arch/x86/kvm/svm/nested.c |    3 ++-
 arch/x86/kvm/vmx/vmx.c    |    4 ++--
 arch/x86/kvm/x86.c        |   12 +++++++++---
 arch/x86/kvm/x86.h        |    2 +-
 4 files changed, 14 insertions(+), 7 deletions(-)

arch/x86/kvm/svm/nested.c +2 -1

@@ -275,7 +275,8 @@ static bool nested_vmcb_check_cr3_cr4(st
 			return false;
 	}
 
-	if (CC(!kvm_is_valid_cr4(vcpu, save->cr4)))
+	/* Note, SVM doesn't have any additional restrictions on CR4. */
+	if (CC(!__kvm_is_valid_cr4(vcpu, save->cr4)))
 		return false;
 
 	return true;

arch/x86/kvm/vmx/vmx.c +2 -2

@@ -3213,8 +3213,8 @@ static bool vmx_is_valid_cr4(struct kvm_
 {
 	/*
 	 * We operate under the default treatment of SMM, so VMX cannot be
-	 * enabled under SMM.  Note, whether or not VMXE is allowed at all is
-	 * handled by kvm_is_valid_cr4().
+	 * enabled under SMM.  Note, whether or not VMXE is allowed at all,
+	 * i.e. is a reserved bit, is handled by common x86 code.
 	 */
 	if ((cr4 & X86_CR4_VMXE) && is_smm(vcpu))
 		return false;

arch/x86/kvm/x86.c +9 -3

@@ -1031,7 +1031,7 @@ int kvm_emulate_xsetbv(struct kvm_vcpu *
 }
 EXPORT_SYMBOL_GPL(kvm_emulate_xsetbv);
 
-bool kvm_is_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
+bool __kvm_is_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
 {
 	if (cr4 & cr4_reserved_bits)
 		return false;

@@ -1039,9 +1039,15 @@ bool kvm_is_valid_cr4(struct kvm_vcpu *v
 	if (cr4 & vcpu->arch.cr4_guest_rsvd_bits)
 		return false;
 
-	return static_call(kvm_x86_is_valid_cr4)(vcpu, cr4);
+	return true;
+}
+EXPORT_SYMBOL_GPL(__kvm_is_valid_cr4);
+
+static bool kvm_is_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
+{
+	return __kvm_is_valid_cr4(vcpu, cr4) &&
+	       static_call(kvm_x86_is_valid_cr4)(vcpu, cr4);
 }
-EXPORT_SYMBOL_GPL(kvm_is_valid_cr4);
 
 void kvm_post_set_cr4(struct kvm_vcpu *vcpu, unsigned long old_cr4, unsigned long cr4)
 {

arch/x86/kvm/x86.h +1 -1

@@ -448,7 +448,7 @@ static inline void kvm_machine_check(voi
 void kvm_load_guest_xsave_state(struct kvm_vcpu *vcpu);
 void kvm_load_host_xsave_state(struct kvm_vcpu *vcpu);
 int kvm_spec_ctrl_test_value(u64 value);
-bool kvm_is_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4);
+bool __kvm_is_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4);
 int kvm_handle_memory_failure(struct kvm_vcpu *vcpu, int r,
 			      struct x86_exception *e);
 int kvm_handle_invpcid(struct kvm_vcpu *vcpu, unsigned long type, gva_t gva);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #25 lore raw

PATCH 25/779 KVM: nVMX: Let userspace set nVMX MSR to any _host_ supported value

From: Sean Christopherson <[email protected]>

commit f8ae08f9789ad59d318ea75b570caa454aceda81 upstream.

Restrict the nVMX MSRs based on KVM's config, not based on the guest's current config. Using the guest's config to audit the new config prevents userspace from restoring the original config (KVM's config) if at any point in the past the guest's config was restricted in any way.

Fixes 62cc6b9dc61e ("KVM: nVMX: support restore of VMX capability MSRs")

Cc David Matlack <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

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

---
 arch/x86/kvm/vmx/nested.c |   70 ++++++++++++++++++++++++----------------------
 1 file changed, 37 insertions(+), 33 deletions(-)

arch/x86/kvm/vmx/nested.c +37 ~~-33~~

@@ -1217,7 +1217,7 @@ static int vmx_restore_vmx_basic(struct
 		BIT_ULL(49) | BIT_ULL(54) | BIT_ULL(55) |
 		/* reserved */
 		BIT_ULL(31) | GENMASK_ULL(47, 45) | GENMASK_ULL(63, 56);
-	u64 vmx_basic = vmx->nested.msrs.basic;
+	u64 vmx_basic = vmcs_config.nested.basic;
 
 	if (!is_bitwise_subset(vmx_basic, data, feature_and_reserved))
 		return -EINVAL;

@@ -1240,36 +1240,42 @@ static int vmx_restore_vmx_basic(struct
 	return 0;
 }
 
-static int
-vmx_restore_control_msr(struct vcpu_vmx *vmx, u32 msr_index, u64 data)
+static void vmx_get_control_msr(struct nested_vmx_msrs *msrs, u32 msr_index,
+				u32 **low, u32 **high)
 {
-	u64 supported;
-	u32 *lowp, *highp;
-
 	switch (msr_index) {
 	case MSR_IA32_VMX_TRUE_PINBASED_CTLS:
-		lowp = &vmx->nested.msrs.pinbased_ctls_low;
-		highp = &vmx->nested.msrs.pinbased_ctls_high;
+		*low = &msrs->pinbased_ctls_low;
+		*high = &msrs->pinbased_ctls_high;
 		break;
 	case MSR_IA32_VMX_TRUE_PROCBASED_CTLS:
-		lowp = &vmx->nested.msrs.procbased_ctls_low;
-		highp = &vmx->nested.msrs.procbased_ctls_high;
+		*low = &msrs->procbased_ctls_low;
+		*high = &msrs->procbased_ctls_high;
 		break;
 	case MSR_IA32_VMX_TRUE_EXIT_CTLS:
-		lowp = &vmx->nested.msrs.exit_ctls_low;
-		highp = &vmx->nested.msrs.exit_ctls_high;
+		*low = &msrs->exit_ctls_low;
+		*high = &msrs->exit_ctls_high;
 		break;
 	case MSR_IA32_VMX_TRUE_ENTRY_CTLS:
-		lowp = &vmx->nested.msrs.entry_ctls_low;
-		highp = &vmx->nested.msrs.entry_ctls_high;
+		*low = &msrs->entry_ctls_low;
+		*high = &msrs->entry_ctls_high;
 		break;
 	case MSR_IA32_VMX_PROCBASED_CTLS2:
-		lowp = &vmx->nested.msrs.secondary_ctls_low;
-		highp = &vmx->nested.msrs.secondary_ctls_high;
+		*low = &msrs->secondary_ctls_low;
+		*high = &msrs->secondary_ctls_high;
 		break;
 	default:
 		BUG();
 	}
+}
+
+static int
+vmx_restore_control_msr(struct vcpu_vmx *vmx, u32 msr_index, u64 data)
+{
+	u32 *lowp, *highp;
+	u64 supported;
+
+	vmx_get_control_msr(&vmcs_config.nested, msr_index, &lowp, &highp);
 
 	supported = vmx_control_msr(*lowp, *highp);

@@ -1281,6 +1287,7 @@ vmx_restore_control_msr(struct vcpu_vmx
 	if (!is_bitwise_subset(supported, data, GENMASK_ULL(63, 32)))
 		return -EINVAL;
 
+	vmx_get_control_msr(&vmx->nested.msrs, msr_index, &lowp, &highp);
 	*lowp = data;
 	*highp = data >> 32;
 	return 0;

@@ -1294,10 +1301,8 @@ static int vmx_restore_vmx_misc(struct v
 		BIT_ULL(28) | BIT_ULL(29) | BIT_ULL(30) |
 		/* reserved */
 		GENMASK_ULL(13, 9) | BIT_ULL(31);
-	u64 vmx_misc;
-
-	vmx_misc = vmx_control_msr(vmx->nested.msrs.misc_low,
-				   vmx->nested.msrs.misc_high);
+	u64 vmx_misc = vmx_control_msr(vmcs_config.nested.misc_low,
+				       vmcs_config.nested.misc_high);
 
 	if (!is_bitwise_subset(vmx_misc, data, feature_and_reserved_bits))
 		return -EINVAL;

@@ -1325,10 +1330,8 @@ static int vmx_restore_vmx_misc(struct v
 
 static int vmx_restore_vmx_ept_vpid_cap(struct vcpu_vmx *vmx, u64 data)
 {
-	u64 vmx_ept_vpid_cap;
-
-	vmx_ept_vpid_cap = vmx_control_msr(vmx->nested.msrs.ept_caps,
-					   vmx->nested.msrs.vpid_caps);
+	u64 vmx_ept_vpid_cap = vmx_control_msr(vmcs_config.nested.ept_caps,
+					       vmcs_config.nested.vpid_caps);
 
 	/* Every bit is either reserved or a feature bit. */
 	if (!is_bitwise_subset(vmx_ept_vpid_cap, data, -1ULL))

@@ -1339,20 +1342,21 @@ static int vmx_restore_vmx_ept_vpid_cap(
 	return 0;
 }
 
-static int vmx_restore_fixed0_msr(struct vcpu_vmx *vmx, u32 msr_index, u64 data)
+static u64 *vmx_get_fixed0_msr(struct nested_vmx_msrs *msrs, u32 msr_index)
 {
-	u64 *msr;
-
 	switch (msr_index) {
 	case MSR_IA32_VMX_CR0_FIXED0:
-		msr = &vmx->nested.msrs.cr0_fixed0;
-		break;
+		return &msrs->cr0_fixed0;
 	case MSR_IA32_VMX_CR4_FIXED0:
-		msr = &vmx->nested.msrs.cr4_fixed0;
-		break;
+		return &msrs->cr4_fixed0;
 	default:
 		BUG();
 	}
+}
+
+static int vmx_restore_fixed0_msr(struct vcpu_vmx *vmx, u32 msr_index, u64 data)
+{
+	const u64 *msr = vmx_get_fixed0_msr(&vmcs_config.nested, msr_index);
 
 	/*
 	 * 1 bits (which indicates bits which "must-be-1" during VMX operation)

@@ -1361,7 +1365,7 @@ static int vmx_restore_fixed0_msr(struct
 	if (!is_bitwise_subset(data, *msr, -1ULL))
 		return -EINVAL;
 
-	*msr = data;
+	*vmx_get_fixed0_msr(&vmx->nested.msrs, msr_index) = data;
 	return 0;
 }

@@ -1422,7 +1426,7 @@ int vmx_set_vmx_msr(struct kvm_vcpu *vcp
 		vmx->nested.msrs.vmcs_enum = data;
 		return 0;
 	case MSR_IA32_VMX_VMFUNC:
-		if (data & ~vmx->nested.msrs.vmfunc_controls)
+		if (data & ~vmcs_config.nested.vmfunc_controls)
 			return -EINVAL;
 		vmx->nested.msrs.vmfunc_controls = data;
 		return 0;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:19 UTC #26 lore raw

PATCH 26/779 KVM: nVMX: Account for KVM reserved CR4 bits in consistency checks

From: Sean Christopherson <[email protected]>

commit ca58f3aa53d165afe4ab74c755bc2f6d168617ac upstream.

Check that the guest (L2) and host (L1) CR4 values that would be loaded by nested VM-Enter and VM-Exit respectively are valid with respect to KVM's (L0 host) allowed CR4 bits. Failure to check KVM reserved bits would allow L1 to load an illegal CR4 (or trigger hardware VM-Fail or failed VM-Entry) by massaging guest CPUID to allow features that are not supported by KVM. Amusingly, KVM itself is an accomplice in its doom, as KVM adjusts L1's MSR_IA32_VMX_CR4_FIXED1 to allow L1 to enable bits for L2 based on L1's CPUID model.

Note, although nested_{guest,host}_cr4_valid() are _currently_ used if and only if the vCPU is post-VMXON (nested.vmxon == true), that may not be true in the future, e.g. emulating VMXON has a bug where it doesn't check the allowed/required CR0/CR4 bits.

Fixes 3899152ccbf4 ("KVM: nVMX: fix checks on CR{0,4} during virtual VMX operation")

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

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

---
 arch/x86/kvm/vmx/nested.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/x86/kvm/vmx/nested.h +2 -1

@@ -280,7 +280,8 @@ static inline bool nested_cr4_valid(stru
 	u64 fixed0 = to_vmx(vcpu)->nested.msrs.cr4_fixed0;
 	u64 fixed1 = to_vmx(vcpu)->nested.msrs.cr4_fixed1;
 
-	return fixed_bits_valid(val, fixed0, fixed1);
+	return fixed_bits_valid(val, fixed0, fixed1) &&
+	       __kvm_is_valid_cr4(vcpu, val);
 }
 
 /* No difference in the restrictions on guest and host CR4 in VMX operation. */

Greg Kroah-Hartman

author maintainer

2022-08-15 18:15 UTC #27 lore raw

PATCH 27/779 KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4

Link https://bugzilla.kernel.org/show_bug.cgi?id=216033

From: Sean Christopherson <[email protected]>

commit c7d855c2aff2d511fd60ee2e356134c4fb394799 upstream.

Inject a #UD if L1 attempts VMXON with a CR0 or CR4 that is disallowed per the associated nested VMX MSRs' fixed0/1 settings. KVM cannot rely on hardware to perform the checks, even for the few checks that have higher priority than VM-Exit, as (a) KVM may have forced CR0/CR4 bits in hardware while running the guest, (b) there may incompatible CR0/CR4 bits that have lower priority than VM-Exit, e.g. CR0.NE, and (c) userspace may have further restricted the allowed CR0/CR4 values by manipulating the guest's nested VMX MSRs.

Note, despite a very strong desire to throw shade at Jim, commit 70f3aac964ae ("kvm: nVMX: Remove superfluous VMX instruction fault checks") is not to blame for the buggy behavior (though the comment...). That commit only removed the CR0.PE, EFLAGS.VM, and COMPATIBILITY mode checks (though it did erroneously drop the CPL check, but that has already been remedied). KVM may force CR0.PE=1, but will do so only when also forcing EFLAGS.VM=1 to emulate Real Mode, i.e. hardware will still #UD.

Fixes ec378aeef9df ("KVM: nVMX: Implement VMXON and VMXOFF")

Reported-by Eric Li <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

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

---
 arch/x86/kvm/vmx/nested.c |   23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

arch/x86/kvm/vmx/nested.c +14 -9

@@ -4952,20 +4952,25 @@ static int handle_vmon(struct kvm_vcpu *
 		| FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX;
 
 	/*
-	 * The Intel VMX Instruction Reference lists a bunch of bits that are
-	 * prerequisite to running VMXON, most notably cr4.VMXE must be set to
-	 * 1 (see vmx_is_valid_cr4() for when we allow the guest to set this).
-	 * Otherwise, we should fail with #UD.  But most faulting conditions
-	 * have already been checked by hardware, prior to the VM-exit for
-	 * VMXON.  We do test guest cr4.VMXE because processor CR4 always has
-	 * that bit set to 1 in non-root mode.
+	 * Note, KVM cannot rely on hardware to perform the CR0/CR4 #UD checks
+	 * that have higher priority than VM-Exit (see Intel SDM's pseudocode
+	 * for VMXON), as KVM must load valid CR0/CR4 values into hardware while
+	 * running the guest, i.e. KVM needs to check the _guest_ values.
+	 *
+	 * Rely on hardware for the other two pre-VM-Exit checks, !VM86 and
+	 * !COMPATIBILITY modes.  KVM may run the guest in VM86 to emulate Real
+	 * Mode, but KVM will never take the guest out of those modes.
 	 */
-	if (!kvm_read_cr4_bits(vcpu, X86_CR4_VMXE)) {
+	if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) ||
+	    !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) {
 		kvm_queue_exception(vcpu, UD_VECTOR);
 		return 1;
 	}
 
-	/* CPL=0 must be checked manually. */
+	/*
+	 * CPL=0 and all other checks that are lower priority than VM-Exit must
+	 * be checked manually.
+	 */
 	if (vmx_get_cpl(vcpu)) {
 		kvm_inject_gp(vcpu, 0);
 		return 1;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #28 lore raw

PATCH 28/779 KVM: x86: Mark TSS busy during LTR emulation _after_ all fault checks

From: Sean Christopherson <[email protected]>

commit ec6e4d863258d4bfb36d48d5e3ef68140234d688 upstream.

Wait to mark the TSS as busy during LTR emulation until after all fault checks for the LTR have passed. Specifically, don't mark the TSS busy if the new TSS base is non-canonical.

Opportunistically drop the one-off !seg_desc.PRESENT check for TR as the only reason for the early check was to avoid marking a !PRESENT TSS as busy, i.e. the common !PRESENT is now done before setting the busy bit.

Fixes e37a75a13cda ("KVM: x86: Emulator ignores LDTR/TR extended base on LLDT/LTR")

Reported-by [email protected]

Cc Tetsuo Handa <[email protected]>

Cc Hou Wenlong <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Reviewed-by Maxim Levitsky <[email protected]>

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

Signed-off-by Sean Christopherson <[email protected]>

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

---
 arch/x86/kvm/emulate.c |   19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

arch/x86/kvm/emulate.c +9 ~~-10~~

@@ -1669,16 +1669,6 @@ static int __load_segment_descriptor(str
 	case VCPU_SREG_TR:
 		if (seg_desc.s || (seg_desc.type != 1 && seg_desc.type != 9))
 			goto exception;
-		if (!seg_desc.p) {
-			err_vec = NP_VECTOR;
-			goto exception;
-		}
-		old_desc = seg_desc;
-		seg_desc.type |= 2; /* busy */
-		ret = ctxt->ops->cmpxchg_emulated(ctxt, desc_addr, &old_desc, &seg_desc,
-						  sizeof(seg_desc), &ctxt->exception);
-		if (ret != X86EMUL_CONTINUE)
-			return ret;
 		break;
 	case VCPU_SREG_LDTR:
 		if (seg_desc.s || seg_desc.type != 2)

@@ -1719,6 +1709,15 @@ static int __load_segment_descriptor(str
 				((u64)base3 << 32), ctxt))
 			return emulate_gp(ctxt, 0);
 	}
+
+	if (seg == VCPU_SREG_TR) {
+		old_desc = seg_desc;
+		seg_desc.type |= 2; /* busy */
+		ret = ctxt->ops->cmpxchg_emulated(ctxt, desc_addr, &old_desc, &seg_desc,
+						  sizeof(seg_desc), &ctxt->exception);
+		if (ret != X86EMUL_CONTINUE)
+			return ret;
+	}
 load:
 	ctxt->ops->set_segment(ctxt, selector, &seg_desc, base3, seg);
 	if (desc)

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #29 lore raw

PATCH 29/779 KVM: x86: Set error code to segment selector on LLDT/LTR non-canonical #GP

From: Sean Christopherson <[email protected]>

commit 2626206963ace9e8bf92b6eea5ff78dd674c555c upstream.

When injecting a #GP on LLDT/LTR due to a non-canonical LDT/TSS base, set the error code to the selector. Intel SDM's says nothing about the #GP, but AMD's APM explicitly states that both LLDT and LTR set the error code to the selector, not zero.

Note, a non-canonical memory operand on LLDT/LTR does generate a #GP(0), but the KVM code in question is specific to the base from the descriptor.

Fixes e37a75a13cda ("KVM: x86: Emulator ignores LDTR/TR extended base on LLDT/LTR")

Signed-off-by Sean Christopherson <[email protected]>

Reviewed-by Maxim Levitsky <[email protected]>

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

Signed-off-by Sean Christopherson <[email protected]>

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

---
 arch/x86/kvm/emulate.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/x86/kvm/emulate.c +2 -2

@@ -1706,8 +1706,8 @@ static int __load_segment_descriptor(str
 		if (ret != X86EMUL_CONTINUE)
 			return ret;
 		if (emul_is_noncanonical_address(get_desc_base(&seg_desc) |
-				((u64)base3 << 32), ctxt))
-			return emulate_gp(ctxt, 0);
+						 ((u64)base3 << 32), ctxt))
+			return emulate_gp(ctxt, err_code);
 	}
 
 	if (seg == VCPU_SREG_TR) {

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #30 lore raw

PATCH 30/779 KVM: nVMX: Always enable TSC scaling for L2 when it was enabled for L1

From: Vitaly Kuznetsov <[email protected]>

commit 156b9d76e8822f2956c15029acf2d4b171502f3a upstream.

Windows 10/11 guests with Hyper-V role (WSL2) enabled are observed to hang upon boot or shortly after when a non-default TSC frequency was set for L1. The issue is observed on a host where TSC scaling is supported. The problem appears to be that Windows doesn't use TSC scaling for its guests, even when the feature is advertised, and KVM filters SECONDARY_EXEC_TSC_SCALING out when creating L2 controls from L1's VMCS. This leads to L2 running with the default frequency (matching host's) while L1 is running with an altered one.

Keep SECONDARY_EXEC_TSC_SCALING in secondary exec controls for L2 when it was set for L1. TSC_MULTIPLIER is already correctly computed and written by prepare_vmcs02().

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

Fixes d041b5ea93352b ("KVM: nVMX: Enable nested TSC scaling")

Reviewed-by Maxim Levitsky <[email protected]>

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

Signed-off-by Sean Christopherson <[email protected]>

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

---
 arch/x86/kvm/vmx/nested.c |    1 -
 1 file changed, 1 deletion(-)

arch/x86/kvm/vmx/nested.c +0 -1

@@ -2273,7 +2273,6 @@ static void prepare_vmcs02_early(struct
 				  SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
 				  SECONDARY_EXEC_APIC_REGISTER_VIRT |
 				  SECONDARY_EXEC_ENABLE_VMFUNC |
-				  SECONDARY_EXEC_TSC_SCALING |
 				  SECONDARY_EXEC_DESC);
 
 		if (nested_cpu_has(vmcs12,

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #31 lore raw

PATCH 31/779 KVM: x86: Tag kvm_mmu_x86_module_init() with __init

From: Sean Christopherson <[email protected]>

commit 982bae43f11c37b51d2f1961bb25ef7cac3746fa upstream.

Mark kvm_mmu_x86_module_init() with __init, the entire reason it exists is to initialize variables when kvm.ko is loaded, i.e. it must never be called after module initialization.

Fixes 1d0e84806047 ("KVM: x86/mmu: Resolve nx_huge_pages when kvm.ko is loaded")

Reviewed-by Kai Huang <[email protected]>

Tested-by Michael Roth <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

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

---
 arch/x86/include/asm/kvm_host.h |    2 +-
 arch/x86/kvm/mmu/mmu.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

arch/x86/include/asm/kvm_host.h +1 -1

@@ -1562,7 +1562,7 @@ static inline int kvm_arch_flush_remote_
 		return -ENOTSUPP;
 }
 
-void kvm_mmu_x86_module_init(void);
+void __init kvm_mmu_x86_module_init(void);
 int kvm_mmu_vendor_module_init(void);
 void kvm_mmu_vendor_module_exit(void);

arch/x86/kvm/mmu/mmu.c +1 -1

@@ -6115,7 +6115,7 @@ static int set_nx_huge_pages(const char
  * nx_huge_pages needs to be resolved to true/false when kvm.ko is loaded, as
  * its default value of -1 is technically undefined behavior for a boolean.
  */
-void kvm_mmu_x86_module_init(void)
+void __init kvm_mmu_x86_module_init(void)
 {
 	if (nx_huge_pages == -1)
 		__set_nx_huge_pages(get_nx_auto_mode());

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #32 lore raw

PATCH 32/779 KVM: x86: do not report preemption if the steal time cache is stale

From: Paolo Bonzini <[email protected]>

commit c3c28d24d910a746b02f496d190e0e8c6560224b upstream.

Commit 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status", 2021-11-11) open coded the previous call to kvm_map_gfn, but in doing so it dropped the comparison between the cached guest physical address and the one in the MSR. This cause an incorrect cache hit if the guest modifies the steal time address while the memslots remain the same. This can happen with kexec, in which case the preempted bit is written at the address used by the old kernel instead of the old one.

Cc David Woodhouse <[email protected]>

Fixes 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status")

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

---
 arch/x86/kvm/x86.c |    2 ++
 1 file changed, 2 insertions(+)

arch/x86/kvm/x86.c +2 -0

@@ -4378,6 +4378,7 @@ static void kvm_steal_time_set_preempted
 	struct kvm_steal_time __user *st;
 	struct kvm_memslots *slots;
 	static const u8 preempted = KVM_VCPU_PREEMPTED;
+	gpa_t gpa = vcpu->arch.st.msr_val & KVM_STEAL_VALID_BITS;
 
 	/*
 	 * The vCPU can be marked preempted if and only if the VM-Exit was on

@@ -4405,6 +4406,7 @@ static void kvm_steal_time_set_preempted
 	slots = kvm_memslots(vcpu->kvm);
 
 	if (unlikely(slots->generation != ghc->generation ||
+		     gpa != ghc->gpa ||
 		     kvm_is_error_hva(ghc->hva) || !ghc->memslot))
 		return;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #33 lore raw

PATCH 33/779 KVM: x86: revalidate steal time cache if MSR value changes

From: Paolo Bonzini <[email protected]>

commit 901d3765fa804ce42812f1d5b1f3de2dfbb26723 upstream.

Commit 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status", 2021-11-11) open coded the previous call to kvm_map_gfn, but in doing so it dropped the comparison between the cached guest physical address and the one in the MSR. This cause an incorrect cache hit if the guest modifies the steal time address while the memslots remain the same. This can happen with kexec, in which case the steal time data is written at the address used by the old kernel instead of the old one.

While at it, rename the variable from gfn to gpa since it is a plain physical address and not a right-shifted one.

Reported-by Dave Young <[email protected]>

Reported-by Xiaoying Yan <[email protected]>

Analyzed-by Dr. David Alan Gilbert <[email protected]>

Cc David Woodhouse <[email protected]>

Fixes 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status")

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

---
 arch/x86/kvm/x86.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/x86/kvm/x86.c +3 -3

@@ -3244,6 +3244,7 @@ static void record_steal_time(struct kvm
 	struct gfn_to_hva_cache *ghc = &vcpu->arch.st.cache;
 	struct kvm_steal_time __user *st;
 	struct kvm_memslots *slots;
+	gpa_t gpa = vcpu->arch.st.msr_val & KVM_STEAL_VALID_BITS;
 	u64 steal;
 	u32 version;

@@ -3261,13 +3262,12 @@ static void record_steal_time(struct kvm
 	slots = kvm_memslots(vcpu->kvm);
 
 	if (unlikely(slots->generation != ghc->generation ||
+		     gpa != ghc->gpa ||
 		     kvm_is_error_hva(ghc->hva) || !ghc->memslot)) {
-		gfn_t gfn = vcpu->arch.st.msr_val & KVM_STEAL_VALID_BITS;
-
 		/* We rely on the fact that it fits in a single page. */
 		BUILD_BUG_ON((sizeof(*st) - 1) & KVM_STEAL_VALID_BITS);
 
-		if (kvm_gfn_to_hva_cache_init(vcpu->kvm, ghc, gfn, sizeof(*st)) ||
+		if (kvm_gfn_to_hva_cache_init(vcpu->kvm, ghc, gpa, sizeof(*st)) ||
 		    kvm_is_error_hva(ghc->hva) || !ghc->memslot)
 			return;
 	}

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #34 lore raw

PATCH 34/779 riscv: set default pm_power_off to NULL

From: Dimitri John Ledkov <[email protected]>

commit f2928e224d85e7cc139009ab17cefdfec2df5d11 upstream.

Set pm_power_off to NULL like on all other architectures, check if it is set in machine_halt() and machine_power_off() and fallback to default_power_off if no other power driver got registered.

This brings riscv architecture inline with all other architectures, and allows to reuse exiting power drivers unmodified.

Kernels without legacy SBI v0.1 extensions (CONFIG_RISCV_SBI_V01 is not set), do not set pm_power_off to sbi_shutdown(). There is no support for SBI v0.3 system reset extension either. This prevents using gpio_poweroff on SiFive HiFive Unmatched.

Tested on SiFive HiFive unmatched, with a dtb specifying gpio-poweroff node and kernel complied without CONFIG_RISCV_SBI_V01.

BugLink https://bugs.launchpad.net/bugs/1942806

Signed-off-by Dimitri John Ledkov <[email protected]>

Reviewed-by Anup Patel <[email protected]>

Tested-by Ron Economos <[email protected]>

Cc Nathan Chancellor <[email protected]>

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

---
 arch/riscv/kernel/reset.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

arch/riscv/kernel/reset.c +9 -3

@@ -12,7 +12,7 @@ static void default_power_off(void)
 		wait_for_interrupt();
 }
 
-void (*pm_power_off)(void) = default_power_off;
+void (*pm_power_off)(void) = NULL;
 EXPORT_SYMBOL(pm_power_off);
 
 void machine_restart(char *cmd)

@@ -23,10 +23,16 @@ void machine_restart(char *cmd)
 
 void machine_halt(void)
 {
-	pm_power_off();
+	if (pm_power_off != NULL)
+		pm_power_off();
+	else
+		default_power_off();
 }
 
 void machine_power_off(void)
 {
-	pm_power_off();
+	if (pm_power_off != NULL)
+		pm_power_off();
+	else
+		default_power_off();
 }

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #35 lore raw

PATCH 35/779 ALSA: hda/conexant: Add quirk for LENOVO 20149 Notebook model

From: Meng Tang <[email protected]>

commit f83bb2592482fe94c6eea07a8121763c80f36ce5 upstream.

There is another LENOVO 20149 (Type1Sku0) Notebook model with CX20590, the device PCI SSID is 17aa:3977, which headphones are not responding, that requires the quirk CXT_PINCFG_LENOVO_NOTEBOOK. Add the corresponding entry to the quirk table.

Signed-off-by Meng Tang <[email protected]>

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

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

---
 sound/pci/hda/patch_conexant.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

sound/pci/hda/patch_conexant.c +10 -1

@@ -222,6 +222,7 @@ enum {
 	CXT_PINCFG_LEMOTE_A1205,
 	CXT_PINCFG_COMPAQ_CQ60,
 	CXT_FIXUP_STEREO_DMIC,
+	CXT_PINCFG_LENOVO_NOTEBOOK,
 	CXT_FIXUP_INC_MIC_BOOST,
 	CXT_FIXUP_HEADPHONE_MIC_PIN,
 	CXT_FIXUP_HEADPHONE_MIC,

@@ -772,6 +773,14 @@ static const struct hda_fixup cxt_fixups
 		.type = HDA_FIXUP_FUNC,
 		.v.func = cxt_fixup_stereo_dmic,
 	},
+	[CXT_PINCFG_LENOVO_NOTEBOOK] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x1a, 0x05d71030 },
+			{ }
+		},
+		.chain_id = CXT_FIXUP_STEREO_DMIC,
+	},
 	[CXT_FIXUP_INC_MIC_BOOST] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = cxt5066_increase_mic_boost,

@@ -971,7 +980,7 @@ static const struct snd_pci_quirk cxt506
 	SND_PCI_QUIRK(0x17aa, 0x3905, "Lenovo G50-30", CXT_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK(0x17aa, 0x390b, "Lenovo G50-80", CXT_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC),
-	SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC),
+	SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_PINCFG_LENOVO_NOTEBOOK),
 	SND_PCI_QUIRK(0x17aa, 0x3978, "Lenovo G50-70", CXT_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205", CXT_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK_VENDOR(0x17aa, "Thinkpad", CXT_FIXUP_THINKPAD_ACPI),

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #36 lore raw

PATCH 36/779 ALSA: hda/cirrus - support for iMac 12,1 model

From: Allen Ballway <[email protected]>

commit 74bba640d69914cf832b87f6bbb700e5ba430672 upstream.

The 12,1 model requires the same configuration as the 12,2 model to enable headphones but has a different codec SSID. Adds 12,1 SSID for matching quirk.

[ re-sorted in SSID order by tiwai ]

Signed-off-by Allen Ballway <[email protected]>

Link https://lore.kernel.org/r/20220810152701.1.I902c2e591bbf8de9acb649d1322fa1f291849266@changeid open here

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

---
 sound/pci/hda/patch_cirrus.c |    1 +
 1 file changed, 1 insertion(+)

sound/pci/hda/patch_cirrus.c +1 -0

@@ -395,6 +395,7 @@ static const struct snd_pci_quirk cs420x
 
 	/* codec SSID */
 	SND_PCI_QUIRK(0x106b, 0x0600, "iMac 14,1", CS420X_IMAC27_122),
+	SND_PCI_QUIRK(0x106b, 0x0900, "iMac 12,1", CS420X_IMAC27_122),
 	SND_PCI_QUIRK(0x106b, 0x1c00, "MacBookPro 8,1", CS420X_MBP81),
 	SND_PCI_QUIRK(0x106b, 0x2000, "iMac 12,2", CS420X_IMAC27_122),
 	SND_PCI_QUIRK(0x106b, 0x2800, "MacBookPro 10,1", CS420X_MBP101),

Greg Kroah-Hartman

author maintainer

2022-08-15 18:17 UTC #37 lore raw

PATCH 37/779 ALSA: hda/realtek: Add quirk for another Asus K42JZ model

From: Meng Tang <[email protected]>

commit f882c4bef9cb914d9f7be171afb10ed26536bfa7 upstream.

There is another Asus K42JZ model with the PCI SSID 1043:1313 that requires the quirk ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE. Add the corresponding entry to the quirk table.

Signed-off-by Meng Tang <[email protected]>

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

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

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

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

@@ -6721,6 +6721,7 @@ enum {
 	ALC269_FIXUP_LIMIT_INT_MIC_BOOST,
 	ALC269VB_FIXUP_ASUS_ZENBOOK,
 	ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A,
+	ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE,
 	ALC269_FIXUP_LIMIT_INT_MIC_BOOST_MUTE_LED,
 	ALC269VB_FIXUP_ORDISSIMO_EVE2,
 	ALC283_FIXUP_CHROME_BOOK,

@@ -7297,6 +7298,15 @@ static const struct hda_fixup alc269_fix
 		.chained = true,
 		.chain_id = ALC269VB_FIXUP_ASUS_ZENBOOK,
 	},
+	[ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x18, 0x01a110f0 },  /* use as headset mic */
+			{ }
+		},
+		.chained = true,
+		.chain_id = ALC269_FIXUP_HEADSET_MIC
+	},
 	[ALC269_FIXUP_LIMIT_INT_MIC_BOOST_MUTE_LED] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc269_fixup_limit_int_mic_boost,

@@ -8919,6 +8929,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1043, 0x12a0, "ASUS X441UV", ALC233_FIXUP_EAPD_COEF_AND_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
 	SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC),
+	SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
 	SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK),
 	SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),

Greg Kroah-Hartman

author maintainer

2022-08-15 18:17 UTC #38 lore raw

PATCH 38/779 ALSA: hda/realtek: Add a quirk for HP OMEN 15 (8786) mute LED

From: Bedant Patnaik <[email protected]>

commit 30267718fe2d4dbea49015b022f6f1fe16ca31ab upstream.

Board ID 8786 seems to be another variant of the Omen 15 that needs ALC285_FIXUP_HP_MUTE_LED for working mute LED.

Signed-off-by Bedant Patnaik <[email protected]>

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

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

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

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

@@ -8879,6 +8879,7 @@ static const struct snd_pci_quirk alc269
 		      ALC285_FIXUP_HP_GPIO_AMP_INIT),
 	SND_PCI_QUIRK(0x103c, 0x8783, "HP ZBook Fury 15 G7 Mobile Workstation",
 		      ALC285_FIXUP_HP_GPIO_AMP_INIT),
+	SND_PCI_QUIRK(0x103c, 0x8786, "HP OMEN 15", ALC285_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x8787, "HP OMEN 15", ALC285_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x8788, "HP OMEN 15", ALC285_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x87c8, "HP", ALC287_FIXUP_HP_GPIO_LED),

Greg Kroah-Hartman

author maintainer

2022-08-15 18:17 UTC #39 lore raw

PATCH 39/779 tty: vt: initialize unicode screen buffer

From: Tetsuo Handa <[email protected]>

commit af77c56aa35325daa2bc2bed5c2ebf169be61b86 upstream.

syzbot reports kernel infoleak at vcs_read() [1], for buffer can be read immediately after resize operation. Initialize buffer using kzalloc().

  ----------
  #include <fcntl.h>
  #include <unistd.h>
  #include <sys/ioctl.h>
  #include <linux/fb.h>

  int main(int argc, char *argv[])
  {
    struct fb_var_screeninfo var = { };
    const int fb_fd = open("/dev/fb0", 3);
    ioctl(fb_fd, FBIOGET_VSCREENINFO, &var);
    var.yres = 0x21;
    ioctl(fb_fd, FBIOPUT_VSCREENINFO, &var);
    return read(open("/dev/vcsu", O_RDONLY), &var, sizeof(var)) == -1;
  }
  ----------

Link https://syzkaller.appspot.com/bug?extid=31a641689d43387f05d3 [1]

Cc stable <[email protected]>

Reported-by syzbot <[email protected]>

Reviewed-by Jiri Slaby <[email protected]>

Signed-off-by Tetsuo Handa <[email protected]>

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

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

---
 drivers/tty/vt/vt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/tty/vt/vt.c +1 -1

@@ -344,7 +344,7 @@ static struct uni_screen *vc_uniscr_allo
 	/* allocate everything in one go */
 	memsize = cols * rows * sizeof(char32_t);
 	memsize += rows * sizeof(char32_t *);
-	p = vmalloc(memsize);
+	p = vzalloc(memsize);
 	if (!p)
 		return NULL;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:17 UTC #40 lore raw

PATCH 40/779 vfs: Check the truncate maximum size in inode_newsize_ok()

From: David Howells <[email protected]>

commit e2ebff9c57fe4eb104ce4768f6ebcccf76bef849 upstream.

If something manages to set the maximum file size to MAX_OFFSET+1, this can cause the xfs and ext4 filesystems at least to become corrupt.

Ordinarily, the kernel protects against userspace trying this by checking the value early in the truncate() and ftruncate() system calls calls - but there are at least two places that this check is bypassed:

(1) Cachefiles will round up the EOF of the backing file to DIO block size so as to allow DIO on the final block - but this might push the offset negative. It then calls notify_change(), but this inadvertently bypasses the checking. This can be triggered if someone puts an 8EiB-1 file on a server for someone else to try and access by, say, nfs.

(2) ksmbd doesn't check the value it is given in set_end_of_file_info() and then calls vfs_truncate() directly - which also bypasses the check.

In both cases, it is potentially possible for a network filesystem to cause a disk filesystem to be corrupted: cachefiles in the client's cache filesystem; ksmbd in the server's filesystem.

nfsd is okay as it checks the value, but we can then remove this check too.

Fix this by adding a check to inode_newsize_ok(), as called from setattr_prepare(), thereby catching the issue as filesystems set up to perform the truncate with minimal opportunity for bypassing the new check.

Fixes 1f08c925e7a3 ("cachefiles: Implement backing file wrangling")

Fixes f44158485826 ("cifsd: add file operations")

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

Reported-by Jeff Layton <[email protected]>

Tested-by Jeff Layton <[email protected]>

Reviewed-by Namjae Jeon <[email protected]>

Acked-by Alexander Viro <[email protected]>

cc Steve French <[email protected]>

cc Hyunchul Lee <[email protected]>

cc Chuck Lever <[email protected]>

cc Dave Wysochanski <[email protected]>

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

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

fs/attr.c +2 -0

@@ -184,6 +184,8 @@ EXPORT_SYMBOL(setattr_prepare);
  */
 int inode_newsize_ok(const struct inode *inode, loff_t offset)
 {
+	if (offset < 0)
+		return -EINVAL;
 	if (inode->i_size < offset) {
 		unsigned long limit;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:17 UTC #41 lore raw

PATCH 41/779 fs: Add missing umask strip in vfs_tmpfile

From: Yang Xu <[email protected]>

commit ac6800e279a22b28f4fc21439843025a0d5bf03e upstream.

All creation paths except for O_TMPFILE handle umask in the vfs directly if the filesystem doesn't support or enable POSIX ACLs. If the filesystem does then umask handling is deferred until posix_acl_create(). Because, O_TMPFILE misses umask handling in the vfs it will not honor umask settings. Fix this by adding the missing umask handling.

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

Fixes 60545d0d4610 ("[O_TMPFILE] it's still short a few helpers, but infrastructure should be OK now...")

Cc <[email protected]> # 4.19+

Reported-by Christian Brauner (Microsoft) <[email protected]>

Reviewed-by Darrick J. Wong <[email protected]>

Reviewed-and-Tested-by Jeff Layton <[email protected]>

Acked-by Christian Brauner (Microsoft) <[email protected]>

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

Signed-off-by Christian Brauner (Microsoft) <[email protected]>

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

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

fs/namei.c +2 -0

@@ -3523,6 +3523,8 @@ struct dentry *vfs_tmpfile(struct user_n
 	child = d_alloc(dentry, &slash_name);
 	if (unlikely(!child))
 		goto out_err;
+	if (!IS_POSIXACL(dir))
+		mode &= ~current_umask();
 	error = dir->i_op->tmpfile(mnt_userns, dir, child, mode);
 	if (error)
 		goto out_err;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #42 lore raw

PATCH 42/779 thermal: sysfs: Fix cooling_device_stats_setup() error code path

From: Rafael J. Wysocki <[email protected]>

commit d5a8aa5d7d80d21ab6b266f1bed4194b61746199 upstream.

If cooling_device_stats_setup() fails to create the stats object, it must clear the last slot in cooling_device_attr_groups that was initially empty (so as to make it possible to add stats attributes to the cooling device attribute groups).

Failing to do so may cause the stats attributes to be created by mistake for a device that doesn't have a stats object, because the slot in question might be populated previously during the registration of another cooling device.

Fixes 8ea229511e06 ("thermal: Add cooling device's statistics in sysfs")

Reported-by Di Shen <[email protected]>

Tested-by Di Shen <[email protected]>

Cc 4.17+ <[email protected]> # 4.17+

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

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

---
 drivers/thermal/thermal_sysfs.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

drivers/thermal/thermal_sysfs.c +7 -3

@@ -813,12 +813,13 @@ static const struct attribute_group cool
 
 static void cooling_device_stats_setup(struct thermal_cooling_device *cdev)
 {
+	const struct attribute_group *stats_attr_group = NULL;
 	struct cooling_dev_stats *stats;
 	unsigned long states;
 	int var;
 
 	if (cdev->ops->get_max_state(cdev, &states))
-		return;
+		goto out;
 
 	states++; /* Total number of states is highest state + 1 */

@@ -828,7 +829,7 @@ static void cooling_device_stats_setup(s
 
 	stats = kzalloc(var, GFP_KERNEL);
 	if (!stats)
-		return;
+		goto out;
 
 	stats->time_in_state = (ktime_t *)(stats + 1);
 	stats->trans_table = (unsigned int *)(stats->time_in_state + states);

@@ -838,9 +839,12 @@ static void cooling_device_stats_setup(s
 
 	spin_lock_init(&stats->lock);
 
+	stats_attr_group = &cooling_device_stats_attr_group;
+
+out:
 	/* Fill the empty slot left in cooling_device_attr_groups */
 	var = ARRAY_SIZE(cooling_device_attr_groups) - 2;
-	cooling_device_attr_groups[var] = &cooling_device_stats_attr_group;
+	cooling_device_attr_groups[var] = stats_attr_group;
 }
 
 static void cooling_device_stats_destroy(struct thermal_cooling_device *cdev)

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #43 lore raw

PATCH 43/779 fbcon: Fix boundary checks for fbcon=vc:n1-n2 parameters

From: Helge Deller <[email protected]>

commit cad564ca557f8d3bb3b1fa965d9a2b3f6490ec69 upstream.

The user may use the fbcon=vc:<n1>-<n2> option to tell fbcon to take over the given range (n1...n2) of consoles. The value for n1 and n2 needs to be a positive number and up to (MAX_NR_CONSOLES - 1). The given values were not fully checked against those boundaries yet.

To fix the issue, convert first_fb_vc and last_fb_vc to unsigned integers and check them against the upper boundary, and make sure that first_fb_vc is smaller than last_fb_vc.

Cc [email protected] # v4.19+

Reviewed-by Daniel Vetter <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/YpkYRMojilrtZIgM@p100

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

---
 drivers/video/fbdev/core/fbcon.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

drivers/video/fbdev/core/fbcon.c +5 -3

@@ -115,8 +115,8 @@ static int logo_lines;
    enums.  */
 static int logo_shown = FBCON_LOGO_CANSHOW;
 /* console mappings */
-static int first_fb_vc;
-static int last_fb_vc = MAX_NR_CONSOLES - 1;
+static unsigned int first_fb_vc;
+static unsigned int last_fb_vc = MAX_NR_CONSOLES - 1;
 static int fbcon_is_default = 1; 
 static int primary_device = -1;
 static int fbcon_has_console_bind;

@@ -464,10 +464,12 @@ static int __init fb_console_setup(char
 			options += 3;
 			if (*options)
 				first_fb_vc = simple_strtoul(options, &options, 10) - 1;
-			if (first_fb_vc < 0)
+			if (first_fb_vc >= MAX_NR_CONSOLES)
 				first_fb_vc = 0;
 			if (*options++ == '-')
 				last_fb_vc = simple_strtoul(options, &options, 10) - 1;
+			if (last_fb_vc < first_fb_vc || last_fb_vc >= MAX_NR_CONSOLES)
+				last_fb_vc = MAX_NR_CONSOLES - 1;
 			fbcon_is_default = 0; 
 			continue;
 		}

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #44 lore raw

PATCH 44/779 fbcon: Fix accelerated fbdev scrolling while logo is still shown

From: Helge Deller <[email protected]>

commit 3866cba87dcd0162fb41e9b3b653d0af68fad5ec upstream.

There is no need to directly skip over to the SCROLL_REDRAW case while the logo is still shown.

When using DRM, this change has no effect because the code will reach the SCROLL_REDRAW case immediately anyway.

But if you run an accelerated fbdev driver and have FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION enabled, console scrolling is slowed down by factors so that it feels as if you use a 9600 baud terminal.

So, drop those unnecessary checks and speed up fbdev console acceleration during bootup.

Cc [email protected] # v5.10+

Acked-by Daniel Vetter <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/YpkYxk7wsBPx3po+@p100

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

---
 drivers/video/fbdev/core/fbcon.c |    4 ----
 1 file changed, 4 deletions(-)

drivers/video/fbdev/core/fbcon.c +0 -4

@@ -1706,8 +1706,6 @@ static bool fbcon_scroll(struct vc_data
 	case SM_UP:
 		if (count > vc->vc_rows)	/* Maximum realistic size */
 			count = vc->vc_rows;
-		if (logo_shown >= 0)
-			goto redraw_up;
 		switch (fb_scrollmode(p)) {
 		case SCROLL_MOVE:
 			fbcon_redraw_blit(vc, info, p, t, b - t - count,

@@ -1796,8 +1794,6 @@ static bool fbcon_scroll(struct vc_data
 	case SM_DOWN:
 		if (count > vc->vc_rows)	/* Maximum realistic size */
 			count = vc->vc_rows;
-		if (logo_shown >= 0)
-			goto redraw_down;
 		switch (fb_scrollmode(p)) {
 		case SCROLL_MOVE:
 			fbcon_redraw_blit(vc, info, p, b - 1, b - t - count,

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #45 lore raw

PATCH 45/779 usbnet: Fix linkwatch use-after-free on disconnect

https://git.kernel.org/tglx/history/c/0f138bbfd83c

From: Lukas Wunner <[email protected]>

commit a69e617e533edddf3fa3123149900f36e0a6dc74 upstream.

usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock":

The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all* work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex held in ->ndo_stop().

The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c:

* If the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent().
* usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls netif_carrier_{on,off}().
* That in turn schedules the work linkwatch_event().

Because usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free.

In 2010, usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf ("drivers/net: don't use flush_scheduled_work()").

Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last.

Reported-by Jann Horn <[email protected]>

Link https://lore.kernel.org/netdev/CAG48ez0MHBbENX5gCdHAUXZ7h7s20LnepBF-pa5M=7Bi-jZrEA@mail.gmail.com/ open here

Reported-by Oleksij Rempel <[email protected]>

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

Signed-off-by Lukas Wunner <[email protected]>

Link https://lore.kernel.org/r/d1c87ebe9fc502bffcd1576e238d685ad08321e4.1655987888.git.lukas@wunner.de open here

Acked-by Oliver Neukum <[email protected]>

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

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

---
 drivers/net/usb/usbnet.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

drivers/net/usb/usbnet.c +2 -6

@@ -847,13 +847,11 @@ int usbnet_stop (struct net_device *net)
 
 	mpn = !test_and_clear_bit(EVENT_NO_RUNTIME_PM, &dev->flags);
 
-	/* deferred work (task, timer, softirq) must also stop.
-	 * can't flush_scheduled_work() until we drop rtnl (later),
-	 * else workers could deadlock; so make workers a NOP.
-	 */
+	/* deferred work (timer, softirq, task) must also stop */
 	dev->flags = 0;
 	del_timer_sync (&dev->delay);
 	tasklet_kill (&dev->bh);
+	cancel_work_sync(&dev->kevent);
 	if (!pm)
 		usb_autopm_put_interface(dev->intf);

@@ -1617,8 +1615,6 @@ void usbnet_disconnect (struct usb_inter
 	net = dev->net;
 	unregister_netdev (net);
 
-	cancel_work_sync(&dev->kevent);
-
 	usb_scuttle_anchored_urbs(&dev->deferred);
 
 	if (dev->driver_info->unbind)

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #46 lore raw

PATCH 46/779 fix short copy handling in copy_mc_pipe_to_iter()

From: Al Viro <[email protected]>

commit c3497fd009ef2c59eea60d21c3ac22de3585ed7d upstream.

Unlike other copying operations on ITER_PIPE, copy_mc_to_iter() can result in a short copy. In that case we need to trim the unused buffers, as well as the length of partially filled one - it's not enough to set ->head, ->iov_offset and ->count to reflect how much had we copied. Not hard to fix, fortunately...

I'd put a helper (pipe_discard_from(pipe, head)) into pipe_fs_i.h, rather than iov_iter.c - it has nothing to do with iov_iter and having it will allow us to avoid an ugly kludge in fs/splice.c. We could put it into lib/iov_iter.c for now and move it later, but I don't see the point going that way...

Cc [email protected] # 4.19+

Fixes ca146f6f091e "lib/iov_iter: Fix pipe handling in _copy_to_iter_mcsafe()"

Reviewed-by Jeff Layton <[email protected]>

Reviewed-by Christian Brauner (Microsoft) <[email protected]>

Signed-off-by Al Viro <[email protected]>

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

---
 include/linux/pipe_fs_i.h |    9 +++++++++
 lib/iov_iter.c            |   15 +++++++++++----
 2 files changed, 20 insertions(+), 4 deletions(-)

include/linux/pipe_fs_i.h +9 -0

@@ -229,6 +229,15 @@ static inline bool pipe_buf_try_steal(st
 	return buf->ops->try_steal(pipe, buf);
 }
 
+static inline void pipe_discard_from(struct pipe_inode_info *pipe,
+		unsigned int old_head)
+{
+	unsigned int mask = pipe->ring_size - 1;
+
+	while (pipe->head > old_head)
+		pipe_buf_release(pipe, &pipe->bufs[--pipe->head & mask]);
+}
+
 /* Differs from PIPE_BUF in that PIPE_SIZE is the length of the actual
    memory allocation, whereas PIPE_BUF makes atomicity guarantees.  */
 #define PIPE_SIZE		PAGE_SIZE

lib/iov_iter.c +11 -4

@@ -691,6 +691,7 @@ static size_t copy_mc_pipe_to_iter(const
 	struct pipe_inode_info *pipe = i->pipe;
 	unsigned int p_mask = pipe->ring_size - 1;
 	unsigned int i_head;
+	unsigned int valid = pipe->head;
 	size_t n, off, xfer = 0;
 
 	if (!sanity(i))

@@ -704,11 +705,17 @@ static size_t copy_mc_pipe_to_iter(const
 		rem = copy_mc_to_kernel(p + off, addr + xfer, chunk);
 		chunk -= rem;
 		kunmap_local(p);
-		i->head = i_head;
-		i->iov_offset = off + chunk;
-		xfer += chunk;
-		if (rem)
+		if (chunk) {
+			i->head = i_head;
+			i->iov_offset = off + chunk;
+			xfer += chunk;
+			valid = i_head + 1;
+		}
+		if (rem) {
+			pipe->bufs[i_head & p_mask].len -= rem;
+			pipe_discard_from(pipe, valid);
 			break;
+		}
 		n -= chunk;
 		off = 0;
 		i_head++;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #47 lore raw

PATCH 47/779 crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak

From: John Allen <[email protected]>

commit 13dc15a3f5fd7f884e4bfa8c011a0ae868df12ae upstream.

For some sev ioctl interfaces, input may be passed that is less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the buffer, the sev ioctl interfaces with the issue may return uninitialized slab memory.

Currently, all of the ioctl interfaces in the ccp driver are safe, but to prevent future problems, change all ioctl interfaces that allocate memory with kmalloc to use kzalloc and memset the data buffer to zero in sev_ioctl_do_platform_status.

Fixes 38103671aad3 ("crypto: ccp: Use the stack and common buffer for status commands")

Fixes e799035609e15 ("crypto: ccp: Implement SEV_PEK_CSR ioctl command")

Fixes 76a2b524a4b1d ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command")

Fixes d6112ea0cb344 ("crypto: ccp - introduce SEV_GET_ID2 command")

Reported-by Andy Nguyen <[email protected]>

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

Reviewed-by Peter Gonda <[email protected]>

Acked-by David Rientjes <[email protected]>

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

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

---
 drivers/crypto/ccp/sev-dev.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

drivers/crypto/ccp/sev-dev.c +6 -4

@@ -388,6 +388,8 @@ static int sev_ioctl_do_platform_status(
 	struct sev_user_data_status data;
 	int ret;
 
+	memset(&data, 0, sizeof(data));
+
 	ret = __sev_do_cmd_locked(SEV_CMD_PLATFORM_STATUS, &data, &argp->error);
 	if (ret)
 		return ret;

@@ -441,7 +443,7 @@ static int sev_ioctl_do_pek_csr(struct s
 	if (input.length > SEV_FW_BLOB_MAX_SIZE)
 		return -EFAULT;
 
-	blob = kmalloc(input.length, GFP_KERNEL);
+	blob = kzalloc(input.length, GFP_KERNEL);
 	if (!blob)
 		return -ENOMEM;

@@ -665,7 +667,7 @@ static int sev_ioctl_do_get_id2(struct s
 	input_address = (void __user *)input.address;
 
 	if (input.address && input.length) {
-		id_blob = kmalloc(input.length, GFP_KERNEL);
+		id_blob = kzalloc(input.length, GFP_KERNEL);
 		if (!id_blob)
 			return -ENOMEM;

@@ -784,14 +786,14 @@ static int sev_ioctl_do_pdh_export(struc
 	if (input.cert_chain_len > SEV_FW_BLOB_MAX_SIZE)
 		return -EFAULT;
 
-	pdh_blob = kmalloc(input.pdh_cert_len, GFP_KERNEL);
+	pdh_blob = kzalloc(input.pdh_cert_len, GFP_KERNEL);
 	if (!pdh_blob)
 		return -ENOMEM;
 
 	data.pdh_cert_address = __psp_pa(pdh_blob);
 	data.pdh_cert_len = input.pdh_cert_len;
 
-	cert_blob = kmalloc(input.cert_chain_len, GFP_KERNEL);
+	cert_blob = kzalloc(input.cert_chain_len, GFP_KERNEL);
 	if (!cert_blob) {
 		ret = -ENOMEM;
 		goto e_free_pdh;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #48 lore raw

PATCH 48/779 ovl: drop WARN_ON() dentry is NULL in ovl_encode_fh()

From: Jiachen Zhang <[email protected]>

commit dd524b7f317de8d31d638cbfdc7be4cf9b770e42 upstream.

Some code paths cannot guarantee the inode have any dentry alias. So WARN_ON() all !dentry may flood the kernel logs.

For example, when an overlayfs inode is watched by inotifywait (1), and someone is trying to read the /proc/$(pidof inotifywait)/fdinfo/INOTIFY_FD, at that time if the dentry has been reclaimed by kernel (such as echo 2 > /proc/sys/vm/drop_caches), there will be a WARN_ON(). The printed call stack would be like:

    ? show_mark_fhandle+0xf0/0xf0
    show_mark_fhandle+0x4a/0xf0
    ? show_mark_fhandle+0xf0/0xf0
    ? seq_vprintf+0x30/0x50
    ? seq_printf+0x53/0x70
    ? show_mark_fhandle+0xf0/0xf0
    inotify_fdinfo+0x70/0x90
    show_fdinfo.isra.4+0x53/0x70
    seq_show+0x130/0x170
    seq_read+0x153/0x440
    vfs_read+0x94/0x150
    ksys_read+0x5f/0xe0
    do_syscall_64+0x59/0x1e0
    entry_SYSCALL_64_after_hwframe+0x44/0xa9

So let's drop WARN_ON() to avoid kernel log flooding.

Reported-by Hongbo Yin <[email protected]>

Signed-off-by Jiachen Zhang <[email protected]>

Signed-off-by Tianci Zhang <[email protected]>

Fixes 8ed5eec9d6c4 ("ovl: encode pure upper file handles")

Cc <[email protected]> # v4.16

Signed-off-by Miklos Szeredi <[email protected]>

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

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

fs/overlayfs/export.c +1 -1

@@ -259,7 +259,7 @@ static int ovl_encode_fh(struct inode *i
 		return FILEID_INVALID;
 
 	dentry = d_find_any_alias(inode);
-	if (WARN_ON(!dentry))
+	if (!dentry)
 		return FILEID_INVALID;
 
 	bytes = ovl_dentry_to_fid(ofs, dentry, fid, buflen);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #49 lore raw

PATCH 49/779 parisc: Fix device names in /proc/iomem

From: Helge Deller <[email protected]>

commit cab56b51ec0e69128909cef4650e1907248d821b upstream.

Fix the output of /proc/iomem to show the real hardware device name including the pa_pathname, e.g. "Merlin 160 Core Centronics [8:16:0]". Up to now only the pa_pathname ("[8:16.0]") was shown.

Cc <[email protected]> # v4.9+

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

---
 arch/parisc/kernel/drivers.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

arch/parisc/kernel/drivers.c +4 -5

@@ -520,7 +520,6 @@ alloc_pa_dev(unsigned long hpa, struct h
 	dev->id.hversion_rev = iodc_data[1] & 0x0f;
 	dev->id.sversion = ((iodc_data[4] & 0x0f) << 16) |
 			(iodc_data[5] << 8) | iodc_data[6];
-	dev->hpa.name = parisc_pathname(dev);
 	dev->hpa.start = hpa;
 	/* This is awkward.  The STI spec says that gfx devices may occupy
 	 * 32MB or 64MB.  Unfortunately, we don't know how to tell whether

@@ -534,10 +533,10 @@ alloc_pa_dev(unsigned long hpa, struct h
 		dev->hpa.end = hpa + 0xfff;
 	}
 	dev->hpa.flags = IORESOURCE_MEM;
-	name = parisc_hardware_description(&dev->id);
-	if (name) {
-		strlcpy(dev->name, name, sizeof(dev->name));
-	}
+	dev->hpa.name = dev->name;
+	name = parisc_hardware_description(&dev->id) ? : "unknown";
+	snprintf(dev->name, sizeof(dev->name), "%s [%s]",
+		name, parisc_pathname(dev));
 
 	/* Silently fail things like mouse ports which are subsumed within
 	 * the keyboard controller

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #50 lore raw

PATCH 50/779 parisc: Drop pa_swapper_pg_lock spinlock

From: Helge Deller <[email protected]>

commit 3fbc9a7de0564c55d8a9584c9cd2c9dfe6bd6d43 upstream.

This spinlock was dropped with commit b7795074a046 ("parisc: Optimize per-pagetable spinlocks") in kernel v5.12.

Remove it to silence a sparse warning.

Cc <[email protected]> # v5.12+

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

---
 arch/parisc/kernel/cache.c |    3 ---
 1 file changed, 3 deletions(-)

arch/parisc/kernel/cache.c +0 -3

@@ -46,9 +46,6 @@ void flush_icache_page_asm(unsigned long
  */
 DEFINE_SPINLOCK(pa_tlb_flush_lock);
 
-/* Swapper page setup lock. */
-DEFINE_SPINLOCK(pa_swapper_pg_lock);
-
 #if defined(CONFIG_64BIT) && defined(CONFIG_SMP)
 int pa_serialize_tlb_flushes __ro_after_init;
 #endif

Greg Kroah-Hartman

author maintainer

2022-08-15 18:18 UTC #51 lore raw

PATCH 51/779 parisc: Check the return value of ioremap() in lba_driver_probe()

From: William Dean <[email protected]>

commit cf59f34d7f978d14d6520fd80a78a5ad5cb8abf8 upstream.

The function ioremap() in lba_driver_probe() can fail, so its return value should be checked.

Fixes 4bdc0d676a643 ("remove ioremap_nocache and devm_ioremap_nocache")

Reported-by Hacash Robot <[email protected]>

Signed-off-by William Dean <[email protected]>

Cc <[email protected]> # v5.6+

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

---
 drivers/parisc/lba_pci.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

drivers/parisc/lba_pci.c +5 -1

@@ -1476,9 +1476,13 @@ lba_driver_probe(struct parisc_device *d
 	u32 func_class;
 	void *tmp_obj;
 	char *version;
-	void __iomem *addr = ioremap(dev->hpa.start, 4096);
+	void __iomem *addr;
 	int max;
 
+	addr = ioremap(dev->hpa.start, 4096);
+	if (addr == NULL)
+		return -ENOMEM;
+
 	/* Read HW Rev First */
 	func_class = READ_REG32(addr + LBA_FCLASS);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:24 UTC #52 lore raw

PATCH 52/779 parisc: io_pgetevents_time64() needs compat syscall in 32-bit compat mode

From: Helge Deller <[email protected]>

commit 6431e92fc827bdd2d28f79150d90415ba9ce0d21 upstream.

For all syscalls in 32-bit compat mode on 64-bit kernels the upper 32-bits of the 64-bit registers are zeroed out, so a negative 32-bit signed value will show up as positive 64-bit signed value.

This behaviour breaks the io_pgetevents_time64() syscall which expects signed 64-bit values for the "min_nr" and "nr" parameters. Fix this by switching to the compat_sys_io_pgetevents_time64() syscall, which uses "compat_long_t" types for those parameters.

Cc <[email protected]> # v5.1+

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

---
 arch/parisc/kernel/syscalls/syscall.tbl |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/parisc/kernel/syscalls/syscall.tbl +1 -1

@@ -413,7 +413,7 @@
 412	32	utimensat_time64		sys_utimensat			sys_utimensat
 413	32	pselect6_time64			sys_pselect6			compat_sys_pselect6_time64
 414	32	ppoll_time64			sys_ppoll			compat_sys_ppoll_time64
-416	32	io_pgetevents_time64		sys_io_pgetevents		sys_io_pgetevents
+416	32	io_pgetevents_time64		sys_io_pgetevents		compat_sys_io_pgetevents_time64
 417	32	recvmmsg_time64			sys_recvmmsg			compat_sys_recvmmsg_time64
 418	32	mq_timedsend_time64		sys_mq_timedsend		sys_mq_timedsend
 419	32	mq_timedreceive_time64		sys_mq_timedreceive		sys_mq_timedreceive

Greg Kroah-Hartman

author maintainer

2022-08-15 18:19 UTC #53 lore raw

PATCH 53/779 riscv:uprobe fix SR_SPIE set/clear handling

From: Yipeng Zou <[email protected]>

commit 3dbe5829408bc1586f75b4667ef60e5aab0209c7 upstream.

In riscv the process of uprobe going to clear spie before exec the origin insn,and set spie after that.But When access the page which origin insn has been placed a page fault may happen and irq was disabled in arch_uprobe_pre_xol function,It cause a WARN as follows.
There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol. We can just remove it.

[   31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488
[   31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work
[   31.684929] preempt_count: 0, expected: 0
[   31.685969] CPU: 2 PID: 76 Comm: work Tainted: G
[   31.686542] Hardware name: riscv-virtio,qemu (DT)
[   31.686797] Call Trace:
[   31.687053] [<ffffffff80006442>] dump_backtrace+0x30/0x38
[   31.687699] [<ffffffff80812118>] show_stack+0x40/0x4c
[   31.688141] [<ffffffff8081817a>] dump_stack_lvl+0x44/0x5c
[   31.688396] [<ffffffff808181aa>] dump_stack+0x18/0x20
[   31.688653] [<ffffffff8003e454>] __might_resched+0x114/0x122
[   31.688948] [<ffffffff8003e4b2>] __might_sleep+0x50/0x7a
[   31.689435] [<ffffffff80822676>] down_read+0x30/0x130
[   31.689728] [<ffffffff8000b650>] do_page_fault+0x166/x446
[   31.689997] [<ffffffff80003c0c>] ret_from_exception+0x0/0xc

Fixes 74784081aac8 ("riscv: Add uprobes supported")

Signed-off-by Yipeng Zou <[email protected]>

Reviewed-by Guo Ren <[email protected]>

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

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

---
 arch/riscv/kernel/probes/uprobes.c |    6 ------
 1 file changed, 6 deletions(-)

arch/riscv/kernel/probes/uprobes.c +0 -6

@@ -59,8 +59,6 @@ int arch_uprobe_pre_xol(struct arch_upro
 
 	instruction_pointer_set(regs, utask->xol_vaddr);
 
-	regs->status &= ~SR_SPIE;
-
 	return 0;
 }

@@ -72,8 +70,6 @@ int arch_uprobe_post_xol(struct arch_upr
 
 	instruction_pointer_set(regs, utask->vaddr + auprobe->insn_size);
 
-	regs->status |= SR_SPIE;
-
 	return 0;
 }

@@ -111,8 +107,6 @@ void arch_uprobe_abort_xol(struct arch_u
 	 * address.
 	 */
 	instruction_pointer_set(regs, utask->vaddr);
-
-	regs->status &= ~SR_SPIE;
 }
 
 bool arch_uretprobe_is_alive(struct return_instance *ret, enum rp_check ctx,

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #54 lore raw

PATCH 54/779 dt-bindings: riscv: fix SiFive l2-caches cache-sets

From: Conor Dooley <[email protected]>

commit b60cf8e59e61133b6c9514ff8d8c8d7049d040ef upstream.

Fix device tree schema validation error messages for the SiFive
Unmatched: ' cache-sets:0:0: 1024 was expected'.

The existing bindings allow for just 1024 cache-sets but the fu740 on Unmatched the has 2048 cache-sets. The ISA itself permits any arbitrary power of two, however this is not supported by dt-schema. The RTL for the IP, to which the number of cache-sets is a tunable parameter, has been released publicly so speculatively adding a small number of "reasonable" values seems unwise also.

Instead, as the binding only supports two distinct controllers: add 2048 and explicitly lock it to the fu740's l2 cache while limiting 1024 to the l2 cache on the fu540.

Fixes af951c3a113b ("dt-bindings: riscv: Update l2 cache DT documentation to add support for SiFive FU740")

Reported-by Atul Khare <[email protected]>

Signed-off-by Conor Dooley <[email protected]>

Reviewed-by Krzysztof Kozlowski <[email protected]>

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

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

---
 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml +5 -1

@@ -47,7 +47,7 @@ properties:
     const: 2
 
   cache-sets:
-    const: 1024
+    enum: [1024, 2048]
 
   cache-size:
     const: 2097152

@@ -85,6 +85,8 @@ then:
       description: |
         Must contain entries for DirError, DataError and DataFail signals.
       maxItems: 3
+    cache-sets:
+      const: 1024
 
 else:
   properties:

@@ -92,6 +94,8 @@ else:
       description: |
         Must contain entries for DirError, DataError, DataFail, DirFail signals.
       minItems: 4
+    cache-sets:
+      const: 2048
 
 additionalProperties: false

Greg Kroah-Hartman

author maintainer

2022-08-15 18:22 UTC #55 lore raw

PATCH 55/779 RISC-V: kexec: Fixup use of smp_processor_id() in preemptible context

From: Xianting Tian <[email protected]>

commit 357628e68f5c08ad578a718dc62a0031e06dbe91 upstream.

Use __smp_processor_id() to avoid check the preemption context when CONFIG_DEBUG_PREEMPT enabled, as we will enter crash kernel and no return.

Without the patch,

[  103.781044] sysrq: Trigger a crash
[  103.784625] Kernel panic - not syncing: sysrq triggered crash
[  103.837634] CPU1: off
[  103.889668] CPU2: off
[  103.933479] CPU3: off
[  103.939424] Starting crashdump kernel...
[  103.943442] BUG: using smp_processor_id() in preemptible [00000000] code: sh/346
[  103.950884] caller is debug_smp_processor_id+0x1c/0x26
[  103.956051] CPU: 0 PID: 346 Comm: sh Kdump: loaded Not tainted 5.10.113-00002-gce03f03bf4ec-dirty #149
[  103.965355] Call Trace:
[  103.967805] [<ffffffe00020372a>] walk_stackframe+0x0/0xa2
[  103.973206] [<ffffffe000bcf1f4>] show_stack+0x32/0x3e
[  103.978258] [<ffffffe000bd382a>] dump_stack_lvl+0x72/0x8e
[  103.983655] [<ffffffe000bd385a>] dump_stack+0x14/0x1c
[  103.988705] [<ffffffe000bdc8fe>] check_preemption_disabled+0x9e/0xaa
[  103.995057] [<ffffffe000bdc926>] debug_smp_processor_id+0x1c/0x26
[  104.001150] [<ffffffe000206c64>] machine_kexec+0x22/0xd0
[  104.006463] [<ffffffe000291a7e>] __crash_kexec+0x6a/0xa4
[  104.011774] [<ffffffe000bcf3fa>] panic+0xfc/0x2b0
[  104.016480] [<ffffffe000656ca4>] sysrq_reset_seq_param_set+0x0/0x70
[  104.022745] [<ffffffe000657310>] __handle_sysrq+0x8c/0x154
[  104.028229] [<ffffffe0006577e8>] write_sysrq_trigger+0x5a/0x6a
[  104.034061] [<ffffffe0003d90e0>] proc_reg_write+0x58/0xd4
[  104.039459] [<ffffffe00036cff4>] vfs_write+0x7e/0x254
[  104.044509] [<ffffffe00036d2f6>] ksys_write+0x58/0xbe
[  104.049558] [<ffffffe00036d36a>] sys_write+0xe/0x16
[  104.054434] [<ffffffe000201b9a>] ret_from_syscall+0x0/0x2
[  104.067863] Will call new kernel at ecc00000 from hart id 0
[  104.074939] FDT image at fc5ee000
[  104.079523] Bye...

With the patch we can got clear output,

[   67.740553] sysrq: Trigger a crash
[   67.744166] Kernel panic - not syncing: sysrq triggered crash
[   67.809123] CPU1: off
[   67.865210] CPU2: off
[   67.909075] CPU3: off
[   67.919123] Starting crashdump kernel...
[   67.924900] Will call new kernel at ecc00000 from hart id 0
[   67.932045] FDT image at fc5ee000
[   67.935560] Bye...

Fixes 0e105f1d0037 ("riscv: use hart id instead of cpu id on machine_kexec")

Reviewed-by Guo Ren <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

Reviewed-by Atish Patra <[email protected]>

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

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

---
 arch/riscv/kernel/machine_kexec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/riscv/kernel/machine_kexec.c +1 -1

index df8e24559035..86d1b5f9dfb5 100644
@@ -171,7 +171,7 @@ machine_kexec(struct kimage *image)
 	struct kimage_arch *internal = &image->arch;
 	unsigned long jump_addr = (unsigned long) image->start;
 	unsigned long first_ind_entry = (unsigned long) &image->head;
-	unsigned long this_cpu_id = smp_processor_id();
+	unsigned long this_cpu_id = __smp_processor_id();
 	unsigned long this_hart_id = cpuid_to_hartid_map(this_cpu_id);
 	unsigned long fdt_addr = internal->fdt_addr;
 	void *control_code_buffer = page_address(image->control_code_page);

Signature · 1 line

2.37.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:23 UTC #56 lore raw

PATCH 56/779 RISC-V: Fixup get incorrect user mode PC for kernel mode regs

From: Xianting Tian <[email protected]>

commit 59c026c359c30f116fef6ee958e24d04983efbb0 upstream.

When use 'echo c > /proc/sysrq-trigger' to trigger kdump, riscv_crash_save_regs() will be called to save regs for vmcore, we found "epc" value 00ffffffa5537400 is not a valid kernel virtual address, but is a user virtual address. Other regs(eg, ra, sp, gp...) are correct kernel virtual address.
Actually 0x00ffffffb0dd9400 is the user mode PC of 'PID: 113 Comm: sh', which is saved in the task's stack.

[   21.201701] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #45
[   21.201979] Hardware name: riscv-virtio,qemu (DT)
[   21.202160] epc : 00ffffffa5537400 ra : ffffffff80088640 sp : ff20000010333b90
[   21.202435]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be7c
[   21.202707]  t1 : 0720072007200720 t2 : 30203a7375746174 s0 : ff20000010333cf0
[   21.202973]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
[   21.203243]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 28c8f0aeffea4e00
[   21.203519]  a5 : 28c8f0aeffea4e00 a6 : 0000000000000009 a7 : ffffffff8035c9b8
[   21.203794]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
[   21.204062]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
[   21.204331]  s8 : 00ffffffef451410 s9 : 0000000000000007 s10: 00aaaaaac0510700
[   21.204606]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
[   21.204876]  t5 : ff60000001218000 t6 : ff200000103338b8
[   21.205079] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008

With the incorrect PC, the backtrace showed by crash tool as below, the first stack frame is abnormal,

crash> bt
PID: 113 TASK: ff60000002269600 CPU: 0 COMMAND: "sh"
#0 [ff2000001039bb90] __efistub_.Ldebug_info0 at 00ffffffa5537400 <-- Abnormal #1 [ff2000001039bcf0] panic at ffffffff806578ba
#2 [ff2000001039bd50] sysrq_reset_seq_param_set at ffffffff8038c030 #3 [ff2000001039bda0] __handle_sysrq at ffffffff8038c5f8
#4 [ff2000001039be00] write_sysrq_trigger at ffffffff8038cad8
#5 [ff2000001039be20] proc_reg_write at ffffffff801b7edc
#6 [ff2000001039be40] vfs_write at ffffffff80152ba6
#7 [ff2000001039be80] ksys_write at ffffffff80152ece
#8 [ff2000001039bed0] sys_write at ffffffff80152f46

With the patch, we can get current kernel mode PC, the output as below,

[   17.607658] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #42
[   17.607937] Hardware name: riscv-virtio,qemu (DT)
[   17.608150] epc : ffffffff800078f8 ra : ffffffff8008862c sp : ff20000010333b90
[   17.608441]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be68
[   17.608741]  t1 : 0720072007200720 t2 : 666666666666663c s0 : ff20000010333cf0
[   17.609025]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
[   17.609320]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 0000000000000000
[   17.609601]  a5 : ff60000001c78000 a6 : 000000000000003c a7 : ffffffff8035c9a4
[   17.609894]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
[   17.610186]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
[   17.610469]  s8 : 00ffffffca281410 s9 : 0000000000000007 s10: 00aaaaaab5bb6700
[   17.610755]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
[   17.611041]  t5 : ff60000001218000 t6 : ff20000010333988
[   17.611255] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008

With the correct PC, the backtrace showed by crash tool as below,

crash> bt
PID: 113 TASK: ff6000000226c200 CPU: 0 COMMAND: "sh"
#0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8 <--- Normal #1 [ff20000010333cf0] panic at ffffffff806578c6
#2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c #3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
#4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4 #5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
#6 [ff20000010333e40] vfs_write at ffffffff80152bb2
#7 [ff20000010333e80] ksys_write at ffffffff80152eda
#8 [ff20000010333ed0] sys_write at ffffffff80152f52

Fixes e53d28180d4d ("RISC-V: Add kdump support")

Co-developed-by Guo Ren <[email protected]>

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

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

---
 arch/riscv/kernel/crash_save_regs.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/riscv/kernel/crash_save_regs.S +1 -1

index 7832fb763aba..b2a1908c0463 100644
@@ -44,7 +44,7 @@ SYM_CODE_START(riscv_crash_save_regs)
 	REG_S t6,  PT_T6(a0)	/* x31 */
 
 	csrr t1, CSR_STATUS
-	csrr t2, CSR_EPC
+	auipc t2, 0x0
 	csrr t3, CSR_TVAL
 	csrr t4, CSR_CAUSE

Signature · 1 line

2.37.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:23 UTC #57 lore raw

PATCH 57/779 RISC-V: Fixup schedule out issue in machine_crash_shutdown()

From: Xianting Tian <[email protected]>

commit ad943893d5f1d0aeea892bf7b781cf8062b36d58 upstream.

Current task of executing crash kexec will be schedule out when panic is triggered by RCU Stall, as it needs to wait rcu completion. It lead to inability to enter the crash system.

The implementation of machine_crash_shutdown() is non-standard for RISC-V according to other Arch's implementation(eg, x86, arm64), we need to send IPI to stop secondary harts.

[224521.877268] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[224521.883471] rcu: 	0-...0: (3 GPs behind) idle=cfa/0/0x1 softirq=3968793/3968793 fqs=2495
[224521.891742] 	(detected by 2, t=5255 jiffies, g=60855593, q=328)
[224521.897754] Task dump for CPU 0:
[224521.901074] task:swapper/0     state:R  running task   stack:  0 pid:  0 ppid:   0 flags:0x00000008
[224521.911090] Call Trace:
[224521.913638] [<ffffffe000c432de>] __schedule+0x208/0x5ea
[224521.918957] Kernel panic - not syncing: RCU Stall
[224521.923773] bad: scheduling from the idle thread!
[224521.928571] CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: G   O  5.10.113-yocto-standard #1
[224521.938658] Call Trace:
[224521.941200] [<ffffffe00020395c>] walk_stackframe+0x0/0xaa
[224521.946689] [<ffffffe000c34f8e>] show_stack+0x32/0x3e
[224521.951830] [<ffffffe000c39020>] dump_stack_lvl+0x7e/0xa2
[224521.957317] [<ffffffe000c39058>] dump_stack+0x14/0x1c
[224521.962459] [<ffffffe000243884>] dequeue_task_idle+0x2c/0x40
[224521.968207] [<ffffffe000c434f4>] __schedule+0x41e/0x5ea
[224521.973520] [<ffffffe000c43826>] schedule+0x34/0xe4
[224521.978487] [<ffffffe000c46cae>] schedule_timeout+0xc6/0x170
[224521.984234] [<ffffffe000c4491e>] wait_for_completion+0x98/0xf2
[224521.990157] [<ffffffe00026d9e2>] __wait_rcu_gp+0x148/0x14a
[224521.995733] [<ffffffe0002761c4>] synchronize_rcu+0x5c/0x66
[224522.001307] [<ffffffe00026f1a6>] rcu_sync_enter+0x54/0xe6
[224522.006795] [<ffffffe00025a436>] percpu_down_write+0x32/0x11c
[224522.012629] [<ffffffe000c4266a>] _cpu_down+0x92/0x21a
[224522.017771] [<ffffffe000219a0a>] smp_shutdown_nonboot_cpus+0x90/0x118
[224522.024299] [<ffffffe00020701e>] machine_crash_shutdown+0x30/0x4a
[224522.030483] [<ffffffe00029a3f8>] __crash_kexec+0x62/0xa6
[224522.035884] [<ffffffe000c3515e>] panic+0xfa/0x2b6
[224522.040678] [<ffffffe0002772be>] rcu_sched_clock_irq+0xc26/0xcb8
[224522.046774] [<ffffffe00027fc7a>] update_process_times+0x62/0x8a
[224522.052785] [<ffffffe00028d522>] tick_sched_timer+0x9e/0x102
[224522.058533] [<ffffffe000280c3a>] __hrtimer_run_queues+0x16a/0x318
[224522.064716] [<ffffffe0002812ec>] hrtimer_interrupt+0xd4/0x228
[224522.070551] [<ffffffe0009a69b6>] riscv_timer_interrupt+0x3c/0x48
[224522.076646] [<ffffffe000268f8c>] handle_percpu_devid_irq+0xb0/0x24c
[224522.083004] [<ffffffe00026428e>] __handle_domain_irq+0xa8/0x122
[224522.089014] [<ffffffe00062f954>] riscv_intc_irq+0x38/0x60
[224522.094501] [<ffffffe000201bd4>] ret_from_exception+0x0/0xc
[224522.100161] [<ffffffe000c42146>] rcu_eqs_enter.constprop.0+0x8c/0xb8

With the patch, it can enter crash system when RCU Stall occur.

Fixes e53d28180d4d ("RISC-V: Add kdump support")

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

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

---
 arch/riscv/kernel/machine_kexec.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

arch/riscv/kernel/machine_kexec.c +22 -4

index 86d1b5f9dfb5..ee79e6839b86 100644
@@ -138,19 +138,37 @@ void machine_shutdown(void)
 #endif
 }
 
+/* Override the weak function in kernel/panic.c */
+void crash_smp_send_stop(void)
+{
+	static int cpus_stopped;
+
+	/*
+	 * This function can be called twice in panic path, but obviously
+	 * we execute this only once.
+	 */
+	if (cpus_stopped)
+		return;
+
+	smp_send_stop();
+	cpus_stopped = 1;
+}
+
 /*
  * machine_crash_shutdown - Prepare to kexec after a kernel crash
  *
  * This function is called by crash_kexec just before machine_kexec
- * below and its goal is similar to machine_shutdown, but in case of
- * a kernel crash. Since we don't handle such cases yet, this function
- * is empty.
+ * and its goal is to shutdown non-crashing cpus and save registers.
  */
 void
 machine_crash_shutdown(struct pt_regs *regs)
 {
+	local_irq_disable();
+
+	/* shutdown non-crashing cpus */
+	crash_smp_send_stop();
+
 	crash_save_cpu(regs, smp_processor_id());
-	machine_shutdown();
 	pr_info("Starting crashdump kernel...\n");
 }

Signature · 1 line

2.37.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:23 UTC #58 lore raw

PATCH 58/779 RISC-V: Add modules to virtual kernel memory layout dump

From: Xianting Tian <[email protected]>

commit f9293ad46d8ba9909187a37b7215324420ad4596 upstream.

Modules always live before the kernel, MODULES_END is fixed but MODULES_VADDR isn't fixed, it depends on the kernel size. Let's add it to virtual kernel memory layout dump.

As MODULES is only defined for CONFIG_64BIT, so we dump it when CONFIG_64BIT=y.

eg,
MODULES_VADDR - MODULES_END
0xffffffff01133000 - 0xffffffff80000000

Reviewed-by Guo Ren <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

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

Fixes 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping")

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

---
 arch/riscv/mm/init.c |    4 ++++
 1 file changed, 4 insertions(+)

arch/riscv/mm/init.c +4 -0

@@ -100,6 +100,10 @@ static void __init print_vm_layout(void)
 		  (unsigned long)VMEMMAP_END);
 	print_mlm("vmalloc", (unsigned long)VMALLOC_START,
 		  (unsigned long)VMALLOC_END);
+#ifdef CONFIG_64BIT
+	print_mlm("modules", (unsigned long)MODULES_VADDR,
+		  (unsigned long)MODULES_END);
+#endif
 	print_mlm("lowmem", (unsigned long)PAGE_OFFSET,
 		  (unsigned long)high_memory);
 #ifdef CONFIG_64BIT

Greg Kroah-Hartman

author maintainer

2022-08-15 18:23 UTC #59 lore raw

PATCH 59/779 rtc: rx8025: fix 12/24 hour mode detection on RX-8035

From: Mathew McBride <[email protected]>

commit 71af91565052214ad86f288e0d8ffb165f790995 upstream.

The 12/24hr flag in the RX-8035 can be found in the hour register, instead of the CTRL1 on the RX-8025. This was overlooked when support for the RX-8035 was added, and was causing read errors when the hour register 'overflowed'.

To deal with the relevant register not always being visible in the relevant functions, determine the 12/24 mode at startup and store it in the driver state.

Signed-off-by Mathew McBride <[email protected]>

Fixes f120e2e33ac8 ("rtc: rx8025: implement RX-8035 support")

Signed-off-by Alexandre Belloni <[email protected]>

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

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

---
 drivers/rtc/rtc-rx8025.c |   22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

drivers/rtc/rtc-rx8025.c +18 -4

@@ -55,6 +55,8 @@
 #define RX8025_BIT_CTRL2_XST	BIT(5)
 #define RX8025_BIT_CTRL2_VDET	BIT(6)
 
+#define RX8035_BIT_HOUR_1224	BIT(7)
+
 /* Clock precision adjustment */
 #define RX8025_ADJ_RESOLUTION	3050 /* in ppb */
 #define RX8025_ADJ_DATA_MAX	62

@@ -78,6 +80,7 @@ struct rx8025_data {
 	struct rtc_device *rtc;
 	enum rx_model model;
 	u8 ctrl1;
+	int is_24;
 };
 
 static s32 rx8025_read_reg(const struct i2c_client *client, u8 number)

@@ -226,7 +229,7 @@ static int rx8025_get_time(struct device
 
 	dt->tm_sec = bcd2bin(date[RX8025_REG_SEC] & 0x7f);
 	dt->tm_min = bcd2bin(date[RX8025_REG_MIN] & 0x7f);
-	if (rx8025->ctrl1 & RX8025_BIT_CTRL1_1224)
+	if (rx8025->is_24)
 		dt->tm_hour = bcd2bin(date[RX8025_REG_HOUR] & 0x3f);
 	else
 		dt->tm_hour = bcd2bin(date[RX8025_REG_HOUR] & 0x1f) % 12

@@ -257,7 +260,7 @@ static int rx8025_set_time(struct device
 	 */
 	date[RX8025_REG_SEC] = bin2bcd(dt->tm_sec);
 	date[RX8025_REG_MIN] = bin2bcd(dt->tm_min);
-	if (rx8025->ctrl1 & RX8025_BIT_CTRL1_1224)
+	if (rx8025->is_24)
 		date[RX8025_REG_HOUR] = bin2bcd(dt->tm_hour);
 	else
 		date[RX8025_REG_HOUR] = (dt->tm_hour >= 12 ? 0x20 : 0)

@@ -282,6 +285,7 @@ static int rx8025_init_client(struct i2c
 	struct rx8025_data *rx8025 = i2c_get_clientdata(client);
 	u8 ctrl[2], ctrl2;
 	int need_clear = 0;
+	int hour_reg;
 	int err;
 
 	err = rx8025_read_regs(client, RX8025_REG_CTRL1, 2, ctrl);

@@ -306,6 +310,16 @@ static int rx8025_init_client(struct i2c
 
 		err = rx8025_write_reg(client, RX8025_REG_CTRL2, ctrl2);
 	}
+
+	if (rx8025->model == model_rx_8035) {
+		/* In RX-8035, 12/24 flag is in the hour register */
+		hour_reg = rx8025_read_reg(client, RX8025_REG_HOUR);
+		if (hour_reg < 0)
+			return hour_reg;
+		rx8025->is_24 = (hour_reg & RX8035_BIT_HOUR_1224);
+	} else {
+		rx8025->is_24 = (ctrl[1] & RX8025_BIT_CTRL1_1224);
+	}
 out:
 	return err;
 }

@@ -335,7 +349,7 @@ static int rx8025_read_alarm(struct devi
 	/* Hardware alarms precision is 1 minute! */
 	t->time.tm_sec = 0;
 	t->time.tm_min = bcd2bin(ald[0] & 0x7f);
-	if (rx8025->ctrl1 & RX8025_BIT_CTRL1_1224)
+	if (rx8025->is_24)
 		t->time.tm_hour = bcd2bin(ald[1] & 0x3f);
 	else
 		t->time.tm_hour = bcd2bin(ald[1] & 0x1f) % 12

@@ -370,7 +384,7 @@ static int rx8025_set_alarm(struct devic
 	}
 
 	ald[0] = bin2bcd(t->time.tm_min);
-	if (rx8025->ctrl1 & RX8025_BIT_CTRL1_1224)
+	if (rx8025->is_24)
 		ald[1] = bin2bcd(t->time.tm_hour);
 	else
 		ald[1] = (t->time.tm_hour >= 12 ? 0x20 : 0)

Greg Kroah-Hartman

author maintainer

2022-08-15 18:23 UTC #60 lore raw

PATCH 60/779 drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error

From: Dmitry Osipenko <[email protected]>

commit 2939deac1fa220bc82b89235f146df1d9b52e876 upstream.

Use ww_acquire_fini() in the error code paths. Otherwise lockdep thinks that lock is held when lock's memory is freed after the drm_gem_lock_reservations() error. The ww_acquire_context needs to be annotated as "released", which fixes the noisy "WARNING: held lock freed!" splat of VirtIO-GPU driver with CONFIG_DEBUG_MUTEXES=y and enabled lockdep.

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Fixes 7edc3e3b975b5 ("drm: Add helpers for locking an array of BO reservations.")

Reviewed-by Thomas Hellström <[email protected]>

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

Signed-off-by Dmitry Osipenko <[email protected]>

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

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

---
 drivers/gpu/drm/drm_gem.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/drm_gem.c +2 -2

@@ -1224,7 +1224,7 @@ retry:
 		ret = dma_resv_lock_slow_interruptible(obj->resv,
 								 acquire_ctx);
 		if (ret) {
-			ww_acquire_done(acquire_ctx);
+			ww_acquire_fini(acquire_ctx);
 			return ret;
 		}
 	}

@@ -1249,7 +1249,7 @@ retry:
 				goto retry;
 			}
 
-			ww_acquire_done(acquire_ctx);
+			ww_acquire_fini(acquire_ctx);
 			return ret;
 		}
 	}

Greg Kroah-Hartman

author maintainer

2022-08-15 18:23 UTC #61 lore raw

PATCH 61/779 drm/shmem-helper: Add missing vunmap on error

From: Dmitry Osipenko <[email protected]>

commit df4aaf015775221dde8a51ee09edb919981f091e upstream.

The vmapping of dma-buf may succeed, but DRM SHMEM rejects the IOMEM mapping, and thus, drm_gem_shmem_vmap_locked() should unvmap the IOMEM before erroring out.

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Fixes 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends")

Signed-off-by Dmitry Osipenko <[email protected]>

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

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

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

drivers/gpu/drm/drm_gem_shmem_helper.c +1 -0

@@ -275,6 +275,7 @@ static int drm_gem_shmem_vmap_locked(str
 		ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
 		if (!ret) {
 			if (WARN_ON(map->is_iomem)) {
+				dma_buf_vunmap(obj->import_attach->dmabuf, map);
 				ret = -EIO;
 				goto err_put_pages;
 			}

Greg Kroah-Hartman

author maintainer

2022-08-15 18:19 UTC #62 lore raw

PATCH 62/779 drm/vc4: hdmi: Disable audio if dmas property is present but empty

From: Phil Elwell <[email protected]>

commit db2b927f8668adf3ac765e0921cd2720f5c04172 upstream.

The dmas property is used to hold the dmaengine channel used for audio output.

Older device trees were missing that property, so if it's not there we disable the audio output entirely.

However, some overlays have set an empty value to that property, mostly to workaround the fact that overlays cannot remove a property. Let's add a test for that case and if it's empty, let's disable it as well.

Signed-off-by Phil Elwell <[email protected]>

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

Signed-off-by Maxime Ripard <[email protected]>

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

---
 drivers/gpu/drm/vc4/vc4_hdmi.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/gpu/drm/vc4/vc4_hdmi.c +3 -3

@@ -1470,12 +1470,12 @@ static int vc4_hdmi_audio_init(struct vc
 	struct device *dev = &vc4_hdmi->pdev->dev;
 	struct platform_device *codec_pdev;
 	const __be32 *addr;
-	int index;
+	int index, len;
 	int ret;
 
-	if (!of_find_property(dev->of_node, "dmas", NULL)) {
+	if (!of_find_property(dev->of_node, "dmas", &len) || !len) {
 		dev_warn(dev,
-			 "'dmas' DT property is missing, no HDMI audio\n");
+			 "'dmas' DT property is missing or empty, no HDMI audio\n");
 		return 0;
 	}

Greg Kroah-Hartman

author maintainer

2022-08-15 18:16 UTC #63 lore raw

PATCH 63/779 drm/hyperv-drm: Include framebuffer and EDID headers

From: Thomas Zimmermann <[email protected]>

commit 009a3a52791f31c57d755a73f6bc66fbdd8bd76c upstream.

Fix a number of compile errors by including the correct header files. Examples are shown below.

../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_blit_to_vram_rect':
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:25:48: error: invalid use of undefined type 'struct drm_framebuffer'
25 | struct hyperv_drm_device *hv = to_hv(fb->dev);
| ^~

../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_connector_get_modes':
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:59:17: error: implicit declaration of function 'drm_add_modes_noedid' [-Werror=implicit-function-declaration]
59 | count = drm_add_modes_noedid(connector,

      |                 ^~~~~~~~~~~~~~~~~~~~

../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:62:9: error: implicit declaration of function 'drm_set_preferred_mode'; did you mean 'drm_mm_reserve_node'? [-Werror=implicit-function-declaration]

   62 |         drm_set_preferred_mode(connector, hv->preferred_width,
      |         ^~~~~~~~~~~~~~~~~~~~~~

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

Fixes 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device")

Fixes 720cf96d8fec ("drm: Drop drm_framebuffer.h from drm_crtc.h")

Fixes 255490f9150d ("drm: Drop drm_edid.h from drm_crtc.h")

Cc Deepak Rawat <[email protected]>

Cc Thomas Zimmermann <[email protected]>

Cc Maarten Lankhorst <[email protected]>

Cc Maxime Ripard <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Cc <[email protected]> # v5.14+

Acked-by Maxime Ripard <[email protected]>

Reviewed-by Ville Syrjälä <[email protected]>

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

---
 drivers/gpu/drm/hyperv/hyperv_drm_modeset.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/gpu/drm/hyperv/hyperv_drm_modeset.c +2 -0

@@ -7,9 +7,11 @@
 
 #include <drm/drm_damage_helper.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_edid.h>
 #include <drm/drm_fb_helper.h>
 #include <drm/drm_format_helper.h>
 #include <drm/drm_fourcc.h>
+#include <drm/drm_framebuffer.h>
 #include <drm/drm_gem_atomic_helper.h>
 #include <drm/drm_gem_framebuffer_helper.h>
 #include <drm/drm_gem_shmem_helper.h>

Greg Kroah-Hartman

author maintainer

2022-08-15 18:19 UTC #64 lore raw

PATCH 64/779 drm/nouveau: fix another off-by-one in nvbios_addr

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Timur Tabi <[email protected]>

commit c441d28945fb113220d48d6c86ebc0b090a2b677 upstream.

This check determines whether a given address is part of image 0 or image 1. Image 1 starts at offset image0_size, so that address should be included.

Fixes 4d4e9907ff572 ("drm/nouveau/bios: guard against out-of-bounds accesses to image")

Cc <[email protected]> # v4.8+

Signed-off-by Timur Tabi <[email protected]>

Reviewed-by Karol Herbst <[email protected]>

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

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

---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c +1 -1

@@ -33,7 +33,7 @@ nvbios_addr(struct nvkm_bios *bios, u32
 {
 	u32 p = *addr;
 
-	if (*addr > bios->image0_size && bios->imaged_addr) {
+	if (*addr >= bios->image0_size && bios->imaged_addr) {
 		*addr -= bios->image0_size;
 		*addr += bios->imaged_addr;
 	}

Greg Kroah-Hartman

author maintainer

2022-08-15 18:19 UTC #65 lore raw

PATCH 65/779 drm/nouveau: Dont pm_runtime_put_sync(), only pm_runtime_put_autosuspend()

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Lyude Paul <[email protected]>

commit c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2 upstream.

While trying to fix another issue, it occurred to me that I don't actually think there is any situation where we want pm_runtime_put() in nouveau to be synchronous. In fact, this kind of just seems like it would cause issues where we may unexpectedly block a thread we don't expect to be blocked.

So, let's only use pm_runtime_put_autosuspend().

Changes since v1:
* Use pm_runtime_put_autosuspend(), not pm_runtime_put()

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

Reviewed-by David Airlie <[email protected]>

Fixes 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE")

Cc Hans de Goede <[email protected]>

Cc <[email protected]> # v4.10+

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

---
 drivers/gpu/drm/nouveau/nouveau_display.c |    2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/nouveau/nouveau_display.c +1 -1

@@ -518,7 +518,7 @@ nouveau_display_hpd_work(struct work_str
 
 	pm_runtime_mark_last_busy(drm->dev->dev);
 noop:
-	pm_runtime_put_sync(drm->dev->dev);
+	pm_runtime_put_autosuspend(dev->dev);
 }
 
 #ifdef CONFIG_ACPI

drivers/gpu/drm/nouveau/nouveau_fbcon.c +1 -1

@@ -466,7 +466,7 @@ nouveau_fbcon_set_suspend_work(struct wo
 	if (state == FBINFO_STATE_RUNNING) {
 		nouveau_fbcon_hotplug_resume(drm->fbcon);
 		pm_runtime_mark_last_busy(drm->dev->dev);
-		pm_runtime_put_sync(drm->dev->dev);
+		pm_runtime_put_autosuspend(drm->dev->dev);
 	}
 }

Greg Kroah-Hartman

author maintainer

2022-08-15 18:19 UTC #66 lore raw

PATCH 66/779 drm/nouveau/acpi: Dont print error when we get -EINPROGRESS from pm_runtime

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Lyude Paul <[email protected]>

commit 53c26181950ddc3c8ace3c0939c89e9c4d8deeb9 upstream.

Since this isn't actually a failure.

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

Reviewed-by David Airlie <[email protected]>

Fixes 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early")

Cc <[email protected]> # v4.19+

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

---
 drivers/gpu/drm/nouveau/nouveau_display.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/nouveau/nouveau_display.c +1 -1

@@ -540,7 +540,7 @@ nouveau_display_acpi_ntfy(struct notifie
 				 * it's own hotplug events.
 				 */
 				pm_runtime_put_autosuspend(drm->dev->dev);
-			} else if (ret == 0) {
+			} else if (ret == 0 || ret == -EINPROGRESS) {
 				/* We've started resuming the GPU already, so
 				 * it will handle scheduling a full reprobe
 				 * itself

Greg Kroah-Hartman

author maintainer

2022-08-15 18:20 UTC #67 lore raw

PATCH 67/779 drm/nouveau/kms: Fix failure path for creating DP connectors

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Lyude Paul <[email protected]>

commit ca0367ca5d9216644b41f86348d6661f8d9e32d8 upstream.

It looks like that when we moved nouveau over to using drm_dp_aux_init() and registering it's aux bus during late connector registration, we totally forgot to fix the failure codepath in nouveau_connector_create() - as it still seems to assume that drm_dp_aux_init() can fail (it can't).

So, let's fix that and also add a missing check to ensure that we've properly allocated nv_connector->aux.name while we're at it.

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

Reviewed-by David Airlie <[email protected]>

Fixes fd43ad9d47e7 ("drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister")

Cc <[email protected]> # v5.14+

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

---
 drivers/gpu/drm/nouveau/nouveau_connector.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

drivers/gpu/drm/nouveau/nouveau_connector.c +3 -5

@@ -1361,13 +1361,11 @@ nouveau_connector_create(struct drm_devi
 		snprintf(aux_name, sizeof(aux_name), "sor-%04x-%04x",
 			 dcbe->hasht, dcbe->hashm);
 		nv_connector->aux.name = kstrdup(aux_name, GFP_KERNEL);
-		drm_dp_aux_init(&nv_connector->aux);
-		if (ret) {
-			NV_ERROR(drm, "Failed to init AUX adapter for sor-%04x-%04x: %d\n",
-				 dcbe->hasht, dcbe->hashm, ret);
+		if (!nv_connector->aux.name) {
 			kfree(nv_connector);
-			return ERR_PTR(ret);
+			return ERR_PTR(-ENOMEM);
 		}
+		drm_dp_aux_init(&nv_connector->aux);
 		fallthrough;
 	default:
 		funcs = &nouveau_connector_funcs;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:20 UTC #68 lore raw

PATCH 68/779 drm/amdgpu: Check BOs requested pinning domains against its preferred_domains

From: Leo Li <[email protected]>

commit f5ba14043621f4afdf3ad5f92ee2d8dbebbe4340 upstream.

When pinning a buffer, we should check to see if there are any additional restrictions imposed by bo->preferred_domains. This will prevent the BO from being moved to an invalid domain when pinning.

For example, this can happen if the user requests to create a BO in GTT domain for display scanout. amdgpu_dm will allow pinning to either VRAM or GTT domains, since DCN can scanout from either or. However, in amdgpu_bo_pin_restricted(), pinning to VRAM is preferred if there is adequate carveout. This can lead to pinning to VRAM despite the user requesting GTT placement for the BO.

v2: Allow the kernel to override the domain, which can happen when
exporting a BO to a V4L camera (for example).

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

Reviewed-by Alex Deucher <[email protected]>

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

Signed-off-by Alex Deucher <[email protected]>

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

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

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

@@ -912,6 +912,10 @@ int amdgpu_bo_pin_restricted(struct amdg
 	if (WARN_ON_ONCE(min_offset > max_offset))
 		return -EINVAL;
 
+	/* Check domain to be pinned to against preferred domains */
+	if (bo->preferred_domains & domain)
+		domain = bo->preferred_domains & domain;
+
 	/* A shared bo cannot be migrated to VRAM */
 	if (bo->tbo.base.import_attach) {
 		if (domain & AMDGPU_GEM_DOMAIN_GTT)

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #69 lore raw

PATCH 69/779 drm/amdgpu: fix check in fbdev init

From: Alex Deucher <[email protected]>

The new vkms virtual display code is atomic so there is no need to call drm_helper_disable_unused_functions() when it is enabled. Doing so can result in a segfault. When the driver switched from the old virtual display code to the new atomic virtual display code, it was missed that we enable virtual display unconditionally under SR-IOV so the checks here missed that case. Add the missing check for SR-IOV.

There is no equivalent of this patch for Linus' tree because the relevant code no longer exists. This patch is only relevant to kernels 5.15 and 5.16.

Fixes 84ec374bd580 ("drm/amdgpu: create amdgpu_vkms (v4)")

Cc [email protected] # 5.15.x

Signed-off-by Alex Deucher <[email protected]>

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

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c +2 -1

@@ -341,7 +341,8 @@ int amdgpu_fbdev_init(struct amdgpu_devi
 	}
 
 	/* disable all the possible outputs/crtcs before entering KMS mode */
-	if (!amdgpu_device_has_dc_support(adev) && !amdgpu_virtual_display)
+	if (!amdgpu_device_has_dc_support(adev) && !amdgpu_virtual_display &&
+	    !amdgpu_sriov_vf(adev))
 		drm_helper_disable_unused_functions(adev_to_drm(adev));
 
 	drm_fb_helper_initial_config(&rfbdev->helper, bpp_sel);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #70 lore raw

PATCH 70/779 bpf: Fix KASAN use-after-free Read in compute_effective_progs

From: Tadeusz Struk <[email protected]>

commit 4c46091ee985ae84c60c5e95055d779fcd291d87 upstream.

Syzbot found a Use After Free bug in compute_effective_progs(). The reproducer creates a number of BPF links, and causes a fault injected alloc to fail, while calling bpf_link_detach on them. Link detach triggers the link to be freed by bpf_link_free(), which calls __cgroup_bpf_detach() and update_effective_progs(). If the memory allocation in this function fails, the function restores the pointer to the bpf_cgroup_link on the cgroup list, but the memory gets freed just after it returns. After this, every subsequent call to update_effective_progs() causes this already deallocated pointer to be dereferenced in prog_list_length(), and triggers KASAN UAF error.

To fix this issue don't preserve the pointer to the prog or link in the list, but remove it and replace it with a dummy prog without shrinking the table. The subsequent call to __cgroup_bpf_detach() or __cgroup_bpf_detach() will correct it.

Fixes af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")

Reported-by <[email protected]>

Signed-off-by Tadeusz Struk <[email protected]>

Signed-off-by Andrii Nakryiko <[email protected]>

Link https://syzkaller.appspot.com/bug?id=8ebf179a95c2a2670f7cf1ba62429ec044369db4

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

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

---
 kernel/bpf/cgroup.c |   70 ++++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 60 insertions(+), 10 deletions(-)

kernel/bpf/cgroup.c +60 ~~-10~~

@@ -668,6 +668,60 @@ static struct bpf_prog_list *find_detach
 }
 
 /**
+ * purge_effective_progs() - After compute_effective_progs fails to alloc new
+ *                           cgrp->bpf.inactive table we can recover by
+ *                           recomputing the array in place.
+ *
+ * @cgrp: The cgroup which descendants to travers
+ * @prog: A program to detach or NULL
+ * @link: A link to detach or NULL
+ * @atype: Type of detach operation
+ */
+static void purge_effective_progs(struct cgroup *cgrp, struct bpf_prog *prog,
+				  struct bpf_cgroup_link *link,
+				  enum cgroup_bpf_attach_type atype)
+{
+	struct cgroup_subsys_state *css;
+	struct bpf_prog_array *progs;
+	struct bpf_prog_list *pl;
+	struct list_head *head;
+	struct cgroup *cg;
+	int pos;
+
+	/* recompute effective prog array in place */
+	css_for_each_descendant_pre(css, &cgrp->self) {
+		struct cgroup *desc = container_of(css, struct cgroup, self);
+
+		if (percpu_ref_is_zero(&desc->bpf.refcnt))
+			continue;
+
+		/* find position of link or prog in effective progs array */
+		for (pos = 0, cg = desc; cg; cg = cgroup_parent(cg)) {
+			if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))
+				continue;
+
+			head = &cg->bpf.progs[atype];
+			list_for_each_entry(pl, head, node) {
+				if (!prog_list_prog(pl))
+					continue;
+				if (pl->prog == prog && pl->link == link)
+					goto found;
+				pos++;
+			}
+		}
+found:
+		BUG_ON(!cg);
+		progs = rcu_dereference_protected(
+				desc->bpf.effective[atype],
+				lockdep_is_held(&cgroup_mutex));
+
+		/* Remove the program from the array */
+		WARN_ONCE(bpf_prog_array_delete_safe_at(progs, pos),
+			  "Failed to purge a prog from array at index %d", pos);
+	}
+}
+
+/**
  * __cgroup_bpf_detach() - Detach the program or link from a cgroup, and
  *                         propagate the change to descendants
  * @cgrp: The cgroup which descendants to traverse

@@ -686,7 +740,6 @@ int __cgroup_bpf_detach(struct cgroup *c
 	struct bpf_prog_list *pl;
 	struct list_head *progs;
 	u32 flags;
-	int err;
 
 	atype = to_cgroup_bpf_attach_type(type);
 	if (atype < 0)

@@ -708,9 +761,12 @@ int __cgroup_bpf_detach(struct cgroup *c
 	pl->prog = NULL;
 	pl->link = NULL;
 
-	err = update_effective_progs(cgrp, atype);
-	if (err)
-		goto cleanup;
+	if (update_effective_progs(cgrp, atype)) {
+		/* if update effective array failed replace the prog with a dummy prog*/
+		pl->prog = old_prog;
+		pl->link = link;
+		purge_effective_progs(cgrp, old_prog, link, atype);
+	}
 
 	/* now can actually delete it from this cgroup list */
 	list_del(&pl->node);

@@ -722,12 +778,6 @@ int __cgroup_bpf_detach(struct cgroup *c
 		bpf_prog_put(old_prog);
 	static_branch_dec(&cgroup_bpf_enabled_key[atype]);
 	return 0;
-
-cleanup:
-	/* restore back prog or link */
-	pl->prog = old_prog;
-	pl->link = link;
-	return err;
 }
 
 /* Must be called with cgroup_mutex held to avoid races. */

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #71 lore raw

PATCH 71/779 btrfs: reject log replay if there is unsupported RO compat flag

From: Qu Wenruo <[email protected]>

commit dc4d31684974d140250f3ee612c3f0cab13b3146 upstream.

[BUG]
If we have a btrfs image with dirty log, along with an unsupported RO compatible flag:

log_root 30474240
...
compat_flags 0x0
compat_ro_flags 0x40000003

			( FREE_SPACE_TREE |
			  FREE_SPACE_TREE_VALID |
			  unknown flag: 0x40000000 )

Then even if we can only mount it RO, we will still cause metadata update for log replay:

BTRFS info (device dm-1): flagging fs with big metadata feature BTRFS info (device dm-1): using free space tree
BTRFS info (device dm-1): has skinny extents
BTRFS info (device dm-1): start tree-log replay

This is definitely against RO compact flag requirement.

[CAUSE]
RO compact flag only forces us to do RO mount, but we will still do log replay for plain RO mount.

Thus this will result us to do log replay and update metadata.

This can be very problematic for new RO compat flag, for example older kernel can not understand v2 cache, and if we allow metadata update on RO mount and invalidate/corrupt v2 cache.

[FIX]
Just reject the mount unless rescue=nologreplay is provided:

BTRFS error (device dm-1): cannot replay dirty log with unsupport optional features (0x40000000), try rescue=nologreplay instead

We don't want to set rescue=nologreply directly, as this would make the end user to read the old data, and cause confusion.

Since the such case is really rare, we're mostly fine to just reject the mount with an error message, which also includes the proper workaround.

CC [email protected] #4.9+

Signed-off-by Qu Wenruo <[email protected]>

Reviewed-by David Sterba <[email protected]>

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

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

---
 fs/btrfs/disk-io.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

fs/btrfs/disk-io.c +14 -0

@@ -3557,6 +3557,20 @@ int __cold open_ctree(struct super_block
 		btrfs_err(fs_info, "failed to init dev_replace: %d", ret);
 		goto fail_block_groups;
 	}
+	/*
+	 * We have unsupported RO compat features, although RO mounted, we
+	 * should not cause any metadata write, including log replay.
+	 * Or we could screw up whatever the new feature requires.
+	 */
+	if (unlikely(features && btrfs_super_log_root(disk_super) &&
+		     !btrfs_test_opt(fs_info, NOLOGREPLAY))) {
+		btrfs_err(fs_info,
+"cannot replay dirty log with unsupported compat_ro features (0x%llx), try rescue=nologreplay",
+			  features);
+		err = -EINVAL;
+		goto fail_alloc;
+	}
+
 
 	ret = btrfs_check_zoned_mode(fs_info);
 	if (ret) {

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #72 lore raw

PATCH 72/779 mtd: rawnand: arasan: Fix clock rate in NV-DDR

Link https://lore.kernel.org/linux-mtd/[email protected] open here

From: Olga Kitaina <[email protected]>

commit e16eceea863b417fd328588b1be1a79de0bc937f upstream.

According to the Arasan NAND controller spec, the flash clock rate for SDR must be <= 100 MHz, while for NV-DDR it must be the same as the rate of the CLK line for the mode. The driver previously always set 100 MHz for NV-DDR, which would result in incorrect behavior for NV-DDR modes 0-4.

The appropriate clock rate can be calculated from the NV-DDR timing parameters as 1/tCK, or for rates measured in picoseconds, 10^12 / nand_nvddr_timings->tCK_min.

Fixes 197b88fecc50 ("mtd: rawnand: arasan: Add new Arasan NAND controller")

CC [email protected] # 5.8+

Signed-off-by Olga Kitaina <[email protected]>

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

Signed-off-by Miquel Raynal <[email protected]>

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

---
 drivers/mtd/nand/raw/arasan-nand-controller.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

drivers/mtd/nand/raw/arasan-nand-controller.c +7 -1

@@ -1043,7 +1043,13 @@ static int anfc_setup_interface(struct n
 				 DQS_BUFF_SEL_OUT(dqs_mode);
 	}
 
-	anand->clk = ANFC_XLNX_SDR_DFLT_CORE_CLK;
+	if (nand_interface_is_sdr(conf)) {
+		anand->clk = ANFC_XLNX_SDR_DFLT_CORE_CLK;
+	} else {
+		/* ONFI timings are defined in picoseconds */
+		anand->clk = div_u64((u64)NSEC_PER_SEC * 1000,
+				     conf->timings.nvddr.tCK_min);
+	}
 
 	/*
 	 * Due to a hardware bug in the ZynqMP SoC, SDR timing modes 0-1 work

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #73 lore raw

PATCH 73/779 mtd: rawnand: arasan: Update NAND bus clock instead of system clock

Link https://lore.kernel.org/linux-mtd/[email protected] open here

From: Amit Kumar Mahapatra <[email protected]>

commit 7499bfeedb47efc1ee4dc793b92c610d46e6d6a6 upstream.

In current implementation the Arasan NAND driver is updating the system clock(i.e., anand->clk) in accordance to the timing modes (i.e., SDR or NVDDR). But as per the Arasan NAND controller spec the flash clock or the NAND bus clock(i.e., nfc->bus_clk), need to be updated instead. This patch keeps the system clock unchanged and updates the NAND bus clock as per the timing modes.

Fixes 197b88fecc50 ("mtd: rawnand: arasan: Add new Arasan NAND controller")

CC [email protected] # 5.8+

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

Signed-off-by Miquel Raynal <[email protected]>

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

---
 drivers/mtd/nand/raw/arasan-nand-controller.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/mtd/nand/raw/arasan-nand-controller.c +4 -4

@@ -347,17 +347,17 @@ static int anfc_select_target(struct nan
 
 	/* Update clock frequency */
 	if (nfc->cur_clk != anand->clk) {
-		clk_disable_unprepare(nfc->controller_clk);
-		ret = clk_set_rate(nfc->controller_clk, anand->clk);
+		clk_disable_unprepare(nfc->bus_clk);
+		ret = clk_set_rate(nfc->bus_clk, anand->clk);
 		if (ret) {
 			dev_err(nfc->dev, "Failed to change clock rate\n");
 			return ret;
 		}
 
-		ret = clk_prepare_enable(nfc->controller_clk);
+		ret = clk_prepare_enable(nfc->bus_clk);
 		if (ret) {
 			dev_err(nfc->dev,
-				"Failed to re-enable the controller clock\n");
+				"Failed to re-enable the bus clock\n");
 			return ret;
 		}

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #74 lore raw

PATCH 74/779 um: Remove straying parenthesis

From: Benjamin Beichler <[email protected]>

commit c6496e0a4a90d8149203c16323cff3fa46e422e7 upstream.

Commit e3a33af812c6 ("um: fix and optimize xor select template for CONFIG64 and timetravel mode") caused a build regression when CONFIG_XOR_BLOCKS and CONFIG_UML_TIME_TRAVEL_SUPPORT are selected.
Fix it by removing the straying parenthesis.

Fixes e3a33af812c6 ("um: fix and optimize xor select template for CONFIG64 and timetravel mode")

Signed-off-by Benjamin Beichler <[email protected]>

[rw: Added commit message]

Signed-off-by Richard Weinberger <[email protected]>

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

---
 arch/um/include/asm/xor.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/um/include/asm/xor.h +1 -1

@@ -18,7 +18,7 @@
 #undef XOR_SELECT_TEMPLATE
 /* pick an arbitrary one - measuring isn't possible with inf-cpu */
 #define XOR_SELECT_TEMPLATE(x)	\
-	(time_travel_mode == TT_MODE_INFCPU ? TT_CPU_INF_XOR_DEFAULT : x))
+	(time_travel_mode == TT_MODE_INFCPU ? TT_CPU_INF_XOR_DEFAULT : x)
 #endif
 
 #endif

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #75 lore raw

PATCH 75/779 um: seed rng using host OS rng

From: Jason A. Donenfeld <[email protected]>

commit 0b9ba6135d7f18b82f3d8bebb55ded725ba88e0e upstream.

UML generally does not provide access to special CPU instructions like RDRAND, and execution tends to be rather deterministic, with no real hardware interrupts, making good randomness really very hard, if not all together impossible. Not only is this a security eyebrow raiser, but it's also quite annoying when trying to do various pieces of UML-based automation that takes a long time to boot, if ever.

Fix this by trivially calling getrandom() in the host and using that seed as "bootloader randomness", which initializes the rng immediately at UML boot.

The old behavior can be restored the same way as on any other arch, by way of CONFIG_TRUST_BOOTLOADER_RANDOMNESS=n or random.trust_bootloader=0. So seen from that perspective, this just makes UML act like other archs, which is positive in its own right.

Additionally, wire up arch_get_random_{int,long}() in the same way, so that reseeds can also make use of the host RNG, controllable by CONFIG_TRUST_CPU_RANDOMNESS and random.trust_cpu, per usual.

Acked-by Johannes Berg <[email protected]>

Acked-by Anton Ivanov <[email protected]>

Signed-off-by Jason A. Donenfeld <[email protected]>

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

---
 arch/um/include/asm/archrandom.h |   30 ++++++++++++++++++++++++++++++
 arch/um/include/shared/os.h      |    7 +++++++
 arch/um/kernel/um_arch.c         |    8 ++++++++
 arch/um/os-Linux/util.c          |    6 ++++++
 4 files changed, 51 insertions(+)
 create mode 100644 arch/um/include/asm/archrandom.h

arch/um/include/asm/archrandom.h new file +30 -0

@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_UM_ARCHRANDOM_H__
+#define __ASM_UM_ARCHRANDOM_H__
+
+#include <linux/types.h>
+
+/* This is from <os.h>, but better not to #include that in a global header here. */
+ssize_t os_getrandom(void *buf, size_t len, unsigned int flags);
+
+static inline bool __must_check arch_get_random_long(unsigned long *v)
+{
+	return os_getrandom(v, sizeof(*v), 0) == sizeof(*v);
+}
+
+static inline bool __must_check arch_get_random_int(unsigned int *v)
+{
+	return os_getrandom(v, sizeof(*v), 0) == sizeof(*v);
+}
+
+static inline bool __must_check arch_get_random_seed_long(unsigned long *v)
+{
+	return false;
+}
+
+static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
+{
+	return false;
+}
+
+#endif

arch/um/include/shared/os.h +7 -0

@@ -11,6 +11,12 @@
 #include <irq_user.h>
 #include <longjmp.h>
 #include <mm_id.h>
+/* This is to get size_t */
+#ifndef __UM_HOST__
+#include <linux/types.h>
+#else
+#include <sys/types.h>
+#endif
 
 #define CATCH_EINTR(expr) while ((errno = 0, ((expr) < 0)) && (errno == EINTR))

@@ -252,6 +258,7 @@ extern void stack_protections(unsigned l
 extern int raw(int fd);
 extern void setup_machinename(char *machine_out);
 extern void setup_hostinfo(char *buf, int len);
+extern ssize_t os_getrandom(void *buf, size_t len, unsigned int flags);
 extern void os_dump_core(void) __attribute__ ((noreturn));
 extern void um_early_printk(const char *s, unsigned int n);
 extern void os_fix_helper_signals(void);

arch/um/kernel/um_arch.c +8 -0

@@ -16,6 +16,7 @@
 #include <linux/sched/task.h>
 #include <linux/kmsg_dump.h>
 #include <linux/suspend.h>
+#include <linux/random.h>
 
 #include <asm/processor.h>
 #include <asm/cpufeature.h>

@@ -404,6 +405,8 @@ int __init __weak read_initrd(void)
 
 void __init setup_arch(char **cmdline_p)
 {
+	u8 rng_seed[32];
+
 	stack_protections((unsigned long) &init_thread_info);
 	setup_physmem(uml_physmem, uml_reserved, physmem_size, highmem);
 	mem_total_pages(physmem_size, iomem_size, highmem);

@@ -413,6 +416,11 @@ void __init setup_arch(char **cmdline_p)
 	strlcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
 	*cmdline_p = command_line;
 	setup_hostinfo(host_info, sizeof host_info);
+
+	if (os_getrandom(rng_seed, sizeof(rng_seed), 0) == sizeof(rng_seed)) {
+		add_bootloader_randomness(rng_seed, sizeof(rng_seed));
+		memzero_explicit(rng_seed, sizeof(rng_seed));
+	}
 }
 
 void __init check_bugs(void)

arch/um/os-Linux/util.c +6 -0

@@ -14,6 +14,7 @@
 #include <sys/wait.h>
 #include <sys/mman.h>
 #include <sys/utsname.h>
+#include <sys/random.h>
 #include <init.h>
 #include <os.h>

@@ -96,6 +97,11 @@ static inline void __attribute__ ((noret
 			exit(127);
 }
 
+ssize_t os_getrandom(void *buf, size_t len, unsigned int flags)
+{
+	return getrandom(buf, len, flags);
+}
+
 /*
  * UML helper threads must not handle SIGWINCH/INT/TERM
  */

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #76 lore raw

PATCH 76/779 iio: fix iio_format_avail_range() printing for none IIO_VAL_INT

From: Fawzi Khaber <[email protected]>

commit 5e1f91850365de55ca74945866c002fda8f00331 upstream.

iio_format_avail_range() should print range as follow [min, step, max], so the function was previously calling iio_format_list() with length = 3, length variable refers to the array size of values not the number of elements. In case of non IIO_VAL_INT values each element has integer part and decimal part. With length = 3 this would cause premature end of loop and result in printing only one element.

Signed-off-by Fawzi Khaber <[email protected]>

Signed-off-by Jean-Baptiste Maneyrol <[email protected]>

Fixes eda20ba1e25e ("iio: core: Consolidate iio_format_avail_{list,range}()")

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

Signed-off-by Jonathan Cameron <[email protected]>

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

---
 drivers/iio/industrialio-core.c |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

drivers/iio/industrialio-core.c +17 -1

@@ -818,7 +818,23 @@ static ssize_t iio_format_avail_list(cha
 
 static ssize_t iio_format_avail_range(char *buf, const int *vals, int type)
 {
-	return iio_format_list(buf, vals, type, 3, "[", "]");
+	int length;
+
+	/*
+	 * length refers to the array size , not the number of elements.
+	 * The purpose is to print the range [min , step ,max] so length should
+	 * be 3 in case of int, and 6 for other types.
+	 */
+	switch (type) {
+	case IIO_VAL_INT:
+		length = 3;
+		break;
+	default:
+		length = 6;
+		break;
+	}
+
+	return iio_format_list(buf, vals, type, length, "[", "]");
 }
 
 static ssize_t iio_read_channel_info_avail(struct device *dev,

Greg Kroah-Hartman

author maintainer

2022-08-15 18:21 UTC #77 lore raw

PATCH 77/779 iio: light: isl29028: Fix the warning in isl29028_remove()

From: Zheyu Ma <[email protected]>

commit 06674fc7c003b9d0aa1d37fef7ab2c24802cc6ad upstream.

The driver use the non-managed form of the register function in isl29028_remove(). To keep the release order as mirroring the ordering in probe, the driver should use non-managed form in probe, too.

The following log reveals it:

[   32.374955] isl29028 0-0010: remove
[   32.376861] general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI
[   32.377676] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[   32.379432] RIP: 0010:kernfs_find_and_get_ns+0x28/0xe0
[   32.385461] Call Trace:
[   32.385807]  sysfs_unmerge_group+0x59/0x110
[   32.386110]  dpm_sysfs_remove+0x58/0xc0
[   32.386391]  device_del+0x296/0xe50
[   32.386959]  cdev_device_del+0x1d/0xd0
[   32.387231]  devm_iio_device_unreg+0x27/0xb0
[   32.387542]  devres_release_group+0x319/0x3d0
[   32.388162]  i2c_device_remove+0x93/0x1f0

Fixes 2db5054ac28d ("staging: iio: isl29028: add runtime power management support")

Signed-off-by Zheyu Ma <[email protected]>

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

Signed-off-by Jonathan Cameron <[email protected]>

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

---
 drivers/iio/light/isl29028.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/iio/light/isl29028.c +1 -1

@@ -625,7 +625,7 @@ static int isl29028_probe(struct i2c_cli
 					 ISL29028_POWER_OFF_DELAY_MS);
 	pm_runtime_use_autosuspend(&client->dev);
 
-	ret = devm_iio_device_register(indio_dev->dev.parent, indio_dev);
+	ret = iio_device_register(indio_dev);
 	if (ret < 0) {
 		dev_err(&client->dev,
 			"%s(): iio registration failed with error %d\n",

Greg Kroah-Hartman

author maintainer

2022-08-15 18:22 UTC #78 lore raw

PATCH 78/779 scsi: sg: Allow waiting for commands to complete on removed device

From: Tony Battersby <[email protected]>

commit 3455607fd7be10b449f5135c00dc306b85dc0d21 upstream.

When a SCSI device is removed while in active use, currently sg will immediately return -ENODEV on any attempt to wait for active commands that were sent before the removal. This is problematic for commands that use SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel when userspace frees or reuses it after getting ENODEV, leading to corrupted userspace memory (in the case of READ-type commands) or corrupted data being sent to the device (in the case of WRITE-type commands). This has been seen in practice when logging out of a iscsi_tcp session, where the iSCSI driver may still be processing commands after the device has been marked for removal.

Change the policy to allow userspace to wait for active sg commands even when the device is being removed. Return -ENODEV only when there are no more responses to read.

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

Acked-by Douglas Gilbert <[email protected]>

Signed-off-by Tony Battersby <[email protected]>

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

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

---
 drivers/scsi/sg.c |   53 +++++++++++++++++++++++++++++++++--------------------
 1 file changed, 33 insertions(+), 20 deletions(-)

drivers/scsi/sg.c +33 ~~-20~~

@@ -191,7 +191,7 @@ static void sg_link_reserve(Sg_fd * sfp,
 static void sg_unlink_reserve(Sg_fd * sfp, Sg_request * srp);
 static Sg_fd *sg_add_sfp(Sg_device * sdp);
 static void sg_remove_sfp(struct kref *);
-static Sg_request *sg_get_rq_mark(Sg_fd * sfp, int pack_id);
+static Sg_request *sg_get_rq_mark(Sg_fd * sfp, int pack_id, bool *busy);
 static Sg_request *sg_add_request(Sg_fd * sfp);
 static int sg_remove_request(Sg_fd * sfp, Sg_request * srp);
 static Sg_device *sg_get_dev(int dev);

@@ -445,6 +445,7 @@ sg_read(struct file *filp, char __user *
 	Sg_fd *sfp;
 	Sg_request *srp;
 	int req_pack_id = -1;
+	bool busy;
 	sg_io_hdr_t *hp;
 	struct sg_header *old_hdr;
 	int retval;

@@ -467,20 +468,16 @@ sg_read(struct file *filp, char __user *
 	if (retval)
 		return retval;
 
-	srp = sg_get_rq_mark(sfp, req_pack_id);
+	srp = sg_get_rq_mark(sfp, req_pack_id, &busy);
 	if (!srp) {		/* now wait on packet to arrive */
-		if (atomic_read(&sdp->detaching))
-			return -ENODEV;
 		if (filp->f_flags & O_NONBLOCK)
 			return -EAGAIN;
 		retval = wait_event_interruptible(sfp->read_wait,
-			(atomic_read(&sdp->detaching) ||
-			(srp = sg_get_rq_mark(sfp, req_pack_id))));
-		if (atomic_read(&sdp->detaching))
-			return -ENODEV;
-		if (retval)
-			/* -ERESTARTSYS as signal hit process */
-			return retval;
+			((srp = sg_get_rq_mark(sfp, req_pack_id, &busy)) ||
+			(!busy && atomic_read(&sdp->detaching))));
+		if (!srp)
+			/* signal or detaching */
+			return retval ? retval : -ENODEV;
 	}
 	if (srp->header.interface_id != '\0')
 		return sg_new_read(sfp, buf, count, srp);

@@ -941,9 +938,7 @@ sg_ioctl_common(struct file *filp, Sg_de
 		if (result < 0)
 			return result;
 		result = wait_event_interruptible(sfp->read_wait,
-			(srp_done(sfp, srp) || atomic_read(&sdp->detaching)));
-		if (atomic_read(&sdp->detaching))
-			return -ENODEV;
+			srp_done(sfp, srp));
 		write_lock_irq(&sfp->rq_list_lock);
 		if (srp->done) {
 			srp->done = 2;

@@ -2056,19 +2051,28 @@ sg_unlink_reserve(Sg_fd * sfp, Sg_reques
 }
 
 static Sg_request *
-sg_get_rq_mark(Sg_fd * sfp, int pack_id)
+sg_get_rq_mark(Sg_fd * sfp, int pack_id, bool *busy)
 {
 	Sg_request *resp;
 	unsigned long iflags;
 
+	*busy = false;
 	write_lock_irqsave(&sfp->rq_list_lock, iflags);
 	list_for_each_entry(resp, &sfp->rq_list, entry) {
-		/* look for requests that are ready + not SG_IO owned */
-		if ((1 == resp->done) && (!resp->sg_io_owned) &&
+		/* look for requests that are not SG_IO owned */
+		if ((!resp->sg_io_owned) &&
 		    ((-1 == pack_id) || (resp->header.pack_id == pack_id))) {
-			resp->done = 2;	/* guard against other readers */
-			write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
-			return resp;
+			switch (resp->done) {
+			case 0: /* request active */
+				*busy = true;
+				break;
+			case 1: /* request done; response ready to return */
+				resp->done = 2;	/* guard against other readers */
+				write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
+				return resp;
+			case 2: /* response already being returned */
+				break;
+			}
 		}
 	}
 	write_unlock_irqrestore(&sfp->rq_list_lock, iflags);

@@ -2122,6 +2126,15 @@ sg_remove_request(Sg_fd * sfp, Sg_reques
 		res = 1;
 	}
 	write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
+
+	/*
+	 * If the device is detaching, wakeup any readers in case we just
+	 * removed the last response, which would leave nothing for them to
+	 * return other than -ENODEV.
+	 */
+	if (unlikely(atomic_read(&sfp->parentdp->detaching)))
+		wake_up_interruptible_all(&sfp->read_wait);
+
 	return res;
 }

Greg Kroah-Hartman

author maintainer

2022-08-15 18:22 UTC #79 lore raw

PATCH 79/779 scsi: qla2xxx: Fix incorrect display of max frame size

From: Bikash Hazarika <[email protected]>

commit cf3b4fb655796674e605268bd4bfb47a47c8bce6 upstream.

Replace display field with the correct field.

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

Fixes 8777e4314d39 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine")

Reviewed-by Himanshu Madhani <[email protected]>

Signed-off-by Bikash Hazarika <[email protected]>

Signed-off-by Nilesh Javali <[email protected]>

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

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

---
 drivers/scsi/qla2xxx/qla_def.h  |    1 +
 drivers/scsi/qla2xxx/qla_gs.c   |    9 +++------
 drivers/scsi/qla2xxx/qla_init.c |    2 ++
 drivers/scsi/qla2xxx/qla_isr.c  |    4 +---
 4 files changed, 7 insertions(+), 9 deletions(-)

drivers/scsi/qla2xxx/qla_def.h +1 -0

@@ -3972,6 +3972,7 @@ struct qla_hw_data {
 	/* SRB cache. */
 #define SRB_MIN_REQ     128
 	mempool_t       *srb_mempool;
+	u8 port_name[WWN_SIZE];
 
 	volatile struct {
 		uint32_t	mbox_int		:1;

drivers/scsi/qla2xxx/qla_gs.c +3 -6

@@ -1595,7 +1595,6 @@ qla2x00_hba_attributes(scsi_qla_host_t *
 	unsigned int callopt)
 {
 	struct qla_hw_data *ha = vha->hw;
-	struct init_cb_24xx *icb24 = (void *)ha->init_cb;
 	struct new_utsname *p_sysid = utsname();
 	struct ct_fdmi_hba_attr *eiter;
 	uint16_t alen;

@@ -1757,8 +1756,8 @@ qla2x00_hba_attributes(scsi_qla_host_t *
 	/* MAX CT Payload Length */
 	eiter = entries + size;
 	eiter->type = cpu_to_be16(FDMI_HBA_MAXIMUM_CT_PAYLOAD_LENGTH);
-	eiter->a.max_ct_len = cpu_to_be32(le16_to_cpu(IS_FWI2_CAPABLE(ha) ?
-		icb24->frame_payload_size : ha->init_cb->frame_payload_size));
+	eiter->a.max_ct_len = cpu_to_be32(ha->frame_payload_size >> 2);
+
 	alen = sizeof(eiter->a.max_ct_len);
 	alen += FDMI_ATTR_TYPELEN(eiter);
 	eiter->len = cpu_to_be16(alen);

@@ -1850,7 +1849,6 @@ qla2x00_port_attributes(scsi_qla_host_t
 	unsigned int callopt)
 {
 	struct qla_hw_data *ha = vha->hw;
-	struct init_cb_24xx *icb24 = (void *)ha->init_cb;
 	struct new_utsname *p_sysid = utsname();
 	char *hostname = p_sysid ?
 		p_sysid->nodename : fc_host_system_hostname(vha->host);

@@ -1902,8 +1900,7 @@ qla2x00_port_attributes(scsi_qla_host_t
 	/* Max frame size. */
 	eiter = entries + size;
 	eiter->type = cpu_to_be16(FDMI_PORT_MAX_FRAME_SIZE);
-	eiter->a.max_frame_size = cpu_to_be32(le16_to_cpu(IS_FWI2_CAPABLE(ha) ?
-		icb24->frame_payload_size : ha->init_cb->frame_payload_size));
+	eiter->a.max_frame_size = cpu_to_be32(ha->frame_payload_size);
 	alen = sizeof(eiter->a.max_frame_size);
 	alen += FDMI_ATTR_TYPELEN(eiter);
 	eiter->len = cpu_to_be16(alen);

drivers/scsi/qla2xxx/qla_init.c +2 -0

@@ -4490,6 +4490,8 @@ qla2x00_init_rings(scsi_qla_host_t *vha)
 			 BIT_6) != 0;
 		ql_dbg(ql_dbg_init, vha, 0x00bc, "FA-WWPN Support: %s.\n",
 		    (ha->flags.fawwpn_enabled) ? "enabled" : "disabled");
+		/* Init_cb will be reused for other command(s).  Save a backup copy of port_name */
+		memcpy(ha->port_name, ha->init_cb->port_name, WWN_SIZE);
 	}
 
 	/* ELS pass through payload is limit by frame size. */

drivers/scsi/qla2xxx/qla_isr.c +1 -3

@@ -1354,9 +1354,7 @@ skip_rio:
 			if (!vha->vp_idx) {
 				if (ha->flags.fawwpn_enabled &&
 				    (ha->current_topology == ISP_CFG_F)) {
-					void *wwpn = ha->init_cb->port_name;
-
-					memcpy(vha->port_name, wwpn, WWN_SIZE);
+					memcpy(vha->port_name, ha->port_name, WWN_SIZE);
 					fc_host_port_name(vha->host) =
 					    wwn_to_u64(vha->port_name);
 					ql_dbg(ql_dbg_init + ql_dbg_verbose,

Greg Kroah-Hartman

author maintainer

2022-08-15 18:22 UTC #80 lore raw

PATCH 80/779 scsi: qla2xxx: Zero undefined mailbox IN registers

From: Bikash Hazarika <[email protected]>

commit 6c96a3c7d49593ef15805f5e497601c87695abc9 upstream.

While requesting a new mailbox command, driver does not write any data to unused registers. Initialize the unused register value to zero while requesting a new mailbox command to prevent stale entry access by firmware.

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

Reviewed-by Himanshu Madhani <[email protected]>

Signed-off-by Bikash Hazarika <[email protected]>

Signed-off-by Quinn Tran <[email protected]>

Signed-off-by Nilesh Javali <[email protected]>

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

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

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

drivers/scsi/qla2xxx/qla_mbx.c +2 -0

@@ -238,6 +238,8 @@ qla2x00_mailbox_command(scsi_qla_host_t
 			ql_dbg(ql_dbg_mbx, vha, 0x1112,
 			    "mbox[%d]<-0x%04x\n", cnt, *iptr);
 			wrt_reg_word(optr, *iptr);
+		} else {
+			wrt_reg_word(optr, 0);
 		}
 
 		mboxes >>= 1;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:22 UTC #81 lore raw

PATCH 81/779 soundwire: qcom: Check device status before reading devid

From: Srinivas Kandagatla <[email protected]>

commit aa1262ca66957183ea1fb32a067e145b995f3744 upstream.

As per hardware datasheet its recommended that we check the device status before reading devid assigned by auto-enumeration.

Without this patch we see SoundWire devices with invalid enumeration addresses on the bus.

Fixes a6e6581942ca ("soundwire: qcom: add auto enumeration support")

Signed-off-by Srinivas Kandagatla <[email protected]>

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

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

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

---
 drivers/soundwire/qcom.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/soundwire/qcom.c +4 -0

@@ -451,6 +451,10 @@ static int qcom_swrm_enumerate(struct sd
 	char *buf1 = (char *)&val1, *buf2 = (char *)&val2;
 
 	for (i = 1; i <= SDW_MAX_DEVICES; i++) {
+		/* do not continue if the status is Not Present  */
+		if (!ctrl->status[i])
+			continue;
+
 		/*SCP_Devid5 - Devid 4*/
 		ctrl->reg_read(ctrl, SWRM_ENUMERATOR_SLAVE_DEV_ID_1(i), &val1);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:22 UTC #82 lore raw

PATCH 82/779 ksmbd: fix memory leak in smb2_handle_negotiate

From: Namjae Jeon <[email protected]>

commit aa7253c2393f6dcd6a1468b0792f6da76edad917 upstream.

The allocated memory didn't free under an error path in smb2_handle_negotiate().

Fixes e2f34481b24d ("cifsd: add server-side procedures for SMB3")

Reported-by [email protected] # ZDI-CAN-17815

Signed-off-by Namjae Jeon <[email protected]>

Reviewed-by Hyunchul Lee <[email protected]>

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

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

---
 fs/ksmbd/smb2pdu.c |    4 ++++
 1 file changed, 4 insertions(+)

fs/ksmbd/smb2pdu.c +4 -0

@@ -1146,12 +1146,16 @@ int smb2_handle_negotiate(struct ksmbd_w
 			       status);
 			rsp->hdr.Status = status;
 			rc = -EINVAL;
+			kfree(conn->preauth_info);
+			conn->preauth_info = NULL;
 			goto err_out;
 		}
 
 		rc = init_smb3_11_server(conn);
 		if (rc < 0) {
 			rsp->hdr.Status = STATUS_INVALID_PARAMETER;
+			kfree(conn->preauth_info);
+			conn->preauth_info = NULL;
 			goto err_out;
 		}

Greg Kroah-Hartman

author maintainer

2022-08-15 18:22 UTC #83 lore raw

PATCH 83/779 ksmbd: prevent out of bound read for SMB2_TREE_CONNNECT

From: Hyunchul Lee <[email protected]>

commit 824d4f64c20093275f72fc8101394d75ff6a249e upstream.

if Status is not 0 and PathLength is long,
smb_strndup_from_utf16 could make out of bound
read in smb2_tree_connnect.

This bug can lead an oops looking something like:

[ 1553.882047] BUG: KASAN: slab-out-of-bounds in smb_strndup_from_utf16+0x469/0x4c0 [ksmbd]
[ 1553.882064] Read of size 2 at addr ffff88802c4eda04 by task kworker/0:2/42805
...
[ 1553.882095] Call Trace:
[ 1553.882098]  <TASK>
[ 1553.882101]  dump_stack_lvl+0x49/0x5f
[ 1553.882107]  print_report.cold+0x5e/0x5cf
[ 1553.882112]  ? smb_strndup_from_utf16+0x469/0x4c0 [ksmbd]
[ 1553.882122]  kasan_report+0xaa/0x120
[ 1553.882128]  ? smb_strndup_from_utf16+0x469/0x4c0 [ksmbd]
[ 1553.882139]  __asan_report_load_n_noabort+0xf/0x20
[ 1553.882143]  smb_strndup_from_utf16+0x469/0x4c0 [ksmbd]
[ 1553.882155]  ? smb_strtoUTF16+0x3b0/0x3b0 [ksmbd]
[ 1553.882166]  ? __kmalloc_node+0x185/0x430
[ 1553.882171]  smb2_tree_connect+0x140/0xab0 [ksmbd]
[ 1553.882185]  handle_ksmbd_work+0x30e/0x1020 [ksmbd]
[ 1553.882197]  process_one_work+0x778/0x11c0
[ 1553.882201]  ? _raw_spin_lock_irq+0x8e/0xe0
[ 1553.882206]  worker_thread+0x544/0x1180
[ 1553.882209]  ? __cpuidle_text_end+0x4/0x4
[ 1553.882214]  kthread+0x282/0x320
[ 1553.882218]  ? process_one_work+0x11c0/0x11c0
[ 1553.882221]  ? kthread_complete_and_exit+0x30/0x30
[ 1553.882225]  ret_from_fork+0x1f/0x30
[ 1553.882231]  </TASK>

There is no need to check error request validation in server. This check allow invalid requests not to validate message.

Fixes e2f34481b24d ("cifsd: add server-side procedures for SMB3")

Reported-by [email protected] # ZDI-CAN-17818

Signed-off-by Hyunchul Lee <[email protected]>

Acked-by Namjae Jeon <[email protected]>

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

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

---
 fs/ksmbd/smb2misc.c |    5 -----
 1 file changed, 5 deletions(-)

fs/ksmbd/smb2misc.c +0 -5

@@ -91,11 +91,6 @@ static int smb2_get_data_area_len(unsign
 	*off = 0;
 	*len = 0;
 
-	/* error reqeusts do not have data area */
-	if (hdr->Status && hdr->Status != STATUS_MORE_PROCESSING_REQUIRED &&
-	    (((struct smb2_err_rsp *)hdr)->StructureSize) == SMB2_ERROR_STRUCTURE_SIZE2_LE)
-		return ret;
-
 	/*
 	 * Following commands have data areas so we have to get the location
 	 * of the data buffer offset and data buffer length for the particular

Greg Kroah-Hartman

author maintainer

2022-08-15 18:23 UTC #84 lore raw

PATCH 84/779 ksmbd: fix use-after-free bug in smb2_tree_disconect

From: Namjae Jeon <[email protected]>

commit cf6531d98190fa2cf92a6d8bbc8af0a4740a223c upstream.

smb2_tree_disconnect() freed the struct ksmbd_tree_connect, but it left the dangling pointer. It can be accessed again under compound requests.

This bug can lead an oops looking something link:

[ 1685.468014 ] BUG: KASAN: use-after-free in ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd] [ 1685.468068 ] Read of size 4 at addr ffff888102172180 by task kworker/1:2/4807
...
[ 1685.468130 ] Call Trace:

[ 1685.468132 ]  <TASK>
[ 1685.468135 ]  dump_stack_lvl+0x49/0x5f
[ 1685.468141 ]  print_report.cold+0x5e/0x5cf
[ 1685.468145 ]  ? ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd]
[ 1685.468157 ]  kasan_report+0xaa/0x120
[ 1685.468194 ]  ? ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd]
[ 1685.468206 ]  __asan_report_load4_noabort+0x14/0x20
[ 1685.468210 ]  ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd]
[ 1685.468222 ]  smb2_tree_disconnect+0x175/0x250 [ksmbd]
[ 1685.468235 ]  handle_ksmbd_work+0x30e/0x1020 [ksmbd]
[ 1685.468247 ]  process_one_work+0x778/0x11c0
[ 1685.468251 ]  ? _raw_spin_lock_irq+0x8e/0xe0
[ 1685.468289 ]  worker_thread+0x544/0x1180
[ 1685.468293 ]  ? __cpuidle_text_end+0x4/0x4
[ 1685.468297 ]  kthread+0x282/0x320
[ 1685.468301 ]  ? process_one_work+0x11c0/0x11c0
[ 1685.468305 ]  ? kthread_complete_and_exit+0x30/0x30
[ 1685.468309 ]  ret_from_fork+0x1f/0x30

Fixes e2f34481b24d ("cifsd: add server-side procedures for SMB3")

Reported-by [email protected] # ZDI-CAN-17816

Signed-off-by Namjae Jeon <[email protected]>

Reviewed-by Hyunchul Lee <[email protected]>

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

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

---
 fs/ksmbd/smb2pdu.c |    1 +
 1 file changed, 1 insertion(+)

fs/ksmbd/smb2pdu.c +1 -0

@@ -2044,6 +2044,7 @@ int smb2_tree_disconnect(struct ksmbd_wo
 
 	ksmbd_close_tree_conn_fds(work);
 	ksmbd_tree_conn_disconnect(sess, tcon);
+	work->tcon = NULL;
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2022-08-15 18:23 UTC #85 lore raw

PATCH 85/779 fuse: limit nsec

From: Miklos Szeredi <[email protected]>

commit 47912eaa061a6a81e4aa790591a1874c650733c0 upstream.

Limit nanoseconds to 0..999999999.

Fixes d8a5ba45457e ("[PATCH] FUSE - core")

Signed-off-by Miklos Szeredi <[email protected]>

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

---
 fs/fuse/inode.c |    6 ++++++
 1 file changed, 6 insertions(+)

fs/fuse/inode.c +6 -0

@@ -181,6 +181,12 @@ void fuse_change_attributes_common(struc
 	inode->i_uid     = make_kuid(fc->user_ns, attr->uid);
 	inode->i_gid     = make_kgid(fc->user_ns, attr->gid);
 	inode->i_blocks  = attr->blocks;
+
+	/* Sanitize nsecs */
+	attr->atimensec = min_t(u32, attr->atimensec, NSEC_PER_SEC - 1);
+	attr->mtimensec = min_t(u32, attr->mtimensec, NSEC_PER_SEC - 1);
+	attr->ctimensec = min_t(u32, attr->ctimensec, NSEC_PER_SEC - 1);
+
 	inode->i_atime.tv_sec   = attr->atime;
 	inode->i_atime.tv_nsec  = attr->atimensec;
 	/* mtime from server may be stale due to local buffered write */

Greg Kroah-Hartman

author maintainer

2022-08-15 18:29 UTC #86 lore raw

PATCH 86/779 fuse: ioctl: translate ENOSYS

From: Miklos Szeredi <[email protected]>

commit 02c0cab8e7345b06f1c0838df444e2902e4138d3 upstream.

Overlayfs may fail to complete updates when a filesystem lacks fileattr/xattr syscall support and responds with an ENOSYS error code, resulting in an unexpected "Function not implemented" error.

This bug may occur with FUSE filesystems, such as davfs2.

Steps to reproduce:

  # install davfs2, e.g., apk add davfs2
  mkdir /test mkdir /test/lower /test/upper /test/work /test/mnt
  yes '' | mount -t davfs -o ro http://some-web-dav-server/path \
    /test/lower
  mount -t overlay -o upperdir=/test/upper,lowerdir=/test/lower \
    -o workdir=/test/work overlay /test/mnt

  # when "some-file" exists in the lowerdir, this fails with "Function
  # not implemented", with dmesg showing "overlayfs: failed to retrieve
  # lower fileattr (/some-file, err=-38)"
  touch /test/mnt/some-file

The underlying cause of this regresion is actually in FUSE, which fails to translate the ENOSYS error code returned by userspace filesystem (which means that the ioctl operation is not supported) to ENOTTY.

Reported-by Christian Kohlschütter <[email protected]>

Fixes 72db82115d2b ("ovl: copy up sync/noatime fileattr flags")

Fixes 59efec7b9039 ("fuse: implement ioctl support")

Signed-off-by Miklos Szeredi <[email protected]>

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

---
 fs/fuse/ioctl.c |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

fs/fuse/ioctl.c +13 -2

@@ -9,6 +9,17 @@
 #include <linux/compat.h>
 #include <linux/fileattr.h>
 
+static ssize_t fuse_send_ioctl(struct fuse_mount *fm, struct fuse_args *args)
+{
+	ssize_t ret = fuse_simple_request(fm, args);
+
+	/* Translate ENOSYS, which shouldn't be returned from fs */
+	if (ret == -ENOSYS)
+		ret = -ENOTTY;
+
+	return ret;
+}
+
 /*
  * CUSE servers compiled on 32bit broke on 64bit kernels because the
  * ABI was defined to be 'struct iovec' which is different on 32bit

@@ -259,7 +270,7 @@ long fuse_do_ioctl(struct file *file, un
 	ap.args.out_pages = true;
 	ap.args.out_argvar = true;
 
-	transferred = fuse_simple_request(fm, &ap.args);
+	transferred = fuse_send_ioctl(fm, &ap.args);
 	err = transferred;
 	if (transferred < 0)
 		goto out;

@@ -393,7 +404,7 @@ static int fuse_priv_ioctl(struct inode
 	args.out_args[1].size = inarg.out_size;
 	args.out_args[1].value = ptr;
 
-	err = fuse_simple_request(fm, &args);
+	err = fuse_send_ioctl(fm, &args);
 	if (!err) {
 		if (outarg.result < 0)
 			err = outarg.result;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:24 UTC #87 lore raw

PATCH 87/779 serial: mvebu-uart: uart2 error bits clearing

From: Narendra Hadke <[email protected]>

commit a7209541239e5dd44d981289e5f9059222d40fd1 upstream.

For mvebu uart2, error bits are not cleared on buffer read. This causes interrupt loop and system hang.

Reviewed-by Yi Guo <[email protected]>

Reviewed-by Nadav Haklai <[email protected]>

Signed-off-by Narendra Hadke <[email protected]>

Signed-off-by Pali Rohár <[email protected]>

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

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

---
 drivers/tty/serial/mvebu-uart.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

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

@@ -237,6 +237,7 @@ static void mvebu_uart_rx_chars(struct u
 	struct tty_port *tport = &port->state->port;
 	unsigned char ch = 0;
 	char flag = 0;
+	int ret;
 
 	do {
 		if (status & STAT_RX_RDY(port)) {

@@ -249,6 +250,16 @@ static void mvebu_uart_rx_chars(struct u
 				port->icount.parity++;
 		}
 
+		/*
+		 * For UART2, error bits are not cleared on buffer read.
+		 * This causes interrupt loop and system hang.
+		 */
+		if (IS_EXTENDED(port) && (status & STAT_BRK_ERR)) {
+			ret = readl(port->membase + UART_STAT);
+			ret |= STAT_BRK_ERR;
+			writel(ret, port->membase + UART_STAT);
+		}
+
 		if (status & STAT_BRK_DET) {
 			port->icount.brk++;
 			status &= ~(STAT_FRM_ERR | STAT_PAR_ERR);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #88 lore raw

PATCH 88/779 md-raid: destroy the bitmap after destroying the thread

From: Mikulas Patocka <[email protected]>

commit e151db8ecfb019b7da31d076130a794574c89f6f upstream.

When we ran the lvm test "shell/integrity-blocksize-3.sh" on a kernel with kasan, we got failure in write_page.

The reason for the failure is that md_bitmap_destroy is called before destroying the thread and the thread may be waiting in the function write_page for the bio to complete. When the thread finishes waiting, it executes "if (test_bit(BITMAP_WRITE_ERROR, &bitmap->flags))", which triggers the kasan warning.

Note that the commit 48df498daf62 that caused this bug claims that it is neede for md-cluster, you should check md-cluster and possibly find another bugfix for it.

BUG: KASAN: use-after-free in write_page+0x18d/0x680 [md_mod]
Read of size 8 at addr ffff889162030c78 by task mdX_raid1/5539

CPU: 10 PID: 5539 Comm: mdX_raid1 Not tainted 5.19.0-rc2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x34/0x44
 print_report.cold+0x45/0x57a
 ? __lock_text_start+0x18/0x18
 ? write_page+0x18d/0x680 [md_mod]
 kasan_report+0xa8/0xe0
 ? write_page+0x18d/0x680 [md_mod]
 kasan_check_range+0x13f/0x180
 write_page+0x18d/0x680 [md_mod]
 ? super_sync+0x4d5/0x560 [dm_raid]
 ? md_bitmap_file_kick+0xa0/0xa0 [md_mod]
 ? rs_set_dev_and_array_sectors+0x2e0/0x2e0 [dm_raid]
 ? mutex_trylock+0x120/0x120
 ? preempt_count_add+0x6b/0xc0
 ? preempt_count_sub+0xf/0xc0
 md_update_sb+0x707/0xe40 [md_mod]
 md_reap_sync_thread+0x1b2/0x4a0 [md_mod]
 md_check_recovery+0x533/0x960 [md_mod]
 raid1d+0xc8/0x2a20 [raid1]
 ? var_wake_function+0xe0/0xe0
 ? psi_group_change+0x411/0x500
 ? preempt_count_sub+0xf/0xc0
 ? _raw_spin_lock_irqsave+0x78/0xc0
 ? __lock_text_start+0x18/0x18
 ? raid1_end_read_request+0x2a0/0x2a0 [raid1]
 ? preempt_count_sub+0xf/0xc0
 ? _raw_spin_unlock_irqrestore+0x19/0x40
 ? del_timer_sync+0xa9/0x100
 ? try_to_del_timer_sync+0xc0/0xc0
 ? _raw_spin_lock_irqsave+0x78/0xc0
 ? __lock_text_start+0x18/0x18
 ? __list_del_entry_valid+0x68/0xa0
 ? finish_wait+0xa3/0x100
 md_thread+0x161/0x260 [md_mod]
 ? unregister_md_personality+0xa0/0xa0 [md_mod]
 ? _raw_spin_lock_irqsave+0x78/0xc0
 ? prepare_to_wait_event+0x2c0/0x2c0
 ? unregister_md_personality+0xa0/0xa0 [md_mod]
 kthread+0x148/0x180
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x1f/0x30
 </TASK>

Allocated by task 5522:
 kasan_save_stack+0x1e/0x40
 __kasan_kmalloc+0x80/0xa0
 md_bitmap_create+0xa8/0xe80 [md_mod]
 md_run+0x777/0x1300 [md_mod]
 raid_ctr+0x249c/0x4a30 [dm_raid]
 dm_table_add_target+0x2b0/0x620 [dm_mod]
 table_load+0x1c8/0x400 [dm_mod]
 ctl_ioctl+0x29e/0x560 [dm_mod]
 dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]
 __do_compat_sys_ioctl+0xfa/0x160
 do_syscall_64+0x90/0xc0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Freed by task 5680:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x40
 kasan_set_free_info+0x20/0x40
 __kasan_slab_free+0xf7/0x140
 kfree+0x80/0x240
 md_bitmap_free+0x1c3/0x280 [md_mod]
 __md_stop+0x21/0x120 [md_mod]
 md_stop+0x9/0x40 [md_mod]
 raid_dtr+0x1b/0x40 [dm_raid]
 dm_table_destroy+0x98/0x1e0 [dm_mod]
 __dm_destroy+0x199/0x360 [dm_mod]
 dev_remove+0x10c/0x160 [dm_mod]
 ctl_ioctl+0x29e/0x560 [dm_mod]
 dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]
 __do_compat_sys_ioctl+0xfa/0x160
 do_syscall_64+0x90/0xc0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Signed-off-by Mikulas Patocka <[email protected]>

Fixes 48df498daf62 ("md: move bitmap_destroy to the beginning of __md_stop")

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

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

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

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

drivers/md/md.c +1 -1

@@ -6251,11 +6251,11 @@ static void mddev_detach(struct mddev *m
 static void __md_stop(struct mddev *mddev)
 {
 	struct md_personality *pers = mddev->pers;
-	md_bitmap_destroy(mddev);
 	mddev_detach(mddev);
 	/* Ensure ->event_work is done */
 	if (mddev->event_work.func)
 		flush_workqueue(md_misc_wq);
+	md_bitmap_destroy(mddev);
 	spin_lock(&mddev->lock);
 	mddev->pers = NULL;
 	spin_unlock(&mddev->lock);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #89 lore raw

PATCH 89/779 md-raid10: fix KASAN warning

From: Mikulas Patocka <[email protected]>

commit d17f744e883b2f8d13cca252d71cfe8ace346f7d upstream.

There's a KASAN warning in raid10_remove_disk when running the lvm test lvconvert-raid-reshape.sh. We fix this warning by verifying that the value "number" is valid.

BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]
Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682

CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x34/0x44
 print_report.cold+0x45/0x57a
 ? __lock_text_start+0x18/0x18
 ? raid10_remove_disk+0x61/0x2a0 [raid10]
 kasan_report+0xa8/0xe0
 ? raid10_remove_disk+0x61/0x2a0 [raid10]
 raid10_remove_disk+0x61/0x2a0 [raid10]
Buffer I/O error on dev dm-76, logical block 15344, async page read
 ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0
 remove_and_add_spares+0x367/0x8a0 [md_mod]
 ? super_written+0x1c0/0x1c0 [md_mod]
 ? mutex_trylock+0xac/0x120
 ? _raw_spin_lock+0x72/0xc0
 ? _raw_spin_lock_bh+0xc0/0xc0
 md_check_recovery+0x848/0x960 [md_mod]
 raid10d+0xcf/0x3360 [raid10]
 ? sched_clock_cpu+0x185/0x1a0
 ? rb_erase+0x4d4/0x620
 ? var_wake_function+0xe0/0xe0
 ? psi_group_change+0x411/0x500
 ? preempt_count_sub+0xf/0xc0
 ? _raw_spin_lock_irqsave+0x78/0xc0
 ? __lock_text_start+0x18/0x18
 ? raid10_sync_request+0x36c0/0x36c0 [raid10]
 ? preempt_count_sub+0xf/0xc0
 ? _raw_spin_unlock_irqrestore+0x19/0x40
 ? del_timer_sync+0xa9/0x100
 ? try_to_del_timer_sync+0xc0/0xc0
 ? _raw_spin_lock_irqsave+0x78/0xc0
 ? __lock_text_start+0x18/0x18
 ? _raw_spin_unlock_irq+0x11/0x24
 ? __list_del_entry_valid+0x68/0xa0
 ? finish_wait+0xa3/0x100
 md_thread+0x161/0x260 [md_mod]
 ? unregister_md_personality+0xa0/0xa0 [md_mod]
 ? _raw_spin_lock_irqsave+0x78/0xc0
 ? prepare_to_wait_event+0x2c0/0x2c0
 ? unregister_md_personality+0xa0/0xa0 [md_mod]
 kthread+0x148/0x180
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x1f/0x30
 </TASK>

Allocated by task 124495:
 kasan_save_stack+0x1e/0x40
 __kasan_kmalloc+0x80/0xa0
 setup_conf+0x140/0x5c0 [raid10]
 raid10_run+0x4cd/0x740 [raid10]
 md_run+0x6f9/0x1300 [md_mod]
 raid_ctr+0x2531/0x4ac0 [dm_raid]
 dm_table_add_target+0x2b0/0x620 [dm_mod]
 table_load+0x1c8/0x400 [dm_mod]
 ctl_ioctl+0x29e/0x560 [dm_mod]
 dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]
 __do_compat_sys_ioctl+0xfa/0x160
 do_syscall_64+0x90/0xc0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Last potentially related work creation:
 kasan_save_stack+0x1e/0x40
 __kasan_record_aux_stack+0x9e/0xc0
 kvfree_call_rcu+0x84/0x480
 timerfd_release+0x82/0x140
L __fput+0xfa/0x400
 task_work_run+0x80/0xc0
 exit_to_user_mode_prepare+0x155/0x160
 syscall_exit_to_user_mode+0x12/0x40
 do_syscall_64+0x42/0xc0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Second to last potentially related work creation:
 kasan_save_stack+0x1e/0x40
 __kasan_record_aux_stack+0x9e/0xc0
 kvfree_call_rcu+0x84/0x480
 timerfd_release+0x82/0x140
 __fput+0xfa/0x400
 task_work_run+0x80/0xc0
 exit_to_user_mode_prepare+0x155/0x160
 syscall_exit_to_user_mode+0x12/0x40
 do_syscall_64+0x42/0xc0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

The buggy address belongs to the object at ffff889108f3d200
 which belongs to the cache kmalloc-256 of size 256

The buggy address is located 0 bytes to the right of
256-byte region [ffff889108f3d200, ffff889108f3d300)

The buggy address belongs to the physical page:
page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c
head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0
flags: 0x4000000000010200(slab|head|zone=2)
raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40
raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff889108f3d280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff889108f3d300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                   ^
 ffff889108f3d380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff889108f3d400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Signed-off-by Mikulas Patocka <[email protected]>

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

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

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

---
 drivers/md/raid10.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/md/raid10.c +4 -1

@@ -2139,9 +2139,12 @@ static int raid10_remove_disk(struct mdd
 	int err = 0;
 	int number = rdev->raid_disk;
 	struct md_rdev **rdevp;
-	struct raid10_info *p = conf->mirrors + number;
+	struct raid10_info *p;
 
 	print_conf(conf);
+	if (unlikely(number >= mddev->raid_disks))
+		return 0;
+	p = conf->mirrors + number;
 	if (rdev == p->rdev)
 		rdevp = &p->rdev;
 	else if (rdev == p->replacement)

Pavel Machek

2022-08-19 10:45 UTC #90 lore raw

Re: [PATCH 5.15 089/779] md-raid10: fix KASAN warning

Hi!

Quoted 10 lines

From: Mikulas Patocka <[email protected]>
commit d17f744e883b2f8d13cca252d71cfe8ace346f7d upstream.
There's a KASAN warning in raid10_remove_disk when running the lvm test lvconvert-raid-reshape.sh. We fix this warning by verifying that the value "number" is valid.
BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]
Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682

Is this place for array_index_nospec?

Best regards,
Pavel

Quoted 17 lines

drivers/md/raid10.c +4 -1

@@ -2139,9 +2139,12 @@ static int raid10_remove_disk(struct mdd
 	int err = 0;
 	int number = rdev->raid_disk;
 	struct md_rdev **rdevp;
-	struct raid10_info *p = conf->mirrors + number;
+	struct raid10_info *p;
 
 	print_conf(conf);
+	if (unlikely(number >= mddev->raid_disks))
+		return 0;
+	p = conf->mirrors + number;
 	if (rdev == p->rdev)
 		rdevp = &p->rdev;
 	else if (rdev == p->replacement)

Signature · 2 lines

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Mikulas Patocka

2022-08-20 16:04 UTC #91 lore raw

Re: [PATCH 5.15 089/779] md-raid10: fix KASAN warning

Quoted 10 lines · Pavel Machek

Hi!
Quoted 8 lines
From: Mikulas Patocka <[email protected]>
commit d17f744e883b2f8d13cca252d71cfe8ace346f7d upstream.
There's a KASAN warning in raid10_remove_disk when running the lvm test lvconvert-raid-reshape.sh. We fix this warning by verifying that the value "number" is valid.

Quoted 7 lines

Quoted 2 lines
BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]
Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682
Is this place for array_index_nospec?
Best regards,
Pavel

I think it is not needed - userspace code can't trigger this code path at will.

Mikulas

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #92 lore raw

PATCH 90/779 mbcache: dont reclaim used entries

From: Jan Kara <[email protected]>

commit 58318914186c157477b978b1739dfe2f1b9dc0fe upstream.

Do not reclaim entries that are currently used by somebody from a shrinker. Firstly, these entries are likely useful. Secondly, we will need to keep such entries to protect pending increment of xattr block refcount.

CC [email protected]

Fixes 82939d7999df ("ext4: convert to mbcache2")

Signed-off-by Jan Kara <[email protected]>

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

Signed-off-by Theodore Ts'o <[email protected]>

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

---
 fs/mbcache.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

fs/mbcache.c +9 -1

@@ -288,7 +288,7 @@ static unsigned long mb_cache_shrink(str
 	while (nr_to_scan-- && !list_empty(&cache->c_list)) {
 		entry = list_first_entry(&cache->c_list,
 					 struct mb_cache_entry, e_list);
-		if (entry->e_referenced) {
+		if (entry->e_referenced || atomic_read(&entry->e_refcnt) > 2) {
 			entry->e_referenced = 0;
 			list_move_tail(&entry->e_list, &cache->c_list);
 			continue;

@@ -302,6 +302,14 @@ static unsigned long mb_cache_shrink(str
 		spin_unlock(&cache->c_list_lock);
 		head = mb_cache_entry_head(cache, entry->e_key);
 		hlist_bl_lock(head);
+		/* Now a reliable check if the entry didn't get used... */
+		if (atomic_read(&entry->e_refcnt) > 2) {
+			hlist_bl_unlock(head);
+			spin_lock(&cache->c_list_lock);
+			list_add_tail(&entry->e_list, &cache->c_list);
+			cache->c_entry_count++;
+			continue;
+		}
 		if (!hlist_bl_unhashed(&entry->e_hash_list)) {
 			hlist_bl_del_init(&entry->e_hash_list);
 			atomic_dec(&entry->e_refcnt);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #93 lore raw

PATCH 91/779 mbcache: add functions to delete entry if unused

From: Jan Kara <[email protected]>

commit 3dc96bba65f53daa217f0a8f43edad145286a8f5 upstream.

Add function mb_cache_entry_delete_or_get() to delete mbcache entry if it is unused and also add a function to wait for entry to become unused
- mb_cache_entry_wait_unused(). We do not share code between the two deleting function as one of them will go away soon.

CC [email protected]

Fixes 82939d7999df ("ext4: convert to mbcache2")

Signed-off-by Jan Kara <[email protected]>

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

Signed-off-by Theodore Ts'o <[email protected]>

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

---
 fs/mbcache.c            |   66 ++++++++++++++++++++++++++++++++++++++++++++++--
 include/linux/mbcache.h |   10 ++++++-
 2 files changed, 73 insertions(+), 3 deletions(-)

fs/mbcache.c +64 -2

@@ -11,7 +11,7 @@
 /*
  * Mbcache is a simple key-value store. Keys need not be unique, however
  * key-value pairs are expected to be unique (we use this fact in
- * mb_cache_entry_delete()).
+ * mb_cache_entry_delete_or_get()).
  *
  * Ext2 and ext4 use this cache for deduplication of extended attribute blocks.
  * Ext4 also uses it for deduplication of xattr values stored in inodes.

@@ -125,6 +125,19 @@ void __mb_cache_entry_free(struct mb_cac
 }
 EXPORT_SYMBOL(__mb_cache_entry_free);
 
+/*
+ * mb_cache_entry_wait_unused - wait to be the last user of the entry
+ *
+ * @entry - entry to work on
+ *
+ * Wait to be the last user of the entry.
+ */
+void mb_cache_entry_wait_unused(struct mb_cache_entry *entry)
+{
+	wait_var_event(&entry->e_refcnt, atomic_read(&entry->e_refcnt) <= 3);
+}
+EXPORT_SYMBOL(mb_cache_entry_wait_unused);
+
 static struct mb_cache_entry *__entry_find(struct mb_cache *cache,
 					   struct mb_cache_entry *entry,
 					   u32 key)

@@ -217,7 +230,7 @@ out:
 }
 EXPORT_SYMBOL(mb_cache_entry_get);
 
-/* mb_cache_entry_delete - remove a cache entry
+/* mb_cache_entry_delete - try to remove a cache entry
  * @cache - cache we work with
  * @key - key
  * @value - value

@@ -254,6 +267,55 @@ void mb_cache_entry_delete(struct mb_cac
 }
 EXPORT_SYMBOL(mb_cache_entry_delete);
 
+/* mb_cache_entry_delete_or_get - remove a cache entry if it has no users
+ * @cache - cache we work with
+ * @key - key
+ * @value - value
+ *
+ * Remove entry from cache @cache with key @key and value @value. The removal
+ * happens only if the entry is unused. The function returns NULL in case the
+ * entry was successfully removed or there's no entry in cache. Otherwise the
+ * function grabs reference of the entry that we failed to delete because it
+ * still has users and return it.
+ */
+struct mb_cache_entry *mb_cache_entry_delete_or_get(struct mb_cache *cache,
+						    u32 key, u64 value)
+{
+	struct hlist_bl_node *node;
+	struct hlist_bl_head *head;
+	struct mb_cache_entry *entry;
+
+	head = mb_cache_entry_head(cache, key);
+	hlist_bl_lock(head);
+	hlist_bl_for_each_entry(entry, node, head, e_hash_list) {
+		if (entry->e_key == key && entry->e_value == value) {
+			if (atomic_read(&entry->e_refcnt) > 2) {
+				atomic_inc(&entry->e_refcnt);
+				hlist_bl_unlock(head);
+				return entry;
+			}
+			/* We keep hash list reference to keep entry alive */
+			hlist_bl_del_init(&entry->e_hash_list);
+			hlist_bl_unlock(head);
+			spin_lock(&cache->c_list_lock);
+			if (!list_empty(&entry->e_list)) {
+				list_del_init(&entry->e_list);
+				if (!WARN_ONCE(cache->c_entry_count == 0,
+		"mbcache: attempt to decrement c_entry_count past zero"))
+					cache->c_entry_count--;
+				atomic_dec(&entry->e_refcnt);
+			}
+			spin_unlock(&cache->c_list_lock);
+			mb_cache_entry_put(cache, entry);
+			return NULL;
+		}
+	}
+	hlist_bl_unlock(head);
+
+	return NULL;
+}
+EXPORT_SYMBOL(mb_cache_entry_delete_or_get);
+
 /* mb_cache_entry_touch - cache entry got used
  * @cache - cache the entry belongs to
  * @entry - entry that got used

include/linux/mbcache.h +9 -1

@@ -30,15 +30,23 @@ void mb_cache_destroy(struct mb_cache *c
 int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
 			  u64 value, bool reusable);
 void __mb_cache_entry_free(struct mb_cache_entry *entry);
+void mb_cache_entry_wait_unused(struct mb_cache_entry *entry);
 static inline int mb_cache_entry_put(struct mb_cache *cache,
 				     struct mb_cache_entry *entry)
 {
-	if (!atomic_dec_and_test(&entry->e_refcnt))
+	unsigned int cnt = atomic_dec_return(&entry->e_refcnt);
+
+	if (cnt > 0) {
+		if (cnt <= 3)
+			wake_up_var(&entry->e_refcnt);
 		return 0;
+	}
 	__mb_cache_entry_free(entry);
 	return 1;
 }
 
+struct mb_cache_entry *mb_cache_entry_delete_or_get(struct mb_cache *cache,
+						    u32 key, u64 value);
 void mb_cache_entry_delete(struct mb_cache *cache, u32 key, u64 value);
 struct mb_cache_entry *mb_cache_entry_get(struct mb_cache *cache, u32 key,
 					  u64 value);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #94 lore raw

PATCH 92/779 media: [PATCH] pci: atomisp_cmd: fix three missing checks on list iterator

Link https://lore.kernel.org/linux-media/[email protected] open here

From: Xiaomeng Tong <[email protected]>

commit 09b204eb9de9fdf07d028c41c4331b5cfeb70dd7 upstream.

The three bugs are here:

	__func__, s3a_buf->s3a_data->exp_id);
	__func__, md_buf->metadata->exp_id);
	__func__, dis_buf->dis_data->exp_id);

The list iterator 's3a_buf/md_buf/dis_buf' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to a invalid memory access.

To fix this bug, add an check. Use a new variable '*_iter' as the list iterator, while use the old variable '*_buf' as a dedicated pointer to point to the found element.

Fixes ad85094b293e4 ("Revert "media: staging: atomisp: Remove driver"")

Signed-off-by Xiaomeng Tong <[email protected]>

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

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

---
 drivers/staging/media/atomisp/pci/atomisp_cmd.c |   57 +++++++++++++++---------
 1 file changed, 36 insertions(+), 21 deletions(-)

drivers/staging/media/atomisp/pci/atomisp_cmd.c +36 ~~-21~~

@@ -899,9 +899,9 @@ void atomisp_buf_done(struct atomisp_sub
 	int err;
 	unsigned long irqflags;
 	struct ia_css_frame *frame = NULL;
-	struct atomisp_s3a_buf *s3a_buf = NULL, *_s3a_buf_tmp;
-	struct atomisp_dis_buf *dis_buf = NULL, *_dis_buf_tmp;
-	struct atomisp_metadata_buf *md_buf = NULL, *_md_buf_tmp;
+	struct atomisp_s3a_buf *s3a_buf = NULL, *_s3a_buf_tmp, *s3a_iter;
+	struct atomisp_dis_buf *dis_buf = NULL, *_dis_buf_tmp, *dis_iter;
+	struct atomisp_metadata_buf *md_buf = NULL, *_md_buf_tmp, *md_iter;
 	enum atomisp_metadata_type md_type;
 	struct atomisp_device *isp = asd->isp;
 	struct v4l2_control ctrl;

@@ -940,60 +940,75 @@ void atomisp_buf_done(struct atomisp_sub
 
 	switch (buf_type) {
 	case IA_CSS_BUFFER_TYPE_3A_STATISTICS:
-		list_for_each_entry_safe(s3a_buf, _s3a_buf_tmp,
+		list_for_each_entry_safe(s3a_iter, _s3a_buf_tmp,
 					 &asd->s3a_stats_in_css, list) {
-			if (s3a_buf->s3a_data ==
+			if (s3a_iter->s3a_data ==
 			    buffer.css_buffer.data.stats_3a) {
-				list_del_init(&s3a_buf->list);
-				list_add_tail(&s3a_buf->list,
+				list_del_init(&s3a_iter->list);
+				list_add_tail(&s3a_iter->list,
 					      &asd->s3a_stats_ready);
+				s3a_buf = s3a_iter;
 				break;
 			}
 		}
 
 		asd->s3a_bufs_in_css[css_pipe_id]--;
 		atomisp_3a_stats_ready_event(asd, buffer.css_buffer.exp_id);
-		dev_dbg(isp->dev, "%s: s3a stat with exp_id %d is ready\n",
-			__func__, s3a_buf->s3a_data->exp_id);
+		if (s3a_buf)
+			dev_dbg(isp->dev, "%s: s3a stat with exp_id %d is ready\n",
+				__func__, s3a_buf->s3a_data->exp_id);
+		else
+			dev_dbg(isp->dev, "%s: s3a stat is ready with no exp_id found\n",
+				__func__);
 		break;
 	case IA_CSS_BUFFER_TYPE_METADATA:
 		if (error)
 			break;
 
 		md_type = atomisp_get_metadata_type(asd, css_pipe_id);
-		list_for_each_entry_safe(md_buf, _md_buf_tmp,
+		list_for_each_entry_safe(md_iter, _md_buf_tmp,
 					 &asd->metadata_in_css[md_type], list) {
-			if (md_buf->metadata ==
+			if (md_iter->metadata ==
 			    buffer.css_buffer.data.metadata) {
-				list_del_init(&md_buf->list);
-				list_add_tail(&md_buf->list,
+				list_del_init(&md_iter->list);
+				list_add_tail(&md_iter->list,
 					      &asd->metadata_ready[md_type]);
+				md_buf = md_iter;
 				break;
 			}
 		}
 		asd->metadata_bufs_in_css[stream_id][css_pipe_id]--;
 		atomisp_metadata_ready_event(asd, md_type);
-		dev_dbg(isp->dev, "%s: metadata with exp_id %d is ready\n",
-			__func__, md_buf->metadata->exp_id);
+		if (md_buf)
+			dev_dbg(isp->dev, "%s: metadata with exp_id %d is ready\n",
+				__func__, md_buf->metadata->exp_id);
+		else
+			dev_dbg(isp->dev, "%s: metadata is ready with no exp_id found\n",
+				__func__);
 		break;
 	case IA_CSS_BUFFER_TYPE_DIS_STATISTICS:
-		list_for_each_entry_safe(dis_buf, _dis_buf_tmp,
+		list_for_each_entry_safe(dis_iter, _dis_buf_tmp,
 					 &asd->dis_stats_in_css, list) {
-			if (dis_buf->dis_data ==
+			if (dis_iter->dis_data ==
 			    buffer.css_buffer.data.stats_dvs) {
 				spin_lock_irqsave(&asd->dis_stats_lock,
 						  irqflags);
-				list_del_init(&dis_buf->list);
-				list_add(&dis_buf->list, &asd->dis_stats);
+				list_del_init(&dis_iter->list);
+				list_add(&dis_iter->list, &asd->dis_stats);
 				asd->params.dis_proj_data_valid = true;
 				spin_unlock_irqrestore(&asd->dis_stats_lock,
 						       irqflags);
+				dis_buf = dis_iter;
 				break;
 			}
 		}
 		asd->dis_bufs_in_css--;
-		dev_dbg(isp->dev, "%s: dis stat with exp_id %d is ready\n",
-			__func__, dis_buf->dis_data->exp_id);
+		if (dis_buf)
+			dev_dbg(isp->dev, "%s: dis stat with exp_id %d is ready\n",
+				__func__, dis_buf->dis_data->exp_id);
+		else
+			dev_dbg(isp->dev, "%s: dis stat is ready with no exp_id found\n",
+				__func__);
 		break;
 	case IA_CSS_BUFFER_TYPE_VF_OUTPUT_FRAME:
 	case IA_CSS_BUFFER_TYPE_SEC_VF_OUTPUT_FRAME:

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #95 lore raw

PATCH 93/779 ia64, processor: fix -Wincompatible-pointer-types in ia64_get_irr()

From: Alexander Lobakin <[email protected]>

commit e5a16a5c4602c119262f350274021f90465f479d upstream.

test_bit(), as any other bitmap op, takes unsigned long * as a second argument (pointer to the actual bitmap), as any bitmap itself is an array of unsigned longs. However, the ia64_get_irr() code passes a ref to u64 as a second argument.
This works with the ia64 bitops implementation due to that they have void * as the second argument and then cast it later on. This works with the bitmap API itself due to that unsigned long has the same size on ia64 as u64 (unsigned long long), but from the compiler PoV those two are different.
Define @irr as unsigned long to fix that. That implies no functional changes. Has been hidden for 16 years!

Fixes a58786917ce2 ("[IA64] avoid broken SAL_CACHE_FLUSH implementations")

Cc [email protected] # 2.6.16+

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

Reviewed-by Andy Shevchenko <[email protected]>

Reviewed-by Yury Norov <[email protected]>

Signed-off-by Yury Norov <[email protected]>

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

---
 arch/ia64/include/asm/processor.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/ia64/include/asm/processor.h +1 -1

@@ -542,7 +542,7 @@ ia64_get_irr(unsigned int vector)
 {
 	unsigned int reg = vector / 64;
 	unsigned int bit = vector % 64;
-	u64 irr;
+	unsigned long irr;
 
 	switch (reg) {
 	case 0: irr = ia64_getreg(_IA64_REG_CR_IRR0); break;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #96 lore raw

PATCH 94/779 powerpc/fsl-pci: Fix Class Code of PCIe Root Port

From: Pali Rohár <[email protected]>

commit 0c551abfa004ce154d487d91777bf221c808a64f upstream.

By default old pre-3.0 Freescale PCIe controllers reports invalid PCI Class Code 0x0b20 for PCIe Root Port. It can be seen by lspci -b output on P2020 board which has this pre-3.0 controller:

  $ lspci -bvnn
  00:00.0 Power PC [0b20]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21)
          !!! Invalid class 0b20 for header type 01
          Capabilities: [4c] Express Root Port (Slot-), MSI 00

Fix this issue by programming correct PCI Class Code 0x0604 for PCIe Root Port to the Freescale specific PCIe register 0x474.

With this change lspci -b output is:

  $ lspci -bvnn
  00:00.0 PCI bridge [0604]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21) (prog-if 00 [Normal decode])
          Capabilities: [4c] Express Root Port (Slot-), MSI 00

Without any "Invalid class" error. So class code was properly reflected into standard (read-only) PCI register 0x08.

Same fix is already implemented in U-Boot pcie_fsl.c driver in commit:
http://source.denx.de/u-boot/u-boot/-/commit/d18d06ac35229345a0af80977a408cfbe1d1015b

Fix activated by U-Boot stay active also after booting Linux kernel. But boards which use older U-Boot version without that fix are affected and still require this fix.

So implement this class code fix also in kernel fsl_pci.c driver.

Signed-off-by Pali Rohár <[email protected]>

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

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

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

---
 arch/powerpc/sysdev/fsl_pci.c |    8 ++++++++
 arch/powerpc/sysdev/fsl_pci.h |    1 +
 2 files changed, 9 insertions(+)

arch/powerpc/sysdev/fsl_pci.c +8 -0

@@ -520,6 +520,7 @@ int fsl_add_bridge(struct platform_devic
 	struct resource rsrc;
 	const int *bus_range;
 	u8 hdr_type, progif;
+	u32 class_code;
 	struct device_node *dev;
 	struct ccsr_pci __iomem *pci;
 	u16 temp;

@@ -593,6 +594,13 @@ int fsl_add_bridge(struct platform_devic
 			PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS;
 		if (fsl_pcie_check_link(hose))
 			hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
+		/* Fix Class Code to PCI_CLASS_BRIDGE_PCI_NORMAL for pre-3.0 controller */
+		if (in_be32(&pci->block_rev1) < PCIE_IP_REV_3_0) {
+			early_read_config_dword(hose, 0, 0, PCIE_FSL_CSR_CLASSCODE, &class_code);
+			class_code &= 0xff;
+			class_code |= PCI_CLASS_BRIDGE_PCI_NORMAL << 8;
+			early_write_config_dword(hose, 0, 0, PCIE_FSL_CSR_CLASSCODE, class_code);
+		}
 	} else {
 		/*
 		 * Set PBFR(PCI Bus Function Register)[10] = 1 to

arch/powerpc/sysdev/fsl_pci.h +1 -0

@@ -18,6 +18,7 @@ struct platform_device;
 
 #define PCIE_LTSSM	0x0404		/* PCIE Link Training and Status */
 #define PCIE_LTSSM_L0	0x16		/* L0 state */
+#define PCIE_FSL_CSR_CLASSCODE	0x474	/* FSL GPEX CSR */
 #define PCIE_IP_REV_2_2		0x02080202 /* PCIE IP block version Rev2.2 */
 #define PCIE_IP_REV_3_0		0x02080300 /* PCIE IP block version Rev3.0 */
 #define PIWAR_EN		0x80000000	/* Enable */

Greg Kroah-Hartman

author maintainer

2022-08-15 18:29 UTC #97 lore raw

PATCH 95/779 powerpc/ptdump: Fix display of RW pages on FSL_BOOK3E

From: Christophe Leroy <[email protected]>

commit dd8de84b57b02ba9c1fe530a6d916c0853f136bd upstream.

On FSL_BOOK3E, _PAGE_RW is defined with two bits, one for user and one for supervisor. As soon as one of the two bits is set, the page has to be display as RW. But the way it is implemented today requires both bits to be set in order to display it as RW.

Instead of display RW when _PAGE_RW bits are set and R otherwise, reverse the logic and display R when _PAGE_RW bits are all 0 and RW otherwise.

This change has no impact on other platforms as _PAGE_RW is a single bit on all of them.

Fixes 8eb07b187000 ("powerpc/mm: Dump linux pagetables")

Link https://lore.kernel.org/r/0c33b96317811edf691e81698aaee8fa45ec3449.1656427391.git.christophe.leroy@csgroup.eu open here

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

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

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

---
 arch/powerpc/mm/ptdump/shared.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/powerpc/mm/ptdump/shared.c +3 -3

@@ -17,9 +17,9 @@ static const struct flag_info flag_array
 		.clear	= "    ",
 	}, {
 		.mask	= _PAGE_RW,
-		.val	= _PAGE_RW,
-		.set	= "rw",
-		.clear	= "r ",
+		.val	= 0,
+		.set	= "r ",
+		.clear	= "rw",
 	}, {
 		.mask	= _PAGE_EXEC,
 		.val	= _PAGE_EXEC,

Greg Kroah-Hartman

author maintainer

2022-08-15 18:24 UTC #98 lore raw

PATCH 96/779 powerpc/powernv: Avoid crashing if rng is NULL

From: Michael Ellerman <[email protected]>

commit 90b5d4fe0b3ba7f589c6723c6bfb559d9e83956a upstream.

On a bare-metal Power8 system that doesn't have an "ibm,power-rng", a malicious QEMU and guest that ignore the absence of the KVM_CAP_PPC_HWRNG flag, and calls H_RANDOM anyway, will dereference a NULL pointer.

In practice all Power8 machines have an "ibm,power-rng", but let's not rely on that, add a NULL check and early return in powernv_get_random_real_mode().

Fixes e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.")

Cc [email protected] # v4.1+

Signed-off-by Jason A. Donenfeld <[email protected]>

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

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

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

---
 arch/powerpc/platforms/powernv/rng.c |    2 ++
 1 file changed, 2 insertions(+)

arch/powerpc/platforms/powernv/rng.c +2 -0

@@ -63,6 +63,8 @@ int powernv_get_random_real_mode(unsigne
 	struct powernv_rng *rng;
 
 	rng = raw_cpu_read(powernv_rng);
+	if (!rng)
+		return 0;
 
 	*v = rng_whiten(rng, __raw_rm_readq(rng->regs_real));

Greg Kroah-Hartman

author maintainer

2022-08-15 18:24 UTC #99 lore raw

PATCH 97/779 MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK

From: Huacai Chen <[email protected]>

commit e1a534f5d074db45ae5cbac41d8912b98e96a006 upstream.

When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.

[    3.052463] ------------[ cut here ]------------
[    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
[    3.070072] Modules linked in: efivarfs autofs4
[    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
[    3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27
[    3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000
[    3.109127]         9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430
[    3.118774]         90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff
[    3.128412]         0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890
[    3.138056]         0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa
[    3.147711]         ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000
[    3.157364]         900000000101c998 0000000000000004 9000000000ef7430 0000000000000000
[    3.167012]         0000000000000009 000000000000006c 0000000000000000 0000000000000000
[    3.176641]         9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286
[    3.186260]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
[    3.195868]         ...
[    3.199917] Call Trace:
[    3.203941] [<98000000002086d8>] show_stack+0x38/0x14c
[    3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88
[    3.217625] [<980000000023d268>] __warn+0xd0/0x100
[    3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc
[    3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0
[    3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4
[    3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4
[    3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0
[    3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100
[    3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94
[    3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160
[    3.281824] ---[ end trace 8b484262b4b8c24c ]---

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

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

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

---
 arch/mips/kernel/proc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/mips/kernel/proc.c +1 -1

@@ -172,7 +172,7 @@ static void *c_start(struct seq_file *m,
 {
 	unsigned long i = *pos;
 
-	return i < NR_CPUS ? (void *) (i + 1) : NULL;
+	return i < nr_cpu_ids ? (void *) (i + 1) : NULL;
 }
 
 static void *c_next(struct seq_file *m, void *v, loff_t *pos)

Greg Kroah-Hartman

author maintainer

2022-08-15 18:24 UTC #100 lore raw

PATCH 98/779 coresight: Clear the connection field properly

From: Suzuki K Poulose <[email protected]>

commit 2af89ebacf299b7fba5f3087d35e8a286ec33706 upstream.

coresight devices track their connections (output connections) and hold a reference to the fwnode. When a device goes away, we walk through the devices on the coresight bus and make sure that the references are dropped. This happens both ways:
a) For all output connections from the device, drop the reference to the target device via coresight_release_platform_data()

b) Iterate over all the devices on the coresight bus and drop the reference to fwnode if *this* device is the target of the output connection, via coresight_remove_conns()->coresight_remove_match().

However, the coresight_remove_match() doesn't clear the fwnode field, after dropping the reference, this causes use-after-free and additional refcount drops on the fwnode.

e.g., if we have two devices, A and B, with a connection, A -> B. If we remove B first, B would clear the reference on B, from A via coresight_remove_match(). But when A is removed, it still has a connection with fwnode still pointing to B. Thus it tries to drops the reference in coresight_release_platform_data(), raising the bells like :

[   91.990153] ------------[ cut here ]------------
[   91.990163] refcount_t: addition on 0; use-after-free.
[   91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144
[   91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-)
 crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug]
[   91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G        W       T 5.19.0-rc2+ #53
[   91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb  1 2019
[   91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   91.990454] pc : refcount_warn_saturate+0xa0/0x144
[   91.990476] lr : refcount_warn_saturate+0xa0/0x144
[   91.990496] sp : ffff80000c843640
[   91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8
[   91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8
[   91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2
[   91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40
[   91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0
[   91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375
[   91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28
[   91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572
[   91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027
[   91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00
[   91.991000] Call trace:
[   91.991012]  refcount_warn_saturate+0xa0/0x144
[   91.991034]  kobject_get+0xac/0xb0
[   91.991055]  of_node_get+0x2c/0x40
[   91.991076]  of_fwnode_get+0x40/0x60
[   91.991094]  fwnode_handle_get+0x3c/0x60
[   91.991116]  fwnode_get_nth_parent+0xf4/0x110
[   91.991137]  fwnode_full_name_string+0x48/0xc0
[   91.991158]  device_node_string+0x41c/0x530
[   91.991178]  pointer+0x320/0x3ec
[   91.991198]  vsnprintf+0x23c/0x750
[   91.991217]  vprintk_store+0x104/0x4b0
[   91.991238]  vprintk_emit+0x8c/0x360
[   91.991257]  vprintk_default+0x44/0x50
[   91.991276]  vprintk+0xcc/0xf0
[   91.991295]  _printk+0x68/0x90
[   91.991315]  of_node_release+0x13c/0x14c
[   91.991334]  kobject_put+0x98/0x114
[   91.991354]  of_node_put+0x24/0x34
[   91.991372]  of_fwnode_put+0x40/0x5c
[   91.991390]  fwnode_handle_put+0x38/0x50
[   91.991411]  coresight_release_platform_data+0x74/0xb0 [coresight]
[   91.991472]  coresight_unregister+0x64/0xcc [coresight]
[   91.991525]  etm4_remove_dev+0x64/0x78 [coresight_etm4x]
[   91.991563]  etm4_remove_amba+0x1c/0x2c [coresight_etm4x]
[   91.991598]  amba_remove+0x3c/0x19c

Reproducible by: (Build all coresight components as modules):

#!/bin/sh
while true
do
for m in tmc stm cpu_debug etm4x replicator funnel do
modprobe coresight_${m}
done

for m in tmc stm cpu_debug etm4x replicator funnel do
rmmode coresight_${m}
done
done

Cc Mathieu Poirier <[email protected]>

Cc Mike Leach <[email protected]>

Cc Leo Yan <[email protected]>

Signed-off-by Suzuki K Poulose <[email protected]>

Fixes 37ea1ffddffa ("coresight: Use fwnode handle instead of device names")

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

Signed-off-by Mathieu Poirier <[email protected]>

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

---
 drivers/hwtracing/coresight/coresight-core.c |    1 +
 1 file changed, 1 insertion(+)

drivers/hwtracing/coresight/coresight-core.c +1 -0

@@ -1427,6 +1427,7 @@ static int coresight_remove_match(struct
 			 * platform data.
 			 */
 			fwnode_handle_put(conn->child_fwnode);
+			conn->child_fwnode = NULL;
 			/* No need to continue */
 			break;
 		}

Greg Kroah-Hartman

author maintainer

2022-08-15 18:25 UTC #101 lore raw

PATCH 99/779 usb: typec: ucsi: Acknowledge the GET_ERROR_STATUS command completion

From: Linyu Yuan <[email protected]>

commit a7dc438b5e446afcd1b3b6651da28271400722f2 upstream.

We found PPM will not send any notification after it report error status and OPM issue GET_ERROR_STATUS command to read the details about error.

According UCSI spec, PPM may clear the Error Status Data after the OPM has acknowledged the command completion.

This change add operation to acknowledge the command completion from PPM.

Fixes bdc62f2bae8f (usb: typec: ucsi: Simplified registration and I/O API)

Cc <[email protected]> # 5.10

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

Signed-off-by Linyu Yuan <[email protected]>

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

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

---
 drivers/usb/typec/ucsi/ucsi.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/usb/typec/ucsi/ucsi.c +4 -0

@@ -76,6 +76,10 @@ static int ucsi_read_error(struct ucsi *
 	if (ret)
 		return ret;
 
+	ret = ucsi_acknowledge_command(ucsi);
+	if (ret)
+		return ret;
+
 	switch (error) {
 	case UCSI_ERROR_INCOMPATIBLE_PARTNER:
 		return -EOPNOTSUPP;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:25 UTC #102 lore raw

PATCH 100/779 USB: HCD: Fix URB giveback issue in tasklet function

From: Weitao Wang <[email protected]>

commit 26c6c2f8a907c9e3a2f24990552a4d77235791e6 upstream.

Usb core introduce the mechanism of giveback of URB in tasklet context to reduce hardware interrupt handling time. On some test situation(such as FIO with 4KB block size), when tasklet callback function called to giveback URB, interrupt handler add URB node to the bh->head list also. If check bh->head list again after finish all URB giveback of local_list, then it may introduce a "dynamic balance" between giveback URB and add URB to bh->head list. This tasklet callback function may not exit for a long time, which will cause other tasklet function calls to be delayed. Some real-time applications(such as KB and Mouse) will see noticeable lag.

In order to prevent the tasklet function from occupying the cpu for a long time at a time, new URBS will not be added to the local_list even though the bh->head list is not empty. But also need to ensure the left URB giveback to be processed in time, so add a member high_prio for structure giveback_urb_bh to prioritize tasklet and schelule this tasklet again if bh->head list is not empty.

At the same time, we are able to prioritize tasklet through structure member high_prio. So, replace the local high_prio_bh variable with this structure member in usb_hcd_giveback_urb.

Fixes 94dfd7edfd5c ("USB: HCD: support giveback of URB in tasklet context")

Cc stable <[email protected]>

Reviewed-by Alan Stern <[email protected]>

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

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

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

---
 drivers/usb/core/hcd.c  |   26 +++++++++++++++-----------
 include/linux/usb/hcd.h |    1 +
 2 files changed, 16 insertions(+), 11 deletions(-)

drivers/usb/core/hcd.c +15 ~~-11~~

@@ -1691,7 +1691,6 @@ static void usb_giveback_urb_bh(struct t
 
 	spin_lock_irq(&bh->lock);
 	bh->running = true;
- restart:
 	list_replace_init(&bh->head, &local_list);
 	spin_unlock_irq(&bh->lock);

@@ -1705,10 +1704,17 @@ static void usb_giveback_urb_bh(struct t
 		bh->completing_ep = NULL;
 	}
 
-	/* check if there are new URBs to giveback */
+	/*
+	 * giveback new URBs next time to prevent this function
+	 * from not exiting for a long time.
+	 */
 	spin_lock_irq(&bh->lock);
-	if (!list_empty(&bh->head))
-		goto restart;
+	if (!list_empty(&bh->head)) {
+		if (bh->high_prio)
+			tasklet_hi_schedule(&bh->bh);
+		else
+			tasklet_schedule(&bh->bh);
+	}
 	bh->running = false;
 	spin_unlock_irq(&bh->lock);
 }

@@ -1737,7 +1743,7 @@ static void usb_giveback_urb_bh(struct t
 void usb_hcd_giveback_urb(struct usb_hcd *hcd, struct urb *urb, int status)
 {
 	struct giveback_urb_bh *bh;
-	bool running, high_prio_bh;
+	bool running;
 
 	/* pass status to tasklet via unlinked */
 	if (likely(!urb->unlinked))

@@ -1748,13 +1754,10 @@ void usb_hcd_giveback_urb(struct usb_hcd
 		return;
 	}
 
-	if (usb_pipeisoc(urb->pipe) || usb_pipeint(urb->pipe)) {
+	if (usb_pipeisoc(urb->pipe) || usb_pipeint(urb->pipe))
 		bh = &hcd->high_prio_bh;
-		high_prio_bh = true;
-	} else {
+	else
 		bh = &hcd->low_prio_bh;
-		high_prio_bh = false;
-	}
 
 	spin_lock(&bh->lock);
 	list_add_tail(&urb->urb_list, &bh->head);

@@ -1763,7 +1766,7 @@ void usb_hcd_giveback_urb(struct usb_hcd
 
 	if (running)
 		;
-	else if (high_prio_bh)
+	else if (bh->high_prio)
 		tasklet_hi_schedule(&bh->bh);
 	else
 		tasklet_schedule(&bh->bh);

@@ -2959,6 +2962,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
 
 	/* initialize tasklets */
 	init_giveback_urb_bh(&hcd->high_prio_bh);
+	hcd->high_prio_bh.high_prio = true;
 	init_giveback_urb_bh(&hcd->low_prio_bh);
 
 	/* enable irqs just before we start the controller,

include/linux/usb/hcd.h +1 -0

@@ -66,6 +66,7 @@
 
 struct giveback_urb_bh {
 	bool running;
+	bool high_prio;
 	spinlock_t lock;
 	struct list_head  head;
 	struct tasklet_struct bh;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:24 UTC #103 lore raw

PATCH 101/779 ARM: dts: uniphier: Fix USB interrupts for PXs2 SoC

From: Kunihiko Hayashi <[email protected]>

commit 9b0dc7abb5cc43a2dbf90690c3c6011dcadc574d upstream.

An interrupt for USB device are shared with USB host. Set interrupt-names property to common "dwc_usb3" instead of "host" and "peripheral".

Fixes 45be1573ad19 ("ARM: dts: uniphier: Add USB3 controller nodes")

Reported-by Ryuta NAKANISHI <[email protected]>

Signed-off-by Kunihiko Hayashi <[email protected]>

Signed-off-by Arnd Bergmann <[email protected]>

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

---
 arch/arm/boot/dts/uniphier-pxs2.dtsi |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm/boot/dts/uniphier-pxs2.dtsi +4 -4

@@ -597,8 +597,8 @@
 			compatible = "socionext,uniphier-dwc3", "snps,dwc3";
 			status = "disabled";
 			reg = <0x65a00000 0xcd00>;
-			interrupt-names = "host", "peripheral";
-			interrupts = <0 134 4>, <0 135 4>;
+			interrupt-names = "dwc_usb3";
+			interrupts = <0 134 4>;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_usb0>, <&pinctrl_usb2>;
 			clock-names = "ref", "bus_early", "suspend";

@@ -693,8 +693,8 @@
 			compatible = "socionext,uniphier-dwc3", "snps,dwc3";
 			status = "disabled";
 			reg = <0x65c00000 0xcd00>;
-			interrupt-names = "host", "peripheral";
-			interrupts = <0 137 4>, <0 138 4>;
+			interrupt-names = "dwc_usb3";
+			interrupts = <0 137 4>;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_usb1>, <&pinctrl_usb3>;
 			clock-names = "ref", "bus_early", "suspend";

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #104 lore raw

PATCH 102/779 arm64: dts: uniphier: Fix USB interrupts for PXs3 SoC

From: Kunihiko Hayashi <[email protected]>

commit fe17b91a7777df140d0f1433991da67ba658796c upstream.

An interrupt for USB device are shared with USB host. Set interrupt-names property to common "dwc_usb3" instead of "host" and "peripheral".

Fixes d7b9beb830d7 ("arm64: dts: uniphier: Add USB3 controller nodes")

Reported-by Ryuta NAKANISHI <[email protected]>

Signed-off-by Kunihiko Hayashi <[email protected]>

Signed-off-by Arnd Bergmann <[email protected]>

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

---
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi +4 -4

@@ -599,8 +599,8 @@
 			compatible = "socionext,uniphier-dwc3", "snps,dwc3";
 			status = "disabled";
 			reg = <0x65a00000 0xcd00>;
-			interrupt-names = "host", "peripheral";
-			interrupts = <0 134 4>, <0 135 4>;
+			interrupt-names = "dwc_usb3";
+			interrupts = <0 134 4>;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_usb0>, <&pinctrl_usb2>;
 			clock-names = "ref", "bus_early", "suspend";

@@ -701,8 +701,8 @@
 			compatible = "socionext,uniphier-dwc3", "snps,dwc3";
 			status = "disabled";
 			reg = <0x65c00000 0xcd00>;
-			interrupt-names = "host", "peripheral";
-			interrupts = <0 137 4>, <0 138 4>;
+			interrupt-names = "dwc_usb3";
+			interrupts = <0 137 4>;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_usb1>, <&pinctrl_usb3>;
 			clock-names = "ref", "bus_early", "suspend";

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #105 lore raw

PATCH 103/779 USB: gadget: Fix use-after-free Read in usb_udc_uevent()

From: Alan Stern <[email protected]>

commit 2191c00855b03aa59c20e698be713d952d51fc18 upstream.

The syzbot fuzzer found a race between uevent callbacks and gadget driver unregistration that can cause a use-after-free bug:

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

BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130
drivers/usb/gadget/udc/core.c:1732
Read of size 8 at addr ffff888078ce2050 by task udevd/2968

CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
06/29/2022
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:317 [inline]
 print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495
 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732
 dev_uevent+0x290/0x770 drivers/base/core.c:2424
---------------------------------------------------------------

The bug occurs because usb_udc_uevent() dereferences udc->driver but does so without acquiring the udc_lock mutex, which protects this field. If the gadget driver is unbound from the udc concurrently with uevent processing, the driver structure may be accessed after it has been deallocated.

To prevent the race, we make sure that the routine holds the mutex around the racing accesses.

Link <https://lore.kernel.org/all/[email protected]> open here

CC [email protected] # fc274c1e9973

Reported-and-tested-by [email protected]

Signed-off-by Alan Stern <[email protected]>

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

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

---
 drivers/usb/gadget/udc/core.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

drivers/usb/gadget/udc/core.c +6 -5

@@ -1739,13 +1739,14 @@ static int usb_udc_uevent(struct device
 		return ret;
 	}
 
-	if (udc->driver) {
+	mutex_lock(&udc_lock);
+	if (udc->driver)
 		ret = add_uevent_var(env, "USB_UDC_DRIVER=%s",
 				udc->driver->function);
-		if (ret) {
-			dev_err(dev, "failed to add uevent USB_UDC_DRIVER\n");
-			return ret;
-		}
+	mutex_unlock(&udc_lock);
+	if (ret) {
+		dev_err(dev, "failed to add uevent USB_UDC_DRIVER\n");
+		return ret;
 	}
 
 	return 0;

[email protected]

2022-08-16 06:48 UTC #106 lore raw

RE: [PATCH 5.15 103/779] USB: gadget: Fix use-after-free Read in usb_udc_uevent()

Hi,

This patch is related to "fc274c1e9973 "USB: gadget: Add a new bus for gadgets". 5.15.y, 5.10.y, 5.5.y and 4.19.y tree doesn't include it, so it's unnecessary. Please drop each tree.

Best regards,
Nobuhiro

Quoted 80 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Tuesday, August 16, 2022 2:56 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Alan Stern <[email protected]>; [email protected]
Subject: [PATCH 5.15 103/779] USB: gadget: Fix use-after-free Read in usb_udc_uevent()
From: Alan Stern <[email protected]>
commit 2191c00855b03aa59c20e698be713d952d51fc18 upstream.
The syzbot fuzzer found a race between uevent callbacks and gadget driver unregistration that can cause a use-after-free bug:
---------------------------------------------------------------
BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130
drivers/usb/gadget/udc/core.c:1732
Read of size 8 at addr ffff888078ce2050 by task udevd/2968

CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller
#0 Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google
06/29/2022
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
 print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495
 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732
 dev_uevent+0x290/0x770 drivers/base/core.c:2424
---------------------------------------------------------------
The bug occurs because usb_udc_uevent() dereferences udc->driver but does so without acquiring the udc_lock mutex, which protects this field. If the gadget driver is unbound from the udc concurrently with uevent processing, the driver structure may be accessed after it has been deallocated.
To prevent the race, we make sure that the routine holds the mutex around the racing accesses.
Link:
<https://lore.kernel.org/all/[email protected]>
CC: [email protected] # fc274c1e9973 Reported-and-tested-by:
[email protected]
Signed-off-by Alan Stern <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/usb/gadget/udc/core.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/usb/gadget/udc/core.c +6 -5
@@ -1739,13 +1739,14 @@ static int usb_udc_uevent(struct device
 		return ret;
 	}
 
-	if (udc->driver) {
+	mutex_lock(&udc_lock);
+	if (udc->driver)
 		ret = add_uevent_var(env, "USB_UDC_DRIVER=%s",
 				udc->driver->function);
-		if (ret) {
-			dev_err(dev, "failed to add uevent
 USB_UDC_DRIVER\n");
-			return ret;
-		}
+	mutex_unlock(&udc_lock);
+	if (ret) {
+		dev_err(dev, "failed to add uevent USB_UDC_DRIVER\n");
+		return ret;
 	}
 
return 0;

Greg KH

author maintainer

2022-08-16 10:06 UTC #107 lore raw

Re: [PATCH 5.15 103/779] USB: gadget: Fix use-after-free Read in usb_udc_uevent()

Quoted 4 lines · On Tue, Aug 16, 2022 at 01:43:11AM +0000, [email protected]…

Hi,
This patch is related to "fc274c1e9973 "USB: gadget: Add a new bus for gadgets". 5.15.y, 5.10.y, 5.5.y and 4.19.y tree doesn't include it, so it's unnecessary. Please drop each tree.

Ick, good catch, my scripts got confused here. Now dropped from everywhere.

thanks,

greg k-h

Alan Stern

2022-08-16 13:48 UTC #108 lore raw

Re: [PATCH 5.15 103/779] USB: gadget: Fix use-after-free Read in usb_udc_uevent()

Quoted 8 lines · Greg KH

Quoted 4 lines · On Tue, Aug 16, 2022 at 01:43:11AM +0000, [email protected]…
Hi,
This patch is related to "fc274c1e9973 "USB: gadget: Add a new bus for gadgets". 5.15.y, 5.10.y, 5.5.y and 4.19.y tree doesn't include it, so it's unnecessary. Please drop each tree.
Ick, good catch, my scripts got confused here. Now dropped from everywhere.

Sorry, my fault. I forgot to add a "Fixes:" tag to the patch.

Alan Stern

Greg Kroah-Hartman

author maintainer

2022-08-15 18:25 UTC #109 lore raw

PATCH 104/779 usb: dwc3: gadget: refactor dwc3_repare_one_trb

From: Michael Grzeschik <[email protected]>

commit 23385cec5f354794dadced7f28c31da7ae3eb54c upstream.

The function __dwc3_prepare_one_trb has many parameters. Since it is only used in dwc3_prepare_one_trb there is no point in keeping the function. We merge both functions and get rid of the big list of parameters.

Fixes 40d829fb2ec6 ("usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets")

Cc stable <[email protected]>

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

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

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

---
 drivers/usb/dwc3/gadget.c |   92 ++++++++++++++++++++--------------------------
 1 file changed, 40 insertions(+), 52 deletions(-)

drivers/usb/dwc3/gadget.c +40 ~~-52~~

@@ -1169,17 +1169,49 @@ static u32 dwc3_calc_trbs_left(struct dw
 	return trbs_left;
 }
 
-static void __dwc3_prepare_one_trb(struct dwc3_ep *dep, struct dwc3_trb *trb,
-		dma_addr_t dma, unsigned int length, unsigned int chain,
-		unsigned int node, unsigned int stream_id,
-		unsigned int short_not_ok, unsigned int no_interrupt,
-		unsigned int is_last, bool must_interrupt)
+/**
+ * dwc3_prepare_one_trb - setup one TRB from one request
+ * @dep: endpoint for which this request is prepared
+ * @req: dwc3_request pointer
+ * @trb_length: buffer size of the TRB
+ * @chain: should this TRB be chained to the next?
+ * @node: only for isochronous endpoints. First TRB needs different type.
+ * @use_bounce_buffer: set to use bounce buffer
+ * @must_interrupt: set to interrupt on TRB completion
+ */
+static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
+		struct dwc3_request *req, unsigned int trb_length,
+		unsigned int chain, unsigned int node, bool use_bounce_buffer,
+		bool must_interrupt)
 {
+	struct dwc3_trb		*trb;
+	dma_addr_t		dma;
+	unsigned int		stream_id = req->request.stream_id;
+	unsigned int		short_not_ok = req->request.short_not_ok;
+	unsigned int		no_interrupt = req->request.no_interrupt;
+	unsigned int		is_last = req->request.is_last;
 	struct dwc3		*dwc = dep->dwc;
 	struct usb_gadget	*gadget = dwc->gadget;
 	enum usb_device_speed	speed = gadget->speed;
 
-	trb->size = DWC3_TRB_SIZE_LENGTH(length);
+	if (use_bounce_buffer)
+		dma = dep->dwc->bounce_addr;
+	else if (req->request.num_sgs > 0)
+		dma = sg_dma_address(req->start_sg);
+	else
+		dma = req->request.dma;
+
+	trb = &dep->trb_pool[dep->trb_enqueue];
+
+	if (!req->trb) {
+		dwc3_gadget_move_started_request(req);
+		req->trb = trb;
+		req->trb_dma = dwc3_trb_dma_offset(dep, trb);
+	}
+
+	req->num_trbs++;
+
+	trb->size = DWC3_TRB_SIZE_LENGTH(trb_length);
 	trb->bpl = lower_32_bits(dma);
 	trb->bph = upper_32_bits(dma);

@@ -1219,10 +1251,10 @@ static void __dwc3_prepare_one_trb(struc
 				unsigned int mult = 2;
 				unsigned int maxp = usb_endpoint_maxp(ep->desc);
 
-				if (length <= (2 * maxp))
+				if (trb_length <= (2 * maxp))
 					mult--;
 
-				if (length <= maxp)
+				if (trb_length <= maxp)
 					mult--;
 
 				trb->size |= DWC3_TRB_SIZE_PCM1(mult);

@@ -1291,50 +1323,6 @@ static void __dwc3_prepare_one_trb(struc
 	trace_dwc3_prepare_trb(dep, trb);
 }
 
-/**
- * dwc3_prepare_one_trb - setup one TRB from one request
- * @dep: endpoint for which this request is prepared
- * @req: dwc3_request pointer
- * @trb_length: buffer size of the TRB
- * @chain: should this TRB be chained to the next?
- * @node: only for isochronous endpoints. First TRB needs different type.
- * @use_bounce_buffer: set to use bounce buffer
- * @must_interrupt: set to interrupt on TRB completion
- */
-static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
-		struct dwc3_request *req, unsigned int trb_length,
-		unsigned int chain, unsigned int node, bool use_bounce_buffer,
-		bool must_interrupt)
-{
-	struct dwc3_trb		*trb;
-	dma_addr_t		dma;
-	unsigned int		stream_id = req->request.stream_id;
-	unsigned int		short_not_ok = req->request.short_not_ok;
-	unsigned int		no_interrupt = req->request.no_interrupt;
-	unsigned int		is_last = req->request.is_last;
-
-	if (use_bounce_buffer)
-		dma = dep->dwc->bounce_addr;
-	else if (req->request.num_sgs > 0)
-		dma = sg_dma_address(req->start_sg);
-	else
-		dma = req->request.dma;
-
-	trb = &dep->trb_pool[dep->trb_enqueue];
-
-	if (!req->trb) {
-		dwc3_gadget_move_started_request(req);
-		req->trb = trb;
-		req->trb_dma = dwc3_trb_dma_offset(dep, trb);
-	}
-
-	req->num_trbs++;
-
-	__dwc3_prepare_one_trb(dep, trb, dma, trb_length, chain, node,
-			stream_id, short_not_ok, no_interrupt, is_last,
-			must_interrupt);
-}
-
 static bool dwc3_needs_extra_trb(struct dwc3_ep *dep, struct dwc3_request *req)
 {
 	unsigned int maxp = usb_endpoint_maxp(dep->endpoint.desc);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:25 UTC #110 lore raw

PATCH 105/779 usb: dwc3: gadget: fix high speed multiplier setting

From: Michael Grzeschik <[email protected]>

commit 8affe37c525d800a2628c4ecfaed13b77dc5634a upstream.

For High-Speed Transfers the prepare_one_trb function is calculating the multiplier setting for the trb based on the length parameter of the trb currently prepared. This assumption is wrong. For trbs with a sg list, the length of the actual request has to be taken instead.

Fixes 40d829fb2ec6 ("usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets")

Cc stable <[email protected]>

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

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

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

---
 drivers/usb/dwc3/gadget.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/usb/dwc3/gadget.c +2 -2

@@ -1251,10 +1251,10 @@ static void dwc3_prepare_one_trb(struct
 				unsigned int mult = 2;
 				unsigned int maxp = usb_endpoint_maxp(ep->desc);
 
-				if (trb_length <= (2 * maxp))
+				if (req->request.length <= (2 * maxp))
 					mult--;
 
-				if (trb_length <= maxp)
+				if (req->request.length <= maxp)
 					mult--;
 
 				trb->size |= DWC3_TRB_SIZE_PCM1(mult);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #111 lore raw

PATCH 106/779 netfilter: nf_tables: do not allow SET_ID to refer to another table

From: Thadeu Lima de Souza Cascardo <[email protected]>

commit 470ee20e069a6d05ae549f7d0ef2bdbcee6a81b2 upstream.

When doing lookups for sets on the same batch by using its ID, a set from a different table can be used.

Then, when the table is removed, a reference to the set may be kept after the set is freed, leading to a potential use-after-free.

When looking for sets by ID, use the table that was used for the lookup by name, and only return sets belonging to that same table.

This fixes CVE-2022-2586, also reported as ZDI-CAN-17470.

Reported-by Team Orca of Sea Security (@seasecresponse)

Fixes 958bee14d071 ("netfilter: nf_tables: use new transaction infrastructure to handle sets")

Signed-off-by Thadeu Lima de Souza Cascardo <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

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

---
 net/netfilter/nf_tables_api.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

net/netfilter/nf_tables_api.c +3 -1

@@ -3745,6 +3745,7 @@ static struct nft_set *nft_set_lookup_by
 }
 
 static struct nft_set *nft_set_lookup_byid(const struct net *net,
+					   const struct nft_table *table,
 					   const struct nlattr *nla, u8 genmask)
 {
 	struct nftables_pernet *nft_net = nft_pernet(net);

@@ -3756,6 +3757,7 @@ static struct nft_set *nft_set_lookup_by
 			struct nft_set *set = nft_trans_set(trans);
 
 			if (id == nft_trans_set_id(trans) &&
+			    set->table == table &&
 			    nft_active_genmask(set, genmask))
 				return set;
 		}

@@ -3776,7 +3778,7 @@ struct nft_set *nft_set_lookup_global(co
 		if (!nla_set_id)
 			return set;
 
-		set = nft_set_lookup_byid(net, nla_set_id, genmask);
+		set = nft_set_lookup_byid(net, table, nla_set_id, genmask);
 	}
 	return set;
 }

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #112 lore raw

PATCH 107/779 netfilter: nf_tables: do not allow CHAIN_ID to refer to another table

From: Thadeu Lima de Souza Cascardo <[email protected]>

commit 95f466d22364a33d183509629d0879885b4f547e upstream.

When doing lookups for chains on the same batch by using its ID, a chain from a different table can be used. If a rule is added to a table but refers to a chain in a different table, it will be linked to the chain in table2, but would have expressions referring to objects in table1.

Then, when table1 is removed, the rule will not be removed as its linked to a chain in table2. When expressions in the rule are processed or removed, that will lead to a use-after-free.

When looking for chains by ID, use the table that was used for the lookup by name, and only return chains belonging to that same table.

Fixes 837830a4b439 ("netfilter: nf_tables: add NFTA_RULE_CHAIN_ID attribute")

Signed-off-by Thadeu Lima de Souza Cascardo <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

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

---
 net/netfilter/nf_tables_api.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

net/netfilter/nf_tables_api.c +4 -2

@@ -2377,6 +2377,7 @@ err:
 }
 
 static struct nft_chain *nft_chain_lookup_byid(const struct net *net,
+					       const struct nft_table *table,
 					       const struct nlattr *nla)
 {
 	struct nftables_pernet *nft_net = nft_pernet(net);

@@ -2387,6 +2388,7 @@ static struct nft_chain *nft_chain_looku
 		struct nft_chain *chain = trans->ctx.chain;
 
 		if (trans->msg_type == NFT_MSG_NEWCHAIN &&
+		    chain->table == table &&
 		    id == nft_trans_chain_id(trans))
 			return chain;
 	}

@@ -3320,7 +3322,7 @@ static int nf_tables_newrule(struct sk_b
 			return -EOPNOTSUPP;
 
 	} else if (nla[NFTA_RULE_CHAIN_ID]) {
-		chain = nft_chain_lookup_byid(net, nla[NFTA_RULE_CHAIN_ID]);
+		chain = nft_chain_lookup_byid(net, table, nla[NFTA_RULE_CHAIN_ID]);
 		if (IS_ERR(chain)) {
 			NL_SET_BAD_ATTR(extack, nla[NFTA_RULE_CHAIN_ID]);
 			return PTR_ERR(chain);

@@ -9451,7 +9453,7 @@ static int nft_verdict_init(const struct
 						 tb[NFTA_VERDICT_CHAIN],
 						 genmask);
 		} else if (tb[NFTA_VERDICT_CHAIN_ID]) {
-			chain = nft_chain_lookup_byid(ctx->net,
+			chain = nft_chain_lookup_byid(ctx->net, ctx->table,
 						      tb[NFTA_VERDICT_CHAIN_ID]);
 			if (IS_ERR(chain))
 				return PTR_ERR(chain);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #113 lore raw

PATCH 108/779 netfilter: nf_tables: do not allow RULE_ID to refer to another chain

From: Thadeu Lima de Souza Cascardo <[email protected]>

commit 36d5b2913219ac853908b0f1c664345e04313856 upstream.

When doing lookups for rules on the same batch by using its ID, a rule from a different chain can be used. If a rule is added to a chain but tries to be positioned next to a rule from a different chain, it will be linked to chain2, but the use counter on chain1 would be the one to be incremented.

When looking for rules by ID, use the chain that was used for the lookup by name. The chain used in the context copied to the transaction needs to match that same chain. That way, struct nft_rule does not need to get enlarged with another member.

Fixes 1a94e38d254b ("netfilter: nf_tables: add NFTA_RULE_ID attribute")

Fixes 75dd48e2e420 ("netfilter: nf_tables: Support RULE_ID reference in new rule")

Signed-off-by Thadeu Lima de Souza Cascardo <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

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

---
 net/netfilter/nf_tables_api.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

net/netfilter/nf_tables_api.c +5 -2

@@ -3276,6 +3276,7 @@ static int nft_table_validate(struct net
 }
 
 static struct nft_rule *nft_rule_lookup_byid(const struct net *net,
+					     const struct nft_chain *chain,
 					     const struct nlattr *nla);
 
 #define NFT_RULE_MAXEXPRS	128

@@ -3364,7 +3365,7 @@ static int nf_tables_newrule(struct sk_b
 				return PTR_ERR(old_rule);
 			}
 		} else if (nla[NFTA_RULE_POSITION_ID]) {
-			old_rule = nft_rule_lookup_byid(net, nla[NFTA_RULE_POSITION_ID]);
+			old_rule = nft_rule_lookup_byid(net, chain, nla[NFTA_RULE_POSITION_ID]);
 			if (IS_ERR(old_rule)) {
 				NL_SET_BAD_ATTR(extack, nla[NFTA_RULE_POSITION_ID]);
 				return PTR_ERR(old_rule);

@@ -3509,6 +3510,7 @@ err_release_expr:
 }
 
 static struct nft_rule *nft_rule_lookup_byid(const struct net *net,
+					     const struct nft_chain *chain,
 					     const struct nlattr *nla)
 {
 	struct nftables_pernet *nft_net = nft_pernet(net);

@@ -3519,6 +3521,7 @@ static struct nft_rule *nft_rule_lookup_
 		struct nft_rule *rule = nft_trans_rule(trans);
 
 		if (trans->msg_type == NFT_MSG_NEWRULE &&
+		    trans->ctx.chain == chain &&
 		    id == nft_trans_rule_id(trans))
 			return rule;
 	}

@@ -3568,7 +3571,7 @@ static int nf_tables_delrule(struct sk_b
 
 			err = nft_delrule(&ctx, rule);
 		} else if (nla[NFTA_RULE_ID]) {
-			rule = nft_rule_lookup_byid(net, nla[NFTA_RULE_ID]);
+			rule = nft_rule_lookup_byid(net, chain, nla[NFTA_RULE_ID]);
 			if (IS_ERR(rule)) {
 				NL_SET_BAD_ATTR(extack, nla[NFTA_RULE_ID]);
 				return PTR_ERR(rule);

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #114 lore raw

PATCH 109/779 netfilter: nf_tables: fix null deref due to zeroed list head

From: Florian Westphal <[email protected]>

commit 580077855a40741cf511766129702d97ff02f4d9 upstream.

In nf_tables_updtable, if nf_tables_table_enable returns an error, nft_trans_destroy is called to free the transaction object.

nft_trans_destroy() calls list_del(), but the transaction was never placed on a list -- the list head is all zeroes, this results in a null dereference:

BUG: KASAN: null-ptr-deref in nft_trans_destroy+0x26/0x59
Call Trace:
 nft_trans_destroy+0x26/0x59
 nf_tables_newtable+0x4bc/0x9bc
 [..]

Its sane to assume that nft_trans_destroy() can be called on the transaction object returned by nft_trans_alloc(), so make sure the list head is initialised.

Fixes 55dd6f93076b ("netfilter: nf_tables: use new transaction infrastructure to handle table")

Reported-by mingi cho <[email protected]>

Signed-off-by Florian Westphal <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

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

---
 net/netfilter/nf_tables_api.c |    1 +
 1 file changed, 1 insertion(+)

net/netfilter/nf_tables_api.c +1 -0

@@ -153,6 +153,7 @@ static struct nft_trans *nft_trans_alloc
 	if (trans == NULL)
 		return NULL;
 
+	INIT_LIST_HEAD(&trans->list);
 	trans->msg_type = msg_type;
 	trans->ctx	= *ctx;

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #115 lore raw

PATCH 110/779 epoll: autoremove wakers even more aggressively

From: Benjamin Segall <[email protected]>

commit a16ceb13961068f7209e34d7984f8e42d2c06159 upstream.

If a process is killed or otherwise exits while having active network connections and many threads waiting on epoll_wait, the threads will all be woken immediately, but not removed from ep->wq. Then when network traffic scans ep->wq in wake_up, every wakeup attempt will fail, and will not remove the entries from the list.

This means that the cost of the wakeup attempt is far higher than usual, does not decrease, and this also competes with the dying threads trying to actually make progress and remove themselves from the wq.

Handle this by removing visited epoll wq entries unconditionally, rather than only when the wakeup succeeds - the structure of ep_poll means that the only potential loss is the timed_out->eavail heuristic, which now can race and result in a redundant ep_send_events attempt. (But only when incoming data and a timeout actually race, not on every timeout)

Shakeel added:

: We are seeing this issue in production with real workloads and it has : caused hard lockups. Particularly network heavy workloads with a lot : of threads in epoll_wait() can easily trigger this issue if they get : killed (oom-killed in our case).

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

Signed-off-by Ben Segall <[email protected]>

Tested-by Shakeel Butt <[email protected]>

Cc Alexander Viro <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Shakeel Butt <[email protected]>

Cc Eric Dumazet <[email protected]>

Cc Roman Penyaev <[email protected]>

Cc Jason Baron <[email protected]>

Cc Khazhismel Kumykov <[email protected]>

Cc Heiher <[email protected]>

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

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

---
 fs/eventpoll.c |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

fs/eventpoll.c +22 -0

@@ -1740,6 +1740,21 @@ static struct timespec64 *ep_timeout_to_
 	return to;
 }
 
+/*
+ * autoremove_wake_function, but remove even on failure to wake up, because we
+ * know that default_wake_function/ttwu will only fail if the thread is already
+ * woken, and in that case the ep_poll loop will remove the entry anyways, not
+ * try to reuse it.
+ */
+static int ep_autoremove_wake_function(struct wait_queue_entry *wq_entry,
+				       unsigned int mode, int sync, void *key)
+{
+	int ret = default_wake_function(wq_entry, mode, sync, key);
+
+	list_del_init(&wq_entry->entry);
+	return ret;
+}
+
 /**
  * ep_poll - Retrieves ready events, and delivers them to the caller-supplied
  *           event buffer.

@@ -1821,8 +1836,15 @@ static int ep_poll(struct eventpoll *ep,
 		 * normal wakeup path no need to call __remove_wait_queue()
 		 * explicitly, thus ep->lock is not taken, which halts the
 		 * event delivery.
+		 *
+		 * In fact, we now use an even more aggressive function that
+		 * unconditionally removes, because we don't reuse the wait
+		 * entry between loop iterations. This lets us also avoid the
+		 * performance issue if a process is killed, causing all of its
+		 * threads to wake up without being removed normally.
 		 */
 		init_wait(&wait);
+		wait.func = ep_autoremove_wake_function;
 
 		write_lock_irq(&ep->lock);
 		/*

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #116 lore raw

PATCH 111/779 x86: Handle idle=nomwait cmdline properly for x86_idle

Link https://lkml.kernel.org/r/fdc2dc2d0a1bc21c2f53d989ea2d2ee3ccbc0dbe.1654538381.git-series.wyes.karny@amd.com open here

From: Wyes Karny <[email protected]>

[ Upstream commit 8bcedb4ce04750e1ccc9a6b6433387f6a9166a56 ]

When kernel is booted with idle=nomwait do not use MWAIT as the default idle state.

If the user boots the kernel with idle=nomwait, it is a clear direction to not use mwait as the default idle state. However, the current code does not take this into consideration while selecting the default idle state on x86.

Fix it by checking for the idle=nomwait boot option in prefer_mwait_c1_over_halt().

Also update the documentation around idle=nomwait appropriately.

[ dhansen: tweak commit message ]

Signed-off-by Wyes Karny <[email protected]>

Signed-off-by Dave Hansen <[email protected]>

Tested-by Zhang Rui <[email protected]>

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

---
 Documentation/admin-guide/pm/cpuidle.rst | 15 +++++++++------
 arch/x86/kernel/process.c                |  9 ++++++---
 2 files changed, 15 insertions(+), 9 deletions(-)

Documentation/admin-guide/pm/cpuidle.rst +9 -6

index aec2cd2aaea7..19754beb5a4e 100644
@@ -612,8 +612,8 @@ the ``menu`` governor to be used on the systems that use the ``ladder`` governor
 by default this way, for example.
 
 The other kernel command line parameters controlling CPU idle time management
-described below are only relevant for the *x86* architecture and some of
-them affect Intel processors only.
+described below are only relevant for the *x86* architecture and references
+to ``intel_idle`` affect Intel processors only.
 
 The *x86* architecture support code recognizes three kernel command line
 options related to CPU idle time management: ``idle=poll``, ``idle=halt``,

@@ -635,10 +635,13 @@ idle, so it very well may hurt single-thread computations performance as well as
 energy-efficiency.  Thus using it for performance reasons may not be a good idea
 at all.]
 
-The ``idle=nomwait`` option disables the ``intel_idle`` driver and causes
-``acpi_idle`` to be used (as long as all of the information needed by it is
-there in the system's ACPI tables), but it is not allowed to use the
-``MWAIT`` instruction of the CPUs to ask the hardware to enter idle states.
+The ``idle=nomwait`` option prevents the use of ``MWAIT`` instruction of
+the CPU to enter idle states. When this option is used, the ``acpi_idle``
+driver will use the ``HLT`` instruction instead of ``MWAIT``. On systems
+running Intel processors, this option disables the ``intel_idle`` driver
+and forces the use of the ``acpi_idle`` driver instead. Note that in either
+case, ``acpi_idle`` driver will function only if all the information needed
+by it is in the system's ACPI tables.
 
 In addition to the architecture-level kernel command line options affecting CPU
 idle time management, there are parameters affecting individual ``CPUIdle``

arch/x86/kernel/process.c +6 -3

index 8d9d72fc27a2..707376453525 100644
@@ -805,6 +805,10 @@ static void amd_e400_idle(void)
  */
 static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
 {
+	/* User has disallowed the use of MWAIT. Fallback to HALT */
+	if (boot_option_idle_override == IDLE_NOMWAIT)
+		return 0;
+
 	if (c->x86_vendor != X86_VENDOR_INTEL)
 		return 0;

@@ -913,9 +917,8 @@ static int __init idle_setup(char *str)
 	} else if (!strcmp(str, "nomwait")) {
 		/*
 		 * If the boot option of "idle=nomwait" is added,
-		 * it means that mwait will be disabled for CPU C2/C3
-		 * states. In such case it won't touch the variable
-		 * of boot_option_idle_override.
+		 * it means that mwait will be disabled for CPU C1/C2/C3
+		 * states.
 		 */
 		boot_option_idle_override = IDLE_NOMWAIT;
 	} else

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #117 lore raw

PATCH 112/779 arch: make TRACE_IRQFLAGS_NMI_SUPPORT generic

From: Mark Rutland <[email protected]>

[ Upstream commit 4510bffb4d0246cdcc1f14c7367c026b807a862d ]

On most architectures, IRQ flag tracing is disabled in NMI context, and architectures need to define and select TRACE_IRQFLAGS_NMI_SUPPORT in order to enable this.

Commit:

859d069ee1ddd878 ("lockdep: Prepare for NMI IRQ state tracking")

Permitted IRQ flag tracing in NMI context, allowing lockdep to work in NMI context where an architecture had suitable entry logic. At the time, most architectures did not have such suitable entry logic, and this broke lockdep on such architectures. Thus, this was partially disabled in commit:

ed00495333ccc80f ("locking/lockdep: Fix TRACE_IRQFLAGS vs. NMIs")

... with architectures needing to select TRACE_IRQFLAGS_NMI_SUPPORT to enable IRQ flag tracing in NMI context.

Currently TRACE_IRQFLAGS_NMI_SUPPORT is defined under arch/x86/Kconfig.debug. Move it to arch/Kconfig so architectures can select it without having to provide their own definition.

Since the regular TRACE_IRQFLAGS_SUPPORT is selected by arch/x86/Kconfig, the select of TRACE_IRQFLAGS_NMI_SUPPORT is moved there too.

There should be no functional change as a result of this patch.

Signed-off-by Mark Rutland <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Peter Zijlstra (Intel) <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Will Deacon <[email protected]>

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

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

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

---
 arch/Kconfig           | 3 +++
 arch/x86/Kconfig       | 1 +
 arch/x86/Kconfig.debug | 3 ---
 3 files changed, 4 insertions(+), 3 deletions(-)

arch/Kconfig +3 -0

index 191589f26b1a..5987363b41c2 100644
@@ -200,6 +200,9 @@ config HAVE_NMI
 config TRACE_IRQFLAGS_SUPPORT
 	bool
 
+config TRACE_IRQFLAGS_NMI_SUPPORT
+	bool
+
 #
 # An arch should select this if it provides all these things:
 #

arch/x86/Kconfig +1 -0

index fe6981a38795..57f5e881791a 100644
@@ -260,6 +260,7 @@ config X86
 	select SYSCTL_EXCEPTION_TRACE
 	select THREAD_INFO_IN_TASK
 	select TRACE_IRQFLAGS_SUPPORT
+	select TRACE_IRQFLAGS_NMI_SUPPORT
 	select USER_STACKTRACE_SUPPORT
 	select VIRT_TO_BUS
 	select HAVE_ARCH_KCSAN			if X86_64

arch/x86/Kconfig.debug +0 -3

index d3a6f74a94bd..d4d6db4dde22 100644
@@ -1,8 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-config TRACE_IRQFLAGS_NMI_SUPPORT
-	def_bool y
-
 config EARLY_PRINTK_USB
 	bool

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #118 lore raw

PATCH 113/779 arm64: Do not forget syscall when starting a new thread.

From: Francis Laniel <[email protected]>

[ Upstream commit de6921856f99c11d3986c6702d851e1328d4f7f6 ]

Enable tracing of the execve*() system calls with the syscalls:sys_exit_execve tracepoint by removing the call to forget_syscall() when starting a new thread and preserving the value of regs->syscallno across exec.

Signed-off-by Francis Laniel <[email protected]>

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

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

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

---
 arch/arm64/include/asm/processor.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/arm64/include/asm/processor.h +2 -1

index 5e73d7f7d1e7..d9bf3d12a2b8 100644
@@ -204,8 +204,9 @@ void tls_preserve_current_state(void);
 
 static inline void start_thread_common(struct pt_regs *regs, unsigned long pc)
 {
+	s32 previous_syscall = regs->syscallno;
 	memset(regs, 0, sizeof(*regs));
-	forget_syscall(regs);
+	regs->syscallno = previous_syscall;
 	regs->pc = pc;
 
 	if (system_uses_irq_prio_masking())

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #119 lore raw

PATCH 114/779 arm64: fix oops in concurrently setting insn_emulation sysctls

From: haibinzhang (张海斌) <[email protected]>

[ Upstream commit af483947d472eccb79e42059276c4deed76f99a6 ]

emulation_proc_handler() changes table->data for proc_dointvec_minmax and can generate the following Oops if called concurrently with itself:

 | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
 | Internal error: Oops: 96000006 [#1] SMP
 | Call trace:
 | update_insn_emulation_mode+0xc0/0x148
 | emulation_proc_handler+0x64/0xb8
 | proc_sys_call_handler+0x9c/0xf8
 | proc_sys_write+0x18/0x20
 | __vfs_write+0x20/0x48
 | vfs_write+0xe4/0x1d0
 | ksys_write+0x70/0xf8
 | __arm64_sys_write+0x20/0x28
 | el0_svc_common.constprop.0+0x7c/0x1c0
 | el0_svc_handler+0x2c/0xa0
 | el0_svc+0x8/0x200

To fix this issue, keep the table->data as &insn->current_mode and use container_of() to retrieve the insn pointer. Another mutex is used to protect against the current_mode update but not for retrieving insn_emulation as table->data is no longer changing.

Co-developed-by hewenliang <[email protected]>

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

Signed-off-by Haibin Zhang <[email protected]>

Reviewed-by Catalin Marinas <[email protected]>

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

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

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

---
 arch/arm64/kernel/armv8_deprecated.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

arch/arm64/kernel/armv8_deprecated.c +5 -4

index 0e86e8b9cedd..c5da9d1e954a 100644
@@ -59,6 +59,7 @@ struct insn_emulation {
 static LIST_HEAD(insn_emulation);
 static int nr_insn_emulated __initdata;
 static DEFINE_RAW_SPINLOCK(insn_emulation_lock);
+static DEFINE_MUTEX(insn_emulation_mutex);
 
 static void register_emulation_hooks(struct insn_emulation_ops *ops)
 {

@@ -207,10 +208,10 @@ static int emulation_proc_handler(struct ctl_table *table, int write,
 				  loff_t *ppos)
 {
 	int ret = 0;
-	struct insn_emulation *insn = (struct insn_emulation *) table->data;
+	struct insn_emulation *insn = container_of(table->data, struct insn_emulation, current_mode);
 	enum insn_emulation_mode prev_mode = insn->current_mode;
 
-	table->data = &insn->current_mode;
+	mutex_lock(&insn_emulation_mutex);
 	ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
 
 	if (ret || !write || prev_mode == insn->current_mode)

@@ -223,7 +224,7 @@ static int emulation_proc_handler(struct ctl_table *table, int write,
 		update_insn_emulation_mode(insn, INSN_UNDEF);
 	}
 ret:
-	table->data = insn;
+	mutex_unlock(&insn_emulation_mutex);
 	return ret;
 }

@@ -247,7 +248,7 @@ static void __init register_insn_emulation_sysctl(void)
 		sysctl->maxlen = sizeof(int);
 
 		sysctl->procname = insn->ops->name;
-		sysctl->data = insn;
+		sysctl->data = &insn->current_mode;
 		sysctl->extra1 = &insn->min;
 		sysctl->extra2 = &insn->max;
 		sysctl->proc_handler = emulation_proc_handler;

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #120 lore raw

PATCH 115/779 arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags"

From: Catalin Marinas <[email protected]>

[ Upstream commit 20794545c14692094a882d2221c251c4573e6adf ]

This reverts commit e5b8d9218951e59df986f627ec93569a0d22149b.

Pages mapped in user-space with PROT_MTE have the allocation tags either zeroed or copied/restored to some user values. In order for the kernel to access such pages via page_address(), resetting the tag in page->flags was necessary. This tag resetting was deferred to set_pte_at() -> mte_sync_page_tags() but it can race with another CPU reading the flags (via page_to_virt()):

P0 (mte_sync_page_tags): P1 (memcpy from virt_to_page):

				  Rflags!=0xff

Wflags=0xff
DMB (doesn't help)
Wtags=0
Rtags=0 // fault

Since now the post_alloc_hook() function resets the page->flags tag when unpoisoning is skipped for user pages (including the __GFP_ZEROTAGS case), revert the arm64 commit calling page_kasan_tag_reset().

Signed-off-by Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

Cc Vincenzo Frascino <[email protected]>

Cc Andrey Konovalov <[email protected]>

Cc Peter Collingbourne <[email protected]>

Reviewed-by Vincenzo Frascino <[email protected]>

Acked-by Andrey Konovalov <[email protected]>

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

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

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

---
 arch/arm64/kernel/hibernate.c | 5 -----
 arch/arm64/kernel/mte.c       | 9 ---------
 arch/arm64/mm/copypage.c      | 9 ---------
 arch/arm64/mm/mteswap.c       | 9 ---------
 4 files changed, 32 deletions(-)

arch/arm64/kernel/hibernate.c +0 -5

index 46a0b4d6e251..db93ce2b0113 100644
@@ -326,11 +326,6 @@ static void swsusp_mte_restore_tags(void)
 		unsigned long pfn = xa_state.xa_index;
 		struct page *page = pfn_to_online_page(pfn);
 
-		/*
-		 * It is not required to invoke page_kasan_tag_reset(page)
-		 * at this point since the tags stored in page->flags are
-		 * already restored.
-		 */
 		mte_restore_page_tags(page_address(page), tags);
 
 		mte_free_tag_storage(tags);

arch/arm64/kernel/mte.c +0 -9

index 7c1c82c8115c..10207e3e5ae2 100644
@@ -44,15 +44,6 @@ static void mte_sync_page_tags(struct page *page, pte_t old_pte,
 	if (!pte_is_tagged)
 		return;
 
-	page_kasan_tag_reset(page);
-	/*
-	 * We need smp_wmb() in between setting the flags and clearing the
-	 * tags because if another thread reads page->flags and builds a
-	 * tagged address out of it, there is an actual dependency to the
-	 * memory access, but on the current thread we do not guarantee that
-	 * the new page->flags are visible before the tags were updated.
-	 */
-	smp_wmb();
 	mte_clear_page_tags(page_address(page));
 }

arch/arm64/mm/copypage.c +0 -9

index 0dea80bf6de4..24913271e898 100644
@@ -23,15 +23,6 @@ void copy_highpage(struct page *to, struct page *from)
 
 	if (system_supports_mte() && test_bit(PG_mte_tagged, &from->flags)) {
 		set_bit(PG_mte_tagged, &to->flags);
-		page_kasan_tag_reset(to);
-		/*
-		 * We need smp_wmb() in between setting the flags and clearing the
-		 * tags because if another thread reads page->flags and builds a
-		 * tagged address out of it, there is an actual dependency to the
-		 * memory access, but on the current thread we do not guarantee that
-		 * the new page->flags are visible before the tags were updated.
-		 */
-		smp_wmb();
 		mte_copy_page_tags(kto, kfrom);
 	}
 }

arch/arm64/mm/mteswap.c +0 -9

index 7c4ef56265ee..c52c1847079c 100644
@@ -53,15 +53,6 @@ bool mte_restore_tags(swp_entry_t entry, struct page *page)
 	if (!tags)
 		return false;
 
-	page_kasan_tag_reset(page);
-	/*
-	 * We need smp_wmb() in between setting the flags and clearing the
-	 * tags because if another thread reads page->flags and builds a
-	 * tagged address out of it, there is an actual dependency to the
-	 * memory access, but on the current thread we do not guarantee that
-	 * the new page->flags are visible before the tags were updated.
-	 */
-	smp_wmb();
 	mte_restore_page_tags(page_address(page), tags);
 
 	return true;

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #121 lore raw

PATCH 116/779 ext2: Add more validity checks for inode counts

From: Jan Kara <[email protected]>

[ Upstream commit fa78f336937240d1bc598db817d638086060e7e9 ]

Add checks verifying number of inodes stored in the superblock matches the number computed from number of inodes per group. Also verify we have at least one block worth of inodes per group. This prevents crashes on corrupted filesystems.

Reported-by [email protected]

Signed-off-by Jan Kara <[email protected]>

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

---
 fs/ext2/super.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

fs/ext2/super.c +10 -2

index 3d21279fe2cb..fd855574ef09 100644
@@ -1058,9 +1058,10 @@ static int ext2_fill_super(struct super_block *sb, void *data, int silent)
 			sbi->s_frags_per_group);
 		goto failed_mount;
 	}
-	if (sbi->s_inodes_per_group > sb->s_blocksize * 8) {
+	if (sbi->s_inodes_per_group < sbi->s_inodes_per_block ||
+	    sbi->s_inodes_per_group > sb->s_blocksize * 8) {
 		ext2_msg(sb, KERN_ERR,
-			"error: #inodes per group too big: %lu",
+			"error: invalid #inodes per group: %lu",
 			sbi->s_inodes_per_group);
 		goto failed_mount;
 	}

@@ -1070,6 +1071,13 @@ static int ext2_fill_super(struct super_block *sb, void *data, int silent)
 	sbi->s_groups_count = ((le32_to_cpu(es->s_blocks_count) -
 				le32_to_cpu(es->s_first_data_block) - 1)
 					/ EXT2_BLOCKS_PER_GROUP(sb)) + 1;
+	if ((u64)sbi->s_groups_count * sbi->s_inodes_per_group !=
+	    le32_to_cpu(es->s_inodes_count)) {
+		ext2_msg(sb, KERN_ERR, "error: invalid #inodes: %u vs computed %llu",
+			 le32_to_cpu(es->s_inodes_count),
+			 (u64)sbi->s_groups_count * sbi->s_inodes_per_group);
+		goto failed_mount;
+	}
 	db_count = (sbi->s_groups_count + EXT2_DESC_PER_BLOCK(sb) - 1) /
 		   EXT2_DESC_PER_BLOCK(sb);
 	sbi->s_group_desc = kmalloc_array(db_count,

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #122 lore raw

PATCH 117/779 sched/fair: Introduce SIS_UTIL to search idle CPU based on sum of util_avg

From: Chen Yu <[email protected]>

[ Upstream commit 70fb5ccf2ebb09a0c8ebba775041567812d45f86 ]

[Problem Statement]
select_idle_cpu() might spend too much time searching for an idle CPU, when the system is overloaded.

The following histogram is the time spent in select_idle_cpu(), when running 224 instances of netperf on a system with 112 CPUs per LLC domain:

@usecs:

[0]                  533 |                                                    |
[1]                 5495 |                                                    |
[2, 4)             12008 |                                                    |
[4, 8)            239252 |                                                    |
[8, 16)          4041924 |@@@@@@@@@@@@@@                                      |
[16, 32)        12357398 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@         |
[32, 64)        14820255 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[64, 128)       13047682 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@       |
[128, 256)       8235013 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@                        |
[256, 512)       4507667 |@@@@@@@@@@@@@@@                                     |
[512, 1K)        2600472 |@@@@@@@@@                                           |
[1K, 2K)          927912 |@@@                                                 |
[2K, 4K)          218720 |                                                    |
[4K, 8K)           98161 |                                                    |
[8K, 16K)          37722 |                                                    |
[16K, 32K)          6715 |                                                    |
[32K, 64K)           477 |                                                    |
[64K, 128K)            7 |                                                    |

netperf latency usecs:
=======
case load Lat_99th std%
TCP_RR thread-224 257.39 ( 0.21)

The time spent in select_idle_cpu() is visible to netperf and might have a negative impact.

[Symptom analysis]
The patch [1] from Mel Gorman has been applied to track the efficiency of select_idle_sibling. Copy the indicators here:

SIS Search Efficiency(se_eff%):
A ratio expressed as a percentage of runqueues scanned versus idle CPUs found. A 100% efficiency indicates that the target, prev or recent CPU of a task was idle at wakeup. The lower the efficiency, the more runqueues were scanned before an idle CPU was found.

SIS Domain Search Efficiency(dom_eff%):
Similar, except only for the slower SIS
patch.

SIS Fast Success Rate(fast_rate%):
Percentage of SIS that used target, prev or recent CPUs.

SIS Success rate(success_rate%):
Percentage of scans that found an idle CPU.

The test is based on Aubrey's schedtests tool, including netperf, hackbench, schbench and tbench.

Test on vanilla kernel:
schedstat_parse.py -f netperf_vanilla.log
case load se_eff% dom_eff% fast_rate% success_rate%

TCP_RR	   28 threads	     99.978	      18.535	      99.995	     100.000
TCP_RR	   56 threads	     99.397	       5.671	      99.964	     100.000
TCP_RR	   84 threads	     21.721	       6.818	      73.632	     100.000
TCP_RR	  112 threads	     12.500	       5.533	      59.000	     100.000
TCP_RR	  140 threads	      8.524	       4.535	      49.020	     100.000
TCP_RR	  168 threads	      6.438	       3.945	      40.309	      99.999
TCP_RR	  196 threads	      5.397	       3.718	      32.320	      99.982
TCP_RR	  224 threads	      4.874	       3.661	      25.775	      99.767
UDP_RR	   28 threads	     99.988	      17.704	      99.997	     100.000
UDP_RR	   56 threads	     99.528	       5.977	      99.970	     100.000
UDP_RR	   84 threads	     24.219	       6.992	      76.479	     100.000
UDP_RR	  112 threads	     13.907	       5.706	      62.538	     100.000
UDP_RR	  140 threads	      9.408	       4.699	      52.519	     100.000
UDP_RR	  168 threads	      7.095	       4.077	      44.352	     100.000
UDP_RR	  196 threads	      5.757	       3.775	      35.764	      99.991
UDP_RR	  224 threads	      5.124	       3.704	      28.748	      99.860

schedstat_parse.py -f schbench_vanilla.log
(each group has 28 tasks)
case load se_eff% dom_eff% fast_rate% success_rate%

normal	   1   mthread	     99.152	       6.400	      99.941	     100.000
normal	   2   mthreads	     97.844	       4.003	      99.908	     100.000
normal	   3   mthreads	     96.395	       2.118	      99.917	      99.998
normal	   4   mthreads	     55.288	       1.451	      98.615	      99.804
normal	   5   mthreads	      7.004	       1.870	      45.597	      61.036
normal	   6   mthreads	      3.354	       1.346	      20.777	      34.230
normal	   7   mthreads	      2.183	       1.028	      11.257	      21.055
normal	   8   mthreads	      1.653	       0.825	       7.849	      15.549

schedstat_parse.py -f hackbench_vanilla.log
(each group has 28 tasks)
case load se_eff% dom_eff% fast_rate% success_rate%

process-pipe	     1 group	         99.991	       7.692	      99.999	     100.000
process-pipe	    2 groups	         99.934	       4.615	      99.997	     100.000
process-pipe	    3 groups	         99.597	       3.198	      99.987	     100.000
process-pipe	    4 groups	         98.378	       2.464	      99.958	     100.000
process-pipe	    5 groups	         27.474	       3.653	      89.811	      99.800
process-pipe	    6 groups	         20.201	       4.098	      82.763	      99.570
process-pipe	    7 groups	         16.423	       4.156	      77.398	      99.316
process-pipe	    8 groups	         13.165	       3.920	      72.232	      98.828
process-sockets	     1 group	         99.977	       5.882	      99.999	     100.000
process-sockets	    2 groups	         99.927	       5.505	      99.996	     100.000
process-sockets	    3 groups	         99.397	       3.250	      99.980	     100.000
process-sockets	    4 groups	         79.680	       4.258	      98.864	      99.998
process-sockets	    5 groups	          7.673	       2.503	      63.659	      92.115
process-sockets	    6 groups	          4.642	       1.584	      58.946	      88.048
process-sockets	    7 groups	          3.493	       1.379	      49.816	      81.164
process-sockets	    8 groups	          3.015	       1.407	      40.845	      75.500
threads-pipe	     1 group	         99.997	       0.000	     100.000	     100.000
threads-pipe	    2 groups	         99.894	       2.932	      99.997	     100.000
threads-pipe	    3 groups	         99.611	       4.117	      99.983	     100.000
threads-pipe	    4 groups	         97.703	       2.624	      99.937	     100.000
threads-pipe	    5 groups	         22.919	       3.623	      87.150	      99.764
threads-pipe	    6 groups	         18.016	       4.038	      80.491	      99.557
threads-pipe	    7 groups	         14.663	       3.991	      75.239	      99.247
threads-pipe	    8 groups	         12.242	       3.808	      70.651	      98.644
threads-sockets	     1 group	         99.990	       6.667	      99.999	     100.000
threads-sockets	    2 groups	         99.940	       5.114	      99.997	     100.000
threads-sockets	    3 groups	         99.469	       4.115	      99.977	     100.000
threads-sockets	    4 groups	         87.528	       4.038	      99.400	     100.000
threads-sockets	    5 groups	          6.942	       2.398	      59.244	      88.337
threads-sockets	    6 groups	          4.359	       1.954	      49.448	      87.860
threads-sockets	    7 groups	          2.845	       1.345	      41.198	      77.102
threads-sockets	    8 groups	          2.871	       1.404	      38.512	      74.312

schedstat_parse.py -f tbench_vanilla.log
case load se_eff% dom_eff% fast_rate% success_rate%

loopback	  28 threads	       99.976	      18.369	      99.995	     100.000
loopback	  56 threads	       99.222	       7.799	      99.934	     100.000
loopback	  84 threads	       19.723	       6.819	      70.215	     100.000
loopback	 112 threads	       11.283	       5.371	      55.371	      99.999
loopback	 140 threads	        0.000	       0.000	       0.000	       0.000
loopback	 168 threads	        0.000	       0.000	       0.000	       0.000
loopback	 196 threads	        0.000	       0.000	       0.000	       0.000
loopback	 224 threads	        0.000	       0.000	       0.000	       0.000

According to the test above, if the system becomes busy, the SIS Search Efficiency(se_eff%) drops significantly. Although some benchmarks would finally find an idle CPU(success_rate% = 100%), it is doubtful whether it is worth it to search the whole LLC domain.

[Proposal]
It would be ideal to have a crystal ball to answer this question:
How many CPUs must a wakeup path walk down, before it can find an idle CPU? Many potential metrics could be used to predict the number. One candidate is the sum of util_avg in this LLC domain. The benefit of choosing util_avg is that it is a metric of accumulated historic activity, which seems to be smoother than instantaneous metrics (such as rq->nr_running). Besides, choosing the sum of util_avg would help predict the load of the LLC domain more precisely, because SIS_PROP uses one CPU's idle time to estimate the total LLC domain idle time.

In summary, the lower the util_avg is, the more select_idle_cpu() should scan for idle CPU, and vice versa. When the sum of util_avg in this LLC domain hits 85% or above, the scan stops. The reason to choose 85% as the threshold is that this is the imbalance_pct(117) when a LLC sched group is overloaded.

Introduce the quadratic function:

y = SCHED_CAPACITY_SCALE - p * x^2
and y'= y / SCHED_CAPACITY_SCALE

x is the ratio of sum_util compared to the CPU capacity:
x = sum_util / (llc_weight * SCHED_CAPACITY_SCALE) y' is the ratio of CPUs to be scanned in the LLC domain, and the number of CPUs to scan is calculated by:

nr_scan = llc_weight * y'

Choosing quadratic function is because:
[1] Compared to the linear function, it scans more aggressively when the sum_util is low.
[2] Compared to the exponential function, it is easier to calculate.
[3] It seems that there is no accurate mapping between the sum of util_avg and the number of CPUs to be scanned. Use heuristic scan for now.

For a platform with 112 CPUs per LLC, the number of CPUs to scan is:

sum_util%   0    5   15   25  35  45  55   65   75   85   86 ...
scan_nr   112  111  108  102  93  81  65   47   25    1    0 ...

For a platform with 16 CPUs per LLC, the number of CPUs to scan is:

sum_util%   0    5   15   25  35  45  55   65   75   85   86 ...
scan_nr    16   15   15   14  13  11   9    6    3    0    0 ...

Furthermore, to minimize the overhead of calculating the metrics in select_idle_cpu(), borrow the statistics from periodic load balance. As mentioned by Abel, on a platform with 112 CPUs per LLC, the sum_util calculated by periodic load balance after 112 ms would decay to about 0.5 * 0.5 * 0.5 * 0.7 = 8.75%, thus bringing a delay in reflecting the latest utilization. But it is a trade-off. Checking the util_avg in newidle load balance would be more frequent, but it brings overhead - multiple CPUs write/read the per-LLC shared variable and introduces cache contention. Tim also mentioned that, it is allowed to be non-optimal in terms of scheduling for the short-term variations, but if there is a long-term trend in the load behavior, the scheduler can adjust for that.

When SIS_UTIL is enabled, the select_idle_cpu() uses the nr_scan calculated by SIS_UTIL instead of the one from SIS_PROP. As Peter and Mel suggested, SIS_UTIL should be enabled by default.

This patch is based on the util_avg, which is very sensitive to the CPU frequency invariance. There is an issue that, when the max frequency has been clamp, the util_avg would decay insanely fast when
the CPU is idle. Commit addca285120b ("cpufreq: intel_pstate: Handle no_turbo in frequency invariance") could be used to mitigate this symptom, by adjusting the arch_max_freq_ratio when turbo is disabled. But this issue is still not thoroughly fixed, because the current code is unaware of the user-specified max CPU frequency.

[Test result]

netperf and tbench were launched with 25% 50% 75% 100% 125% 150% 175% 200% of CPU number respectively. Hackbench and schbench were launched by 1, 2 ,4, 8 groups. Each test lasts for 100 seconds and repeats 3 times.

The following is the benchmark result comparison between baseline:vanilla v5.19-rc1 and compare:patched kernel. Positive compare% indicates better performance.

Each netperf test is a:
netperf -4 -H 127.0.1 -t TCP/UDP_RR -c -C -l 100
netperf.throughput
=======

case            	load    	baseline(std%)	compare%( std%)
TCP_RR          	28 threads	 1.00 (  0.34)	 -0.16 (  0.40)
TCP_RR          	56 threads	 1.00 (  0.19)	 -0.02 (  0.20)
TCP_RR          	84 threads	 1.00 (  0.39)	 -0.47 (  0.40)
TCP_RR          	112 threads	 1.00 (  0.21)	 -0.66 (  0.22)
TCP_RR          	140 threads	 1.00 (  0.19)	 -0.69 (  0.19)
TCP_RR          	168 threads	 1.00 (  0.18)	 -0.48 (  0.18)
TCP_RR          	196 threads	 1.00 (  0.16)	+194.70 ( 16.43)
TCP_RR          	224 threads	 1.00 (  0.16)	+197.30 (  7.85)
UDP_RR          	28 threads	 1.00 (  0.37)	 +0.35 (  0.33)
UDP_RR          	56 threads	 1.00 ( 11.18)	 -0.32 (  0.21)
UDP_RR          	84 threads	 1.00 (  1.46)	 -0.98 (  0.32)
UDP_RR          	112 threads	 1.00 ( 28.85)	 -2.48 ( 19.61)
UDP_RR          	140 threads	 1.00 (  0.70)	 -0.71 ( 14.04)
UDP_RR          	168 threads	 1.00 ( 14.33)	 -0.26 ( 11.16)
UDP_RR          	196 threads	 1.00 ( 12.92)	+186.92 ( 20.93)
UDP_RR          	224 threads	 1.00 ( 11.74)	+196.79 ( 18.62)

Take the 224 threads as an example, the SIS search metrics changes are illustrated below:

vanilla patched

   4544492          +237.5%   15338634        sched_debug.cpu.sis_domain_search.avg
     38539        +39686.8%   15333634        sched_debug.cpu.sis_failed.avg
  128300000          -87.9%   15551326        sched_debug.cpu.sis_scanned.avg
   5842896          +162.7%   15347978        sched_debug.cpu.sis_search.avg

There is -87.9% less CPU scans after patched, which indicates lower overhead. Besides, with this patch applied, there is -13% less rq lock contention in perf-profile.calltrace.cycles-pp._raw_spin_lock.raw_spin_rq_lock_nested .try_to_wake_up.default_wake_function.woken_wake_function.
This might help explain the performance improvement - Because this patch allows the waking task to remain on the previous CPU, rather than grabbing other CPUs' lock.

Each hackbench test is a:
hackbench -g $job --process/threads --pipe/sockets -l 1000000 -s 100 hackbench.throughput
=========

case            	load    	baseline(std%)	compare%( std%)
process-pipe    	1 group 	 1.00 (  1.29)	 +0.57 (  0.47)
process-pipe    	2 groups 	 1.00 (  0.27)	 +0.77 (  0.81)
process-pipe    	4 groups 	 1.00 (  0.26)	 +1.17 (  0.02)
process-pipe    	8 groups 	 1.00 (  0.15)	 -4.79 (  0.02)
process-sockets 	1 group 	 1.00 (  0.63)	 -0.92 (  0.13)
process-sockets 	2 groups 	 1.00 (  0.03)	 -0.83 (  0.14)
process-sockets 	4 groups 	 1.00 (  0.40)	 +5.20 (  0.26)
process-sockets 	8 groups 	 1.00 (  0.04)	 +3.52 (  0.03)
threads-pipe    	1 group 	 1.00 (  1.28)	 +0.07 (  0.14)
threads-pipe    	2 groups 	 1.00 (  0.22)	 -0.49 (  0.74)
threads-pipe    	4 groups 	 1.00 (  0.05)	 +1.88 (  0.13)
threads-pipe    	8 groups 	 1.00 (  0.09)	 -4.90 (  0.06)
threads-sockets 	1 group 	 1.00 (  0.25)	 -0.70 (  0.53)
threads-sockets 	2 groups 	 1.00 (  0.10)	 -0.63 (  0.26)
threads-sockets 	4 groups 	 1.00 (  0.19)	+11.92 (  0.24)
threads-sockets 	8 groups 	 1.00 (  0.08)	 +4.31 (  0.11)

Each tbench test is a:
tbench -t 100 $job 127.0.0.1
tbench.throughput
======

case            	load    	baseline(std%)	compare%( std%)
loopback        	28 threads	 1.00 (  0.06)	 -0.14 (  0.09)
loopback        	56 threads	 1.00 (  0.03)	 -0.04 (  0.17)
loopback        	84 threads	 1.00 (  0.05)	 +0.36 (  0.13)
loopback        	112 threads	 1.00 (  0.03)	 +0.51 (  0.03)
loopback        	140 threads	 1.00 (  0.02)	 -1.67 (  0.19)
loopback        	168 threads	 1.00 (  0.38)	 +1.27 (  0.27)
loopback        	196 threads	 1.00 (  0.11)	 +1.34 (  0.17)
loopback        	224 threads	 1.00 (  0.11)	 +1.67 (  0.22)

Each schbench test is a:
schbench -m $job -t 28 -r 100 -s 30000 -c 30000
schbench.latency_90%_us
========

case            	load    	baseline(std%)	compare%( std%)
normal          	1 mthread	 1.00 ( 31.22)	 -7.36 ( 20.25)*
normal          	2 mthreads	 1.00 (  2.45)	 -0.48 (  1.79)
normal          	4 mthreads	 1.00 (  1.69)	 +0.45 (  0.64)
normal          	8 mthreads	 1.00 (  5.47)	 +9.81 ( 14.28)

*Consider the Standard Deviation, this -7.36% regression might not be valid.

Also, a OLTP workload with a commercial RDBMS has been tested, and there is no significant change.

There were concerns that unbalanced tasks among CPUs would cause problems. For example, suppose the LLC domain is composed of 8 CPUs, and 7 tasks are bound to CPU0~CPU6, while CPU7 is idle:

          CPU0    CPU1    CPU2    CPU3    CPU4    CPU5    CPU6    CPU7
util_avg  1024    1024    1024    1024    1024    1024    1024    0

Since the util_avg ratio is 87.5%( = 7/8 ), which is higher than 85%, select_idle_cpu() will not scan, thus CPU7 is undetected during scan. But according to Mel, it is unlikely the CPU7 will be idle all the time because CPU7 could pull some tasks via CPU_NEWLY_IDLE.

lkp(kernel test robot) has reported a regression on stress-ng.sock on a very busy system. According to the sched_debug statistics, it might be caused by SIS_UTIL terminates the scan and chooses a previous CPU earlier, and this might introduce more context switch, especially involuntary preemption, which impacts a busy stress-ng. This regression has shown that, not all benchmarks in every scenario benefit from idle CPU scan limit, and it needs further investigation.

Besides, there is slight regression in hackbench's 16 groups case when the LLC domain has 16 CPUs. Prateek mentioned that we should scan aggressively in an LLC domain with 16 CPUs. Because the cost to search for an idle one among 16 CPUs is negligible. The current patch aims to propose a generic solution and only considers the util_avg. Something like the below could be applied on top of the current patch to fulfill the requirement:

	if (llc_weight <= 16)
		nr_scan = nr_scan * 32 / llc_weight;

For LLC domain with 16 CPUs, the nr_scan will be expanded to 2 times large. The smaller the CPU number this LLC domain has, the larger nr_scan will be expanded. This needs further investigation.

There is also ongoing work[2] from Abel to filter out the busy CPUs during wakeup, to further speed up the idle CPU scan. And it could be a following-up optimization on top of this change.

Suggested-by Tim Chen <[email protected]>

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

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

Tested-by Yicong Yang <[email protected]>

Tested-by Mohini Narkhede <[email protected]>

Tested-by K Prateek Nayak <[email protected]>

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

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

---
 include/linux/sched/topology.h |  1 +
 kernel/sched/fair.c            | 87 ++++++++++++++++++++++++++++++++++
 kernel/sched/features.h        |  3 +-
 3 files changed, 90 insertions(+), 1 deletion(-)

include/linux/sched/topology.h +1 -0

index 8f0f778b7c91..63a04a65e310 100644
@@ -74,6 +74,7 @@ struct sched_domain_shared {
 	atomic_t	ref;
 	atomic_t	nr_busy_cpus;
 	int		has_idle_cores;
+	int		nr_idle_scan;
 };
 
 struct sched_domain {

kernel/sched/fair.c +87 -0

123 lines not on this page · raw message

kernel/sched/features.h +2 -1

index 7f8dace0964c..c4947c1b5edb 100644
@@ -55,7 +55,8 @@ SCHED_FEAT(TTWU_QUEUE, true)
 /*
  * When doing wakeups, attempt to limit superfluous scans of the LLC domain.
  */
-SCHED_FEAT(SIS_PROP, true)
+SCHED_FEAT(SIS_PROP, false)
+SCHED_FEAT(SIS_UTIL, true)
 
 /*
  * Issue a WARN when we do multiple update_rq_clock() calls

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #123 lore raw

PATCH 118/779 genirq: Dont return error on missing optional irq_request_resources()

From: Antonio Borneo <[email protected]>

[ Upstream commit 95001b756467ecc9f5973eb5e74e97699d9bbdf1 ]

Function irq_chip::irq_request_resources() is reported as optional in the declaration of struct irq_chip.
If the parent irq_chip does not implement it, we should ignore it and return.

Don't return error if the functions is missing.

Signed-off-by Antonio Borneo <[email protected]>

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

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

---
 kernel/irq/chip.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

kernel/irq/chip.c +2 -1

index a98bcfc4be7b..f3920374f71c 100644
@@ -1516,7 +1516,8 @@ int irq_chip_request_resources_parent(struct irq_data *data)
 	if (data->chip->irq_request_resources)
 		return data->chip->irq_request_resources(data);
 
-	return -ENOSYS;
+	/* no error on missing optional irq_chip::irq_request_resources */
+	return 0;
 }
 EXPORT_SYMBOL_GPL(irq_chip_request_resources_parent);

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:32 UTC #124 lore raw

PATCH 119/779 irqchip/mips-gic: Only register IPI domain when SMP is enabled

From: Samuel Holland <[email protected]>

[ Upstream commit 8190cc572981f2f13b6ffc26c7cfa7899e5d3ccc ]

The MIPS GIC irqchip driver may be selected in a uniprocessor configuration, but it unconditionally registers an IPI domain.

Limit the part of the driver dealing with IPIs to only be compiled when GENERIC_IRQ_IPI is enabled, which corresponds to an SMP configuration.

Signed-off-by Samuel Holland <[email protected]>

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

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

---
 drivers/irqchip/Kconfig        |  3 +-
 drivers/irqchip/irq-mips-gic.c | 80 +++++++++++++++++++++++-----------
 2 files changed, 56 insertions(+), 27 deletions(-)

drivers/irqchip/Kconfig +2 -1

index aca7b595c4c7..8f9c52873338 100644
@@ -304,7 +304,8 @@ config KEYSTONE_IRQ
 
 config MIPS_GIC
 	bool
-	select GENERIC_IRQ_IPI
+	select GENERIC_IRQ_IPI if SMP
+	select IRQ_DOMAIN_HIERARCHY
 	select MIPS_CM
 
 config INGENIC_IRQ

drivers/irqchip/irq-mips-gic.c +54 ~~-26~~

129 lines not on this page · raw message

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:27 UTC #125 lore raw

PATCH 120/779 genirq: GENERIC_IRQ_IPI depends on SMP

From: Samuel Holland <[email protected]>

[ Upstream commit 0f5209fee90b4544c58b4278d944425292789967 ]

The generic IPI code depends on the IRQ affinity mask being allocated and initialized. This will not be the case if SMP is disabled. Fix up the remaining driver that selected GENERIC_IRQ_IPI in a non-SMP config.

Signed-off-by Samuel Holland <[email protected]>

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

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

---
 drivers/irqchip/Kconfig | 2 +-
 kernel/irq/Kconfig      | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

drivers/irqchip/Kconfig +1 -1

index 8f9c52873338..ae1b9f59abc5 100644
@@ -171,7 +171,7 @@ config MADERA_IRQ
 config IRQ_MIPS_CPU
 	bool
 	select GENERIC_IRQ_CHIP
-	select GENERIC_IRQ_IPI if SYS_SUPPORTS_MULTITHREADING
+	select GENERIC_IRQ_IPI if SMP && SYS_SUPPORTS_MULTITHREADING
 	select IRQ_DOMAIN
 	select GENERIC_IRQ_EFFECTIVE_AFF_MASK

kernel/irq/Kconfig +1 -0

index fbc54c2a7f23..00d58588ea95 100644
@@ -82,6 +82,7 @@ config IRQ_FASTEOI_HIERARCHY_HANDLERS
 # Generic IRQ IPI support
 config GENERIC_IRQ_IPI
 	bool
+	depends on SMP
 	select IRQ_DOMAIN_HIERARCHY
 
 # Generic MSI interrupt support

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:29 UTC #126 lore raw

PATCH 121/779 sched/core: Always flush pending blk_plug

[1] https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/0022-locking-rtmutex-Use-custom-scheduling-function-for-s.patch?h=linux-5.10.y-rt-patches

From: John Keeping <[email protected]>

[ Upstream commit 401e4963bf45c800e3e9ea0d3a0289d738005fd4 ]

With CONFIG_PREEMPT_RT, it is possible to hit a deadlock between two normal priority tasks (SCHED_OTHER, nice level zero):

	INFO: task kworker/u8:0:8 blocked for more than 491 seconds.
	      Not tainted 5.15.49-rt46 #1
	"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
	task:kworker/u8:0    state:D stack:    0 pid:    8 ppid:     2 flags:0x00000000
	Workqueue: writeback wb_workfn (flush-7:0)
	[<c08a3a10>] (__schedule) from [<c08a3d84>] (schedule+0xdc/0x134)
	[<c08a3d84>] (schedule) from [<c08a65a0>] (rt_mutex_slowlock_block.constprop.0+0xb8/0x174)
	[<c08a65a0>] (rt_mutex_slowlock_block.constprop.0) from [<c08a6708>]
	+(rt_mutex_slowlock.constprop.0+0xac/0x174)
	[<c08a6708>] (rt_mutex_slowlock.constprop.0) from [<c0374d60>] (fat_write_inode+0x34/0x54)
	[<c0374d60>] (fat_write_inode) from [<c0297304>] (__writeback_single_inode+0x354/0x3ec)
	[<c0297304>] (__writeback_single_inode) from [<c0297998>] (writeback_sb_inodes+0x250/0x45c)
	[<c0297998>] (writeback_sb_inodes) from [<c0297c20>] (__writeback_inodes_wb+0x7c/0xb8)
	[<c0297c20>] (__writeback_inodes_wb) from [<c0297f24>] (wb_writeback+0x2c8/0x2e4)
	[<c0297f24>] (wb_writeback) from [<c0298c40>] (wb_workfn+0x1a4/0x3e4)
	[<c0298c40>] (wb_workfn) from [<c0138ab8>] (process_one_work+0x1fc/0x32c)
	[<c0138ab8>] (process_one_work) from [<c0139120>] (worker_thread+0x22c/0x2d8)
	[<c0139120>] (worker_thread) from [<c013e6e0>] (kthread+0x16c/0x178)
	[<c013e6e0>] (kthread) from [<c01000fc>] (ret_from_fork+0x14/0x38)
	Exception stack(0xc10e3fb0 to 0xc10e3ff8)
	3fa0:                                     00000000 00000000 00000000 00000000
	3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
	3fe0: 00000000 00000000 00000000 00000000 00000013 00000000

	INFO: task tar:2083 blocked for more than 491 seconds.
	      Not tainted 5.15.49-rt46 #1
	"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
	task:tar             state:D stack:    0 pid: 2083 ppid:  2082 flags:0x00000000
	[<c08a3a10>] (__schedule) from [<c08a3d84>] (schedule+0xdc/0x134)
	[<c08a3d84>] (schedule) from [<c08a41b0>] (io_schedule+0x14/0x24)
	[<c08a41b0>] (io_schedule) from [<c08a455c>] (bit_wait_io+0xc/0x30)
	[<c08a455c>] (bit_wait_io) from [<c08a441c>] (__wait_on_bit_lock+0x54/0xa8)
	[<c08a441c>] (__wait_on_bit_lock) from [<c08a44f4>] (out_of_line_wait_on_bit_lock+0x84/0xb0)
	[<c08a44f4>] (out_of_line_wait_on_bit_lock) from [<c0371fb0>] (fat_mirror_bhs+0xa0/0x144)
	[<c0371fb0>] (fat_mirror_bhs) from [<c0372a68>] (fat_alloc_clusters+0x138/0x2a4)
	[<c0372a68>] (fat_alloc_clusters) from [<c0370b14>] (fat_alloc_new_dir+0x34/0x250)
	[<c0370b14>] (fat_alloc_new_dir) from [<c03787c0>] (vfat_mkdir+0x58/0x148)
	[<c03787c0>] (vfat_mkdir) from [<c0277b60>] (vfs_mkdir+0x68/0x98)
	[<c0277b60>] (vfs_mkdir) from [<c027b484>] (do_mkdirat+0xb0/0xec)
	[<c027b484>] (do_mkdirat) from [<c0100060>] (ret_fast_syscall+0x0/0x1c)
	Exception stack(0xc2e1bfa8 to 0xc2e1bff0)
	bfa0:                   01ee42f0 01ee4208 01ee42f0 000041ed 00000000 00004000
	bfc0: 01ee42f0 01ee4208 00000000 00000027 01ee4302 00000004 000dcb00 01ee4190
	bfe0: 000dc368 bed11924 0006d4b0 b6ebddfc

Here the kworker is waiting on msdos_sb_info::s_lock which is held by tar which is in turn waiting for a buffer which is locked waiting to be flushed, but this operation is plugged in the kworker.

The lock is a normal struct mutex, so tsk_is_pi_blocked() will always return false on !RT and thus the behaviour changes for RT.

It seems that the intent here is to skip blk_flush_plug() in the case where a non-preemptible lock (such as a spinlock) has been converted to a rtmutex on RT, which is the case covered by the SM_RTLOCK_WAIT schedule flag. But sched_submit_work() is only called from schedule() which is never called in this scenario, so the check can simply be deleted.

Looking at the history of the -rt patchset, in fact this change was present from v5.9.1-rt20 until being dropped in v5.13-rt1 as it was part of a larger patch [1] most of which was replaced by commit b4bfa3fcfe3b ("sched/core: Rework the __schedule() preempt argument").

As described in [1]:

The schedule process must distinguish between blocking on a regular sleeping lock (rwsem and mutex) and a RT-only sleeping lock (spinlock and rwlock):
- rwsem and mutex must flush block requests (blk_schedule_flush_plug()) even if blocked on a lock. This can not deadlock because this also happens for non-RT.
There should be a warning if the scheduling point is within a RCU read section.

- spinlock and rwlock must not flush block requests. This will deadlock if the callback attempts to acquire a lock which is already acquired. Similarly to being preempted, there should be no warning if the scheduling point is within a RCU read section.

and with the tsk_is_pi_blocked() in the scheduler path, we hit the first issue.

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

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

Reviewed-by Steven Rostedt (Google) <[email protected]>

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

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

---
 include/linux/sched/rt.h | 8 --------
 kernel/sched/core.c      | 8 ++++++--
 2 files changed, 6 insertions(+), 10 deletions(-)

include/linux/sched/rt.h +0 -8

index e5af028c08b4..994c25640e15 100644
@@ -39,20 +39,12 @@ static inline struct task_struct *rt_mutex_get_top_task(struct task_struct *p)
 }
 extern void rt_mutex_setprio(struct task_struct *p, struct task_struct *pi_task);
 extern void rt_mutex_adjust_pi(struct task_struct *p);
-static inline bool tsk_is_pi_blocked(struct task_struct *tsk)
-{
-	return tsk->pi_blocked_on != NULL;
-}
 #else
 static inline struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
 {
 	return NULL;
 }
 # define rt_mutex_adjust_pi(p)		do { } while (0)
-static inline bool tsk_is_pi_blocked(struct task_struct *tsk)
-{
-	return false;
-}
 #endif
 
 extern void normalize_rt_tasks(void);

kernel/sched/core.c +6 -2

index b89ca5c83143..012c037da58a 100644
@@ -6379,8 +6379,12 @@ static inline void sched_submit_work(struct task_struct *tsk)
 		preempt_enable_no_resched();
 	}
 
-	if (tsk_is_pi_blocked(tsk))
-		return;
+	/*
+	 * spinlock and rwlock must not flush block requests.  This will
+	 * deadlock if the callback attempts to acquire a lock which is
+	 * already acquired.
+	 */
+	SCHED_WARN_ON(current->__state & TASK_RTLOCK_WAIT);
 
 	/*
 	 * If we are going to sleep and we have plugged IO queued,

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:31 UTC #127 lore raw

PATCH 122/779 irqchip/mips-gic: Check the return value of ioremap() in gic_of_init()

From: William Dean <[email protected]>

[ Upstream commit 71349cc85e5930dce78ed87084dee098eba24b59 ]

The function ioremap() in gic_of_init() can fail, so its return value should be checked.

Reported-by Hacash Robot <[email protected]>

Signed-off-by William Dean <[email protected]>

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

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

---
 drivers/irqchip/irq-mips-gic.c | 4 ++++
 1 file changed, 4 insertions(+)

drivers/irqchip/irq-mips-gic.c +4 -0

index f03f47ffea1e..d815285f1efe 100644
@@ -767,6 +767,10 @@ static int __init gic_of_init(struct device_node *node,
 	}
 
 	mips_gic_base = ioremap(gic_base, gic_len);
+	if (!mips_gic_base) {
+		pr_err("Failed to ioremap gic_base\n");
+		return -ENOMEM;
+	}
 
 	gicconfig = read_gic_config();
 	gic_shared_intrs = gicconfig & GIC_CONFIG_NUMINTERRUPTS;

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:31 UTC #128 lore raw

PATCH 123/779 wait: Fix __wait_event_hrtimeout for RT/DL tasks

From: Juri Lelli <[email protected]>

[ Upstream commit cceeeb6a6d02e7b9a74ddd27a3225013b34174aa ]

Changes to hrtimer mode (potentially made by __hrtimer_init_sleeper on PREEMPT_RT) are not visible to hrtimer_start_range_ns, thus not accounted for by hrtimer_start_expires call paths. In particular, __wait_event_hrtimeout suffers from this problem as we have, for example:

fs/aio.c::read_events
wait_event_interruptible_hrtimeout
__wait_event_hrtimeout
hrtimer_init_sleeper_on_stack <- this might "mode |= HRTIMER_MODE_HARD"
on RT if task runs at RT/DL priority
hrtimer_start_range_ns
WARN_ON_ONCE(!(mode & HRTIMER_MODE_HARD) ^ !timer->is_hard) fires since the latter doesn't see the change of mode done by init_sleeper

Fix it by making __wait_event_hrtimeout call hrtimer_sleeper_start_expires, which is aware of the special RT/DL case, instead of hrtimer_start_range_ns.

Reported-by Bruno Goncalves <[email protected]>

Signed-off-by Juri Lelli <[email protected]>

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

Reviewed-by Daniel Bristot de Oliveira <[email protected]>

Reviewed-by Valentin Schneider <[email protected]>

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

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

---
 include/linux/wait.h | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

include/linux/wait.h +5 -4

index d22cf2985b8f..21044562aab7 100644
@@ -544,10 +544,11 @@ do {										\
 										\
 	hrtimer_init_sleeper_on_stack(&__t, CLOCK_MONOTONIC,			\
 				      HRTIMER_MODE_REL);			\
-	if ((timeout) != KTIME_MAX)						\
-		hrtimer_start_range_ns(&__t.timer, timeout,			\
-				       current->timer_slack_ns,			\
-				       HRTIMER_MODE_REL);			\
+	if ((timeout) != KTIME_MAX) {						\
+		hrtimer_set_expires_range_ns(&__t.timer, timeout,		\
+					current->timer_slack_ns);		\
+		hrtimer_sleeper_start_expires(&__t, HRTIMER_MODE_REL);		\
+	}									\
 										\
 	__ret = ___wait_event(wq_head, condition, state, 0, 0,			\
 		if (!__t.task) {						\

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:32 UTC #129 lore raw

PATCH 124/779 ARM: dts: imx6ul: add missing properties for sram

From: Alexander Stein <[email protected]>

[ Upstream commit 5655699cf5cff9f4c4ee703792156bdd05d1addf ]

All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property

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

Signed-off-by Shawn Guo <[email protected]>

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

---
 arch/arm/boot/dts/imx6ul.dtsi | 3 +++
 1 file changed, 3 insertions(+)

arch/arm/boot/dts/imx6ul.dtsi +3 -0

index afeec01f6522..1d435a46fc5c 100644
@@ -149,6 +149,9 @@ soc {
 		ocram: sram@900000 {
 			compatible = "mmio-sram";
 			reg = <0x00900000 0x20000>;
+			ranges = <0 0x00900000 0x20000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
 		};
 
 		intc: interrupt-controller@a01000 {

Signature · 1 line

2.35.1

Greg Kroah-Hartman

author maintainer

2022-08-15 18:32 UTC #130 lore raw

PATCH 125/779 ARM: dts: imx6ul: change operating-points to uint32-matrix