6.0.3-rc1 review

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

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

---
 sound/core/sound_oss.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

sound/core/sound_oss.c +9 -4

@@ -162,7 +162,6 @@ int snd_unregister_oss_device(int type,
 		mutex_unlock(&sound_oss_mutex);
 		return -ENOENT;
 	}
-	unregister_sound_special(minor);
 	switch (SNDRV_MINOR_OSS_DEVICE(minor)) {
 	case SNDRV_MINOR_OSS_PCM:
 		track2 = SNDRV_MINOR_OSS(cidx, SNDRV_MINOR_OSS_AUDIO);

@@ -174,12 +173,18 @@ int snd_unregister_oss_device(int type,
 		track2 = SNDRV_MINOR_OSS(cidx, SNDRV_MINOR_OSS_DMMIDI1);
 		break;
 	}
-	if (track2 >= 0) {
-		unregister_sound_special(track2);
+	if (track2 >= 0)
 		snd_oss_minors[track2] = NULL;
-	}
 	snd_oss_minors[minor] = NULL;
 	mutex_unlock(&sound_oss_mutex);
+
+	/* call unregister_sound_special() outside sound_oss_mutex;
+	 * otherwise may deadlock, as it can trigger the release of a card
+	 */
+	unregister_sound_special(minor);
+	if (track2 >= 0)
+		unregister_sound_special(track2);
+
 	kfree(mptr);
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #2 lore raw

PATCH 2/862 ALSA: rawmidi: Drop register_mutex in snd_rawmidi_free()

Link https://lore.kernel.org/r/CAB7eexJP7w1B0mVgDF0dQ+gWor7UdkiwPczmL7pn91xx8xpzOA@mail.gmail.com open here

From: Takashi Iwai <[email protected]>

commit a70aef7982b012e86dfd39fbb235e76a21ae778a upstream.

The register_mutex taken around the dev_unregister callback call in snd_rawmidi_free() may potentially lead to a mutex deadlock, when OSS emulation and a hot unplug are involved.

Since the mutex doesn't protect the actual race (as the registration itself is already protected by another means), let's drop it.

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

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

---
 sound/core/rawmidi.c |    2 --
 1 file changed, 2 deletions(-)

sound/core/rawmidi.c +0 -2

@@ -1899,10 +1899,8 @@ static int snd_rawmidi_free(struct snd_r
 
 	snd_info_free_entry(rmidi->proc_entry);
 	rmidi->proc_entry = NULL;
-	mutex_lock(&register_mutex);
 	if (rmidi->ops && rmidi->ops->dev_unregister)
 		rmidi->ops->dev_unregister(rmidi);
-	mutex_unlock(&register_mutex);
 
 	snd_rawmidi_free_substreams(&rmidi->streams[SNDRV_RAWMIDI_STREAM_INPUT]);
 	snd_rawmidi_free_substreams(&rmidi->streams[SNDRV_RAWMIDI_STREAM_OUTPUT]);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:40 UTC #3 lore raw

PATCH 3/862 ALSA: usb-audio: Fix potential memory leaks

From: Takashi Iwai <[email protected]>

commit 6382da0828995af87aa8b8bef28cc61aceb4aff3 upstream.

When the driver hits -ENOMEM at allocating a URB or a buffer, it aborts and goes to the error path that releases the all previously allocated resources. However, when -ENOMEM hits at the middle of the sync EP URB allocation loop, the partially allocated URBs might be left without released, because ep->nurbs is still zero at that point.

Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB list.

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

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

---
 sound/usb/endpoint.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

sound/usb/endpoint.c +1 -2

@@ -1261,6 +1261,7 @@ static int sync_ep_set_params(struct snd
 	if (!ep->syncbuf)
 		return -ENOMEM;
 
+	ep->nurbs = SYNC_URBS;
 	for (i = 0; i < SYNC_URBS; i++) {
 		struct snd_urb_ctx *u = &ep->urb[i];
 		u->index = i;

@@ -1280,8 +1281,6 @@ static int sync_ep_set_params(struct snd
 		u->urb->complete = snd_complete_urb;
 	}
 
-	ep->nurbs = SYNC_URBS;
-
 	return 0;
 
 out_of_memory:

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #4 lore raw

PATCH 4/862 ALSA: usb-audio: Fix NULL dererence at error path

From: Takashi Iwai <[email protected]>

commit 568be8aaf8a535f79c4db76cabe17b035aa2584d upstream.

At an error path to release URB buffers and contexts, the driver might hit a NULL dererence for u->urb pointer, when u->buffer_size has been already set but the actual URB allocation failed.

Fix it by adding the NULL check of urb. Also, make sure that buffer_size is cleared after the error path or the close.

Link https://lore.kernel.org/r/CAKG+3NRjTey+fFfUEGwuxL-pi_=T4cUskYG9OzpzHytF+tzYng@mail.gmail.com open here

Reported-by Sabri N. Ferreiro <[email protected]>

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

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

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

sound/usb/endpoint.c +2 -1

@@ -93,12 +93,13 @@ static inline unsigned get_usb_high_spee
  */
 static void release_urb_ctx(struct snd_urb_ctx *u)
 {
-	if (u->buffer_size)
+	if (u->urb && u->buffer_size)
 		usb_free_coherent(u->ep->chip->dev, u->buffer_size,
 				  u->urb->transfer_buffer,
 				  u->urb->transfer_dma);
 	usb_free_urb(u->urb);
 	u->urb = NULL;
+	u->buffer_size = 0;
 }
 
 static const char *usb_error_string(int err)

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #5 lore raw

PATCH 5/862 ALSA: hda/realtek: remove ALC289_FIXUP_DUAL_SPK for Dell 5530

From: Callum Osmotherly <[email protected]>

commit 417b9c51f59734d852e47252476fadc293ad994a upstream.

After some feedback from users with Dell Precision 5530 machines, this patch reverts the previous change to add ALC289_FIXUP_DUAL_SPK. While it improved the speaker output quality, it caused the headphone jack to have an audible "pop" sound when power saving was toggled.

Fixes 1885ff13d4c4 ("ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5530 laptop")

Signed-off-by Callum Osmotherly <[email protected]>

Link https://lore.kernel.org/r/Yz0uyN1zwZhnyRD6@piranha open here

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

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

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

@@ -9186,7 +9186,6 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1028, 0x0871, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1028, 0x0872, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1028, 0x0873, "Dell Precision 3930", ALC255_FIXUP_DUMMY_LINEOUT_VERB),
-	SND_PCI_QUIRK(0x1028, 0x087d, "Dell Precision 5530", ALC289_FIXUP_DUAL_SPK),
 	SND_PCI_QUIRK(0x1028, 0x08ad, "Dell WYSE AIO", ALC225_FIXUP_DELL_WYSE_AIO_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1028, 0x08ae, "Dell WYSE NB", ALC225_FIXUP_DELL1_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1028, 0x0935, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),

Greg Kroah-Hartman

author maintainer

2022-10-19 08:41 UTC #6 lore raw

PATCH 6/862 ALSA: hda/realtek: Correct pin configs for ASUS G533Z

From: Luke D. Jones <[email protected]>

commit 66ba7c88507344dee68ad1acbdb630473ab36114 upstream.

The initial fix for ASUS G533Z was based on faulty information. This fixes the pincfg to values that have been verified with no existing module options or other hacks enabled.

Enables headphone jack, and 5.1 surround.

[ corrected the indent level by tiwai ]

Fixes bc2c23549ccd ("ALSA: hda/realtek: Add pincfg for ASUS G533Z HP jack")

Signed-off-by Luke D. Jones <[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 |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

sound/pci/hda/patch_realtek.c +5 -3

@@ -8427,11 +8427,13 @@ static const struct hda_fixup alc269_fix
 	[ALC285_FIXUP_ASUS_G533Z_PINS] = {
 		.type = HDA_FIXUP_PINS,
 		.v.pins = (const struct hda_pintbl[]) {
-			{ 0x14, 0x90170120 },
+			{ 0x14, 0x90170152 }, /* Speaker Surround Playback Switch */
+			{ 0x19, 0x03a19020 }, /* Mic Boost Volume */
+			{ 0x1a, 0x03a11c30 }, /* Mic Boost Volume */
+			{ 0x1e, 0x90170151 }, /* Rear jack, IN OUT EAPD Detect */
+			{ 0x21, 0x03211420 },
 			{ }
 		},
-		.chained = true,
-		.chain_id = ALC294_FIXUP_ASUS_G513_PINS,
 	},
 	[ALC294_FIXUP_ASUS_COEF_1B] = {
 		.type = HDA_FIXUP_VERBS,

Greg Kroah-Hartman

author maintainer

2022-10-19 08:40 UTC #7 lore raw

PATCH 7/862 ALSA: hda/realtek: Add quirk for ASUS GV601R laptop

From: Luke D. Jones <[email protected]>

commit 2ea8e1297801f7b0220ebf6ae61a5b74ca83981e upstream.

The ASUS ROG X16 (GV601R) series laptop has the same node-to-DAC pairs as early models and the G14, this includes bass speakers which are by default mapped incorrectly to the 0x06 node.

Add a quirk to use the same DAC pairs as the G14.

Signed-off-by Luke D. Jones <[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

@@ -9411,6 +9411,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1043, 0x1e8e, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA401),
 	SND_PCI_QUIRK(0x1043, 0x1c52, "ASUS Zephyrus G15 2022", ALC289_FIXUP_ASUS_GA401),
 	SND_PCI_QUIRK(0x1043, 0x1f11, "ASUS Zephyrus G14", ALC289_FIXUP_ASUS_GA401),
+	SND_PCI_QUIRK(0x1043, 0x1f92, "ASUS ROG Flow X16", ALC289_FIXUP_ASUS_GA401),
 	SND_PCI_QUIRK(0x1043, 0x3030, "ASUS ZN270IE", ALC256_FIXUP_ASUS_AIO_GPIO2),
 	SND_PCI_QUIRK(0x1043, 0x831a, "ASUS P901", ALC269_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK(0x1043, 0x834a, "ASUS S101", ALC269_FIXUP_STEREO_DMIC),

Greg Kroah-Hartman

author maintainer

2022-10-19 08:40 UTC #8 lore raw

PATCH 8/862 ALSA: hda/realtek: Add Intel Reference SSID to support headset keys

From: Saranya Gopal <[email protected]>

commit 4f2e56a59b9947b3e698d3cabcb858765c12b1e8 upstream.

This patch fixes the issue with 3.5mm headset keys on RPL-P platform.

[ Rearranged the entry in SSID order by tiwai ]

Signed-off-by Saranya Gopal <[email protected]>

Signed-off-by Ninad Naik <[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

@@ -9433,6 +9433,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board", ALC700_FIXUP_INTEL_REFERENCE),
 	SND_PCI_QUIRK(0x10ec, 0x118c, "Medion EE4254 MD62100", ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE),
 	SND_PCI_QUIRK(0x10ec, 0x1230, "Intel Reference board", ALC295_FIXUP_CHROME_BOOK),
+	SND_PCI_QUIRK(0x10ec, 0x124c, "Intel Reference board", ALC295_FIXUP_CHROME_BOOK),
 	SND_PCI_QUIRK(0x10ec, 0x1252, "Intel Reference board", ALC295_FIXUP_CHROME_BOOK),
 	SND_PCI_QUIRK(0x10ec, 0x1254, "Intel Reference board", ALC295_FIXUP_CHROME_BOOK),
 	SND_PCI_QUIRK(0x10f7, 0x8338, "Panasonic CF-SZ6", ALC269_FIXUP_HEADSET_MODE),

Greg Kroah-Hartman

author maintainer

2022-10-19 08:40 UTC #9 lore raw

PATCH 9/862 mtd: rawnand: atmel: Unmap streaming DMA mappings

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

From: Tudor Ambarus <[email protected]>

commit 1161703c9bd664da5e3b2eb1a3bb40c210e026ea upstream.

Every dma_map_single() call should have its dma_unmap_single() counterpart, because the DMA address space is a shared resource and one could render the machine unusable by consuming all DMA addresses.

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

Fixes f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")

Signed-off-by Tudor Ambarus <[email protected]>

Acked-by Alexander Dahl <[email protected]>

Reported-by Peter Rosin <[email protected]>

Tested-by Alexander Dahl <[email protected]>

Reviewed-by Boris Brezillon <[email protected]>

Tested-by Peter Rosin <[email protected]>

Signed-off-by Miquel Raynal <[email protected]>

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

---
 drivers/mtd/nand/raw/atmel/nand-controller.c |    1 +
 1 file changed, 1 insertion(+)

drivers/mtd/nand/raw/atmel/nand-controller.c +1 -0

@@ -405,6 +405,7 @@ static int atmel_nand_dma_transfer(struc
 
 	dma_async_issue_pending(nc->dmac);
 	wait_for_completion(&finished);
+	dma_unmap_single(nc->dev, buf_dma, len, dir);
 
 	return 0;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:37 UTC #10 lore raw

PATCH 10/862 io_uring: add custom opcode hooks on fail

From: Pavel Begunkov <[email protected]>

commit a47b255e90395bdb481975ab3d9e96fcf8b3165f upstream.

Sometimes we have to do a little bit of a fixup on a request failuer in io_req_complete_failed(). Add a callback in opdef for that.

Link https://lore.kernel.org/r/b734cff4e67cb30cca976b9face321023f37549a.1663668091.git.asml.silence@gmail.com open here

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

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

---
 io_uring/io_uring.c |    4 ++++
 io_uring/opdef.h    |    1 +
 2 files changed, 5 insertions(+)

io_uring/io_uring.c +4 -0

@@ -823,8 +823,12 @@ inline void __io_req_complete(struct io_
 
 void io_req_complete_failed(struct io_kiocb *req, s32 res)
 {
+	const struct io_op_def *def = &io_op_defs[req->opcode];
+
 	req_set_fail(req);
 	io_req_set_res(req, res, io_put_kbuf(req, IO_URING_F_UNLOCKED));
+	if (def->fail)
+		def->fail(req);
 	io_req_complete_post(req);
 }

io_uring/opdef.h +1 -0

@@ -36,6 +36,7 @@ struct io_op_def {
 	int (*issue)(struct io_kiocb *, unsigned int);
 	int (*prep_async)(struct io_kiocb *);
 	void (*cleanup)(struct io_kiocb *);
+	void (*fail)(struct io_kiocb *);
 };
 
 extern const struct io_op_def io_op_defs[];

Greg Kroah-Hartman

author maintainer

2022-10-19 08:38 UTC #11 lore raw

PATCH 11/862 io_uring/rw: dont lose partial IO result on fail

From: Pavel Begunkov <[email protected]>

commit 47b4c68660752facfa6247b1fc9ca9d722b8b601 upstream.

A partially done read/write may end up in io_req_complete_failed() and loose the result, make sure we return the number of bytes processed.

Link https://lore.kernel.org/r/05e0879c226bcd53b441bf92868eadd4bf04e2fc.1663668091.git.asml.silence@gmail.com open here

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

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

---
 io_uring/opdef.c |    6 ++++++
 io_uring/rw.c    |    8 ++++++++
 io_uring/rw.h    |    1 +
 3 files changed, 15 insertions(+)

io_uring/opdef.c +6 -0

@@ -69,6 +69,7 @@ const struct io_op_def io_op_defs[] = {
 		.issue			= io_read,
 		.prep_async		= io_readv_prep_async,
 		.cleanup		= io_readv_writev_cleanup,
+		.fail			= io_rw_fail,
 	},
 	[IORING_OP_WRITEV] = {
 		.needs_file		= 1,

@@ -85,6 +86,7 @@ const struct io_op_def io_op_defs[] = {
 		.issue			= io_write,
 		.prep_async		= io_writev_prep_async,
 		.cleanup		= io_readv_writev_cleanup,
+		.fail			= io_rw_fail,
 	},
 	[IORING_OP_FSYNC] = {
 		.needs_file		= 1,

@@ -105,6 +107,7 @@ const struct io_op_def io_op_defs[] = {
 		.name			= "READ_FIXED",
 		.prep			= io_prep_rw,
 		.issue			= io_read,
+		.fail			= io_rw_fail,
 	},
 	[IORING_OP_WRITE_FIXED] = {
 		.needs_file		= 1,

@@ -119,6 +122,7 @@ const struct io_op_def io_op_defs[] = {
 		.name			= "WRITE_FIXED",
 		.prep			= io_prep_rw,
 		.issue			= io_write,
+		.fail			= io_rw_fail,
 	},
 	[IORING_OP_POLL_ADD] = {
 		.needs_file		= 1,

@@ -273,6 +277,7 @@ const struct io_op_def io_op_defs[] = {
 		.name			= "READ",
 		.prep			= io_prep_rw,
 		.issue			= io_read,
+		.fail			= io_rw_fail,
 	},
 	[IORING_OP_WRITE] = {
 		.needs_file		= 1,

@@ -287,6 +292,7 @@ const struct io_op_def io_op_defs[] = {
 		.name			= "WRITE",
 		.prep			= io_prep_rw,
 		.issue			= io_write,
+		.fail			= io_rw_fail,
 	},
 	[IORING_OP_FADVISE] = {
 		.needs_file		= 1,

io_uring/rw.c +8 -0

@@ -984,6 +984,14 @@ static void io_cqring_ev_posted_iopoll(s
 		io_cqring_wake(ctx);
 }
 
+void io_rw_fail(struct io_kiocb *req)
+{
+	int res;
+
+	res = io_fixup_rw_res(req, req->cqe.res);
+	io_req_set_res(req, res, req->cqe.flags);
+}
+
 int io_do_iopoll(struct io_ring_ctx *ctx, bool force_nonspin)
 {
 	struct io_wq_work_node *pos, *start, *prev;

io_uring/rw.h +1 -0

@@ -21,3 +21,4 @@ int io_readv_prep_async(struct io_kiocb
 int io_write(struct io_kiocb *req, unsigned int issue_flags);
 int io_writev_prep_async(struct io_kiocb *req);
 void io_readv_writev_cleanup(struct io_kiocb *req);
+void io_rw_fail(struct io_kiocb *req);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:38 UTC #12 lore raw

PATCH 12/862 io_uring/net: dont lose partial send/recv on fail

From: Pavel Begunkov <[email protected]>

commit 7e6b638ed501cced4e472298d6b08dd16346f3a6 upstream.

Just as with rw, partial send/recv may end up in io_req_complete_failed() and loose the result, make sure we return the number of bytes processed.

Link https://lore.kernel.org/r/a4ff95897b5419356fca9ea55db91ac15b2975f9.1663668091.git.asml.silence@gmail.com open here

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

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

---
 io_uring/net.c   |   10 ++++++++++
 io_uring/net.h   |    2 ++
 io_uring/opdef.c |    4 ++++
 3 files changed, 16 insertions(+)

io_uring/net.c +10 -0

@@ -1087,6 +1087,16 @@ int io_sendzc(struct io_kiocb *req, unsi
 	return IOU_OK;
 }
 
+void io_sendrecv_fail(struct io_kiocb *req)
+{
+	struct io_sr_msg *sr = io_kiocb_to_cmd(req, struct io_sr_msg);
+	int res = req->cqe.res;
+
+	if (req->flags & REQ_F_PARTIAL_IO)
+		res = sr->done_io;
+	io_req_set_res(req, res, req->cqe.flags);
+}
+
 int io_accept_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
 {
 	struct io_accept *accept = io_kiocb_to_cmd(req, struct io_accept);

io_uring/net.h +2 -0

@@ -43,6 +43,8 @@ int io_recvmsg_prep(struct io_kiocb *req
 int io_recvmsg(struct io_kiocb *req, unsigned int issue_flags);
 int io_recv(struct io_kiocb *req, unsigned int issue_flags);
 
+void io_sendrecv_fail(struct io_kiocb *req);
+
 int io_accept_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe);
 int io_accept(struct io_kiocb *req, unsigned int issue_flags);

io_uring/opdef.c +4 -0

@@ -157,6 +157,7 @@ const struct io_op_def io_op_defs[] = {
 		.issue			= io_sendmsg,
 		.prep_async		= io_sendmsg_prep_async,
 		.cleanup		= io_sendmsg_recvmsg_cleanup,
+		.fail			= io_sendrecv_fail,
 #else
 		.prep			= io_eopnotsupp_prep,
 #endif

@@ -174,6 +175,7 @@ const struct io_op_def io_op_defs[] = {
 		.issue			= io_recvmsg,
 		.prep_async		= io_recvmsg_prep_async,
 		.cleanup		= io_sendmsg_recvmsg_cleanup,
+		.fail			= io_sendrecv_fail,
 #else
 		.prep			= io_eopnotsupp_prep,
 #endif

@@ -316,6 +318,7 @@ const struct io_op_def io_op_defs[] = {
 #if defined(CONFIG_NET)
 		.prep			= io_sendmsg_prep,
 		.issue			= io_send,
+		.fail			= io_sendrecv_fail,
 #else
 		.prep			= io_eopnotsupp_prep,
 #endif

@@ -331,6 +334,7 @@ const struct io_op_def io_op_defs[] = {
 #if defined(CONFIG_NET)
 		.prep			= io_recvmsg_prep,
 		.issue			= io_recv,
+		.fail			= io_sendrecv_fail,
 #else
 		.prep			= io_eopnotsupp_prep,
 #endif

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #13 lore raw

PATCH 13/862 io_uring/rw: fix unexpected link breakage

From: Pavel Begunkov <[email protected]>

commit bf68b5b34311ee57ed40749a1257a30b46127556 upstream.

req->cqe.res is set in io_read() to the amount of bytes left to be done, which is used to figure out whether to fail a read or not. However, io_read() may do another without returning, and we stash the previous value into ->bytes_done but forget to update cqe.res. Then we ask a read to do strictly less than cqe.res but expect the return to be exactly cqe.res.

Fix the bug by updating cqe.res for retries.

Reported-and-Tested-by Beld Zhang <[email protected]>

Link https://lore.kernel.org/r/3a1088440c7be98e5800267af922a67da0ef9f13.1664235732.git.asml.silence@gmail.com open here

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

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

---
 io_uring/rw.c |    1 +
 1 file changed, 1 insertion(+)

io_uring/rw.c +1 -0

@@ -823,6 +823,7 @@ int io_read(struct io_kiocb *req, unsign
 			return -EAGAIN;
 		}
 
+		req->cqe.res = iov_iter_count(&s->iter);
 		/*
 		 * Now retry read with the IOCB_WAITQ parts set in the iocb. If
 		 * we get -EIOCBQUEUED, then we'll get a notification when the

Greg Kroah-Hartman

author maintainer

2022-10-19 08:38 UTC #14 lore raw

PATCH 14/862 io_uring/rw: dont lose short results on io_setup_async_rw()

From: Pavel Begunkov <[email protected]>

commit c278d9f8ac0db5590909e6d9e85b5ca2b786704f upstream.

If a retry io_setup_async_rw() fails we lose result from the first io_iter_do_read(), which is a problem mostly for streams/sockets.

Link https://lore.kernel.org/r/0e8d20cebe5fc9c96ed268463c394237daabc384.1664235732.git.asml.silence@gmail.com open here

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

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

---
 io_uring/rw.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

io_uring/rw.c +5 -3

@@ -794,10 +794,12 @@ int io_read(struct io_kiocb *req, unsign
 	iov_iter_restore(&s->iter, &s->iter_state);
 
 	ret2 = io_setup_async_rw(req, iovec, s, true);
-	if (ret2)
-		return ret2;
-
 	iovec = NULL;
+	if (ret2) {
+		ret = ret > 0 ? ret : ret2;
+		goto done;
+	}
+
 	io = req->async_data;
 	s = &io->s;
 	/*

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #15 lore raw

PATCH 15/862 io_uring/net: fix fast_iov assignment in io_setup_async_msg()

From: Stefan Metzmacher <[email protected]>

commit 3e4cb6ebbb2bad201c1186bc0b7e8cf41dd7f7e6 upstream.

I hit a very bad problem during my tests of SENDMSG_ZC. BUG(); in first_iovec_segment() triggered very easily. The problem was io_setup_async_msg() in the partial retry case, which seems to happen more often with _ZC.

iov_iter_iovec_advance() may change i->iov in order to have i->iov_offset being only relative to the first element.

Which means kmsg->msg.msg_iter.iov is no longer the same as kmsg->fast_iov.

But this would rewind the copy to be the start of
async_msg->fast_iov, which means the internal
state of sync_msg->msg.msg_iter is inconsitent.

I tested with 5 vectors with length like this 4, 0, 64, 20, 8388608 and got a short writes with:
- ret=2675244 min_ret=8388692 => remaining 5713448 sr->done_io=2675244
- ret=-EAGAIN => io_uring_poll_arm
- ret=4911225 min_ret=5713448 => remaining 802223 sr->done_io=7586469
- ret=-EAGAIN => io_uring_poll_arm
- ret=802223 min_ret=802223 => res=8388692

While this was easily triggered with SENDMSG_ZC (queued for 6.1),
it was a potential problem starting with 7ba89d2af17aa879dda30f5d5d3f152e587fc551 in 5.18 for IORING_OP_RECVMSG.
And also with 4c3c09439c08b03d9503df0ca4c7619c5842892e in 5.19
for IORING_OP_SENDMSG.

However 257e84a5377fbbc336ff563833a8712619acce56 introduced the critical code into io_setup_async_msg() in 5.11.

Fixes 7ba89d2af17aa ("io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly")

Fixes 257e84a5377fb ("io_uring: refactor sendmsg/recvmsg iov managing")

Link https://lore.kernel.org/r/b2e7be246e2fb173520862b0c7098e55767567a2.1664436949.git.metze@samba.org open here

Signed-off-by Stefan Metzmacher <[email protected]>

Reviewed-by Pavel Begunkov <[email protected]>

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

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

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

io_uring/net.c +4 -2

@@ -165,8 +165,10 @@ static int io_setup_async_msg(struct io_
 	memcpy(async_msg, kmsg, sizeof(*kmsg));
 	async_msg->msg.msg_name = &async_msg->addr;
 	/* if were using fast_iov, set it to the new one */
-	if (!async_msg->free_iov)
-		async_msg->msg.msg_iter.iov = async_msg->fast_iov;
+	if (!kmsg->free_iov) {
+		size_t fast_idx = kmsg->msg.msg_iter.iov - kmsg->fast_iov;
+		async_msg->msg.msg_iter.iov = &async_msg->fast_iov[fast_idx];
+	}
 
 	return -EAGAIN;
 }

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #16 lore raw

PATCH 16/862 io_uring/net: dont update msg_name if not provided

From: Pavel Begunkov <[email protected]>

commit 6f10ae8a155446248055c7ddd480ef40139af788 upstream.

io_sendmsg_copy_hdr() may clear msg->msg_name if the userspace didn't provide it, we should retain NULL in this case.

Link https://lore.kernel.org/r/97d49f61b5ec76d0900df658cfde3aa59ff22121.1664486545.git.asml.silence@gmail.com open here

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

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

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

io_uring/net.c +2 -1

@@ -163,7 +163,8 @@ static int io_setup_async_msg(struct io_
 	}
 	req->flags |= REQ_F_NEED_CLEANUP;
 	memcpy(async_msg, kmsg, sizeof(*kmsg));
-	async_msg->msg.msg_name = &async_msg->addr;
+	if (async_msg->msg.msg_name)
+		async_msg->msg.msg_name = &async_msg->addr;
 	/* if were using fast_iov, set it to the new one */
 	if (!kmsg->free_iov) {
 		size_t fast_idx = kmsg->msg.msg_iter.iov - kmsg->fast_iov;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #17 lore raw

PATCH 17/862 io_uring: limit registration w/ SINGLE_ISSUER

From: Pavel Begunkov <[email protected]>

commit d7cce96c449e35bbfd41e830b341b95973891eed upstream.

IORING_SETUP_SINGLE_ISSUER restricts what tasks can submit requests. Extend it to registration as well, so non-owning task can't do registrations. It's not necessary at the moment but might be useful in the future.

Cc <[email protected]> # 6.0

Fixes 97bbdc06a444 ("io_uring: add IORING_SETUP_SINGLE_ISSUER")

Link https://lore.kernel.org/r/f52a6a9c8a8990d4a831f73c0571e7406aac2bba.1664237592.git.asml.silence@gmail.com open here

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

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

---
 io_uring/io_uring.c |    3 +++
 1 file changed, 3 insertions(+)

io_uring/io_uring.c +3 -0

@@ -3710,6 +3710,9 @@ static int __io_uring_register(struct io
 	if (WARN_ON_ONCE(percpu_ref_is_dying(&ctx->refs)))
 		return -ENXIO;
 
+	if (ctx->submitter_task && ctx->submitter_task != current)
+		return -EEXIST;
+
 	if (ctx->restricted) {
 		if (opcode >= IORING_REGISTER_LAST)
 			return -EINVAL;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #18 lore raw

PATCH 18/862 io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT

From: Jens Axboe <[email protected]>

commit 3fb1bd68817288729179444caf1fd5c5c4d2d65d upstream.

We treat EINPROGRESS like EAGAIN, but if we're retrying post getting EINPROGRESS, then we just need to check the socket for errors and terminate the request.

This was exposed on a bluetooth connection request which ends up taking a while and hitting EINPROGRESS, and yields a CQE result of -EBADFD because we're retrying a connect on a socket that is now connected.

Fixes 87f80d623c6c ("io_uring: handle connect -EINPROGRESS like -EAGAIN")

Link https://github.com/axboe/liburing/issues/671

Reported-by Aidan Sun <[email protected]>

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

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

---
 io_uring/net.c |   28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

io_uring/net.c +22 -6

@@ -46,6 +46,7 @@ struct io_connect {
 	struct file			*file;
 	struct sockaddr __user		*addr;
 	int				addr_len;
+	bool				in_progress;
 };
 
 struct io_sr_msg {

@@ -1263,6 +1264,7 @@ int io_connect_prep(struct io_kiocb *req
 
 	conn->addr = u64_to_user_ptr(READ_ONCE(sqe->addr));
 	conn->addr_len =  READ_ONCE(sqe->addr2);
+	conn->in_progress = false;
 	return 0;
 }

@@ -1274,6 +1276,16 @@ int io_connect(struct io_kiocb *req, uns
 	int ret;
 	bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK;
 
+	if (connect->in_progress) {
+		struct socket *socket;
+
+		ret = -ENOTSOCK;
+		socket = sock_from_file(req->file);
+		if (socket)
+			ret = sock_error(socket->sk);
+		goto out;
+	}
+
 	if (req_has_async_data(req)) {
 		io = req->async_data;
 	} else {

@@ -1290,13 +1302,17 @@ int io_connect(struct io_kiocb *req, uns
 	ret = __sys_connect_file(req->file, &io->address,
 					connect->addr_len, file_flags);
 	if ((ret == -EAGAIN || ret == -EINPROGRESS) && force_nonblock) {
-		if (req_has_async_data(req))
-			return -EAGAIN;
-		if (io_alloc_async_data(req)) {
-			ret = -ENOMEM;
-			goto out;
+		if (ret == -EINPROGRESS) {
+			connect->in_progress = true;
+		} else {
+			if (req_has_async_data(req))
+				return -EAGAIN;
+			if (io_alloc_async_data(req)) {
+				ret = -ENOMEM;
+				goto out;
+			}
+			memcpy(req->async_data, &__io, sizeof(__io));
 		}
-		memcpy(req->async_data, &__io, sizeof(__io));
 		return -EAGAIN;
 	}
 	if (ret == -ERESTARTSYS)

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #19 lore raw

PATCH 19/862 io_uring/af_unix: defer registered files gc to io_uring release

From: Pavel Begunkov <[email protected]>

commit 0091bfc81741b8d3aeb3b7ab8636f911b2de6e80 upstream.

Instead of putting io_uring's registered files in unix_gc() we want it to be done by io_uring itself. The trick here is to consider io_uring registered files for cycle detection but not actually putting them down. Because io_uring can't register other ring instances, this will remove all refs to the ring file triggering the ->release path and clean up with io_ring_ctx_free().

Fixes 6b06314c47e1 ("io_uring: add file set registration")

Reported-and-tested-by David Bouman <[email protected]>

Signed-off-by Thadeu Lima de Souza Cascardo <[email protected]>

[axboe: add kerneldoc comment to skb, fold in skb leak fix]

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

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

---
 include/linux/skbuff.h |    2 ++
 io_uring/rsrc.c        |    1 +
 net/unix/garbage.c     |   20 ++++++++++++++++++++
 3 files changed, 23 insertions(+)

include/linux/skbuff.h +2 -0

@@ -796,6 +796,7 @@ typedef unsigned char *sk_buff_data_t;
  *	@csum_level: indicates the number of consecutive checksums found in
  *		the packet minus one that have been verified as
  *		CHECKSUM_UNNECESSARY (max 3)
+ *	@scm_io_uring: SKB holds io_uring registered files
  *	@dst_pending_confirm: need to confirm neighbour
  *	@decrypted: Decrypted SKB
  *	@slow_gro: state present at GRO time, slower prepare step required

@@ -975,6 +976,7 @@ struct sk_buff {
 #endif
 	__u8			slow_gro:1;
 	__u8			csum_not_inet:1;
+	__u8			scm_io_uring:1;
 
 #ifdef CONFIG_NET_SCHED
 	__u16			tc_index;	/* traffic control index */

io_uring/rsrc.c +1 -0

@@ -855,6 +855,7 @@ int __io_scm_file_account(struct io_ring
 
 		UNIXCB(skb).fp = fpl;
 		skb->sk = sk;
+		skb->scm_io_uring = 1;
 		skb->destructor = unix_destruct_scm;
 		refcount_add(skb->truesize, &sk->sk_wmem_alloc);
 	}

net/unix/garbage.c +20 -0

@@ -204,6 +204,7 @@ void wait_for_unix_gc(void)
 /* The external entry point: unix_gc() */
 void unix_gc(void)
 {
+	struct sk_buff *next_skb, *skb;
 	struct unix_sock *u;
 	struct unix_sock *next;
 	struct sk_buff_head hitlist;

@@ -297,11 +298,30 @@ void unix_gc(void)
 
 	spin_unlock(&unix_gc_lock);
 
+	/* We need io_uring to clean its registered files, ignore all io_uring
+	 * originated skbs. It's fine as io_uring doesn't keep references to
+	 * other io_uring instances and so killing all other files in the cycle
+	 * will put all io_uring references forcing it to go through normal
+	 * release.path eventually putting registered files.
+	 */
+	skb_queue_walk_safe(&hitlist, skb, next_skb) {
+		if (skb->scm_io_uring) {
+			__skb_unlink(skb, &hitlist);
+			skb_queue_tail(&skb->sk->sk_receive_queue, skb);
+		}
+	}
+
 	/* Here we are. Hitlist is filled. Die. */
 	__skb_queue_purge(&hitlist);
 
 	spin_lock(&unix_gc_lock);
 
+	/* There could be io_uring registered files, just push them back to
+	 * the inflight list
+	 */
+	list_for_each_entry_safe(u, next, &gc_candidates, link)
+		list_move_tail(&u->link, &gc_inflight_list);
+
 	/* All candidates should have been detached by now. */
 	BUG_ON(!list_empty(&gc_candidates));

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #20 lore raw

PATCH 20/862 io_uring: correct pinned_vm accounting

From: Pavel Begunkov <[email protected]>

commit 42b6419d0aba47c5d8644cdc0b68502254671de5 upstream.

->mm_account should be released only after we free all registered buffers, otherwise __io_sqe_buffers_unregister() will see a NULL ->mm_account and skip locked_vm accounting.

Link https://lore.kernel.org/r/6d798f65ed4ab8db3664c4d3397d4af16ca98846.1664849932.git.asml.silence@gmail.com open here

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

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

---
 io_uring/io_uring.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

io_uring/io_uring.c +4 -6

@@ -2422,12 +2422,6 @@ static void io_req_caches_free(struct io
 static __cold void io_ring_ctx_free(struct io_ring_ctx *ctx)
 {
 	io_sq_thread_finish(ctx);
-
-	if (ctx->mm_account) {
-		mmdrop(ctx->mm_account);
-		ctx->mm_account = NULL;
-	}
-
 	io_rsrc_refs_drop(ctx);
 	/* __io_rsrc_put_work() may need uring_lock to progress, wait w/o it */
 	io_wait_rsrc_data(ctx->buf_data);

@@ -2470,6 +2464,10 @@ static __cold void io_ring_ctx_free(stru
 	WARN_ON_ONCE(!list_empty(&ctx->ltimeout_list));
 	WARN_ON_ONCE(ctx->notif_slots || ctx->nr_notif_slots);
 
+	if (ctx->mm_account) {
+		mmdrop(ctx->mm_account);
+		ctx->mm_account = NULL;
+	}
 	io_mem_free(ctx->rings);
 	io_mem_free(ctx->sq_sqes);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:40 UTC #21 lore raw

PATCH 21/862 hv_netvsc: Fix race between VF offering and VF association message from host

From: Gaurav Kohli <[email protected]>

commit 365e1ececb2905f94cc10a5817c5b644a32a3ae2 upstream.

During vm boot, there might be possibility that vf registration call comes before the vf association from host to vm.

And this might break netvsc vf path, To prevent the same block vf registration until vf bind message comes from host.

Fixes 00d7ddba11436 ("hv_netvsc: pair VF based on serial number")

Reviewed-by Haiyang Zhang <[email protected]>

Signed-off-by Gaurav Kohli <[email protected]>

Signed-off-by David S. Miller <[email protected]>

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

---
 drivers/net/hyperv/hyperv_net.h |    3 ++-
 drivers/net/hyperv/netvsc.c     |    4 ++++
 drivers/net/hyperv/netvsc_drv.c |   19 +++++++++++++++++++
 3 files changed, 25 insertions(+), 1 deletion(-)

drivers/net/hyperv/hyperv_net.h +2 -1

@@ -1051,7 +1051,8 @@ struct net_device_context {
 	u32 vf_alloc;
 	/* Serial number of the VF to team with */
 	u32 vf_serial;
-
+	/* completion variable to confirm vf association */
+	struct completion vf_add;
 	/* Is the current data path through the VF NIC? */
 	bool  data_path_is_vf;

drivers/net/hyperv/netvsc.c +4 -0

@@ -1580,6 +1580,10 @@ static void netvsc_send_vf(struct net_de
 
 	net_device_ctx->vf_alloc = nvmsg->msg.v4_msg.vf_assoc.allocated;
 	net_device_ctx->vf_serial = nvmsg->msg.v4_msg.vf_assoc.serial;
+
+	if (net_device_ctx->vf_alloc)
+		complete(&net_device_ctx->vf_add);
+
 	netdev_info(ndev, "VF slot %u %s\n",
 		    net_device_ctx->vf_serial,
 		    net_device_ctx->vf_alloc ? "added" : "removed");

drivers/net/hyperv/netvsc_drv.c +19 -0

@@ -2313,6 +2313,18 @@ static struct net_device *get_netvsc_bys
 
 	}
 
+	/* Fallback path to check synthetic vf with
+	 * help of mac addr
+	 */
+	list_for_each_entry(ndev_ctx, &netvsc_dev_list, list) {
+		ndev = hv_get_drvdata(ndev_ctx->device_ctx);
+		if (ether_addr_equal(vf_netdev->perm_addr, ndev->perm_addr)) {
+			netdev_notice(vf_netdev,
+				      "falling back to mac addr based matching\n");
+			return ndev;
+		}
+	}
+
 	netdev_notice(vf_netdev,
 		      "no netdev found for vf serial:%u\n", serial);
 	return NULL;

@@ -2409,6 +2421,11 @@ static int netvsc_vf_changed(struct net_
 	if (net_device_ctx->data_path_is_vf == vf_is_up)
 		return NOTIFY_OK;
 
+	if (vf_is_up && !net_device_ctx->vf_alloc) {
+		netdev_info(ndev, "Waiting for the VF association from host\n");
+		wait_for_completion(&net_device_ctx->vf_add);
+	}
+
 	ret = netvsc_switch_datapath(ndev, vf_is_up);
 
 	if (ret) {

@@ -2440,6 +2457,7 @@ static int netvsc_unregister_vf(struct n
 
 	netvsc_vf_setxdp(vf_netdev, NULL);
 
+	reinit_completion(&net_device_ctx->vf_add);
 	netdev_rx_handler_unregister(vf_netdev);
 	netdev_upper_dev_unlink(vf_netdev, ndev);
 	RCU_INIT_POINTER(net_device_ctx->vf_netdev, NULL);

@@ -2479,6 +2497,7 @@ static int netvsc_probe(struct hv_device
 
 	INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_link_change);
 
+	init_completion(&net_device_ctx->vf_add);
 	spin_lock_init(&net_device_ctx->lock);
 	INIT_LIST_HEAD(&net_device_ctx->reconfig_events);
 	INIT_DELAYED_WORK(&net_device_ctx->vf_takeover, netvsc_vf_setup);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #22 lore raw

PATCH 22/862 cifs: destage dirty pages before re-reading them for cache=none

From: Ronnie Sahlberg <[email protected]>

commit bb44c31cdcac107344dd2fcc3bd0504a53575c51 upstream.

This is the opposite case of kernel bugzilla 216301.
If we mmap a file using cache=none and then proceed to update the mmapped area these updates are not reflected in a later pread() of that part of the file.
To fix this we must first destage any dirty pages in the range before we allow the pread() to proceed.

Reviewed-by Paulo Alcantara (SUSE) <[email protected]>

Reviewed-by Enzo Matsumiya <[email protected]>

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

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

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

fs/cifs/file.c +9 -0

@@ -4271,6 +4271,15 @@ static ssize_t __cifs_readv(
 		len = ctx->len;
 	}
 
+	if (direct) {
+		rc = filemap_write_and_wait_range(file->f_inode->i_mapping,
+						  offset, offset + len - 1);
+		if (rc) {
+			kref_put(&ctx->refcount, cifs_aio_ctx_release);
+			return -EAGAIN;
+		}
+	}
+
 	/* grab a lock here due to read response handlers can access ctx */
 	mutex_lock(&ctx->aio_mutex);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:40 UTC #23 lore raw

PATCH 23/862 cifs: Fix the error length of VALIDATE_NEGOTIATE_INFO message

From: Zhang Xiaoxu <[email protected]>

commit e98ecc6e94f4e6d21c06660b0f336df02836694f upstream.

Commit d5c7076b772a ("smb3: add smb3.1.1 to default dialect list") extend the dialects from 3 to 4, but forget to decrease the extended length when specific the dialect, then the message length is larger than expected.

This maybe leak some info through network because not initialize the message body.

After apply this patch, the VALIDATE_NEGOTIATE_INFO message length is reduced from 28 bytes to 26 bytes.

Fixes d5c7076b772a ("smb3: add smb3.1.1 to default dialect list")

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

Acked-by Paulo Alcantara (SUSE) <[email protected]>

Reviewed-by Tom Talpey <[email protected]>

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

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

fs/cifs/smb2pdu.c +2 -2

@@ -1169,9 +1169,9 @@ int smb3_validate_negotiate(const unsign
 		pneg_inbuf->Dialects[0] =
 			cpu_to_le16(server->vals->protocol_id);
 		pneg_inbuf->DialectCount = cpu_to_le16(1);
-		/* structure is big enough for 3 dialects, sending only 1 */
+		/* structure is big enough for 4 dialects, sending only 1 */
 		inbuflen = sizeof(*pneg_inbuf) -
-				sizeof(pneg_inbuf->Dialects[0]) * 2;
+				sizeof(pneg_inbuf->Dialects[0]) * 3;
 	}
 
 	rc = SMB2_ioctl(xid, tcon, NO_FILE_ID, NO_FILE_ID,

Greg Kroah-Hartman

author maintainer

2022-10-19 08:41 UTC #24 lore raw

PATCH 24/862 iio: dac: ad5593r: Fix i2c read protocol requirements

From: Michael Hennerich <[email protected]>

commit 558a25f903b4af6361b7fbeea08a6446a0745653 upstream.

For reliable operation across the full range of supported interface rates, the AD5593R needs a STOP condition between address write, and data read (like show in the datasheet Figure 40) so in turn i2c_smbus_read_word_swapped cannot be used.

While at it, a simple helper was added to make the code simpler.

Fixes 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs")

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

Signed-off-by Nuno Sá <[email protected]>

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

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

---
 drivers/iio/dac/ad5593r.c |   46 +++++++++++++++++++++++++++-------------------
 1 file changed, 27 insertions(+), 19 deletions(-)

drivers/iio/dac/ad5593r.c +27 ~~-19~~

@@ -13,6 +13,8 @@
 #include <linux/module.h>
 #include <linux/mod_devicetable.h>
 
+#include <asm/unaligned.h>
+
 #define AD5593R_MODE_CONF		(0 << 4)
 #define AD5593R_MODE_DAC_WRITE		(1 << 4)
 #define AD5593R_MODE_ADC_READBACK	(4 << 4)

@@ -20,6 +22,24 @@
 #define AD5593R_MODE_GPIO_READBACK	(6 << 4)
 #define AD5593R_MODE_REG_READBACK	(7 << 4)
 
+static int ad5593r_read_word(struct i2c_client *i2c, u8 reg, u16 *value)
+{
+	int ret;
+	u8 buf[2];
+
+	ret = i2c_smbus_write_byte(i2c, reg);
+	if (ret < 0)
+		return ret;
+
+	ret = i2c_master_recv(i2c, buf, sizeof(buf));
+	if (ret < 0)
+		return ret;
+
+	*value = get_unaligned_be16(buf);
+
+	return 0;
+}
+
 static int ad5593r_write_dac(struct ad5592r_state *st, unsigned chan, u16 value)
 {
 	struct i2c_client *i2c = to_i2c_client(st->dev);

@@ -38,13 +58,7 @@ static int ad5593r_read_adc(struct ad559
 	if (val < 0)
 		return (int) val;
 
-	val = i2c_smbus_read_word_swapped(i2c, AD5593R_MODE_ADC_READBACK);
-	if (val < 0)
-		return (int) val;
-
-	*value = (u16) val;
-
-	return 0;
+	return ad5593r_read_word(i2c, AD5593R_MODE_ADC_READBACK, value);
 }
 
 static int ad5593r_reg_write(struct ad5592r_state *st, u8 reg, u16 value)

@@ -58,25 +72,19 @@ static int ad5593r_reg_write(struct ad55
 static int ad5593r_reg_read(struct ad5592r_state *st, u8 reg, u16 *value)
 {
 	struct i2c_client *i2c = to_i2c_client(st->dev);
-	s32 val;
-
-	val = i2c_smbus_read_word_swapped(i2c, AD5593R_MODE_REG_READBACK | reg);
-	if (val < 0)
-		return (int) val;
 
-	*value = (u16) val;
-
-	return 0;
+	return ad5593r_read_word(i2c, AD5593R_MODE_REG_READBACK | reg, value);
 }
 
 static int ad5593r_gpio_read(struct ad5592r_state *st, u8 *value)
 {
 	struct i2c_client *i2c = to_i2c_client(st->dev);
-	s32 val;
+	u16 val;
+	int ret;
 
-	val = i2c_smbus_read_word_swapped(i2c, AD5593R_MODE_GPIO_READBACK);
-	if (val < 0)
-		return (int) val;
+	ret = ad5593r_read_word(i2c, AD5593R_MODE_GPIO_READBACK, &val);
+	if (ret)
+		return ret;
 
 	*value = (u8) val;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:39 UTC #25 lore raw

PATCH 25/862 iio: ltc2497: Fix reading conversion results

From: Uwe Kleine-König <[email protected]>

commit 7f4f1096d5921f5d90547596f9ce80e0b924f887 upstream.

After the result of the previous conversion is read the chip automatically starts a new conversion and doesn't accept new i2c transfers until this conversion is completed which makes the function return failure.

So add an early return iff the programming of the new address isn't needed. Note this will not fix the problem in general, but all cases that are currently used. Once this changes we get the failure back, but this can be addressed when the need arises.

Fixes 69548b7c2c4f ("iio: adc: ltc2497: split protocol independent part in a separate module ")

Reported-by Meng Li <[email protected]>

Signed-off-by Uwe Kleine-König <[email protected]>

Tested-by Denys Zagorui <[email protected]>

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

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

---
 drivers/iio/adc/ltc2497.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

drivers/iio/adc/ltc2497.c +13 -0

@@ -41,6 +41,19 @@ static int ltc2497_result_and_measure(st
 		}
 
 		*val = (be32_to_cpu(st->buf) >> 14) - (1 << 17);
+
+		/*
+		 * The part started a new conversion at the end of the above i2c
+		 * transfer, so if the address didn't change since the last call
+		 * everything is fine and we can return early.
+		 * If not (which should only happen when some sort of bulk
+		 * conversion is implemented) we have to program the new
+		 * address. Note that this probably fails as the conversion that
+		 * was triggered above is like not complete yet and the two
+		 * operations have to be done in a single transfer.
+		 */
+		if (ddata->addr_prev == address)
+			return 0;
 	}
 
 	ret = i2c_smbus_write_byte(st->client,

Greg Kroah-Hartman

author maintainer

2022-10-19 08:40 UTC #26 lore raw

PATCH 26/862 iio: adc: ad7923: fix channel readings for some variants

From: Nuno Sá <[email protected]>

commit f4f43f01cff2f29779343ade755191afd2581c77 upstream.

Some of the supported devices have 4 or 2 LSB trailing bits that should not be taken into account. Hence we need to shift these bits out which fits perfectly on the scan type shift property. This change fixes both raw and buffered reads.

Fixes f2f7a449707e ("iio:adc:ad7923: Add support for the ad7904/ad7914/ad7924")

Fixes 851644a60d20 ("iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928")

Signed-off-by Nuno Sá <[email protected]>

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

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

---
 drivers/iio/adc/ad7923.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/iio/adc/ad7923.c +3 -1

@@ -93,6 +93,7 @@ enum ad7923_id {
 			.sign = 'u',					\
 			.realbits = (bits),				\
 			.storagebits = 16,				\
+			.shift = 12 - (bits),				\
 			.endianness = IIO_BE,				\
 		},							\
 	}

@@ -268,7 +269,8 @@ static int ad7923_read_raw(struct iio_de
 			return ret;
 
 		if (chan->address == EXTRACT(ret, 12, 4))
-			*val = EXTRACT(ret, 0, 12);
+			*val = EXTRACT(ret, chan->scan_type.shift,
+				       chan->scan_type.realbits);
 		else
 			return -EIO;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:41 UTC #27 lore raw

PATCH 27/862 iio: pressure: dps310: Refactor startup procedure

From: Eddie James <[email protected]>

commit c2329717bdd3fa62f8a2f3d8d85ad0bee4556bd7 upstream.

Move the startup procedure into a function, and correct a missing check on the return code for writing the PRS_CFG register.

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

Reviewed-by Joel Stanley <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

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

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

---
 drivers/iio/pressure/dps310.c |  188 ++++++++++++++++++++++--------------------
 1 file changed, 99 insertions(+), 89 deletions(-)

drivers/iio/pressure/dps310.c +99 ~~-89~~

@@ -159,6 +159,102 @@ static int dps310_get_coefs(struct dps31
 	return 0;
 }
 
+/*
+ * Some versions of the chip will read temperatures in the ~60C range when
+ * it's actually ~20C. This is the manufacturer recommended workaround
+ * to correct the issue. The registers used below are undocumented.
+ */
+static int dps310_temp_workaround(struct dps310_data *data)
+{
+	int rc;
+	int reg;
+
+	rc = regmap_read(data->regmap, 0x32, &reg);
+	if (rc)
+		return rc;
+
+	/*
+	 * If bit 1 is set then the device is okay, and the workaround does not
+	 * need to be applied
+	 */
+	if (reg & BIT(1))
+		return 0;
+
+	rc = regmap_write(data->regmap, 0x0e, 0xA5);
+	if (rc)
+		return rc;
+
+	rc = regmap_write(data->regmap, 0x0f, 0x96);
+	if (rc)
+		return rc;
+
+	rc = regmap_write(data->regmap, 0x62, 0x02);
+	if (rc)
+		return rc;
+
+	rc = regmap_write(data->regmap, 0x0e, 0x00);
+	if (rc)
+		return rc;
+
+	return regmap_write(data->regmap, 0x0f, 0x00);
+}
+
+static int dps310_startup(struct dps310_data *data)
+{
+	int rc;
+	int ready;
+
+	/*
+	 * Set up pressure sensor in single sample, one measurement per second
+	 * mode
+	 */
+	rc = regmap_write(data->regmap, DPS310_PRS_CFG, 0);
+	if (rc)
+		return rc;
+
+	/*
+	 * Set up external (MEMS) temperature sensor in single sample, one
+	 * measurement per second mode
+	 */
+	rc = regmap_write(data->regmap, DPS310_TMP_CFG, DPS310_TMP_EXT);
+	if (rc)
+		return rc;
+
+	/* Temp and pressure shifts are disabled when PRC <= 8 */
+	rc = regmap_write_bits(data->regmap, DPS310_CFG_REG,
+			       DPS310_PRS_SHIFT_EN | DPS310_TMP_SHIFT_EN, 0);
+	if (rc)
+		return rc;
+
+	/* MEAS_CFG doesn't update correctly unless first written with 0 */
+	rc = regmap_write_bits(data->regmap, DPS310_MEAS_CFG,
+			       DPS310_MEAS_CTRL_BITS, 0);
+	if (rc)
+		return rc;
+
+	/* Turn on temperature and pressure measurement in the background */
+	rc = regmap_write_bits(data->regmap, DPS310_MEAS_CFG,
+			       DPS310_MEAS_CTRL_BITS, DPS310_PRS_EN |
+			       DPS310_TEMP_EN | DPS310_BACKGROUND);
+	if (rc)
+		return rc;
+
+	/*
+	 * Calibration coefficients required for reporting temperature.
+	 * They are available 40ms after the device has started
+	 */
+	rc = regmap_read_poll_timeout(data->regmap, DPS310_MEAS_CFG, ready,
+				      ready & DPS310_COEF_RDY, 10000, 40000);
+	if (rc)
+		return rc;
+
+	rc = dps310_get_coefs(data);
+	if (rc)
+		return rc;
+
+	return dps310_temp_workaround(data);
+}
+
 static int dps310_get_pres_precision(struct dps310_data *data)
 {
 	int rc;

@@ -677,52 +773,12 @@ static const struct iio_info dps310_info
 	.write_raw = dps310_write_raw,
 };
 
-/*
- * Some verions of chip will read temperatures in the ~60C range when
- * its actually ~20C. This is the manufacturer recommended workaround
- * to correct the issue. The registers used below are undocumented.
- */
-static int dps310_temp_workaround(struct dps310_data *data)
-{
-	int rc;
-	int reg;
-
-	rc = regmap_read(data->regmap, 0x32, &reg);
-	if (rc < 0)
-		return rc;
-
-	/*
-	 * If bit 1 is set then the device is okay, and the workaround does not
-	 * need to be applied
-	 */
-	if (reg & BIT(1))
-		return 0;
-
-	rc = regmap_write(data->regmap, 0x0e, 0xA5);
-	if (rc < 0)
-		return rc;
-
-	rc = regmap_write(data->regmap, 0x0f, 0x96);
-	if (rc < 0)
-		return rc;
-
-	rc = regmap_write(data->regmap, 0x62, 0x02);
-	if (rc < 0)
-		return rc;
-
-	rc = regmap_write(data->regmap, 0x0e, 0x00);
-	if (rc < 0)
-		return rc;
-
-	return regmap_write(data->regmap, 0x0f, 0x00);
-}
-
 static int dps310_probe(struct i2c_client *client,
 			const struct i2c_device_id *id)
 {
 	struct dps310_data *data;
 	struct iio_dev *iio;
-	int rc, ready;
+	int rc;
 
 	iio = devm_iio_device_alloc(&client->dev,  sizeof(*data));
 	if (!iio)

@@ -747,54 +803,8 @@ static int dps310_probe(struct i2c_clien
 	if (rc)
 		return rc;
 
-	/*
-	 * Set up pressure sensor in single sample, one measurement per second
-	 * mode
-	 */
-	rc = regmap_write(data->regmap, DPS310_PRS_CFG, 0);
-
-	/*
-	 * Set up external (MEMS) temperature sensor in single sample, one
-	 * measurement per second mode
-	 */
-	rc = regmap_write(data->regmap, DPS310_TMP_CFG, DPS310_TMP_EXT);
-	if (rc < 0)
-		return rc;
-
-	/* Temp and pressure shifts are disabled when PRC <= 8 */
-	rc = regmap_write_bits(data->regmap, DPS310_CFG_REG,
-			       DPS310_PRS_SHIFT_EN | DPS310_TMP_SHIFT_EN, 0);
-	if (rc < 0)
-		return rc;
-
-	/* MEAS_CFG doesn't update correctly unless first written with 0 */
-	rc = regmap_write_bits(data->regmap, DPS310_MEAS_CFG,
-			       DPS310_MEAS_CTRL_BITS, 0);
-	if (rc < 0)
-		return rc;
-
-	/* Turn on temperature and pressure measurement in the background */
-	rc = regmap_write_bits(data->regmap, DPS310_MEAS_CFG,
-			       DPS310_MEAS_CTRL_BITS, DPS310_PRS_EN |
-			       DPS310_TEMP_EN | DPS310_BACKGROUND);
-	if (rc < 0)
-		return rc;
-
-	/*
-	 * Calibration coefficients required for reporting temperature.
-	 * They are available 40ms after the device has started
-	 */
-	rc = regmap_read_poll_timeout(data->regmap, DPS310_MEAS_CFG, ready,
-				      ready & DPS310_COEF_RDY, 10000, 40000);
-	if (rc < 0)
-		return rc;
-
-	rc = dps310_get_coefs(data);
-	if (rc < 0)
-		return rc;
-
-	rc = dps310_temp_workaround(data);
-	if (rc < 0)
+	rc = dps310_startup(data);
+	if (rc)
 		return rc;
 
 	rc = devm_iio_device_register(&client->dev, iio);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:46 UTC #28 lore raw

PATCH 28/862 iio: pressure: dps310: Reset chip after timeout

From: Eddie James <[email protected]>

commit 7b4ab4abcea4c0c10b25187bf2569e5a07e9a20c upstream.

The DPS310 chip has been observed to get "stuck" such that pressure and temperature measurements are never indicated as "ready" in the MEAS_CFG register. The only solution is to reset the device and try again. In order to avoid continual failures, use a boolean flag to only try the reset after timeout once if errors persist.

Fixes ba6ec48e76bc ("iio: Add driver for Infineon DPS310")

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

Reviewed-by Andy Shevchenko <[email protected]>

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

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

---
 drivers/iio/pressure/dps310.c |   74 ++++++++++++++++++++++++++++++++++++------
 1 file changed, 64 insertions(+), 10 deletions(-)

drivers/iio/pressure/dps310.c +64 ~~-10~~

@@ -89,6 +89,7 @@ struct dps310_data {
 	s32 c00, c10, c20, c30, c01, c11, c21;
 	s32 pressure_raw;
 	s32 temp_raw;
+	bool timeout_recovery_failed;
 };
 
 static const struct iio_chan_spec dps310_channels[] = {

@@ -393,11 +394,69 @@ static int dps310_get_temp_k(struct dps3
 	return scale_factors[ilog2(rc)];
 }
 
+static int dps310_reset_wait(struct dps310_data *data)
+{
+	int rc;
+
+	rc = regmap_write(data->regmap, DPS310_RESET, DPS310_RESET_MAGIC);
+	if (rc)
+		return rc;
+
+	/* Wait for device chip access: 2.5ms in specification */
+	usleep_range(2500, 12000);
+	return 0;
+}
+
+static int dps310_reset_reinit(struct dps310_data *data)
+{
+	int rc;
+
+	rc = dps310_reset_wait(data);
+	if (rc)
+		return rc;
+
+	return dps310_startup(data);
+}
+
+static int dps310_ready_status(struct dps310_data *data, int ready_bit, int timeout)
+{
+	int sleep = DPS310_POLL_SLEEP_US(timeout);
+	int ready;
+
+	return regmap_read_poll_timeout(data->regmap, DPS310_MEAS_CFG, ready, ready & ready_bit,
+					sleep, timeout);
+}
+
+static int dps310_ready(struct dps310_data *data, int ready_bit, int timeout)
+{
+	int rc;
+
+	rc = dps310_ready_status(data, ready_bit, timeout);
+	if (rc) {
+		if (rc == -ETIMEDOUT && !data->timeout_recovery_failed) {
+			/* Reset and reinitialize the chip. */
+			if (dps310_reset_reinit(data)) {
+				data->timeout_recovery_failed = true;
+			} else {
+				/* Try again to get sensor ready status. */
+				if (dps310_ready_status(data, ready_bit, timeout))
+					data->timeout_recovery_failed = true;
+				else
+					return 0;
+			}
+		}
+
+		return rc;
+	}
+
+	data->timeout_recovery_failed = false;
+	return 0;
+}
+
 static int dps310_read_pres_raw(struct dps310_data *data)
 {
 	int rc;
 	int rate;
-	int ready;
 	int timeout;
 	s32 raw;
 	u8 val[3];

@@ -409,9 +468,7 @@ static int dps310_read_pres_raw(struct d
 	timeout = DPS310_POLL_TIMEOUT_US(rate);
 
 	/* Poll for sensor readiness; base the timeout upon the sample rate. */
-	rc = regmap_read_poll_timeout(data->regmap, DPS310_MEAS_CFG, ready,
-				      ready & DPS310_PRS_RDY,
-				      DPS310_POLL_SLEEP_US(timeout), timeout);
+	rc = dps310_ready(data, DPS310_PRS_RDY, timeout);
 	if (rc)
 		goto done;

@@ -448,7 +505,6 @@ static int dps310_read_temp_raw(struct d
 {
 	int rc;
 	int rate;
-	int ready;
 	int timeout;
 
 	if (mutex_lock_interruptible(&data->lock))

@@ -458,10 +514,8 @@ static int dps310_read_temp_raw(struct d
 	timeout = DPS310_POLL_TIMEOUT_US(rate);
 
 	/* Poll for sensor readiness; base the timeout upon the sample rate. */
-	rc = regmap_read_poll_timeout(data->regmap, DPS310_MEAS_CFG, ready,
-				      ready & DPS310_TMP_RDY,
-				      DPS310_POLL_SLEEP_US(timeout), timeout);
-	if (rc < 0)
+	rc = dps310_ready(data, DPS310_TMP_RDY, timeout);
+	if (rc)
 		goto done;
 
 	rc = dps310_read_temp_ready(data);

@@ -756,7 +810,7 @@ static void dps310_reset(void *action_da
 {
 	struct dps310_data *data = action_data;
 
-	regmap_write(data->regmap, DPS310_RESET, DPS310_RESET_MAGIC);
+	dps310_reset_wait(data);
 }
 
 static const struct regmap_config dps310_regmap_config = {

Greg Kroah-Hartman

author maintainer

2022-10-19 08:40 UTC #29 lore raw

PATCH 29/862 xhci: dbc: Fix memory leak in xhci_alloc_dbc()

From: Rafael Mendonca <[email protected]>

commit d591b32e519603524a35b172156db71df9116902 upstream.

If DbC is already in use, then the allocated memory for the xhci_dbc struct doesn't get freed before returning NULL, which leads to a memleak.

Fixes 534675942e90 ("xhci: dbc: refactor xhci_dbc_init()")

Signed-off-by Rafael Mendonca <[email protected]>

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

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

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

---
 drivers/usb/host/xhci-dbgcap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/host/xhci-dbgcap.c +1 -1

@@ -988,7 +988,7 @@ xhci_alloc_dbc(struct device *dev, void
 	dbc->driver = driver;
 
 	if (readl(&dbc->regs->control) & DBC_CTRL_DBC_ENABLE)
-		return NULL;
+		goto err;
 
 	INIT_DELAYED_WORK(&dbc->event_work, xhci_dbc_handle_events);
 	spin_lock_init(&dbc->lock);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:42 UTC #30 lore raw

PATCH 30/862 usb: gadget: uvc: Fix argument to sizeof() in uvc_register_video()

From: Nathan Chancellor <[email protected]>

commit a15e17acce5aaae54243f55a7349c2225450b9bc upstream.

When building s390 allmodconfig after commit 9b91a6523078 ("usb: gadget:
uvc: increase worker prio to WQ_HIGHPRI"), the following error occurs:

In file included from ../include/linux/string.h:253,

                   from ../include/linux/bitmap.h:11,
                   from ../include/linux/cpumask.h:12,
                   from ../include/linux/smp.h:13,
                   from ../include/linux/lockdep.h:14,
                   from ../include/linux/rcupdate.h:29,
                   from ../include/linux/rculist.h:11,
                   from ../include/linux/pid.h:5,
                   from ../include/linux/sched.h:14,
                   from ../include/linux/ratelimit.h:6,
                   from ../include/linux/dev_printk.h:16,
                   from ../include/linux/device.h:15,
                   from ../drivers/usb/gadget/function/f_uvc.c:9:
  In function ‘fortify_memset_chk’,
      inlined from ‘uvc_register_video’ at ../drivers/usb/gadget/function/f_uvc.c:424:2:
  ../include/linux/fortify-string.h:301:25: error: call to ‘__write_overflow_field’ declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
    301 |                         __write_overflow_field(p_size_field, size);
        |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This points to the memset() in uvc_register_video(). It is clear that the argument to sizeof() is incorrect, as uvc->vdev (a 'struct video_device') is being zeroed out but the size of uvc->video (a 'struct uvc_video') is being used as the third arugment to memset().

pahole shows that prior to commit 9b91a6523078 ("usb: gadget: uvc:
increase worker prio to WQ_HIGHPRI"), 'struct video_device' and 'struct ucv_video' had the same size, meaning that the argument to sizeof() is incorrect semantically but there is no visible issue:

  $ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+"
  video_device    1400    4
  uvc_video       1400    3

After that change, uvc_video becomes slightly larger, meaning that the memset() will overwrite by 8 bytes:

  $ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+"
  video_device    1400    4
  uvc_video       1408    3

Fix the arugment to sizeof() so that there is no overwrite.

Fixes e4ce9ed835bc ("usb: gadget: uvc: ensure the vdev is unset")

Signed-off-by Nathan Chancellor <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

Reviewed-by Kees Cook <[email protected]>

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

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

---
 drivers/usb/gadget/function/f_uvc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/gadget/function/f_uvc.c +1 -1

@@ -421,7 +421,7 @@ uvc_register_video(struct uvc_device *uv
 	int ret;
 
 	/* TODO reference counting. */
-	memset(&uvc->vdev, 0, sizeof(uvc->video));
+	memset(&uvc->vdev, 0, sizeof(uvc->vdev));
 	uvc->vdev.v4l2_dev = &uvc->v4l2_dev;
 	uvc->vdev.v4l2_dev->dev = &cdev->gadget->dev;
 	uvc->vdev.fops = &uvc_v4l2_fops;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #31 lore raw

PATCH 31/862 usb: add quirks for Lenovo OneLink+ Dock

From: Jean-Francois Le Fillatre <[email protected]>

commit 37d49519b41405b08748392c6a7f193d9f77ecd2 upstream.

The Lenovo OneLink+ Dock contains two VL812 USB3.0 controllers:
17ef:1018 upstream
17ef:1019 downstream

These hubs suffer from two separate problems:

1) After the host system was suspended and woken up, the hubs appear to be in a random state. Some downstream ports (both internal to the built-in audio and network controllers, and external to USB sockets) may no longer be functional. The exact list of disabled ports (if any) changes from wakeup to wakeup. Ports remain in that state until the dock is power-cycled, or until the laptop is rebooted.

Wakeup sources connected to the hubs (keyboard, WoL on the integrated gigabit controller) will wake the system up from suspend, but they may no longer work after wakeup (and in that case will no longer work as wakeup source in a subsequent suspend-wakeup cycle).

This issue appears in the logs with messages such as:

     usb 1-6.1-port4: cannot disable (err = -71)
     usb 1-6-port2: cannot disable (err = -71)
     usb 1-6.1: clear tt 1 (80c0) error -71
     usb 1-6-port4: cannot disable (err = -71)
     usb 1-6.4: PM: dpm_run_callback(): usb_dev_resume+0x0/0x10 [usbcore] returns -71
     usb 1-6.4: PM: failed to resume async: error -71
     usb 1-7: reset full-speed USB device number 5 using xhci_hcd
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: Cannot enable. Maybe the USB cable is bad?
     usb 1-6.1-port1: cannot disable (err = -71)
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: cannot reset (err = -71)
     usb 1-6.1-port1: Cannot enable. Maybe the USB cable is bad?
     usb 1-6.1-port1: cannot disable (err = -71)

2) Some USB devices cannot be enumerated properly. So far I have only seen the issue with USB 3.0 devices. The same devices work without problem directly connected to the host system, to other systems or to other hubs (even when those hubs are connected to the OneLink+ dock).

One very reliable reproducer is this USB 3.0 HDD enclosure:
152d:9561 JMicron Technology Corp. / JMicron USA Technology Corp. Mobius

I have seen it happen sporadically with other USB 3.0 enclosures, with controllers from different manufacturers, all self-powered.

Typical messages in the logs:

xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command usb 2-1.4: device not accepting address 6, error -62 xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command usb 2-1.4: device not accepting address 7, error -62
usb 2-1-port4: attempt power cycle
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command usb 2-1.4: device not accepting address 8, error -62 xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command usb 2-1.4: device not accepting address 9, error -62
usb 2-1-port4: unable to enumerate USB device

Through trial and error, I found that the USB_QUIRK_RESET_RESUME solved the second issue. Further testing then uncovered the first issue. Test results are summarized in this table:

=======================================================================================
Settings USB2 hotplug USB3 hotplug State after waking up
---------------------------------------------------------------------------------------

power/control=auto works fails broken

usbcore.autosuspend=-1 works works broken
OR power/control=on

power/control=auto works (1) works (1) works
and USB_QUIRK_RESET_RESUME

power/control=on works works works
and USB_QUIRK_RESET_RESUME

HUB_QUIRK_DISABLE_AUTOSUSPEND works works works
and USB_QUIRK_RESET_RESUME

=======================================================================================

In those results, the power/control settings are applied to both hubs, both on the USB2 and USB3 side, before each test.

Quoted 1 line

From those results, USB_QUIRK_RESET_RESUME is required to reset the hubs

properly after a suspend-wakeup cycle, and the hubs must not autosuspend to work around the USB3 issue.

A secondary effect of USB_QUIRK_RESET_RESUME is to prevent the hubs' upstream links from suspending (the downstream ports can still suspend). This secondary effect is used in results (1). It is enough to solve the USB3 problem.

Setting USB_QUIRK_RESET_RESUME on those hubs is the smallest patch that solves both issues.

Prior to creating this patch, I have used the USB_QUIRK_RESET_RESUME via the kernel command line for over a year without noticing any side effect.

Thanks to Oliver Neukum @Suse for explanations of the operations of USB_QUIRK_RESET_RESUME, and requesting more testing.

Signed-off-by Jean-Francois Le Fillatre <[email protected]>

Cc stable <[email protected]>

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

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

---
 drivers/usb/core/quirks.c |    4 ++++
 1 file changed, 4 insertions(+)

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

@@ -437,6 +437,10 @@ static const struct usb_device_id usb_qu
 	{ USB_DEVICE(0x1532, 0x0116), .driver_info =
 			USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
 
+	/* Lenovo ThinkPad OneLink+ Dock twin hub controllers (VIA Labs VL812) */
+	{ USB_DEVICE(0x17ef, 0x1018), .driver_info = USB_QUIRK_RESET_RESUME },
+	{ USB_DEVICE(0x17ef, 0x1019), .driver_info = USB_QUIRK_RESET_RESUME },
+
 	/* Lenovo USB-C to Ethernet Adapter RTL8153-04 */
 	{ USB_DEVICE(0x17ef, 0x720c), .driver_info = USB_QUIRK_NO_LPM },

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #32 lore raw

PATCH 32/862 mmc: core: Add SD card quirk for broken discard

From: Avri Altman <[email protected]>

commit 07d2872bf4c864eb83d034263c155746a2fb7a3b upstream.

Some SD-cards from Sandisk that are SDA-6.0 compliant reports they supports discard, while they actually don't. This might cause mk2fs to fail while trying to format the card and revert it to a read-only mode.

To fix this problem, let's add a card quirk (MMC_QUIRK_BROKEN_SD_DISCARD) to indicate that we shall fall-back to use the legacy erase command instead.

Signed-off-by Avri Altman <[email protected]>

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

[Ulf: Updated the commit message]

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

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

---
 drivers/mmc/core/block.c  |    6 +++++-
 drivers/mmc/core/card.h   |    6 ++++++
 drivers/mmc/core/quirks.h |    6 ++++++
 include/linux/mmc/card.h  |    1 +
 4 files changed, 18 insertions(+), 1 deletion(-)

drivers/mmc/core/block.c +5 -1

@@ -1140,8 +1140,12 @@ static void mmc_blk_issue_discard_rq(str
 {
 	struct mmc_blk_data *md = mq->blkdata;
 	struct mmc_card *card = md->queue.card;
+	unsigned int arg = card->erase_arg;
 
-	mmc_blk_issue_erase_rq(mq, req, MMC_BLK_DISCARD, card->erase_arg);
+	if (mmc_card_broken_sd_discard(card))
+		arg = SD_ERASE_ARG;
+
+	mmc_blk_issue_erase_rq(mq, req, MMC_BLK_DISCARD, arg);
 }
 
 static void mmc_blk_issue_secdiscard_rq(struct mmc_queue *mq,

drivers/mmc/core/card.h +6 -0

@@ -73,6 +73,7 @@ struct mmc_fixup {
 #define EXT_CSD_REV_ANY (-1u)
 
 #define CID_MANFID_SANDISK      0x2
+#define CID_MANFID_SANDISK_SD   0x3
 #define CID_MANFID_ATP          0x9
 #define CID_MANFID_TOSHIBA      0x11
 #define CID_MANFID_MICRON       0x13

@@ -258,4 +259,9 @@ static inline int mmc_card_broken_hpi(co
 	return c->quirks & MMC_QUIRK_BROKEN_HPI;
 }
 
+static inline int mmc_card_broken_sd_discard(const struct mmc_card *c)
+{
+	return c->quirks & MMC_QUIRK_BROKEN_SD_DISCARD;
+}
+
 #endif

drivers/mmc/core/quirks.h +6 -0

@@ -100,6 +100,12 @@ static const struct mmc_fixup __maybe_un
 	MMC_FIXUP("V10016", CID_MANFID_KINGSTON, CID_OEMID_ANY, add_quirk_mmc,
 		  MMC_QUIRK_TRIM_BROKEN),
 
+	/*
+	 * Some SD cards reports discard support while they don't
+	 */
+	MMC_FIXUP(CID_NAME_ANY, CID_MANFID_SANDISK_SD, 0x5344, add_quirk_sd,
+		  MMC_QUIRK_BROKEN_SD_DISCARD),
+
 	END_FIXUP
 };

include/linux/mmc/card.h +1 -0

@@ -293,6 +293,7 @@ struct mmc_card {
 #define MMC_QUIRK_BROKEN_IRQ_POLLING	(1<<11)	/* Polling SDIO_CCCR_INTx could create a fake interrupt */
 #define MMC_QUIRK_TRIM_BROKEN	(1<<12)		/* Skip trim */
 #define MMC_QUIRK_BROKEN_HPI	(1<<13)		/* Disable broken HPI support */
+#define MMC_QUIRK_BROKEN_SD_DISCARD	(1<<14)	/* Disable broken SD discard support */
 
 	bool			reenable_cmdq;	/* Re-enable Command Queue */

Greg Kroah-Hartman

author maintainer

2022-10-19 08:46 UTC #33 lore raw

PATCH 33/862 can: kvaser_usb: Fix use of uninitialized completion

From: Anssi Hannula <[email protected]>

commit cd7f30e174d09a02ca2afa5ef093fb0f0352e0d8 upstream.

flush_comp is initialized when CMD_FLUSH_QUEUE is sent to the device and completed when the device sends CMD_FLUSH_QUEUE_RESP.

This causes completion of uninitialized completion if the device sends CMD_FLUSH_QUEUE_RESP before CMD_FLUSH_QUEUE is ever sent (e.g. as a response to a flush by a previously bound driver, or a misbehaving device).

Fix that by initializing flush_comp in kvaser_usb_init_one() like the other completions.

This issue is only triggerable after RX URBs have been set up, i.e. the interface has been opened at least once.

Fixes aec5fb2268b7 ("can: kvaser_usb: Add support for Kvaser USB hydra family")

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

Signed-off-by Marc Kleine-Budde <[email protected]>

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

---
 drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c  |    1 +
 drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c |    2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c +1 -0

@@ -729,6 +729,7 @@ static int kvaser_usb_init_one(struct kv
 	init_usb_anchor(&priv->tx_submitted);
 	init_completion(&priv->start_comp);
 	init_completion(&priv->stop_comp);
+	init_completion(&priv->flush_comp);
 	priv->can.ctrlmode_supported = 0;
 
 	priv->dev = dev;

drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c +1 -1

@@ -1916,7 +1916,7 @@ static int kvaser_usb_hydra_flush_queue(
 {
 	int err;
 
-	init_completion(&priv->flush_comp);
+	reinit_completion(&priv->flush_comp);
 
 	err = kvaser_usb_hydra_send_simple_cmd(priv->dev, CMD_FLUSH_QUEUE,
 					       priv->channel);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:45 UTC #34 lore raw

PATCH 34/862 can: kvaser_usb_leaf: Fix overread with an invalid command

From: Anssi Hannula <[email protected]>

commit 1499ecaea9d2ba68d5e18d80573b4561a8dc4ee7 upstream.

For command events read from the device, kvaser_usb_leaf_read_bulk_callback() verifies that cmd->len does not exceed the size of the received data, but the actual kvaser_cmd handlers will happily read any kvaser_cmd fields without checking for cmd->len.

This can cause an overread if the last cmd in the buffer is shorter than expected for the command type (with cmd->len showing the actual short size).

Maximum overread seems to be 22 bytes (CMD_LEAF_LOG_MESSAGE), some of which are delivered to userspace as-is.

Fix that by verifying the length of command before handling it.

This issue can only occur after RX URBs have been set up, i.e. the interface has been opened at least once.

Fixes 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")

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

Signed-off-by Marc Kleine-Budde <[email protected]>

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

---
 drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c |   75 +++++++++++++++++++++++
 1 file changed, 75 insertions(+)

drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c +75 -0

@@ -310,6 +310,38 @@ struct kvaser_cmd {
 	} u;
 } __packed;
 
+#define CMD_SIZE_ANY 0xff
+#define kvaser_fsize(field) sizeof_field(struct kvaser_cmd, field)
+
+static const u8 kvaser_usb_leaf_cmd_sizes_leaf[] = {
+	[CMD_START_CHIP_REPLY]		= kvaser_fsize(u.simple),
+	[CMD_STOP_CHIP_REPLY]		= kvaser_fsize(u.simple),
+	[CMD_GET_CARD_INFO_REPLY]	= kvaser_fsize(u.cardinfo),
+	[CMD_TX_ACKNOWLEDGE]		= kvaser_fsize(u.tx_acknowledge_header),
+	[CMD_GET_SOFTWARE_INFO_REPLY]	= kvaser_fsize(u.leaf.softinfo),
+	[CMD_RX_STD_MESSAGE]		= kvaser_fsize(u.leaf.rx_can),
+	[CMD_RX_EXT_MESSAGE]		= kvaser_fsize(u.leaf.rx_can),
+	[CMD_LEAF_LOG_MESSAGE]		= kvaser_fsize(u.leaf.log_message),
+	[CMD_CHIP_STATE_EVENT]		= kvaser_fsize(u.leaf.chip_state_event),
+	[CMD_CAN_ERROR_EVENT]		= kvaser_fsize(u.leaf.error_event),
+	/* ignored events: */
+	[CMD_FLUSH_QUEUE_REPLY]		= CMD_SIZE_ANY,
+};
+
+static const u8 kvaser_usb_leaf_cmd_sizes_usbcan[] = {
+	[CMD_START_CHIP_REPLY]		= kvaser_fsize(u.simple),
+	[CMD_STOP_CHIP_REPLY]		= kvaser_fsize(u.simple),
+	[CMD_GET_CARD_INFO_REPLY]	= kvaser_fsize(u.cardinfo),
+	[CMD_TX_ACKNOWLEDGE]		= kvaser_fsize(u.tx_acknowledge_header),
+	[CMD_GET_SOFTWARE_INFO_REPLY]	= kvaser_fsize(u.usbcan.softinfo),
+	[CMD_RX_STD_MESSAGE]		= kvaser_fsize(u.usbcan.rx_can),
+	[CMD_RX_EXT_MESSAGE]		= kvaser_fsize(u.usbcan.rx_can),
+	[CMD_CHIP_STATE_EVENT]		= kvaser_fsize(u.usbcan.chip_state_event),
+	[CMD_CAN_ERROR_EVENT]		= kvaser_fsize(u.usbcan.error_event),
+	/* ignored events: */
+	[CMD_USBCAN_CLOCK_OVERFLOW_EVENT] = CMD_SIZE_ANY,
+};
+
 /* Summary of a kvaser error event, for a unified Leaf/Usbcan error
  * handling. Some discrepancies between the two families exist:
  *

@@ -397,6 +429,43 @@ static const struct kvaser_usb_dev_cfg k
 	.bittiming_const = &kvaser_usb_flexc_bittiming_const,
 };
 
+static int kvaser_usb_leaf_verify_size(const struct kvaser_usb *dev,
+				       const struct kvaser_cmd *cmd)
+{
+	/* buffer size >= cmd->len ensured by caller */
+	u8 min_size = 0;
+
+	switch (dev->driver_info->family) {
+	case KVASER_LEAF:
+		if (cmd->id < ARRAY_SIZE(kvaser_usb_leaf_cmd_sizes_leaf))
+			min_size = kvaser_usb_leaf_cmd_sizes_leaf[cmd->id];
+		break;
+	case KVASER_USBCAN:
+		if (cmd->id < ARRAY_SIZE(kvaser_usb_leaf_cmd_sizes_usbcan))
+			min_size = kvaser_usb_leaf_cmd_sizes_usbcan[cmd->id];
+		break;
+	}
+
+	if (min_size == CMD_SIZE_ANY)
+		return 0;
+
+	if (min_size) {
+		min_size += CMD_HEADER_LEN;
+		if (cmd->len >= min_size)
+			return 0;
+
+		dev_err_ratelimited(&dev->intf->dev,
+				    "Received command %u too short (size %u, needed %u)",
+				    cmd->id, cmd->len, min_size);
+		return -EIO;
+	}
+
+	dev_warn_ratelimited(&dev->intf->dev,
+			     "Unhandled command (%d, size %d)\n",
+			     cmd->id, cmd->len);
+	return -EINVAL;
+}
+
 static void *
 kvaser_usb_leaf_frame_to_cmd(const struct kvaser_usb_net_priv *priv,
 			     const struct sk_buff *skb, int *cmd_len,

@@ -502,6 +571,9 @@ static int kvaser_usb_leaf_wait_cmd(cons
 end:
 	kfree(buf);
 
+	if (err == 0)
+		err = kvaser_usb_leaf_verify_size(dev, cmd);
+
 	return err;
 }

@@ -1133,6 +1205,9 @@ static void kvaser_usb_leaf_stop_chip_re
 static void kvaser_usb_leaf_handle_command(const struct kvaser_usb *dev,
 					   const struct kvaser_cmd *cmd)
 {
+	if (kvaser_usb_leaf_verify_size(dev, cmd) < 0)
+		return;
+
 	switch (cmd->id) {
 	case CMD_START_CHIP_REPLY:
 		kvaser_usb_leaf_start_chip_reply(dev, cmd);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:45 UTC #35 lore raw

PATCH 35/862 can: kvaser_usb_leaf: Fix TX queue out of sync after restart

From: Anssi Hannula <[email protected]>

commit 455561fb618fde40558776b5b8435f9420f335db upstream.

The TX queue seems to be implicitly flushed by the hardware during bus-off or bus-off recovery, but the driver does not reset the TX bookkeeping.

Despite not resetting TX bookkeeping the driver still re-enables TX queue unconditionally, leading to "cannot find free context" / NETDEV_TX_BUSY errors if the TX queue was full at bus-off time.

Fix that by resetting TX bookkeeping on CAN restart.

Tested with 0bfd:0124 Kvaser Mini PCI Express 2xHS FW 4.18.778.

Fixes 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")

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

Signed-off-by Marc Kleine-Budde <[email protected]>

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

---
 drivers/net/can/usb/kvaser_usb/kvaser_usb.h      |    2 ++
 drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c |    2 +-
 drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c |    2 ++
 3 files changed, 5 insertions(+), 1 deletion(-)

drivers/net/can/usb/kvaser_usb/kvaser_usb.h +2 -0

@@ -178,6 +178,8 @@ struct kvaser_usb_dev_cfg {
 extern const struct kvaser_usb_dev_ops kvaser_usb_hydra_dev_ops;
 extern const struct kvaser_usb_dev_ops kvaser_usb_leaf_dev_ops;
 
+void kvaser_usb_unlink_tx_urbs(struct kvaser_usb_net_priv *priv);
+
 int kvaser_usb_recv_cmd(const struct kvaser_usb *dev, void *cmd, int len,
 			int *actual_len);

drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c +1 -1

@@ -477,7 +477,7 @@ static void kvaser_usb_reset_tx_urb_cont
 /* This method might sleep. Do not call it in the atomic context
  * of URB completions.
  */
-static void kvaser_usb_unlink_tx_urbs(struct kvaser_usb_net_priv *priv)
+void kvaser_usb_unlink_tx_urbs(struct kvaser_usb_net_priv *priv)
 {
 	usb_kill_anchored_urbs(&priv->tx_submitted);
 	kvaser_usb_reset_tx_urb_contexts(priv);

drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c +2 -0

@@ -1426,6 +1426,8 @@ static int kvaser_usb_leaf_set_mode(stru
 
 	switch (mode) {
 	case CAN_MODE_START:
+		kvaser_usb_unlink_tx_urbs(priv);
+
 		err = kvaser_usb_leaf_simple_cmd_async(priv, CMD_START_CHIP);
 		if (err)
 			return err;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:45 UTC #36 lore raw

PATCH 36/862 can: kvaser_usb_leaf: Fix CAN state after restart

From: Anssi Hannula <[email protected]>

commit 0be1a655fe68c8e6dcadbcbddb69cf2fb29881f5 upstream.

can_restart() expects CMD_START_CHIP to set the error state to ERROR_ACTIVE as it calls netif_carrier_on() immediately afterwards.

Otherwise the user may immediately trigger restart again and hit a BUG_ON() in can_restart().

Fix kvaser_usb_leaf set_mode(CMD_START_CHIP) to set the expected state.

Fixes 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")

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

Signed-off-by Marc Kleine-Budde <[email protected]>

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

---
 drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c +2 -0

@@ -1431,6 +1431,8 @@ static int kvaser_usb_leaf_set_mode(stru
 		err = kvaser_usb_leaf_simple_cmd_async(priv, CMD_START_CHIP);
 		if (err)
 			return err;
+
+		priv->can.state = CAN_STATE_ERROR_ACTIVE;
 		break;
 	default:
 		return -EOPNOTSUPP;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:46 UTC #37 lore raw

PATCH 37/862 mmc: renesas_sdhi: Fix rounding errors

From: Biju Das <[email protected]>

commit f0c00454bf78975925eccc9737faaa4d4951edbf upstream.

Due to clk rounding errors on RZ/G2L platforms, it selects a clock source with a lower clock rate compared to a higher one.
For eg: The rounding error (533333333 Hz / 4 * 4 = 533333332 Hz < 5333333 33 Hz) selects a clk source of 400 MHz instead of 533.333333 MHz.

This patch fixes this issue by adding a margin of (1/1024) higher to the clock rate.

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

Reviewed-by Geert Uytterhoeven <[email protected]>

Tested-by Geert Uytterhoeven <[email protected]>

Reviewed-by Wolfram Sang <[email protected]>

Tested-by Wolfram Sang <[email protected]>

Fixes bb6d3fa98a41 ("clk: renesas: rcar-gen3: Switch to new SD clock handling")

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

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

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

---
 drivers/mmc/host/renesas_sdhi_core.c |   21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

drivers/mmc/host/renesas_sdhi_core.c +18 -3

@@ -128,6 +128,7 @@ static unsigned int renesas_sdhi_clk_upd
 	struct clk *ref_clk = priv->clk;
 	unsigned int freq, diff, best_freq = 0, diff_min = ~0;
 	unsigned int new_clock, clkh_shift = 0;
+	unsigned int new_upper_limit;
 	int i;
 
 	/*

@@ -153,13 +154,20 @@ static unsigned int renesas_sdhi_clk_upd
 	 * greater than, new_clock.  As we can divide by 1 << i for
 	 * any i in [0, 9] we want the input clock to be as close as
 	 * possible, but no greater than, new_clock << i.
+	 *
+	 * Add an upper limit of 1/1024 rate higher to the clock rate to fix
+	 * clk rate jumping to lower rate due to rounding error (eg: RZ/G2L has
+	 * 3 clk sources 533.333333 MHz, 400 MHz and 266.666666 MHz. The request
+	 * for 533.333333 MHz will selects a slower 400 MHz due to rounding
+	 * error (533333333 Hz / 4 * 4 = 533333332 Hz < 533333333 Hz)).
 	 */
 	for (i = min(9, ilog2(UINT_MAX / new_clock)); i >= 0; i--) {
 		freq = clk_round_rate(ref_clk, new_clock << i);
-		if (freq > (new_clock << i)) {
+		new_upper_limit = (new_clock << i) + ((new_clock << i) >> 10);
+		if (freq > new_upper_limit) {
 			/* Too fast; look for a slightly slower option */
 			freq = clk_round_rate(ref_clk, (new_clock << i) / 4 * 3);
-			if (freq > (new_clock << i))
+			if (freq > new_upper_limit)
 				continue;
 		}

@@ -181,6 +189,7 @@ static unsigned int renesas_sdhi_clk_upd
 static void renesas_sdhi_set_clock(struct tmio_mmc_host *host,
 				   unsigned int new_clock)
 {
+	unsigned int clk_margin;
 	u32 clk = 0, clock;
 
 	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &

@@ -194,7 +203,13 @@ static void renesas_sdhi_set_clock(struc
 	host->mmc->actual_clock = renesas_sdhi_clk_update(host, new_clock);
 	clock = host->mmc->actual_clock / 512;
 
-	for (clk = 0x80000080; new_clock >= (clock << 1); clk >>= 1)
+	/*
+	 * Add a margin of 1/1024 rate higher to the clock rate in order
+	 * to avoid clk variable setting a value of 0 due to the margin
+	 * provided for actual_clock in renesas_sdhi_clk_update().
+	 */
+	clk_margin = new_clock >> 10;
+	for (clk = 0x80000080; new_clock + clk_margin >= (clock << 1); clk >>= 1)
 		clock <<= 1;
 
 	/* 1/1 clock is option */

Greg Kroah-Hartman

author maintainer

2022-10-19 08:40 UTC #38 lore raw

PATCH 38/862 mmc: sdhci-tegra: Use actual clock rate for SW tuning correction

From: Prathamesh Shete <[email protected]>

commit b78870e7f41534cc719c295d1f8809aca93aeeab upstream.

Ensure tegra_host member "curr_clk_rate" holds the actual clock rate instead of requested clock rate for proper use during tuning correction algorithm. Actual clk rate may not be the same as the requested clk frequency depending on the parent clock source set. Tuning correction algorithm depends on certain parameters which are sensitive to current clk rate. If the host clk is selected instead of the actual clock rate, tuning correction algorithm may end up applying invalid correction, which could result in errors

Fixes ea8fc5953e8b ("mmc: tegra: update hw tuning process")

Signed-off-by Aniruddha TVS Rao <[email protected]>

Signed-off-by Prathamesh Shete <[email protected]>

Acked-by Adrian Hunter <[email protected]>

Acked-by Thierry Reding <[email protected]>

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

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

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

---
 drivers/mmc/host/sdhci-tegra.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mmc/host/sdhci-tegra.c +1 -1

@@ -773,7 +773,7 @@ static void tegra_sdhci_set_clock(struct
 		dev_err(dev, "failed to set clk rate to %luHz: %d\n",
 			host_clk, err);
 
-	tegra_host->curr_clk_rate = host_clk;
+	tegra_host->curr_clk_rate = clk_get_rate(pltfm_host->clk);
 	if (tegra_host->ddr_signaling)
 		host->max_clk = host_clk;
 	else

Greg Kroah-Hartman

author maintainer

2022-10-19 08:41 UTC #39 lore raw

PATCH 39/862 mmc: sdhci-sprd: Fix minimum clock limit

From: Wenchao Chen <[email protected]>

commit 6e141772e6465f937458b35ddcfd0a981b6f5280 upstream.

The Spreadtrum controller supports 100KHz minimal clock rate, which means that the current value 400KHz is wrong.

Unfortunately this has also lead to fail to initialize some cards, which are allowed to require 100KHz to work. So, let's fix the problem by changing the minimal supported clock rate to 100KHz.

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

Acked-by Adrian Hunter <[email protected]>

Fixes fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller")

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

[Ulf: Clarified to commit-message]

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

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

---
 drivers/mmc/host/sdhci-sprd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mmc/host/sdhci-sprd.c +1 -1

@@ -309,7 +309,7 @@ static unsigned int sdhci_sprd_get_max_c
 
 static unsigned int sdhci_sprd_get_min_clock(struct sdhci_host *host)
 {
-	return 400000;
+	return 100000;
 }
 
 static void sdhci_sprd_set_uhs_signaling(struct sdhci_host *host,

Greg Kroah-Hartman

author maintainer

2022-10-19 08:42 UTC #40 lore raw

PATCH 40/862 i2c: designware: Fix handling of real but unexpected device interrupts

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

From: Jarkko Nikula <[email protected]>

commit 301c8f5c32c8fb79c67539bc23972dc3ef48024c upstream.

Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2c_dw_xfer_msg() when system resumes from S3 sleep state ("deep").

I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made following notes:

- Issue happens when resuming from S3 but not when resuming from "s2idle"
- PCI device 00:15.0 == i2c_designware.0 is already in D0 state when system enters into pci_pm_resume_noirq() while all other i2c_designware PCI devices are in D3. Devices were runtime suspended and in D3 prior entering into suspend
- Interrupt comes after pci_pm_resume_noirq() when device interrupts are re-enabled
- According to register dump the interrupt really comes from the i2c_designware.0. Controller is enabled, I2C target address register points to a one detectable I2C device address 0x60 and the DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and TX_EMPTY bits are set indicating completed I2C transaction.

My guess is that the firmware uses this controller to communicate with an on-board I2C device during resume but does not disable the controller before giving control to an operating system.

I was told the UEFI update fixes this but never the less it revealed the driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device is supposed to be idle and state variables are not set (especially the dev->msgs pointer which may point to NULL or stale old data).

Introduce a new software status flag STATUS_ACTIVE indicating when the controller is active in driver point of view. Now treat all interrupts that occur when is not set as unexpected and mask all interrupts from the controller.

Fixes c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs")

Reported-by Samuel Clark <[email protected]>

Cc [email protected] # v5.12+

Signed-off-by Jarkko Nikula <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

Signed-off-by Wolfram Sang <[email protected]>

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

---
 drivers/i2c/busses/i2c-designware-core.h   |    7 +++++--
 drivers/i2c/busses/i2c-designware-master.c |   13 +++++++++++++
 2 files changed, 18 insertions(+), 2 deletions(-)

drivers/i2c/busses/i2c-designware-core.h +5 -2

@@ -126,8 +126,9 @@
  * status codes
  */
 #define STATUS_IDLE			0x0
-#define STATUS_WRITE_IN_PROGRESS	0x1
-#define STATUS_READ_IN_PROGRESS		0x2
+#define STATUS_ACTIVE			0x1
+#define STATUS_WRITE_IN_PROGRESS	0x2
+#define STATUS_READ_IN_PROGRESS		0x4
 
 /*
  * operation modes

@@ -334,12 +335,14 @@ void i2c_dw_disable_int(struct dw_i2c_de
 
 static inline void __i2c_dw_enable(struct dw_i2c_dev *dev)
 {
+	dev->status |= STATUS_ACTIVE;
 	regmap_write(dev->map, DW_IC_ENABLE, 1);
 }
 
 static inline void __i2c_dw_disable_nowait(struct dw_i2c_dev *dev)
 {
 	regmap_write(dev->map, DW_IC_ENABLE, 0);
+	dev->status &= ~STATUS_ACTIVE;
 }
 
 void __i2c_dw_disable(struct dw_i2c_dev *dev);

drivers/i2c/busses/i2c-designware-master.c +13 -0

@@ -716,6 +716,19 @@ static int i2c_dw_irq_handler_master(str
 	u32 stat;
 
 	stat = i2c_dw_read_clear_intrbits(dev);
+
+	if (!(dev->status & STATUS_ACTIVE)) {
+		/*
+		 * Unexpected interrupt in driver point of view. State
+		 * variables are either unset or stale so acknowledge and
+		 * disable interrupts for suppressing further interrupts if
+		 * interrupt really came from this HW (E.g. firmware has left
+		 * the HW active).
+		 */
+		regmap_write(dev->map, DW_IC_INTR_MASK, 0);
+		return 0;
+	}
+
 	if (stat & DW_IC_INTR_TX_ABRT) {
 		dev->cmd_err |= DW_IC_ERR_TX_ABRT;
 		dev->status = STATUS_IDLE;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:42 UTC #41 lore raw

PATCH 41/862 fs: dlm: fix race between test_bit() and queue_work()

From: Alexander Aring <[email protected]>

commit eef6ec9bf390e836a6c4029f3620fe49528aa1fe upstream.

This patch fixes a race by using ls_cb_mutex around the bit operations and conditional code blocks for LSFL_CB_DELAY.

The function dlm_callback_stop() expects to stop all callbacks and flush all currently queued onces. The set_bit() is not enough because there can still be queue_work() after the workqueue was flushed. To avoid queue_work() after set_bit(), surround both by ls_cb_mutex.

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

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

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

---
 fs/dlm/ast.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

fs/dlm/ast.c +4 -2

@@ -200,13 +200,13 @@ void dlm_add_cb(struct dlm_lkb *lkb, uin
 	if (!prev_seq) {
 		kref_get(&lkb->lkb_ref);
 
+		mutex_lock(&ls->ls_cb_mutex);
 		if (test_bit(LSFL_CB_DELAY, &ls->ls_flags)) {
-			mutex_lock(&ls->ls_cb_mutex);
 			list_add(&lkb->lkb_cb_list, &ls->ls_cb_delay);
-			mutex_unlock(&ls->ls_cb_mutex);
 		} else {
 			queue_work(ls->ls_callback_wq, &lkb->lkb_cb_work);
 		}
+		mutex_unlock(&ls->ls_cb_mutex);
 	}
  out:
 	mutex_unlock(&lkb->lkb_cb_mutex);

@@ -288,7 +288,9 @@ void dlm_callback_stop(struct dlm_ls *ls
 
 void dlm_callback_suspend(struct dlm_ls *ls)
 {
+	mutex_lock(&ls->ls_cb_mutex);
 	set_bit(LSFL_CB_DELAY, &ls->ls_flags);
+	mutex_unlock(&ls->ls_cb_mutex);
 
 	if (ls->ls_callback_wq)
 		flush_workqueue(ls->ls_callback_wq);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:41 UTC #42 lore raw

PATCH 42/862 fs: dlm: handle -EBUSY first in lock arg validation

From: Alexander Aring <[email protected]>

commit 44637ca41d551d409a481117b07fa209b330fca9 upstream.

During lock arg validation, first check for -EBUSY cases, then for -EINVAL cases. The -EINVAL checks look at lkb state variables which are not stable when an lkb is busy and would cause an -EBUSY result, e.g. lkb->lkb_grmode.

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

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

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

---
 fs/dlm/lock.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

fs/dlm/lock.c +9 -9

@@ -2864,17 +2864,9 @@ static int set_unlock_args(uint32_t flag
 static int validate_lock_args(struct dlm_ls *ls, struct dlm_lkb *lkb,
 			      struct dlm_args *args)
 {
-	int rv = -EINVAL;
+	int rv = -EBUSY;
 
 	if (args->flags & DLM_LKF_CONVERT) {
-		if (lkb->lkb_flags & DLM_IFL_MSTCPY)
-			goto out;
-
-		if (args->flags & DLM_LKF_QUECVT &&
-		    !__quecvt_compat_matrix[lkb->lkb_grmode+1][args->mode+1])
-			goto out;
-
-		rv = -EBUSY;
 		if (lkb->lkb_status != DLM_LKSTS_GRANTED)
 			goto out;

@@ -2884,6 +2876,14 @@ static int validate_lock_args(struct dlm
 
 		if (is_overlap(lkb))
 			goto out;
+
+		rv = -EINVAL;
+		if (lkb->lkb_flags & DLM_IFL_MSTCPY)
+			goto out;
+
+		if (args->flags & DLM_LKF_QUECVT &&
+		    !__quecvt_compat_matrix[lkb->lkb_grmode+1][args->mode+1])
+			goto out;
 	}
 
 	lkb->lkb_exflags = args->flags;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:42 UTC #43 lore raw

PATCH 43/862 fs: dlm: fix invalid derefence of sb_lvbptr

From: Alexander Aring <[email protected]>

commit 7175e131ebba47afef47e6ac4d5bab474d1e6e49 upstream.

I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example:

[  102.749317] BUG: unable to handle page fault for address: 00000000deadbeef
[  102.749320] #PF: supervisor read access in kernel mode
[  102.749323] #PF: error_code(0x0000) - not-present page
[  102.749325] PGD 0 P4D 0
[  102.749332] Oops: 0000 [#1] PREEMPT SMP PTI
[  102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G        W         5.19.0-rc3+ #1565
[  102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014
[  102.749344] RIP: 0010:memcpy_erms+0x6/0x10
[  102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe
[  102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202
[  102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040
[  102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070
[  102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001
[  102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70
[  102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001
[  102.749368] FS:  0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000
[  102.749372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0
[  102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  102.749379] PKRU: 55555554
[  102.749381] Call Trace:
[  102.749382]  <TASK>
[  102.749383]  ? send_args+0xb2/0xd0
[  102.749389]  send_common+0xb7/0xd0
[  102.749395]  _unlock_lock+0x2c/0x90
[  102.749400]  unlock_lock.isra.56+0x62/0xa0
[  102.749405]  dlm_unlock+0x21e/0x330
[  102.749411]  ? lock_torture_stats+0x80/0x80 [dlm_locktorture]
[  102.749416]  torture_unlock+0x5a/0x90 [dlm_locktorture]
[  102.749419]  ? preempt_count_sub+0xba/0x100
[  102.749427]  lock_torture_writer+0xbd/0x150 [dlm_locktorture]
[  102.786186]  kthread+0x10a/0x130
[  102.786581]  ? kthread_complete_and_exit+0x20/0x20
[  102.787156]  ret_from_fork+0x22/0x30
[  102.787588]  </TASK>
[  102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw
[  102.792536] CR2: 00000000deadbeef
[  102.792930] ---[ end trace 0000000000000000 ]---

This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue.

I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour.

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

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

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

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

fs/dlm/lock.c +1 -1

@@ -3623,7 +3623,7 @@ static void send_args(struct dlm_rsb *r,
 	case cpu_to_le32(DLM_MSG_REQUEST_REPLY):
 	case cpu_to_le32(DLM_MSG_CONVERT_REPLY):
 	case cpu_to_le32(DLM_MSG_GRANT):
-		if (!lkb->lkb_lvbptr)
+		if (!lkb->lkb_lvbptr || !(lkb->lkb_exflags & DLM_LKF_VALBLK))
 			break;
 		memcpy(ms->m_extra, lkb->lkb_lvbptr, r->res_ls->ls_lvblen);
 		break;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:42 UTC #44 lore raw

PATCH 44/862 btf: Export bpf_dynptr definition

From: Roberto Sassu <[email protected]>

commit 00f146413ccb6c84308e559281449755c83f54c5 upstream.

eBPF dynamic pointers is a new feature recently added to upstream. It binds together a pointer to a memory area and its size. The internal kernel structure bpf_dynptr_kern is not accessible by eBPF programs in user space. They instead see bpf_dynptr, which is then translated to the internal kernel structure by the eBPF verifier.

The problem is that it is not possible to include at the same time the uapi include linux/bpf.h and the vmlinux BTF vmlinux.h, as they both contain the definition of some structures/enums. The compiler complains saying that the structures/enums are redefined.

As bpf_dynptr is defined in the uapi include linux/bpf.h, this makes it impossible to include vmlinux.h. However, in some cases, e.g. when using kfuncs, vmlinux.h has to be included. The only option until now was to include vmlinux.h and add the definition of bpf_dynptr directly in the eBPF program source code from linux/bpf.h.

Solve the problem by using the same approach as for bpf_timer (which also follows the same scheme with the _kern suffix for the internal kernel structure).

Add the following line in one of the dynamic pointer helpers, bpf_dynptr_from_mem():

BTF_TYPE_EMIT(struct bpf_dynptr);

Cc Joanne Koong <[email protected]>

Fixes 97e03f521050c ("bpf: Add verifier support for dynptrs")

Signed-off-by Roberto Sassu <[email protected]>

Acked-by Yonghong Song <[email protected]>

Tested-by KP Singh <[email protected]>

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

Signed-off-by Alexei Starovoitov <[email protected]>

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

---
 kernel/bpf/helpers.c |    2 ++
 1 file changed, 2 insertions(+)

kernel/bpf/helpers.c +2 -0

@@ -1468,6 +1468,8 @@ BPF_CALL_4(bpf_dynptr_from_mem, void *,
 {
 	int err;
 
+	BTF_TYPE_EMIT(struct bpf_dynptr);
+
 	err = bpf_dynptr_check_size(size);
 	if (err)
 		goto error;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:42 UTC #45 lore raw

PATCH 45/862 mbcache: Avoid nesting of cache->c_list_lock under bit locks

From: Jan Kara <[email protected]>

commit 5fc4cbd9fde5d4630494fd6ffc884148fb618087 upstream.

Commit 307af6c87937 ("mbcache: automatically delete entries from cache on freeing") started nesting cache->c_list_lock under the bit locks protecting hash buckets of the mbcache hash table in mb_cache_entry_create(). This causes problems for real-time kernels because there spinlocks are sleeping locks while bitlocks stay atomic. Luckily the nesting is easy to avoid by holding entry reference until the entry is added to the LRU list. This makes sure we cannot race with entry deletion.

Fixes 307af6c87937 ("mbcache: automatically delete entries from cache on freeing")

Reported-by Mike Galbraith <[email protected]>

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 | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

fs/mbcache.c +10 -7

index 47ccfcbe0a22..e272ad738faf 100644
@@ -90,8 +90,14 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
 		return -ENOMEM;
 
 	INIT_LIST_HEAD(&entry->e_list);
-	/* Initial hash reference */
-	atomic_set(&entry->e_refcnt, 1);
+	/*
+	 * We create entry with two references. One reference is kept by the
+	 * hash table, the other reference is used to protect us from
+	 * mb_cache_entry_delete_or_get() until the entry is fully setup. This
+	 * avoids nesting of cache->c_list_lock into hash table bit locks which
+	 * is problematic for RT.
+	 */
+	atomic_set(&entry->e_refcnt, 2);
 	entry->e_key = key;
 	entry->e_value = value;
 	entry->e_reusable = reusable;

@@ -106,15 +112,12 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
 		}
 	}
 	hlist_bl_add_head(&entry->e_hash_list, head);
-	/*
-	 * Add entry to LRU list before it can be found by
-	 * mb_cache_entry_delete() to avoid races
-	 */
+	hlist_bl_unlock(head);
 	spin_lock(&cache->c_list_lock);
 	list_add_tail(&entry->e_list, &cache->c_list);
 	cache->c_entry_count++;
 	spin_unlock(&cache->c_list_lock);
-	hlist_bl_unlock(head);
+	mb_cache_entry_put(cache, entry);
 
 	return 0;
 }

Signature · 1 line

2.38.0

Greg Kroah-Hartman

author maintainer

2022-10-19 08:42 UTC #46 lore raw

PATCH 46/862 HID: multitouch: Add memory barriers

From: Andri Yngvason <[email protected]>

commit be6e2b5734a425941fcdcdbd2a9337be498ce2cf upstream.

This fixes broken atomic checks which cause a race between the release-timer and processing of hid input.

I noticed that contacts were sometimes sticking, even with the "sticky fingers" quirk enabled. This fixes that problem.

Fixes 9609827458c3 ("HID: multitouch: optimize the sticky fingers timer")

Signed-off-by Andri Yngvason <[email protected]>

Signed-off-by Benjamin Tissoires <[email protected]>

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

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

---
 drivers/hid/hid-multitouch.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/hid/hid-multitouch.c +4 -4

@@ -1186,7 +1186,7 @@ static void mt_touch_report(struct hid_d
 	int contact_count = -1;
 
 	/* sticky fingers release in progress, abort */
-	if (test_and_set_bit(MT_IO_FLAGS_RUNNING, &td->mt_io_flags))
+	if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags))
 		return;
 
 	scantime = *app->scantime;

@@ -1267,7 +1267,7 @@ static void mt_touch_report(struct hid_d
 			del_timer(&td->release_timer);
 	}
 
-	clear_bit(MT_IO_FLAGS_RUNNING, &td->mt_io_flags);
+	clear_bit_unlock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags);
 }
 
 static int mt_touch_input_configured(struct hid_device *hdev,

@@ -1699,11 +1699,11 @@ static void mt_expired_timeout(struct ti
 	 * An input report came in just before we release the sticky fingers,
 	 * it will take care of the sticky fingers.
 	 */
-	if (test_and_set_bit(MT_IO_FLAGS_RUNNING, &td->mt_io_flags))
+	if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags))
 		return;
 	if (test_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags))
 		mt_release_contacts(hdev);
-	clear_bit(MT_IO_FLAGS_RUNNING, &td->mt_io_flags);
+	clear_bit_unlock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags);
 }
 
 static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)

Greg Kroah-Hartman

author maintainer

2022-10-19 08:42 UTC #47 lore raw

PATCH 47/862 quota: Check next/prev free block number after reading from quota file

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

From: Zhihao Cheng <[email protected]>

commit 6c8ea8b8cd4722efd419f91ca46a2dc81b7d89a3 upstream.

Following process:
Init: v2_read_file_info: <3> dqi_free_blk 0 dqi_free_entry 5 dqi_blks 6

Step 1. chown bin f_a -> dquot_acquire -> v2_write_dquot:
qtree_write_dquot
do_insert_tree
find_free_dqentry
get_free_dqblk
write_blk(info->dqi_blocks) // info->dqi_blocks = 6, failure. The
content in physical block (corresponding to blk 6) is random.

Step 2. chown root f_a -> dquot_transfer -> dqput_all -> dqput ->

         ext4_release_dquot -> v2_release_dquot -> qtree_delete_dquot:
  dquot_release
   remove_tree
    free_dqentry
     put_free_dqblk(6)
      info->dqi_free_blk = blk    // info->dqi_free_blk = 6

Step 3. drop cache (buffer head for block 6 is released)

Step 4. chown bin f_b -> dquot_acquire -> commit_dqblk -> v2_write_dquot:
qtree_write_dquot
do_insert_tree
find_free_dqentry
get_free_dqblk
dh = (struct qt_disk_dqdbheader *)buf
blk = info->dqi_free_blk // 6
ret = read_blk(info, blk, buf) // The content of buf is random info->dqi_free_blk = le32_to_cpu(dh->dqdh_next_free) // random blk

Step 5. chown bin f_c -> notify_change -> ext4_setattr -> dquot_transfer:
dquot = dqget -> acquire_dquot -> ext4_acquire_dquot -> dquot_acquire ->

          commit_dqblk -> v2_write_dquot -> dq_insert_tree:

do_insert_tree
find_free_dqentry
get_free_dqblk
blk = info->dqi_free_blk // If blk < 0 and blk is not an error
code, it will be returned as dquot

transfer_to[USRQUOTA] = dquot // A random negative value __dquot_transfer(transfer_to)
dquot_add_inodes(transfer_to[cnt])

    spin_lock(&dquot->dq_dqb_lock)  // page fault

, which will lead to kernel page fault:
Quota error (device sda): qtree_write_dquot: Error -8000 occurred while creating quota

 BUG: unable to handle page fault for address: ffffffffffffe120
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 Oops: 0002 [#1] PREEMPT SMP
 CPU: 0 PID: 5974 Comm: chown Not tainted 6.0.0-rc1-00004
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
 RIP: 0010:_raw_spin_lock+0x3a/0x90
 Call Trace:
  dquot_add_inodes+0x28/0x270
  __dquot_transfer+0x377/0x840
  dquot_transfer+0xde/0x540
  ext4_setattr+0x405/0x14d0
  notify_change+0x68e/0x9f0
  chown_common+0x300/0x430
  __x64_sys_fchownat+0x29/0x40

In order to avoid accessing invalid quota memory address, this patch adds block number checking of next/prev free block read from quota file.

Fetch a reproducer in [Link].

Fixes 1da177e4c3f4152 ("Linux-2.6.12-rc2")

CC [email protected]

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

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

Signed-off-by Jan Kara <[email protected]>

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

---
 fs/quota/quota_tree.c |   38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

fs/quota/quota_tree.c +38 -0

@@ -71,6 +71,35 @@ static ssize_t write_blk(struct qtree_me
 	return ret;
 }
 
+static inline int do_check_range(struct super_block *sb, const char *val_name,
+				 uint val, uint min_val, uint max_val)
+{
+	if (val < min_val || val > max_val) {
+		quota_error(sb, "Getting %s %u out of range %u-%u",
+			    val_name, val, min_val, max_val);
+		return -EUCLEAN;
+	}
+
+	return 0;
+}
+
+static int check_dquot_block_header(struct qtree_mem_dqinfo *info,
+				    struct qt_disk_dqdbheader *dh)
+{
+	int err = 0;
+
+	err = do_check_range(info->dqi_sb, "dqdh_next_free",
+			     le32_to_cpu(dh->dqdh_next_free), 0,
+			     info->dqi_blocks - 1);
+	if (err)
+		return err;
+	err = do_check_range(info->dqi_sb, "dqdh_prev_free",
+			     le32_to_cpu(dh->dqdh_prev_free), 0,
+			     info->dqi_blocks - 1);
+
+	return err;
+}
+
 /* Remove empty block from list and return it */
 static int get_free_dqblk(struct qtree_mem_dqinfo *info)
 {

@@ -85,6 +114,9 @@ static int get_free_dqblk(struct qtree_m
 		ret = read_blk(info, blk, buf);
 		if (ret < 0)
 			goto out_buf;
+		ret = check_dquot_block_header(info, dh);
+		if (ret)
+			goto out_buf;
 		info->dqi_free_blk = le32_to_cpu(dh->dqdh_next_free);
 	}
 	else {

@@ -232,6 +264,9 @@ static uint find_free_dqentry(struct qtr
 		*err = read_blk(info, blk, buf);
 		if (*err < 0)
 			goto out_buf;
+		*err = check_dquot_block_header(info, dh);
+		if (*err)
+			goto out_buf;
 	} else {
 		blk = get_free_dqblk(info);
 		if ((int)blk < 0) {

@@ -424,6 +459,9 @@ static int free_dqentry(struct qtree_mem
 		goto out_buf;
 	}
 	dh = (struct qt_disk_dqdbheader *)buf;
+	ret = check_dquot_block_header(info, dh);
+	if (ret)
+		goto out_buf;
 	le16_add_cpu(&dh->dqdh_entries, -1);
 	if (!le16_to_cpu(dh->dqdh_entries)) {	/* Block got free? */
 		ret = remove_free_dqentry(info, buf, blk);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #48 lore raw

PATCH 48/862 platform/chrome: cros_ec_proto: Update version on GET_NEXT_EVENT failure

From: Patryk Duda <[email protected]>

commit f74c7557ed0d321947e8bb4e9d47c1013f8b2227 upstream.

Some EC based devices (e.g. Fingerpint MCU) can jump to RO part of the firmware (intentionally or due to device reboot). The RO part doesn't change during the device lifecycle, so it won't support newer version of EC_CMD_GET_NEXT_EVENT command.

Function cros_ec_query_all() is responsible for finding maximum supported MKBP event version. It's usually called when the device is running RW part of the firmware, so the command version can be potentially higher than version supported by the RO.

The problem was fixed by updating maximum supported version when the device returns EC_RES_INVALID_VERSION (mapped to -ENOPROTOOPT). That way the kernel will use highest common version supported by RO and RW.

Fixes 3300fdd630d4 ("platform/chrome: cros_ec: handle MKBP more events flag")

Cc <[email protected]> # 5.10+

Reviewed-by Guenter Roeck <[email protected]>

Signed-off-by Patryk Duda <[email protected]>

Signed-off-by Tzung-Bi Shih <[email protected]>

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

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

---
 drivers/platform/chrome/cros_ec_proto.c |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

drivers/platform/chrome/cros_ec_proto.c +32 -0

@@ -773,6 +773,7 @@ int cros_ec_get_next_event(struct cros_e
 	u8 event_type;
 	u32 host_event;
 	int ret;
+	u32 ver_mask;
 
 	/*
 	 * Default value for wake_event.

@@ -794,6 +795,37 @@ int cros_ec_get_next_event(struct cros_e
 		return get_keyboard_state_event(ec_dev);
 
 	ret = get_next_event(ec_dev);
+	/*
+	 * -ENOPROTOOPT is returned when EC returns EC_RES_INVALID_VERSION.
+	 * This can occur when EC based device (e.g. Fingerprint MCU) jumps to
+	 * the RO image which doesn't support newer version of the command. In
+	 * this case we will attempt to update maximum supported version of the
+	 * EC_CMD_GET_NEXT_EVENT.
+	 */
+	if (ret == -ENOPROTOOPT) {
+		dev_dbg(ec_dev->dev,
+			"GET_NEXT_EVENT returned invalid version error.\n");
+		ret = cros_ec_get_host_command_version_mask(ec_dev,
+							EC_CMD_GET_NEXT_EVENT,
+							&ver_mask);
+		if (ret < 0 || ver_mask == 0)
+			/*
+			 * Do not change the MKBP supported version if we can't
+			 * obtain supported version correctly. Please note that
+			 * calling EC_CMD_GET_NEXT_EVENT returned
+			 * EC_RES_INVALID_VERSION which means that the command
+			 * is present.
+			 */
+			return -ENOPROTOOPT;
+
+		ec_dev->mkbp_event_supported = fls(ver_mask);
+		dev_dbg(ec_dev->dev, "MKBP support version changed to %u\n",
+			ec_dev->mkbp_event_supported - 1);
+
+		/* Try to get next event with new MKBP support version set. */
+		ret = get_next_event(ec_dev);
+	}
+
 	if (ret <= 0)
 		return ret;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #49 lore raw

PATCH 49/862 arm64: dts: qcom: sdm845-mtp: correct ADC settle time

From: Krzysztof Kozlowski <[email protected]>

commit 209a04885ab5f76722a1671d0fbf0a5b4bccacec upstream.

The PMIC's VADC property for settle time is qcom,hw-settle-time, not qcom,hw-settle-time-us. The latter is used in PMIC's TM ADC.

qcom/sdm845-mtp.dtb: pmic@0: adc@3100:adc-chan@4c: 'qcom,hw-settle-time-us' does not match any of the regexes: 'pinctrl-[0-9]+'

Fixes d5e12f3823ae ("arm64: dts: qcom: sdm845: mtp: Add vadc channels and thermal zones")

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

Reviewed-by Stephen Boyd <[email protected]>

Reviewed-by Vinod Koul <[email protected]>

Reviewed-by David Heidelberg <[email protected]>

Signed-off-by Bjorn Andersson <[email protected]>

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

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

---
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

arch/arm64/boot/dts/qcom/sdm845-mtp.dts +6 -6

@@ -536,42 +536,42 @@
 		reg = <ADC5_XO_THERM_100K_PU>;
 		label = "xo_therm";
 		qcom,ratiometric;
-		qcom,hw-settle-time-us = <200>;
+		qcom,hw-settle-time = <200>;
 	};
 
 	adc-chan@4d {
 		reg = <ADC5_AMUX_THM1_100K_PU>;
 		label = "msm_therm";
 		qcom,ratiometric;
-		qcom,hw-settle-time-us = <200>;
+		qcom,hw-settle-time = <200>;
 	};
 
 	adc-chan@4f {
 		reg = <ADC5_AMUX_THM3_100K_PU>;
 		label = "pa_therm1";
 		qcom,ratiometric;
-		qcom,hw-settle-time-us = <200>;
+		qcom,hw-settle-time = <200>;
 	};
 
 	adc-chan@51 {
 		reg = <ADC5_AMUX_THM5_100K_PU>;
 		label = "quiet_therm";
 		qcom,ratiometric;
-		qcom,hw-settle-time-us = <200>;
+		qcom,hw-settle-time = <200>;
 	};
 
 	adc-chan@83 {
 		reg = <ADC5_VPH_PWR>;
 		label = "vph_pwr";
 		qcom,ratiometric;
-		qcom,hw-settle-time-us = <200>;
+		qcom,hw-settle-time = <200>;
 	};
 
 	adc-chan@85 {
 		reg = <ADC5_VCOIN>;
 		label = "vcoin";
 		qcom,ratiometric;
-		qcom,hw-settle-time-us = <200>;
+		qcom,hw-settle-time = <200>;
 	};
 };

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #50 lore raw

PATCH 50/862 ASoC: wcd9335: fix order of Slimbus unprepare/disable

From: Krzysztof Kozlowski <[email protected]>

commit ea8ef003aa53ad23e7705c5cab1c4e664faa6c79 upstream.

Slimbus streams are first prepared and then enabled, so the cleanup path should reverse it. The unprepare sets stream->num_ports to 0 and frees the stream->ports. Calling disable after unprepare was not really effective (channels was not deactivated) and could lead to further issues due to making transfers on unprepared stream.

Fixes 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec")

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

Reviewed-by Srinivas Kandagatla <[email protected]>

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

Signed-off-by Mark Brown <[email protected]>

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

---
 sound/soc/codecs/wcd9335.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/soc/codecs/wcd9335.c +1 -1

@@ -1974,8 +1974,8 @@ static int wcd9335_trigger(struct snd_pc
 	case SNDRV_PCM_TRIGGER_STOP:
 	case SNDRV_PCM_TRIGGER_SUSPEND:
 	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
-		slim_stream_unprepare(dai_data->sruntime);
 		slim_stream_disable(dai_data->sruntime);
+		slim_stream_unprepare(dai_data->sruntime);
 		break;
 	default:
 		break;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #51 lore raw

PATCH 51/862 ASoC: wcd934x: fix order of Slimbus unprepare/disable

From: Krzysztof Kozlowski <[email protected]>

commit e96bca7eaa5747633ec638b065630ff83728982a upstream.

Fixes a61f3b4f476e ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec")

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

Reviewed-by Srinivas Kandagatla <[email protected]>

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

Signed-off-by Mark Brown <[email protected]>

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

---
 sound/soc/codecs/wcd934x.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/soc/codecs/wcd934x.c +1 -1

@@ -1913,8 +1913,8 @@ static int wcd934x_trigger(struct snd_pc
 	case SNDRV_PCM_TRIGGER_STOP:
 	case SNDRV_PCM_TRIGGER_SUSPEND:
 	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
-		slim_stream_unprepare(dai_data->sruntime);
 		slim_stream_disable(dai_data->sruntime);
+		slim_stream_unprepare(dai_data->sruntime);
 		break;
 	default:
 		break;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #52 lore raw

PATCH 52/862 hwmon: (gsc-hwmon) Call of_node_get() before of_find_xxx API

From: Liang He <[email protected]>

commit 7f62cf781e6567d59c8935dc8c6068ce2bb904b7 upstream.

In gsc_hwmon_get_devtree_pdata(), we should call of_node_get() before the of_find_compatible_node() which will automatically call of_node_put() for the 'from' argument.

Fixes 3bce5377ef66 ("hwmon: Add Gateworks System Controller support")

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

Co-developed-by Mengda Chen <[email protected]>

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

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

Signed-off-by Guenter Roeck <[email protected]>

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

---
 drivers/hwmon/gsc-hwmon.c |    1 +
 1 file changed, 1 insertion(+)

drivers/hwmon/gsc-hwmon.c +1 -0

@@ -267,6 +267,7 @@ gsc_hwmon_get_devtree_pdata(struct devic
 	pdata->nchannels = nchannels;
 
 	/* fan controller base address */
+	of_node_get(dev->parent->of_node);
 	fan = of_find_compatible_node(dev->parent->of_node, NULL, "gw,gsc-fan");
 	if (fan && of_property_read_u32(fan, "reg", &pdata->fan_base)) {
 		of_node_put(fan);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #53 lore raw

PATCH 53/862 net: thunderbolt: Enable DMA paths only after rings are enabled

From: Mika Westerberg <[email protected]>

commit ff7cd07f306406493f7b78890475e85b6d0811ed upstream.

If the other host starts sending packets early on it is possible that we are still in the middle of populating the initial Rx ring packets to the ring. This causes the tbnet_poll() to mess over the queue and causes list corruption. This happens specifically when connected with macOS as it seems start sending various IP discovery packets as soon as its side of the paths are configured.

To prevent this we move the DMA path enabling to happen after we have primed the Rx ring. This makes sure no incoming packets can arrive before we are ready to handle them.

Fixes e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")

Signed-off-by Mika Westerberg <[email protected]>

Signed-off-by David S. Miller <[email protected]>

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

---
 drivers/net/thunderbolt.c |   28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

drivers/net/thunderbolt.c +17 ~~-11~~

@@ -612,18 +612,13 @@ static void tbnet_connected_work(struct
 		return;
 	}
 
-	/* Both logins successful so enable the high-speed DMA paths and
-	 * start the network device queue.
+	/* Both logins successful so enable the rings, high-speed DMA
+	 * paths and start the network device queue.
+	 *
+	 * Note we enable the DMA paths last to make sure we have primed
+	 * the Rx ring before any incoming packets are allowed to
+	 * arrive.
 	 */
-	ret = tb_xdomain_enable_paths(net->xd, net->local_transmit_path,
-				      net->rx_ring.ring->hop,
-				      net->remote_transmit_path,
-				      net->tx_ring.ring->hop);
-	if (ret) {
-		netdev_err(net->dev, "failed to enable DMA paths\n");
-		return;
-	}
-
 	tb_ring_start(net->tx_ring.ring);
 	tb_ring_start(net->rx_ring.ring);

@@ -635,10 +630,21 @@ static void tbnet_connected_work(struct
 	if (ret)
 		goto err_free_rx_buffers;
 
+	ret = tb_xdomain_enable_paths(net->xd, net->local_transmit_path,
+				      net->rx_ring.ring->hop,
+				      net->remote_transmit_path,
+				      net->tx_ring.ring->hop);
+	if (ret) {
+		netdev_err(net->dev, "failed to enable DMA paths\n");
+		goto err_free_tx_buffers;
+	}
+
 	netif_carrier_on(net->dev);
 	netif_start_queue(net->dev);
 	return;
 
+err_free_tx_buffers:
+	tbnet_free_buffers(&net->tx_ring);
 err_free_rx_buffers:
 	tbnet_free_buffers(&net->rx_ring);
 err_stop_rings:

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #54 lore raw

PATCH 54/862 regulator: qcom_rpm: Fix circular deferral regression

From: Linus Walleij <[email protected]>

commit 8478ed5844588703a1a4c96a004b1525fbdbdd5e upstream.

On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator) does not come up if they are supplied by an SMPS-regulator. This is not very strange since the regulators are registered in a long array and the L-regulators are registered before the S-regulators, and if an L-regulator defers, it will never get around to registering the S-regulator that it needs.

See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts:

pm8058-regulators {
    (...)
    vdd_l13_l16-supply = <&pm8058_s4>;
    (...)

Ooops.

Fix this by moving the PM8058 S-regulators first in the array.

Do the same for the PM8901 S-regulators (though this is currently not causing any problems with out device trees) so that the pattern of registration order is the same on all PMnnnn chips.

Fixes 087a1b5cdd55 ("regulator: qcom: Rework to single platform device")

Cc Andy Gross <[email protected]>

Cc Bjorn Andersson <[email protected]>

Cc Konrad Dybcio <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

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

Signed-off-by Mark Brown <[email protected]>

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

---
 drivers/regulator/qcom_rpm-regulator.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

drivers/regulator/qcom_rpm-regulator.c +12 ~~-12~~

@@ -802,6 +802,12 @@ static const struct rpm_regulator_data r
 };
 
 static const struct rpm_regulator_data rpm_pm8058_regulators[] = {
+	{ "s0",   QCOM_RPM_PM8058_SMPS0,  &pm8058_smps, "vdd_s0" },
+	{ "s1",   QCOM_RPM_PM8058_SMPS1,  &pm8058_smps, "vdd_s1" },
+	{ "s2",   QCOM_RPM_PM8058_SMPS2,  &pm8058_smps, "vdd_s2" },
+	{ "s3",   QCOM_RPM_PM8058_SMPS3,  &pm8058_smps, "vdd_s3" },
+	{ "s4",   QCOM_RPM_PM8058_SMPS4,  &pm8058_smps, "vdd_s4" },
+
 	{ "l0",   QCOM_RPM_PM8058_LDO0,   &pm8058_nldo, "vdd_l0_l1_lvs"	},
 	{ "l1",   QCOM_RPM_PM8058_LDO1,   &pm8058_nldo, "vdd_l0_l1_lvs" },
 	{ "l2",   QCOM_RPM_PM8058_LDO2,   &pm8058_pldo, "vdd_l2_l11_l12" },

@@ -829,12 +835,6 @@ static const struct rpm_regulator_data r
 	{ "l24",  QCOM_RPM_PM8058_LDO24,  &pm8058_nldo, "vdd_l23_l24_l25" },
 	{ "l25",  QCOM_RPM_PM8058_LDO25,  &pm8058_nldo, "vdd_l23_l24_l25" },
 
-	{ "s0",   QCOM_RPM_PM8058_SMPS0,  &pm8058_smps, "vdd_s0" },
-	{ "s1",   QCOM_RPM_PM8058_SMPS1,  &pm8058_smps, "vdd_s1" },
-	{ "s2",   QCOM_RPM_PM8058_SMPS2,  &pm8058_smps, "vdd_s2" },
-	{ "s3",   QCOM_RPM_PM8058_SMPS3,  &pm8058_smps, "vdd_s3" },
-	{ "s4",   QCOM_RPM_PM8058_SMPS4,  &pm8058_smps, "vdd_s4" },
-
 	{ "lvs0", QCOM_RPM_PM8058_LVS0, &pm8058_switch, "vdd_l0_l1_lvs" },
 	{ "lvs1", QCOM_RPM_PM8058_LVS1, &pm8058_switch, "vdd_l0_l1_lvs" },

@@ -843,6 +843,12 @@ static const struct rpm_regulator_data r
 };
 
 static const struct rpm_regulator_data rpm_pm8901_regulators[] = {
+	{ "s0",   QCOM_RPM_PM8901_SMPS0, &pm8901_ftsmps, "vdd_s0" },
+	{ "s1",   QCOM_RPM_PM8901_SMPS1, &pm8901_ftsmps, "vdd_s1" },
+	{ "s2",   QCOM_RPM_PM8901_SMPS2, &pm8901_ftsmps, "vdd_s2" },
+	{ "s3",   QCOM_RPM_PM8901_SMPS3, &pm8901_ftsmps, "vdd_s3" },
+	{ "s4",   QCOM_RPM_PM8901_SMPS4, &pm8901_ftsmps, "vdd_s4" },
+
 	{ "l0",   QCOM_RPM_PM8901_LDO0, &pm8901_nldo, "vdd_l0" },
 	{ "l1",   QCOM_RPM_PM8901_LDO1, &pm8901_pldo, "vdd_l1" },
 	{ "l2",   QCOM_RPM_PM8901_LDO2, &pm8901_pldo, "vdd_l2" },

@@ -851,12 +857,6 @@ static const struct rpm_regulator_data r
 	{ "l5",   QCOM_RPM_PM8901_LDO5, &pm8901_pldo, "vdd_l5" },
 	{ "l6",   QCOM_RPM_PM8901_LDO6, &pm8901_pldo, "vdd_l6" },
 
-	{ "s0",   QCOM_RPM_PM8901_SMPS0, &pm8901_ftsmps, "vdd_s0" },
-	{ "s1",   QCOM_RPM_PM8901_SMPS1, &pm8901_ftsmps, "vdd_s1" },
-	{ "s2",   QCOM_RPM_PM8901_SMPS2, &pm8901_ftsmps, "vdd_s2" },
-	{ "s3",   QCOM_RPM_PM8901_SMPS3, &pm8901_ftsmps, "vdd_s3" },
-	{ "s4",   QCOM_RPM_PM8901_SMPS4, &pm8901_ftsmps, "vdd_s4" },
-
 	{ "lvs0", QCOM_RPM_PM8901_LVS0, &pm8901_switch, "lvs0_in" },
 	{ "lvs1", QCOM_RPM_PM8901_LVS1, &pm8901_switch, "lvs1_in" },
 	{ "lvs2", QCOM_RPM_PM8901_LVS2, &pm8901_switch, "lvs2_in" },

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #55 lore raw

PATCH 55/862 arm64: topology: move store_cpu_topology() to shared code

From: Conor Dooley <[email protected]>

commit 456797da792fa7cbf6698febf275fe9b36691f78 upstream.

arm64's method of defining a default cpu topology requires only minimal changes to apply to RISC-V also. The current arm64 implementation exits early in a uniprocessor configuration by reading MPIDR & claiming that uniprocessor can rely on the default values.

This is appears to be a hangover from prior to '3102bc0e6ac7 ("arm64:
topology: Stop using MPIDR for topology information")', because the current code just assigns default values for multiprocessor systems.

With the MPIDR references removed, store_cpu_topolgy() can be moved to the common arch_topology code.

Reviewed-by Sudeep Holla <[email protected]>

Acked-by Catalin Marinas <[email protected]>

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

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

---
 arch/arm64/kernel/topology.c |   40 ----------------------------------------
 drivers/base/arch_topology.c |   19 +++++++++++++++++++
 2 files changed, 19 insertions(+), 40 deletions(-)

arch/arm64/kernel/topology.c +0 ~~-40~~

@@ -22,46 +22,6 @@
 #include <asm/cputype.h>
 #include <asm/topology.h>
 
-void store_cpu_topology(unsigned int cpuid)
-{
-	struct cpu_topology *cpuid_topo = &cpu_topology[cpuid];
-	u64 mpidr;
-
-	if (cpuid_topo->package_id != -1)
-		goto topology_populated;
-
-	mpidr = read_cpuid_mpidr();
-
-	/* Uniprocessor systems can rely on default topology values */
-	if (mpidr & MPIDR_UP_BITMASK)
-		return;
-
-	/*
-	 * This would be the place to create cpu topology based on MPIDR.
-	 *
-	 * However, it cannot be trusted to depict the actual topology; some
-	 * pieces of the architecture enforce an artificial cap on Aff0 values
-	 * (e.g. GICv3's ICC_SGI1R_EL1 limits it to 15), leading to an
-	 * artificial cycling of Aff1, Aff2 and Aff3 values. IOW, these end up
-	 * having absolutely no relationship to the actual underlying system
-	 * topology, and cannot be reasonably used as core / package ID.
-	 *
-	 * If the MT bit is set, Aff0 *could* be used to define a thread ID, but
-	 * we still wouldn't be able to obtain a sane core ID. This means we
-	 * need to entirely ignore MPIDR for any topology deduction.
-	 */
-	cpuid_topo->thread_id  = -1;
-	cpuid_topo->core_id    = cpuid;
-	cpuid_topo->package_id = cpu_to_node(cpuid);
-
-	pr_debug("CPU%u: cluster %d core %d thread %d mpidr %#016llx\n",
-		 cpuid, cpuid_topo->package_id, cpuid_topo->core_id,
-		 cpuid_topo->thread_id, mpidr);
-
-topology_populated:
-	update_siblings_masks(cpuid);
-}
-
 #ifdef CONFIG_ACPI
 static bool __init acpi_cpu_is_threaded(int cpu)
 {

drivers/base/arch_topology.c +19 -0

@@ -841,4 +841,23 @@ void __init init_cpu_topology(void)
 		return;
 	}
 }
+
+void store_cpu_topology(unsigned int cpuid)
+{
+	struct cpu_topology *cpuid_topo = &cpu_topology[cpuid];
+
+	if (cpuid_topo->package_id != -1)
+		goto topology_populated;
+
+	cpuid_topo->thread_id = -1;
+	cpuid_topo->core_id = cpuid;
+	cpuid_topo->package_id = cpu_to_node(cpuid);
+
+	pr_debug("CPU%u: package %d core %d thread %d\n",
+		 cpuid, cpuid_topo->package_id, cpuid_topo->core_id,
+		 cpuid_topo->thread_id);
+
+topology_populated:
+	update_siblings_masks(cpuid);
+}
 #endif

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #56 lore raw

PATCH 56/862 riscv: topology: fix default topology reporting

From: Conor Dooley <[email protected]>

commit fbd92809997a391f28075f1c8b5ee314c225557c upstream.

RISC-V has no sane defaults to fall back on where there is no cpu-map in the devicetree.
Without sane defaults, the package, core and thread IDs are all set to -1. This causes user-visible inaccuracies for tools like hwloc/lstopo which rely on the sysfs cpu topology files to detect a system's topology.

On a PolarFire SoC, which should have 4 harts with a thread each, lstopo currently reports:

Machine (793MB total)
Package L#0

    NUMANode L#0 (P#0 793MB)
    Core L#0
      L1d L#0 (32KB) + L1i L#0 (32KB) + PU L#0 (P#0)
      L1d L#1 (32KB) + L1i L#1 (32KB) + PU L#1 (P#1)
      L1d L#2 (32KB) + L1i L#2 (32KB) + PU L#2 (P#2)
      L1d L#3 (32KB) + L1i L#3 (32KB) + PU L#3 (P#3)

Adding calls to store_cpu_topology() in {boot,smp} hart bringup code results in the correct topolgy being reported:

Machine (793MB total)
Package L#0

    NUMANode L#0 (P#0 793MB)
    L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
    L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
    L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#2)
    L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#3)

CC [email protected] # 456797da792f: arm64: topology: move store_cpu_topology() to shared code

Fixes 03f11f03dbfe ("RISC-V: Parse cpu topology during boot.")

Reported-by Brice Goglin <[email protected]>

Link https://github.com/open-mpi/hwloc/issues/536

Reviewed-by Sudeep Holla <[email protected]>

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

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

---
 arch/riscv/Kconfig          |    2 +-
 arch/riscv/kernel/smpboot.c |    3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

arch/riscv/Kconfig +1 -1

@@ -52,7 +52,7 @@ config RISCV
 	select COMMON_CLK
 	select CPU_PM if CPU_IDLE
 	select EDAC_SUPPORT
-	select GENERIC_ARCH_TOPOLOGY if SMP
+	select GENERIC_ARCH_TOPOLOGY
 	select GENERIC_ATOMIC64 if !64BIT
 	select GENERIC_CLOCKEVENTS_BROADCAST if SMP
 	select GENERIC_EARLY_IOREMAP

arch/riscv/kernel/smpboot.c +2 -1

@@ -49,6 +49,7 @@ void __init smp_prepare_cpus(unsigned in
 	unsigned int curr_cpuid;
 
 	curr_cpuid = smp_processor_id();
+	store_cpu_topology(curr_cpuid);
 	numa_store_cpu_info(curr_cpuid);
 	numa_add_cpu(curr_cpuid);

@@ -162,9 +163,9 @@ asmlinkage __visible void smp_callin(voi
 	mmgrab(mm);
 	current->active_mm = mm;
 
+	store_cpu_topology(curr_cpuid);
 	notify_cpu_starting(curr_cpuid);
 	numa_add_cpu(curr_cpuid);
-	update_siblings_masks(curr_cpuid);
 	set_cpu_online(curr_cpuid, 1);
 
 	/*

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #57 lore raw

PATCH 57/862 RISC-V: Re-enable counter access from userspace

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

From: Palmer Dabbelt <[email protected]>

commit 5a5294fbe0200d1327f0e089135dad77b45aa2ee upstream.

These counters were part of the ISA when we froze the uABI, removing them breaks userspace.

Fixes e9991434596f ("RISC-V: Add perf platform driver based on SBI PMU extension")

Tested-by Conor Dooley <[email protected]>

Reviewed-by Conor Dooley <[email protected]>

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

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

---
 drivers/perf/riscv_pmu_sbi.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/perf/riscv_pmu_sbi.c +5 -2

@@ -645,8 +645,11 @@ static int pmu_sbi_starting_cpu(unsigned
 	struct riscv_pmu *pmu = hlist_entry_safe(node, struct riscv_pmu, node);
 	struct cpu_hw_events *cpu_hw_evt = this_cpu_ptr(pmu->hw_events);
 
-	/* Enable the access for TIME csr only from the user mode now */
-	csr_write(CSR_SCOUNTEREN, 0x2);
+	/*
+	 * Enable the access for CYCLE, TIME, and INSTRET CSRs from userspace,
+	 * as is necessary to maintain uABI compatibility.
+	 */
+	csr_write(CSR_SCOUNTEREN, 0x7);
 
 	/* Stop all the counters so that they can be enabled from perf */
 	pmu_sbi_stop_all(pmu);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #58 lore raw

PATCH 58/862 RISC-V: Make port I/O string accessors actually work

From: Maciej W. Rozycki <[email protected]>

commit 9cc205e3c17d5716da7ebb7fa0c985555e95d009 upstream.

Fix port I/O string accessors such as insb', outsb', etc. which use the physical PCI port I/O address rather than the corresponding memory mapping to get at the requested location, which in turn breaks at least accesses made by our parport driver to a PCIe parallel port such as:

PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 20
parport0: PC-style at 0x1000 (0x1008), irq 20, using FIFO [PCSPP,TRISTATE,COMPAT,EPP,ECP]

causing a memory access fault:

Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000001008
Oops [#1]
Modules linked in:
CPU: 1 PID: 350 Comm: cat Not tainted 6.0.0-rc2-00283-g10d4879f9ef0-dirty #23
Hardware name: SiFive HiFive Unmatched A00 (DT)
epc : parport_pc_fifo_write_block_pio+0x266/0x416
 ra : parport_pc_fifo_write_block_pio+0xb4/0x416

epc : ffffffff80542c3e ra : ffffffff80542a8c sp : ffffffd88899fc60
gp : ffffffff80fa2700 tp : ffffffd882b1e900 t0 : ffffffd883d0b000 t1 : ffffffffff000002 t2 : 4646393043330a38 s0 : ffffffd88899fcf0 s1 : 0000000000001000 a0 : 0000000000000010 a1 : 0000000000000000 a2 : ffffffd883d0a010 a3 : 0000000000000023 a4 : 00000000ffff8fbb a5 : ffffffd883d0a001 a6 : 0000000100000000 a7 : ffffffc800000000 s2 : ffffffffff000002 s3 : ffffffff80d28880 s4 : ffffffff80fa1f50 s5 : 0000000000001008 s6 : 0000000000000008 s7 : ffffffd883d0a000 s8 : 0004000000000000 s9 : ffffffff80dc1d80 s10: ffffffd8807e4000
s11: 0000000000000000 t3 : 00000000000000ff t4 : 393044410a303930 t5 : 0000000000001000 t6 : 0000000000040000
status: 0000000200000120 badaddr: 0000000000001008 cause: 000000000000000f

[<ffffffff80543212>] parport_pc_compat_write_block_pio+0xfe/0x200
[<ffffffff8053bbc0>] parport_write+0x46/0xf8
[<ffffffff8050530e>] lp_write+0x158/0x2d2
[<ffffffff80185716>] vfs_write+0x8e/0x2c2
[<ffffffff80185a74>] ksys_write+0x52/0xc2
[<ffffffff80185af2>] sys_write+0xe/0x16
[<ffffffff80003770>] ret_from_syscall+0x0/0x2
---[ end trace 0000000000000000 ]---

For simplicity address the problem by adding PCI_IOBASE to the physical address requested in the respective wrapper macros only, observing that the raw accessors such as __insb', __outsb', etc. are not supposed to be used other than by said macros. Remove the cast to long' that is no longer needed on addr' now that it is used as an offset from PCI_IOBASE and add parentheses around `addr' needed for predictable evaluation in macro expansion. No need to make said adjustments in separate changes given that current code is gravely broken and does not ever work.

Signed-off-by Maciej W. Rozycki <[email protected]>

Fixes fab957c11efe2 ("RISC-V: Atomic and Locking Code")

Cc [email protected] # v4.15+

Reviewed-by Arnd Bergmann <[email protected]>

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

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

---
 arch/riscv/include/asm/io.h |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

arch/riscv/include/asm/io.h +8 -8

@@ -101,9 +101,9 @@ __io_reads_ins(reads, u32, l, __io_br(),
 __io_reads_ins(ins,  u8, b, __io_pbr(), __io_par(addr))
 __io_reads_ins(ins, u16, w, __io_pbr(), __io_par(addr))
 __io_reads_ins(ins, u32, l, __io_pbr(), __io_par(addr))
-#define insb(addr, buffer, count) __insb((void __iomem *)(long)addr, buffer, count)
-#define insw(addr, buffer, count) __insw((void __iomem *)(long)addr, buffer, count)
-#define insl(addr, buffer, count) __insl((void __iomem *)(long)addr, buffer, count)
+#define insb(addr, buffer, count) __insb(PCI_IOBASE + (addr), buffer, count)
+#define insw(addr, buffer, count) __insw(PCI_IOBASE + (addr), buffer, count)
+#define insl(addr, buffer, count) __insl(PCI_IOBASE + (addr), buffer, count)
 
 __io_writes_outs(writes,  u8, b, __io_bw(), __io_aw())
 __io_writes_outs(writes, u16, w, __io_bw(), __io_aw())

@@ -115,22 +115,22 @@ __io_writes_outs(writes, u32, l, __io_bw
 __io_writes_outs(outs,  u8, b, __io_pbw(), __io_paw())
 __io_writes_outs(outs, u16, w, __io_pbw(), __io_paw())
 __io_writes_outs(outs, u32, l, __io_pbw(), __io_paw())
-#define outsb(addr, buffer, count) __outsb((void __iomem *)(long)addr, buffer, count)
-#define outsw(addr, buffer, count) __outsw((void __iomem *)(long)addr, buffer, count)
-#define outsl(addr, buffer, count) __outsl((void __iomem *)(long)addr, buffer, count)
+#define outsb(addr, buffer, count) __outsb(PCI_IOBASE + (addr), buffer, count)
+#define outsw(addr, buffer, count) __outsw(PCI_IOBASE + (addr), buffer, count)
+#define outsl(addr, buffer, count) __outsl(PCI_IOBASE + (addr), buffer, count)
 
 #ifdef CONFIG_64BIT
 __io_reads_ins(reads, u64, q, __io_br(), __io_ar(addr))
 #define readsq(addr, buffer, count) __readsq(addr, buffer, count)
 
 __io_reads_ins(ins, u64, q, __io_pbr(), __io_par(addr))
-#define insq(addr, buffer, count) __insq((void __iomem *)addr, buffer, count)
+#define insq(addr, buffer, count) __insq(PCI_IOBASE + (addr), buffer, count)
 
 __io_writes_outs(writes, u64, q, __io_bw(), __io_aw())
 #define writesq(addr, buffer, count) __writesq(addr, buffer, count)
 
 __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw())
-#define outsq(addr, buffer, count) __outsq((void __iomem *)addr, buffer, count)
+#define outsq(addr, buffer, count) __outsq(PCI_IOBASE + (addr), buffer, count)
 #endif
 
 #include <asm-generic/io.h>

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #59 lore raw

PATCH 59/862 parisc: fbdev/stifb: Align graphics memory size to 4MB

From: Helge Deller <[email protected]>

commit aca7c13d3bee81a968337a5515411409ae9d095d upstream.

Independend of the current graphics resolution, adjust the reported graphics card memory size to the next 4MB boundary.
This fixes the fbtest program which expects a naturally aligned size.

Signed-off-by Helge Deller <[email protected]>

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

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

drivers/video/fbdev/stifb.c +1 -1

@@ -1298,7 +1298,7 @@ static int __init stifb_init_fb(struct s
 	
 	/* limit fbsize to max visible screen size */
 	if (fix->smem_len > yres*fix->line_length)
-		fix->smem_len = yres*fix->line_length;
+		fix->smem_len = ALIGN(yres*fix->line_length, 4*1024*1024);
 	
 	fix->accel = FB_ACCEL_NONE;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:43 UTC #60 lore raw

PATCH 60/862 parisc: Fix userspace graphics card breakage due to pgtable special bit

From: Helge Deller <[email protected]>

commit 70be49f2f6223ddd2fcddb0089a40864c37e1494 upstream.

Commit df24e1783e6e ("parisc: Add vDSO support") introduced the vDSO support, for which a _PAGE_SPECIAL page table flag was needed. Since we wanted to keep every page table entry in 32-bits, this patch re-used the existing - but yet unused - _PAGE_DMB flag (which triggers a hardware break if a page is accessed) to store the special bit.

But when graphics card memory is mmapped into userspace, the kernel uses vm_iomap_memory() which sets the the special flag. So, with the DMB bit set, every access to the graphics memory now triggered a hardware exception and segfaulted the userspace program.

Fix this breakage by dropping the DMB bit when writing the page protection bits to the CPU TLB.

In addition this patch adds a small optimization: if huge pages aren't configured (which is at least the case for 32-bit kernels), then the special bit is stored in the hpage (HUGE PAGE) bit instead. That way we can skip to reset the DMB bit.

Fixes df24e1783e6e ("parisc: Add vDSO support")

Cc <[email protected]> # 5.18+

Signed-off-by Helge Deller <[email protected]>

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

---
 arch/parisc/include/asm/pgtable.h |    7 ++++++-
 arch/parisc/kernel/entry.S        |    8 ++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

arch/parisc/include/asm/pgtable.h +6 -1

@@ -192,6 +192,11 @@ extern void __update_cache(pte_t pte);
 #define _PAGE_PRESENT_BIT  22   /* (0x200) Software: translation valid */
 #define _PAGE_HPAGE_BIT    21   /* (0x400) Software: Huge Page */
 #define _PAGE_USER_BIT     20   /* (0x800) Software: User accessible page */
+#ifdef CONFIG_HUGETLB_PAGE
+#define _PAGE_SPECIAL_BIT  _PAGE_DMB_BIT  /* DMB feature is currently unused */
+#else
+#define _PAGE_SPECIAL_BIT  _PAGE_HPAGE_BIT /* use unused HUGE PAGE bit */
+#endif
 
 /* N.B. The bits are defined in terms of a 32 bit word above, so the */
 /*      following macro is ok for both 32 and 64 bit.                */

@@ -219,7 +224,7 @@ extern void __update_cache(pte_t pte);
 #define _PAGE_PRESENT  (1 << xlate_pabit(_PAGE_PRESENT_BIT))
 #define _PAGE_HUGE     (1 << xlate_pabit(_PAGE_HPAGE_BIT))
 #define _PAGE_USER     (1 << xlate_pabit(_PAGE_USER_BIT))
-#define _PAGE_SPECIAL  (_PAGE_DMB)
+#define _PAGE_SPECIAL  (1 << xlate_pabit(_PAGE_SPECIAL_BIT))
 
 #define _PAGE_TABLE	(_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | _PAGE_DIRTY | _PAGE_ACCESSED)
 #define _PAGE_CHG_MASK	(PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_SPECIAL)

arch/parisc/kernel/entry.S +8 -0

@@ -499,6 +499,10 @@
 	 * Finally, _PAGE_READ goes in the top bit of PL1 (so we
 	 * trigger an access rights trap in user space if the user
 	 * tries to read an unreadable page */
+#if _PAGE_SPECIAL_BIT == _PAGE_DMB_BIT
+	/* need to drop DMB bit, as it's used as SPECIAL flag */
+	depi		0,_PAGE_SPECIAL_BIT,1,\pte
+#endif
 	depd            \pte,8,7,\prot
 
 	/* PAGE_USER indicates the page can be read with user privileges,

@@ -529,6 +533,10 @@
 	 * makes the tlb entry for the differently formatted pa11
 	 * insertion instructions */
 	.macro		make_insert_tlb_11	spc,pte,prot
+#if _PAGE_SPECIAL_BIT == _PAGE_DMB_BIT
+	/* need to drop DMB bit, as it's used as SPECIAL flag */
+	depi		0,_PAGE_SPECIAL_BIT,1,\pte
+#endif
 	zdep		\spc,30,15,\prot
 	dep		\pte,8,7,\prot
 	extru,=		\pte,_PAGE_NO_CACHE_BIT,1,%r0

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #61 lore raw

PATCH 61/862 riscv: vdso: fix NULL deference in vdso_join_timens() when vfork

From: Jisheng Zhang <[email protected]>

commit a8616d2dc193b6becc36b5f3cfeaa9ac7a5762f9 upstream.

Testing tools/testing/selftests/timens/vfork_exec.c got below kernel log:

[    6.838454] Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000020
[    6.842255] Oops [#1]
[    6.842871] Modules linked in:
[    6.844249] CPU: 1 PID: 64 Comm: vfork_exec Not tainted 6.0.0-rc3-rt15+ #8
[    6.845861] Hardware name: riscv-virtio,qemu (DT)
[    6.848009] epc : vdso_join_timens+0xd2/0x110
[    6.850097]  ra : vdso_join_timens+0xd2/0x110
[    6.851164] epc : ffffffff8000635c ra : ffffffff8000635c sp : ff6000000181fbf0
[    6.852562]  gp : ffffffff80cff648 tp : ff60000000fdb700 t0 : 3030303030303030
[    6.853852]  t1 : 0000000000000030 t2 : 3030303030303030 s0 : ff6000000181fc40
[    6.854984]  s1 : ff60000001e6c000 a0 : 0000000000000010 a1 : ffffffff8005654c
[    6.856221]  a2 : 00000000ffffefff a3 : 0000000000000000 a4 : 0000000000000000
[    6.858114]  a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038
[    6.859484]  s2 : ff60000001e6c068 s3 : ff6000000108abb0 s4 : 0000000000000000
[    6.860751]  s5 : 0000000000001000 s6 : ffffffff8089dc40 s7 : ffffffff8089dc38
[    6.862029]  s8 : ffffffff8089dc30 s9 : ff60000000fdbe38 s10: 000000000000005e
[    6.863304]  s11: ffffffff80cc3510 t3 : ffffffff80d1112f t4 : ffffffff80d1112f
[    6.864565]  t5 : ffffffff80d11130 t6 : ff6000000181fa00
[    6.865561] status: 0000000000000120 badaddr: 0000000000000020 cause: 000000000000000d
[    6.868046] [<ffffffff8008dc94>] timens_commit+0x38/0x11a
[    6.869089] [<ffffffff8008dde8>] timens_on_fork+0x72/0xb4
[    6.870055] [<ffffffff80190096>] begin_new_exec+0x3c6/0x9f0
[    6.871231] [<ffffffff801d826c>] load_elf_binary+0x628/0x1214
[    6.872304] [<ffffffff8018ee7a>] bprm_execve+0x1f2/0x4e4
[    6.873243] [<ffffffff8018f90c>] do_execveat_common+0x16e/0x1ee
[    6.874258] [<ffffffff8018f9c8>] sys_execve+0x3c/0x48
[    6.875162] [<ffffffff80003556>] ret_from_syscall+0x0/0x2
[    6.877484] ---[ end trace 0000000000000000 ]---

This is because the mm->context.vdso_info is NULL in vfork case. From another side, mm->context.vdso_info either points to vdso info for RV64 or vdso info for compat, there's no need to bloat riscv's mm_context_t, we can handle the difference when setup the additional page for vdso.

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

Fixes 3092eb456375 ("riscv: compat: vdso: Add setup additional pages implementation")

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

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

---
 arch/riscv/include/asm/mmu.h |    1 -
 arch/riscv/kernel/vdso.c     |   13 ++++++++++---
 2 files changed, 10 insertions(+), 4 deletions(-)

arch/riscv/include/asm/mmu.h +0 -1

@@ -16,7 +16,6 @@ typedef struct {
 	atomic_long_t id;
 #endif
 	void *vdso;
-	void *vdso_info;
 #ifdef CONFIG_SMP
 	/* A local icache flush is needed before user execution can resume. */
 	cpumask_t icache_stale_mask;

arch/riscv/kernel/vdso.c +10 -3

@@ -60,6 +60,11 @@ struct __vdso_info {
 	struct vm_special_mapping *cm;
 };
 
+static struct __vdso_info vdso_info;
+#ifdef CONFIG_COMPAT
+static struct __vdso_info compat_vdso_info;
+#endif
+
 static int vdso_mremap(const struct vm_special_mapping *sm,
 		       struct vm_area_struct *new_vma)
 {

@@ -114,15 +119,18 @@ int vdso_join_timens(struct task_struct
 {
 	struct mm_struct *mm = task->mm;
 	struct vm_area_struct *vma;
-	struct __vdso_info *vdso_info = mm->context.vdso_info;
 
 	mmap_read_lock(mm);
 
 	for (vma = mm->mmap; vma; vma = vma->vm_next) {
 		unsigned long size = vma->vm_end - vma->vm_start;
 
-		if (vma_is_special_mapping(vma, vdso_info->dm))
+		if (vma_is_special_mapping(vma, vdso_info.dm))
 			zap_page_range(vma, vma->vm_start, size);
+#ifdef CONFIG_COMPAT
+		if (vma_is_special_mapping(vma, compat_vdso_info.dm))
+			zap_page_range(vma, vma->vm_start, size);
+#endif
 	}
 
 	mmap_read_unlock(mm);

@@ -264,7 +272,6 @@ static int __setup_additional_pages(stru
 
 	vdso_base += VVAR_SIZE;
 	mm->context.vdso = (void *)vdso_base;
-	mm->context.vdso_info = (void *)vdso_info;
 
 	ret =
 	   _install_special_mapping(mm, vdso_base, vdso_text_len,

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #62 lore raw

PATCH 62/862 riscv: Allow PROT_WRITE-only mmap()

From: Andrew Bresticker <[email protected]>

commit 9e2e6042a7ec6504fe8e366717afa2f40cf16488 upstream.

Commit 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") made mmap() return EINVAL if PROT_WRITE was set wihtout PROT_READ with the justification that a write-only PTE is considered a reserved PTE permission bit pattern in the privileged spec. This check is unnecessary since we let VM_WRITE imply VM_READ on RISC-V, and it is inconsistent with other architectures that don't support write-only PTEs, creating a potential software portability issue. Just remove the check altogether and let PROT_WRITE imply PROT_READ as is the case on other architectures.

Note that this also allows PROT_WRITE|PROT_EXEC mappings which were disallowed prior to the aforementioned commit; PROT_READ is implied in such mappings as well.

Fixes 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid")

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

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

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

---
 arch/riscv/kernel/sys_riscv.c |    3 ---
 1 file changed, 3 deletions(-)

arch/riscv/kernel/sys_riscv.c +0 -3

@@ -18,9 +18,6 @@ static long riscv_sys_mmap(unsigned long
 	if (unlikely(offset & (~PAGE_MASK >> page_shift_offset)))
 		return -EINVAL;
 
-	if (unlikely((prot & PROT_WRITE) && !(prot & PROT_READ)))
-		return -EINVAL;
-
 	return ksys_mmap_pgoff(addr, len, prot, flags, fd,
 			       offset >> (PAGE_SHIFT - page_shift_offset));
 }

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #63 lore raw

PATCH 63/862 riscv: Make VM_WRITE imply VM_READ

From: Andrew Bresticker <[email protected]>

commit 7ab72c597356be1e7f0f3d856e54ce78527f43c8 upstream.

RISC-V does not presently have write-only mappings as that PTE bit pattern is considered reserved in the privileged spec, so allow handling of read faults in VMAs that have VM_WRITE without VM_READ in order to be consistent with other architectures that have similar limitations.

Fixes 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid")

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

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

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

---
 arch/riscv/mm/fault.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/riscv/mm/fault.c +2 -1

@@ -184,7 +184,8 @@ static inline bool access_error(unsigned
 		}
 		break;
 	case EXC_LOAD_PAGE_FAULT:
-		if (!(vma->vm_flags & VM_READ)) {
+		/* Write implies read */
+		if (!(vma->vm_flags & (VM_READ | VM_WRITE))) {
 			return true;
 		}
 		break;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #64 lore raw

PATCH 64/862 riscv: always honor the CONFIG_CMDLINE_FORCE when parsing dtb

Link https://lore.kernel.org/r/PSBPR04MB399135DFC54928AB958D0638B1829@PSBPR04MB3991.apcprd04.prod.outlook.com open here

From: Wenting Zhang <[email protected]>

commit 10f6913c548b32ecb73801a16b120e761c6957ea upstream.

When CONFIG_CMDLINE_FORCE is enabled, cmdline provided by CONFIG_CMDLINE are always used. This allows CONFIG_CMDLINE to be used regardless of the result of device tree scanning.

This especially fixes the case where a device tree without the chosen node is supplied to the kernel. In such cases, early_init_dt_scan would return true. But inside early_init_dt_scan_chosen, the cmdline won't be updated as there is no chosen node in the device tree. As a result, CONFIG_CMDLINE is not copied into boot_command_line even if CONFIG_CMDLINE_FORCE is enabled. This commit allows properly update boot_command_line in this situation.

Fixes 8fd6e05c7463 ("arch: riscv: support kernel command line forcing when no DTB passed")

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

Reviewed-by Björn Töpel <[email protected]>

Reviewed-by Conor Dooley <[email protected]>

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

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

arch/riscv/kernel/setup.c +2 -2

@@ -252,10 +252,10 @@ static void __init parse_dtb(void)
 			pr_info("Machine model: %s\n", name);
 			dump_stack_set_arch_desc("%s (DT)", name);
 		}
-		return;
+	} else {
+		pr_err("No DTB passed to the kernel\n");
 	}
 
-	pr_err("No DTB passed to the kernel\n");
 #ifdef CONFIG_CMDLINE_FORCE
 	strscpy(boot_command_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
 	pr_info("Forcing kernel command line to: %s\n", boot_command_line);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #65 lore raw

PATCH 65/862 riscv: Pass -mno-relax only on lld < 15.0.0

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

From: Fangrui Song <[email protected]>

commit 3cebf80e9a0d3adcb174053be32c88a640b3344b upstream.

lld since llvm:6611d58f5bbc ("[ELF] Relax R_RISCV_ALIGN"), which will be included in the 15.0.0 release, has implemented some RISC-V linker relaxation. -mno-relax is no longer needed in KBUILD_CFLAGS/KBUILD_AFLAGS to suppress R_RISCV_ALIGN which older lld can not handle:

ld.lld: error: capability.c:(.fixup+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax but the .o is already compiled with -mno-relax

Signed-off-by Fangrui Song <[email protected]>

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

Reviewed-by Nick Desaulniers <[email protected]>

Tested-by Nick Desaulniers <[email protected]>

Tested-by Nathan Chancellor <[email protected]>

Tested-by Conor Dooley <[email protected]>

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

---
 arch/riscv/Makefile |    2 ++
 1 file changed, 2 insertions(+)

arch/riscv/Makefile +2 -0

@@ -37,6 +37,7 @@ else
 endif
 
 ifeq ($(CONFIG_LD_IS_LLD),y)
+ifeq ($(shell test $(CONFIG_LLD_VERSION) -lt 150000; echo $$?),0)
 	KBUILD_CFLAGS += -mno-relax
 	KBUILD_AFLAGS += -mno-relax
 ifndef CONFIG_AS_IS_LLVM

@@ -44,6 +45,7 @@ ifndef CONFIG_AS_IS_LLVM
 	KBUILD_AFLAGS += -Wa,-mno-relax
 endif
 endif
+endif
 
 # ISA string setting
 riscv-march-$(CONFIG_ARCH_RV32I)	:= rv32ima

Greg Kroah-Hartman

author maintainer

2022-10-19 13:53 UTC #66 lore raw

PATCH 66/862 UM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK

From: Huacai Chen <[email protected]>

commit 16c546e148fa6d14a019431436a6f7b4087dbccd 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.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] [<90000000002086d8>] show_stack+0x38/0x14c
[    3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88
[    3.217625] [<900000000023d268>] __warn+0xd0/0x100
[    3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc
[    3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0
[    3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4
[    3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4
[    3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0
[    3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100
[    3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94
[    3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160
[    3.281824] ---[ end trace 8b484262b4b8c24c ]---

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

Signed-off-by Richard Weinberger <[email protected]>

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

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

arch/um/kernel/um_arch.c +1 -1

@@ -96,7 +96,7 @@ static int show_cpuinfo(struct seq_file
 
 static void *c_start(struct seq_file *m, loff_t *pos)
 {
-	return *pos < NR_CPUS ? cpu_data + *pos : NULL;
+	return *pos < nr_cpu_ids ? cpu_data + *pos : NULL;
 }
 
 static void *c_next(struct seq_file *m, void *v, loff_t *pos)

Greg Kroah-Hartman

author maintainer

2022-10-19 09:11 UTC #67 lore raw

PATCH 67/862 nvmem: core: Fix memleak in nvmem_register()

From: Gaosheng Cui <[email protected]>

commit bd1244561fa2a4531ded40dbf09c9599084f8b29 upstream.

dev_set_name will alloc memory for nvmem->dev.kobj.name in nvmem_register, when nvmem_validate_keepouts failed, nvmem's memory will be freed and return, but nobody will free memory for nvmem->dev.kobj.name, there will be memleak, so moving nvmem_validate_keepouts() after device_register() and let the device core deal with cleaning name in error cases.

Fixes de0534df9347 ("nvmem: core: fix error handling while validating keepout regions")

Signed-off-by Gaosheng Cui <[email protected]>

Signed-off-by Srinivas Kandagatla <[email protected]>

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

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

---
 drivers/nvmem/core.c |   15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

drivers/nvmem/core.c +6 -9

@@ -829,21 +829,18 @@ struct nvmem_device *nvmem_register(cons
 	nvmem->dev.groups = nvmem_dev_groups;
 #endif
 
-	if (nvmem->nkeepout) {
-		rval = nvmem_validate_keepouts(nvmem);
-		if (rval) {
-			ida_free(&nvmem_ida, nvmem->id);
-			kfree(nvmem);
-			return ERR_PTR(rval);
-		}
-	}
-
 	dev_dbg(&nvmem->dev, "Registering nvmem device %s\n", config->name);
 
 	rval = device_register(&nvmem->dev);
 	if (rval)
 		goto err_put_device;
 
+	if (nvmem->nkeepout) {
+		rval = nvmem_validate_keepouts(nvmem);
+		if (rval)
+			goto err_device_del;
+	}
+
 	if (config->compat) {
 		rval = nvmem_sysfs_setup_compat(nvmem, config);
 		if (rval)

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #68 lore raw

PATCH 68/862 nvme-multipath: fix possible hang in live ns resize with ANA access

From: Sagi Grimberg <[email protected]>

commit 72e3b8883a36e80ebfa41015c7b6926ce31ace05 upstream.

When we revalidate paths as part of ns size change (as of commit e7d65803e2bb), it is possible that during the path revalidation, the only paths that is IO capable (i.e. optimized/non-optimized) are the ones that ns resize was not yet informed to the host, which will cause inflight requests to be requeued (as we have available paths but none are IO capable). These requests on the requeue list are waiting for someone to resubmit them at some point.

The IO capable paths will eventually notify the ns resize change to the host, but there is nothing that will kick the requeue list to resubmit the queued requests.

Fix this by always kicking the requeue list, and if no IO capable path exists, these requests will be queued again.

A typical log that indicates that IOs are requeued:
--
nvme nvme1: creating 4 I/O queues.
nvme nvme1: new ctrl: "testnqn1"
nvme nvme2: creating 4 I/O queues.
nvme nvme2: mapped 4/0/0 default/read/poll queues. nvme nvme2: new ctrl: NQN "testnqn1", addr 127.0.0.1:8009 nvme nvme1: rescanning namespaces.
nvme1n1: detected capacity change from 2097152 to 4194304 block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O nvme nvme2: rescanning namespaces.
--

Reported-by Yogev Cohen <[email protected]>

Fixes e7d65803e2bb ("nvme-multipath: revalidate paths during rescan")

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

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

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

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

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

drivers/nvme/host/multipath.c +1 -0

@@ -182,6 +182,7 @@ void nvme_mpath_revalidate_paths(struct
 
 	for_each_node(node)
 		rcu_assign_pointer(head->current_path[node], NULL);
+	kblockd_schedule_work(&head->requeue_work);
 }
 
 static bool nvme_path_is_disabled(struct nvme_ns *ns)

Greg Kroah-Hartman

author maintainer

2022-10-19 08:46 UTC #69 lore raw

PATCH 69/862 Revert "drm/amdgpu: use dirty framebuffer helper"

From: Hamza Mahfooz <[email protected]>

commit 17d819e2828cacca2e4c909044eb9798ed379cd2 upstream.

This reverts commit 66f99628eb24409cb8feb5061f78283c8b65f820.

Unfortunately, that commit causes performance regressions on non-PSR setups. So, just revert it until FB_DAMAGE_CLIPS support can be added.

Link https://gitlab.freedesktop.org/drm/amd/-/issues/2189

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

Fixes 66f99628eb2440 ("drm/amdgpu: use dirty framebuffer helper")

Fixes abbc7a3dafb91b ("drm/amdgpu: don't register a dirty callback for non-atomic")

Signed-off-by Hamza Mahfooz <[email protected]>

Acked-by Alex Deucher <[email protected]>

Signed-off-by Alex Deucher <[email protected]>

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

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |   14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +2 ~~-12~~

@@ -38,8 +38,6 @@
 #include <linux/pci.h>
 #include <linux/pm_runtime.h>
 #include <drm/drm_crtc_helper.h>
-#include <drm/drm_damage_helper.h>
-#include <drm/drm_drv.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_gem_framebuffer_helper.h>
 #include <drm/drm_fb_helper.h>

@@ -500,12 +498,6 @@ static const struct drm_framebuffer_func
 	.create_handle = drm_gem_fb_create_handle,
 };
 
-static const struct drm_framebuffer_funcs amdgpu_fb_funcs_atomic = {
-	.destroy = drm_gem_fb_destroy,
-	.create_handle = drm_gem_fb_create_handle,
-	.dirty = drm_atomic_helper_dirtyfb,
-};
-
 uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
 					  uint64_t bo_flags)
 {

@@ -1108,10 +1100,8 @@ static int amdgpu_display_gem_fb_verify_
 	if (ret)
 		goto err;
 
-	if (drm_drv_uses_atomic_modeset(dev))
-		ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs_atomic);
-	else
-		ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
+	ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
+
 	if (ret)
 		goto err;

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #70 lore raw

PATCH 70/862 dm: verity-loadpin: Only trust verity targets with enforcement

From: Matthias Kaehlcke <[email protected]>

commit 916ef6232cc4b84db7082b4c3d3cf1753d9462ba upstream.

Verity targets can be configured to ignore corrupted data blocks. LoadPin must only trust verity targets that are configured to perform some kind of enforcement when data corruption is detected, like returning an error, restarting the system or triggering a panic.

Fixes b6c1c5745ccc ("dm: Add verity helpers for LoadPin")

Reported-by Sarthak Kukreti <[email protected]>

Signed-off-by Matthias Kaehlcke <[email protected]>

Reviewed-by Sarthak Kukreti <[email protected]>

Link https://lore.kernel.org/r/20220907133055.1.Ic8a1dafe960dc0f8302e189642bc88ebb785d274@changeid open here

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

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

---
 drivers/md/dm-verity-loadpin.c |  8 ++++++++
 drivers/md/dm-verity-target.c  | 16 ++++++++++++++++
 drivers/md/dm-verity.h         |  1 +
 3 files changed, 25 insertions(+)

drivers/md/dm-verity-loadpin.c +8 -0

index 387ec43aef72..4f78cc55c251 100644
@@ -14,6 +14,7 @@ LIST_HEAD(dm_verity_loadpin_trusted_root_digests);
 
 static bool is_trusted_verity_target(struct dm_target *ti)
 {
+	int verity_mode;
 	u8 *root_digest;
 	unsigned int digest_size;
 	struct dm_verity_loadpin_trusted_root_digest *trd;

@@ -22,6 +23,13 @@ static bool is_trusted_verity_target(struct dm_target *ti)
 	if (!dm_is_verity_target(ti))
 		return false;
 
+	verity_mode = dm_verity_get_mode(ti);
+
+	if ((verity_mode != DM_VERITY_MODE_EIO) &&
+	    (verity_mode != DM_VERITY_MODE_RESTART) &&
+	    (verity_mode != DM_VERITY_MODE_PANIC))
+		return false;
+
 	if (dm_verity_get_root_digest(ti, &root_digest, &digest_size))
 		return false;

drivers/md/dm-verity-target.c +16 -0

index 94b6cb599db4..8a00cc42e498 100644
@@ -1446,6 +1446,22 @@ bool dm_is_verity_target(struct dm_target *ti)
 	return ti->type->module == THIS_MODULE;
 }
 
+/*
+ * Get the verity mode (error behavior) of a verity target.
+ *
+ * Returns the verity mode of the target, or -EINVAL if 'ti' is not a verity
+ * target.
+ */
+int dm_verity_get_mode(struct dm_target *ti)
+{
+	struct dm_verity *v = ti->private;
+
+	if (!dm_is_verity_target(ti))
+		return -EINVAL;
+
+	return v->mode;
+}
+
 /*
  * Get the root digest of a verity target.
  *

drivers/md/dm-verity.h +1 -0

index 45455de1b4bc..98f306ec6a33 100644
@@ -134,6 +134,7 @@ extern int verity_hash_for_block(struct dm_verity *v, struct dm_verity_io *io,
 				 sector_t block, u8 *digest, bool *is_zero);
 
 extern bool dm_is_verity_target(struct dm_target *ti);
+extern int dm_verity_get_mode(struct dm_target *ti);
 extern int dm_verity_get_root_digest(struct dm_target *ti, u8 **root_digest,
 				     unsigned int *digest_size);

Signature · 1 line

2.38.0

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #71 lore raw

PATCH 71/862 dmaengine: mxs: use platform_driver_register

From: Dario Binacchi <[email protected]>

commit 26696d4657167112a1079f86cba1739765c1360e upstream.

Driver registration fails on SOC imx8mn as its supplier, the clock control module, is probed later than subsys initcall level. This driver uses platform_driver_probe which is not compatible with deferred probing and won't be probed again later if probe function fails due to clock not being available at that time.

This patch replaces the use of platform_driver_probe with platform_driver_register which will allow probing the driver later again when the clock control module will be available.

The __init annotation has been dropped because it is not compatible with deferred probing. The code is not executed once and its memory cannot be freed.

Fixes a580b8c5429a ("dmaengine: mxs-dma: add dma support for i.MX23/28")

Co-developed-by Michael Trimarchi <[email protected]>

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

Signed-off-by Dario Binacchi <[email protected]>

Acked-by Sascha Hauer <[email protected]>

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

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

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

---
 drivers/dma/mxs-dma.c |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

drivers/dma/mxs-dma.c +4 -7

@@ -670,7 +670,7 @@ static enum dma_status mxs_dma_tx_status
 	return mxs_chan->status;
 }
 
-static int __init mxs_dma_init(struct mxs_dma_engine *mxs_dma)
+static int mxs_dma_init(struct mxs_dma_engine *mxs_dma)
 {
 	int ret;

@@ -741,7 +741,7 @@ static struct dma_chan *mxs_dma_xlate(st
 				     ofdma->of_node);
 }
 
-static int __init mxs_dma_probe(struct platform_device *pdev)
+static int mxs_dma_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
 	const struct mxs_dma_type *dma_type;

@@ -839,10 +839,7 @@ static struct platform_driver mxs_dma_dr
 		.name	= "mxs-dma",
 		.of_match_table = mxs_dma_dt_ids,
 	},
+	.probe = mxs_dma_probe,
 };
 
-static int __init mxs_dma_module_init(void)
-{
-	return platform_driver_probe(&mxs_dma_driver, mxs_dma_probe);
-}
-subsys_initcall(mxs_dma_module_init);
+builtin_platform_driver(mxs_dma_driver);

Greg Kroah-Hartman

author maintainer

2022-10-19 11:11 UTC #72 lore raw

PATCH 72/862 dmaengine: qcom-adm: fix wrong sizeof config in slave_config

From: Christian Marangi <[email protected]>

commit 7c8765308371be30f50c1b5b97618b731514b207 upstream.

Fix broken slave_config function that uncorrectly compare the peripheral_size with the size of the config pointer instead of the size of the config struct. This cause the crci value to be ignored and cause a kernel panic on any slave that use adm driver.

To fix this, compare to the size of the struct and NOT the size of the pointer.

Fixes 03de6b273805 ("dmaengine: qcom-adm: stop abusing slave_id config")

Signed-off-by Christian Marangi <[email protected]>

Cc [email protected] # v5.17+

Reviewed-by Arnd Bergmann <[email protected]>

Reviewed-by Dmitry Baryshkov <[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/dma/qcom/qcom_adm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/dma/qcom/qcom_adm.c +1 -1

@@ -494,7 +494,7 @@ static int adm_slave_config(struct dma_c
 
 	spin_lock_irqsave(&achan->vc.lock, flag);
 	memcpy(&achan->slave, cfg, sizeof(struct dma_slave_config));
-	if (cfg->peripheral_size == sizeof(config))
+	if (cfg->peripheral_size == sizeof(*config))
 		achan->crci = config->crci;
 	spin_unlock_irqrestore(&achan->vc.lock, flag);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:48 UTC #73 lore raw

PATCH 73/862 dmaengine: qcom-adm: fix wrong calling convention for prep_slave_sg

From: Christian Marangi <[email protected]>

commit b9d2140c3badf4107973ad77c5a0ec3075705c85 upstream.

The calling convention for pre_slave_sg is to return NULL on error and provide an error log to the system. Qcom-adm instead provide error pointer when an error occur. This indirectly cause kernel panic for example for the nandc driver that checks only if the pointer returned by device_prep_slave_sg is not NULL. Returning an error pointer makes nandc think the device_prep_slave_sg function correctly completed and makes the kernel panics later in the code.

While nandc is the one that makes the kernel crash, it was pointed out that the real problem is qcom-adm not following calling convention for that function.

To fix this, drop returning error pointer and return NULL with an error log.

Fixes 03de6b273805 ("dmaengine: qcom-adm: stop abusing slave_id config")

Fixes 5c9f8c2dbdbe ("dmaengine: qcom: Add ADM driver")

Signed-off-by Christian Marangi <[email protected]>

Cc [email protected] # v5.11+

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/dma/qcom/qcom_adm.c |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

drivers/dma/qcom/qcom_adm.c +13 -7

@@ -379,13 +379,13 @@ static struct dma_async_tx_descriptor *a
 		if (blk_size < 0) {
 			dev_err(adev->dev, "invalid burst value: %d\n",
 				burst);
-			return ERR_PTR(-EINVAL);
+			return NULL;
 		}
 
 		crci = achan->crci & 0xf;
 		if (!crci || achan->crci > 0x1f) {
 			dev_err(adev->dev, "invalid crci value\n");
-			return ERR_PTR(-EINVAL);
+			return NULL;
 		}
 	}

@@ -403,8 +403,10 @@ static struct dma_async_tx_descriptor *a
 	}
 
 	async_desc = kzalloc(sizeof(*async_desc), GFP_NOWAIT);
-	if (!async_desc)
-		return ERR_PTR(-ENOMEM);
+	if (!async_desc) {
+		dev_err(adev->dev, "not enough memory for async_desc struct\n");
+		return NULL;
+	}
 
 	async_desc->mux = achan->mux ? ADM_CRCI_CTL_MUX_SEL : 0;
 	async_desc->crci = crci;

@@ -414,8 +416,10 @@ static struct dma_async_tx_descriptor *a
 				sizeof(*cple) + 2 * ADM_DESC_ALIGN;
 
 	async_desc->cpl = kzalloc(async_desc->dma_len, GFP_NOWAIT);
-	if (!async_desc->cpl)
+	if (!async_desc->cpl) {
+		dev_err(adev->dev, "not enough memory for cpl struct\n");
 		goto free;
+	}
 
 	async_desc->adev = adev;

@@ -437,8 +441,10 @@ static struct dma_async_tx_descriptor *a
 	async_desc->dma_addr = dma_map_single(adev->dev, async_desc->cpl,
 					      async_desc->dma_len,
 					      DMA_TO_DEVICE);
-	if (dma_mapping_error(adev->dev, async_desc->dma_addr))
+	if (dma_mapping_error(adev->dev, async_desc->dma_addr)) {
+		dev_err(adev->dev, "dma mapping error for cpl\n");
 		goto free;
+	}
 
 	cple_addr = async_desc->dma_addr + ((void *)cple - async_desc->cpl);

@@ -454,7 +460,7 @@ static struct dma_async_tx_descriptor *a
 
 free:
 	kfree(async_desc);
-	return ERR_PTR(-ENOMEM);
+	return NULL;
 }
 
 /**

Greg Kroah-Hartman

author maintainer

2022-10-19 08:45 UTC #74 lore raw

PATCH 74/862 drm/virtio: Check whether transferred 2D BO is shmem

From: Dmitry Osipenko <[email protected]>

commit e473216b42aa1fd9fc6b94b608b42c210c655908 upstream.

Transferred 2D BO always must be a shmem BO. Add check for that to prevent NULL dereference if userspace passes a VRAM BO.

Reviewed-by Emil Velikov <[email protected]>

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

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

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

drivers/gpu/drm/virtio/virtgpu_vq.c +1 -1

@@ -597,7 +597,7 @@ void virtio_gpu_cmd_transfer_to_host_2d(
 	bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
 	struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
 
-	if (use_dma_api)
+	if (virtio_gpu_is_shmem(bo) && use_dma_api)
 		dma_sync_sgtable_for_device(vgdev->vdev->dev.parent,
 					    shmem->pages, DMA_TO_DEVICE);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:48 UTC #75 lore raw

PATCH 75/862 drm/virtio: Unlock reservations on virtio_gpu_object_shmem_init() error

From: Dmitry Osipenko <[email protected]>

commit fdf0ff4d12cbcd76b53f27c96ce51ddca400884a upstream.

Unlock reservations in the error code path of virtio_gpu_object_create() to silence debug warning splat produced by ww_mutex_destroy(&obj->lock) when GEM is released with the held lock.

Fixes 30172efbfb84 ("drm/virtio: blob prep: refactor getting pages and attaching backing")

Reviewed-by Emil Velikov <[email protected]>

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

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

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

drivers/gpu/drm/virtio/virtgpu_object.c +2 -0

@@ -248,6 +248,8 @@ int virtio_gpu_object_create(struct virt
 
 	ret = virtio_gpu_object_shmem_init(vgdev, bo, &ents, &nents);
 	if (ret != 0) {
+		if (fence)
+			virtio_gpu_array_unlock_resv(objs);
 		virtio_gpu_array_put_free(objs);
 		virtio_gpu_free_object(&shmem_obj->base);
 		return ret;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:48 UTC #76 lore raw

PATCH 76/862 drm/virtio: Unlock reservations on dma_resv_reserve_fences() error

From: Dmitry Osipenko <[email protected]>

commit 0f877398d30e1df657a31a62f7c7de1869b072b5 upstream.

Unlock reservations on dma_resv_reserve_fences() error to fix recursive locking of the reservations when this error happens.

Fixes c8d4c18bfbc4 ("dma-buf/drivers: make reserving a shared slot mandatory v4")

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

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

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

---
 drivers/gpu/drm/virtio/virtgpu_gem.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/gpu/drm/virtio/virtgpu_gem.c +3 -1

@@ -228,8 +228,10 @@ int virtio_gpu_array_lock_resv(struct vi
 
 	for (i = 0; i < objs->nents; ++i) {
 		ret = dma_resv_reserve_fences(objs->objs[i]->resv, 1);
-		if (ret)
+		if (ret) {
+			virtio_gpu_array_unlock_resv(objs);
 			return ret;
+		}
 	}
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2022-10-19 08:45 UTC #77 lore raw

PATCH 77/862 drm/virtio: Use appropriate atomic state in virtio_gpu_plane_cleanup_fb()

From: Dmitry Osipenko <[email protected]>

commit 4656b3a26a9e9fe5f04bfd2ab55b066266ba7f4d upstream.

Make virtio_gpu_plane_cleanup_fb() to clean the state which DRM core wants to clean up and not the current plane's state. Normally the older atomic state is cleaned up, but the newer state could also be cleaned up in case of aborted commits.

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

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

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

drivers/gpu/drm/virtio/virtgpu_plane.c +3 -3

@@ -266,14 +266,14 @@ static int virtio_gpu_plane_prepare_fb(s
 }
 
 static void virtio_gpu_plane_cleanup_fb(struct drm_plane *plane,
-					struct drm_plane_state *old_state)
+					struct drm_plane_state *state)
 {
 	struct virtio_gpu_framebuffer *vgfb;
 
-	if (!plane->state->fb)
+	if (!state->fb)
 		return;
 
-	vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
+	vgfb = to_virtio_gpu_framebuffer(state->fb);
 	if (vgfb->fence) {
 		dma_fence_put(&vgfb->fence->f);
 		vgfb->fence = NULL;

Greg Kroah-Hartman

author maintainer

2022-10-19 13:45 UTC #78 lore raw

PATCH 78/862 drm/udl: Restore display mode on resume

From: Takashi Iwai <[email protected]>

commit 6d6e732835db92e66c28dbcf258a7e3d3c71420d upstream.

Restore the display mode whne resuming from suspend. Currently, the display remains dark.

On resume, the CRTC's mode does not change, but the 'active' flag changes to 'true'. Taking this into account when considering a mode switch restores the display mode.

The bug is reproducable by using Gnome with udl and observing the adapter's suspend/resume behavior.

Actually, the whole check added in udl_simple_display_pipe_enable() about the crtc_state->mode_changed was bogus. We should drop the whole check and always apply the mode change in this function.

[ tiwai -- Drop the mode_changed check entirely instead, per Daniel's
suggestion ]

Fixes 997d33c35618 ("drm/udl: Inline DPMS code into CRTC enable and disable functions")

Reviewed-by Daniel Vetter <[email protected]>

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

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

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

---
 drivers/gpu/drm/udl/udl_modeset.c |    3 ---
 1 file changed, 3 deletions(-)

drivers/gpu/drm/udl/udl_modeset.c +0 -3

@@ -382,9 +382,6 @@ udl_simple_display_pipe_enable(struct dr
 
 	udl_handle_damage(fb, &shadow_plane_state->data[0], 0, 0, fb->width, fb->height);
 
-	if (!crtc_state->mode_changed)
-		return;
-
 	/* enable display */
 	udl_crtc_write_mode_to_hw(crtc);
 }

Greg Kroah-Hartman

author maintainer

2022-10-19 08:50 UTC #79 lore raw

PATCH 79/862 arm64: mte: move register initialization to C

From: Peter Collingbourne <[email protected]>

commit 973b9e37330656dec719ede508e4dc40e5c2d80c upstream.

If FEAT_MTE2 is disabled via the arm64.nomte command line argument on a CPU that claims to support FEAT_MTE2, the kernel will use Tagged Normal in the MAIR. If we interpret arm64.nomte to mean that the CPU does not in fact implement FEAT_MTE2, setting the system register like this may lead to UNSPECIFIED behavior. Fix it by arranging for MAIR to be set in the C function cpu_enable_mte which is called based on the sanitized version of the system register.

There is no need for the rest of the MTE-related system register initialization to happen from assembly, with the exception of TCR_EL1, which must be set to include at least TBI1 because the secondary CPUs access KASan-allocated data structures early. Therefore, make the TCR_EL1 initialization unconditional and move the rest of the initialization to cpu_enable_mte so that we no longer have a dependency on the unsanitized ID register value.

Co-developed-by Evgenii Stepanov <[email protected]>

Signed-off-by Peter Collingbourne <[email protected]>

Signed-off-by Evgenii Stepanov <[email protected]>

Reported-by kernel test robot <[email protected]>

Fixes 3b714d24ef17 ("arm64: mte: CPU feature detection and initial sysreg configuration")

Cc <[email protected]> # 5.10.x

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

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

---
 arch/arm64/include/asm/mte.h   |    5 ++++
 arch/arm64/kernel/cpufeature.c |    3 +-
 arch/arm64/kernel/mte.c        |   51 +++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/suspend.c    |    2 +
 arch/arm64/mm/proc.S           |   46 ++++--------------------------------
 5 files changed, 65 insertions(+), 42 deletions(-)

arch/arm64/include/asm/mte.h +5 -0

@@ -42,7 +42,9 @@ void mte_sync_tags(pte_t old_pte, pte_t
 void mte_copy_page_tags(void *kto, const void *kfrom);
 void mte_thread_init_user(void);
 void mte_thread_switch(struct task_struct *next);
+void mte_cpu_setup(void);
 void mte_suspend_enter(void);
+void mte_suspend_exit(void);
 long set_mte_ctrl(struct task_struct *task, unsigned long arg);
 long get_mte_ctrl(struct task_struct *task);
 int mte_ptrace_copy_tags(struct task_struct *child, long request,

@@ -72,6 +74,9 @@ static inline void mte_thread_switch(str
 static inline void mte_suspend_enter(void)
 {
 }
+static inline void mte_suspend_exit(void)
+{
+}
 static inline long set_mte_ctrl(struct task_struct *task, unsigned long arg)
 {
 	return 0;

arch/arm64/kernel/cpufeature.c +2 -1

@@ -2034,7 +2034,8 @@ static void bti_enable(const struct arm6
 static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
 {
 	sysreg_clear_set(sctlr_el1, 0, SCTLR_ELx_ATA | SCTLR_EL1_ATA0);
-	isb();
+
+	mte_cpu_setup();
 
 	/*
 	 * Clear the tags in the zero page. This needs to be done via the

arch/arm64/kernel/mte.c +51 -0

63 lines not on this page · raw message

arch/arm64/kernel/suspend.c +2 -0

@@ -43,6 +43,8 @@ void notrace __cpu_suspend_exit(void)
 {
 	unsigned int cpu = smp_processor_id();
 
+	mte_suspend_exit();
+
 	/*
 	 * We are resuming from reset with the idmap active in TTBR0_EL1.
 	 * We must uninstall the idmap and restore the expected MMU

arch/arm64/mm/proc.S +5 ~~-41~~

68 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2022-10-19 08:55 UTC #80 lore raw

PATCH 80/862 arm64: mte: Avoid setting PG_mte_tagged if no tags cleared or restored

From: Catalin Marinas <[email protected]>

commit a8e5e5146ad08d794c58252bab00b261045ef16d upstream.

Prior to commit 69e3b846d8a7 ("arm64: mte: Sync tags for pages where PTE is untagged"), mte_sync_tags() was only called for pte_tagged() entries (those mapped with PROT_MTE). Therefore mte_sync_tags() could safely use test_and_set_bit(PG_mte_tagged, &page->flags) without inadvertently setting PG_mte_tagged on an untagged page.

The above commit was required as guests may enable MTE without any control at the stage 2 mapping, nor a PROT_MTE mapping in the VMM. However, the side-effect was that any page with a PTE that looked like swap (or migration) was getting PG_mte_tagged set automatically. A subsequent page copy (e.g. migration) copied the tags to the destination page even if the tags were owned by KASAN.

This issue was masked by the page_kasan_tag_reset() call introduced in commit e5b8d9218951 ("arm64: mte: reset the page tag in page->flags"). When this commit was reverted (20794545c146), KASAN started reporting access faults because the overriding tags in a page did not match the original page->flags (with CONFIG_KASAN_HW_TAGS=y):

  BUG: KASAN: invalid-access in copy_page+0x10/0xd0 arch/arm64/lib/copy_page.S:26
  Read at addr f5ff000017f2e000 by task syz-executor.1/2218
  Pointer tag: [f5], memory tag: [f2]

Move the PG_mte_tagged bit setting from mte_sync_tags() to the actual place where tags are cleared (mte_sync_page_tags()) or restored (mte_restore_tags()).

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

Reported-by [email protected]

Fixes 69e3b846d8a7 ("arm64: mte: Sync tags for pages where PTE is untagged")

Cc <[email protected]> # 5.14.x

Cc Steven Price <[email protected]>

Cc Andrey Konovalov <[email protected]>

Cc Vincenzo Frascino <[email protected]>

Cc Will Deacon <[email protected]>

Reviewed-by Steven Price <[email protected]>

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

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

---
 arch/arm64/kernel/mte.c |    9 +++++++--
 arch/arm64/mm/mteswap.c |    7 ++++++-
 2 files changed, 13 insertions(+), 3 deletions(-)

arch/arm64/kernel/mte.c +7 -2

@@ -48,7 +48,12 @@ static void mte_sync_page_tags(struct pa
 	if (!pte_is_tagged)
 		return;
 
-	mte_clear_page_tags(page_address(page));
+	/*
+	 * Test PG_mte_tagged again in case it was racing with another
+	 * set_pte_at().
+	 */
+	if (!test_and_set_bit(PG_mte_tagged, &page->flags))
+		mte_clear_page_tags(page_address(page));
 }
 
 void mte_sync_tags(pte_t old_pte, pte_t pte)

@@ -64,7 +69,7 @@ void mte_sync_tags(pte_t old_pte, pte_t
 
 	/* if PG_mte_tagged is set, tags have already been initialised */
 	for (i = 0; i < nr_pages; i++, page++) {
-		if (!test_and_set_bit(PG_mte_tagged, &page->flags))
+		if (!test_bit(PG_mte_tagged, &page->flags))
 			mte_sync_page_tags(page, old_pte, check_swap,
 					   pte_is_tagged);
 	}

arch/arm64/mm/mteswap.c +6 -1

@@ -53,7 +53,12 @@ bool mte_restore_tags(swp_entry_t entry,
 	if (!tags)
 		return false;
 
-	mte_restore_page_tags(page_address(page), tags);
+	/*
+	 * Test PG_mte_tagged again in case it was racing with another
+	 * set_pte_at().
+	 */
+	if (!test_and_set_bit(PG_mte_tagged, &page->flags))
+		mte_restore_page_tags(page_address(page), tags);
 
 	return true;
 }

Greg Kroah-Hartman

author maintainer

2022-10-19 08:46 UTC #81 lore raw

PATCH 81/862 arm64: errata: Add Cortex-A55 to the repeat tlbi list

From: James Morse <[email protected]>

commit 171df58028bf4649460fb146a56a58dcb0c8f75a upstream.

Cortex-A55 is affected by an erratum where in rare circumstances the CPUs may not handle a race between a break-before-make sequence on one CPU, and another CPU accessing the same page. This could allow a store to a page that has been unmapped.

Work around this by adding the affected CPUs to the list that needs TLB sequences to be done twice.

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

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

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

---
 Documentation/arm64/silicon-errata.rst |    2 ++
 arch/arm64/Kconfig                     |   17 +++++++++++++++++
 arch/arm64/kernel/cpu_errata.c         |    5 +++++
 3 files changed, 24 insertions(+)

Documentation/arm64/silicon-errata.rst +2 -0

@@ -76,6 +76,8 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A55      | #1530923        | ARM64_ERRATUM_1530923       |
 +----------------+-----------------+-----------------+-----------------------------+
+| ARM            | Cortex-A55      | #2441007        | ARM64_ERRATUM_2441007       |
++----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075        |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A57      | #852523         | N/A                         |

arch/arm64/Kconfig +17 -0

@@ -632,6 +632,23 @@ config ARM64_ERRATUM_1530923
 config ARM64_WORKAROUND_REPEAT_TLBI
 	bool
 
+config ARM64_ERRATUM_2441007
+	bool "Cortex-A55: Completion of affected memory accesses might not be guaranteed by completion of a TLBI"
+	default y
+	select ARM64_WORKAROUND_REPEAT_TLBI
+	help
+	  This option adds a workaround for ARM Cortex-A55 erratum #2441007.
+
+	  Under very rare circumstances, affected Cortex-A55 CPUs
+	  may not handle a race between a break-before-make sequence on one
+	  CPU, and another CPU accessing the same page. This could allow a
+	  store to a page that has been unmapped.
+
+	  Work around this by adding the affected CPUs to the list that needs
+	  TLB sequences to be done twice.
+
+	  If unsure, say Y.
+
 config ARM64_ERRATUM_1286807
 	bool "Cortex-A76: Modification of the translation table for a virtual address might lead to read-after-read ordering violation"
 	default y

arch/arm64/kernel/cpu_errata.c +5 -0

@@ -214,6 +214,11 @@ static const struct arm64_cpu_capabiliti
 		ERRATA_MIDR_RANGE(MIDR_QCOM_KRYO_4XX_GOLD, 0xc, 0xe, 0xf, 0xe),
 	},
 #endif
+#ifdef CONFIG_ARM64_ERRATUM_2441007
+	{
+		ERRATA_MIDR_ALL_VERSIONS(MIDR_CORTEX_A55),
+	},
+#endif
 #ifdef CONFIG_ARM64_ERRATUM_2441009
 	{
 		/* Cortex-A510 r0p0 -> r1p1. Fixed in r1p2 */

Greg Kroah-Hartman

author maintainer

2022-10-19 08:47 UTC #82 lore raw

PATCH 82/862 clocksource/drivers/arm_arch_timer: Fix CNTPCT_LO and CNTVCT_LO value

From: Yang Guo <[email protected]>

commit af246cc6d0ed11318223606128bb0b09866c4c08 upstream.

CNTPCT_LO and CNTVCT_LO are defined by mistake in commit '8b82c4f883a7', so fix them according to the Arm ARM DDI 0487I.a, Table I2-4 "CNTBaseN memory map" as follows:

Offset    Register      Type Description
0x000     CNTPCT[31:0]  RO   Physical Count register.
0x004     CNTPCT[63:32] RO
0x008     CNTVCT[31:0]  RO   Virtual Count register.
0x00C     CNTVCT[63:32] RO

Fixes 8b82c4f883a7 ("clocksource/drivers/arm_arch_timer: Move MMIO timer programming over to CVAL")

Cc Daniel Lezcano <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Marc Zyngier <[email protected]>

Cc Mark Rutland <[email protected]>

Acked-by Marc Zyngier <[email protected]>

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

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

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

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

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

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

drivers/clocksource/arm_arch_timer.c +2 -2

@@ -44,8 +44,8 @@
 #define CNTACR_RWVT	BIT(4)
 #define CNTACR_RWPT	BIT(5)
 
-#define CNTVCT_LO	0x00
-#define CNTPCT_LO	0x08
+#define CNTPCT_LO	0x00
+#define CNTVCT_LO	0x08
 #define CNTFRQ		0x10
 #define CNTP_CVAL_LO	0x20
 #define CNTP_CTL	0x2c

Greg Kroah-Hartman

author maintainer

2022-10-19 09:06 UTC #83 lore raw

PATCH 83/862 mm/hugetlb: fix races when looking up a CONT-PTE/PMD size hugetlb page

Link https://lkml.kernel.org/r/635f43bdd85ac2615a58405da82b4d33c6e5eb05.1662017562.git.baolin.wang@linux.alibaba.com open here

From: Baolin Wang <[email protected]>

commit fac35ba763ed07ba93154c95ffc0c4a55023707f upstream.

On some architectures (like ARM64), it can support CONT-PTE/PMD size hugetlb, which means it can support not only PMD/PUD size hugetlb (2M and 1G), but also CONT-PTE/PMD size(64K and 32M) if a 4K page size specified.

So when looking up a CONT-PTE size hugetlb page by follow_page(), it will use pte_offset_map_lock() to get the pte entry lock for the CONT-PTE size hugetlb in follow_page_pte(). However this pte entry lock is incorrect for the CONT-PTE size hugetlb, since we should use huge_pte_lock() to get the correct lock, which is mm->page_table_lock.

That means the pte entry of the CONT-PTE size hugetlb under current pte lock is unstable in follow_page_pte(), we can continue to migrate or poison the pte entry of the CONT-PTE size hugetlb, which can cause some potential race issues, even though they are under the 'pte lock'.

For example, suppose thread A is trying to look up a CONT-PTE size hugetlb page by move_pages() syscall under the lock, however antoher thread B can migrate the CONT-PTE hugetlb page at the same time, which will cause thread A to get an incorrect page, if thread A also wants to do page migration, then data inconsistency error occurs.

Moreover we have the same issue for CONT-PMD size hugetlb in follow_huge_pmd().

To fix above issues, rename the follow_huge_pmd() as follow_huge_pmd_pte() to handle PMD and PTE level size hugetlb, which uses huge_pte_lock() to get the correct pte entry lock to make the pte entry stable.

Mike said:

Support for CONT_PMD/_PTE was added with bb9dd3df8ee9 ("arm64: hugetlb:
refactor find_num_contig()"). Patch series "Support for contiguous pte hugepages", v4. However, I do not believe these code paths were executed until migration support was added with 5480280d3f2d ("arm64/mm:
enable HugeTLB migration for contiguous bit HugeTLB pages") I would go with 5480280d3f2d for the Fixes: targe.

Fixes 5480280d3f2d ("arm64/mm: enable HugeTLB migration for contiguous bit HugeTLB pages")

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

Reviewed-by Mike Kravetz <[email protected]>

Cc David Hildenbrand <[email protected]>

Cc Muchun Song <[email protected]>

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

---
 include/linux/hugetlb.h |    8 ++++----
 mm/gup.c                |   14 +++++++++++++-
 mm/hugetlb.c            |   27 +++++++++++++--------------
 3 files changed, 30 insertions(+), 19 deletions(-)

include/linux/hugetlb.h +4 -4

@@ -207,8 +207,8 @@ struct page *follow_huge_addr(struct mm_
 struct page *follow_huge_pd(struct vm_area_struct *vma,
 			    unsigned long address, hugepd_t hpd,
 			    int flags, int pdshift);
-struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
-				pmd_t *pmd, int flags);
+struct page *follow_huge_pmd_pte(struct vm_area_struct *vma, unsigned long address,
+				 int flags);
 struct page *follow_huge_pud(struct mm_struct *mm, unsigned long address,
 				pud_t *pud, int flags);
 struct page *follow_huge_pgd(struct mm_struct *mm, unsigned long address,

@@ -312,8 +312,8 @@ static inline struct page *follow_huge_p
 	return NULL;
 }
 
-static inline struct page *follow_huge_pmd(struct mm_struct *mm,
-				unsigned long address, pmd_t *pmd, int flags)
+static inline struct page *follow_huge_pmd_pte(struct vm_area_struct *vma,
+				unsigned long address, int flags)
 {
 	return NULL;
 }

mm/gup.c +13 -1

@@ -530,6 +530,18 @@ static struct page *follow_page_pte(stru
 	if (WARN_ON_ONCE((flags & (FOLL_PIN | FOLL_GET)) ==
 			 (FOLL_PIN | FOLL_GET)))
 		return ERR_PTR(-EINVAL);
+
+	/*
+	 * Considering PTE level hugetlb, like continuous-PTE hugetlb on
+	 * ARM64 architecture.
+	 */
+	if (is_vm_hugetlb_page(vma)) {
+		page = follow_huge_pmd_pte(vma, address, flags);
+		if (page)
+			return page;
+		return no_page_table(vma, flags);
+	}
+
 retry:
 	if (unlikely(pmd_bad(*pmd)))
 		return no_page_table(vma, flags);

@@ -662,7 +674,7 @@ static struct page *follow_pmd_mask(stru
 	if (pmd_none(pmdval))
 		return no_page_table(vma, flags);
 	if (pmd_huge(pmdval) && is_vm_hugetlb_page(vma)) {
-		page = follow_huge_pmd(mm, address, pmd, flags);
+		page = follow_huge_pmd_pte(vma, address, flags);
 		if (page)
 			return page;
 		return no_page_table(vma, flags);

mm/hugetlb.c +13 ~~-14~~

@@ -6946,12 +6946,13 @@ follow_huge_pd(struct vm_area_struct *vm
 }
 
 struct page * __weak
-follow_huge_pmd(struct mm_struct *mm, unsigned long address,
-		pmd_t *pmd, int flags)
+follow_huge_pmd_pte(struct vm_area_struct *vma, unsigned long address, int flags)
 {
+	struct hstate *h = hstate_vma(vma);
+	struct mm_struct *mm = vma->vm_mm;
 	struct page *page = NULL;
 	spinlock_t *ptl;
-	pte_t pte;
+	pte_t *ptep, pte;
 
 	/*
 	 * FOLL_PIN is not supported for follow_page(). Ordinary GUP goes via

@@ -6961,17 +6962,15 @@ follow_huge_pmd(struct mm_struct *mm, un
 		return NULL;
 
 retry:
-	ptl = pmd_lockptr(mm, pmd);
-	spin_lock(ptl);
-	/*
-	 * make sure that the address range covered by this pmd is not
-	 * unmapped from other threads.
-	 */
-	if (!pmd_huge(*pmd))
-		goto out;
-	pte = huge_ptep_get((pte_t *)pmd);
+	ptep = huge_pte_offset(mm, address, huge_page_size(h));
+	if (!ptep)
+		return NULL;
+
+	ptl = huge_pte_lock(h, mm, ptep);
+	pte = huge_ptep_get(ptep);
 	if (pte_present(pte)) {
-		page = pmd_page(*pmd) + ((address & ~PMD_MASK) >> PAGE_SHIFT);
+		page = pte_page(pte) +
+			((address & ~huge_page_mask(h)) >> PAGE_SHIFT);
 		/*
 		 * try_grab_page() should always succeed here, because: a) we
 		 * hold the pmd (ptl) lock, and b) we've just checked that the

@@ -6987,7 +6986,7 @@ retry:
 	} else {
 		if (is_hugetlb_entry_migration(pte)) {
 			spin_unlock(ptl);
-			__migration_entry_wait_huge((pte_t *)pmd, ptl);
+			__migration_entry_wait_huge(ptep, ptl);
 			goto retry;
 		}
 		/*

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #84 lore raw

PATCH 84/862 mm/damon: validate if the pmd entry is present before accessing

Link https://lkml.kernel.org/r/58b1d1f5fbda7db49ca886d9ef6783e3dcbbbc98.1660805030.git.baolin.wang@linux.alibaba.com open here

From: Baolin Wang <[email protected]>

commit c8b9aff419303e4d4219b5ff64b1c7e062dee48e upstream.

pmd_huge() is used to validate if the pmd entry is mapped by a huge page, also including the case of non-present (migration or hwpoisoned) pmd entry on arm64 or x86 architectures. This means that pmd_pfn() can not get the correct pfn number for a non-present pmd entry, which will cause damon_get_page() to get an incorrect page struct (also may be NULL by pfn_to_online_page()), making the access statistics incorrect.

This means that the DAMON may make incorrect decision according to the incorrect statistics, for example, DAMON may can not reclaim cold page in time due to this cold page was regarded as accessed mistakenly if DAMOS_PAGEOUT operation is specified.

Moreover it does not make sense that we still waste time to get the page of the non-present entry. Just treat it as not-accessed and skip it, which maintains consistency with non-present pte level entries.

So add pmd entry present validation to fix the above issues.

Fixes 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces")

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

Reviewed-by SeongJae Park <[email protected]>

Reviewed-by Muchun Song <[email protected]>

Cc Mike Kravetz <[email protected]>

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

---
 mm/damon/vaddr.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

mm/damon/vaddr.c +10 -0

@@ -304,6 +304,11 @@ static int damon_mkold_pmd_entry(pmd_t *
 
 	if (pmd_huge(*pmd)) {
 		ptl = pmd_lock(walk->mm, pmd);
+		if (!pmd_present(*pmd)) {
+			spin_unlock(ptl);
+			return 0;
+		}
+
 		if (pmd_huge(*pmd)) {
 			damon_pmdp_mkold(pmd, walk->mm, addr);
 			spin_unlock(ptl);

@@ -431,6 +436,11 @@ static int damon_young_pmd_entry(pmd_t *
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	if (pmd_huge(*pmd)) {
 		ptl = pmd_lock(walk->mm, pmd);
+		if (!pmd_present(*pmd)) {
+			spin_unlock(ptl);
+			return 0;
+		}
+
 		if (!pmd_huge(*pmd)) {
 			spin_unlock(ptl);
 			goto regular_page;

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #85 lore raw

PATCH 85/862 mm/uffd: fix warning without PTE_MARKER_UFFD_WP compiled in

Link https://lkml.kernel.org/r/YzeR+R6b4bwBlBHh@x1n open here

From: Peter Xu <[email protected]>

commit 515778e2d790652a38a24554fdb7f21420d91efc upstream.

When PTE_MARKER_UFFD_WP not configured, it's still possible to reach pte marker code and trigger an warning. Add a few CONFIG_PTE_MARKER_UFFD_WP ifdefs to make sure the code won't be reached when not compiled in.

Fixes b1f9e876862d ("mm/uffd: enable write protection for shmem & hugetlbfs")

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

Reported-by <[email protected]>

Cc Axel Rasmussen <[email protected]>

Cc Brian Geffon <[email protected]>

Cc Edward Liaw <[email protected]>

Cc Liu Shixin <[email protected]>

Cc Mike Kravetz <[email protected]>

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

---
 mm/hugetlb.c  |    4 ++++
 mm/memory.c   |    2 ++
 mm/mprotect.c |    2 ++
 3 files changed, 8 insertions(+)

mm/hugetlb.c +4 -0

@@ -5059,6 +5059,7 @@ static void __unmap_hugepage_range(struc
 		 * unmapped and its refcount is dropped, so just clear pte here.
 		 */
 		if (unlikely(!pte_present(pte))) {
+#ifdef CONFIG_PTE_MARKER_UFFD_WP
 			/*
 			 * If the pte was wr-protected by uffd-wp in any of the
 			 * swap forms, meanwhile the caller does not want to

@@ -5070,6 +5071,7 @@ static void __unmap_hugepage_range(struc
 				set_huge_pte_at(mm, address, ptep,
 						make_pte_marker(PTE_MARKER_UFFD_WP));
 			else
+#endif
 				huge_pte_clear(mm, address, ptep, sz);
 			spin_unlock(ptl);
 			continue;

@@ -5098,11 +5100,13 @@ static void __unmap_hugepage_range(struc
 		tlb_remove_huge_tlb_entry(h, tlb, ptep, address);
 		if (huge_pte_dirty(pte))
 			set_page_dirty(page);
+#ifdef CONFIG_PTE_MARKER_UFFD_WP
 		/* Leave a uffd-wp pte marker if needed */
 		if (huge_pte_uffd_wp(pte) &&
 		    !(zap_flags & ZAP_FLAG_DROP_MARKER))
 			set_huge_pte_at(mm, address, ptep,
 					make_pte_marker(PTE_MARKER_UFFD_WP));
+#endif
 		hugetlb_count_sub(pages_per_huge_page(h), mm);
 		page_remove_rmap(page, vma, true);

mm/memory.c +2 -0

@@ -1393,10 +1393,12 @@ zap_install_uffd_wp_if_needed(struct vm_
 			      unsigned long addr, pte_t *pte,
 			      struct zap_details *details, pte_t pteval)
 {
+#ifdef CONFIG_PTE_MARKER_UFFD_WP
 	if (zap_drop_file_uffd_wp(details))
 		return;
 
 	pte_install_uffd_wp_if_needed(vma, addr, pte, pteval);
+#endif
 }
 
 static unsigned long zap_pte_range(struct mmu_gather *tlb,

mm/mprotect.c +2 -0

@@ -260,6 +260,7 @@ static unsigned long change_pte_range(st
 		} else {
 			/* It must be an none page, or what else?.. */
 			WARN_ON_ONCE(!pte_none(oldpte));
+#ifdef CONFIG_PTE_MARKER_UFFD_WP
 			if (unlikely(uffd_wp && !vma_is_anonymous(vma))) {
 				/*
 				 * For file-backed mem, we need to be able to

@@ -271,6 +272,7 @@ static unsigned long change_pte_range(st
 					   make_pte_marker(PTE_MARKER_UFFD_WP));
 				pages++;
 			}
+#endif
 		}
 	} while (pte++, addr += PAGE_SIZE, addr != end);
 	arch_leave_lazy_mmu_mode();

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #86 lore raw

PATCH 86/862 mm/mmap: undo ->mmap() when arch_validate_flags() fails

From: Carlos Llamas <[email protected]>

commit deb0f6562884b5b4beb883d73e66a7d3a1b96d99 upstream.

Commit c462ac288f2c ("mm: Introduce arch_validate_flags()") added a late check in mmap_region() to let architectures validate vm_flags. The check needs to happen after calling ->mmap() as the flags can potentially be modified during this callback.

If arch_validate_flags() check fails we unmap and free the vma. However, the error path fails to undo the ->mmap() call that previously succeeded and depending on the specific ->mmap() implementation this translates to reference increments, memory allocations and other operations what will not be cleaned up.

There are several places (mainly device drivers) where this is an issue. However, one specific example is bpf_map_mmap() which keeps count of the mappings in map->writecnt. The count is incremented on ->mmap() and then decremented on vm_ops->close(). When arch_validate_flags() fails this count is off since bpf_map_mmap_close() is never called.

One can reproduce this issue in arm64 devices with MTE support. Here the vm_flags are checked to only allow VM_MTE if VM_MTE_ALLOWED has been set previously. From userspace then is enough to pass the PROT_MTE flag to mmap() syscall to trigger the arch_validate_flags() failure.

The following program reproduces this issue:

  #include <stdio.h>
  #include <unistd.h>
  #include <linux/unistd.h>
  #include <linux/bpf.h>
  #include <sys/mman.h>

int main(void)

  {
	union bpf_attr attr = {
		.map_type = BPF_MAP_TYPE_ARRAY,
		.key_size = sizeof(int),
		.value_size = sizeof(long long),
		.max_entries = 256,
		.map_flags = BPF_F_MMAPABLE,
	};
	int fd;

	fd = syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));
	mmap(NULL, 4096, PROT_WRITE | PROT_MTE, MAP_SHARED, fd, 0);

	return 0;

}

By manually adding some log statements to the vm_ops callbacks we can confirm that when passing PROT_MTE to mmap() the map->writecnt is off upon ->release():

With PROT_MTE flag:

  root@debian:~# ./bpf-test
  [  111.263874] bpf_map_write_active_inc: map=9 writecnt=1
  [  111.288763] bpf_map_release: map=9 writecnt=1

Without PROT_MTE flag:

  root@debian:~# ./bpf-test
  [  157.816912] bpf_map_write_active_inc: map=10 writecnt=1
  [  157.830442] bpf_map_write_active_dec: map=10 writecnt=0
  [  157.832396] bpf_map_release: map=10 writecnt=0

This patch fixes the above issue by calling vm_ops->close() when the arch_validate_flags() check fails, after this we can proceed to unmap and free the vma on the error path.

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

Fixes c462ac288f2c ("mm: Introduce arch_validate_flags()")

Signed-off-by Carlos Llamas <[email protected]>

Reviewed-by Catalin Marinas <[email protected]>

Acked-by Andrii Nakryiko <[email protected]>

Reviewed-by Liam Howlett <[email protected]>

Cc Christian Brauner (Microsoft) <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Suren Baghdasaryan <[email protected]>

Cc <[email protected]> [5.10+]

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

---
 mm/mmap.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

mm/mmap.c +4 -1

@@ -1797,7 +1797,7 @@ unsigned long mmap_region(struct file *f
 	if (!arch_validate_flags(vma->vm_flags)) {
 		error = -EINVAL;
 		if (file)
-			goto unmap_and_free_vma;
+			goto close_and_free_vma;
 		else
 			goto free_vma;
 	}

@@ -1844,6 +1844,9 @@ out:
 
 	return addr;
 
+close_and_free_vma:
+	if (vma->vm_ops && vma->vm_ops->close)
+		vma->vm_ops->close(vma);
 unmap_and_free_vma:
 	fput(vma->vm_file);
 	vma->vm_file = NULL;

Greg Kroah-Hartman

author maintainer

2022-10-19 12:19 UTC #87 lore raw

PATCH 87/862 xen/gntdev: Prevent leaking grants

Link https://github.com/QubesOS/qubes-issues/issues/7631

From: M. Vefa Bicakci <[email protected]>

commit 0991028cd49567d7016d1b224fe0117c35059f86 upstream.

Prior to this commit, if a grant mapping operation failed partially, some of the entries in the map_ops array would be invalid, whereas all of the entries in the kmap_ops array would be valid. This in turn would cause the following logic in gntdev_map_grant_pages to become invalid:

  for (i = 0; i < map->count; i++) {
    if (map->map_ops[i].status == GNTST_okay) {
      map->unmap_ops[i].handle = map->map_ops[i].handle;
      if (!use_ptemod)
        alloced++;
    }
    if (use_ptemod) {
      if (map->kmap_ops[i].status == GNTST_okay) {
        if (map->map_ops[i].status == GNTST_okay)
          alloced++;
        map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
      }
    }
  }
  ...
  atomic_add(alloced, &map->live_grants);

Assume that use_ptemod is true (i.e., the domain mapping the granted pages is a paravirtualized domain). In the code excerpt above, note that the "alloced" variable is only incremented when both kmap_ops[i].status and map_ops[i].status are set to GNTST_okay (i.e., both mapping operations are successful). However, as also noted above, there are cases where a grant mapping operation fails partially, breaking the assumption of the code excerpt above.

The aforementioned causes map->live_grants to be incorrectly set. In some cases, all of the map_ops mappings fail, but all of the kmap_ops mappings succeed, meaning that live_grants may remain zero. This in turn makes it impossible to unmap the successfully grant-mapped pages pointed to by kmap_ops, because unmap_grant_pages has the following snippet of code at its beginning:

if (atomic_read(&map->live_grants) == 0)
return; /* Nothing to do */

In other cases where only some of the map_ops mappings fail but all kmap_ops mappings succeed, live_grants is made positive, but when the user requests unmapping the grant-mapped pages, __unmap_grant_pages_done will then make map->live_grants negative, because the latter function does not check if all of the pages that were requested to be unmapped were actually unmapped, and the same function unconditionally subtracts "data->count" (i.e., a value that can be greater than map->live_grants) from map->live_grants. The side effects of a negative live_grants value have not been studied.

The net effect of all of this is that grant references are leaked in one of the above conditions. In Qubes OS v4.1 (which uses Xen's grant mechanism extensively for X11 GUI isolation), this issue manifests itself with warning messages like the following to be printed out by the Linux kernel in the VM that had granted pages (that contain X11 GUI window data) to dom0: "g.e. 0x1234 still pending", especially after the user rapidly resizes GUI VM windows (causing some grant-mapping operations to partially or completely fail, due to the fact that the VM unshares some of the pages as part of the window resizing, making the pages impossible to grant-map from dom0).

The fix for this issue involves counting all successful map_ops and kmap_ops mappings separately, and then adding the sum to live_grants. During unmapping, only the number of successfully unmapped grants is subtracted from live_grants. The code is also modified to check for negative live_grants values after the subtraction and warn the user.

Fixes dbe97cff7dd9 ("xen/gntdev: Avoid blocking in unmap_grant_pages()")

Signed-off-by M. Vefa Bicakci <[email protected]>

Acked-by Demi Marie Obenour <[email protected]>

Reviewed-by Juergen Gross <[email protected]>

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

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

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

---
 drivers/xen/gntdev.c |   22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

drivers/xen/gntdev.c +17 -5

@@ -367,8 +367,7 @@ int gntdev_map_grant_pages(struct gntdev
 	for (i = 0; i < map->count; i++) {
 		if (map->map_ops[i].status == GNTST_okay) {
 			map->unmap_ops[i].handle = map->map_ops[i].handle;
-			if (!use_ptemod)
-				alloced++;
+			alloced++;
 		} else if (!err)
 			err = -EINVAL;

@@ -377,8 +376,7 @@ int gntdev_map_grant_pages(struct gntdev
 
 		if (use_ptemod) {
 			if (map->kmap_ops[i].status == GNTST_okay) {
-				if (map->map_ops[i].status == GNTST_okay)
-					alloced++;
+				alloced++;
 				map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
 			} else if (!err)
 				err = -EINVAL;

@@ -394,8 +392,14 @@ static void __unmap_grant_pages_done(int
 	unsigned int i;
 	struct gntdev_grant_map *map = data->data;
 	unsigned int offset = data->unmap_ops - map->unmap_ops;
+	int successful_unmaps = 0;
+	int live_grants;
 
 	for (i = 0; i < data->count; i++) {
+		if (map->unmap_ops[offset + i].status == GNTST_okay &&
+		    map->unmap_ops[offset + i].handle != INVALID_GRANT_HANDLE)
+			successful_unmaps++;
+
 		WARN_ON(map->unmap_ops[offset + i].status != GNTST_okay &&
 			map->unmap_ops[offset + i].handle != INVALID_GRANT_HANDLE);
 		pr_debug("unmap handle=%d st=%d\n",

@@ -403,6 +407,10 @@ static void __unmap_grant_pages_done(int
 			map->unmap_ops[offset+i].status);
 		map->unmap_ops[offset+i].handle = INVALID_GRANT_HANDLE;
 		if (use_ptemod) {
+			if (map->kunmap_ops[offset + i].status == GNTST_okay &&
+			    map->kunmap_ops[offset + i].handle != INVALID_GRANT_HANDLE)
+				successful_unmaps++;
+
 			WARN_ON(map->kunmap_ops[offset + i].status != GNTST_okay &&
 				map->kunmap_ops[offset + i].handle != INVALID_GRANT_HANDLE);
 			pr_debug("kunmap handle=%u st=%d\n",

@@ -411,11 +419,15 @@ static void __unmap_grant_pages_done(int
 			map->kunmap_ops[offset+i].handle = INVALID_GRANT_HANDLE;
 		}
 	}
+
 	/*
 	 * Decrease the live-grant counter.  This must happen after the loop to
 	 * prevent premature reuse of the grants by gnttab_mmap().
 	 */
-	atomic_sub(data->count, &map->live_grants);
+	live_grants = atomic_sub_return(successful_unmaps, &map->live_grants);
+	if (WARN_ON(live_grants < 0))
+		pr_err("%s: live_grants became negative (%d) after unmapping %d pages!\n",
+		       __func__, live_grants, successful_unmaps);
 
 	/* Release reference taken by __unmap_grant_pages */
 	gntdev_put_map(NULL, map);

Greg Kroah-Hartman

author maintainer

2022-10-19 11:11 UTC #88 lore raw

PATCH 88/862 xen/gntdev: Accommodate VMA splitting

Link https://github.com/QubesOS/qubes-issues/issues/7631

From: M. Vefa Bicakci <[email protected]>

commit 5c13a4a0291b30191eff9ead8d010e1ca43a4d0c upstream.

Prior to this commit, the gntdev driver code did not handle the following scenario correctly with paravirtualized (PV) Xen domains:

* User process sets up a gntdev mapping composed of two grant mappings (i.e., two pages shared by another Xen domain).
* User process munmap()s one of the pages.
* User process munmap()s the remaining page.
* User process exits.

In the scenario above, the user process would cause the kernel to log the following messages in dmesg for the first munmap(), and the second munmap() call would result in similar log messages:

  BUG: Bad page map in process doublemap.test  pte:... pmd:...
  page:0000000057c97bff refcount:1 mapcount:-1 \
    mapping:0000000000000000 index:0x0 pfn:...
  ...
  page dumped because: bad pte
  ...
  file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0
  ...
  Call Trace:
   <TASK>
   dump_stack_lvl+0x46/0x5e
   print_bad_pte.cold+0x66/0xb6
   unmap_page_range+0x7e5/0xdc0
   unmap_vmas+0x78/0xf0
   unmap_region+0xa8/0x110
   __do_munmap+0x1ea/0x4e0
   __vm_munmap+0x75/0x120
   __x64_sys_munmap+0x28/0x40
   do_syscall_64+0x38/0x90
   entry_SYSCALL_64_after_hwframe+0x61/0xcb
   ...

For each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG) would print out the following and trigger a general protection fault in the affected Xen PV domain:

(XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ...

As of this writing, gntdev_grant_map structure's vma field (referred to as map->vma below) is mainly used for checking the start and end addresses of mappings. However, with split VMAs, these may change, and there could be more than one VMA associated with a gntdev mapping. Hence, remove the use of map->vma and rely on map->pages_vm_start for the original start address and on (map->count << PAGE_SHIFT) for the original mapping size. Let the invalidate() and find_special_page() hooks use these.

Also, given that there can be multiple VMAs associated with a gntdev mapping, move the "mmu_interval_notifier_remove(&map->notifier)" call to the end of gntdev_put_map, so that the MMU notifier is only removed after the closing of the last remaining VMA.

Finally, use an atomic to prevent inadvertent gntdev mapping re-use, instead of using the map->live_grants atomic counter and/or the map->vma pointer (the latter of which is now removed). This prevents the userspace from mmap()'ing (with MAP_FIXED) a gntdev mapping over the same address range as a previously set up gntdev mapping. This scenario can be summarized with the following call-trace, which was valid prior to this commit:

mmap
gntdev_mmap
mmap (repeat mmap with MAP_FIXED over the same address range)
gntdev_invalidate
unmap_grant_pages (sets 'being_removed' entries to true)
gnttab_unmap_refs_async
unmap_single_vma
gntdev_mmap (maps the shared pages again)
munmap
gntdev_invalidate
unmap_grant_pages
(no-op because 'being_removed' entries are true)
unmap_single_vma (For PV domains, Xen reports that a granted page
is being unmapped and triggers a general protection fault in the affected domain, if Xen was built with CONFIG_DEBUG)

The fix for this last scenario could be worth its own commit, but we opted for a single commit, because removing the gntdev_grant_map structure's vma field requires guarding the entry to gntdev_mmap(), and the live_grants atomic counter is not sufficient on its own to prevent the mmap() over a pre-existing mapping.

Fixes ab31523c2fca ("xen/gntdev: allow usermode to map granted pages")

Signed-off-by M. Vefa Bicakci <[email protected]>

Reviewed-by Juergen Gross <[email protected]>

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

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

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

---
 drivers/xen/gntdev-common.h |    3 +-
 drivers/xen/gntdev.c        |   58 ++++++++++++++++++--------------------------
 2 files changed, 27 insertions(+), 34 deletions(-)

drivers/xen/gntdev-common.h +2 -1

@@ -44,9 +44,10 @@ struct gntdev_unmap_notify {
 };
 
 struct gntdev_grant_map {
+	atomic_t in_use;
 	struct mmu_interval_notifier notifier;
+	bool notifier_init;
 	struct list_head next;
-	struct vm_area_struct *vma;
 	int index;
 	int count;
 	int flags;

drivers/xen/gntdev.c +25 ~~-33~~

131 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2022-10-19 12:19 UTC #89 lore raw

PATCH 89/862 PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridge

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

From: Maciej W. Rozycki <[email protected]>

commit 0e32818397426a688f598f35d3bc762eca6d7592 upstream.

When pci_assign_resource() is unable to assign resources to a BAR, it uses pci_revert_fw_address() to fall back to a firmware assignment (if any). Previously pci_revert_fw_address() assumed all addresses could reach the device, but this is not true if the device is below a bridge that only forwards addresses within its windows.

This problem was observed on a Tyan Tomcat IV S1564D system where the BIOS did not assign valid addresses to several bridges and USB devices:

pci 0000:00:11.0: PCI-to-PCIe bridge to [bus 01-ff]
pci 0000:00:11.0: bridge window [io 0xe000-0xefff]
pci 0000:01:00.0: PCIe Upstream Port to [bus 02-ff]
pci 0000:01:00.0: bridge window [io 0x0000-0x0fff] # unreachable
pci 0000:02:02.0: PCIe Downstream Port to [bus 05-ff]
pci 0000:02:02.0: bridge window [io 0x0000-0x0fff] # unreachable
pci 0000:05:00.0: PCIe-to-PCI bridge to [bus 06-ff]
pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] # unreachable
pci 0000:06:08.0: USB UHCI 1.1
pci 0000:06:08.0: BAR 4: [io 0xfce0-0xfcff] # unreachable
pci 0000:06:08.1: USB UHCI 1.1
pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] # unreachable
pci 0000:06:08.0: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window pci 0000:06:08.1: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window

During the first pass of assigning unassigned resources, there was not enough I/O space available, so we couldn't assign the 06:08.0 BAR and reverted to the firmware assignment (still unreachable). Reverting the 06:08.1 assignment failed because it conflicted with 06:08.0:

pci 0000:00:11.0: bridge window [io 0xe000-0xefff]

  pci 0000:01:00.0: no space for bridge window [io  size 0x2000]
  pci 0000:02:02.0: no space for bridge window [io  size 0x1000]
  pci 0000:05:00.0: no space for bridge window [io  size 0x1000]

pci 0000:06:08.0: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.0: BAR 4: trying firmware assignment [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.1: BAR 4: trying firmware assignment [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] conflicts with 0000:06:08.0 [io 0xfce0-0xfcff]

A subsequent pass assigned valid bridge windows and a valid 06:08.1 BAR, but left the 06:08.0 BAR alone, so the UHCI device was still unusable:

  pci 0000:00:11.0:   bridge window [io  0xe000-0xefff] released
  pci 0000:00:11.0:   bridge window [io  0x1000-0x2fff]   # reassigned
  pci 0000:01:00.0:   bridge window [io  0x1000-0x2fff]   # reassigned
  pci 0000:02:02.0:   bridge window [io  0x2000-0x2fff]   # reassigned
  pci 0000:05:00.0:   bridge window [io  0x2000-0x2fff]   # reassigned
  pci 0000:06:08.0: BAR 4: assigned [io  0xfce0-0xfcff]   # left alone
  pci 0000:06:08.1: BAR 4: assigned [io  0x2000-0x201f]

...
uhci_hcd 0000:06:08.0: host system error, PCI problems?
uhci_hcd 0000:06:08.0: host controller process error, something bad happened! uhci_hcd 0000:06:08.0: host controller halted, very bad! uhci_hcd 0000:06:08.0: HCRESET not completed yet!
uhci_hcd 0000:06:08.0: HC died; cleaning up

If the address assigned by firmware is not reachable because it's not within upstream bridge windows, fail instead of assigning the unusable address from firmware.

[bhelgaas: commit log, use pci_upstream_bridge()]

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

Fixes 58c84eda0756 ("PCI: fall back to original BIOS BAR addresses")

Signed-off-by Maciej W. Rozycki <[email protected]>

Signed-off-by Bjorn Helgaas <[email protected]>

Cc [email protected] # v2.6.35+

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

---
 drivers/pci/setup-res.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/pci/setup-res.c +11 -0

@@ -214,6 +214,17 @@ static int pci_revert_fw_address(struct
 
 	root = pci_find_parent_resource(dev, res);
 	if (!root) {
+		/*
+		 * If dev is behind a bridge, accesses will only reach it
+		 * if res is inside the relevant bridge window.
+		 */
+		if (pci_upstream_bridge(dev))
+			return -ENXIO;
+
+		/*
+		 * On the root bus, assume the host bridge will forward
+		 * everything.
+		 */
 		if (res->flags & IORESOURCE_IO)
 			root = &ioport_resource;
 		else

Greg Kroah-Hartman

author maintainer

2022-10-19 11:12 UTC #90 lore raw

PATCH 90/862 serial: cpm_uart: Dont request IRQ too early for console port

From: Christophe Leroy <[email protected]>

commit 30963b2f75bfdbbcf1cc5d80bf88fec7aaba808d upstream.

The following message is seen during boot and the activation of console port gets delayed until normal serial ports activation.

[    0.001346] irq: no irq domain found for pic@930 !

The console port doesn't need irq, perform irq reservation later, during cpm_uart probe.

While at it, don't use NO_IRQ but 0 which is the value returned by irq_of_parse_and_map() in case of error. By chance powerpc's NO_IRQ has value 0 but on some architectures it is -1.

Fixes 14d893fc6846 ("powerpc/8xx: Convert CPM1 interrupt controller to platform_device")

Link https://lore.kernel.org/r/8bed0f30c2e9ef16ae64fb1243a16d54a48eb8da.1664526717.git.christophe.leroy@csgroup.eu open here

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

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

---
 drivers/tty/serial/cpm_uart/cpm_uart_core.c |   22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

drivers/tty/serial/cpm_uart/cpm_uart_core.c +10 ~~-12~~

@@ -1214,12 +1214,6 @@ static int cpm_uart_init_port(struct dev
 	pinfo->port.fifosize = pinfo->tx_nrfifos * pinfo->tx_fifosize;
 	spin_lock_init(&pinfo->port.lock);
 
-	pinfo->port.irq = irq_of_parse_and_map(np, 0);
-	if (pinfo->port.irq == NO_IRQ) {
-		ret = -EINVAL;
-		goto out_pram;
-	}
-
 	for (i = 0; i < NUM_GPIOS; i++) {
 		struct gpio_desc *gpiod;

@@ -1229,7 +1223,7 @@ static int cpm_uart_init_port(struct dev
 
 		if (IS_ERR(gpiod)) {
 			ret = PTR_ERR(gpiod);
-			goto out_irq;
+			goto out_pram;
 		}
 
 		if (gpiod) {

@@ -1255,8 +1249,6 @@ static int cpm_uart_init_port(struct dev
 
 	return cpm_uart_request_port(&pinfo->port);
 
-out_irq:
-	irq_dispose_mapping(pinfo->port.irq);
 out_pram:
 	cpm_uart_unmap_pram(pinfo, pram);
 out_mem:

@@ -1436,11 +1428,17 @@ static int cpm_uart_probe(struct platfor
 	/* initialize the device pointer for the port */
 	pinfo->port.dev = &ofdev->dev;
 
+	pinfo->port.irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
+	if (!pinfo->port.irq)
+		return -EINVAL;
+
 	ret = cpm_uart_init_port(ofdev->dev.of_node, pinfo);
-	if (ret)
-		return ret;
+	if (!ret)
+		return uart_add_one_port(&cpm_reg, &pinfo->port);
+
+	irq_dispose_mapping(pinfo->port.irq);
 
-	return uart_add_one_port(&cpm_reg, &pinfo->port);
+	return ret;
 }
 
 static int cpm_uart_remove(struct platform_device *ofdev)

Greg Kroah-Hartman

author maintainer

2022-10-19 11:11 UTC #91 lore raw

PATCH 91/862 serial: stm32: Deassert Transmit Enable on ->rs485_config()

Link https://lore.kernel.org/r/6059eab35dba394468335ef640df8b0050fd9dbd.1662886616.git.lukas@wunner.de open here

From: Lukas Wunner <[email protected]>

commit adafbbf6895eb0ce41a313c6ee68870ab9aa93cd upstream.

The STM32 USART can control RS-485 Transmit Enable in hardware. Since commit 7df5081cbf5e ("serial: stm32: Add RS485 RTS GPIO control"), it can alternatively be controlled in software. That was done to allow RS-485 even if the RTS pin is unavailable because it's pinmuxed to a different function.

However the commit neglected to deassert Transmit Enable upon invocation of the ->rs485_config() callback. Fix it.

Avoid forward declarations by moving stm32_usart_tx_empty(), stm32_usart_rs485_rts_enable() and stm32_usart_rs485_rts_disable() further up in the driver.

Fixes 7df5081cbf5e ("serial: stm32: Add RS485 RTS GPIO control")

Cc [email protected] # v5.9+

Cc Marek Vasut <[email protected]>

Reviewed-by Ilpo Järvinen <[email protected]>

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

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

---
 drivers/tty/serial/stm32-usart.c |  100 ++++++++++++++++++++-------------------
 1 file changed, 53 insertions(+), 47 deletions(-)

drivers/tty/serial/stm32-usart.c +53 ~~-47~~

@@ -131,6 +131,53 @@ static void stm32_usart_clr_bits(struct
 	writel_relaxed(val, port->membase + reg);
 }
 
+static unsigned int stm32_usart_tx_empty(struct uart_port *port)
+{
+	struct stm32_port *stm32_port = to_stm32_port(port);
+	const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
+
+	if (readl_relaxed(port->membase + ofs->isr) & USART_SR_TC)
+		return TIOCSER_TEMT;
+
+	return 0;
+}
+
+static void stm32_usart_rs485_rts_enable(struct uart_port *port)
+{
+	struct stm32_port *stm32_port = to_stm32_port(port);
+	struct serial_rs485 *rs485conf = &port->rs485;
+
+	if (stm32_port->hw_flow_control ||
+	    !(rs485conf->flags & SER_RS485_ENABLED))
+		return;
+
+	if (rs485conf->flags & SER_RS485_RTS_ON_SEND) {
+		mctrl_gpio_set(stm32_port->gpios,
+			       stm32_port->port.mctrl | TIOCM_RTS);
+	} else {
+		mctrl_gpio_set(stm32_port->gpios,
+			       stm32_port->port.mctrl & ~TIOCM_RTS);
+	}
+}
+
+static void stm32_usart_rs485_rts_disable(struct uart_port *port)
+{
+	struct stm32_port *stm32_port = to_stm32_port(port);
+	struct serial_rs485 *rs485conf = &port->rs485;
+
+	if (stm32_port->hw_flow_control ||
+	    !(rs485conf->flags & SER_RS485_ENABLED))
+		return;
+
+	if (rs485conf->flags & SER_RS485_RTS_ON_SEND) {
+		mctrl_gpio_set(stm32_port->gpios,
+			       stm32_port->port.mctrl & ~TIOCM_RTS);
+	} else {
+		mctrl_gpio_set(stm32_port->gpios,
+			       stm32_port->port.mctrl | TIOCM_RTS);
+	}
+}
+
 static void stm32_usart_config_reg_rs485(u32 *cr1, u32 *cr3, u32 delay_ADE,
 					 u32 delay_DDE, u32 baud)
 {

@@ -214,6 +261,12 @@ static int stm32_usart_config_rs485(stru
 
 	stm32_usart_set_bits(port, ofs->cr1, BIT(cfg->uart_enable_bit));
 
+	/* Adjust RTS polarity in case it's driven in software */
+	if (stm32_usart_tx_empty(port))
+		stm32_usart_rs485_rts_disable(port);
+	else
+		stm32_usart_rs485_rts_enable(port);
+
 	return 0;
 }

@@ -529,42 +582,6 @@ static void stm32_usart_tc_interrupt_dis
 	stm32_usart_clr_bits(port, ofs->cr1, USART_CR1_TCIE);
 }
 
-static void stm32_usart_rs485_rts_enable(struct uart_port *port)
-{
-	struct stm32_port *stm32_port = to_stm32_port(port);
-	struct serial_rs485 *rs485conf = &port->rs485;
-
-	if (stm32_port->hw_flow_control ||
-	    !(rs485conf->flags & SER_RS485_ENABLED))
-		return;
-
-	if (rs485conf->flags & SER_RS485_RTS_ON_SEND) {
-		mctrl_gpio_set(stm32_port->gpios,
-			       stm32_port->port.mctrl | TIOCM_RTS);
-	} else {
-		mctrl_gpio_set(stm32_port->gpios,
-			       stm32_port->port.mctrl & ~TIOCM_RTS);
-	}
-}
-
-static void stm32_usart_rs485_rts_disable(struct uart_port *port)
-{
-	struct stm32_port *stm32_port = to_stm32_port(port);
-	struct serial_rs485 *rs485conf = &port->rs485;
-
-	if (stm32_port->hw_flow_control ||
-	    !(rs485conf->flags & SER_RS485_ENABLED))
-		return;
-
-	if (rs485conf->flags & SER_RS485_RTS_ON_SEND) {
-		mctrl_gpio_set(stm32_port->gpios,
-			       stm32_port->port.mctrl & ~TIOCM_RTS);
-	} else {
-		mctrl_gpio_set(stm32_port->gpios,
-			       stm32_port->port.mctrl | TIOCM_RTS);
-	}
-}
-
 static void stm32_usart_transmit_chars_pio(struct uart_port *port)
 {
 	struct stm32_port *stm32_port = to_stm32_port(port);

@@ -807,17 +824,6 @@ static irqreturn_t stm32_usart_threaded_
 	return IRQ_HANDLED;
 }
 
-static unsigned int stm32_usart_tx_empty(struct uart_port *port)
-{
-	struct stm32_port *stm32_port = to_stm32_port(port);
-	const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
-
-	if (readl_relaxed(port->membase + ofs->isr) & USART_SR_TC)
-		return TIOCSER_TEMT;
-
-	return 0;
-}
-
 static void stm32_usart_set_mctrl(struct uart_port *port, unsigned int mctrl)
 {
 	struct stm32_port *stm32_port = to_stm32_port(port);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #92 lore raw

PATCH 92/862 serial: Deassert Transmit Enable on probe in driver-specific way

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

From: Lukas Wunner <[email protected]>

commit 7c7f9bc986e698873b489c371a08f206979d06b7 upstream.

When a UART port is newly registered, uart_configure_port() seeks to deassert RS485 Transmit Enable by setting the RTS bit in port->mctrl. However a number of UART drivers interpret a set RTS bit as *assertion* instead of deassertion: Affected drivers include those using serial8250_em485_config() (except 8250_bcm2835aux.c) and some using mctrl_gpio (e.g. imx.c).

Since the interpretation of the RTS bit is driver-specific, it is not suitable as a means to centrally deassert Transmit Enable in the serial core. Instead, the serial core must call on drivers to deassert it in their driver-specific way. One way to achieve that is to call ->rs485_config(). It implicitly deasserts Transmit Enable.

So amend uart_configure_port() and uart_resume_port() to invoke uart_rs485_config(). That allows removing calls to uart_rs485_config() from drivers' ->probe() hooks and declaring the function static.

Skip any invocation of ->set_mctrl() if RS485 is enabled. RS485 has no hardware flow control, so the modem control lines are irrelevant and need not be touched. When leaving RS485 mode, reset the modem control lines to the state stored in port->mctrl. That way, UARTs which are muxed between RS485 and RS232 transceivers drive the lines correctly when switched to RS232. (serial8250_do_startup() historically raises the OUT1 modem signal because otherwise interrupts are not signaled on ancient PC UARTs, but I believe that no longer applies to modern, RS485-capable UARTs and is thus safe to be skipped.)

imx.c modifies port->mctrl whenever Transmit Enable is asserted and deasserted. Stop it from doing that so port->mctrl reflects the RS232 line state.

8250_omap.c deasserts Transmit Enable on ->runtime_resume() by calling ->set_mctrl(). Because that is now a no-op in RS485 mode, amend the function to call serial8250_em485_stop_tx().

fsl_lpuart.c retrieves and applies the RS485 device tree properties after registering the UART port. Because applying now happens on registration in uart_configure_port(), move retrieval of the properties ahead of uart_add_one_port().

Fixes d3b3404df318 ("serial: Fix incorrect rs485 polarity on uart open")

Cc [email protected] # v4.14+

Reported-by Matthias Schiffer <[email protected]>

Reported-by Roosen Henri <[email protected]>

Tested-by Matthias Schiffer <[email protected]>

Reviewed-by Ilpo Järvinen <[email protected]>

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

Link https://lore.kernel.org/r/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663863805.git.lukas@wunner.de open here

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

---
 drivers/tty/serial/8250/8250_omap.c |    3 +++
 drivers/tty/serial/8250/8250_pci.c  |    9 +--------
 drivers/tty/serial/8250/8250_port.c |   12 +++++++-----
 drivers/tty/serial/fsl_lpuart.c     |   10 ++++------
 drivers/tty/serial/imx.c            |    8 ++------
 drivers/tty/serial/serial_core.c    |   36 ++++++++++++++++++++----------------
 include/linux/serial_core.h         |    1 -
 7 files changed, 37 insertions(+), 42 deletions(-)

drivers/tty/serial/8250/8250_omap.c +3 -0

@@ -342,6 +342,9 @@ static void omap8250_restore_regs(struct
 	omap8250_update_mdr1(up, priv);
 
 	up->port.ops->set_mctrl(&up->port, up->port.mctrl);
+
+	if (up->port.rs485.flags & SER_RS485_ENABLED)
+		serial8250_em485_stop_tx(up);
 }
 
 /*

drivers/tty/serial/8250/8250_pci.c +1 -8

@@ -1627,7 +1627,6 @@ static int pci_fintek_init(struct pci_de
 	resource_size_t bar_data[3];
 	u8 config_base;
 	struct serial_private *priv = pci_get_drvdata(dev);
-	struct uart_8250_port *port;
 
 	if (!(pci_resource_flags(dev, 5) & IORESOURCE_IO) ||
 			!(pci_resource_flags(dev, 4) & IORESOURCE_IO) ||

@@ -1674,13 +1673,7 @@ static int pci_fintek_init(struct pci_de
 
 		pci_write_config_byte(dev, config_base + 0x06, dev->irq);
 
-		if (priv) {
-			/* re-apply RS232/485 mode when
-			 * pciserial_resume_ports()
-			 */
-			port = serial8250_get_port(priv->line[i]);
-			uart_rs485_config(&port->port);
-		} else {
+		if (!priv) {
 			/* First init without port data
 			 * force init to RS232 Mode
 			 */

drivers/tty/serial/8250/8250_port.c +7 -5

@@ -600,7 +600,7 @@ EXPORT_SYMBOL_GPL(serial8250_rpm_put);
 static int serial8250_em485_init(struct uart_8250_port *p)
 {
 	if (p->em485)
-		return 0;
+		goto deassert_rts;
 
 	p->em485 = kmalloc(sizeof(struct uart_8250_em485), GFP_ATOMIC);
 	if (!p->em485)

@@ -616,7 +616,9 @@ static int serial8250_em485_init(struct
 	p->em485->active_timer = NULL;
 	p->em485->tx_stopped = true;
 
-	p->rs485_stop_tx(p);
+deassert_rts:
+	if (p->em485->tx_stopped)
+		p->rs485_stop_tx(p);
 
 	return 0;
 }

@@ -2042,6 +2044,9 @@ EXPORT_SYMBOL_GPL(serial8250_do_set_mctr
 
 static void serial8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
 {
+	if (port->rs485.flags & SER_RS485_ENABLED)
+		return;
+
 	if (port->set_mctrl)
 		port->set_mctrl(port, mctrl);
 	else

@@ -3187,9 +3192,6 @@ static void serial8250_config_port(struc
 	if (flags & UART_CONFIG_TYPE)
 		autoconfig(up);
 
-	if (port->rs485.flags & SER_RS485_ENABLED)
-		uart_rs485_config(port);
-
 	/* if access method is AU, it is a 16550 with a quirk */
 	if (port->type == PORT_16550A && port->iotype == UPIO_AU)
 		up->bugs |= UART_BUG_NOMSR;

drivers/tty/serial/fsl_lpuart.c +4 -6

@@ -2729,15 +2729,13 @@ static int lpuart_probe(struct platform_
 	if (ret)
 		goto failed_reset;
 
-	ret = uart_add_one_port(&lpuart_reg, &sport->port);
-	if (ret)
-		goto failed_attach_port;
-
 	ret = uart_get_rs485_mode(&sport->port);
 	if (ret)
 		goto failed_get_rs485;
 
-	uart_rs485_config(&sport->port);
+	ret = uart_add_one_port(&lpuart_reg, &sport->port);
+	if (ret)
+		goto failed_attach_port;
 
 	ret = devm_request_irq(&pdev->dev, sport->port.irq, handler, 0,
 				DRIVER_NAME, sport);

@@ -2747,9 +2745,9 @@ static int lpuart_probe(struct platform_
 	return 0;
 
 failed_irq_request:
-failed_get_rs485:
 	uart_remove_one_port(&lpuart_reg, &sport->port);
 failed_attach_port:
+failed_get_rs485:
 failed_reset:
 	lpuart_disable_clks(sport);
 	return ret;

drivers/tty/serial/imx.c +2 -6

@@ -380,8 +380,7 @@ static void imx_uart_rts_active(struct i
 {
 	*ucr2 &= ~(UCR2_CTSC | UCR2_CTS);
 
-	sport->port.mctrl |= TIOCM_RTS;
-	mctrl_gpio_set(sport->gpios, sport->port.mctrl);
+	mctrl_gpio_set(sport->gpios, sport->port.mctrl | TIOCM_RTS);
 }
 
 /* called with port.lock taken and irqs caller dependent */

@@ -390,8 +389,7 @@ static void imx_uart_rts_inactive(struct
 	*ucr2 &= ~UCR2_CTSC;
 	*ucr2 |= UCR2_CTS;
 
-	sport->port.mctrl &= ~TIOCM_RTS;
-	mctrl_gpio_set(sport->gpios, sport->port.mctrl);
+	mctrl_gpio_set(sport->gpios, sport->port.mctrl & ~TIOCM_RTS);
 }
 
 static void start_hrtimer_ms(struct hrtimer *hrt, unsigned long msec)

@@ -2347,8 +2345,6 @@ static int imx_uart_probe(struct platfor
 		dev_err(&pdev->dev,
 			"low-active RTS not possible when receiver is off, enabling receiver\n");
 
-	uart_rs485_config(&sport->port);
-
 	/* Disable interrupts before requesting them */
 	ucr1 = imx_uart_readl(sport, UCR1);
 	ucr1 &= ~(UCR1_ADEN | UCR1_TRDYEN | UCR1_IDEN | UCR1_RRDYEN | UCR1_RTSDEN);

drivers/tty/serial/serial_core.c +20 ~~-16~~

@@ -158,15 +158,10 @@ uart_update_mctrl(struct uart_port *port
 	unsigned long flags;
 	unsigned int old;
 
-	if (port->rs485.flags & SER_RS485_ENABLED) {
-		set &= ~TIOCM_RTS;
-		clear &= ~TIOCM_RTS;
-	}
-
 	spin_lock_irqsave(&port->lock, flags);
 	old = port->mctrl;
 	port->mctrl = (old & ~clear) | set;
-	if (old != port->mctrl)
+	if (old != port->mctrl && !(port->rs485.flags & SER_RS485_ENABLED))
 		port->ops->set_mctrl(port, port->mctrl);
 	spin_unlock_irqrestore(&port->lock, flags);
 }

@@ -1391,7 +1386,7 @@ static void uart_set_rs485_termination(s
 				 !!(rs485->flags & SER_RS485_TERMINATE_BUS));
 }
 
-int uart_rs485_config(struct uart_port *port)
+static int uart_rs485_config(struct uart_port *port)
 {
 	struct serial_rs485 *rs485 = &port->rs485;
 	int ret;

@@ -1405,7 +1400,6 @@ int uart_rs485_config(struct uart_port *
 
 	return ret;
 }
-EXPORT_SYMBOL_GPL(uart_rs485_config);
 
 static int uart_get_rs485_config(struct uart_port *port,
 			 struct serial_rs485 __user *rs485)

@@ -1444,8 +1438,13 @@ static int uart_set_rs485_config(struct
 
 	spin_lock_irqsave(&port->lock, flags);
 	ret = port->rs485_config(port, &tty->termios, &rs485);
-	if (!ret)
+	if (!ret) {
 		port->rs485 = rs485;
+
+		/* Reset RTS and other mctrl lines when disabling RS485 */
+		if (!(rs485.flags & SER_RS485_ENABLED))
+			port->ops->set_mctrl(port, port->mctrl);
+	}
 	spin_unlock_irqrestore(&port->lock, flags);
 	if (ret)
 		return ret;

@@ -2352,7 +2351,8 @@ int uart_suspend_port(struct uart_driver
 
 		spin_lock_irq(&uport->lock);
 		ops->stop_tx(uport);
-		ops->set_mctrl(uport, 0);
+		if (!(uport->rs485.flags & SER_RS485_ENABLED))
+			ops->set_mctrl(uport, 0);
 		/* save mctrl so it can be restored on resume */
 		mctrl = uport->mctrl;
 		uport->mctrl = 0;

@@ -2440,7 +2440,8 @@ int uart_resume_port(struct uart_driver
 
 		uart_change_pm(state, UART_PM_STATE_ON);
 		spin_lock_irq(&uport->lock);
-		ops->set_mctrl(uport, 0);
+		if (!(uport->rs485.flags & SER_RS485_ENABLED))
+			ops->set_mctrl(uport, 0);
 		spin_unlock_irq(&uport->lock);
 		if (console_suspend_enabled || !uart_console(uport)) {
 			/* Protected by port mutex for now */

@@ -2451,7 +2452,10 @@ int uart_resume_port(struct uart_driver
 				if (tty)
 					uart_change_speed(tty, state, NULL);
 				spin_lock_irq(&uport->lock);
-				ops->set_mctrl(uport, uport->mctrl);
+				if (!(uport->rs485.flags & SER_RS485_ENABLED))
+					ops->set_mctrl(uport, uport->mctrl);
+				else
+					uart_rs485_config(uport);
 				ops->start_tx(uport);
 				spin_unlock_irq(&uport->lock);
 				tty_port_set_initialized(port, 1);

@@ -2558,10 +2562,10 @@ uart_configure_port(struct uart_driver *
 		 */
 		spin_lock_irqsave(&port->lock, flags);
 		port->mctrl &= TIOCM_DTR;
-		if (port->rs485.flags & SER_RS485_ENABLED &&
-		    !(port->rs485.flags & SER_RS485_RTS_AFTER_SEND))
-			port->mctrl |= TIOCM_RTS;
-		port->ops->set_mctrl(port, port->mctrl);
+		if (!(port->rs485.flags & SER_RS485_ENABLED))
+			port->ops->set_mctrl(port, port->mctrl);
+		else
+			uart_rs485_config(port);
 		spin_unlock_irqrestore(&port->lock, flags);
 
 		/*

include/linux/serial_core.h +0 -1

@@ -950,5 +950,4 @@ static inline int uart_handle_break(stru
 					 !((cflag) & CLOCAL))
 
 int uart_get_rs485_mode(struct uart_port *port);
-int uart_rs485_config(struct uart_port *port);
 #endif /* LINUX_SERIAL_CORE_H */

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #93 lore raw

PATCH 93/862 serial: ar933x: Deassert Transmit Enable on ->rs485_config()

Link https://lore.kernel.org/r/5b36af26e57553f084334666e7d24c7fd131a01e.1662887231.git.lukas@wunner.de open here

From: Lukas Wunner <[email protected]>

commit 3a939433ddc1bab98be028903aaa286e5e7461d7 upstream.

The ar933x_uart driver neglects to deassert Transmit Enable when ->rs485_config() is invoked. Fix it.

Fixes 9be1064fe524 ("serial: ar933x_uart: add RS485 support")

Cc [email protected] # v5.7+

Cc Daniel Golle <[email protected]>

Reviewed-by Ilpo Järvinen <[email protected]>

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

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

---
 drivers/tty/serial/ar933x_uart.c |    7 +++++++
 1 file changed, 7 insertions(+)

drivers/tty/serial/ar933x_uart.c +7 -0

@@ -583,6 +583,13 @@ static const struct uart_ops ar933x_uart
 static int ar933x_config_rs485(struct uart_port *port, struct ktermios *termios,
 				struct serial_rs485 *rs485conf)
 {
+	struct ar933x_uart_port *up =
+			container_of(port, struct ar933x_uart_port, port);
+
+	if (port->rs485.flags & SER_RS485_ENABLED)
+		gpiod_set_value(up->rts_gpiod,
+			!!(rs485conf->flags & SER_RS485_RTS_AFTER_SEND));
+
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2022-10-19 13:52 UTC #94 lore raw

PATCH 94/862 serial: 8250: Let drivers request full 16550A feature probing

From: Maciej W. Rozycki <[email protected]>

commit 9906890c89e4dbd900ed87ad3040080339a7f411 upstream.

A SERIAL_8250_16550A_VARIANTS configuration option has been recently defined that lets one request the 8250 driver not to probe for 16550A device features so as to reduce the driver's device startup time in virtual machines.

Some actual hardware devices require these features to have been fully determined however for their driver to work correctly, so define a flag to let drivers request full 16550A feature probing on a device-by-device basis if required regardless of the SERIAL_8250_16550A_VARIANTS option setting chosen.

Fixes dc56ecb81a0a ("serial: 8250: Support disabling mdelay-filled probes of 16550A variants")

Cc [email protected] # v5.6+

Reported-by Anders Blomdell <[email protected]>

Signed-off-by Maciej W. Rozycki <[email protected]>

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

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

---
 drivers/tty/serial/8250/8250_port.c |    3 ++-
 include/linux/serial_core.h         |    3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

drivers/tty/serial/8250/8250_port.c +2 -1

@@ -1023,7 +1023,8 @@ static void autoconfig_16550a(struct uar
 	up->port.type = PORT_16550A;
 	up->capabilities |= UART_CAP_FIFO;
 
-	if (!IS_ENABLED(CONFIG_SERIAL_8250_16550A_VARIANTS))
+	if (!IS_ENABLED(CONFIG_SERIAL_8250_16550A_VARIANTS) &&
+	    !(up->port.flags & UPF_FULL_PROBE))
 		return;
 
 	/*

include/linux/serial_core.h +2 -1

@@ -422,7 +422,7 @@ struct uart_icount {
 	__u32	buf_overrun;
 };
 
-typedef unsigned int __bitwise upf_t;
+typedef u64 __bitwise upf_t;
 typedef unsigned int __bitwise upstat_t;
 
 struct uart_port {

@@ -530,6 +530,7 @@ struct uart_port {
 #define UPF_FIXED_PORT		((__force upf_t) (1 << 29))
 #define UPF_DEAD		((__force upf_t) (1 << 30))
 #define UPF_IOREMAP		((__force upf_t) (1 << 31))
+#define UPF_FULL_PROBE		((__force upf_t) (1ULL << 32))
 
 #define __UPF_CHANGE_MASK	0x17fff
 #define UPF_CHANGE_MASK		((__force upf_t) __UPF_CHANGE_MASK)

Greg Kroah-Hartman

author maintainer

2022-10-19 08:47 UTC #95 lore raw

PATCH 95/862 serial: 8250: Request full 16550A feature probing for OxSemi PCIe devices

From: Maciej W. Rozycki <[email protected]>

commit 00b7a4d4ee42be1c515e56cb1e8ba0f25e271d8e upstream.

Oxford Semiconductor PCIe (Tornado) 950 serial port devices need to operate in the enhanced mode via the EFR register for the Divide-by-M N/8 baud rate generator prescaler to be used in their native UART mode. Otherwise the prescaler is fixed at 1 causing grossly incorrect baud rates to be programmed.

Accessing the EFR register requires 16550A features to have been probed for, so request this to happen regardless of SERIAL_8250_16550A_VARIANTS by setting UPF_FULL_PROBE in port flags.

Fixes 366f6c955d4d ("serial: 8250: Add proper clock handling for OxSemi PCIe devices")

Cc [email protected] # v5.19+

Reported-by Anders Blomdell <[email protected]>

Signed-off-by Maciej W. Rozycki <[email protected]>

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

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

---
 drivers/tty/serial/8250/8250_pci.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/tty/serial/8250/8250_pci.c +5 -0

@@ -1232,6 +1232,10 @@ static void pci_oxsemi_tornado_set_mctrl
 	serial8250_do_set_mctrl(port, mctrl);
 }
 
+/*
+ * We require EFR features for clock programming, so set UPF_FULL_PROBE
+ * for full probing regardless of CONFIG_SERIAL_8250_16550A_VARIANTS setting.
+ */
 static int pci_oxsemi_tornado_setup(struct serial_private *priv,
 				    const struct pciserial_board *board,
 				    struct uart_8250_port *up, int idx)

@@ -1239,6 +1243,7 @@ static int pci_oxsemi_tornado_setup(stru
 	struct pci_dev *dev = priv->dev;
 
 	if (pci_oxsemi_tornado_p(dev)) {
+		up->port.flags |= UPF_FULL_PROBE;
 		up->port.get_divisor = pci_oxsemi_tornado_get_divisor;
 		up->port.set_divisor = pci_oxsemi_tornado_set_divisor;
 		up->port.set_mctrl = pci_oxsemi_tornado_set_mctrl;

Greg Kroah-Hartman

author maintainer

2022-10-19 08:44 UTC #96 lore raw

PATCH 96/862 NFSD: Protect against send buffer overflow in NFSv3 READDIR

From: Chuck Lever <[email protected]>

commit 640f87c190e0d1b2a0fcb2ecf6d2cd53b1c41991 upstream.

Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply message at the same time.

Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large.

A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case.

Thanks to Aleksi Illikainen and Kari Hulkko for uncovering this issue.

Reported-by Ben Ronallo <[email protected]>

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

Reviewed-by Jeff Layton <[email protected]>

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

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

---
 fs/nfsd/nfs3proc.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

fs/nfsd/nfs3proc.c +4 -3

@@ -563,13 +563,14 @@ static void nfsd3_init_dirlist_pages(str
 {
 	struct xdr_buf *buf = &resp->dirlist;
 	struct xdr_stream *xdr = &resp->xdr;
-
-	count = clamp(count, (u32)(XDR_UNIT * 2), svc_max_payload(rqstp));
+	unsigned int sendbuf = min_t(unsigned int, rqstp->rq_res.buflen,
+				     svc_max_payload(rqstp));
 
 	memset(buf, 0, sizeof(*buf));
 
 	/* Reserve room for the NULL ptr & eof flag (-2 words) */
-	buf->buflen = count - XDR_UNIT * 2;
+	buf->buflen = clamp(count, (u32)(XDR_UNIT * 2), sendbuf);
+	buf->buflen -= XDR_UNIT * 2;
 	buf->pages = rqstp->rq_next_page;
 	rqstp->rq_next_page += (buf->buflen + PAGE_SIZE - 1) >> PAGE_SHIFT;

Greg Kroah-Hartman

author maintainer

2022-10-19 11:11 UTC #97 lore raw

PATCH 97/862 NFSD: Protect against send buffer overflow in NFSv2 READ

From: Chuck Lever <[email protected]>

commit 401bc1f90874280a80b93f23be33a0e7e2d1f912 upstream.

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

Reviewed-by Jeff Layton <[email protected]>

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

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

---
 fs/nfsd/nfsproc.c |    1 +
 1 file changed, 1 insertion(+)

fs/nfsd/nfsproc.c +1 -0

@@ -185,6 +185,7 @@ nfsd_proc_read(struct svc_rqst *rqstp)
 		argp->count, argp->offset);
 
 	argp->count = min_t(u32, argp->count, NFSSVC_MAXBLKSIZE_V2);
+	argp->count = min_t(u32, argp->count, rqstp->rq_res.buflen);
 
 	v = 0;
 	len = argp->count;

Greg Kroah-Hartman

author maintainer

2022-10-19 11:12 UTC #98 lore raw

PATCH 98/862 NFSD: Protect against send buffer overflow in NFSv3 READ

From: Chuck Lever <[email protected]>

commit fa6be9cc6e80ec79892ddf08a8c10cabab9baf38 upstream.

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

Reviewed-by Jeff Layton <[email protected]>

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

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

---
 fs/nfsd/nfs3proc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

fs/nfsd/nfs3proc.c +2 -2

@@ -150,7 +150,6 @@ nfsd3_proc_read(struct svc_rqst *rqstp)
 {
 	struct nfsd3_readargs *argp = rqstp->rq_argp;
 	struct nfsd3_readres *resp = rqstp->rq_resp;
-	u32 max_blocksize = svc_max_payload(rqstp);
 	unsigned int len;
 	int v;

@@ -159,7 +158,8 @@ nfsd3_proc_read(struct svc_rqst *rqstp)
 				(unsigned long) argp->count,
 				(unsigned long long) argp->offset);
 
-	argp->count = min_t(u32, argp->count, max_blocksize);
+	argp->count = min_t(u32, argp->count, svc_max_payload(rqstp));
+	argp->count = min_t(u32, argp->count, rqstp->rq_res.buflen);
 	if (argp->offset > (u64)OFFSET_MAX)
 		argp->offset = (u64)OFFSET_MAX;
 	if (argp->offset + argp->count > (u64)OFFSET_MAX)

Greg Kroah-Hartman

author maintainer

2022-10-19 08:47 UTC #99 lore raw

PATCH 99/862 cpufreq: qcom-cpufreq-hw: Fix uninitialized throttled_freq warning

From: Viresh Kumar <[email protected]>

commit 91dc90fdb8b8199519a3aac9c46a433b02223c5b upstream.

Commit 6240aaad75e1 was supposed to drop the reference count to the OPP, instead it avoided more stuff if the OPP isn't found. This isn't entirely correct. We already have a frequency value available, we just couldn't align it with an OPP in case of IS_ERR(opp).

Lets continue with updating thermal pressure, etc, even if we aren't able to find an OPP here.

This fixes warning generated by the 'smatch' tool.

Fixes 6240aaad75e1 ("cpufreq: qcom-hw: fix the opp entries refcounting")

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

Reported-by kernel test robot <[email protected]>

Reported-by Dan Carpenter <[email protected]>

Reviewed-by Neil Armstrong <[email protected]>

Signed-off-by Viresh Kumar <[email protected]>

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

---
 drivers/cpufreq/qcom-cpufreq-hw.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/cpufreq/qcom-cpufreq-hw.c +5 -5

@@ -316,14 +316,14 @@ static void qcom_lmh_dcvs_notify(struct
 	if (IS_ERR(opp)) {
 		dev_warn(dev, "Can't find the OPP for throttling: %pe!\n", opp);
 	} else {
-		throttled_freq = freq_hz / HZ_PER_KHZ;
-
-		/* Update thermal pressure (the boost frequencies are accepted) */
-		arch_update_thermal_pressure(policy->related_cpus, throttled_freq);
-
 		dev_pm_opp_put(opp);
 	}
 
+	throttled_freq = freq_hz / HZ_PER_KHZ;
+
+	/* Update thermal pressure (the boost frequencies are accepted) */
+	arch_update_thermal_pressure(policy->related_cpus, throttled_freq);
+
 	/*
 	 * In the unlikely case policy is unregistered do not enable
 	 * polling or h/w interrupt

Greg Kroah-Hartman

author maintainer

2022-10-19 08:48 UTC #100 lore raw

PATCH 100/862 LoadPin: Fix Kconfig doc about format of file with verity digests

From: Matthias Kaehlcke <[email protected]>

commit aafc203bbad4bf6cf394a34ea698c2b0b8affae0 upstream.

The doc for CONFIG_SECURITY_LOADPIN_VERITY says that the file with verity digests must contain a comma separated list of digests. That was the case at some stage of the development, but was changed during the review process to one digest per line. Update the Kconfig doc accordingly.

Reported-by Jae Hoon Kim <[email protected]>

Signed-off-by Matthias Kaehlcke <[email protected]>

Fixes 3f805f8cc23b ("LoadPin: Enable loading from trusted dm-verity devices")

Link https://lore.kernel.org/r/20220829174557.1.I5d202d1344212a3800d9828f936df6511eb2d0d1@changeid open here

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

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

---
 security/loadpin/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

security/loadpin/Kconfig +1 -1

@@ -33,4 +33,4 @@ config SECURITY_LOADPIN_VERITY
 	  on the LoadPin securityfs entry 'dm-verity'. The ioctl
 	  expects a file descriptor of a file with verity digests as
 	  parameter. The file must be located on the pinned root and
-	  contain a comma separated list of digests.
+	  contain one digest per line.

Greg Kroah-Hartman

author maintainer

2022-10-19 11:08 UTC #101 lore raw

PATCH 101/862 powercap: intel_rapl: Use standard Energy Unit for SPR Dram RAPL domain

From: Zhang Rui <[email protected]>

commit 4c081324df5608b73428662ca54d5221ea03a6bd upstream.

Intel Xeon servers used to use a fixed energy resolution (15.3uj) for Dram RAPL domain. But on SPR, Dram RAPL domain follows the standard energy resolution as described in MSR_RAPL_POWER_UNIT.

Remove the SPR dram_domain_energy_unit quirk.

Fixes 2d798d9f5967 ("powercap: intel_rapl: add support for Sapphire Rapids")

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

Tested-by Wang Wendy <[email protected]>

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

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

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

---
 drivers/powercap/intel_rapl_common.c |    1 -
 1 file changed, 1 deletion(-)

drivers/powercap/intel_rapl_common.c +0 -1

@@ -1035,7 +1035,6 @@ static const struct rapl_defaults rapl_d
 	.check_unit = rapl_check_unit_core,
 	.set_floor_freq = set_floor_freq_default,
 	.compute_time_window = rapl_compute_time_window_core,
-	.dram_domain_energy_unit = 15300,
 	.psys_domain_energy_unit = 1000000000,
 	.spr_psys_bits = true,
 };

Greg Kroah-Hartman

author maintainer

2022-10-19 11:11 UTC #102 lore raw

PATCH 102/862 powerpc/Kconfig: Fix non existing CONFIG_PPC_FSL_BOOKE

From: Christophe Leroy <[email protected]>

commit d1203f32d86987a3ccd7de9ba2448ba12d86d125 upstream.

CONFIG_PPC_FSL_BOOKE doesn't exist. Should be CONFIG_FSL_BOOKE.

Fixes 49e3d8ea6248 ("powerpc/fsl_booke: Enable STRICT_KERNEL_RWX")

Link https://lore.kernel.org/r/828f6a64eeb51ce9abfa1d4e84c521a02fecebb8.1663606875.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/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/powerpc/Kconfig +1 -1

@@ -828,7 +828,7 @@ config DATA_SHIFT
 	default 24 if STRICT_KERNEL_RWX && PPC64
 	range 17 28 if (STRICT_KERNEL_RWX || DEBUG_PAGEALLOC || KFENCE) && PPC_BOOK3S_32
 	range 19 23 if (STRICT_KERNEL_RWX || DEBUG_PAGEALLOC || KFENCE) && PPC_8xx
-	range 20 24 if (STRICT_KERNEL_RWX || DEBUG_PAGEALLOC || KFENCE) && PPC_FSL_BOOKE
+	range 20 24 if (STRICT_KERNEL_RWX || DEBUG_PAGEALLOC || KFENCE) && FSL_BOOKE
 	default 22 if STRICT_KERNEL_RWX && PPC_BOOK3S_32
 	default 18 if (DEBUG_PAGEALLOC || KFENCE) && PPC_BOOK3S_32
 	default 23 if STRICT_KERNEL_RWX && PPC_8xx

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #103 lore raw

PATCH 103/862 powerpc/boot: Explicitly disable usage of SPE instructions

From: Pali Rohár <[email protected]>

commit 110a58b9f91c66f743c01a2c217243d94c899c23 upstream.

uImage boot wrapper should not use SPE instructions, like kernel itself. Boot wrapper has already disabled Altivec and VSX instructions but not SPE. Options -mno-spe and -mspe=no already set when compilation of kernel, but not when compiling uImage wrapper yet. Fix it.

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/boot/Makefile |    1 +
 1 file changed, 1 insertion(+)

arch/powerpc/boot/Makefile +1 -0

@@ -34,6 +34,7 @@ endif
 
 BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
 		 -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \
+		 $(call cc-option,-mno-spe) $(call cc-option,-mspe=no) \
 		 -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
 		 $(LINUXINCLUDE)

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #104 lore raw

PATCH 104/862 slimbus: qcom-ngd: use correct error in message of pdr_add_lookup() failure

From: Krzysztof Kozlowski <[email protected]>

commit 5038d21dde818fe74ba1fcb6f2cee35b8c2ebbf2 upstream.

Use correct error code, instead of previous 'ret' value, when printing error from pdr_add_lookup() failure.

Fixes e1ae85e1830e ("slimbus: qcom-ngd-ctrl: add Protection Domain Restart Support")

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

Signed-off-by Srinivas Kandagatla <[email protected]>

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

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

---
 drivers/slimbus/qcom-ngd-ctrl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/slimbus/qcom-ngd-ctrl.c +2 -1

@@ -1581,8 +1581,9 @@ static int qcom_slim_ngd_ctrl_probe(stru
 
 	pds = pdr_add_lookup(ctrl->pdr, "avs/audio", "msm/adsp/audio_pd");
 	if (IS_ERR(pds) && PTR_ERR(pds) != -EALREADY) {
+		ret = PTR_ERR(pds);
 		dev_err(dev, "pdr add lookup failed: %d\n", ret);
-		return PTR_ERR(pds);
+		return ret;
 	}
 
 	platform_driver_register(&qcom_slim_ngd_driver);

Greg Kroah-Hartman

author maintainer

2022-10-19 12:16 UTC #105 lore raw

PATCH 105/862 slimbus: qcom-ngd: cleanup in probe error path

From: Krzysztof Kozlowski <[email protected]>

commit 16f14551d0df9e7cd283545d7d748829594d912f upstream.

Add proper error path in probe() to cleanup resources previously acquired/allocated to fix warnings visible during probe deferral:

notifier callback qcom_slim_ngd_ssr_notify already registered

  WARNING: CPU: 6 PID: 70 at kernel/notifier.c:28 notifier_chain_register+0x5c/0x90
  Modules linked in:
  CPU: 6 PID: 70 Comm: kworker/u16:1 Not tainted 6.0.0-rc3-next-20220830 #380
  Call trace:
   notifier_chain_register+0x5c/0x90
   srcu_notifier_chain_register+0x44/0x90
   qcom_register_ssr_notifier+0x38/0x4c
   qcom_slim_ngd_ctrl_probe+0xd8/0x400
   platform_probe+0x6c/0xe0
   really_probe+0xbc/0x2d4
   __driver_probe_device+0x78/0xe0
   driver_probe_device+0x3c/0x12c
   __device_attach_driver+0xb8/0x120
   bus_for_each_drv+0x78/0xd0
   __device_attach+0xa8/0x1c0
   device_initial_probe+0x18/0x24
   bus_probe_device+0xa0/0xac
   deferred_probe_work_func+0x88/0xc0
   process_one_work+0x1d4/0x320
   worker_thread+0x2cc/0x44c
   kthread+0x110/0x114
   ret_from_fork+0x10/0x20

Fixes e1ae85e1830e ("slimbus: qcom-ngd-ctrl: add Protection Domain Restart Support")

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

Signed-off-by Srinivas Kandagatla <[email protected]>

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

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

---
 drivers/slimbus/qcom-ngd-ctrl.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

drivers/slimbus/qcom-ngd-ctrl.c +11 -2

@@ -1576,18 +1576,27 @@ static int qcom_slim_ngd_ctrl_probe(stru
 	ctrl->pdr = pdr_handle_alloc(slim_pd_status, ctrl);
 	if (IS_ERR(ctrl->pdr)) {
 		dev_err(dev, "Failed to init PDR handle\n");
-		return PTR_ERR(ctrl->pdr);
+		ret = PTR_ERR(ctrl->pdr);
+		goto err_pdr_alloc;
 	}
 
 	pds = pdr_add_lookup(ctrl->pdr, "avs/audio", "msm/adsp/audio_pd");
 	if (IS_ERR(pds) && PTR_ERR(pds) != -EALREADY) {
 		ret = PTR_ERR(pds);
 		dev_err(dev, "pdr add lookup failed: %d\n", ret);
-		return ret;
+		goto err_pdr_lookup;
 	}
 
 	platform_driver_register(&qcom_slim_ngd_driver);
 	return of_qcom_slim_ngd_register(dev, ctrl);
+
+err_pdr_alloc:
+	qcom_unregister_ssr_notifier(ctrl->notifier, &ctrl->nb);
+
+err_pdr_lookup:
+	pdr_handle_release(ctrl->pdr);
+
+	return ret;
 }
 
 static int qcom_slim_ngd_ctrl_remove(struct platform_device *pdev)

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #106 lore raw

PATCH 106/862 scsi: lpfc: Rework MIB Rx Monitor debug info logic

From: James Smart <[email protected]>

commit bd269188ea94e40ab002cad7b0df8f12b8f0de54 upstream.

The kernel test robot reported the following sparse warning:

arch/arm64/include/asm/cmpxchg.h:88:1: sparse: sparse: cast truncates
bits from constant value (369 becomes 69)

On arm64, atomic_xchg only works on 8-bit byte fields. Thus, the macro usage of LPFC_RXMONITOR_TABLE_IN_USE can be unintentionally truncated leading to all logic involving the LPFC_RXMONITOR_TABLE_IN_USE macro to not work properly.

Replace the Rx Table atomic_t indexing logic with a new lpfc_rx_info_monitor structure that holds a circular ring buffer. For locking semantics, a spinlock_t is used.

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

Fixes 17b27ac59224 ("scsi: lpfc: Add rx monitoring statistics")

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

Co-developed-by Justin Tee <[email protected]>

Signed-off-by Justin Tee <[email protected]>

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

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

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

---
 drivers/scsi/lpfc/lpfc.h         |   14 +-
 drivers/scsi/lpfc/lpfc_crtn.h    |    8 +
 drivers/scsi/lpfc/lpfc_debugfs.c |   59 ++----------
 drivers/scsi/lpfc/lpfc_debugfs.h |    2 
 drivers/scsi/lpfc/lpfc_init.c    |   83 ++++-------------
 drivers/scsi/lpfc/lpfc_mem.c     |    9 +
 drivers/scsi/lpfc/lpfc_sli.c     |  190 +++++++++++++++++++++++++++++++++++++--
 7 files changed, 240 insertions(+), 125 deletions(-)

drivers/scsi/lpfc/lpfc.h +9 -5

@@ -1570,10 +1570,7 @@ struct lpfc_hba {
 	u32 cgn_acqe_cnt;
 
 	/* RX monitor handling for CMF */
-	struct rxtable_entry *rxtable;  /* RX_monitor information */
-	atomic_t rxtable_idx_head;
-#define LPFC_RXMONITOR_TABLE_IN_USE     (LPFC_MAX_RXMONITOR_ENTRY + 73)
-	atomic_t rxtable_idx_tail;
+	struct lpfc_rx_info_monitor *rx_monitor;
 	atomic_t rx_max_read_cnt;       /* Maximum read bytes */
 	uint64_t rx_block_cnt;

@@ -1622,7 +1619,7 @@ struct lpfc_hba {
 
 #define LPFC_MAX_RXMONITOR_ENTRY	800
 #define LPFC_MAX_RXMONITOR_DUMP		32
-struct rxtable_entry {
+struct rx_info_entry {
 	uint64_t cmf_bytes;	/* Total no of read bytes for CMF_SYNC_WQE */
 	uint64_t total_bytes;   /* Total no of read bytes requested */
 	uint64_t rcv_bytes;     /* Total no of read bytes completed */

@@ -1637,6 +1634,13 @@ struct rxtable_entry {
 	uint32_t timer_interval;
 };
 
+struct lpfc_rx_info_monitor {
+	struct rx_info_entry *ring; /* info organized in a circular buffer */
+	u32 head_idx, tail_idx; /* index to head/tail of ring */
+	spinlock_t lock; /* spinlock for ring */
+	u32 entries; /* storing number entries/size of ring */
+};
+
 static inline struct Scsi_Host *
 lpfc_shost_from_vport(struct lpfc_vport *vport)
 {

drivers/scsi/lpfc/lpfc_crtn.h +8 -0

@@ -92,6 +92,14 @@ void lpfc_cgn_dump_rxmonitor(struct lpfc
 void lpfc_cgn_update_stat(struct lpfc_hba *phba, uint32_t dtag);
 void lpfc_unblock_requests(struct lpfc_hba *phba);
 void lpfc_block_requests(struct lpfc_hba *phba);
+int lpfc_rx_monitor_create_ring(struct lpfc_rx_info_monitor *rx_monitor,
+				u32 entries);
+void lpfc_rx_monitor_destroy_ring(struct lpfc_rx_info_monitor *rx_monitor);
+void lpfc_rx_monitor_record(struct lpfc_rx_info_monitor *rx_monitor,
+			    struct rx_info_entry *entry);
+u32 lpfc_rx_monitor_report(struct lpfc_hba *phba,
+			   struct lpfc_rx_info_monitor *rx_monitor, char *buf,
+			   u32 buf_len, u32 max_read_entries);
 
 void lpfc_mbx_cmpl_local_config_link(struct lpfc_hba *, LPFC_MBOXQ_t *);
 void lpfc_mbx_cmpl_reg_login(struct lpfc_hba *, LPFC_MBOXQ_t *);

drivers/scsi/lpfc/lpfc_debugfs.c +10 ~~-49~~

74 lines not on this page · raw message

drivers/scsi/lpfc/lpfc_debugfs.h +1 -1

@@ -282,7 +282,7 @@ struct lpfc_idiag {
 	void *ptr_private;
 };
 
-#define MAX_DEBUGFS_RX_TABLE_SIZE	(128 * LPFC_MAX_RXMONITOR_ENTRY)
+#define MAX_DEBUGFS_RX_INFO_SIZE	(128 * LPFC_MAX_RXMONITOR_ENTRY)
 struct lpfc_rx_monitor_debug {
 	char *i_private;
 	char *buffer;

drivers/scsi/lpfc/lpfc_init.c +23 ~~-60~~

110 lines not on this page · raw message

drivers/scsi/lpfc/lpfc_mem.c +6 -3

@@ -344,9 +344,12 @@ lpfc_mem_free_all(struct lpfc_hba *phba)
 		phba->cgn_i = NULL;
 	}
 
-	/* Free RX table */
-	kfree(phba->rxtable);
-	phba->rxtable = NULL;
+	/* Free RX Monitor */
+	if (phba->rx_monitor) {
+		lpfc_rx_monitor_destroy_ring(phba->rx_monitor);
+		kfree(phba->rx_monitor);
+		phba->rx_monitor = NULL;
+	}
 
 	/* Free the iocb lookup array */
 	kfree(psli->iocbq_lookup);

drivers/scsi/lpfc/lpfc_sli.c +183 -7

208 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #107 lore raw

PATCH 107/862 scsi: qedf: Populate sysfs attributes for vport

From: Saurav Kashyap <[email protected]>

commit 592642e6b11e620e4b43189f8072752429fc8dc3 upstream.

Few vport parameters were displayed by systool as 'Unknown' or 'NULL'. Copy speed, supported_speed, frame_size and update port_type for NPIV port.

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

Tested-by Guangwu Zhang <[email protected]>

Reviewed-by John Meneghini <[email protected]>

Signed-off-by Saurav Kashyap <[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/qedf/qedf_main.c |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

drivers/scsi/qedf/qedf_main.c +21 -0

@@ -1921,6 +1921,27 @@ static int qedf_vport_create(struct fc_v
 		fc_vport_setlink(vn_port);
 	}
 
+	/* Set symbolic node name */
+	if (base_qedf->pdev->device == QL45xxx)
+		snprintf(fc_host_symbolic_name(vn_port->host), 256,
+			 "Marvell FastLinQ 45xxx FCoE v%s", QEDF_VERSION);
+
+	if (base_qedf->pdev->device == QL41xxx)
+		snprintf(fc_host_symbolic_name(vn_port->host), 256,
+			 "Marvell FastLinQ 41xxx FCoE v%s", QEDF_VERSION);
+
+	/* Set supported speed */
+	fc_host_supported_speeds(vn_port->host) = n_port->link_supported_speeds;
+
+	/* Set speed */
+	vn_port->link_speed = n_port->link_speed;
+
+	/* Set port type */
+	fc_host_port_type(vn_port->host) = FC_PORTTYPE_NPIV;
+
+	/* Set maxframe size */
+	fc_host_maxframe_size(vn_port->host) = n_port->mfs;
+
 	QEDF_INFO(&(base_qedf->dbg_ctx), QEDF_LOG_NPIV, "vn_port=%p.\n",
 		   vn_port);

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #108 lore raw

PATCH 108/862 gpio: rockchip: request GPIO mux to pinctrl when setting direction

From: Quentin Schulz <[email protected]>

commit 8ea8af6c8469156ac2042d83d73f6b74eb4b4b45 upstream.

Before the split of gpio and pinctrl sections in their own driver, rockchip_set_mux was called in pinmux_ops.gpio_set_direction for configuring a pin in its GPIO function.

This is essential for cases where pinctrl is "bypassed" by gpio consumers otherwise the GPIO function is not configured for the pin and it does not work. Such was the case for the sysfs/libgpiod userspace GPIO handling.

Let's call pinctrl_gpio_direction_input/output when setting the direction of a GPIO so that the pinctrl core requests from the rockchip pinctrl driver to put the pin in its GPIO function.

Fixes 9ce9a02039de ("pinctrl/rockchip: drop the gpio related codes")

Fixes 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio")

Reviewed-by Heiko Stuebner <[email protected]>

Signed-off-by Quentin Schulz <[email protected]>

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

Signed-off-by Linus Walleij <[email protected]>

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

---
 drivers/gpio/gpio-rockchip.c |    7 +++++++
 1 file changed, 7 insertions(+)

drivers/gpio/gpio-rockchip.c +7 -0

@@ -19,6 +19,7 @@
 #include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
+#include <linux/pinctrl/consumer.h>
 #include <linux/pinctrl/pinconf-generic.h>
 #include <linux/regmap.h>

@@ -156,6 +157,12 @@ static int rockchip_gpio_set_direction(s
 	unsigned long flags;
 	u32 data = input ? 0 : 1;
 
+
+	if (input)
+		pinctrl_gpio_direction_input(bank->pin_base + offset);
+	else
+		pinctrl_gpio_direction_output(bank->pin_base + offset);
+
 	raw_spin_lock_irqsave(&bank->slock, flags);
 	rockchip_gpio_writel_bit(bank, offset, data, bank->gpio_regs->port_ddr);
 	raw_spin_unlock_irqrestore(&bank->slock, flags);

Greg Kroah-Hartman

author maintainer

2022-10-19 08:56 UTC #109 lore raw

PATCH 109/862 pinctrl: rockchip: add pinmux_ops.gpio_set_direction callback

From: Quentin Schulz <[email protected]>

commit 4635c0e2a7f7f3568cbfccae70121f9835efa62c upstream.

Before the split of gpio and pinctrl sections in their own driver, rockchip_set_mux was called in pinmux_ops.gpio_set_direction for configuring a pin in its GPIO function.

Let's re-implement the pinmux_ops.gpio_set_direction callback so that the gpio subsystem can request from the pinctrl driver to put the pin in its GPIO function.

Fixes 9ce9a02039de ("pinctrl/rockchip: drop the gpio related codes")

Reviewed-by Heiko Stuebner <[email protected]>

Signed-off-by Quentin Schulz <[email protected]>

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

Signed-off-by Linus Walleij <[email protected]>

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

---
 drivers/pinctrl/pinctrl-rockchip.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

drivers/pinctrl/pinctrl-rockchip.c +13 -0

@@ -2393,11 +2393,24 @@ static int rockchip_pmx_set(struct pinct
 	return 0;
 }
 
+static int rockchip_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
+					   struct pinctrl_gpio_range *range,
+					   unsigned offset,
+					   bool input)
+{
+	struct rockchip_pinctrl *info = pinctrl_dev_get_drvdata(pctldev);
+	struct rockchip_pin_bank *bank;
+
+	bank = pin_to_bank(info, offset);
+	return rockchip_set_mux(bank, offset - bank->pin_base, RK_FUNC_GPIO);
+}
+
 static const struct pinmux_ops rockchip_pmx_ops = {
 	.get_functions_count	= rockchip_pmx_get_funcs_count,
 	.get_function_name	= rockchip_pmx_get_func_name,
 	.get_function_groups	= rockchip_pmx_get_groups,
 	.set_mux		= rockchip_pmx_set,
+	.gpio_set_direction	= rockchip_pmx_gpio_set_direction,
 };
 
 /*

Greg Kroah-Hartman

author maintainer

2022-10-19 08:51 UTC #110 lore raw

PATCH 110/862 fbdev: smscufx: Fix use-after-free in ufx_ops_open()

From: Hyunwoo Kim <[email protected]>

commit 5610bcfe8693c02e2e4c8b31427f1bdbdecc839c upstream.

A race condition may occur if the user physically removes the USB device while calling open() for this device node.

This is a race condition between the ufx_ops_open() function and the ufx_usb_disconnect() function, which may eventually result in UAF.

So, add a mutex to the ufx_ops_open() and ufx_usb_disconnect() functions to avoid race contidion of krefs.

Signed-off-by Hyunwoo Kim <[email protected]>

Signed-off-by Helge Deller <[email protected]>

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

---
 drivers/video/fbdev/smscufx.c |   14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

drivers/video/fbdev/smscufx.c +13 -1

@@ -137,6 +137,8 @@ static int ufx_submit_urb(struct ufx_dat
 static int ufx_alloc_urb_list(struct ufx_data *dev, int count, size_t size);
 static void ufx_free_urb_list(struct ufx_data *dev);
 
+static DEFINE_MUTEX(disconnect_mutex);
+
 /* reads a control register */
 static int ufx_reg_read(struct ufx_data *dev, u32 index, u32 *data)
 {

@@ -1071,9 +1073,13 @@ static int ufx_ops_open(struct fb_info *
 	if (user == 0 && !console)
 		return -EBUSY;
 
+	mutex_lock(&disconnect_mutex);
+
 	/* If the USB device is gone, we don't accept new opens */
-	if (dev->virtualized)
+	if (dev->virtualized) {
+		mutex_unlock(&disconnect_mutex);
 		return -ENODEV;
+	}
 
 	dev->fb_count++;

@@ -1097,6 +1103,8 @@ static int ufx_ops_open(struct fb_info *
 	pr_debug("open /dev/fb%d user=%d fb_info=%p count=%d",
 		info->node, user, info, dev->fb_count);
 
+	mutex_unlock(&disconnect_mutex);
+
 	return 0;
 }

@@ -1741,6 +1749,8 @@ static void ufx_usb_disconnect(struct us
 {
 	struct ufx_data *dev;
 
+	mutex_lock(&disconnect_mutex);
+
 	dev = usb_get_intfdata(interface);
 
 	pr_debug("USB disconnect starting\n");

@@ -1761,6 +1771,8 @@ static void ufx_usb_disconnect(struct us
 	kref_put(&dev->kref, ufx_free);
 
 	/* consider ufx_data freed */
+
+	mutex_unlock(&disconnect_mutex);
 }
 
 static struct usb_driver ufx_driver = {

Greg Kroah-Hartman

author maintainer

2022-10-19 08:50 UTC #111 lore raw

PATCH 111/862 hwrng: core - let sleep be interrupted when unregistering hwrng

From: Jason A. Donenfeld <[email protected]>

commit 36cb6494429bd64b27b7ff8b4af56f8e526da2b4 upstream.

There are two deadlock scenarios that need addressing, which cause problems when the computer goes to sleep, the interface is set down, and hwrng_unregister() is called. When the deadlock is hit, sleep is delayed for tens of seconds, causing it to fail. These scenarios are:

1) The hwrng kthread can't be stopped while it's sleeping, because it uses msleep_interruptible() which does not react to kthread_stop.

2) A normal user thread can't be interrupted by hwrng_unregister() while it's sleeping, because hwrng_unregister() is called from elsewhere.

We solve both issues by add a completion object called dying that fulfils waiters once we have started the process in hwrng_unregister.

At the same time, we should cleanup a common and useless dmesg splat in the same area.

Link https://lore.kernel.org/all/CAO+Okf6ZJC5-nTE_EJUGQtd8JiCkiEHytGgDsFGTEjs0c00giw@mail.gmail.com/ open here

Reported-by Gregory Erwin <[email protected]>

Fixes fcd09c90c3c5 ("ath9k: use hw_random API instead of directly dumping into random.c")

Link https://lore.kernel.org/lkml/CAO+Okf5k+C+SE6pMVfPf-d8MfVPVq4PO7EY8Hys_DVXtent3HA@mail.gmail.com/ open here

Link https://bugs.archlinux.org/task/75138

Signed-off-by Jason A. Donenfeld <[email protected]>

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

Acked-by Toke Høiland-Jørgensen <[email protected]>

Acked-by Kalle Valo <[email protected]>

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

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

---
 drivers/char/hw_random/core.c        |   19 +++++++++++++++----
 drivers/net/wireless/ath/ath9k/rng.c |    3 ++-
 include/linux/hw_random.h            |    3 +++
 3 files changed, 20 insertions(+), 5 deletions(-)

drivers/char/hw_random/core.c +15 -4

@@ -507,16 +507,17 @@ static int hwrng_fillfn(void *unused)
 			rng->quality = current_quality; /* obsolete */
 		quality = rng->quality;
 		mutex_unlock(&reading_mutex);
+
+		if (rc <= 0)
+			hwrng_msleep(rng, 10000);
+
 		put_rng(rng);
 
 		if (!quality)
 			break;
 
-		if (rc <= 0) {
-			pr_warn("hwrng: no data available\n");
-			msleep_interruptible(10000);
+		if (rc <= 0)
 			continue;
-		}
 
 		/* If we cannot credit at least one bit of entropy,
 		 * keep track of the remainder for the next iteration

@@ -570,6 +571,7 @@ int hwrng_register(struct hwrng *rng)
 
 	init_completion(&rng->cleanup_done);
 	complete(&rng->cleanup_done);
+	init_completion(&rng->dying);
 
 	if (!current_rng ||
 	    (!cur_rng_set_by_user && rng->quality > current_rng->quality)) {

@@ -617,6 +619,7 @@ void hwrng_unregister(struct hwrng *rng)
 
 	old_rng = current_rng;
 	list_del(&rng->list);
+	complete_all(&rng->dying);
 	if (current_rng == rng) {
 		err = enable_best_rng();
 		if (err) {

@@ -685,6 +688,14 @@ void devm_hwrng_unregister(struct device
 }
 EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
 
+long hwrng_msleep(struct hwrng *rng, unsigned int msecs)
+{
+	unsigned long timeout = msecs_to_jiffies(msecs) + 1;
+
+	return wait_for_completion_interruptible_timeout(&rng->dying, timeout);
+}
+EXPORT_SYMBOL_GPL(hwrng_msleep);
+
 static int __init hwrng_modinit(void)
 {
 	int ret;

drivers/net/wireless/ath/ath9k/rng.c +2 -1

@@ -83,7 +83,8 @@ static int ath9k_rng_read(struct hwrng *
 		if (!wait || !max || likely(bytes_read) || fail_stats > 110)
 			break;
 
-		msleep_interruptible(ath9k_rng_delay_get(++fail_stats));
+		if (hwrng_msleep(rng, ath9k_rng_delay_get(++fail_stats)))
+			break;
 	}
 
 	if (wait && !bytes_read && max)

include/linux/hw_random.h +3 -0

@@ -50,6 +50,7 @@ struct hwrng {
 	struct list_head list;
 	struct kref ref;
 	struct completion cleanup_done;
+	struct completion dying;
 };
 
 struct device;

@@ -61,4 +62,6 @@ extern int devm_hwrng_register(struct de
 extern void hwrng_unregister(struct hwrng *rng);
 extern void devm_hwrng_unregister(struct device *dve, struct hwrng *rng);
 
+extern long hwrng_msleep(struct hwrng *rng, unsigned int msecs);
+
 #endif /* LINUX_HWRANDOM_H_ */

Greg Kroah-Hartman

author maintainer

2022-10-19 12:25 UTC #112 lore raw

PATCH 112/862 smb3: do not log confusing message when server returns no network interfaces

From: Steve French <[email protected]>

commit 4659f01e3cd94f64d9bd06764ace2ef8fe1b6227 upstream.

Some servers can return an empty network interface list so, unless multichannel is requested, no need to log an error for this, and when multichannel is requested on mount but no interfaces, log something less confusing. For this case change
parse_server_interfaces: malformed interface info
to
empty network interface list returned by server localhost

Also do not relog this error every ten minutes (only log on mount, once)

Reviewed-by Paulo Alcantara (SUSE) <[email protected]>

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

---
 fs/cifs/cifsproto.h |    2 +-
 fs/cifs/connect.c   |    2 +-
 fs/cifs/smb2ops.c   |   23 ++++++++++++++++++-----
 3 files changed, 20 insertions(+), 7 deletions(-)

fs/cifs/cifsproto.h +1 -1

@@ -639,7 +639,7 @@ cifs_chan_is_iface_active(struct cifs_se
 int
 cifs_chan_update_iface(struct cifs_ses *ses, struct TCP_Server_Info *server);
 int
-SMB3_request_interfaces(const unsigned int xid, struct cifs_tcon *tcon);
+SMB3_request_interfaces(const unsigned int xid, struct cifs_tcon *tcon, bool in_mount);
 
 void extract_unc_hostname(const char *unc, const char **h, size_t *len);
 int copy_path_name(char *dst, const char *src);

fs/cifs/connect.c +1 -1

@@ -155,7 +155,7 @@ static void smb2_query_server_interfaces
 	/*
 	 * query server network interfaces, in case they change
 	 */
-	rc = SMB3_request_interfaces(0, tcon);
+	rc = SMB3_request_interfaces(0, tcon, false);
 	if (rc) {
 		cifs_dbg(FYI, "%s: failed to query server interfaces: %d\n",
 				__func__, rc);

fs/cifs/smb2ops.c +18 -5

@@ -512,8 +512,7 @@ smb3_negotiate_rsize(struct cifs_tcon *t
 
 static int
 parse_server_interfaces(struct network_interface_info_ioctl_rsp *buf,
-			size_t buf_len,
-			struct cifs_ses *ses)
+			size_t buf_len, struct cifs_ses *ses, bool in_mount)
 {
 	struct network_interface_info_ioctl_rsp *p;
 	struct sockaddr_in *addr4;

@@ -543,6 +542,20 @@ parse_server_interfaces(struct network_i
 	}
 	spin_unlock(&ses->iface_lock);
 
+	/*
+	 * Samba server e.g. can return an empty interface list in some cases,
+	 * which would only be a problem if we were requesting multichannel
+	 */
+	if (bytes_left == 0) {
+		/* avoid spamming logs every 10 minutes, so log only in mount */
+		if ((ses->chan_max > 1) && in_mount)
+			cifs_dbg(VFS,
+				 "empty network interface list returned by server %s\n",
+				 ses->server->hostname);
+		rc = -EINVAL;
+		goto out;
+	}
+
 	while (bytes_left >= sizeof(*p)) {
 		memset(&tmp_iface, 0, sizeof(tmp_iface));
 		tmp_iface.speed = le64_to_cpu(p->LinkSpeed);

@@ -673,7 +686,7 @@ out:
 }
 
 int
-SMB3_request_interfaces(const unsigned int xid, struct cifs_tcon *tcon)
+SMB3_request_interfaces(const unsigned int xid, struct cifs_tcon *tcon, bool in_mount)
 {
 	int rc;
 	unsigned int ret_data_len = 0;

@@ -693,7 +706,7 @@ SMB3_request_interfaces(const unsigned i
 		goto out;
 	}
 
-	rc = parse_server_interfaces(out_buf, ret_data_len, ses);
+	rc = parse_server_interfaces(out_buf, ret_data_len, ses, in_mount);
 	if (rc)
 		goto out;

@@ -729,7 +742,7 @@ smb3_qfs_tcon(const unsigned int xid, st
 	if (rc)
 		return;
 
-	SMB3_request_interfaces(xid, tcon);
+	SMB3_request_interfaces(xid, tcon, true /* called during  mount */);
 
 	SMB2_QFS_attr(xid, tcon, fid.persistent_fid, fid.volatile_fid,
 			FS_ATTRIBUTE_INFORMATION);

Greg Kroah-Hartman

author maintainer

2022-10-19 12:19 UTC #113 lore raw

PATCH 113/862 ksmbd: fix incorrect handling of iterate_dir

From: Namjae Jeon <[email protected]>

commit 88541cb414b7a2450c45fc9c131b37b5753b7679 upstream.

if iterate_dir() returns non-negative value, caller has to treat it as normal and check there is any error while populating dentry information. ksmbd doesn't have to do anything because ksmbd already checks too small OutputBufferLength to store one file information.

And because ctx->pos is set to file->f_pos when iterative_dir is called, remove restart_ctx(). And if iterate_dir() return -EIO, which mean directory entry is corrupted, return STATUS_FILE_CORRUPT_ERROR error response.

This patch fixes some failure of SMB2_QUERY_DIRECTORY, which happens when ntfs3 is local filesystem.

Fixes e2f34481b24d ("cifsd: add server-side procedures for SMB3")

Signed-off-by Hyunchul Lee <[email protected]>

Signed-off-by Namjae Jeon <[email protected]>

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

---
 fs/ksmbd/smb2pdu.c |   14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

fs/ksmbd/smb2pdu.c +4 ~~-10~~

@@ -3808,11 +3808,6 @@ static int __query_dir(struct dir_contex
 	return 0;
 }
 
-static void restart_ctx(struct dir_context *ctx)
-{
-	ctx->pos = 0;
-}
-
 static int verify_info_level(int info_level)
 {
 	switch (info_level) {

@@ -3921,7 +3916,6 @@ int smb2_query_dir(struct ksmbd_work *wo
 	if (srch_flag & SMB2_REOPEN || srch_flag & SMB2_RESTART_SCANS) {
 		ksmbd_debug(SMB, "Restart directory scan\n");
 		generic_file_llseek(dir_fp->filp, 0, SEEK_SET);
-		restart_ctx(&dir_fp->readdir_data.ctx);
 	}
 
 	memset(&d_info, 0, sizeof(struct ksmbd_dir_info));

@@ -3968,11 +3962,9 @@ int smb2_query_dir(struct ksmbd_work *wo
 	 */
 	if (!d_info.out_buf_len && !d_info.num_entry)
 		goto no_buf_len;
-	if (rc == 0)
-		restart_ctx(&dir_fp->readdir_data.ctx);
-	if (rc == -ENOSPC)
+	if (rc > 0 || rc == -ENOSPC)
 		rc = 0;
-	if (rc)
+	else if (rc)
 		goto err_out;
 
 	d_info.wptr = d_info.rptr;

@@ -4029,6 +4021,8 @@ err_out2:
 		rsp->hdr.Status = STATUS_NO_MEMORY;
 	else if (rc == -EFAULT)
 		rsp->hdr.Status = STATUS_INVALID_INFO_CLASS;
+	else if (rc == -EIO)
+		rsp->hdr.Status = STATUS_FILE_CORRUPT_ERROR;
 	if (!rsp->hdr.Status)
 		rsp->hdr.Status = STATUS_UNEXPECTED_IO_ERROR;

Greg Kroah-Hartman

author maintainer

2022-10-19 12:19 UTC #114 lore raw

PATCH 114/862 ksmbd: fix endless loop when encryption for response fails

From: Namjae Jeon <[email protected]>

commit 360c8ee6fefdb496fffd2c18bb9a96a376a1a804 upstream.

If ->encrypt_resp return error, goto statement cause endless loop. It send an error response immediately after removing it.

Fixes 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")

Signed-off-by Namjae Jeon <[email protected]>

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

---
 fs/ksmbd/server.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

fs/ksmbd/server.c +1 -3

@@ -235,10 +235,8 @@ send:
 	if (work->sess && work->sess->enc && work->encrypted &&
 	    conn->ops->encrypt_resp) {
 		rc = conn->ops->encrypt_resp(work);
-		if (rc < 0) {
+		if (rc < 0)
 			conn->ops->set_rsp_status(work, STATUS_DATA_ERROR);
-			goto send;
-		}
 	}
 
 	ksmbd_conn_write(work);

Greg Kroah-Hartman

author maintainer

2022-10-19 09:00 UTC #115 lore raw

PATCH 115/862 ksmbd: Fix wrong return value and message length check in smb2_ioctl()

From: Zhang Xiaoxu <[email protected]>

commit b1763d265af62800ec96eeb79803c4c537dcef3a upstream.

Commit c7803b05f74b ("smb3: fix ksmbd bigendian bug in oplock break, and move its struct to smbfs_common") use the defination of 'struct validate_negotiate_info_req' in smbfs_common, the array length of 'Dialects' changed from 1 to 4, but the protocol does not require the client to send all 4. This lead the request which satisfied with protocol and server to fail.

So just ensure the request payload has the 'DialectCount' in smb2_ioctl(), then fsctl_validate_negotiate_info() will use it to validate the payload length and each dialect.

Also when the {in, out}_buf_len is less than the required, should goto out to initialize the status in the response header.

Fixes f7db8fd03a4b ("ksmbd: add validation in smb2_ioctl")

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

Acked-by Namjae Jeon <[email protected]>

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

---
 fs/ksmbd/smb2pdu.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

fs/ksmbd/smb2pdu.c +9 -4

@@ -7637,11 +7637,16 @@ int smb2_ioctl(struct ksmbd_work *work)
 			goto out;
 		}
 
-		if (in_buf_len < sizeof(struct validate_negotiate_info_req))
-			return -EINVAL;
+		if (in_buf_len < offsetof(struct validate_negotiate_info_req,
+					  Dialects)) {
+			ret = -EINVAL;
+			goto out;
+		}
 
-		if (out_buf_len < sizeof(struct validate_negotiate_info_rsp))
-			return -EINVAL;
+		if (out_buf_len < sizeof(struct validate_negotiate_info_rsp)) {
+			ret = -EINVAL;
+			goto out;
+		}
 
 		ret = fsctl_validate_negotiate_info(conn,
 			(struct validate_negotiate_info_req *)&req->Buffer[0],

Greg Kroah-Hartman

author maintainer

2022-10-19 13:52 UTC #116 lore raw

PATCH 116/862 ksmbd: Fix user namespace mapping

From: Mickaël Salaün <[email protected]>

commit 7c88c1e0ab1704bacb751341ee6431c3be34b834 upstream.

A kernel daemon should not rely on the current thread, which is unknown and might be malicious. Before this security fix, ksmbd_override_fsids() didn't correctly override FS UID/GID which means that arbitrary user space threads could trick the kernel to impersonate arbitrary users or groups for file system access checks, leading to file system access bypass.

This was found while investigating truncate support for Landlock:
https://lore.kernel.org/r/CAKYAXd8fpMJ7guizOjHgxEyyjoUwPsx3jLOPZP=wPYcbhkVXqA@mail.gmail.com

Fixes e2f34481b24d ("cifsd: add server-side procedures for SMB3")

Cc Hyunchul Lee <[email protected]>

Cc Steve French <[email protected]>

Signed-off-by Mickaël Salaün <[email protected]>

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

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

Acked-by Namjae Jeon <[email protected]>