Skip to contentSkip to conversation

5.7.10-rc1 review

PATCH In review Greg Kroah-Hartman 7 participants 256 messages Jul 20, 2020 – Jul 27, 2020 Stable branch Page 2 of 2

lore
Share & tools
lore
author maintainer
#155 lore raw

PATCH 153/244 ALSA: usb-audio: Fix race against the error recovery URB submission

In reply to Greg Kroah-Hartman

From: Takashi Iwai <[email protected]>

commit 9b7e5208a941e2e491a83eb5fa83d889e888fa2f upstream.

USB MIDI driver has an error recovery mechanism to resubmit the URB in the delayed timer handler, and this may race with the standard start / stop operations. Although both start and stop operations themselves don't race with each other due to the umidi->mutex protection, but this isn't applied to the timer handler.

For fixing this potential race, the following changes are applied:

- Since the timer handler can't use the mutex, we apply the umidi->disc_lock protection at each input stream URB submission; this also needs to change the GFP flag to GFP_ATOMIC
- Add a check of the URB refcount and skip if already submitted
- Move the timer cancel call at disconnection to the beginning of the procedure; this assures the in-flight timer handler is gone properly before killing all pending URBs

---
 sound/usb/midi.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)
sound/usb/midi.c +12 -5
@@ -1499,6 +1499,8 @@ void snd_usbmidi_disconnect(struct list_
 	spin_unlock_irq(&umidi->disc_lock);
 	up_write(&umidi->disc_rwsem);
 
+	del_timer_sync(&umidi->error_timer);
+
 	for (i = 0; i < MIDI_MAX_ENDPOINTS; ++i) {
 		struct snd_usb_midi_endpoint *ep = &umidi->endpoints[i];
 		if (ep->out)
@@ -1525,7 +1527,6 @@ void snd_usbmidi_disconnect(struct list_
 			ep->in = NULL;
 		}
 	}
-	del_timer_sync(&umidi->error_timer);
 }
 EXPORT_SYMBOL(snd_usbmidi_disconnect);
 
@@ -2301,16 +2302,22 @@ void snd_usbmidi_input_stop(struct list_
 }
 EXPORT_SYMBOL(snd_usbmidi_input_stop);
 
-static void snd_usbmidi_input_start_ep(struct snd_usb_midi_in_endpoint *ep)
+static void snd_usbmidi_input_start_ep(struct snd_usb_midi *umidi,
+				       struct snd_usb_midi_in_endpoint *ep)
 {
 	unsigned int i;
+	unsigned long flags;
 
 	if (!ep)
 		return;
 	for (i = 0; i < INPUT_URBS; ++i) {
 		struct urb *urb = ep->urbs[i];
-		urb->dev = ep->umidi->dev;
-		snd_usbmidi_submit_urb(urb, GFP_KERNEL);
+		spin_lock_irqsave(&umidi->disc_lock, flags);
+		if (!atomic_read(&urb->use_count)) {
+			urb->dev = ep->umidi->dev;
+			snd_usbmidi_submit_urb(urb, GFP_ATOMIC);
+		}
+		spin_unlock_irqrestore(&umidi->disc_lock, flags);
 	}
 }
 
@@ -2326,7 +2333,7 @@ void snd_usbmidi_input_start(struct list
 	if (umidi->input_running || !umidi->opened[1])
 		return;
 	for (i = 0; i < MIDI_MAX_ENDPOINTS; ++i)
-		snd_usbmidi_input_start_ep(umidi->endpoints[i].in);
+		snd_usbmidi_input_start_ep(umidi, umidi->endpoints[i].in);
 	umidi->input_running = 1;
 }
 EXPORT_SYMBOL(snd_usbmidi_input_start);
author maintainer
#156 lore raw

PATCH 154/244 ALSA: hda/realtek - change to suitable link model for ASUS platform

In reply to Greg Kroah-Hartman

From: Kailang Yang <[email protected]>

commit ef9ddb9dc4f8b1da3b975918cd1fd98ec055b918 upstream.

ASUS platform couldn't need to use Headset Mode model. It changes to the suitable model.

---
 sound/pci/hda/patch_realtek.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
sound/pci/hda/patch_realtek.c +2 -2
@@ -7082,7 +7082,7 @@ static const struct hda_fixup alc269_fix
 			{ }
 		},
 		.chained = true,
-		.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+		.chain_id = ALC269_FIXUP_HEADSET_MIC
 	},
 	[ALC294_FIXUP_ASUS_HEADSET_MIC] = {
 		.type = HDA_FIXUP_PINS,
@@ -7091,7 +7091,7 @@ static const struct hda_fixup alc269_fix
 			{ }
 		},
 		.chained = true,
-		.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+		.chain_id = ALC269_FIXUP_HEADSET_MIC
 	},
 	[ALC294_FIXUP_ASUS_SPK] = {
 		.type = HDA_FIXUP_VERBS,
author maintainer
#157 lore raw

PATCH 155/244 ALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G14(G401) series with ALC289

In reply to Greg Kroah-Hartman

From: Armas Spann <[email protected]>

commit ff53664daff2a65f4bf2479ac56dfb3e908deff0 upstream.

This patch adds support for headset mic to the ASUS ROG Zephyrus G14(GA401) notebook series by adding the corresponding vendor/pci_device id, as well as adding a new fixup for the used realtek ALC289. The fixup stets the correct pin to get the headset mic correctly recognized on audio-jack.

---
 sound/pci/hda/patch_realtek.c |    9 +++++++++
 1 file changed, 9 insertions(+)
sound/pci/hda/patch_realtek.c +9 -0
@@ -6117,6 +6117,7 @@ enum {
 	ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS,
 	ALC269VC_FIXUP_ACER_HEADSET_MIC,
 	ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE,
+	ALC289_FIXUP_ASUS_G401,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -7324,6 +7325,13 @@ static const struct hda_fixup alc269_fix
 		.chained = true,
 		.chain_id = ALC269_FIXUP_HEADSET_MIC
 	},
+	[ALC289_FIXUP_ASUS_G401] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x19, 0x03a11020 }, /* headset mic with jack detect */
+			{ }
+		},
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7504,6 +7512,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1043, 0x1bbd, "ASUS Z550MA", ALC255_FIXUP_ASUS_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1043, 0x1c23, "Asus X55U", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
 	SND_PCI_QUIRK(0x1043, 0x1ccd, "ASUS X555UB", ALC256_FIXUP_ASUS_MIC),
+	SND_PCI_QUIRK(0x1043, 0x1f11, "ASUS Zephyrus G14", ALC289_FIXUP_ASUS_G401),
 	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),
author maintainer
#158 lore raw

PATCH 156/244 ALSA: hda/realtek: Enable headset mic of Acer TravelMate B311R-31 with ALC256

In reply to Greg Kroah-Hartman

From: Jian-Hong Pan <[email protected]>

commit f50a121d2f32bccc1d6b94df925a1ce44ea7eff7 upstream.

The Acer TravelMate B311R-31 laptop's audio (1025:1430) with ALC256 cannot detect the headset microphone until ALC256_FIXUP_ACER_MIC_NO_PRESENCE quirk maps the NID 0x19 as the headset mic pin.

---
 sound/pci/hda/patch_realtek.c |   11 +++++++++++
 1 file changed, 11 insertions(+)
sound/pci/hda/patch_realtek.c +11 -0
@@ -6118,6 +6118,7 @@ enum {
 	ALC269VC_FIXUP_ACER_HEADSET_MIC,
 	ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE,
 	ALC289_FIXUP_ASUS_G401,
+	ALC256_FIXUP_ACER_MIC_NO_PRESENCE,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -7332,6 +7333,15 @@ static const struct hda_fixup alc269_fix
 			{ }
 		},
 	},
+	[ALC256_FIXUP_ACER_MIC_NO_PRESENCE] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x19, 0x02a11120 }, /* use as headset mic, without its own jack detect */
+			{ }
+		},
+		.chained = true,
+		.chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7360,6 +7370,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890", ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21", ALC233_FIXUP_ACER_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T", ALC255_FIXUP_ACER_HEADSET_MIC),
+	SND_PCI_QUIRK(0x1025, 0x1430, "Acer TravelMate B311R-31", ALC256_FIXUP_ACER_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
 	SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710", ALC275_FIXUP_DELL_XPS),
 	SND_PCI_QUIRK(0x1028, 0x05bd, "Dell Latitude E6440", ALC292_FIXUP_DELL_E7X),
author maintainer
#159 lore raw

PATCH 157/244 ALSA: hda/realtek - Enable Speaker for ASUS UX533 and UX534

In reply to Greg Kroah-Hartman

From: Kailang Yang <[email protected]>

commit 473fbe13fd6f9082e413aea37e624ecbce5463cc upstream.

ASUS UX533 and UX534 speaker still can't output. End User feedback speaker didn't have output. Add this COEF value will enable it.

Fixes 4e051106730d ("ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294")
---
 sound/pci/hda/patch_realtek.c |    2 ++
 1 file changed, 2 insertions(+)
sound/pci/hda/patch_realtek.c +2 -0
@@ -7101,6 +7101,8 @@ static const struct hda_fixup alc269_fix
 			/* Set EAPD high */
 			{ 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
 			{ 0x20, AC_VERB_SET_PROC_COEF, 0x8800 },
+			{ 0x20, AC_VERB_SET_COEF_INDEX, 0x0f },
+			{ 0x20, AC_VERB_SET_PROC_COEF, 0x7774 },
 			{ }
 		},
 		.chained = true,
author maintainer
#160 lore raw

PATCH 158/244 ALSA: hda/realtek - Enable Speaker for ASUS UX563

In reply to Greg Kroah-Hartman

From: Kailang Yang <[email protected]>

commit 158ae2f5e6fead30be1f0c203037f5556871513b upstream.

ASUS UX563 speaker can't output.
Add quirk to link suitable model will enable it. This model also could enable headset Mic.

---
 sound/pci/hda/patch_realtek.c |    1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -7516,6 +7516,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL", ALC294_FIXUP_ASUS_DUAL_SPK),
 	SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA", ALC256_FIXUP_ASUS_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1043, 0x18f1, "Asus FX505DT", ALC256_FIXUP_ASUS_HEADSET_MIC),
+	SND_PCI_QUIRK(0x1043, 0x194e, "ASUS UX563FD", ALC294_FIXUP_ASUS_HPE),
 	SND_PCI_QUIRK(0x1043, 0x19ce, "ASUS B9450FA", ALC294_FIXUP_ASUS_HPE),
 	SND_PCI_QUIRK(0x1043, 0x19e1, "ASUS UX581LV", ALC295_FIXUP_ASUS_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
author maintainer
#161 lore raw

PATCH 159/244 thunderbolt: Fix path indices used in USB3 tunnel discovery

In reply to Greg Kroah-Hartman

From: Mika Westerberg <[email protected]>

commit 8b94a4b92327d061327117e127d7d44a4a43e639 upstream.

The USB3 discovery used wrong indices when tunnel is discovered. It should use TB_USB3_PATH_DOWN for path that flows downstream and TB_USB3_PATH_UP when it flows upstream. This should not affect the functionality but better to fix it.

Fixes e6f818585713 ("thunderbolt: Add support for USB 3.x tunnels")
---
 drivers/thunderbolt/tunnel.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/thunderbolt/tunnel.c +6 -6
@@ -913,21 +913,21 @@ struct tb_tunnel *tb_tunnel_discover_usb
 	 * case.
 	 */
 	path = tb_path_discover(down, TB_USB3_HOPID, NULL, -1,
-				&tunnel->dst_port, "USB3 Up");
+				&tunnel->dst_port, "USB3 Down");
 	if (!path) {
 		/* Just disable the downstream port */
 		tb_usb3_port_enable(down, false);
 		goto err_free;
 	}
-	tunnel->paths[TB_USB3_PATH_UP] = path;
-	tb_usb3_init_path(tunnel->paths[TB_USB3_PATH_UP]);
+	tunnel->paths[TB_USB3_PATH_DOWN] = path;
+	tb_usb3_init_path(tunnel->paths[TB_USB3_PATH_DOWN]);
 
 	path = tb_path_discover(tunnel->dst_port, -1, down, TB_USB3_HOPID, NULL,
-				"USB3 Down");
+				"USB3 Up");
 	if (!path)
 		goto err_deactivate;
-	tunnel->paths[TB_USB3_PATH_DOWN] = path;
-	tb_usb3_init_path(tunnel->paths[TB_USB3_PATH_DOWN]);
+	tunnel->paths[TB_USB3_PATH_UP] = path;
+	tb_usb3_init_path(tunnel->paths[TB_USB3_PATH_UP]);
 
 	/* Validate that the tunnel is complete */
 	if (!tb_port_is_usb3_up(tunnel->dst_port)) {
author maintainer
#162 lore raw

PATCH 160/244 USB: c67x00: fix use after free in c67x00_giveback_urb

In reply to Greg Kroah-Hartman

From: Tom Rix <[email protected]>

commit 211f08347355cba1f769bbf3355816a12b3ddd55 upstream.

clang static analysis flags this error

c67x00-sched.c:489:55: warning: Use of memory after it is freed [unix.Malloc]

        usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, urbp->status);
                                                             ^~~~~~~~~~~~

Problem happens in this block of code

	c67x00_release_urb(c67x00, urb);
	usb_hcd_unlink_urb_from_ep(c67x00_hcd_to_hcd(c67x00), urb);
	spin_unlock(&c67x00->lock);
	usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, urbp->status);

In the call to c67x00_release_urb has this freeing of urbp

	urbp = urb->hcpriv;
	urb->hcpriv = NULL;
	list_del(&urbp->hep_node);
	kfree(urbp);

And so urbp is freed before usb_hcd_giveback_urb uses it as its 3rd parameter.

Since all is required is the status, pass the status directly as is done in c64x00_urb_dequeue

Fixes e9b29ffc519b ("USB: add Cypress c67x00 OTG controller HCD driver")
Cc stable <[email protected]>
---
 drivers/usb/c67x00/c67x00-sched.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/c67x00/c67x00-sched.c +1 -1
@@ -486,7 +486,7 @@ c67x00_giveback_urb(struct c67x00_hcd *c
 	c67x00_release_urb(c67x00, urb);
 	usb_hcd_unlink_urb_from_ep(c67x00_hcd_to_hcd(c67x00), urb);
 	spin_unlock(&c67x00->lock);
-	usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, urbp->status);
+	usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, status);
 	spin_lock(&c67x00->lock);
 }
 
author maintainer
#163 lore raw

PATCH 161/244 usb: dwc2: Fix shutdown callback in platform

In reply to Greg Kroah-Hartman

From: Minas Harutyunyan <[email protected]>

commit 4fdf228cdf6925af45a2066d403821e0977bfddb upstream.

To avoid lot of interrupts from dwc2 core, which can be asserted in specific conditions need to disable interrupts on HW level instead of disable IRQs on Kernel level, because of IRQ can be shared between drivers.

---
 drivers/usb/dwc2/platform.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/dwc2/platform.c +2 -1
@@ -342,7 +342,8 @@ static void dwc2_driver_shutdown(struct
 {
 	struct dwc2_hsotg *hsotg = platform_get_drvdata(dev);
 
-	disable_irq(hsotg->irq);
+	dwc2_disable_global_interrupts(hsotg);
+	synchronize_irq(hsotg->irq);
 }
 
 /**
author maintainer
#164 lore raw

PATCH 162/244 usb: chipidea: core: add wakeup support for extcon

In reply to Greg Kroah-Hartman

From: Peter Chen <[email protected]>

commit 876d4e1e8298ad1f94d9e9392fc90486755437b4 upstream.

If wakeup event occurred by extcon event, it needs to call ci_irq again since the first ci_irq calling at extcon notifier only wakes up controller, but do noop for event handling, it causes the extcon use case can't work well from low power mode.

---
 drivers/usb/chipidea/core.c |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
drivers/usb/chipidea/core.c +24 -0
@@ -1265,6 +1265,29 @@ static void ci_controller_suspend(struct
 	enable_irq(ci->irq);
 }
 
+/*
+ * Handle the wakeup interrupt triggered by extcon connector
+ * We need to call ci_irq again for extcon since the first
+ * interrupt (wakeup int) only let the controller be out of
+ * low power mode, but not handle any interrupts.
+ */
+static void ci_extcon_wakeup_int(struct ci_hdrc *ci)
+{
+	struct ci_hdrc_cable *cable_id, *cable_vbus;
+	u32 otgsc = hw_read_otgsc(ci, ~0);
+
+	cable_id = &ci->platdata->id_extcon;
+	cable_vbus = &ci->platdata->vbus_extcon;
+
+	if (!IS_ERR(cable_id->edev) && ci->is_otg &&
+		(otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS))
+		ci_irq(ci->irq, ci);
+
+	if (!IS_ERR(cable_vbus->edev) && ci->is_otg &&
+		(otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS))
+		ci_irq(ci->irq, ci);
+}
+
 static int ci_controller_resume(struct device *dev)
 {
 	struct ci_hdrc *ci = dev_get_drvdata(dev);
@@ -1297,6 +1320,7 @@ static int ci_controller_resume(struct d
 		enable_irq(ci->irq);
 		if (ci_otg_is_fsm_mode(ci))
 			ci_otg_fsm_wakeup_by_srp(ci);
+		ci_extcon_wakeup_int(ci);
 	}
 
 	return 0;
author maintainer
#165 lore raw

PATCH 163/244 usb: gadget: function: fix missing spinlock in f_uac1_legacy

In reply to Greg Kroah-Hartman

From: Zhang Qiang <[email protected]>

commit 8778eb0927ddcd3f431805c37b78fa56481aeed9 upstream.

Add a missing spinlock protection for play_queue, because the play_queue may be destroyed when the "playback_work" work func and "f_audio_out_ep_complete" callback func operate this paly_queue at the same time.

Fixes c6994e6f067cf ("USB: gadget: add USB Audio Gadget driver")
Cc stable <[email protected]>
---
 drivers/usb/gadget/function/f_uac1_legacy.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/usb/gadget/function/f_uac1_legacy.c +2 -0
@@ -336,7 +336,9 @@ static int f_audio_out_ep_complete(struc
 
 	/* Copy buffer is full, add it to the play_queue */
 	if (audio_buf_size - copy_buf->actual < req->actual) {
+		spin_lock_irq(&audio->lock);
 		list_add_tail(&copy_buf->list, &audio->play_queue);
+		spin_unlock_irq(&audio->lock);
 		schedule_work(&audio->playback_work);
 		copy_buf = f_audio_buffer_alloc(audio_buf_size);
 		if (IS_ERR(copy_buf))
author maintainer
#166 lore raw

PATCH 164/244 USB: serial: iuu_phoenix: fix memory corruption

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

commit e7b931bee739e8a77ae216e613d3b99342b6dec0 upstream.

The driver would happily overwrite its write buffer with user data in 256 byte increments due to a removed buffer-space sanity check.

Fixes 5fcf62b0f1f2 ("tty: iuu_phoenix: fix locking.")
Cc stable <[email protected]> # 2.6.31
---
 drivers/usb/serial/iuu_phoenix.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/usb/serial/iuu_phoenix.c +5 -3
@@ -697,14 +697,16 @@ static int iuu_uart_write(struct tty_str
 	struct iuu_private *priv = usb_get_serial_port_data(port);
 	unsigned long flags;
 
-	if (count > 256)
-		return -ENOMEM;
-
 	spin_lock_irqsave(&priv->lock, flags);
 
+	count = min(count, 256 - priv->writelen);
+	if (count == 0)
+		goto out;
+
 	/* fill the buffer */
 	memcpy(priv->writebuf + priv->writelen, buf, count);
 	priv->writelen += count;
+out:
 	spin_unlock_irqrestore(&priv->lock, flags);
 
 	return count;
author maintainer
#167 lore raw

PATCH 165/244 USB: serial: cypress_m8: enable Simply Automated UPB PIM

In reply to Greg Kroah-Hartman

From: James Hilliard <[email protected]>

commit 5c45d04c5081c1830d674f4d22d4400ea2083afe upstream.

This is a UPB (Universal Powerline Bus) PIM (Powerline Interface Module) which allows for controlling multiple UPB compatible devices from Linux using the standard serial interface.

Based on vendor application source code there are two different models of USB based PIM devices in addition to a number of RS232 based PIM's.

The vendor UPB application source contains the following USB ID's:

	#define USB_PCS_VENDOR_ID 0x04b4
	#define USB_PCS_PIM_PRODUCT_ID 0x5500

	#define USB_SAI_VENDOR_ID 0x17dd
	#define USB_SAI_PIM_PRODUCT_ID 0x5500

The first set of ID's correspond to the PIM variant sold by Powerline Control Systems while the second corresponds to the Simply Automated Incorporated PIM. As the product ID for both of these match the default cypress HID->COM RS232 product ID it assumed that they both use an internal variant of this HID->COM RS232 converter hardware. However as the vendor ID for the Simply Automated variant is different we need to also add it to the cypress_M8 driver so that it is properly detected.

---
 drivers/usb/serial/cypress_m8.c |    2 ++
 drivers/usb/serial/cypress_m8.h |    3 +++
 2 files changed, 5 insertions(+)
drivers/usb/serial/cypress_m8.c +2 -0
@@ -59,6 +59,7 @@ static const struct usb_device_id id_tab
 
 static const struct usb_device_id id_table_cyphidcomrs232[] = {
 	{ USB_DEVICE(VENDOR_ID_CYPRESS, PRODUCT_ID_CYPHIDCOM) },
+	{ USB_DEVICE(VENDOR_ID_SAI, PRODUCT_ID_CYPHIDCOM) },
 	{ USB_DEVICE(VENDOR_ID_POWERCOM, PRODUCT_ID_UPS) },
 	{ USB_DEVICE(VENDOR_ID_FRWD, PRODUCT_ID_CYPHIDCOM_FRWD) },
 	{ }						/* Terminating entry */
@@ -73,6 +74,7 @@ static const struct usb_device_id id_tab
 	{ USB_DEVICE(VENDOR_ID_DELORME, PRODUCT_ID_EARTHMATEUSB) },
 	{ USB_DEVICE(VENDOR_ID_DELORME, PRODUCT_ID_EARTHMATEUSB_LT20) },
 	{ USB_DEVICE(VENDOR_ID_CYPRESS, PRODUCT_ID_CYPHIDCOM) },
+	{ USB_DEVICE(VENDOR_ID_SAI, PRODUCT_ID_CYPHIDCOM) },
 	{ USB_DEVICE(VENDOR_ID_POWERCOM, PRODUCT_ID_UPS) },
 	{ USB_DEVICE(VENDOR_ID_FRWD, PRODUCT_ID_CYPHIDCOM_FRWD) },
 	{ USB_DEVICE(VENDOR_ID_DAZZLE, PRODUCT_ID_CA42) },
drivers/usb/serial/cypress_m8.h +3 -0
@@ -25,6 +25,9 @@
 #define VENDOR_ID_CYPRESS		0x04b4
 #define PRODUCT_ID_CYPHIDCOM		0x5500
 
+/* Simply Automated HID->COM UPB PIM (using Cypress PID 0x5500) */
+#define VENDOR_ID_SAI			0x17dd
+
 /* FRWD Dongle - a GPS sports watch */
 #define VENDOR_ID_FRWD			0x6737
 #define PRODUCT_ID_CYPHIDCOM_FRWD	0x0001
author maintainer
#168 lore raw

PATCH 166/244 USB: serial: ch341: add new Product ID for CH340

In reply to Greg Kroah-Hartman

From: Igor Moura <[email protected]>

commit 5d0136f8e79f8287e6a36780601f0ce797cf11c2 upstream.

Add PID for CH340 that's found on some ESP8266 dev boards made by LilyGO. The specific device that contains such serial converter can be seen here: https://github.com/LilyGO/LILYGO-T-OI.

Apparently, it's a regular CH340, but I've confirmed with others that also bought this board that the PID found on this device (0x7522) differs from other devices with the "same" converter (0x7523). Simply adding its PID to the driver and rebuilding it made it work as expected.

---
 drivers/usb/serial/ch341.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/serial/ch341.c +1 -0
@@ -77,6 +77,7 @@
 
 static const struct usb_device_id id_table[] = {
 	{ USB_DEVICE(0x4348, 0x5523) },
+	{ USB_DEVICE(0x1a86, 0x7522) },
 	{ USB_DEVICE(0x1a86, 0x7523) },
 	{ USB_DEVICE(0x1a86, 0x5523) },
 	{ },
author maintainer
#169 lore raw

PATCH 167/244 USB: serial: option: add GosunCn GM500 series

In reply to Greg Kroah-Hartman

From: Jörgen Storvist <[email protected]>

commit 08d4ef5cc9203a113702f24725f6cf4db476c958 upstream.

Add USB IDs for GosunCn GM500 series cellular modules.

RNDIS config:
usb-devices

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 12 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=305a ProdID=1404 Rev=03.18
S:  Manufacturer=Android
S:  Product=Android
S:  SerialNumber=
C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#=0x0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
I:  If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
I:  If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option

MBIM config:
usb-devices

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=305a ProdID=1405 Rev=03.18
S:  Manufacturer=Android
S:  Product=Android
S:  SerialNumber=
C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#=0x3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I:  If#=0x4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim

ECM config:
usb-devices

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 13 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=305a ProdID=1406 Rev=03.18
S:  Manufacturer=Android
S:  Product=Android
S:  SerialNumber=
C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#=0x3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
I:  If#=0x4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
---
 drivers/usb/serial/option.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/usb/serial/option.c +3 -0
@@ -2028,6 +2028,9 @@ static const struct usb_device_id option
 	  .driver_info = RSVD(4) | RSVD(5) },
 	{ USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x0105, 0xff),			/* Fibocom NL678 series */
 	  .driver_info = RSVD(6) },
+	{ USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1404, 0xff) },			/* GosunCn GM500 RNDIS */
+	{ USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1405, 0xff) },			/* GosunCn GM500 MBIM */
+	{ USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1406, 0xff) },			/* GosunCn GM500 ECM/NCM */
 	{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);
author maintainer
#170 lore raw

PATCH 168/244 USB: serial: option: add Quectel EG95 LTE modem

In reply to Greg Kroah-Hartman

From: AceLan Kao <[email protected]>

commit da6902e5b6dbca9081e3d377f9802d4fd0c5ea59 upstream.

Add support for Quectel Wireless Solutions Co., Ltd. EG95 LTE modem

T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  5 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=2c7c ProdID=0195 Rev=03.18
S:  Manufacturer=Android
S:  Product=Android
C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
---
 drivers/usb/serial/option.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/usb/serial/option.c +3 -0
@@ -245,6 +245,7 @@ static void option_instat_callback(struc
 /* These Quectel products use Quectel's vendor ID */
 #define QUECTEL_PRODUCT_EC21			0x0121
 #define QUECTEL_PRODUCT_EC25			0x0125
+#define QUECTEL_PRODUCT_EG95			0x0195
 #define QUECTEL_PRODUCT_BG96			0x0296
 #define QUECTEL_PRODUCT_EP06			0x0306
 #define QUECTEL_PRODUCT_EM12			0x0512
@@ -1097,6 +1098,8 @@ static const struct usb_device_id option
 	  .driver_info = RSVD(4) },
 	{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
 	  .driver_info = RSVD(4) },
+	{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG95),
+	  .driver_info = RSVD(4) },
 	{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
 	  .driver_info = RSVD(4) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EP06, 0xff, 0xff, 0xff),
author maintainer
#171 lore raw

PATCH 169/244 virt: vbox: Fix VBGL_IOCTL_VMMDEV_REQUEST_BIG and _LOG req numbers to match upstream

In reply to Greg Kroah-Hartman

From: Hans de Goede <[email protected]>

commit f794db6841e5480208f0c3a3ac1df445a96b079e upstream.

Until this commit the mainline kernel version (this version) of the vboxguest module contained a bug where it defined VBGL_IOCTL_VMMDEV_REQUEST_BIG and VBGL_IOCTL_LOG using _IOC(_IOC_READ | _IOC_WRITE, 'V', ...) instead of
_IO(V, ...) as the out of tree VirtualBox upstream version does.

Since the VirtualBox userspace bits are always built against VirtualBox upstream's headers, this means that so far the mainline kernel version of the vboxguest module has been failing these 2 ioctls with -ENOTTY. I guess that VBGL_IOCTL_VMMDEV_REQUEST_BIG is never used causing us to not hit that one and sofar the vboxguest driver has failed to actually log any log messages passed it through VBGL_IOCTL_LOG.

This commit changes the VBGL_IOCTL_VMMDEV_REQUEST_BIG and VBGL_IOCTL_LOG defines to match the out of tree VirtualBox upstream vboxguest version, while keeping compatibility with the old wrong request defines so as to not break the kernel ABI in case someone has been using the old request defines.

Fixes f6ddd094f579 ("virt: Add vboxguest driver for Virtual Box Guest integration UAPI")
---
 drivers/virt/vboxguest/vboxguest_core.c  |    4 +++-
 drivers/virt/vboxguest/vboxguest_core.h  |   15 +++++++++++++++
 drivers/virt/vboxguest/vboxguest_linux.c |    3 ++-
 include/uapi/linux/vboxguest.h           |    4 ++--
 4 files changed, 22 insertions(+), 4 deletions(-)
drivers/virt/vboxguest/vboxguest_core.c +3 -1
@@ -1520,7 +1520,8 @@ int vbg_core_ioctl(struct vbg_session *s
 
 	/* For VMMDEV_REQUEST hdr->type != VBG_IOCTL_HDR_TYPE_DEFAULT */
 	if (req_no_size == VBG_IOCTL_VMMDEV_REQUEST(0) ||
-	    req == VBG_IOCTL_VMMDEV_REQUEST_BIG)
+	    req == VBG_IOCTL_VMMDEV_REQUEST_BIG ||
+	    req == VBG_IOCTL_VMMDEV_REQUEST_BIG_ALT)
 		return vbg_ioctl_vmmrequest(gdev, session, data);
 
 	if (hdr->type != VBG_IOCTL_HDR_TYPE_DEFAULT)
@@ -1558,6 +1559,7 @@ int vbg_core_ioctl(struct vbg_session *s
 	case VBG_IOCTL_HGCM_CALL(0):
 		return vbg_ioctl_hgcm_call(gdev, session, f32bit, data);
 	case VBG_IOCTL_LOG(0):
+	case VBG_IOCTL_LOG_ALT(0):
 		return vbg_ioctl_log(data);
 	}
 
drivers/virt/vboxguest/vboxguest_core.h +15 -0
@@ -15,6 +15,21 @@
 #include <linux/vboxguest.h>
 #include "vmmdev.h"
 
+/*
+ * The mainline kernel version (this version) of the vboxguest module
+ * contained a bug where it defined VBGL_IOCTL_VMMDEV_REQUEST_BIG and
+ * VBGL_IOCTL_LOG using _IOC(_IOC_READ | _IOC_WRITE, 'V', ...) instead
+ * of _IO(V, ...) as the out of tree VirtualBox upstream version does.
+ *
+ * These _ALT definitions keep compatibility with the wrong defines the
+ * mainline kernel version used for a while.
+ * Note the VirtualBox userspace bits have always been built against
+ * VirtualBox upstream's headers, so this is likely not necessary. But
+ * we must never break our ABI so we keep these around to be 100% sure.
+ */
+#define VBG_IOCTL_VMMDEV_REQUEST_BIG_ALT _IOC(_IOC_READ | _IOC_WRITE, 'V', 3, 0)
+#define VBG_IOCTL_LOG_ALT(s)             _IOC(_IOC_READ | _IOC_WRITE, 'V', 9, s)
+
 struct vbg_session;
 
 /** VBox guest memory balloon. */
drivers/virt/vboxguest/vboxguest_linux.c +2 -1
@@ -131,7 +131,8 @@ static long vbg_misc_device_ioctl(struct
 	 * the need for a bounce-buffer and another copy later on.
 	 */
 	is_vmmdev_req = (req & ~IOCSIZE_MASK) == VBG_IOCTL_VMMDEV_REQUEST(0) ||
-			 req == VBG_IOCTL_VMMDEV_REQUEST_BIG;
+			 req == VBG_IOCTL_VMMDEV_REQUEST_BIG ||
+			 req == VBG_IOCTL_VMMDEV_REQUEST_BIG_ALT;
 
 	if (is_vmmdev_req)
 		buf = vbg_req_alloc(size, VBG_IOCTL_HDR_TYPE_DEFAULT,
include/uapi/linux/vboxguest.h +2 -2
@@ -103,7 +103,7 @@ VMMDEV_ASSERT_SIZE(vbg_ioctl_driver_vers
 
 
 /* IOCTL to perform a VMM Device request larger then 1KB. */
-#define VBG_IOCTL_VMMDEV_REQUEST_BIG	_IOC(_IOC_READ | _IOC_WRITE, 'V', 3, 0)
+#define VBG_IOCTL_VMMDEV_REQUEST_BIG	_IO('V', 3)
 
 
 /** VBG_IOCTL_HGCM_CONNECT data structure. */
@@ -198,7 +198,7 @@ struct vbg_ioctl_log {
 	} u;
 };
 
-#define VBG_IOCTL_LOG(s)		_IOC(_IOC_READ | _IOC_WRITE, 'V', 9, s)
+#define VBG_IOCTL_LOG(s)		_IO('V', 9)
 
 
 /** VBG_IOCTL_WAIT_FOR_EVENTS data structure. */
author maintainer
#172 lore raw

PATCH 170/244 virt: vbox: Fix guest capabilities mask check

In reply to Greg Kroah-Hartman

From: Hans de Goede <[email protected]>

commit 59d1d2e8e1e7c50d2657d5e4812b53f71f507968 upstream.

Check the passed in capabilities against VMMDEV_GUEST_CAPABILITIES_MASK instead of against VMMDEV_EVENT_VALID_EVENT_MASK.
This tightens the allowed mask from 0x7ff to 0x7.

Fixes 0ba002bc4393 ("virt: Add vboxguest driver for Virtual Box Guest integration")
---
 drivers/virt/vboxguest/vboxguest_core.c |    2 +-
 drivers/virt/vboxguest/vmmdev.h         |    2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
drivers/virt/vboxguest/vboxguest_core.c +1 -1
@@ -1444,7 +1444,7 @@ static int vbg_ioctl_change_guest_capabi
 	or_mask = caps->u.in.or_mask;
 	not_mask = caps->u.in.not_mask;
 
-	if ((or_mask | not_mask) & ~VMMDEV_EVENT_VALID_EVENT_MASK)
+	if ((or_mask | not_mask) & ~VMMDEV_GUEST_CAPABILITIES_MASK)
 		return -EINVAL;
 
 	ret = vbg_set_session_capabilities(gdev, session, or_mask, not_mask,
drivers/virt/vboxguest/vmmdev.h +2 -0
@@ -206,6 +206,8 @@ VMMDEV_ASSERT_SIZE(vmmdev_mask, 24 + 8);
  * not.
  */
 #define VMMDEV_GUEST_SUPPORTS_GRAPHICS                      BIT(2)
+/* The mask of valid capabilities, for sanity checking. */
+#define VMMDEV_GUEST_CAPABILITIES_MASK                      0x00000007U
 
 /** struct vmmdev_hypervisorinfo - Hypervisor info structure. */
 struct vmmdev_hypervisorinfo {
author maintainer
#173 lore raw

PATCH 171/244 Revert "tty: xilinx_uartps: Fix missing id assignment to the console"

In reply to Greg Kroah-Hartman

From: Jan Kiszka <[email protected]>

commit 76ed2e105796710cf5b8a4ba43c81eceed948b70 upstream.

This reverts commit 2ae11c46d5fdc46cb396e35911c713d271056d35.

It turned out to break the ultra96-rev1, e.g., which uses uart1 as serial0 (and stdout-path = "serial0:115200n8").

Fixes 2ae11c46d5fd ("tty: xilinx_uartps: Fix missing id assignment to the console")
Cc stable <[email protected]>
---
 drivers/tty/serial/xilinx_uartps.c |    1 -
 1 file changed, 1 deletion(-)
drivers/tty/serial/xilinx_uartps.c +0 -1
@@ -1459,7 +1459,6 @@ static int cdns_uart_probe(struct platfo
 		cdns_uart_uart_driver.nr = CDNS_UART_NR_PORTS;
 #ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE
 		cdns_uart_uart_driver.cons = &cdns_uart_console;
-		cdns_uart_console.index = id;
 #endif
 
 		rc = uart_register_driver(&cdns_uart_uart_driver);
author maintainer
#174 lore raw

PATCH 172/244 tty: serial: cpm_uart: Fix behaviour for non existing GPIOs

In reply to Greg Kroah-Hartman

From: Christophe Leroy <[email protected]>

commit 311eab8d5900ea9088513d4c6b4570058958edb5 upstream.

devm_gpiod_get_index() doesn't return NULL but -ENOENT when the requested GPIO doesn't exist, leading to the following messages:

[    2.742468] gpiod_direction_input: invalid GPIO (errorpointer)
[    2.748147] can't set direction for gpio #2: -2
[    2.753081] gpiod_direction_input: invalid GPIO (errorpointer)
[    2.758724] can't set direction for gpio #3: -2
[    2.763666] gpiod_direction_output: invalid GPIO (errorpointer)
[    2.769394] can't set direction for gpio #4: -2
[    2.774341] gpiod_direction_input: invalid GPIO (errorpointer)
[    2.779981] can't set direction for gpio #5: -2
[    2.784545] ff000a20.serial: ttyCPM1 at MMIO 0xfff00a20 (irq = 39, base_baud = 8250000) is a CPM UART

Use devm_gpiod_get_index_optional() instead.

At the same time, handle the error case and properly exit with an error.

---
 drivers/tty/serial/cpm_uart/cpm_uart_core.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/tty/serial/cpm_uart/cpm_uart_core.c +8 -1
@@ -1215,7 +1215,12 @@ static int cpm_uart_init_port(struct dev
 
 		pinfo->gpios[i] = NULL;
 
-		gpiod = devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
+		gpiod = devm_gpiod_get_index_optional(dev, NULL, i, GPIOD_ASIS);
+
+		if (IS_ERR(gpiod)) {
+			ret = PTR_ERR(gpiod);
+			goto out_irq;
+		}
 
 		if (gpiod) {
 			if (i == GPIO_RTS || i == GPIO_DTR)
@@ -1237,6 +1242,8 @@ 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:
author maintainer
#175 lore raw

PATCH 173/244 virtio: virtio_console: add missing MODULE_DEVICE_TABLE() for rproc serial

In reply to Greg Kroah-Hartman

From: Alexander Lobakin <[email protected]>

commit 897c44f0bae574c5fb318c759b060bebf9dd6013 upstream.

rproc_serial_id_table lacks an exposure to module devicetable, so when remoteproc firmware requests VIRTIO_ID_RPROC_SERIAL, no uevent is generated and no module autoloading occurs.
Add missing MODULE_DEVICE_TABLE() annotation and move the existing one for VIRTIO_ID_CONSOLE right to the table itself.

---
 drivers/char/virtio_console.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/char/virtio_console.c +2 -1
@@ -2116,6 +2116,7 @@ static struct virtio_device_id id_table[
 	{ VIRTIO_ID_CONSOLE, VIRTIO_DEV_ANY_ID },
 	{ 0 },
 };
+MODULE_DEVICE_TABLE(virtio, id_table);
 
 static unsigned int features[] = {
 	VIRTIO_CONSOLE_F_SIZE,
@@ -2128,6 +2129,7 @@ static struct virtio_device_id rproc_ser
 #endif
 	{ 0 },
 };
+MODULE_DEVICE_TABLE(virtio, rproc_serial_id_table);
 
 static unsigned int rproc_serial_features[] = {
 };
@@ -2280,6 +2282,5 @@ static void __exit fini(void)
 module_init(init);
 module_exit(fini);
 
-MODULE_DEVICE_TABLE(virtio, id_table);
 MODULE_DESCRIPTION("Virtio console driver");
 MODULE_LICENSE("GPL");
author maintainer
#176 lore raw

PATCH 174/244 serial: sh-sci: Initialize spinlock for uart console

In reply to Greg Kroah-Hartman

From: Lad Prabhakar <[email protected]>

commit f38278e9b810b06aff2981d505267be984423ba3 upstream.

serial core expects the spinlock to be initialized by the controller driver for serial console, this patch makes sure the spinlock is initialized, fixing the below issue:

[    0.865928] BUG: spinlock bad magic on CPU#0, swapper/0/1
[    0.865945]  lock: sci_ports+0x0/0x4c80, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[    0.865955] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc1+ #112
[    0.865961] Hardware name: HopeRun HiHope RZ/G2H with sub board (DT)
[    0.865968] Call trace:
[    0.865979]  dump_backtrace+0x0/0x1d8
[    0.865985]  show_stack+0x14/0x20
[    0.865996]  dump_stack+0xe8/0x130
[    0.866006]  spin_dump+0x6c/0x88
[    0.866012]  do_raw_spin_lock+0xb0/0xf8
[    0.866023]  _raw_spin_lock_irqsave+0x80/0xa0
[    0.866032]  uart_add_one_port+0x3a4/0x4e0
[    0.866039]  sci_probe+0x504/0x7c8
[    0.866048]  platform_drv_probe+0x50/0xa0
[    0.866059]  really_probe+0xdc/0x330
[    0.866066]  driver_probe_device+0x58/0xb8
[    0.866072]  device_driver_attach+0x6c/0x90
[    0.866078]  __driver_attach+0x88/0xd0
[    0.866085]  bus_for_each_dev+0x74/0xc8
[    0.866091]  driver_attach+0x20/0x28
[    0.866098]  bus_add_driver+0x14c/0x1f8
[    0.866104]  driver_register+0x60/0x110
[    0.866109]  __platform_driver_register+0x40/0x48
[    0.866119]  sci_init+0x2c/0x34
[    0.866127]  do_one_initcall+0x88/0x428
[    0.866137]  kernel_init_freeable+0x2c0/0x328
[    0.866143]  kernel_init+0x10/0x108
[    0.866150]  ret_from_fork+0x10/0x18
---
 drivers/tty/serial/sh-sci.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/tty/serial/sh-sci.c +3 -0
@@ -3301,6 +3301,9 @@ static int sci_probe_single(struct platf
 		sciport->port.flags |= UPF_HARD_FLOW;
 	}
 
+	if (sci_uart_driver.cons->index == sciport->port.line)
+		spin_lock_init(&sciport->port.lock);
+
 	ret = uart_add_one_port(&sci_uart_driver, &sciport->port);
 	if (ret) {
 		sci_cleanup_single(sciport);
author maintainer
#177 lore raw

PATCH 175/244 serial: mxs-auart: add missed iounmap() in probe failure and remove

In reply to Greg Kroah-Hartman

From: Chuhong Yuan <[email protected]>

commit d8edf8eb5f6e921fe6389f96d2cd05862730a6ff upstream.

This driver calls ioremap() in probe, but it misses calling iounmap() in probe's error handler and remove.
Add the missed calls to fix it.

Fixes 47d37d6f94cc ("serial: Add auart driver for i.MX23/28")
Cc stable <[email protected]>
---
 drivers/tty/serial/mxs-auart.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/tty/serial/mxs-auart.c +8 -4
@@ -1698,21 +1698,21 @@ static int mxs_auart_probe(struct platfo
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		ret = irq;
-		goto out_disable_clks;
+		goto out_iounmap;
 	}
 
 	s->port.irq = irq;
 	ret = devm_request_irq(&pdev->dev, irq, mxs_auart_irq_handle, 0,
 			       dev_name(&pdev->dev), s);
 	if (ret)
-		goto out_disable_clks;
+		goto out_iounmap;
 
 	platform_set_drvdata(pdev, s);
 
 	ret = mxs_auart_init_gpios(s, &pdev->dev);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to initialize GPIOs.\n");
-		goto out_disable_clks;
+		goto out_iounmap;
 	}
 
 	/*
@@ -1720,7 +1720,7 @@ static int mxs_auart_probe(struct platfo
 	 */
 	ret = mxs_auart_request_gpio_irq(s);
 	if (ret)
-		goto out_disable_clks;
+		goto out_iounmap;
 
 	auart_port[s->port.line] = s;
 
@@ -1746,6 +1746,9 @@ out_free_qpio_irq:
 	mxs_auart_free_gpio_irq(s);
 	auart_port[pdev->id] = NULL;
 
+out_iounmap:
+	iounmap(s->port.membase);
+
 out_disable_clks:
 	if (is_asm9260_auart(s)) {
 		clk_disable_unprepare(s->clk);
@@ -1761,6 +1764,7 @@ static int mxs_auart_remove(struct platf
 	uart_remove_one_port(&auart_driver, &s->port);
 	auart_port[pdev->id] = NULL;
 	mxs_auart_free_gpio_irq(s);
+	iounmap(s->port.membase);
 	if (is_asm9260_auart(s)) {
 		clk_disable_unprepare(s->clk);
 		clk_disable_unprepare(s->clk_ahb);
author maintainer
#178 lore raw

PATCH 176/244 Revert "serial: core: Refactor uart_unlock_and_check_sysrq()"

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

commit 10652a9e9fe3fbcaca090f99cd3060ac3fee2913 upstream.

This reverts commit da9a5aa3402db0ff3b57216d8dbf2478e1046cae.

In order to ease backporting a fix for a sysrq regression, revert this rewrite which was since added on top.

The other sysrq helpers now bail out early when sysrq is not enabled; it's better to keep that pattern here as well.

Note that the __releases() attribute won't be needed after the follow-on fix either.

Fixes da9a5aa3402d ("serial: core: Refactor uart_unlock_and_check_sysrq()")
Cc stable <[email protected]>
---
 drivers/tty/serial/serial_core.c |   23 +++++++++++++----------
 include/linux/serial_core.h      |    3 ++-
 2 files changed, 15 insertions(+), 11 deletions(-)
drivers/tty/serial/serial_core.c +13 -10
@@ -3251,19 +3251,22 @@ int uart_prepare_sysrq_char(struct uart_
 }
 EXPORT_SYMBOL_GPL(uart_prepare_sysrq_char);
 
-void uart_unlock_and_check_sysrq(struct uart_port *port, unsigned long flags)
-__releases(&port->lock)
+void uart_unlock_and_check_sysrq(struct uart_port *port, unsigned long irqflags)
 {
-	if (port->has_sysrq) {
-		int sysrq_ch = port->sysrq_ch;
+	int sysrq_ch;
 
-		port->sysrq_ch = 0;
-		spin_unlock_irqrestore(&port->lock, flags);
-		if (sysrq_ch)
-			handle_sysrq(sysrq_ch);
-	} else {
-		spin_unlock_irqrestore(&port->lock, flags);
+	if (!port->has_sysrq) {
+		spin_unlock_irqrestore(&port->lock, irqflags);
+		return;
 	}
+
+	sysrq_ch = port->sysrq_ch;
+	port->sysrq_ch = 0;
+
+	spin_unlock_irqrestore(&port->lock, irqflags);
+
+	if (sysrq_ch)
+		handle_sysrq(sysrq_ch);
 }
 EXPORT_SYMBOL_GPL(uart_unlock_and_check_sysrq);
 
include/linux/serial_core.h +2 -1
@@ -462,7 +462,8 @@ extern void uart_insert_char(struct uart
 
 extern int uart_handle_sysrq_char(struct uart_port *port, unsigned int ch);
 extern int uart_prepare_sysrq_char(struct uart_port *port, unsigned int ch);
-extern void uart_unlock_and_check_sysrq(struct uart_port *port, unsigned long flags);
+extern void uart_unlock_and_check_sysrq(struct uart_port *port,
+					unsigned long irqflags);
 extern int uart_handle_break(struct uart_port *port);
 
 /*
author maintainer
#179 lore raw

PATCH 177/244 serial: core: fix sysrq overhead regression

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

commit 08d5470308ac3598e7709d08b8979ce6e9de8da2 upstream.

Commit 8e20fc391711 ("serial_core: Move sysrq functions from header file") converted the inline sysrq helpers to exported functions which are now called for every received character, interrupt and break signal also on systems without CONFIG_MAGIC_SYSRQ_SERIAL instead of being optimised away by the compiler.

Inlining these helpers again also avoids the function call overhead when CONFIG_MAGIC_SYSRQ_SERIAL is enabled (e.g. when the port is not used as a console).

Fixes 8e20fc391711 ("serial_core: Move sysrq functions from header file")
Cc Dmitry Safonov <[email protected]>
Cc stable <[email protected]>
---
 drivers/tty/serial/serial_core.c |   99 -------------------------------------
 include/linux/serial_core.h      |  103 +++++++++++++++++++++++++++++++++++++--
 2 files changed, 100 insertions(+), 102 deletions(-)
drivers/tty/serial/serial_core.c +2 -97
@@ -41,8 +41,6 @@ static struct lock_class_key port_lock_k
 
 #define HIGH_BITS_OFFSET	((sizeof(long)-sizeof(int))*8)
 
-#define SYSRQ_TIMEOUT	(HZ * 5)
-
 static void uart_change_speed(struct tty_struct *tty, struct uart_state *state,
 					struct ktermios *old_termios);
 static void uart_wait_until_sent(struct tty_struct *tty, int timeout);
@@ -3175,7 +3173,7 @@ static DECLARE_WORK(sysrq_enable_work, u
  *	Returns false if @ch is out of enabling sequence and should be
  *	handled some other way, true if @ch was consumed.
  */
-static bool uart_try_toggle_sysrq(struct uart_port *port, unsigned int ch)
+bool uart_try_toggle_sysrq(struct uart_port *port, unsigned int ch)
 {
 	int sysrq_toggle_seq_len = strlen(sysrq_toggle_seq);
 
@@ -3198,102 +3196,9 @@ static bool uart_try_toggle_sysrq(struct
 	port->sysrq = 0;
 	return true;
 }
-#else
-static inline bool uart_try_toggle_sysrq(struct uart_port *port, unsigned int ch)
-{
-	return false;
-}
+EXPORT_SYMBOL_GPL(uart_try_toggle_sysrq);
 #endif
 
-int uart_handle_sysrq_char(struct uart_port *port, unsigned int ch)
-{
-	if (!IS_ENABLED(CONFIG_MAGIC_SYSRQ_SERIAL))
-		return 0;
-
-	if (!port->has_sysrq || !port->sysrq)
-		return 0;
-
-	if (ch && time_before(jiffies, port->sysrq)) {
-		if (sysrq_mask()) {
-			handle_sysrq(ch);
-			port->sysrq = 0;
-			return 1;
-		}
-		if (uart_try_toggle_sysrq(port, ch))
-			return 1;
-	}
-	port->sysrq = 0;
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(uart_handle_sysrq_char);
-
-int uart_prepare_sysrq_char(struct uart_port *port, unsigned int ch)
-{
-	if (!IS_ENABLED(CONFIG_MAGIC_SYSRQ_SERIAL))
-		return 0;
-
-	if (!port->has_sysrq || !port->sysrq)
-		return 0;
-
-	if (ch && time_before(jiffies, port->sysrq)) {
-		if (sysrq_mask()) {
-			port->sysrq_ch = ch;
-			port->sysrq = 0;
-			return 1;
-		}
-		if (uart_try_toggle_sysrq(port, ch))
-			return 1;
-	}
-	port->sysrq = 0;
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(uart_prepare_sysrq_char);
-
-void uart_unlock_and_check_sysrq(struct uart_port *port, unsigned long irqflags)
-{
-	int sysrq_ch;
-
-	if (!port->has_sysrq) {
-		spin_unlock_irqrestore(&port->lock, irqflags);
-		return;
-	}
-
-	sysrq_ch = port->sysrq_ch;
-	port->sysrq_ch = 0;
-
-	spin_unlock_irqrestore(&port->lock, irqflags);
-
-	if (sysrq_ch)
-		handle_sysrq(sysrq_ch);
-}
-EXPORT_SYMBOL_GPL(uart_unlock_and_check_sysrq);
-
-/*
- * We do the SysRQ and SAK checking like this...
- */
-int uart_handle_break(struct uart_port *port)
-{
-	struct uart_state *state = port->state;
-
-	if (port->handle_break)
-		port->handle_break(port);
-
-	if (port->has_sysrq && uart_console(port)) {
-		if (!port->sysrq) {
-			port->sysrq = jiffies + SYSRQ_TIMEOUT;
-			return 1;
-		}
-		port->sysrq = 0;
-	}
-
-	if (port->flags & UPF_SAK)
-		do_SAK(state->port.tty);
-	return 0;
-}
-EXPORT_SYMBOL_GPL(uart_handle_break);
-
 EXPORT_SYMBOL(uart_write_wakeup);
 EXPORT_SYMBOL(uart_register_driver);
 EXPORT_SYMBOL(uart_unregister_driver);
include/linux/serial_core.h +98 -5

109 lines not on this page · raw message

author maintainer
#180 lore raw

PATCH 178/244 ovl: fix regression with re-formatted lower squashfs

In reply to Greg Kroah-Hartman

From: Amir Goldstein <[email protected]>

commit a888db310195400f050b89c47673f0f8babfbb41 upstream.

Commit 9df085f3c9a2 ("ovl: relax requirement for non null uuid of lower fs") relaxed the requirement for non null uuid with single lower layer to allow enabling index and nfs_export features with single lower squashfs.

Fabian reported a regression in a setup when overlay re-uses an existing upper layer and re-formats the lower squashfs image. Because squashfs has no uuid, the origin xattr in upper layer are decoded from the new lower layer where they may resolve to a wrong origin file and user may get an ESTALE or EIO error on lookup.

To avoid the reported regression while still allowing the new features with single lower squashfs, do not allow decoding origin with lower null uuid unless user opted-in to one of the new features that require following the lower inode of non-dir upper (index, xino, metacopy).

---
 fs/overlayfs/super.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)
fs/overlayfs/super.c +12 -0
@@ -1331,6 +1331,18 @@ static bool ovl_lower_uuid_ok(struct ovl
 	if (!ofs->config.nfs_export && !ofs->upper_mnt)
 		return true;
 
+	/*
+	 * We allow using single lower with null uuid for index and nfs_export
+	 * for example to support those features with single lower squashfs.
+	 * To avoid regressions in setups of overlay with re-formatted lower
+	 * squashfs, do not allow decoding origin with lower null uuid unless
+	 * user opted-in to one of the new features that require following the
+	 * lower inode of non-dir upper.
+	 */
+	if (!ofs->config.index && !ofs->config.metacopy && !ofs->config.xino &&
+	    uuid_is_null(uuid))
+		return false;
+
 	for (i = 0; i < ofs->numfs; i++) {
 		/*
 		 * We use uuid to associate an overlay lower file handle with a
author maintainer
#181 lore raw

PATCH 179/244 ovl: inode reference leak in ovl_is_inuse true case.

In reply to Greg Kroah-Hartman

From: youngjun <[email protected]>

commit 24f14009b8f1754ec2ae4c168940c01259b0f88a upstream.

When "ovl_is_inuse" true case, trap inode reference not put. plus adding the comment explaining sequence of ovl_is_inuse after ovl_setup_trap.

Fixes 0be0bfd2de9d ("ovl: fix regression caused by overlapping layers detection")
Cc <[email protected]> # v4.19+
---
 fs/overlayfs/super.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
fs/overlayfs/super.c +10 -1
@@ -1450,14 +1450,23 @@ static int ovl_get_layers(struct super_b
 		if (err < 0)
 			goto out;
 
+		/*
+		 * Check if lower root conflicts with this overlay layers before
+		 * checking if it is in-use as upperdir/workdir of "another"
+		 * mount, because we do not bother to check in ovl_is_inuse() if
+		 * the upperdir/workdir is in fact in-use by our
+		 * upperdir/workdir.
+		 */
 		err = ovl_setup_trap(sb, stack[i].dentry, &trap, "lowerdir");
 		if (err)
 			goto out;
 
 		if (ovl_is_inuse(stack[i].dentry)) {
 			err = ovl_report_in_use(ofs, "lowerdir");
-			if (err)
+			if (err) {
+				iput(trap);
 				goto out;
+			}
 		}
 
 		mnt = clone_private_mount(&stack[i]);
author maintainer
#182 lore raw

PATCH 180/244 ovl: relax WARN_ON() when decoding lower directory file handle

In reply to Greg Kroah-Hartman

From: Amir Goldstein <[email protected]>

commit 124c2de2c0aee96271e4ddab190083d8aa7aa71a upstream.

Decoding a lower directory file handle to overlay path with cold inode/dentry cache may go as follows:

1. Decode real lower file handle to lower dir path
2. Check if lower dir is indexed (was copied up)
3. If indexed, get the upper dir path from index
4. Lookup upper dir path in overlay
5. If overlay path found, verify that overlay lower is the lower dir from step 1

On failure to verify step 5 above, user will get an ESTALE error and a WARN_ON will be printed.

A mismatch in step 5 could be a result of lower directory that was renamed while overlay was offline, after that lower directory has been copied up and indexed.

This is a scripted reproducer based on xfstest overlay/052:

# Create lower subdir
create_dirs
create_test_files $lower/lowertestdir/subdir
mount_dirs
# Copy up lower dir and encode lower subdir file handle touch $SCRATCH_MNT/lowertestdir
test_file_handles $SCRATCH_MNT/lowertestdir/subdir -p -o $tmp.fhandle # Rename lower dir offline
unmount_dirs
mv $lower/lowertestdir $lower/lowertestdir.new/
mount_dirs
# Attempt to decode lower subdir file handle test_file_handles $SCRATCH_MNT -p -i $tmp.fhandle

Since this WARN_ON() can be triggered by user we need to relax it.

Fixes 4b91c30a5a19 ("ovl: lookup connected ancestor of dir in inode cache")
Cc <[email protected]> # v4.16+
---
 fs/overlayfs/export.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/overlayfs/export.c +1 -1
@@ -478,7 +478,7 @@ static struct dentry *ovl_lookup_real_in
 	if (IS_ERR_OR_NULL(this))
 		return this;
 
-	if (WARN_ON(ovl_dentry_real_at(this, layer->idx) != real)) {
+	if (ovl_dentry_real_at(this, layer->idx) != real) {
 		dput(this);
 		this = ERR_PTR(-EIO);
 	}
author maintainer
#183 lore raw

PATCH 181/244 ovl: fix unneeded call to ovl_change_flags()

In reply to Greg Kroah-Hartman

From: Amir Goldstein <[email protected]>

commit 81a33c1ee941c3bb9ffc6bac8f676be13351344e upstream.

The check if user has changed the overlay file was wrong, causing unneeded call to ovl_change_flags() including taking f_lock on every file access.

Fixes d989903058a8 ("ovl: do not generate duplicate fsnotify events for "fake" path")
Cc <[email protected]> # v4.19+
---
 fs/overlayfs/file.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
fs/overlayfs/file.c +6 -4
@@ -32,13 +32,16 @@ static char ovl_whatisit(struct inode *i
 		return 'm';
 }
 
+/* No atime modificaton nor notify on underlying */
+#define OVL_OPEN_FLAGS (O_NOATIME | FMODE_NONOTIFY)
+
 static struct file *ovl_open_realfile(const struct file *file,
 				      struct inode *realinode)
 {
 	struct inode *inode = file_inode(file);
 	struct file *realfile;
 	const struct cred *old_cred;
-	int flags = file->f_flags | O_NOATIME | FMODE_NONOTIFY;
+	int flags = file->f_flags | OVL_OPEN_FLAGS;
 
 	old_cred = ovl_override_creds(inode->i_sb);
 	realfile = open_with_fake_path(&file->f_path, flags, realinode,
@@ -59,8 +62,7 @@ static int ovl_change_flags(struct file
 	struct inode *inode = file_inode(file);
 	int err;
 
-	/* No atime modificaton on underlying */
-	flags |= O_NOATIME | FMODE_NONOTIFY;
+	flags |= OVL_OPEN_FLAGS;
 
 	/* If some flag changed that cannot be changed then something's amiss */
 	if (WARN_ON((file->f_flags ^ flags) & ~OVL_SETFL_MASK))
@@ -113,7 +115,7 @@ static int ovl_real_fdget_meta(const str
 	}
 
 	/* Did the flags change since open? */
-	if (unlikely((file->f_flags ^ real->file->f_flags) & ~O_NOATIME))
+	if (unlikely((file->f_flags ^ real->file->f_flags) & ~OVL_OPEN_FLAGS))
 		return ovl_change_flags(real->file, file->f_flags);
 
 	return 0;
author maintainer
#184 lore raw

PATCH 182/244 fuse: ignore data argument of mount(..., MS_REMOUNT)

In reply to Greg Kroah-Hartman

From: Miklos Szeredi <[email protected]>

commit e8b20a474cf2c42698d1942f939ff2128819f151 upstream.

The command

mount -o remount -o unknownoption /mnt/fuse

succeeds on kernel versions prior to v5.4 and fails on kernel version at or after. This is because fuse_parse_param() rejects any unrecognised options in case of FS_CONTEXT_FOR_RECONFIGURE, just as for FS_CONTEXT_FOR_MOUNT.

This causes a regression in case the fuse filesystem is in fstab, since remount sends all options found there to the kernel; even ones that are meant for the initial mount and are consumed by the userspace fuse server.

Fix this by ignoring mount options, just as fuse_remount_fs() did prior to the conversion to the new API.

Fixes c30da2e981a7 ("fuse: convert to use the new mount API")
Cc <[email protected]> # v5.4
---
 fs/fuse/inode.c |    7 +++++++
 1 file changed, 7 insertions(+)
fs/fuse/inode.c +7 -0
@@ -468,6 +468,13 @@ static int fuse_parse_param(struct fs_co
 	struct fuse_fs_context *ctx = fc->fs_private;
 	int opt;
 
+	/*
+	 * Ignore options coming from mount(MS_REMOUNT) for backward
+	 * compatibility.
+	 */
+	if (fc->purpose == FS_CONTEXT_FOR_RECONFIGURE)
+		return 0;
+
 	opt = fs_parse(fc, fuse_fs_parameters, param, &result);
 	if (opt < 0)
 		return opt;
author maintainer
#185 lore raw

PATCH 183/244 fuse: use ->reconfigure() instead of ->remount_fs()

In reply to Greg Kroah-Hartman

From: Miklos Szeredi <[email protected]>

commit 0189a2d367f49729622fdafaef5da73161591859 upstream.

s_op->remount_fs() is only called from legacy_reconfigure(), which is not used after being converted to the new API.

Convert to using ->reconfigure(). This restores the previous behavior of syncing the filesystem and rejecting MS_MANDLOCK on remount.

Fixes c30da2e981a7 ("fuse: convert to use the new mount API")
Cc <[email protected]> # v5.4
---
 fs/fuse/inode.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
fs/fuse/inode.c +5 -3
@@ -121,10 +121,12 @@ static void fuse_evict_inode(struct inod
 	}
 }
 
-static int fuse_remount_fs(struct super_block *sb, int *flags, char *data)
+static int fuse_reconfigure(struct fs_context *fc)
 {
+	struct super_block *sb = fc->root->d_sb;
+
 	sync_filesystem(sb);
-	if (*flags & SB_MANDLOCK)
+	if (fc->sb_flags & SB_MANDLOCK)
 		return -EINVAL;
 
 	return 0;
@@ -817,7 +819,6 @@ static const struct super_operations fus
 	.evict_inode	= fuse_evict_inode,
 	.write_inode	= fuse_write_inode,
 	.drop_inode	= generic_delete_inode,
-	.remount_fs	= fuse_remount_fs,
 	.put_super	= fuse_put_super,
 	.umount_begin	= fuse_umount_begin,
 	.statfs		= fuse_statfs,
@@ -1291,6 +1292,7 @@ static int fuse_get_tree(struct fs_conte
 static const struct fs_context_operations fuse_context_ops = {
 	.free		= fuse_free_fc,
 	.parse_param	= fuse_parse_param,
+	.reconfigure	= fuse_reconfigure,
 	.get_tree	= fuse_get_tree,
 };
 
author maintainer
#186 lore raw

PATCH 184/244 fuse: Fix parameter for FS_IOC_{GET,SET}FLAGS

In reply to Greg Kroah-Hartman

From: Chirantan Ekbote <[email protected]>

commit 31070f6ccec09f3bd4f1e28cd1e592fa4f3ba0b6 upstream.

The ioctl encoding for this parameter is a long but the documentation says it should be an int and the kernel drivers expect it to be an int. If the fuse driver treats this as a long it might end up scribbling over the stack of a userspace process that only allocated enough space for an int.

This was previously discussed in [1] and a patch for fuse was proposed in [2]. From what I can tell the patch in [2] was nacked in favor of adding new, "fixed" ioctls and using those from userspace. However there is still no "fixed" version of these ioctls and the fact is that it's sometimes infeasible to change all userspace to use the new one.

Handling the ioctls specially in the fuse driver seems like the most pragmatic way for fuse servers to support them without causing crashes in userspace applications that call them.

[1]: https://lore.kernel.org/linux-fsdevel/[email protected]/T/
[2]: https://sourceforge.net/p/fuse/mailman/message/31771759/

Fixes 59efec7b9039 ("fuse: implement ioctl support")
---
 fs/fuse/file.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)
fs/fuse/file.c +11 -1
@@ -18,6 +18,7 @@
 #include <linux/swap.h>
 #include <linux/falloc.h>
 #include <linux/uio.h>
+#include <linux/fs.h>
 
 static struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags,
 				      struct fuse_page_desc **desc)
@@ -2758,7 +2759,16 @@ long fuse_do_ioctl(struct file *file, un
 		struct iovec *iov = iov_page;
 
 		iov->iov_base = (void __user *)arg;
-		iov->iov_len = _IOC_SIZE(cmd);
+
+		switch (cmd) {
+		case FS_IOC_GETFLAGS:
+		case FS_IOC_SETFLAGS:
+			iov->iov_len = sizeof(int);
+			break;
+		default:
+			iov->iov_len = _IOC_SIZE(cmd);
+			break;
+		}
 
 		if (_IOC_DIR(cmd) & _IOC_WRITE) {
 			in_iov = iov;
author maintainer
#187 lore raw

PATCH 185/244 Revert "zram: convert remaining CLASS_ATTR() to CLASS_ATTR_RO()"

In reply to Greg Kroah-Hartman

From: Wade Mealing <[email protected]>

commit 853eab68afc80f59f36bbdeb715e5c88c501e680 upstream.

Turns out that the permissions for 0400 really are what we want here, otherwise any user can read from this file.

[fixed formatting, added changelog, and made attribute static - gregkh]

---
 drivers/block/zram/zram_drv.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/block/zram/zram_drv.c +2 -1
@@ -2025,7 +2025,8 @@ static ssize_t hot_add_show(struct class
 		return ret;
 	return scnprintf(buf, PAGE_SIZE, "%d\n", ret);
 }
-static CLASS_ATTR_RO(hot_add);
+static struct class_attribute class_attr_hot_add =
+	__ATTR(hot_add, 0400, hot_add_show, NULL);
 
 static ssize_t hot_remove_store(struct class *class,
 			struct class_attribute *attr,
author maintainer
#188 lore raw

PATCH 186/244 mei: bus: dont clean driver pointer

In reply to Greg Kroah-Hartman

From: Alexander Usyskin <[email protected]>

commit e852c2c251ed9c23ae6e3efebc5ec49adb504207 upstream.

It's not needed to set driver to NULL in mei_cl_device_remove() which is bus_type remove() handler as this is done anyway in __device_release_driver().

Actually this is causing an endless loop in driver_detach() on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module. The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty. as the check is always true in __device_release_driver()

	if (dev->driver != drv)
		return;

The non upstream patch is causing this behavior, titled:
'vfio -- release device lock before userspace requests'

Nevertheless the fix is correct also for the upstream.

---
 drivers/misc/mei/bus.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/misc/mei/bus.c +1 -2
@@ -745,9 +745,8 @@ static int mei_cl_device_remove(struct d
 
 	mei_cl_bus_module_put(cldev);
 	module_put(THIS_MODULE);
-	dev->driver = NULL;
-	return ret;
 
+	return ret;
 }
 
 static ssize_t name_show(struct device *dev, struct device_attribute *a,
author maintainer
#189 lore raw

PATCH 187/244 Revert "Input: elants_i2c - report resolution information for touch major"

In reply to Greg Kroah-Hartman

From: Dmitry Torokhov <[email protected]>

commit 93b9de223c0135db495c25334e66cb669bef13e2 upstream.

This reverts commit 061706716384f1633d3d5090b22a99f33f1fcf2f - it turns out that the resolution of 1 unit per mm was not correct for a number of touch screens, causing touch sizes to be reported as way too large. See https://crbug.com/1085648

---
 drivers/input/touchscreen/elants_i2c.c |    1 -
 1 file changed, 1 deletion(-)
drivers/input/touchscreen/elants_i2c.c +0 -1
@@ -1318,7 +1318,6 @@ static int elants_i2c_probe(struct i2c_c
 			     0, MT_TOOL_PALM, 0, 0);
 	input_abs_set_res(ts->input, ABS_MT_POSITION_X, ts->x_res);
 	input_abs_set_res(ts->input, ABS_MT_POSITION_Y, ts->y_res);
-	input_abs_set_res(ts->input, ABS_MT_TOUCH_MAJOR, 1);
 
 	error = input_register_device(ts->input);
 	if (error) {
author maintainer
#190 lore raw

PATCH 188/244 Input: i8042 - add Lenovo XiaoXin Air 12 to i8042 nomux list

In reply to Greg Kroah-Hartman

From: David Pedersen <[email protected]>

commit 17d51429da722cd8fc77a365a112f008abf4f8b3 upstream.

This fixes two finger trackpad scroll on the Lenovo XiaoXin Air 12. Without nomux, the trackpad behaves as if only one finger is present and moves the cursor when trying to scroll.

---
 drivers/input/serio/i8042-x86ia64io.h |    7 +++++++
 1 file changed, 7 insertions(+)
drivers/input/serio/i8042-x86ia64io.h +7 -0
@@ -426,6 +426,13 @@ static const struct dmi_system_id __init
 		},
 	},
 	{
+		/* Lenovo XiaoXin Air 12 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "80UN"),
+		},
+	},
+	{
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
 			DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 1360"),
author maintainer
#191 lore raw

PATCH 189/244 Input: elan_i2c - add more hardware ID for Lenovo laptops

In reply to Greg Kroah-Hartman

From: Dave Wang <[email protected]>

commit a50ca29523b18baea548bdf5df9b4b923c2bb4f6 upstream.

This adds more hardware IDs for Elan touchpads found in various Lenovo laptops.

---
 include/linux/input/elan-i2c-ids.h |    7 +++++++
 1 file changed, 7 insertions(+)
include/linux/input/elan-i2c-ids.h +7 -0
@@ -67,8 +67,15 @@ static const struct acpi_device_id elan_
 	{ "ELAN062B", 0 },
 	{ "ELAN062C", 0 },
 	{ "ELAN062D", 0 },
+	{ "ELAN062E", 0 }, /* Lenovo V340 Whiskey Lake U */
+	{ "ELAN062F", 0 }, /* Lenovo V340 Comet Lake U */
 	{ "ELAN0631", 0 },
 	{ "ELAN0632", 0 },
+	{ "ELAN0633", 0 }, /* Lenovo S145 */
+	{ "ELAN0634", 0 }, /* Lenovo V340 Ice lake */
+	{ "ELAN0635", 0 }, /* Lenovo V1415-IIL */
+	{ "ELAN0636", 0 }, /* Lenovo V1415-Dali */
+	{ "ELAN0637", 0 }, /* Lenovo V1415-IGLR */
 	{ "ELAN1000", 0 },
 	{ }
 };
author maintainer
#192 lore raw

PATCH 190/244 coresight: etmv4: Fix CPU power management setup in probe() function

In reply to Greg Kroah-Hartman

From: Mike Leach <[email protected]>

commit 9b6a3f3633a5cc928b78627764793b60cb62e0f6 upstream.

The current probe() function calls a pair of cpuhp_xxx API functions to setup CPU hotplug handling. The hotplug lock is held for the duration of the two calls and other CPU related code using cpus_read_lock() / cpus_read_unlock() calls.

The problem is that on error states, goto: statements bypass the cpus_read_unlock() call. This code has increased in complexity as the driver has developed.

This patch introduces a pair of helper functions etm4_pm_setup_cpuslocked() and etm4_pm_clear() which correct the issues above and group the PM code a little better.

The two functions etm4_cpu_pm_register() and etm4_cpu_pm_unregister() are dropped as these call cpu_pm_register_notifier() / ..unregister_notifier() dependent on CONFIG_CPU_PM - but this define is used to nop these functions out in the pm headers - so the wrapper functions are superfluous.

Fixes f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states")
Fixes e9f5d63f84fe ("hwtracing/coresight-etm4x: Use cpuhp_setup_state_nocalls_cpuslocked()")
Fixes 58eb457be028 ("hwtracing/coresight-etm4x: Convert to hotplug state machine")
Cc stable <[email protected]>
---
 drivers/hwtracing/coresight/coresight-etm4x.c |   82 ++++++++++++++++----------
 1 file changed, 53 insertions(+), 29 deletions(-)
drivers/hwtracing/coresight/coresight-etm4x.c +53 -29
@@ -1399,18 +1399,57 @@ static struct notifier_block etm4_cpu_pm
 	.notifier_call = etm4_cpu_pm_notify,
 };
 
-static int etm4_cpu_pm_register(void)
+/* Setup PM. Called with cpus locked. Deals with error conditions and counts */
+static int etm4_pm_setup_cpuslocked(void)
 {
-	if (IS_ENABLED(CONFIG_CPU_PM))
-		return cpu_pm_register_notifier(&etm4_cpu_pm_nb);
+	int ret;
 
-	return 0;
+	if (etm4_count++)
+		return 0;
+
+	ret = cpu_pm_register_notifier(&etm4_cpu_pm_nb);
+	if (ret)
+		goto reduce_count;
+
+	ret = cpuhp_setup_state_nocalls_cpuslocked(CPUHP_AP_ARM_CORESIGHT_STARTING,
+						   "arm/coresight4:starting",
+						   etm4_starting_cpu, etm4_dying_cpu);
+
+	if (ret)
+		goto unregister_notifier;
+
+	ret = cpuhp_setup_state_nocalls_cpuslocked(CPUHP_AP_ONLINE_DYN,
+						   "arm/coresight4:online",
+						   etm4_online_cpu, NULL);
+
+	/* HP dyn state ID returned in ret on success */
+	if (ret > 0) {
+		hp_online = ret;
+		return 0;
+	}
+
+	/* failed dyn state - remove others */
+	cpuhp_remove_state_nocalls_cpuslocked(CPUHP_AP_ARM_CORESIGHT_STARTING);
+
+unregister_notifier:
+	cpu_pm_unregister_notifier(&etm4_cpu_pm_nb);
+
+reduce_count:
+	--etm4_count;
+	return ret;
 }
 
-static void etm4_cpu_pm_unregister(void)
+static void etm4_pm_clear(void)
 {
-	if (IS_ENABLED(CONFIG_CPU_PM))
-		cpu_pm_unregister_notifier(&etm4_cpu_pm_nb);
+	if (--etm4_count != 0)
+		return;
+
+	cpu_pm_unregister_notifier(&etm4_cpu_pm_nb);
+	cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
+	if (hp_online) {
+		cpuhp_remove_state_nocalls(hp_online);
+		hp_online = 0;
+	}
 }
 
 static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
@@ -1464,24 +1503,15 @@ static int etm4_probe(struct amba_device
 				etm4_init_arch_data,  drvdata, 1))
 		dev_err(dev, "ETM arch init failed\n");
 
-	if (!etm4_count++) {
-		cpuhp_setup_state_nocalls_cpuslocked(CPUHP_AP_ARM_CORESIGHT_STARTING,
-						     "arm/coresight4:starting",
-						     etm4_starting_cpu, etm4_dying_cpu);
-		ret = cpuhp_setup_state_nocalls_cpuslocked(CPUHP_AP_ONLINE_DYN,
-							   "arm/coresight4:online",
-							   etm4_online_cpu, NULL);
-		if (ret < 0)
-			goto err_arch_supported;
-		hp_online = ret;
+	ret = etm4_pm_setup_cpuslocked();
+	cpus_read_unlock();
 
-		ret = etm4_cpu_pm_register();
-		if (ret)
-			goto err_arch_supported;
+	/* etm4_pm_setup_cpuslocked() does its own cleanup - exit on error */
+	if (ret) {
+		etmdrvdata[drvdata->cpu] = NULL;
+		return ret;
 	}
 
-	cpus_read_unlock();
-
 	if (etm4_arch_supported(drvdata->arch) == false) {
 		ret = -EINVAL;
 		goto err_arch_supported;
@@ -1528,13 +1558,7 @@ static int etm4_probe(struct amba_device
 
 err_arch_supported:
 	etmdrvdata[drvdata->cpu] = NULL;
-	if (--etm4_count == 0) {
-		etm4_cpu_pm_unregister();
-
-		cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
-		if (hp_online)
-			cpuhp_remove_state_nocalls(hp_online);
-	}
+	etm4_pm_clear();
 	return ret;
 }
 
author maintainer
#193 lore raw

PATCH 191/244 uio_pdrv_genirq: Remove warning when irq is not specified

In reply to Greg Kroah-Hartman

From: Esben Haabendal <[email protected]>

commit 324ac45f25e634eca6346953ae531e8da3e0c73d upstream.

Since e3a3c3a20555 ("UIO: fix uio_pdrv_genirq with device tree but no interrupt"), the uio_pdrv_genirq has supported use without interrupt, so the change in 7723f4c5ecdb ("driver core: platform: Add an error message to") added false warnings for those cases.

Fixes 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
---
 drivers/uio/uio_pdrv_genirq.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/uio/uio_pdrv_genirq.c +1 -1
@@ -159,7 +159,7 @@ static int uio_pdrv_genirq_probe(struct
 	priv->pdev = pdev;
 
 	if (!uioinfo->irq) {
-		ret = platform_get_irq(pdev, 0);
+		ret = platform_get_irq_optional(pdev, 0);
 		uioinfo->irq = ret;
 		if (ret == -ENXIO && pdev->dev.of_node)
 			uioinfo->irq = UIO_IRQ_NONE;
author maintainer
#194 lore raw

PATCH 192/244 uio_pdrv_genirq: fix use without device tree and no interrupt

In reply to Greg Kroah-Hartman

From: Esben Haabendal <[email protected]>

commit bf12fdf0ab728ca8e5933aac46dd972c0dd0421e upstream.

While e3a3c3a20555 ("UIO: fix uio_pdrv_genirq with device tree but no interrupt") added support for using uio_pdrv_genirq for devices without interrupt for device tree platforms, the removal of uio_pdrv in 26dac3c49d56 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead") broke the support for non device tree platforms.

This change fixes this, so that uio_pdrv_genirq can be used without interrupt on all platforms.

This still leaves the support that uio_pdrv had for custom interrupt handler lacking, as uio_pdrv_genirq does not handle it (yet).

Fixes 26dac3c49d56 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead")
---
 drivers/uio/uio_pdrv_genirq.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/uio/uio_pdrv_genirq.c +1 -1
@@ -161,7 +161,7 @@ static int uio_pdrv_genirq_probe(struct
 	if (!uioinfo->irq) {
 		ret = platform_get_irq_optional(pdev, 0);
 		uioinfo->irq = ret;
-		if (ret == -ENXIO && pdev->dev.of_node)
+		if (ret == -ENXIO)
 			uioinfo->irq = UIO_IRQ_NONE;
 		else if (ret == -EPROBE_DEFER)
 			return ret;
author maintainer
#195 lore raw

PATCH 193/244 scsi: megaraid_sas: Remove undefined ENABLE_IRQ_POLL macro

In reply to Greg Kroah-Hartman

From: Chandrakanth Patil <[email protected]>

commit 07d3f04550023395bbf34b99ec7e00fc50d9859f upstream.

As the ENABLE_IRQ_POLL macro is undefined, the check for ENABLE_IRQ_POLL macro in ISR will always be false. This leads to irq polling being non-functional.

Remove ENABLE_IRQ_POLL check from ISR.

Fixes a6ffd5bf6819 ("scsi: megaraid_sas: Call disable_irq from process IRQ")
Cc <[email protected]> # v5.3+
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c |    2 --
 1 file changed, 2 deletions(-)
drivers/scsi/megaraid/megaraid_sas_fusion.c +0 -2
@@ -3797,10 +3797,8 @@ static irqreturn_t megasas_isr_fusion(in
 	if (instance->mask_interrupts)
 		return IRQ_NONE;
 
-#if defined(ENABLE_IRQ_POLL)
 	if (irq_context->irq_poll_scheduled)
 		return IRQ_HANDLED;
-#endif
 
 	if (!instance->msix_vectors) {
 		mfiStatus = instance->instancet->clear_intr(instance);
author maintainer
#196 lore raw

PATCH 194/244 timer: Prevent base->clk from moving backward

In reply to Greg Kroah-Hartman

From: Frederic Weisbecker <[email protected]>

commit 30c66fc30ee7a98c4f3adf5fb7e213b61884474f upstream.

When a timer is enqueued with a negative delta (ie: expiry is below base->clk), it gets added to the wheel as expiring now (base->clk).

Yet the value that gets stored in base->next_expiry, while calling trigger_dyntick_cpu(), is the initial timer->expires value. The resulting state becomes:

	base->next_expiry < base->clk

On the next timer enqueue, forward_timer_base() may accidentally rewind base->clk. As a possible outcome, timers may expire way too early, the worst case being that the highest wheel levels get spuriously processed again.

To prevent from that, make sure that base->next_expiry doesn't get below base->clk.

---
 kernel/time/timer.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)
kernel/time/timer.c +14 -3
@@ -585,7 +585,15 @@ trigger_dyntick_cpu(struct timer_base *b
 	 * Set the next expiry time and kick the CPU so it can reevaluate the
 	 * wheel:
 	 */
-	base->next_expiry = timer->expires;
+	if (time_before(timer->expires, base->clk)) {
+		/*
+		 * Prevent from forward_timer_base() moving the base->clk
+		 * backward
+		 */
+		base->next_expiry = base->clk;
+	} else {
+		base->next_expiry = timer->expires;
+	}
 	wake_up_nohz_cpu(base->cpu);
 }
 
@@ -897,10 +905,13 @@ static inline void forward_timer_base(st
 	 * If the next expiry value is > jiffies, then we fast forward to
 	 * jiffies otherwise we forward to the next expiry value.
 	 */
-	if (time_after(base->next_expiry, jnow))
+	if (time_after(base->next_expiry, jnow)) {
 		base->clk = jnow;
-	else
+	} else {
+		if (WARN_ON_ONCE(time_before(base->next_expiry, base->clk)))
+			return;
 		base->clk = base->next_expiry;
+	}
 #endif
 }
 
author maintainer
#197 lore raw

PATCH 195/244 timer: Fix wheel index calculation on last level

In reply to Greg Kroah-Hartman

From: Frederic Weisbecker <[email protected]>

commit e2a71bdea81690b6ef11f4368261ec6f5b6891aa upstream.

When an expiration delta falls into the last level of the wheel, that delta has be compared against the maximum possible delay and reduced to fit in if necessary.

However instead of comparing the delta against the maximum, the code compares the actual expiry against the maximum. Then instead of fixing the delta to fit in, it sets the maximum delta as the expiry value.

This can result in various undesired outcomes, the worst possible one being a timer expiring 15 days ahead to fire immediately.

---
 kernel/time/timer.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/time/timer.c +2 -2
@@ -522,8 +522,8 @@ static int calc_wheel_index(unsigned lon
 		 * Force expire obscene large timeouts to expire at the
 		 * capacity limit of the wheel.
 		 */
-		if (expires >= WHEEL_TIMEOUT_CUTOFF)
-			expires = WHEEL_TIMEOUT_MAX;
+		if (delta >= WHEEL_TIMEOUT_CUTOFF)
+			expires = clk + WHEEL_TIMEOUT_MAX;
 
 		idx = calc_index(expires, LVL_DEPTH - 1);
 	}
author maintainer
#198 lore raw

PATCH 196/244 riscv: use 16KB kernel stack on 64-bit

In reply to Greg Kroah-Hartman

From: Andreas Schwab <[email protected]>

commit 0cac21b02ba5f3095fd2dcc77c26a25a0b2432ed upstream.

With the current 8KB stack size there are frequent overflows in a 64-bit configuration. We may split IRQ stacks off in the future, but this fixes a number of issues right now.

[Palmer: mention irqstack in the commit text]
Fixes 7db91e57a0ac ("RISC-V: Task implementation")
---
 arch/riscv/include/asm/thread_info.h |    4 ++++
 1 file changed, 4 insertions(+)
arch/riscv/include/asm/thread_info.h +4 -0
@@ -12,7 +12,11 @@
 #include <linux/const.h>
 
 /* thread information allocation */
+#ifdef CONFIG_64BIT
+#define THREAD_SIZE_ORDER	(2)
+#else
 #define THREAD_SIZE_ORDER	(1)
+#endif
 #define THREAD_SIZE		(PAGE_SIZE << THREAD_SIZE_ORDER)
 
 #ifndef __ASSEMBLY__
author maintainer
#199 lore raw

PATCH 197/244 hwmon: (emc2103) fix unable to change fan pwm1_enable attribute

In reply to Greg Kroah-Hartman

From: Vishwas M <[email protected]>

commit 14b0e83dc4f1e52b94acaeb85a18fd7fdd46d2dc upstream.

This patch fixes a bug which does not let FAN mode to be changed from sysfs(pwm1_enable). i.e pwm1_enable can not be set to 3, it will always remain at 0.

This is caused because the device driver handles the result of "read_u8_from_i2c(client, REG_FAN_CONF1, &conf_reg)" incorrectly. The driver thinks an error has occurred if the (result != 0). This has been fixed by changing the condition to (result < 0).

Fixes 9df7305b5a86 ("hwmon: Add driver for SMSC EMC2103 temperature monitor and fan controller")
---
 drivers/hwmon/emc2103.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/emc2103.c +1 -1
@@ -443,7 +443,7 @@ static ssize_t pwm1_enable_store(struct
 	}
 
 	result = read_u8_from_i2c(client, REG_FAN_CONF1, &conf_reg);
-	if (result) {
+	if (result < 0) {
 		count = result;
 		goto err;
 	}
author maintainer
#200 lore raw

PATCH 198/244 hwmon: (drivetemp) Avoid SCT usage on Toshiba DT01ACA family drives

In reply to Greg Kroah-Hartman

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

commit c66ef39eb27fe123ee05082b90eb2985c33c7715 upstream.

It has been observed that Toshiba DT01ACA family drives have WRITE FPDMA QUEUED command timeouts and sometimes just freeze until power-cycled under heavy write loads when their temperature is getting polled in SCT mode. The SMART mode seems to be fine, though.

Let's make sure we don't use SCT mode for these drives then.

While only the 3 TB model was actually caught exhibiting the problem let's play safe here to avoid data corruption and extend the ban to the whole family.

---
 drivers/hwmon/drivetemp.c |   43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)
drivers/hwmon/drivetemp.c +43 -0
@@ -285,6 +285,42 @@ static int drivetemp_get_scttemp(struct
 	return err;
 }
 
+static const char * const sct_avoid_models[] = {
+/*
+ * These drives will have WRITE FPDMA QUEUED command timeouts and sometimes just
+ * freeze until power-cycled under heavy write loads when their temperature is
+ * getting polled in SCT mode. The SMART mode seems to be fine, though.
+ *
+ * While only the 3 TB model (DT01ACA3) was actually caught exhibiting the
+ * problem let's play safe here to avoid data corruption and ban the whole
+ * DT01ACAx family.
+
+ * The models from this array are prefix-matched.
+ */
+	"TOSHIBA DT01ACA",
+};
+
+static bool drivetemp_sct_avoid(struct drivetemp_data *st)
+{
+	struct scsi_device *sdev = st->sdev;
+	unsigned int ctr;
+
+	if (!sdev->model)
+		return false;
+
+	/*
+	 * The "model" field contains just the raw SCSI INQUIRY response
+	 * "product identification" field, which has a width of 16 bytes.
+	 * This field is space-filled, but is NOT NULL-terminated.
+	 */
+	for (ctr = 0; ctr < ARRAY_SIZE(sct_avoid_models); ctr++)
+		if (!strncmp(sdev->model, sct_avoid_models[ctr],
+			     strlen(sct_avoid_models[ctr])))
+			return true;
+
+	return false;
+}
+
 static int drivetemp_identify_sata(struct drivetemp_data *st)
 {
 	struct scsi_device *sdev = st->sdev;
@@ -326,6 +362,13 @@ static int drivetemp_identify_sata(struc
 	/* bail out if this is not a SATA device */
 	if (!is_ata || !is_sata)
 		return -ENODEV;
+
+	if (have_sct && drivetemp_sct_avoid(st)) {
+		dev_notice(&sdev->sdev_gendev,
+			   "will avoid using SCT for temperature monitoring\n");
+		have_sct = false;
+	}
+
 	if (!have_sct)
 		goto skip_sct;
 
author maintainer
#201 lore raw

PATCH 199/244 powerpc/book3s64/pkeys: Fix pkey_access_permitted() for execute disable pkey

In reply to Greg Kroah-Hartman

From: Aneesh Kumar K.V <[email protected]>

commit 192b6a780598976feb7321ff007754f8511a4129 upstream.

Even if the IAMR value denies execute access, the current code returns true from pkey_access_permitted() for an execute permission check, if the AMR read pkey bit is cleared.

This results in repeated page fault loop with a test like below:

  #define _GNU_SOURCE
  #include <errno.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <signal.h>
  #include <inttypes.h>

  #include <assert.h>
  #include <malloc.h>
  #include <unistd.h>
  #include <pthread.h>
  #include <sys/mman.h>

  #ifdef SYS_pkey_mprotect
  #undef SYS_pkey_mprotect
  #endif

  #ifdef SYS_pkey_alloc
  #undef SYS_pkey_alloc
  #endif

  #ifdef SYS_pkey_free
  #undef SYS_pkey_free
  #endif

  #undef PKEY_DISABLE_EXECUTE
  #define PKEY_DISABLE_EXECUTE	0x4

  #define SYS_pkey_mprotect	386
  #define SYS_pkey_alloc		384
  #define SYS_pkey_free		385

  #define PPC_INST_NOP		0x60000000
  #define PPC_INST_BLR		0x4e800020
  #define PROT_RWX		(PROT_READ | PROT_WRITE | PROT_EXEC)

static int sys_pkey_mprotect(void *addr, size_t len, int prot, int pkey) {
return syscall(SYS_pkey_mprotect, addr, len, prot, pkey);
}

  static int sys_pkey_alloc(unsigned long flags, unsigned long access_rights)
  {
  	return syscall(SYS_pkey_alloc, flags, access_rights);
  }

  static int sys_pkey_free(int pkey)
  {
  	return syscall(SYS_pkey_free, pkey);
  }

  static void do_execute(void *region)
  {
  	/* jump to region */
  	asm volatile(
  		"mtctr	%0;"
  		"bctrl"
  		: : "r"(region) : "ctr", "lr");
  }

  static void do_protect(void *region)
  {
  	size_t pgsize;
  	int i, pkey;

  	pgsize = getpagesize();

  	pkey = sys_pkey_alloc(0, PKEY_DISABLE_EXECUTE);
  	assert (pkey > 0);

  	/* perform mprotect */
  	assert(!sys_pkey_mprotect(region, pgsize, PROT_RWX, pkey));
  	do_execute(region);

  	/* free pkey */
  	assert(!sys_pkey_free(pkey));

  }

  int main(int argc, char **argv)
  {
  	size_t pgsize, numinsns;
  	unsigned int *region;
  	int i;

  	/* allocate memory region to protect */
  	pgsize = getpagesize();
  	region = memalign(pgsize, pgsize);
  	assert(region != NULL);
  	assert(!mprotect(region, pgsize, PROT_RWX));

  	/* fill page with NOPs with a BLR at the end */
  	numinsns = pgsize / sizeof(region[0]);
  	for (i = 0; i < numinsns - 1; i++)
  		region[i] = PPC_INST_NOP;
  	region[i] = PPC_INST_BLR;

  	do_protect(region);

  	return EXIT_SUCCESS;
  }

The fix is to only check the IAMR for an execute check, the AMR value is not relevant.

Fixes f2407ef3ba22 ("powerpc: helper to validate key-access permissions of a pte")
Cc [email protected] # v4.16+
[mpe: Add detail to change log, tweak wording & formatting]
---
 arch/powerpc/mm/book3s64/pkeys.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)
arch/powerpc/mm/book3s64/pkeys.c +7 -5
@@ -357,12 +357,14 @@ static bool pkey_access_permitted(int pk
 		return true;
 
 	pkey_shift = pkeyshift(pkey);
-	if (execute && !(read_iamr() & (IAMR_EX_BIT << pkey_shift)))
-		return true;
+	if (execute)
+		return !(read_iamr() & (IAMR_EX_BIT << pkey_shift));
+
+	amr = read_amr();
+	if (write)
+		return !(amr & (AMR_WR_BIT << pkey_shift));
 
-	amr = read_amr(); /* Delay reading amr until absolutely needed */
-	return ((!write && !(amr & (AMR_RD_BIT << pkey_shift))) ||
-		(write &&  !(amr & (AMR_WR_BIT << pkey_shift))));
+	return !(amr & (AMR_RD_BIT << pkey_shift));
 }
 
 bool arch_pte_access_permitted(u64 pte, bool write, bool execute)
author maintainer
#202 lore raw

PATCH 200/244 powerpc/pseries/svm: Fix incorrect check for shared_lppaca_size

In reply to Greg Kroah-Hartman

From: Satheesh Rajendran <[email protected]>

commit b710d27bf72068b15b2f0305d825988183e2ff28 upstream.

Early secure guest boot hits the below crash while booting with vcpus numbers aligned with page boundary for PAGE size of 64k and LPPACA size of 1k i.e 64, 128 etc.

Partition configured for 64 cpus.
CPU maps initialized for 1 thread per core

  ------------[ cut here ]------------
  kernel BUG at arch/powerpc/kernel/paca.c:89!
  Oops: Exception in kernel mode, sig: 5 [#1]
  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries

This is due to the BUG_ON() for shared_lppaca_total_size equal to shared_lppaca_size. Instead the code should only BUG_ON() if we have exceeded the total_size, which indicates we've overflowed the array.

Fixes bd104e6db6f0 ("powerpc/pseries/svm: Use shared memory for LPPACA structures")
[mpe: Reword change log to clarify we're fixing not removing the check]
---
 arch/powerpc/kernel/paca.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/paca.c +1 -1
@@ -86,7 +86,7 @@ static void *__init alloc_shared_lppaca(
 	 * This is very early in boot, so no harm done if the kernel crashes at
 	 * this point.
 	 */
-	BUG_ON(shared_lppaca_size >= shared_lppaca_total_size);
+	BUG_ON(shared_lppaca_size > shared_lppaca_total_size);
 
 	return ptr;
 }
author maintainer
#203 lore raw

PATCH 201/244 intel_th: pci: Add Jasper Lake CPU support

In reply to Greg Kroah-Hartman

From: Alexander Shishkin <[email protected]>

commit 203c1f615052921901b7a8fbe2005d8ea6add076 upstream.

This adds support for the Trace Hub in Jasper Lake CPU.

---
 drivers/hwtracing/intel_th/pci.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/hwtracing/intel_th/pci.c +5 -0
@@ -239,6 +239,11 @@ static const struct pci_device_id intel_
 		.driver_data = (kernel_ulong_t)&intel_th_2x,
 	},
 	{
+		/* Jasper Lake CPU */
+		PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4e29),
+		.driver_data = (kernel_ulong_t)&intel_th_2x,
+	},
+	{
 		/* Elkhart Lake CPU */
 		PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4529),
 		.driver_data = (kernel_ulong_t)&intel_th_2x,
author maintainer
#204 lore raw

PATCH 202/244 intel_th: pci: Add Tiger Lake PCH-H support

In reply to Greg Kroah-Hartman

From: Alexander Shishkin <[email protected]>

commit 6227585dc7b6a5405fc08dc322f98cb95e2f0eb4 upstream.

This adds support for the Trace Hub in Tiger Lake PCH-H.

---
 drivers/hwtracing/intel_th/pci.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/hwtracing/intel_th/pci.c +5 -0
@@ -234,6 +234,11 @@ static const struct pci_device_id intel_
 		.driver_data = (kernel_ulong_t)&intel_th_2x,
 	},
 	{
+		/* Tiger Lake PCH-H */
+		PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x43a6),
+		.driver_data = (kernel_ulong_t)&intel_th_2x,
+	},
+	{
 		/* Jasper Lake PCH */
 		PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4da6),
 		.driver_data = (kernel_ulong_t)&intel_th_2x,
author maintainer
#205 lore raw

PATCH 203/244 intel_th: pci: Add Emmitsburg PCH support

In reply to Greg Kroah-Hartman

From: Alexander Shishkin <[email protected]>

commit fd73d74a32bfaaf259441322cc5a1c83caaa94f2 upstream.

This adds support for the Trace Hub in Emmitsburg PCH.

---
 drivers/hwtracing/intel_th/pci.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/hwtracing/intel_th/pci.c +5 -0
@@ -258,6 +258,11 @@ static const struct pci_device_id intel_
 		PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4b26),
 		.driver_data = (kernel_ulong_t)&intel_th_2x,
 	},
+	{
+		/* Emmitsburg PCH */
+		PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x1bcc),
+		.driver_data = (kernel_ulong_t)&intel_th_2x,
+	},
 	{ 0 },
 };
 
author maintainer
#206 lore raw

PATCH 204/244 intel_th: Fix a NULL dereference when hub driver is not loaded

In reply to Greg Kroah-Hartman

From: Alexander Shishkin <[email protected]>

commit e78e1fdb282726beaf88aa75943682217e6ded0e upstream.

Connecting master to an output port when GTH driver module is not loaded triggers a NULL dereference:

Quoted 5 lines
RIP: 0010:intel_th_set_output+0x35/0x70 [intel_th]
Call Trace:
 ? sth_stm_link+0x12/0x20 [intel_th_sth]
 stm_source_link_store+0x164/0x270 [stm_core]
 dev_attr_store+0x17/0x30
Quoted 8 lines
 sysfs_kf_write+0x3e/0x50
 kernfs_fop_write+0xda/0x1b0
 __vfs_write+0x1b/0x40
 vfs_write+0xb9/0x1a0
 ksys_write+0x67/0xe0
 __x64_sys_write+0x1a/0x20
 do_syscall_64+0x57/0x1d0
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Make sure the module in question is loaded and return an error if not.

Fixes 39f4034693b7c ("intel_th: Add driver infrastructure for Intel(R) Trace Hub devices")
---
 drivers/hwtracing/intel_th/core.c |   21 ++++++++++++++++++---
 drivers/hwtracing/intel_th/sth.c  |    4 +---
 2 files changed, 19 insertions(+), 6 deletions(-)
drivers/hwtracing/intel_th/core.c +18 -3
@@ -1021,15 +1021,30 @@ int intel_th_set_output(struct intel_th_
 {
 	struct intel_th_device *hub = to_intel_th_hub(thdev);
 	struct intel_th_driver *hubdrv = to_intel_th_driver(hub->dev.driver);
+	int ret;
 
 	/* In host mode, this is up to the external debugger, do nothing. */
 	if (hub->host_mode)
 		return 0;
 
-	if (!hubdrv->set_output)
-		return -ENOTSUPP;
+	/*
+	 * hub is instantiated together with the source device that
+	 * calls here, so guaranteed to be present.
+	 */
+	hubdrv = to_intel_th_driver(hub->dev.driver);
+	if (!hubdrv || !try_module_get(hubdrv->driver.owner))
+		return -EINVAL;
 
-	return hubdrv->set_output(hub, master);
+	if (!hubdrv->set_output) {
+		ret = -ENOTSUPP;
+		goto out;
+	}
+
+	ret = hubdrv->set_output(hub, master);
+
+out:
+	module_put(hubdrv->driver.owner);
+	return ret;
 }
 EXPORT_SYMBOL_GPL(intel_th_set_output);
 
drivers/hwtracing/intel_th/sth.c +1 -3
@@ -161,9 +161,7 @@ static int sth_stm_link(struct stm_data
 {
 	struct sth_device *sth = container_of(stm_data, struct sth_device, stm);
 
-	intel_th_set_output(to_intel_th_device(sth->dev), master);
-
-	return 0;
+	return intel_th_set_output(to_intel_th_device(sth->dev), master);
 }
 
 static int intel_th_sw_init(struct sth_device *sth)
author maintainer
#207 lore raw

PATCH 205/244 opp: Increase parsed_static_opps in _of_add_opp_table_v1()

In reply to Greg Kroah-Hartman

From: Walter Lozano <[email protected]>

commit 6544abc520f0fff701e9da382110dc29676c683a upstream.

Currently, when using _of_add_opp_table_v2 parsed_static_opps is increased and this value is used in _opp_remove_all_static() to check if there are static opp entries that need to be freed. Unfortunately this does not happen when using _of_add_opp_table_v1(), which leads to warnings.

This patch increases parsed_static_opps in _of_add_opp_table_v1() in a similar way as in _of_add_opp_table_v2().

Fixes 03758d60265c ("opp: Replace list_kref with a local counter")
Cc v5.6+ <[email protected]> # v5.6+

[ Viresh: Do the operation with lock held and set the value to 1 instead
of incrementing it ]

---
 drivers/opp/of.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/opp/of.c +4 -0
@@ -733,6 +733,10 @@ static int _of_add_opp_table_v1(struct d
 		return -EINVAL;
 	}
 
+	mutex_lock(&opp_table->lock);
+	opp_table->parsed_static_opps = 1;
+	mutex_unlock(&opp_table->lock);
+
 	val = prop->value;
 	while (nr) {
 		unsigned long freq = be32_to_cpup(val++) * 1000;
author maintainer
#208 lore raw

PATCH 206/244 dmaengine: fsl-edma: Fix NULL pointer exception in fsl_edma_tx_handler

In reply to Greg Kroah-Hartman

From: Krzysztof Kozlowski <[email protected]>

commit f5e5677c420346b4e9788051c2e4d750996c428c upstream.

NULL pointer exception happens occasionally on serial output initiated by login timeout. This was reproduced only if kernel was built with significant debugging options and EDMA driver is used with serial console.

    col-vf50 login: root
    Password:
    Login timed out after 60 seconds.
    Unable to handle kernel NULL pointer dereference at virtual address 00000044
    Internal error: Oops: 5 [#1] ARM
    CPU: 0 PID: 157 Comm: login Not tainted 5.7.0-next-20200610-dirty #4
    Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
      (fsl_edma_tx_handler) from [<8016eb10>] (__handle_irq_event_percpu+0x64/0x304)
      (__handle_irq_event_percpu) from [<8016eddc>] (handle_irq_event_percpu+0x2c/0x7c)
      (handle_irq_event_percpu) from [<8016ee64>] (handle_irq_event+0x38/0x5c)
      (handle_irq_event) from [<801729e4>] (handle_fasteoi_irq+0xa4/0x160)
      (handle_fasteoi_irq) from [<8016ddcc>] (generic_handle_irq+0x34/0x44)
      (generic_handle_irq) from [<8016e40c>] (__handle_domain_irq+0x54/0xa8)
      (__handle_domain_irq) from [<80508bc8>] (gic_handle_irq+0x4c/0x80)
      (gic_handle_irq) from [<80100af0>] (__irq_svc+0x70/0x98)
    Exception stack(0x8459fe80 to 0x8459fec8)
    fe80: 72286b00 e3359f64 00000001 0000412d a0070013 85c98840 85c98840 a0070013
    fea0: 8054e0d4 00000000 00000002 00000000 00000002 8459fed0 8081fbe8 8081fbec
    fec0: 60070013 ffffffff
      (__irq_svc) from [<8081fbec>] (_raw_spin_unlock_irqrestore+0x30/0x58)
      (_raw_spin_unlock_irqrestore) from [<8056cb48>] (uart_flush_buffer+0x88/0xf8)
      (uart_flush_buffer) from [<80554e60>] (tty_ldisc_hangup+0x38/0x1ac)
      (tty_ldisc_hangup) from [<8054c7f4>] (__tty_hangup+0x158/0x2bc)
      (__tty_hangup) from [<80557b90>] (disassociate_ctty.part.1+0x30/0x23c)
      (disassociate_ctty.part.1) from [<8011fc18>] (do_exit+0x580/0xba0)
      (do_exit) from [<801214f8>] (do_group_exit+0x3c/0xb4)
      (do_group_exit) from [<80121580>] (__wake_up_parent+0x0/0x14)

Issue looks like race condition between interrupt handler fsl_edma_tx_handler() (called as result of fsl_edma_xfer_desc()) and terminating the transfer with fsl_edma_terminate_all().

The fsl_edma_tx_handler() handles interrupt for a transfer with already freed edesc and idle==true.

---
 drivers/dma/fsl-edma.c |    7 +++++++
 1 file changed, 7 insertions(+)
drivers/dma/fsl-edma.c +7 -0
@@ -45,6 +45,13 @@ static irqreturn_t fsl_edma_tx_handler(i
 			fsl_chan = &fsl_edma->chans[ch];
 
 			spin_lock(&fsl_chan->vchan.lock);
+
+			if (!fsl_chan->edesc) {
+				/* terminate_all called before */
+				spin_unlock(&fsl_chan->vchan.lock);
+				continue;
+			}
+
 			if (!fsl_chan->edesc->iscyclic) {
 				list_del(&fsl_chan->edesc->vdesc.node);
 				vchan_cookie_complete(&fsl_chan->edesc->vdesc);
author maintainer
#209 lore raw

PATCH 207/244 dmaengine: mcf-edma: Fix NULL pointer exception in mcf_edma_tx_handler

In reply to Greg Kroah-Hartman

From: Krzysztof Kozlowski <[email protected]>

commit 8995aa3d164ddd9200e6abcf25c449cf5298c858 upstream.

On Toradex Colibri VF50 (Vybrid VF5xx) with fsl-edma driver NULL pointer exception happens occasionally on serial output initiated by login timeout.

This was reproduced only if kernel was built with significant debugging options and EDMA driver is used with serial console.

Issue looks like a race condition between interrupt handler fsl_edma_tx_handler() (called as a result of fsl_edma_xfer_desc()) and terminating the transfer with fsl_edma_terminate_all().

The fsl_edma_tx_handler() handles interrupt for a transfer with already freed edesc and idle==true.

The mcf-edma driver shares design and lot of code with fsl-edma. It looks like being affected by same problem. Fix this pattern the same way as fix for fsl-edma driver.

Fixes e7a3ff92eaf1 ("dmaengine: fsl-edma: add ColdFire mcf5441x edma support")
---
 drivers/dma/mcf-edma.c |    7 +++++++
 1 file changed, 7 insertions(+)
drivers/dma/mcf-edma.c +7 -0
@@ -35,6 +35,13 @@ static irqreturn_t mcf_edma_tx_handler(i
 			mcf_chan = &mcf_edma->chans[ch];
 
 			spin_lock(&mcf_chan->vchan.lock);
+
+			if (!mcf_chan->edesc) {
+				/* terminate_all called before */
+				spin_unlock(&mcf_chan->vchan.lock);
+				continue;
+			}
+
 			if (!mcf_chan->edesc->iscyclic) {
 				list_del(&mcf_chan->edesc->vdesc.node);
 				vchan_cookie_complete(&mcf_chan->edesc->vdesc);
author maintainer
#210 lore raw

PATCH 208/244 dmaengine: fsl-edma-common: correct DSIZE_32BYTE

In reply to Greg Kroah-Hartman

From: Robin Gong <[email protected]>

commit e142087b15960a4e1e5932942e5abae1f49d2318 upstream.

Correct EDMA_TCD_ATTR_DSIZE_32BYTE define since it's broken by the below:
'0x0005 --> BIT(3) | BIT(0))'

---
 drivers/dma/fsl-edma-common.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dma/fsl-edma-common.h +1 -1
@@ -33,7 +33,7 @@
 #define EDMA_TCD_ATTR_DSIZE_16BIT	BIT(0)
 #define EDMA_TCD_ATTR_DSIZE_32BIT	BIT(1)
 #define EDMA_TCD_ATTR_DSIZE_64BIT	(BIT(0) | BIT(1))
-#define EDMA_TCD_ATTR_DSIZE_32BYTE	(BIT(3) | BIT(0))
+#define EDMA_TCD_ATTR_DSIZE_32BYTE	(BIT(2) | BIT(0))
 #define EDMA_TCD_ATTR_SSIZE_8BIT	0
 #define EDMA_TCD_ATTR_SSIZE_16BIT	(EDMA_TCD_ATTR_DSIZE_16BIT << 8)
 #define EDMA_TCD_ATTR_SSIZE_32BIT	(EDMA_TCD_ATTR_DSIZE_32BIT << 8)
author maintainer
#211 lore raw

PATCH 209/244 misc: atmel-ssc: lock with mutex instead of spinlock

In reply to Greg Kroah-Hartman

From: Michał Mirosław <[email protected]>

commit b037d60a3b1d1227609fd858fa34321f41829911 upstream.

Uninterruptible context is not needed in the driver and causes lockdep warning because of mutex taken in of_alias_get_id(). Convert the lock to mutex to avoid the issue.

---
 drivers/misc/atmel-ssc.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)
drivers/misc/atmel-ssc.c +12 -12
@@ -10,7 +10,7 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/io.h>
-#include <linux/spinlock.h>
+#include <linux/mutex.h>
 #include <linux/atmel-ssc.h>
 #include <linux/slab.h>
 #include <linux/module.h>
@@ -20,7 +20,7 @@
 #include "../../sound/soc/atmel/atmel_ssc_dai.h"
 
 /* Serialize access to ssc_list and user count */
-static DEFINE_SPINLOCK(user_lock);
+static DEFINE_MUTEX(user_lock);
 static LIST_HEAD(ssc_list);
 
 struct ssc_device *ssc_request(unsigned int ssc_num)
@@ -28,7 +28,7 @@ struct ssc_device *ssc_request(unsigned
 	int ssc_valid = 0;
 	struct ssc_device *ssc;
 
-	spin_lock(&user_lock);
+	mutex_lock(&user_lock);
 	list_for_each_entry(ssc, &ssc_list, list) {
 		if (ssc->pdev->dev.of_node) {
 			if (of_alias_get_id(ssc->pdev->dev.of_node, "ssc")
@@ -44,18 +44,18 @@ struct ssc_device *ssc_request(unsigned
 	}
 
 	if (!ssc_valid) {
-		spin_unlock(&user_lock);
+		mutex_unlock(&user_lock);
 		pr_err("ssc: ssc%d platform device is missing\n", ssc_num);
 		return ERR_PTR(-ENODEV);
 	}
 
 	if (ssc->user) {
-		spin_unlock(&user_lock);
+		mutex_unlock(&user_lock);
 		dev_dbg(&ssc->pdev->dev, "module busy\n");
 		return ERR_PTR(-EBUSY);
 	}
 	ssc->user++;
-	spin_unlock(&user_lock);
+	mutex_unlock(&user_lock);
 
 	clk_prepare(ssc->clk);
 
@@ -67,14 +67,14 @@ void ssc_free(struct ssc_device *ssc)
 {
 	bool disable_clk = true;
 
-	spin_lock(&user_lock);
+	mutex_lock(&user_lock);
 	if (ssc->user)
 		ssc->user--;
 	else {
 		disable_clk = false;
 		dev_dbg(&ssc->pdev->dev, "device already free\n");
 	}
-	spin_unlock(&user_lock);
+	mutex_unlock(&user_lock);
 
 	if (disable_clk)
 		clk_unprepare(ssc->clk);
@@ -237,9 +237,9 @@ static int ssc_probe(struct platform_dev
 		return -ENXIO;
 	}
 
-	spin_lock(&user_lock);
+	mutex_lock(&user_lock);
 	list_add_tail(&ssc->list, &ssc_list);
-	spin_unlock(&user_lock);
+	mutex_unlock(&user_lock);
 
 	platform_set_drvdata(pdev, ssc);
 
@@ -258,9 +258,9 @@ static int ssc_remove(struct platform_de
 
 	ssc_sound_dai_remove(ssc);
 
-	spin_lock(&user_lock);
+	mutex_lock(&user_lock);
 	list_del(&ssc->list);
-	spin_unlock(&user_lock);
+	mutex_unlock(&user_lock);
 
 	return 0;
 }
author maintainer
#212 lore raw

PATCH 210/244 dmabuf: use spinlock to access dmabuf->name

In reply to Greg Kroah-Hartman

From: Charan Teja Kalla <[email protected]>

commit 6348dd291e3653534a9e28e6917569bc9967b35b upstream.

There exists a sleep-while-atomic bug while accessing the dmabuf->name under mutex in the dmabuffs_dname(). This is caused from the SELinux permissions checks on a process where it tries to validate the inherited files from fork() by traversing them through iterate_fd() (which traverse files under spin_lock) and call match_file(security/selinux/hooks.c) where the permission checks happen. This audit information is logged using dump_common_audit_data() where it calls d_path() to get the file path name. If the file check happen on the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to access dmabuf->name. The flow will be like below:
flush_unauthorized_files()
iterate_fd()

    spin_lock() --> Start of the atomic section.
      match_file()
        file_has_perm()
          avc_has_perm()
            avc_audit()
              slow_avc_audit()
	        common_lsm_audit()
		  dump_common_audit_data()
		    audit_log_d_path()
		      d_path()
                        dmabuffs_dname()
                          mutex_lock()--> Sleep while atomic.

Call trace captured (on 4.19 kernels) is below:

___might_sleep+0x204/0x208
__might_sleep+0x50/0x88
__mutex_lock_common+0x5c/0x1068
__mutex_lock_common+0x5c/0x1068
mutex_lock_nested+0x40/0x50
dmabuffs_dname+0xa0/0x170
d_path+0x84/0x290
audit_log_d_path+0x74/0x130
common_lsm_audit+0x334/0x6e8
slow_avc_audit+0xb8/0xf8
avc_has_perm+0x154/0x218
file_has_perm+0x70/0x180
match_file+0x60/0x78
iterate_fd+0x128/0x168
selinux_bprm_committing_creds+0x178/0x248
security_bprm_committing_creds+0x30/0x48
install_exec_creds+0x1c/0x68
load_elf_binary+0x3a4/0x14e0
search_binary_handler+0xb0/0x1e0

So, use spinlock to access dmabuf->name to avoid sleep-while-atomic.

---
 drivers/dma-buf/dma-buf.c |   11 +++++++----
 include/linux/dma-buf.h   |    1 +
 2 files changed, 8 insertions(+), 4 deletions(-)
drivers/dma-buf/dma-buf.c +7 -4
@@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentr
 	size_t ret = 0;
 
 	dmabuf = dentry->d_fsdata;
-	dma_resv_lock(dmabuf->resv, NULL);
+	spin_lock(&dmabuf->name_lock);
 	if (dmabuf->name)
 		ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
-	dma_resv_unlock(dmabuf->resv);
+	spin_unlock(&dmabuf->name_lock);
 
 	return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
 			     dentry->d_name.name, ret > 0 ? name : "");
@@ -338,8 +338,10 @@ static long dma_buf_set_name(struct dma_
 		kfree(name);
 		goto out_unlock;
 	}
+	spin_lock(&dmabuf->name_lock);
 	kfree(dmabuf->name);
 	dmabuf->name = name;
+	spin_unlock(&dmabuf->name_lock);
 
 out_unlock:
 	dma_resv_unlock(dmabuf->resv);
@@ -402,10 +404,10 @@ static void dma_buf_show_fdinfo(struct s
 	/* Don't count the temporary reference taken inside procfs seq_show */
 	seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
 	seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name);
-	dma_resv_lock(dmabuf->resv, NULL);
+	spin_lock(&dmabuf->name_lock);
 	if (dmabuf->name)
 		seq_printf(m, "name:\t%s\n", dmabuf->name);
-	dma_resv_unlock(dmabuf->resv);
+	spin_unlock(&dmabuf->name_lock);
 }
 
 static const struct file_operations dma_buf_fops = {
@@ -542,6 +544,7 @@ struct dma_buf *dma_buf_export(const str
 	dmabuf->size = exp_info->size;
 	dmabuf->exp_name = exp_info->exp_name;
 	dmabuf->owner = exp_info->owner;
+	spin_lock_init(&dmabuf->name_lock);
 	init_waitqueue_head(&dmabuf->poll);
 	dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
 	dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
include/linux/dma-buf.h +1 -0
@@ -311,6 +311,7 @@ struct dma_buf {
 	void *vmap_ptr;
 	const char *exp_name;
 	const char *name;
+	spinlock_t name_lock; /* spinlock to protect name access */
 	struct module *owner;
 	struct list_head list_node;
 	void *priv;
author maintainer
#213 lore raw

PATCH 211/244 thermal: int3403_thermal: Downgrade error message

In reply to Greg Kroah-Hartman

From: Alex Hung <[email protected]>

commit f3d7fb38976b1b0a8462ba1c7cbd404ddfaad086 upstream.

Downgrade "Unsupported event" message from dev_err to dev_dbg to avoid flooding with this message on some platforms.

---
 drivers/thermal/intel/int340x_thermal/int3403_thermal.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/thermal/intel/int340x_thermal/int3403_thermal.c +1 -1
@@ -74,7 +74,7 @@ static void int3403_notify(acpi_handle h
 						   THERMAL_TRIP_CHANGED);
 		break;
 	default:
-		dev_err(&priv->pdev->dev, "Unsupported event [0x%x]\n", event);
+		dev_dbg(&priv->pdev->dev, "Unsupported event [0x%x]\n", event);
 		break;
 	}
 }
author maintainer
#214 lore raw

PATCH 212/244 ARM: dts: imx6qdl-gw551x: fix audio SSI

In reply to Greg Kroah-Hartman

From: Tim Harvey <[email protected]>

commit 4237c625304b212a3f30adf787901082082511ec upstream.

The audio codec on the GW551x routes to ssi1. It fixes audio capture on the device.

Fixes 3117e851cef1 ("ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x")
---
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx6qdl-gw551x.dtsi +1 -1
@@ -110,7 +110,7 @@
 		simple-audio-card,frame-master = <&sound_codec>;
 
 		sound_cpu: simple-audio-card,cpu {
-			sound-dai = <&ssi2>;
+			sound-dai = <&ssi1>;
 		};
 
 		sound_codec: simple-audio-card,codec {
author maintainer
#215 lore raw

PATCH 213/244 arm64: dts: agilex: add status to qspi dts node

In reply to Greg Kroah-Hartman

From: Dinh Nguyen <[email protected]>

commit 60176e6be0bb6f629b15aea7dcab5a95ecb158e9 upstream.

Add status = "okay" to QSPI node.

Fixes c4c8757b2d895 ("arm64: dts: agilex: add QSPI support for Intel Agilex")
Cc linux-stable <[email protected]> # >= v5.5
---
 arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts |    1 +
 1 file changed, 1 insertion(+)
arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts +1 -0
@@ -98,6 +98,7 @@
 };
 
 &qspi {
+	status = "okay";
 	flash@0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
author maintainer
#216 lore raw

PATCH 214/244 arm64: dts: stratix10: add status to qspi dts node

In reply to Greg Kroah-Hartman

From: Dinh Nguyen <[email protected]>

commit 263a0269a59c0b4145829462a107fe7f7327105f upstream.

Add status = "okay" to QSPI node.

Fixes 0cb140d07fc75 ("arm64: dts: stratix10: Add QSPI support for Stratix10")
Cc linux-stable <[email protected]> # >= v5.6
---
 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts      |    1 +
 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk_nand.dts |    1 +
 2 files changed, 2 insertions(+)
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts +1 -0
@@ -155,6 +155,7 @@
 };
 
 &qspi {
+	status = "okay";
 	flash@0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk_nand.dts +1 -0
@@ -188,6 +188,7 @@
 };
 
 &qspi {
+	status = "okay";
 	flash@0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
author maintainer
#217 lore raw

PATCH 215/244 arm64: dts: stratix10: increase QSPI reg address in nand dts file

In reply to Greg Kroah-Hartman

From: Dinh Nguyen <[email protected]>

commit 3bf9b8ffc8980c1090bdd3a5570cf42420620838 upstream.

Match the QSPI reg address in the socfpga_stratix10_socdk.dts file.

Fixes 80f132d73709 ("arm64: dts: increase the QSPI reg address for Stratix10 and Agilex")
Cc linux-stable <[email protected]> # >= v5.6
---
 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk_nand.dts |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk_nand.dts +3 -3
@@ -212,12 +212,12 @@
 
 			qspi_boot: partition@0 {
 				label = "Boot and fpga data";
-				reg = <0x0 0x034B0000>;
+				reg = <0x0 0x03FE0000>;
 			};
 
-			qspi_rootfs: partition@4000000 {
+			qspi_rootfs: partition@3FE0000 {
 				label = "Root Filesystem - JFFS2";
-				reg = <0x034B0000 0x0EB50000>;
+				reg = <0x03FE0000 0x0C020000>;
 			};
 		};
 	};
author maintainer
#218 lore raw

PATCH 216/244 arm64: ptrace: Override SPSR.SS when single-stepping is enabled

In reply to Greg Kroah-Hartman

From: Will Deacon <[email protected]>

commit 3a5a4366cecc25daa300b9a9174f7fdd352b9068 upstream.

Luis reports that, when reverse debugging with GDB, single-step does not function as expected on arm64:

  | I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP
  | request by GDB won't execute the underlying instruction. As a consequence,
  | the PC doesn't move, but we return a SIGTRAP just like we would for a
  | regular successful PTRACE_SINGLESTEP request.

The underlying problem is that when the CPU register state is restored as part of a reverse step, the SPSR.SS bit is cleared and so the hardware single-step state can transition to the "active-pending" state, causing an unexpected step exception to be taken immediately if a step operation is attempted.

In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate accessible by the GPR regset, but it's a bit late for that now. Instead, simply prevent userspace from configuring the bit to a value which is inconsistent with the TIF_SINGLESTEP state for the task being traced.

---
 arch/arm64/include/asm/debug-monitors.h |    2 ++
 arch/arm64/kernel/debug-monitors.c      |   20 ++++++++++++++++----
 arch/arm64/kernel/ptrace.c              |    4 ++--
 3 files changed, 20 insertions(+), 6 deletions(-)
arch/arm64/include/asm/debug-monitors.h +2 -0
@@ -109,6 +109,8 @@ void disable_debug_monitors(enum dbg_act
 
 void user_rewind_single_step(struct task_struct *task);
 void user_fastforward_single_step(struct task_struct *task);
+void user_regs_reset_single_step(struct user_pt_regs *regs,
+				 struct task_struct *task);
 
 void kernel_enable_single_step(struct pt_regs *regs);
 void kernel_disable_single_step(void);
arch/arm64/kernel/debug-monitors.c +16 -4
@@ -141,17 +141,20 @@ postcore_initcall(debug_monitors_init);
 /*
  * Single step API and exception handling.
  */
-static void set_regs_spsr_ss(struct pt_regs *regs)
+static void set_user_regs_spsr_ss(struct user_pt_regs *regs)
 {
 	regs->pstate |= DBG_SPSR_SS;
 }
-NOKPROBE_SYMBOL(set_regs_spsr_ss);
+NOKPROBE_SYMBOL(set_user_regs_spsr_ss);
 
-static void clear_regs_spsr_ss(struct pt_regs *regs)
+static void clear_user_regs_spsr_ss(struct user_pt_regs *regs)
 {
 	regs->pstate &= ~DBG_SPSR_SS;
 }
-NOKPROBE_SYMBOL(clear_regs_spsr_ss);
+NOKPROBE_SYMBOL(clear_user_regs_spsr_ss);
+
+#define set_regs_spsr_ss(r)	set_user_regs_spsr_ss(&(r)->user_regs)
+#define clear_regs_spsr_ss(r)	clear_user_regs_spsr_ss(&(r)->user_regs)
 
 static DEFINE_SPINLOCK(debug_hook_lock);
 static LIST_HEAD(user_step_hook);
@@ -404,6 +407,15 @@ void user_fastforward_single_step(struct
 		clear_regs_spsr_ss(task_pt_regs(task));
 }
 
+void user_regs_reset_single_step(struct user_pt_regs *regs,
+				 struct task_struct *task)
+{
+	if (test_tsk_thread_flag(task, TIF_SINGLESTEP))
+		set_user_regs_spsr_ss(regs);
+	else
+		clear_user_regs_spsr_ss(regs);
+}
+
 /* Kernel API */
 void kernel_enable_single_step(struct pt_regs *regs)
 {
arch/arm64/kernel/ptrace.c +2 -2
@@ -1935,8 +1935,8 @@ static int valid_native_regs(struct user
  */
 int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
 {
-	if (!test_tsk_thread_flag(task, TIF_SINGLESTEP))
-		regs->pstate &= ~DBG_SPSR_SS;
+	/* https://lore.kernel.org/lkml/20191118131525.GA4180@willie-the-truck */
+	user_regs_reset_single_step(regs, task);
 
 	if (is_compat_thread(task_thread_info(task)))
 		return valid_compat_regs(regs);
author maintainer
#219 lore raw

PATCH 217/244 arm64: ptrace: Consistently use pseudo-singlestep exceptions

In reply to Greg Kroah-Hartman

From: Will Deacon <[email protected]>

commit ac2081cdc4d99c57f219c1a6171526e0fa0a6fff upstream.

Although the arm64 single-step state machine can be fast-forwarded in cases where we wish to generate a SIGTRAP without actually executing an instruction, this has two major limitations outside of simply skipping an instruction due to emulation.

1. Stepping out of a ptrace signal stop into a signal handler where SIGTRAP is blocked. Fast-forwarding the stepping state machine in this case will result in a forced SIGTRAP, with the handler reset to SIG_DFL.

2. The hardware implicitly fast-forwards the state machine when executing an SVC instruction for issuing a system call. This can interact badly with subsequent ptrace stops signalled during the execution of the system call (e.g. SYSCALL_EXIT or seccomp traps), as they may corrupt the stepping state by updating the PSTATE for the tracee.

Resolve both of these issues by injecting a pseudo-singlestep exception on entry to a signal handler and also on return to userspace following a system call.

---
 arch/arm64/include/asm/thread_info.h |    1 +
 arch/arm64/kernel/ptrace.c           |   27 ++++++++++++++++++++-------
 arch/arm64/kernel/signal.c           |   11 ++---------
 arch/arm64/kernel/syscall.c          |    2 +-
 4 files changed, 24 insertions(+), 17 deletions(-)
arch/arm64/include/asm/thread_info.h +1 -0
@@ -89,6 +89,7 @@ void arch_release_task_struct(struct tas
 #define _TIF_SYSCALL_EMU	(1 << TIF_SYSCALL_EMU)
 #define _TIF_UPROBE		(1 << TIF_UPROBE)
 #define _TIF_FSCHECK		(1 << TIF_FSCHECK)
+#define _TIF_SINGLESTEP		(1 << TIF_SINGLESTEP)
 #define _TIF_32BIT		(1 << TIF_32BIT)
 #define _TIF_SVE		(1 << TIF_SVE)
 
arch/arm64/kernel/ptrace.c +20 -7
@@ -1819,12 +1819,23 @@ static void tracehook_report_syscall(str
 	saved_reg = regs->regs[regno];
 	regs->regs[regno] = dir;
 
-	if (dir == PTRACE_SYSCALL_EXIT)
+	if (dir == PTRACE_SYSCALL_ENTER) {
+		if (tracehook_report_syscall_entry(regs))
+			forget_syscall(regs);
+		regs->regs[regno] = saved_reg;
+	} else if (!test_thread_flag(TIF_SINGLESTEP)) {
 		tracehook_report_syscall_exit(regs, 0);
-	else if (tracehook_report_syscall_entry(regs))
-		forget_syscall(regs);
-
-	regs->regs[regno] = saved_reg;
+		regs->regs[regno] = saved_reg;
+	} else {
+		regs->regs[regno] = saved_reg;
+
+		/*
+		 * Signal a pseudo-step exception since we are stepping but
+		 * tracer modifications to the registers may have rewound the
+		 * state machine.
+		 */
+		tracehook_report_syscall_exit(regs, 1);
+	}
 }
 
 int syscall_trace_enter(struct pt_regs *regs)
@@ -1852,12 +1863,14 @@ int syscall_trace_enter(struct pt_regs *
 
 void syscall_trace_exit(struct pt_regs *regs)
 {
+	unsigned long flags = READ_ONCE(current_thread_info()->flags);
+
 	audit_syscall_exit(regs);
 
-	if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
+	if (flags & _TIF_SYSCALL_TRACEPOINT)
 		trace_sys_exit(regs, regs_return_value(regs));
 
-	if (test_thread_flag(TIF_SYSCALL_TRACE))
+	if (flags & (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP))
 		tracehook_report_syscall(regs, PTRACE_SYSCALL_EXIT);
 
 	rseq_syscall(regs);
arch/arm64/kernel/signal.c +2 -9
@@ -784,7 +784,6 @@ static void setup_restart_syscall(struct
  */
 static void handle_signal(struct ksignal *ksig, struct pt_regs *regs)
 {
-	struct task_struct *tsk = current;
 	sigset_t *oldset = sigmask_to_save();
 	int usig = ksig->sig;
 	int ret;
@@ -808,14 +807,8 @@ static void handle_signal(struct ksignal
 	 */
 	ret |= !valid_user_regs(&regs->user_regs, current);
 
-	/*
-	 * Fast forward the stepping logic so we step into the signal
-	 * handler.
-	 */
-	if (!ret)
-		user_fastforward_single_step(tsk);
-
-	signal_setup_done(ret, ksig, 0);
+	/* Step into the signal handler if we are stepping */
+	signal_setup_done(ret, ksig, test_thread_flag(TIF_SINGLESTEP));
 }
 
 /*
arch/arm64/kernel/syscall.c +1 -1
@@ -121,7 +121,7 @@ static void el0_svc_common(struct pt_reg
 	if (!has_syscall_work(flags) && !IS_ENABLED(CONFIG_DEBUG_RSEQ)) {
 		local_daif_mask();
 		flags = current_thread_info()->flags;
-		if (!has_syscall_work(flags)) {
+		if (!has_syscall_work(flags) && !(flags & _TIF_SINGLESTEP)) {
 			/*
 			 * We're off to userspace, where interrupts are
 			 * always enabled after we restore the flags from
author maintainer
#220 lore raw

PATCH 218/244 arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return

In reply to Greg Kroah-Hartman

From: Will Deacon <[email protected]>

commit 15956689a0e60aa0c795174f3c310b60d8794235 upstream.

Although we zero the upper bits of x0 on entry to the kernel from an AArch32 task, we do not clear them on the exception return path and can therefore expose 64-bit sign extended syscall return values to userspace via interfaces such as the 'perf_regs' ABI, which deal exclusively with 64-bit registers.

Explicitly clear the upper 32 bits of x0 on return from a compat system call.

---
 arch/arm64/include/asm/syscall.h |   12 +++++++++++-
 arch/arm64/kernel/syscall.c      |    3 +++
 2 files changed, 14 insertions(+), 1 deletion(-)
arch/arm64/include/asm/syscall.h +11 -1
@@ -34,6 +34,10 @@ static inline long syscall_get_error(str
 				     struct pt_regs *regs)
 {
 	unsigned long error = regs->regs[0];
+
+	if (is_compat_thread(task_thread_info(task)))
+		error = sign_extend64(error, 31);
+
 	return IS_ERR_VALUE(error) ? error : 0;
 }
 
@@ -47,7 +51,13 @@ static inline void syscall_set_return_va
 					    struct pt_regs *regs,
 					    int error, long val)
 {
-	regs->regs[0] = (long) error ? error : val;
+	if (error)
+		val = error;
+
+	if (is_compat_thread(task_thread_info(task)))
+		val = lower_32_bits(val);
+
+	regs->regs[0] = val;
 }
 
 #define SYSCALL_MAX_ARGS 6
arch/arm64/kernel/syscall.c +3 -0
@@ -50,6 +50,9 @@ static void invoke_syscall(struct pt_reg
 		ret = do_ni_syscall(regs, scno);
 	}
 
+	if (is_compat_task())
+		ret = lower_32_bits(ret);
+
 	regs->regs[0] = ret;
 }
 
author maintainer
#221 lore raw

PATCH 219/244 sched: Fix unreliable rseq cpu_id for new tasks

In reply to Greg Kroah-Hartman

From: Mathieu Desnoyers <[email protected]>

commit ce3614daabea8a2d01c1dd17ae41d1ec5e5ae7db upstream.

While integrating rseq into glibc and replacing glibc's sched_getcpu implementation with rseq, glibc's tests discovered an issue with incorrect __rseq_abi.cpu_id field value right after the first time a newly created process issues sched_setaffinity.

For the records, it triggers after building glibc and running tests, and then issuing:

for x in {1..2000} ; do posix/tst-affinity-static & done

and shows up as:

error: Unexpected CPU 2, expected 0
error: Unexpected CPU 2, expected 0
error: Unexpected CPU 2, expected 0
error: Unexpected CPU 2, expected 0
error: Unexpected CPU 138, expected 0
error: Unexpected CPU 138, expected 0
error: Unexpected CPU 138, expected 0
error: Unexpected CPU 138, expected 0

This is caused by the scheduler invoking __set_task_cpu() directly from sched_fork() and wake_up_new_task(), thus bypassing rseq_migrate() which is done by set_task_cpu().

Add the missing rseq_migrate() to both functions. The only other direct use of __set_task_cpu() is done by init_idle(), which does not involve a user-space task.

Based on my testing with the glibc test-case, just adding rseq_migrate() to wake_up_new_task() is sufficient to fix the observed issue. Also add it to sched_fork() to keep things consistent.

The reason why this never triggered so far with the rseq/basic_test selftest is unclear.

The current use of sched_getcpu(3) does not typically require it to be always accurate. However, use of the __rseq_abi.cpu_id field within rseq critical sections requires it to be accurate. If it is not accurate, it can cause corruption in the per-cpu data targeted by rseq critical sections in user-space.

---
 kernel/sched/core.c |    2 ++
 1 file changed, 2 insertions(+)
kernel/sched/core.c +2 -0
@@ -2876,6 +2876,7 @@ int sched_fork(unsigned long clone_flags
 	 * Silence PROVE_RCU.
 	 */
 	raw_spin_lock_irqsave(&p->pi_lock, flags);
+	rseq_migrate(p);
 	/*
 	 * We're setting the CPU for the first time, we don't migrate,
 	 * so use __set_task_cpu().
@@ -2940,6 +2941,7 @@ void wake_up_new_task(struct task_struct
 	 * as we're not fully set-up yet.
 	 */
 	p->recent_used_cpu = task_cpu(p);
+	rseq_migrate(p);
 	__set_task_cpu(p, select_task_rq(p, task_cpu(p), SD_BALANCE_FORK, 0));
 #endif
 	rq = __task_rq_lock(p, &rf);
author maintainer
#222 lore raw

PATCH 220/244 sched/fair: handle case of task_h_load() returning 0

In reply to Greg Kroah-Hartman

From: Vincent Guittot <[email protected]>

commit 01cfcde9c26d8555f0e6e9aea9d6049f87683998 upstream.

task_h_load() can return 0 in some situations like running stress-ng mmapfork, which forks thousands of threads, in a sched group on a 224 cores system. The load balance doesn't handle this correctly because env->imbalance never decreases and it will stop pulling tasks only after reaching loop_max, which can be equal to the number of running tasks of the cfs. Make sure that imbalance will be decreased by at least 1.

misfit task is the other feature that doesn't handle correctly such situation although it's probably more difficult to face the problem because of the smaller number of CPUs and running tasks on heterogenous system.

We can't simply ensure that task_h_load() returns at least one because it would imply to handle underflow in other places.

---
 kernel/sched/fair.c |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)
kernel/sched/fair.c +13 -2
@@ -4033,7 +4033,11 @@ static inline void update_misfit_status(
 		return;
 	}
 
-	rq->misfit_task_load = task_h_load(p);
+	/*
+	 * Make sure that misfit_task_load will not be null even if
+	 * task_h_load() returns 0.
+	 */
+	rq->misfit_task_load = max_t(unsigned long, task_h_load(p), 1);
 }
 
 #else /* CONFIG_SMP */
@@ -7633,7 +7637,14 @@ static int detach_tasks(struct lb_env *e
 
 		switch (env->migration_type) {
 		case migrate_load:
-			load = task_h_load(p);
+			/*
+			 * Depending of the number of CPUs and tasks and the
+			 * cgroup hierarchy, task_h_load() can return a null
+			 * value. Make sure that env->imbalance decreases
+			 * otherwise detach_tasks() will stop only after
+			 * detaching up to loop_max tasks.
+			 */
+			load = max_t(unsigned long, task_h_load(p), 1);
 
 			if (sched_feat(LB_MIN) &&
 			    load < 16 && !env->sd->nr_balance_failed)
author maintainer
#223 lore raw

PATCH 221/244 x86/ioperm: Fix io bitmap invalidation on Xen PV

In reply to Greg Kroah-Hartman

From: Andy Lutomirski <[email protected]>

commit cadfad870154e14f745ec845708bc17d166065f2 upstream.

tss_invalidate_io_bitmap() wasn't wired up properly through the pvop machinery, so the TSS and Xen's io bitmap would get out of sync whenever disabling a valid io bitmap.

Add a new pvop for tss_invalidate_io_bitmap() to fix it.

This is XSA-329.

---
 arch/x86/include/asm/io_bitmap.h      |   16 ++++++++++++++++
 arch/x86/include/asm/paravirt.h       |    5 +++++
 arch/x86/include/asm/paravirt_types.h |    1 +
 arch/x86/kernel/paravirt.c            |    3 ++-
 arch/x86/kernel/process.c             |   18 ++----------------
 arch/x86/xen/enlighten_pv.c           |   12 ++++++++++++
 6 files changed, 38 insertions(+), 17 deletions(-)
arch/x86/include/asm/io_bitmap.h +16 -0
@@ -19,12 +19,28 @@ struct task_struct;
 void io_bitmap_share(struct task_struct *tsk);
 void io_bitmap_exit(struct task_struct *tsk);
 
+static inline void native_tss_invalidate_io_bitmap(void)
+{
+	/*
+	 * Invalidate the I/O bitmap by moving io_bitmap_base outside the
+	 * TSS limit so any subsequent I/O access from user space will
+	 * trigger a #GP.
+	 *
+	 * This is correct even when VMEXIT rewrites the TSS limit
+	 * to 0x67 as the only requirement is that the base points
+	 * outside the limit.
+	 */
+	this_cpu_write(cpu_tss_rw.x86_tss.io_bitmap_base,
+		       IO_BITMAP_OFFSET_INVALID);
+}
+
 void native_tss_update_io_bitmap(void);
 
 #ifdef CONFIG_PARAVIRT_XXL
 #include <asm/paravirt.h>
 #else
 #define tss_update_io_bitmap native_tss_update_io_bitmap
+#define tss_invalidate_io_bitmap native_tss_invalidate_io_bitmap
 #endif
 
 #else
arch/x86/include/asm/paravirt.h +5 -0
@@ -296,6 +296,11 @@ static inline void write_idt_entry(gate_
 }
 
 #ifdef CONFIG_X86_IOPL_IOPERM
+static inline void tss_invalidate_io_bitmap(void)
+{
+	PVOP_VCALL0(cpu.invalidate_io_bitmap);
+}
+
 static inline void tss_update_io_bitmap(void)
 {
 	PVOP_VCALL0(cpu.update_io_bitmap);
arch/x86/include/asm/paravirt_types.h +1 -0
@@ -141,6 +141,7 @@ struct pv_cpu_ops {
 	void (*load_sp0)(unsigned long sp0);
 
 #ifdef CONFIG_X86_IOPL_IOPERM
+	void (*invalidate_io_bitmap)(void);
 	void (*update_io_bitmap)(void);
 #endif
 
arch/x86/kernel/paravirt.c +2 -1
@@ -343,7 +343,8 @@ struct paravirt_patch_template pv_ops =
 	.cpu.swapgs		= native_swapgs,
 
 #ifdef CONFIG_X86_IOPL_IOPERM
-	.cpu.update_io_bitmap	= native_tss_update_io_bitmap,
+	.cpu.invalidate_io_bitmap	= native_tss_invalidate_io_bitmap,
+	.cpu.update_io_bitmap		= native_tss_update_io_bitmap,
 #endif
 
 	.cpu.start_context_switch	= paravirt_nop,
arch/x86/kernel/process.c +2 -16
@@ -322,20 +322,6 @@ void arch_setup_new_exec(void)
 }
 
 #ifdef CONFIG_X86_IOPL_IOPERM
-static inline void tss_invalidate_io_bitmap(struct tss_struct *tss)
-{
-	/*
-	 * Invalidate the I/O bitmap by moving io_bitmap_base outside the
-	 * TSS limit so any subsequent I/O access from user space will
-	 * trigger a #GP.
-	 *
-	 * This is correct even when VMEXIT rewrites the TSS limit
-	 * to 0x67 as the only requirement is that the base points
-	 * outside the limit.
-	 */
-	tss->x86_tss.io_bitmap_base = IO_BITMAP_OFFSET_INVALID;
-}
-
 static inline void switch_to_bitmap(unsigned long tifp)
 {
 	/*
@@ -346,7 +332,7 @@ static inline void switch_to_bitmap(unsi
 	 * user mode.
 	 */
 	if (tifp & _TIF_IO_BITMAP)
-		tss_invalidate_io_bitmap(this_cpu_ptr(&cpu_tss_rw));
+		tss_invalidate_io_bitmap();
 }
 
 static void tss_copy_io_bitmap(struct tss_struct *tss, struct io_bitmap *iobm)
@@ -380,7 +366,7 @@ void native_tss_update_io_bitmap(void)
 	u16 *base = &tss->x86_tss.io_bitmap_base;
 
 	if (!test_thread_flag(TIF_IO_BITMAP)) {
-		tss_invalidate_io_bitmap(tss);
+		native_tss_invalidate_io_bitmap();
 		return;
 	}
 
arch/x86/xen/enlighten_pv.c +12 -0
@@ -841,6 +841,17 @@ static void xen_load_sp0(unsigned long s
 }
 
 #ifdef CONFIG_X86_IOPL_IOPERM
+static void xen_invalidate_io_bitmap(void)
+{
+	struct physdev_set_iobitmap iobitmap = {
+		.bitmap = 0,
+		.nr_ports = 0,
+	};
+
+	native_tss_invalidate_io_bitmap();
+	HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, &iobitmap);
+}
+
 static void xen_update_io_bitmap(void)
 {
 	struct physdev_set_iobitmap iobitmap;
@@ -1070,6 +1081,7 @@ static const struct pv_cpu_ops xen_cpu_o
 	.load_sp0 = xen_load_sp0,
 
 #ifdef CONFIG_X86_IOPL_IOPERM
+	.invalidate_io_bitmap = xen_invalidate_io_bitmap,
 	.update_io_bitmap = xen_update_io_bitmap,
 #endif
 	.io_delay = xen_io_delay,
author maintainer
#224 lore raw

PATCH 222/244 genirq/affinity: Handle affinity setting on inactive interrupts correctly

In reply to Greg Kroah-Hartman

From: Thomas Gleixner <[email protected]>

commit baedb87d1b53532f81b4bd0387f83b05d4f7eb9a upstream.

Setting interrupt affinity on inactive interrupts is inconsistent when hierarchical irq domains are enabled. The core code should just store the affinity and not call into the irq chip driver for inactive interrupts because the chip drivers may not be in a state to handle such requests.

X86 has a hacky workaround for that but all other irq chips have not which causes problems e.g. on GIC V3 ITS.

Instead of adding more ugly hacks all over the place, solve the problem in the core code. If the affinity is set on an inactive interrupt then:

- Store it in the irq descriptors affinity mask
- Update the effective affinity to reflect that so user space has a consistent view
- Don't call into the irq chip driver

This is the core equivalent of the X86 workaround and works correctly because the affinity setting is established in the irq chip when the interrupt is activated later on.

Note, that this is only effective when hierarchical irq domains are enabled by the architecture. Doing it unconditionally would break legacy irq chip implementations.

For hierarchial irq domains this works correctly as none of the drivers can have a dependency on affinity setting in inactive state by design.

Remove the X86 workaround as it is not longer required.

---
 arch/x86/kernel/apic/vector.c |   22 +++++-----------------
 kernel/irq/manage.c           |   37 +++++++++++++++++++++++++++++++++++--
 2 files changed, 40 insertions(+), 19 deletions(-)
arch/x86/kernel/apic/vector.c +5 -17
@@ -446,12 +446,10 @@ static int x86_vector_activate(struct ir
 	trace_vector_activate(irqd->irq, apicd->is_managed,
 			      apicd->can_reserve, reserve);
 
-	/* Nothing to do for fixed assigned vectors */
-	if (!apicd->can_reserve && !apicd->is_managed)
-		return 0;
-
 	raw_spin_lock_irqsave(&vector_lock, flags);
-	if (reserve || irqd_is_managed_and_shutdown(irqd))
+	if (!apicd->can_reserve && !apicd->is_managed)
+		assign_irq_vector_any_locked(irqd);
+	else if (reserve || irqd_is_managed_and_shutdown(irqd))
 		vector_assign_managed_shutdown(irqd);
 	else if (apicd->is_managed)
 		ret = activate_managed(irqd);
@@ -775,20 +773,10 @@ void lapic_offline(void)
 static int apic_set_affinity(struct irq_data *irqd,
 			     const struct cpumask *dest, bool force)
 {
-	struct apic_chip_data *apicd = apic_chip_data(irqd);
 	int err;
 
-	/*
-	 * Core code can call here for inactive interrupts. For inactive
-	 * interrupts which use managed or reservation mode there is no
-	 * point in going through the vector assignment right now as the
-	 * activation will assign a vector which fits the destination
-	 * cpumask. Let the core code store the destination mask and be
-	 * done with it.
-	 */
-	if (!irqd_is_activated(irqd) &&
-	    (apicd->is_managed || apicd->can_reserve))
-		return IRQ_SET_MASK_OK;
+	if (WARN_ON_ONCE(!irqd_is_activated(irqd)))
+		return -EIO;
 
 	raw_spin_lock(&vector_lock);
 	cpumask_and(vector_searchmask, dest, cpu_online_mask);
kernel/irq/manage.c +35 -2
@@ -195,9 +195,9 @@ void irq_set_thread_affinity(struct irq_
 			set_bit(IRQTF_AFFINITY, &action->thread_flags);
 }
 
+#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK
 static void irq_validate_effective_affinity(struct irq_data *data)
 {
-#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK
 	const struct cpumask *m = irq_data_get_effective_affinity_mask(data);
 	struct irq_chip *chip = irq_data_get_irq_chip(data);
 
@@ -205,9 +205,19 @@ static void irq_validate_effective_affin
 		return;
 	pr_warn_once("irq_chip %s did not update eff. affinity mask of irq %u\n",
 		     chip->name, data->irq);
-#endif
 }
 
+static inline void irq_init_effective_affinity(struct irq_data *data,
+					       const struct cpumask *mask)
+{
+	cpumask_copy(irq_data_get_effective_affinity_mask(data), mask);
+}
+#else
+static inline void irq_validate_effective_affinity(struct irq_data *data) { }
+static inline void irq_init_effective_affinity(struct irq_data *data,
+					       const struct cpumask *mask) { }
+#endif
+
 int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask,
 			bool force)
 {
@@ -304,6 +314,26 @@ static int irq_try_set_affinity(struct i
 	return ret;
 }
 
+static bool irq_set_affinity_deactivated(struct irq_data *data,
+					 const struct cpumask *mask, bool force)
+{
+	struct irq_desc *desc = irq_data_to_desc(data);
+
+	/*
+	 * If the interrupt is not yet activated, just store the affinity
+	 * mask and do not call the chip driver at all. On activation the
+	 * driver has to make sure anyway that the interrupt is in a
+	 * useable state so startup works.
+	 */
+	if (!IS_ENABLED(CONFIG_IRQ_DOMAIN_HIERARCHY) || irqd_is_activated(data))
+		return false;
+
+	cpumask_copy(desc->irq_common_data.affinity, mask);
+	irq_init_effective_affinity(data, mask);
+	irqd_set(data, IRQD_AFFINITY_SET);
+	return true;
+}
+
 int irq_set_affinity_locked(struct irq_data *data, const struct cpumask *mask,
 			    bool force)
 {
@@ -314,6 +344,9 @@ int irq_set_affinity_locked(struct irq_d
 	if (!chip || !chip->irq_set_affinity)
 		return -EINVAL;
 
+	if (irq_set_affinity_deactivated(data, mask, force))
+		return 0;
+
 	if (irq_can_move_pcntxt(data) && !irqd_is_setaffinity_pending(data)) {
 		ret = irq_try_set_affinity(data, mask, force);
 	} else {
author maintainer
#225 lore raw

PATCH 223/244 drm/vmwgfx: fix update of display surface when resolution changes

In reply to Greg Kroah-Hartman

From: Roland Scheidegger <[email protected]>

commit 1f054fd26e29784d373c3d29c348ee48f1c41fb2 upstream.

The assignment of metadata overwrote the new display resolution values, hence we'd miss the size actually changed and wouldn't redefine the surface. This would then lead to command buffer error when trying to update the screen target (due to the size mismatch), and result in a VM with black screen.

Fixes 504901dbb0b5 ("drm/vmwgfx: Refactor surface_define to use vmw_surface_metadata")
---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c +4 -4
@@ -1069,10 +1069,6 @@ vmw_stdu_primary_plane_prepare_fb(struct
 	if (new_content_type != SAME_AS_DISPLAY) {
 		struct vmw_surface_metadata metadata = {0};
 
-		metadata.base_size.width = hdisplay;
-		metadata.base_size.height = vdisplay;
-		metadata.base_size.depth = 1;
-
 		/*
 		 * If content buffer is a buffer object, then we have to
 		 * construct surface info
@@ -1104,6 +1100,10 @@ vmw_stdu_primary_plane_prepare_fb(struct
 			metadata = new_vfbs->surface->metadata;
 		}
 
+		metadata.base_size.width = hdisplay;
+		metadata.base_size.height = vdisplay;
+		metadata.base_size.depth = 1;
+
 		if (vps->surf) {
 			struct drm_vmw_size cur_base_size =
 				vps->surf->metadata.base_size;
author maintainer
#226 lore raw

PATCH 224/244 drm/amdgpu/powerplay: Modify SMC message name for setting power profile mode

In reply to Greg Kroah-Hartman

From: chen gong <[email protected]>

commit 98a34cf931e848f8489d3fb15a8f5fc03802ad65 upstream.

I consulted Cai Land([email protected]), he told me corresponding smc message name to fSMC_MSG_SetWorkloadMask() is "PPSMC_MSG_ActiveProcessNotify" in firmware code of Renoir.

Strange though it may seem, but it's a fact.

---
 drivers/gpu/drm/amd/powerplay/renoir_ppt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/powerplay/renoir_ppt.c +1 -1
@@ -687,7 +687,7 @@ static int renoir_set_power_profile_mode
 		return -EINVAL;
 	}
 
-	ret = smu_send_smc_msg_with_param(smu, SMU_MSG_SetWorkloadMask,
+	ret = smu_send_smc_msg_with_param(smu, SMU_MSG_ActiveProcessNotify,
 				    1 << workload_type,
 				    NULL);
 	if (ret) {
author maintainer
#227 lore raw

PATCH 225/244 drm/amdgpu/sdma5: fix wptr overwritten in ->get_wptr()

In reply to Greg Kroah-Hartman

From: Xiaojie Yuan <[email protected]>

commit 05051496b2622e4d12e2036b35165969aa502f89 upstream.

"u64 *wptr" points to the the wptr value in write back buffer and "*wptr = (*wptr) >> 2;" results in the value being overwritten each time when ->get_wptr() is called.

umr uses /sys/kernel/debug/dri/0/amdgpu_ring_sdma0 to get rptr/wptr and decode ring content and it is affected by this issue.

fix and simplify the logic similar as sdma_v4_0_ring_get_wptr().

v2: fix for sdma5.2 as well
v3: drop sdma 5.2 changes for 5.8 and stable

---
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |   26 ++++++++------------------
 1 file changed, 8 insertions(+), 18 deletions(-)
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c +8 -18
@@ -286,30 +286,20 @@ static uint64_t sdma_v5_0_ring_get_rptr(
 static uint64_t sdma_v5_0_ring_get_wptr(struct amdgpu_ring *ring)
 {
 	struct amdgpu_device *adev = ring->adev;
-	u64 *wptr = NULL;
-	uint64_t local_wptr = 0;
+	u64 wptr;
 
 	if (ring->use_doorbell) {
 		/* XXX check if swapping is necessary on BE */
-		wptr = ((u64 *)&adev->wb.wb[ring->wptr_offs]);
-		DRM_DEBUG("wptr/doorbell before shift == 0x%016llx\n", *wptr);
-		*wptr = (*wptr) >> 2;
-		DRM_DEBUG("wptr/doorbell after shift == 0x%016llx\n", *wptr);
+		wptr = READ_ONCE(*((u64 *)&adev->wb.wb[ring->wptr_offs]));
+		DRM_DEBUG("wptr/doorbell before shift == 0x%016llx\n", wptr);
 	} else {
-		u32 lowbit, highbit;
-
-		wptr = &local_wptr;
-		lowbit = RREG32(sdma_v5_0_get_reg_offset(adev, ring->me, mmSDMA0_GFX_RB_WPTR)) >> 2;
-		highbit = RREG32(sdma_v5_0_get_reg_offset(adev, ring->me, mmSDMA0_GFX_RB_WPTR_HI)) >> 2;
-
-		DRM_DEBUG("wptr [%i]high== 0x%08x low==0x%08x\n",
-				ring->me, highbit, lowbit);
-		*wptr = highbit;
-		*wptr = (*wptr) << 32;
-		*wptr |= lowbit;
+		wptr = RREG32(sdma_v5_0_get_reg_offset(adev, ring->me, mmSDMA0_GFX_RB_WPTR_HI));
+		wptr = wptr << 32;
+		wptr |= RREG32(sdma_v5_0_get_reg_offset(adev, ring->me, mmSDMA0_GFX_RB_WPTR));
+		DRM_DEBUG("wptr before shift [%i] wptr == 0x%016llx\n", ring->me, wptr);
 	}
 
-	return *wptr;
+	return wptr >> 2;
 }
 
 /**
author maintainer
#228 lore raw

PATCH 226/244 drm/amd/display: handle failed allocation during stream construction

In reply to Greg Kroah-Hartman

From: Josip Pavic <[email protected]>

commit be73e608ae2711dc8a1ab8b9549d9e348061b2ee upstream.

[Why]
Failing to allocate a transfer function during stream construction leads to a null pointer dereference

[How]
Handle the failed allocation by failing the stream construction

---
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c |   19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/display/dc/core/dc_stream.c +16 -3
@@ -56,7 +56,7 @@ void update_stream_signal(struct dc_stre
 	}
 }
 
-static void dc_stream_construct(struct dc_stream_state *stream,
+static bool dc_stream_construct(struct dc_stream_state *stream,
 	struct dc_sink *dc_sink_data)
 {
 	uint32_t i = 0;
@@ -118,11 +118,17 @@ static void dc_stream_construct(struct d
 	update_stream_signal(stream, dc_sink_data);
 
 	stream->out_transfer_func = dc_create_transfer_func();
+	if (stream->out_transfer_func == NULL) {
+		dc_sink_release(dc_sink_data);
+		return false;
+	}
 	stream->out_transfer_func->type = TF_TYPE_BYPASS;
 	stream->out_transfer_func->ctx = stream->ctx;
 
 	stream->stream_id = stream->ctx->dc_stream_id_count;
 	stream->ctx->dc_stream_id_count++;
+
+	return true;
 }
 
 static void dc_stream_destruct(struct dc_stream_state *stream)
@@ -164,13 +170,20 @@ struct dc_stream_state *dc_create_stream
 
 	stream = kzalloc(sizeof(struct dc_stream_state), GFP_KERNEL);
 	if (stream == NULL)
-		return NULL;
+		goto alloc_fail;
 
-	dc_stream_construct(stream, sink);
+	if (dc_stream_construct(stream, sink) == false)
+		goto construct_fail;
 
 	kref_init(&stream->refcount);
 
 	return stream;
+
+construct_fail:
+	kfree(stream);
+
+alloc_fail:
+	return NULL;
 }
 
 struct dc_stream_state *dc_copy_stream(const struct dc_stream_state *stream)
author maintainer
#229 lore raw

PATCH 227/244 drm/amd/display: OLED panel backlight adjust not work with external display connected

In reply to Greg Kroah-Hartman

From: hersen wu <[email protected]>

commit b448d30b0c303d5454ea572b772d1ffae96bc6e7 upstream.

[Why]
amdgpu_dm->backlight_caps is for single eDP only. the caps are upddated for very connector. Real eDP caps will be overwritten by other external display. For OLED panel, caps->aux_support is set to 1 for OLED pnael. after external connected, caps+.aux_support is set to 0. This causes OLED backlight adjustment not work.

[How]
within update_conector_ext_caps, backlight caps will be updated only for eDP connector.

---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +5 -0
@@ -1804,6 +1804,7 @@ static void update_connector_ext_caps(st
 	struct amdgpu_display_manager *dm;
 	struct drm_connector *conn_base;
 	struct amdgpu_device *adev;
+	struct dc_link *link = NULL;
 	static const u8 pre_computed_values[] = {
 		50, 51, 52, 53, 55, 56, 57, 58, 59, 61, 62, 63, 65, 66, 68, 69,
 		71, 72, 74, 75, 77, 79, 81, 82, 84, 86, 88, 90, 92, 94, 96, 98};
@@ -1811,6 +1812,10 @@ static void update_connector_ext_caps(st
 	if (!aconnector || !aconnector->dc_link)
 		return;
 
+	link = aconnector->dc_link;
+	if (link->connector_signal != SIGNAL_TYPE_EDP)
+		return;
+
 	conn_base = &aconnector->base;
 	adev = conn_base->dev->dev_private;
 	dm = &adev->dm;
author maintainer
#230 lore raw

PATCH 228/244 drm/amdgpu/display: create fake mst encoders ahead of time (v4)

In reply to Greg Kroah-Hartman

From: Alex Deucher <[email protected]>

commit 3168470142e0a82b5732c04ed4c031a9322ae170 upstream.

Prevents a warning in the MST create connector case.

v2: create global fake encoders rather per connector fake encoders to avoid running out of encoder indices.

v3: use the actual number of crtcs on the asic rather than the max to conserve encoders.

v4: v3 plus missing hunk I forgot to git add.

Fixes c6385e503aeaf9 ("drm/amdgpu: drop legacy drm load and unload callbacks")
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c           |    9 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h           |   11 ++
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c |   57 +++++-------
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h |    3 
 4 files changed, 50 insertions(+), 30 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +9 -0
@@ -956,6 +956,9 @@ static int amdgpu_dm_init(struct amdgpu_
 	/* Update the actual used number of crtc */
 	adev->mode_info.num_crtc = adev->dm.display_indexes_num;
 
+	/* create fake encoders for MST */
+	dm_dp_create_fake_mst_encoders(adev);
+
 	/* TODO: Add_display_info? */
 
 	/* TODO use dynamic cursor width */
@@ -979,6 +982,12 @@ error:
 
 static void amdgpu_dm_fini(struct amdgpu_device *adev)
 {
+	int i;
+
+	for (i = 0; i < adev->dm.display_indexes_num; i++) {
+		drm_encoder_cleanup(&adev->dm.mst_encoders[i].base);
+	}
+
 	amdgpu_dm_audio_fini(adev);
 
 	amdgpu_dm_destroy_drm_device(&adev->dm);
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h +10 -1
@@ -43,6 +43,9 @@
  */
 
 #define AMDGPU_DM_MAX_DISPLAY_INDEX 31
+
+#define AMDGPU_DM_MAX_CRTC 6
+
 /*
 #include "include/amdgpu_dal_power_if.h"
 #include "amdgpu_dm_irq.h"
@@ -327,6 +330,13 @@ struct amdgpu_display_manager {
 	 * available in FW
 	 */
 	const struct gpu_info_soc_bounding_box_v1_0 *soc_bounding_box;
+
+	/**
+	 * @mst_encoders:
+	 *
+	 * fake encoders used for DP MST.
+	 */
+	struct amdgpu_encoder mst_encoders[AMDGPU_DM_MAX_CRTC];
 };
 
 struct amdgpu_dm_connector {
@@ -355,7 +365,6 @@ struct amdgpu_dm_connector {
 	struct amdgpu_dm_dp_aux dm_dp_aux;
 	struct drm_dp_mst_port *port;
 	struct amdgpu_dm_connector *mst_port;
-	struct amdgpu_encoder *mst_encoder;
 	struct drm_dp_aux *dsc_aux;
 
 	/* TODO see if we can merge with ddc_bus or make a dm_connector */
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +28 -29

94 lines not on this page · raw message

drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h +3 -0
@@ -35,6 +35,9 @@ void amdgpu_dm_initialize_dp_connector(s
 				       struct amdgpu_dm_connector *aconnector,
 				       int link_index);
 
+void
+dm_dp_create_fake_mst_encoders(struct amdgpu_device *adev);
+
 #if defined(CONFIG_DRM_AMD_DC_DCN)
 bool compute_mst_dsc_configs_for_state(struct drm_atomic_state *state,
 				       struct dc_state *dc_state);
author maintainer
#231 lore raw

PATCH 229/244 drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.

In reply to Greg Kroah-Hartman

From: Maarten Lankhorst <[email protected]>

commit 6647e6cdba753e71170be7da2acfead7154f56d8 upstream.

This fixes the following KASAN splash on module reload:

[  145.136327] ==================================================================
[  145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134
[  145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G     U          T 5.5.0-rc7-valkyria+ #5783
[  145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016
[  145.136546] Workqueue: events drm_connector_free_work_fn
[  145.136551] Call Trace:
[  145.136560]  dump_stack+0xa1/0xe0
[  145.136571]  print_address_description.constprop.0+0x1e/0x210
[  145.136639]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136703]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136710]  __kasan_report.cold+0x1b/0x37
[  145.136790]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136863]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136870]  kasan_report+0x27/0x30
[  145.136881]  __asan_report_load8_noabort+0x1c/0x20
[  145.136946]  intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136954]  drm_connector_free_work_fn+0xd1/0x100
[  145.136967]  process_one_work+0x86e/0x1610
[  145.136987]  ? pwq_dec_nr_in_flight+0x2f0/0x2f0
[  145.137004]  ? move_linked_works+0x128/0x2c0
[  145.137021]  worker_thread+0x63e/0xc90
[  145.137048]  kthread+0x2f6/0x3f0
[  145.137054]  ? calculate_sigpending+0x81/0xa0
[  145.137059]  ? process_one_work+0x1610/0x1610
[  145.137064]  ? kthread_bind+0x40/0x40
[  145.137075]  ret_from_fork+0x24/0x30
[  145.137111] Allocated by task 0:
[  145.137119] (stack is not available)
[  145.137137] Freed by task 5053:
[  145.137147]  save_stack+0x28/0x90
[  145.137152]  __kasan_slab_free+0x136/0x180
[  145.137157]  kasan_slab_free+0x26/0x30
[  145.137161]  kfree+0xe6/0x350
[  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
[  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
[  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
[  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
[  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
[  145.137489]  pci_device_remove+0x108/0x2d0
[  145.137494]  device_release_driver_internal+0x1e6/0x4a0
[  145.137499]  driver_detach+0xcb/0x198
[  145.137503]  bus_remove_driver+0xde/0x204
[  145.137508]  driver_unregister+0x6d/0xa0
[  145.137513]  pci_unregister_driver+0x2e/0x230
[  145.137576]  i915_exit+0x1f/0x26 [i915]
[  145.137157]  kasan_slab_free+0x26/0x30
[  145.137161]  kfree+0xe6/0x350
[  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
[  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
[  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
[  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
[  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
[  145.137489]  pci_device_remove+0x108/0x2d0
[  145.137494]  device_release_driver_internal+0x1e6/0x4a0
[  145.137499]  driver_detach+0xcb/0x198
[  145.137503]  bus_remove_driver+0xde/0x204
[  145.137508]  driver_unregister+0x6d/0xa0
[  145.137513]  pci_unregister_driver+0x2e/0x230
[  145.137576]  i915_exit+0x1f/0x26 [i915]
[  145.137581]  __x64_sys_delete_module+0x35b/0x470
[  145.137586]  do_syscall_64+0x99/0x4e0
[  145.137591]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  145.137606] The buggy address belongs to the object at ffff888216640000
                which belongs to the cache kmalloc-8k of size 8192
[  145.137618] The buggy address is located 6192 bytes inside of
                8192-byte region [ffff888216640000, ffff888216642000)
[  145.137630] The buggy address belongs to the page:
[  145.137640] page:ffffea0008599000 refcount:1 mapcount:0 mapping:ffff888107c02a80 index:0xffff888216644000 compound_mapcount: 0
[  145.137647] raw: 0200000000010200 0000000000000000 0000000100000001 ffff888107c02a80
[  145.137652] raw: ffff888216644000 0000000080020001 00000001ffffffff 0000000000000000
[  145.137656] page dumped because: kasan: bad access detected
[  145.137668] Memory state around the buggy address:
[  145.137678]  ffff888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137687]  ffff888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137697] >ffff888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137706]                                      ^
[  145.137715]  ffff888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137724]  ffff888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137733] ==================================================================
[  145.137742] Disabling lock debugging due to kernel taint

Changes since v1:
- Add fixes tags.
- Use early unregister.

Fixes 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi")
Cc <[email protected]> # v4.19+
(cherry picked from commit a581483b1e5466d28fc50ff623fba31cea2cccb6)
---
 drivers/gpu/drm/i915/display/intel_hdmi.c |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)
drivers/gpu/drm/i915/display/intel_hdmi.c +2 -8
@@ -2821,19 +2821,13 @@ intel_hdmi_connector_register(struct drm
 	return ret;
 }
 
-static void intel_hdmi_destroy(struct drm_connector *connector)
+static void intel_hdmi_connector_unregister(struct drm_connector *connector)
 {
 	struct cec_notifier *n = intel_attached_hdmi(to_intel_connector(connector))->cec_notifier;
 
 	cec_notifier_conn_unregister(n);
 
-	intel_connector_destroy(connector);
-}
-
-static void intel_hdmi_connector_unregister(struct drm_connector *connector)
-{
 	intel_hdmi_remove_i2c_symlink(connector);
-
 	intel_connector_unregister(connector);
 }
 
@@ -2845,7 +2839,7 @@ static const struct drm_connector_funcs
 	.atomic_set_property = intel_digital_connector_atomic_set_property,
 	.late_register = intel_hdmi_connector_register,
 	.early_unregister = intel_hdmi_connector_unregister,
-	.destroy = intel_hdmi_destroy,
+	.destroy = intel_connector_destroy,
 	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 	.atomic_duplicate_state = intel_digital_connector_duplicate_state,
 };
author maintainer
#232 lore raw

PATCH 230/244 drm/i915/gt: Ignore irq enabling on the virtual engines

In reply to Greg Kroah-Hartman

From: Chris Wilson <[email protected]>

commit 858f1299fd6f7518ddef19ddd304c8398ac79fa5 upstream.

We do not use the virtual engines for interrupts (they have physical components), but we do use them to decouple the fence signaling during submission. Currently, when we submit a completed request, we try to enable the interrupt handler for the virtual engine, but we never disarm it. A quick fix is then to mark the irq as enabled, and it will then remain enabled -- and this prevents us from waking the device and never letting it sleep again.

Fixes f8db4d051b5e ("drm/i915: Initialise breadcrumb lists on the virtual engine")
Cc Mika Kuoppala <[email protected]>
Cc Tvrtko Ursulin <[email protected]>
Cc <[email protected]> # v5.5+
(cherry picked from commit 4fe6abb8f51355224808ab02a9febf65d184c40b)
---
 drivers/gpu/drm/i915/gt/intel_lrc.c |    1 +
 1 file changed, 1 insertion(+)
drivers/gpu/drm/i915/gt/intel_lrc.c +1 -0
@@ -5188,6 +5188,7 @@ intel_execlists_create_virtual(struct in
 	intel_engine_init_active(&ve->base, ENGINE_VIRTUAL);
 	intel_engine_init_breadcrumbs(&ve->base);
 	intel_engine_init_execlists(&ve->base);
+	ve->base.breadcrumbs.irq_armed = true; /* fake HW, used for irq_work */
 
 	ve->base.cops = &virtual_context_ops;
 	ve->base.request_alloc = execlists_request_alloc;
author maintainer
#233 lore raw

PATCH 231/244 drm/i915/gt: Only swap to a random sibling once upon creation

In reply to Greg Kroah-Hartman

From: Chris Wilson <[email protected]>

commit 110f9efa858f584c6bed177cd48d0c0f526940e1 upstream.

The danger in switching at random upon intel_context_pin is that the context may still actually be inflight, as it will not be scheduled out until a context switch after it is complete -- that may be a long time after we do a final intel_context_unpin.

Fixes 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Cc Tvrtko Ursulin <[email protected]>
Cc <[email protected]> # v5.3+
(cherry picked from commit 90a987205c6cf74116a102ed446d22d92cdaf915)
---
 drivers/gpu/drm/i915/gt/intel_lrc.c |   18 ++++--------------
 1 file changed, 4 insertions(+), 14 deletions(-)
drivers/gpu/drm/i915/gt/intel_lrc.c +4 -14
@@ -4897,13 +4897,8 @@ static void virtual_engine_initial_hint(
 	 * typically be the first we inspect for submission.
 	 */
 	swp = prandom_u32_max(ve->num_siblings);
-	if (!swp)
-		return;
-
-	swap(ve->siblings[swp], ve->siblings[0]);
-	if (!intel_engine_has_relative_mmio(ve->siblings[0]))
-		virtual_update_register_offsets(ve->context.lrc_reg_state,
-						ve->siblings[0]);
+	if (swp)
+		swap(ve->siblings[swp], ve->siblings[0]);
 }
 
 static int virtual_context_alloc(struct intel_context *ce)
@@ -4916,15 +4911,9 @@ static int virtual_context_alloc(struct
 static int virtual_context_pin(struct intel_context *ce)
 {
 	struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
-	int err;
 
 	/* Note: we must use a real engine class for setting up reg state */
-	err = __execlists_context_pin(ce, ve->siblings[0]);
-	if (err)
-		return err;
-
-	virtual_engine_initial_hint(ve);
-	return 0;
+	return __execlists_context_pin(ce, ve->siblings[0]);
 }
 
 static void virtual_context_enter(struct intel_context *ce)
@@ -5270,6 +5259,7 @@ intel_execlists_create_virtual(struct in
 
 	ve->base.flags |= I915_ENGINE_IS_VIRTUAL;
 
+	virtual_engine_initial_hint(ve);
 	return &ve->context;
 
 err_put:
author maintainer
#234 lore raw

PATCH 232/244 libceph: dont omit recovery_deletes in target_copy()

In reply to Greg Kroah-Hartman

From: Ilya Dryomov <[email protected]>

commit 2f3fead62144002557f322c2a7c15e1255df0653 upstream.

Currently target_copy() is used only for sending linger pings, so this doesn't come up, but generally omitting recovery_deletes can result in unneeded resends (force_resend in calc_target()).

Fixes ae78dd8139ce ("libceph: make RECOVERY_DELETES feature create a new interval")
---
 net/ceph/osd_client.c |    1 +
 1 file changed, 1 insertion(+)
net/ceph/osd_client.c +1 -0
@@ -445,6 +445,7 @@ static void target_copy(struct ceph_osd_
 	dest->size = src->size;
 	dest->min_size = src->min_size;
 	dest->sort_bitwise = src->sort_bitwise;
+	dest->recovery_deletes = src->recovery_deletes;
 
 	dest->flags = src->flags;
 	dest->paused = src->paused;
author maintainer
#235 lore raw

PATCH 233/244 RISC-V: Acquire mmap lock before invoking walk_page_range

In reply to Greg Kroah-Hartman

From: Atish Patra <[email protected]>

commit 0e2c09011d4de4161f615ff860a605a9186cf62a upstream.

As per walk_page_range documentation, mmap lock should be acquired by the caller before invoking walk_page_range. mmap_assert_locked gets triggered without that. The details can be found here.

http://lists.infradead.org/pipermail/linux-riscv/2020-June/010335.html

Fixes 395a21ff859c(riscv: add ARCH_HAS_SET_DIRECT_MAP support)
---
 arch/riscv/mm/pageattr.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
arch/riscv/mm/pageattr.c +12 -2
@@ -151,6 +151,7 @@ int set_memory_nx(unsigned long addr, in
 
 int set_direct_map_invalid_noflush(struct page *page)
 {
+	int ret;
 	unsigned long start = (unsigned long)page_address(page);
 	unsigned long end = start + PAGE_SIZE;
 	struct pageattr_masks masks = {
@@ -158,11 +159,16 @@ int set_direct_map_invalid_noflush(struc
 		.clear_mask = __pgprot(_PAGE_PRESENT)
 	};
 
-	return walk_page_range(&init_mm, start, end, &pageattr_ops, &masks);
+	mmap_read_lock(&init_mm);
+	ret = walk_page_range(&init_mm, start, end, &pageattr_ops, &masks);
+	mmap_read_unlock(&init_mm);
+
+	return ret;
 }
 
 int set_direct_map_default_noflush(struct page *page)
 {
+	int ret;
 	unsigned long start = (unsigned long)page_address(page);
 	unsigned long end = start + PAGE_SIZE;
 	struct pageattr_masks masks = {
@@ -170,7 +176,11 @@ int set_direct_map_default_noflush(struc
 		.clear_mask = __pgprot(0)
 	};
 
-	return walk_page_range(&init_mm, start, end, &pageattr_ops, &masks);
+	mmap_read_lock(&init_mm);
+	ret = walk_page_range(&init_mm, start, end, &pageattr_ops, &masks);
+	mmap_read_unlock(&init_mm);
+
+	return ret;
 }
 
 void __kernel_map_pages(struct page *page, int numpages, int enable)
#236 lore raw

Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page_range

RISC-V build breaks on stable-rc 5.7 branch.
build failed with gcc-8, gcc-9 and gcc-9.

Quoted 33 lines · Greg Kroah-Hartman

From: Atish Patra <[email protected]>

commit 0e2c09011d4de4161f615ff860a605a9186cf62a upstream.

As per walk_page_range documentation, mmap lock should be acquired by the caller before invoking walk_page_range. mmap_assert_locked gets triggered without that. The details can be found here.

http://lists.infradead.org/pipermail/linux-riscv/2020-June/010335.html

Fixes 395a21ff859c(riscv: add ARCH_HAS_SET_DIRECT_MAP support)
---
 arch/riscv/mm/pageattr.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
arch/riscv/mm/pageattr.c +1 -0
@@ -151,6 +151,7 @@ int set_memory_nx(unsigned long addr, in
 
 int set_direct_map_invalid_noflush(struct page *page)
 {
+       int ret;
        unsigned long start = (unsigned long)page_address(page);
        unsigned long end = start + PAGE_SIZE;
        struct pageattr_masks masks = {

arch/riscv/mm/pageattr.c int set_direct_map_invalid_noflush(struc · line 164

Quoted 7 lines
arch/riscv/mm/pageattr.c +3 -1
@@ -158,11 +159,16 @@ int set_direct_map_invalid_noflush(struc
                .clear_mask = __pgprot(_PAGE_PRESENT)
        };
 
-       return walk_page_range(&init_mm, start, end, &pageattr_ops, &masks);
+       mmap_read_lock(&init_mm);
+       ret = walk_page_range(&init_mm, start, end, &pageattr_ops, &masks);
+       mmap_read_unlock(&init_mm);

make -sk KBUILD_BUILD_USER=TuxBuild -C/linux ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- HOSTCC=gcc CC="sccache riscv64-linux-gnu-gcc" O=build defconfig
#
#
make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j32 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- HOSTCC=gcc CC="sccache riscv64-linux-gnu-gcc" O=build
#
../arch/riscv/mm/pageattr.c: In function ‘set_direct_map_invalid_noflush’:
../arch/riscv/mm/pageattr.c:162:2: error: implicit declaration of function ‘mmap_read_lock’; did you mean ‘_raw_read_lock’? [-Werror=implicit-function-declaration]

  162 |  mmap_read_lock(&init_mm);
      |  ^~~~~~~~~~~~~~
      |  _raw_read_lock
../arch/riscv/mm/pageattr.c:164:2: error: implicit declaration of
function ‘mmap_read_unlock’; did you mean ‘_raw_read_unlock’?
[-Werror=implicit-function-declaration]
  164 |  mmap_read_unlock(&init_mm);
      |  ^~~~~~~~~~~~~~~~
      |  _raw_read_unlock

cc1: some warnings being treated as errors

Quoted 14 lines
arch/riscv/mm/pageattr.c +3 -0
+
+       return ret;
 }
 
 int set_direct_map_default_noflush(struct page *page)
 {
+       int ret;
        unsigned long start = (unsigned long)page_address(page);
        unsigned long end = start + PAGE_SIZE;
        struct pageattr_masks masks = {
@@ -170,7 +176,11 @@ int set_direct_map_default_noflush(struc
                .clear_mask = __pgprot(0)
        };

arch/riscv/mm/pageattr.c int set_direct_map_default_noflush(struc · line 186

Quoted 10 lines
arch/riscv/mm/pageattr.c +5 -1
 
-       return walk_page_range(&init_mm, start, end, &pageattr_ops, &masks);
+       mmap_read_lock(&init_mm);
+       ret = walk_page_range(&init_mm, start, end, &pageattr_ops, &masks);
+       mmap_read_unlock(&init_mm);
+
+       return ret;
 }
 
 void __kernel_map_pages(struct page *page, int numpages, int enable)

ref:
full build log with default config.
https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/647154950

Signature · 2 lines
Linaro LKFT
https://lkft.linaro.org
#237 lore raw

Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page_range

Quoted 3 lines · Naresh Kamboju

RISC-V build breaks on stable-rc 5.7 branch.
build failed with gcc-8, gcc-9 and gcc-9.

Sorry for the compilation issue.

mmap_read_lock was intrdouced in the following commit.

commit 9740ca4e95b4

Author: Michel Lespinasse <[email protected]>
Date:   Mon Jun 8 21:33:14 2020 -0700

mmap locking API: initial implementation as rwsem wrappers

The following two commits replaced the usage of mmap_sem rwsem calls with mmap_lock.

d8ed45c5dcd4 (mmap locking API: use coccinelle to convert mmap_sem rwsem call sites)
89154dd5313f (mmap locking API: convert mmap_sem call sites missed by coccinelle)

The first commit is not present in stale 5.7-y for obvious reasons.

Do we need to send a separate patch only for stable branch with mmap_sem ? I am not sure if that will cause a conflict again in future.

Quoted 103 lines
Quoted 34 lines · Greg Kroah-Hartman

From: Atish Patra <[email protected]>

commit 0e2c09011d4de4161f615ff860a605a9186cf62a upstream.

As per walk_page_range documentation, mmap lock should be acquired by the
caller before invoking walk_page_range. mmap_assert_locked gets triggered
without that. The details can be found here.

http://lists.infradead.org/pipermail/linux-riscv/2020-June/010335.html

Fixes 395a21ff859c(riscv: add ARCH_HAS_SET_DIRECT_MAP support)
---
 arch/riscv/mm/pageattr.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
arch/riscv/mm/pageattr.c +1 -0
@@ -151,6 +151,7 @@ int set_memory_nx(unsigned long addr, in
 
 int set_direct_map_invalid_noflush(struct page *page)
 {
+       int ret;
        unsigned long start = (unsigned long)page_address(page);
        unsigned long end = start + PAGE_SIZE;
        struct pageattr_masks masks = {

arch/riscv/mm/pageattr.c int set_direct_map_invalid_noflush(struc · line 166

Quoted 9 lines
arch/riscv/mm/pageattr.c +3 -1
@@ -158,11 +159,16 @@ int set_direct_map_invalid_noflush(struc
                .clear_mask = __pgprot(_PAGE_PRESENT)
        };
 
-       return walk_page_range(&init_mm, start, end, &pageattr_ops,
 &masks);
+       mmap_read_lock(&init_mm);
+       ret = walk_page_range(&init_mm, start, end, &pageattr_ops,
 &masks);
+       mmap_read_unlock(&init_mm);

make -sk KBUILD_BUILD_USER=TuxBuild -C/linux ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- HOSTCC=gcc CC="sccache riscv64-linux-gnu-gcc" O=build defconfig
#
#
make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j32 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- HOSTCC=gcc CC="sccache riscv64-linux-gnu-gcc" O=build
#
../arch/riscv/mm/pageattr.c: In function ‘set_direct_map_invalid_noflush’:
../arch/riscv/mm/pageattr.c:162:2: error: implicit declaration of function ‘mmap_read_lock’; did you mean ‘_raw_read_lock’? [-Werror=implicit-function-declaration]

  162 |  mmap_read_lock(&init_mm);
      |  ^~~~~~~~~~~~~~
      |  _raw_read_lock
../arch/riscv/mm/pageattr.c:164:2: error: implicit declaration of
function ‘mmap_read_unlock’; did you mean ‘_raw_read_unlock’?
[-Werror=implicit-function-declaration]
  164 |  mmap_read_unlock(&init_mm);
      |  ^~~~~~~~~~~~~~~~
      |  _raw_read_unlock

cc1: some warnings being treated as errors

Quoted 24 lines
arch/riscv/mm/pageattr.c +3 -0
+
+       return ret;
 }
 
 int set_direct_map_default_noflush(struct page *page)
 {
+       int ret;
        unsigned long start = (unsigned long)page_address(page);
        unsigned long end = start + PAGE_SIZE;
        struct pageattr_masks masks = {
arch/riscv/mm/pageattr.c +5 -1
@@ -170,7 +176,11 @@ int set_direct_map_default_noflush(struc
                .clear_mask = __pgprot(0)
        };
 
-       return walk_page_range(&init_mm, start, end, &pageattr_ops,
 &masks);
+       mmap_read_lock(&init_mm);
+       ret = walk_page_range(&init_mm, start, end, &pageattr_ops,
 &masks);
+       mmap_read_unlock(&init_mm);
+
+       return ret;
 }
Quoted 3 lines

void __kernel_map_pages(struct page *page, int numpages, int
enable)

ref:
full build log with default config.
https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/647154950

Signature · 2 lines
Regards,
Atish
author maintainer
#238 lore raw

Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page_range

Quoted 23 lines · Atish Patra
Quoted 3 lines · Naresh Kamboju

RISC-V build breaks on stable-rc 5.7 branch.
build failed with gcc-8, gcc-9 and gcc-9.

Sorry for the compilation issue.

mmap_read_lock was intrdouced in the following commit.

commit 9740ca4e95b4

Author: Michel Lespinasse <[email protected]>
Date:   Mon Jun 8 21:33:14 2020 -0700

mmap locking API: initial implementation as rwsem wrappers

The following two commits replaced the usage of mmap_sem rwsem calls with mmap_lock.

d8ed45c5dcd4 (mmap locking API: use coccinelle to convert mmap_sem rwsem call sites)
89154dd5313f (mmap locking API: convert mmap_sem call sites missed by coccinelle)

Quoted 4 lines

The first commit is not present in stale 5.7-y for obvious reasons.

Do we need to send a separate patch only for stable branch with mmap_sem ? I am not sure if that will cause a conflict again in future.

I do not like taking odd backports, and would rather take the real patch that is upstream.

I will drop this patch from the tree now, so everyone can figure out what they want to do in the future :)

thanks,

greg k-h

#239 lore raw

Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page_range

Quoted 24 lines · Greg KH
Quoted 23 lines · Atish Patra
Quoted 3 lines · Naresh Kamboju

RISC-V build breaks on stable-rc 5.7 branch.
build failed with gcc-8, gcc-9 and gcc-9.

Sorry for the compilation issue.

mmap_read_lock was intrdouced in the following commit.

commit 9740ca4e95b4

Author: Michel Lespinasse <[email protected]>
Date:   Mon Jun 8 21:33:14 2020 -0700

mmap locking API: initial implementation as rwsem wrappers

The following two commits replaced the usage of mmap_sem rwsem calls with mmap_lock.

d8ed45c5dcd4 (mmap locking API: use coccinelle to convert mmap_sem rwsem call sites)
89154dd5313f (mmap locking API: convert mmap_sem call sites missed by coccinelle)

Quoted 7 lines
Quoted 4 lines

The first commit is not present in stale 5.7-y for obvious reasons.

Do we need to send a separate patch only for stable branch with mmap_sem ? I am not sure if that will cause a conflict again in future.

I do not like taking odd backports, and would rather take the real patch that is upstream.

I guess I'm a bit new to stable backports so I'm not sure what's expected here. The failing patch fixes a bug by using a new interface. The smallest diff fix for the stable kernels would be to construct a similar fix without the new interface, which in this case is very easy as the new interface just converted some generic locking calls to one-line functions. It seems somewhat circuitous to land that in Linus' tree, though, as it would require breaking our port before fixing it to use the old interfaces and then cleaning it up to use the new interfaces.

Are we expected to pull the new interface onto stable in addition to this fix? The new interface doesn't actually fix anything itself, but it would allow a functional kernel to be constructed that consisted of only backports from Linus' tree (which would also make further fixes easier). It seems safe to just pull in 9740ca4e95b4 ("mmap locking API: initial implementation as rwsem wrappers") before this failing patch, as in this case the new interface will function correctly with only a subset of callers having been converted. Of course that's not a generally true statement so I don't know if future code will behave that way, but pulling in those conversion patches is definitely unnecessary diff right now.

Quoted 2 lines

I will drop this patch from the tree now, so everyone can figure out what they want to do in the future :)

That certainly seems like the right way to go for now, thanks!

author maintainer
#240 lore raw

Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page_range

Quoted 42 lines · Palmer Dabbelt
Quoted 24 lines · Greg KH
Quoted 23 lines · Atish Patra
Quoted 3 lines · Naresh Kamboju

RISC-V build breaks on stable-rc 5.7 branch.
build failed with gcc-8, gcc-9 and gcc-9.

Sorry for the compilation issue.

mmap_read_lock was intrdouced in the following commit.

commit 9740ca4e95b4

Author: Michel Lespinasse <[email protected]>
Date:   Mon Jun 8 21:33:14 2020 -0700

mmap locking API: initial implementation as rwsem wrappers

The following two commits replaced the usage of mmap_sem rwsem calls with mmap_lock.

d8ed45c5dcd4 (mmap locking API: use coccinelle to convert mmap_sem rwsem call sites)
89154dd5313f (mmap locking API: convert mmap_sem call sites missed by coccinelle)

Quoted 7 lines
Quoted 4 lines

The first commit is not present in stale 5.7-y for obvious reasons.

Do we need to send a separate patch only for stable branch with mmap_sem ? I am not sure if that will cause a conflict again in future.

I do not like taking odd backports, and would rather take the real patch that is upstream.

I guess I'm a bit new to stable backports so I'm not sure what's expected here. The failing patch fixes a bug by using a new interface. The smallest diff fix for the stable kernels would be to construct a similar fix without the new interface, which in this case is very easy as the new interface just converted some generic locking calls to one-line functions. It seems somewhat circuitous to land that in Linus' tree, though, as it would require breaking our port before fixing it to use the old interfaces and then cleaning it up to use the new interfaces.

Quoted 1 line

Are we expected to pull the new interface onto stable in addition to this fix?

If it really does fix a big issue, yes, that is fine to do.

Quoted 3 lines

The new interface doesn't actually fix anything itself, but it would allow a functional kernel to be constructed that consisted of only backports from Linus' tree (which would also make further fixes easier).

That's fine.

Quoted 7 lines

It seems safe to
just pull in 9740ca4e95b4 ("mmap locking API: initial implementation as rwsem wrappers") before this failing patch, as in this case the new interface will function correctly with only a subset of callers having been converted. Of course that's not a generally true statement so I don't know if future code will behave that way, but pulling in those conversion patches is definitely unnecessary diff right now.

If someone wants to send me a full set of the git ids that need to be pulled in, I will be glad to do so.

thanks,

greg k-h

#241 lore raw

Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page_range

Quoted 56 lines · Greg KH
Quoted 55 lines · Palmer Dabbelt
Quoted 30 lines · Greg KH
Quoted 29 lines · Atish Patra
Quoted 3 lines · Naresh Kamboju

RISC-V build breaks on stable-rc 5.7 branch.
build failed with gcc-8, gcc-9 and gcc-9.

Sorry for the compilation issue.

mmap_read_lock was intrdouced in the following commit.

commit 9740ca4e95b4

Author: Michel Lespinasse <[email protected]>
Date:   Mon Jun 8 21:33:14 2020 -0700

mmap locking API: initial implementation as rwsem wrappers

The following two commits replaced the usage of mmap_sem rwsem calls
with mmap_lock.

d8ed45c5dcd4 (mmap locking API: use coccinelle to convert mmap_sem
rwsem call sites)
89154dd5313f (mmap locking API: convert mmap_sem call sites missed by
coccinelle)

The first commit is not present in stale 5.7-y for obvious reasons.

Quoted 7 lines
Quoted 3 lines

Do we need to send a separate patch only for stable branch with mmap_sem ? I am not sure if that will cause a conflict again in future.

I do not like taking odd backports, and would rather take the real patch
that is upstream.

I guess I'm a bit new to stable backports so I'm not sure what's expected here.
The failing patch fixes a bug by using a new interface. The smallest diff fix
for the stable kernels would be to construct a similar fix without the new
interface, which in this case is very easy as the new interface just converted
some generic locking calls to one-line functions. It seems somewhat circuitous
to land that in Linus' tree, though, as it would require breaking our port
before fixing it to use the old interfaces and then cleaning it up to use the
new interfaces.

Quoted 5 lines
Quoted 2 lines

Are we expected to pull the new interface onto stable in addition to this fix?

If it really does fix a big issue, yes, that is fine to do.

The original issue was manifests only for certain rootfs with CONFIG_DEBUG_VM enabled in kernel. I am not sure if that qualfies for a big issue :). But there was a similar fix for OpenRISC as well.

+stafford (who fixed the issue for OpenRISC)

@stafford Was there a request to backport the fix to stable ?

I can combine all the git ids that needs to be pulled in.

Quoted 27 lines
Quoted 5 lines

The new interface doesn't actually fix anything itself, but it would allow a
functional kernel to be constructed that consisted of only backports from
Linus' tree (which would also make further fixes easier).

That's fine.

Quoted 4 lines

It seems safe to
just pull in 9740ca4e95b4 ("mmap locking API: initial implementation as rwsem
wrappers") before this failing patch, as in this case the new

Quoted 8 lines

interface will
function correctly with only a subset of callers having been converted. Of
course that's not a generally true statement so I don't know if future code
will behave that way, but pulling in those conversion patches is definitely
unnecessary diff right now.

If someone wants to send me a full set of the git ids that need to be pulled in, I will be glad to do so.

thanks,

greg k-h

Signature · 2 lines
Regards,
Atish
#242 lore raw

Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page_range

Quoted 63 lines · Atish Patra
Quoted 56 lines · Greg KH
Quoted 55 lines · Palmer Dabbelt
Quoted 30 lines · Greg KH
Quoted 29 lines · Atish Patra
Quoted 3 lines · Naresh Kamboju

RISC-V build breaks on stable-rc 5.7 branch.
build failed with gcc-8, gcc-9 and gcc-9.

Sorry for the compilation issue.

mmap_read_lock was intrdouced in the following commit.

commit 9740ca4e95b4

Author: Michel Lespinasse <[email protected]>
Date:   Mon Jun 8 21:33:14 2020 -0700

mmap locking API: initial implementation as rwsem wrappers

The following two commits replaced the usage of mmap_sem rwsem calls
with mmap_lock.

d8ed45c5dcd4 (mmap locking API: use coccinelle to convert mmap_sem
rwsem call sites)
89154dd5313f (mmap locking API: convert mmap_sem call sites missed by
coccinelle)

The first commit is not present in stale 5.7-y for obvious reasons.

Quoted 7 lines
Quoted 3 lines

Do we need to send a separate patch only for stable branch with mmap_sem ? I am not sure if that will cause a conflict again in future.

I do not like taking odd backports, and would rather take the real patch
that is upstream.

I guess I'm a bit new to stable backports so I'm not sure what's expected here.
The failing patch fixes a bug by using a new interface. The smallest diff fix
for the stable kernels would be to construct a similar fix without the new
interface, which in this case is very easy as the new interface just converted
some generic locking calls to one-line functions. It seems somewhat circuitous
to land that in Linus' tree, though, as it would require breaking our port
before fixing it to use the old interfaces and then cleaning it up to use the
new interfaces.

Quoted 5 lines
Quoted 2 lines

Are we expected to pull the new interface onto stable in addition to this fix?

If it really does fix a big issue, yes, that is fine to do.

Quoted 7 lines

The original issue was manifests only for certain rootfs with CONFIG_DEBUG_VM enabled in kernel. I am not sure if that qualfies for a big issue :). But there was a similar fix for OpenRISC as well.

+stafford (who fixed the issue for OpenRISC)

@stafford Was there a request to backport the fix to stable ?

I have not requested pulling my patch to stable. Mine is this one:

313a5257b84c2 ("openrisc: fix boot oops when DEBUG_VM is enabled")

If you cat request that would be great.

Quoted 1 line

I can combine all the git ids that needs to be pulled in.

Note, mine lists:

Fixes 42fc541404f2 ("mmap locking API: add mmap_assert_locked() and mmap_assert_write_locked()")

while your's lists:

Fixes 395a21ff859c(riscv: add ARCH_HAS_SET_DIRECT_MAP support)

That is when the code was introduced to the riscv port, but not the commit that broke booting.

I think if you list the Fixes as I did when backporting to stable Greg, or his tools, would also know that the patch depends on the the 42fc541404f2 commit.

Also, I guess there is no problem with listing 2 "Fixes" in the future.

Thanks Atish and Palmer.

-Stafford

Quoted 31 lines
Quoted 27 lines
Quoted 5 lines

The new interface doesn't actually fix anything itself, but it would allow a
functional kernel to be constructed that consisted of only backports from
Linus' tree (which would also make further fixes easier).

That's fine.

Quoted 4 lines

It seems safe to
just pull in 9740ca4e95b4 ("mmap locking API: initial implementation as rwsem
wrappers") before this failing patch, as in this case the new

Quoted 8 lines

interface will
function correctly with only a subset of callers having been converted. Of
course that's not a generally true statement so I don't know if future code
will behave that way, but pulling in those conversion patches is definitely
unnecessary diff right now.

If someone wants to send me a full set of the git ids that need to be pulled in, I will be glad to do so.

thanks,

greg k-h

Signature · 2 lines
Regards,
Atish
#243 lore raw

Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page_range

Quoted 103 lines · Stafford Horne
Quoted 72 lines · Atish Patra
Quoted 64 lines · Greg KH
Quoted 63 lines · Palmer Dabbelt
Quoted 38 lines · Greg KH
Quoted 28 lines · Atish Patra
Quoted 3 lines · Naresh Kamboju

RISC-V build breaks on stable-rc 5.7 branch.
build failed with gcc-8, gcc-9 and gcc-9.

Sorry for the compilation issue.

mmap_read_lock was intrdouced in the following commit.

commit 9740ca4e95b4

Author: Michel Lespinasse <[email protected]>
Date:   Mon Jun 8 21:33:14 2020 -0700

mmap locking API: initial implementation as rwsem
wrappers

The following two commits replaced the usage of mmap_sem rwsem
calls
with mmap_lock.

d8ed45c5dcd4 (mmap locking API: use coccinelle to convert mmap_sem
rwsem call sites)
89154dd5313f (mmap locking API: convert mmap_sem call sites missed by
coccinelle)

Quoted 8 lines

The first commit is not present in stale 5.7-y for obvious reasons.

Do we need to send a separate patch only for stable branch with
mmap_sem ? I am not sure if that will cause a conflict again in
future.

Quoted 3 lines

I do not like taking odd backports, and would rather take the real patch
that is upstream.

I guess I'm a bit new to stable backports so I'm not sure what's
expected here.
The failing patch fixes a bug by using a new interface. The smallest diff fix
for the stable kernels would be to construct a similar fix without
the new
interface, which in this case is very easy as the new interface just converted
some generic locking calls to one-line functions. It seems somewhat circuitous
to land that in Linus' tree, though, as it would require breaking
our port
before fixing it to use the old interfaces and then cleaning it up
to use the
new interfaces.

Quoted 6 lines
Quoted 3 lines

Are we expected to pull the new interface onto stable in addition
to this fix?

If it really does fix a big issue, yes, that is fine to do.

Quoted 8 lines

The original issue was manifests only for certain rootfs with CONFIG_DEBUG_VM enabled in kernel. I am not sure if that qualfies for a
big issue :). But there was a similar fix for OpenRISC as well.

+stafford (who fixed the issue for OpenRISC)

@stafford Was there a request to backport the fix to stable ?

I have not requested pulling my patch to stable. Mine is this one:

313a5257b84c2 ("openrisc: fix boot oops when DEBUG_VM is enabled")

If you cat request that would be great.

Quoted 1 line

I can combine all the git ids that needs to be pulled in.

Note, mine lists:

Fixes 42fc541404f2 ("mmap locking API: add mmap_assert_locked()

and mmap_assert_write_locked()")

while your's lists:

Fixes 395a21ff859c(riscv: add ARCH_HAS_SET_DIRECT_MAP support)

That is when the code was introduced to the riscv port, but not the commit that
broke booting.

Quoted 8 lines

I think if you list the Fixes as I did when backporting to stable Greg, or his
tools, would also know that the patch depends on the the 42fc541404f2 commit.

Also, I guess there is no problem with listing 2 "Fixes" in the future.

Thanks. I will keep that in mind in future.

Backporting the RISC-V fix would require the original commit to be backported as well.

commit 9740ca4e95b4 (mmap locking API: initial implementation as rwsem wrappers)

However, that is the first commit for big cleanup 12 patch series.
https://lkml.org/lkml/2020/5/20/56

While backporting the first commit (9740ca4e95b4) would solve the problem for RISC-V, all other architecture fixes won't be there. Do we want that in stable tree?

Quoted 37 lines

Thanks Atish and Palmer.

-Stafford

Quoted 33 lines
Quoted 29 lines
Quoted 5 lines

The new interface doesn't actually fix anything itself, but it would allow a
functional kernel to be constructed that consisted of only backports from
Linus' tree (which would also make further fixes easier).

That's fine.

Quoted 5 lines

It seems safe to
just pull in 9740ca4e95b4 ("mmap locking API: initial implementation as rwsem
wrappers") before this failing patch, as in this case the new interface will

Quoted 8 lines

function correctly with only a subset of callers having been converted. Of
course that's not a generally true statement so I don't know if future code
will behave that way, but pulling in those conversion patches is
definitely
unnecessary diff right now.

If someone wants to send me a full set of the git ids that need to be
pulled in, I will be glad to do so.

thanks,

greg k-h

Signature · 2 lines
Regards,
Atish
Signature · 2 lines
Regards,
Atish
author maintainer
#244 lore raw

PATCH 234/244 rxrpc: Fix trace string

In reply to Greg Kroah-Hartman

From: David Howells <[email protected]>

commit aadf9dcef9d4cd68c73a4ab934f93319c4becc47 upstream.

The trace symbol printer (__print_symbolic()) ignores symbols that map to an empty string and prints the hex value instead.

Fix the symbol for rxrpc_cong_no_change to " -" instead of "" to avoid this.

Fixes b54a134a7de4 ("rxrpc: Fix handling of enums-to-string translation in tracing")
---
 include/trace/events/rxrpc.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/trace/events/rxrpc.h +1 -1
@@ -400,7 +400,7 @@ enum rxrpc_tx_point {
 	EM(rxrpc_cong_begin_retransmission,	" Retrans") \
 	EM(rxrpc_cong_cleared_nacks,		" Cleared") \
 	EM(rxrpc_cong_new_low_nack,		" NewLowN") \
-	EM(rxrpc_cong_no_change,		"") \
+	EM(rxrpc_cong_no_change,		" -") \
 	EM(rxrpc_cong_progress,			" Progres") \
 	EM(rxrpc_cong_retransmit_again,		" ReTxAgn") \
 	EM(rxrpc_cong_rtt_window_end,		" RttWinE") \
author maintainer
#245 lore raw

PATCH 235/244 spi: sprd: switch the sequence of setting WDG_LOAD_LOW and _HIGH

In reply to Greg Kroah-Hartman

From: Lingling Xu <[email protected]>

commit 8bdd79dae1ff5397351b95e249abcae126572617 upstream.

The watchdog counter consists of WDG_LOAD_LOW and WDG_LOAD_HIGH, which would be loaded to watchdog counter once writing WDG_LOAD_LOW.

Fixes ac1775012058 ("spi: sprd: Add the support of restarting the system")
---
 drivers/spi/spi-sprd-adi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-sprd-adi.c +1 -1
@@ -389,9 +389,9 @@ static int sprd_adi_restart_handler(stru
 	sprd_adi_write(sadi, sadi->slave_pbase + REG_WDG_CTRL, val);
 
 	/* Load the watchdog timeout value, 50ms is always enough. */
+	sprd_adi_write(sadi, sadi->slave_pbase + REG_WDG_LOAD_HIGH, 0);
 	sprd_adi_write(sadi, sadi->slave_pbase + REG_WDG_LOAD_LOW,
 		       WDG_LOAD_VAL & WDG_LOAD_MASK);
-	sprd_adi_write(sadi, sadi->slave_pbase + REG_WDG_LOAD_HIGH, 0);
 
 	/* Start the watchdog to reset system */
 	sprd_adi_read(sadi, sadi->slave_pbase + REG_WDG_CTRL, &val);
author maintainer
#246 lore raw

PATCH 236/244 ionic: no link check while resetting queues

In reply to Greg Kroah-Hartman

From: Shannon Nelson <[email protected]>

commit 3103b6feb4454646558eedc50ece728bc469f341 upstream.

If the driver is busy resetting queues after a change in MTU or queue parameters, don't bother checking the link, wait until the next watchdog cycle.

Fixes 987c0871e8ae ("ionic: check for linkup in watchdog")
---
 drivers/net/ethernet/pensando/ionic/ionic_lif.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/pensando/ionic/ionic_lif.c +2 -1
@@ -85,7 +85,8 @@ static void ionic_link_status_check(stru
 	u16 link_status;
 	bool link_up;
 
-	if (!test_bit(IONIC_LIF_F_LINK_CHECK_REQUESTED, lif->state))
+	if (!test_bit(IONIC_LIF_F_LINK_CHECK_REQUESTED, lif->state) ||
+	    test_bit(IONIC_LIF_F_QUEUE_RESET, lif->state))
 		return;
 
 	if (lif->ionic->is_mgmt_nic)
author maintainer
#247 lore raw

PATCH 237/244 ionic: export features for vlans to use

In reply to Greg Kroah-Hartman

From: Shannon Nelson <[email protected]>

commit ef7232da6bcd4294cbb2d424bc35885721570f01 upstream.

Set up vlan_features for use by any vlans above us.

Fixes beead698b173 ("ionic: Add the basic NDO callbacks for netdev support")
---
 drivers/net/ethernet/pensando/ionic/ionic_lif.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/ethernet/pensando/ionic/ionic_lif.c +1 -0
@@ -1236,6 +1236,7 @@ static int ionic_init_nic_features(struc
 
 	netdev->hw_features |= netdev->hw_enc_features;
 	netdev->features |= netdev->hw_features;
+	netdev->vlan_features |= netdev->features & ~NETIF_F_VLAN_FEATURES;
 
 	netdev->priv_flags |= IFF_UNICAST_FLT |
 			      IFF_LIVE_ADDR_CHANGE;
author maintainer
#248 lore raw

PATCH 238/244 iommu/vt-d: Make Intel SVM code 64-bit only

In reply to Greg Kroah-Hartman

From: Lu Baolu <[email protected]>

commit 9486727f5981a5ec5c0b699fb1777451bd6786e4 upstream.

Current Intel SVM is designed by setting the pgd_t of the processor page table to FLPTR field of the PASID entry. The first level translation only supports 4 and 5 level paging structures, hence it's infeasible for the IOMMU to share a processor's page table when it's running in 32-bit mode. Let's disable 32bit support for now and claim support only when all the missing pieces are ready in the future.

Fixes 1c4f88b7f1f92 ("iommu/vt-d: Shared virtual address in scalable mode")
---
 drivers/iommu/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iommu/Kconfig +1 -1
@@ -211,7 +211,7 @@ config INTEL_IOMMU_DEBUGFS
 
 config INTEL_IOMMU_SVM
 	bool "Support for Shared Virtual Memory with Intel IOMMU"
-	depends on INTEL_IOMMU && X86
+	depends on INTEL_IOMMU && X86_64
 	select PCI_PASID
 	select PCI_PRI
 	select MMU_NOTIFIER
author maintainer
#249 lore raw

PATCH 239/244 mm/memory.c: properly pte_offset_map_lock/unlock in vm_insert_pages()

In reply to Greg Kroah-Hartman

From: Arjun Roy <[email protected]>

commit 7f70c2a68a51496289df163f6969d4db7c383f30 upstream.

Calls to pte_offset_map() in vm_insert_pages() are erroneously not matched with a call to pte_unmap(). This would cause problems on architectures where that is not a no-op.

This patch does away with the non-traditional locking in the existing code, and instead uses pte_offset_map_lock/unlock() as usual, incrementing PTE as necessary. The PTE pointer is kept within bounds since we clamp it with PTRS_PER_PTE.

Fixes 8cd3984d81d5 ("mm/memory.c: add vm_insert_pages()")
Cc Eric Dumazet <[email protected]>
Cc Hugh Dickins <[email protected]>
Cc Soheil Hassas Yeganeh <[email protected]>
---
 mm/memory.c |   21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)
mm/memory.c +11 -10
@@ -1501,7 +1501,7 @@ out:
 }
 
 #ifdef pte_index
-static int insert_page_in_batch_locked(struct mm_struct *mm, pmd_t *pmd,
+static int insert_page_in_batch_locked(struct mm_struct *mm, pte_t *pte,
 			unsigned long addr, struct page *page, pgprot_t prot)
 {
 	int err;
@@ -1509,8 +1509,9 @@ static int insert_page_in_batch_locked(s
 	if (!page_count(page))
 		return -EINVAL;
 	err = validate_page_before_insert(page);
-	return err ? err : insert_page_into_pte_locked(
-		mm, pte_offset_map(pmd, addr), addr, page, prot);
+	if (err)
+		return err;
+	return insert_page_into_pte_locked(mm, pte, addr, page, prot);
 }
 
 /* insert_pages() amortizes the cost of spinlock operations
@@ -1520,7 +1521,8 @@ static int insert_pages(struct vm_area_s
 			struct page **pages, unsigned long *num, pgprot_t prot)
 {
 	pmd_t *pmd = NULL;
-	spinlock_t *pte_lock = NULL;
+	pte_t *start_pte, *pte;
+	spinlock_t *pte_lock;
 	struct mm_struct *const mm = vma->vm_mm;
 	unsigned long curr_page_idx = 0;
 	unsigned long remaining_pages_total = *num;
@@ -1539,18 +1541,17 @@ more:
 	ret = -ENOMEM;
 	if (pte_alloc(mm, pmd))
 		goto out;
-	pte_lock = pte_lockptr(mm, pmd);
 
 	while (pages_to_write_in_pmd) {
 		int pte_idx = 0;
 		const int batch_size = min_t(int, pages_to_write_in_pmd, 8);
 
-		spin_lock(pte_lock);
-		for (; pte_idx < batch_size; ++pte_idx) {
-			int err = insert_page_in_batch_locked(mm, pmd,
+		start_pte = pte_offset_map_lock(mm, pmd, addr, &pte_lock);
+		for (pte = start_pte; pte_idx < batch_size; ++pte, ++pte_idx) {
+			int err = insert_page_in_batch_locked(mm, pte,
 				addr, pages[curr_page_idx], prot);
 			if (unlikely(err)) {
-				spin_unlock(pte_lock);
+				pte_unmap_unlock(start_pte, pte_lock);
 				ret = err;
 				remaining_pages_total -= pte_idx;
 				goto out;
@@ -1558,7 +1559,7 @@ more:
 			addr += PAGE_SIZE;
 			++curr_page_idx;
 		}
-		spin_unlock(pte_lock);
+		pte_unmap_unlock(start_pte, pte_lock);
 		pages_to_write_in_pmd -= batch_size;
 		remaining_pages_total -= batch_size;
 	}
author maintainer
#250 lore raw

PATCH 240/244 drm/i915/gvt: Fix two CFL MMIO handling caused by regression.

In reply to Greg Kroah-Hartman

From: Colin Xu <[email protected]>

commit fccd0f7cf4d532674d727c7f204f038456675dee upstream.

D_CFL was incorrectly removed for:
GAMT_CHKN_BIT_REG
GEN9_CTX_PREEMPT_REG

V2: Update commit message.
V3: Rebase and split Fixes and mis-handled MMIO.

---
 drivers/gpu/drm/i915/gvt/handlers.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/gvt/handlers.c +2 -2
@@ -3131,8 +3131,8 @@ static int init_skl_mmio_info(struct int
 	MMIO_DFH(GEN9_WM_CHICKEN3, D_SKL_PLUS, F_MODE_MASK | F_CMD_ACCESS,
 		 NULL, NULL);
 
-	MMIO_D(GAMT_CHKN_BIT_REG, D_KBL);
-	MMIO_D(GEN9_CTX_PREEMPT_REG, D_KBL | D_SKL);
+	MMIO_D(GAMT_CHKN_BIT_REG, D_KBL | D_CFL);
+	MMIO_D(GEN9_CTX_PREEMPT_REG, D_SKL_PLUS);
 
 	return 0;
 }
author maintainer
#251 lore raw

PATCH 241/244 gpio: pca953x: disable regmap locking for automatic address incrementing

In reply to Greg Kroah-Hartman

From: Andy Shevchenko <[email protected]>

commit ec3decd21380081e3b5de4ba8d85d90a95f201a0 upstream.

It's a repetition of the commit aa58a21ae378
("gpio: pca953x: disable regmap locking")
which states the following:

This driver uses its own locking but regmap silently uses a mutex for all operations too. Add the option to disable locking to the regmap config struct.

Fixes bcf41dc480b1 ("gpio: pca953x: fix handling of automatic address incrementing")
Cc Uwe Kleine-König <[email protected]>
---
 drivers/gpio/gpio-pca953x.c |    1 +
 1 file changed, 1 insertion(+)
drivers/gpio/gpio-pca953x.c +1 -0
@@ -399,6 +399,7 @@ static const struct regmap_config pca953
 	.writeable_reg = pca953x_writeable_register,
 	.volatile_reg = pca953x_volatile_register,
 
+	.disable_locking = true,
 	.cache_type = REGCACHE_RBTREE,
 	.max_register = 0x7f,
 };
author maintainer
#252 lore raw

PATCH 242/244 bpf: sockmap: Check value of unused args to BPF_PROG_ATTACH

In reply to Greg Kroah-Hartman

From: Lorenz Bauer <[email protected]>

commit 9b2b09717e1812e450782a43ca0c2790651cf380 upstream.

Using BPF_PROG_ATTACH on a sockmap program currently understands no flags or replace_bpf_fd, but accepts any value. Return EINVAL instead.

Fixes 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
---
 net/core/sock_map.c |    3 +++
 1 file changed, 3 insertions(+)
net/core/sock_map.c +3 -0
@@ -70,6 +70,9 @@ int sock_map_get_from_fd(const union bpf
 	struct fd f;
 	int ret;
 
+	if (attr->attach_flags || attr->replace_bpf_fd)
+		return -EINVAL;
+
 	f = fdget(ufd);
 	map = __bpf_map_get(f);
 	if (IS_ERR(map))
author maintainer
#253 lore raw

PATCH 243/244 bpf: sockmap: Require attach_bpf_fd when detaching a program

In reply to Greg Kroah-Hartman

From: Lorenz Bauer <[email protected]>

commit bb0de3131f4c60a9bf976681e0fe4d1e55c7a821 upstream.

The sockmap code currently ignores the value of attach_bpf_fd when detaching a program. This is contrary to the usual behaviour of checking that attach_bpf_fd represents the currently attached program.

Ensure that attach_bpf_fd is indeed the currently attached program. It turns out that all sockmap selftests already do this, which indicates that this is unlikely to cause breakage.

Fixes 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
---
 include/linux/bpf.h   |   13 +++++++++++--
 include/linux/skmsg.h |   13 +++++++++++++
 kernel/bpf/syscall.c  |    2 +-
 net/core/sock_map.c   |   50 +++++++++++++++++++++++++++++++++++++++++++++-----
 4 files changed, 70 insertions(+), 8 deletions(-)
include/linux/bpf.h +11 -2
@@ -1444,13 +1444,16 @@ static inline void bpf_map_offload_map_f
 #endif /* CONFIG_NET && CONFIG_BPF_SYSCALL */
 
 #if defined(CONFIG_BPF_STREAM_PARSER)
-int sock_map_prog_update(struct bpf_map *map, struct bpf_prog *prog, u32 which);
+int sock_map_prog_update(struct bpf_map *map, struct bpf_prog *prog,
+			 struct bpf_prog *old, u32 which);
 int sock_map_get_from_fd(const union bpf_attr *attr, struct bpf_prog *prog);
+int sock_map_prog_detach(const union bpf_attr *attr, enum bpf_prog_type ptype);
 void sock_map_unhash(struct sock *sk);
 void sock_map_close(struct sock *sk, long timeout);
 #else
 static inline int sock_map_prog_update(struct bpf_map *map,
-				       struct bpf_prog *prog, u32 which)
+				       struct bpf_prog *prog,
+				       struct bpf_prog *old, u32 which)
 {
 	return -EOPNOTSUPP;
 }
@@ -1460,6 +1463,12 @@ static inline int sock_map_get_from_fd(c
 {
 	return -EINVAL;
 }
+
+static inline int sock_map_prog_detach(const union bpf_attr *attr,
+				       enum bpf_prog_type ptype)
+{
+	return -EOPNOTSUPP;
+}
 #endif /* CONFIG_BPF_STREAM_PARSER */
 
 #if defined(CONFIG_INET) && defined(CONFIG_BPF_SYSCALL)
include/linux/skmsg.h +13 -0
@@ -430,6 +430,19 @@ static inline void psock_set_prog(struct
 		bpf_prog_put(prog);
 }
 
+static inline int psock_replace_prog(struct bpf_prog **pprog,
+				     struct bpf_prog *prog,
+				     struct bpf_prog *old)
+{
+	if (cmpxchg(pprog, old, prog) != old)
+		return -ENOENT;
+
+	if (old)
+		bpf_prog_put(old);
+
+	return 0;
+}
+
 static inline void psock_progs_drop(struct sk_psock_progs *progs)
 {
 	psock_set_prog(&progs->msg_parser, NULL);
kernel/bpf/syscall.c +1 -1
@@ -2695,7 +2695,7 @@ static int bpf_prog_detach(const union b
 	switch (ptype) {
 	case BPF_PROG_TYPE_SK_MSG:
 	case BPF_PROG_TYPE_SK_SKB:
-		return sock_map_get_from_fd(attr, NULL);
+		return sock_map_prog_detach(attr, ptype);
 	case BPF_PROG_TYPE_LIRC_MODE2:
 		return lirc_prog_detach(attr);
 	case BPF_PROG_TYPE_FLOW_DISSECTOR:
net/core/sock_map.c +45 -5

79 lines not on this page · raw message

author maintainer
#254 lore raw

PATCH 244/244 drm/i915/perf: Use GTT when saving/restoring engine GPR

In reply to Greg Kroah-Hartman

From: Umesh Nerlige Ramappa <[email protected]>

commit aee62e02c48bd62b9b07f5e297ecfc9aaa964937 upstream.

MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which translation to use when saving restoring the engine general purpose registers to and from the GT scratch. Since GT scratch is mapped to ggtt, we need to set an additional bit in the command to use GTT.

Fixes daed3e44396d17 ("drm/i915/perf: implement active wait for noa configurations")
(cherry picked from commit e43ff99c8deda85234e6233e0f4af6cb09566a37)
---
 drivers/gpu/drm/i915/i915_perf.c |    1 +
 1 file changed, 1 insertion(+)
drivers/gpu/drm/i915/i915_perf.c +1 -0
@@ -1645,6 +1645,7 @@ static u32 *save_restore_register(struct
 	u32 d;
 
 	cmd = save ? MI_STORE_REGISTER_MEM : MI_LOAD_REGISTER_MEM;
+	cmd |= MI_SRM_LRM_GLOBAL_GTT;
 	if (INTEL_GEN(stream->perf->i915) >= 8)
 		cmd++;
 
#255 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

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

Responses should be made by Wed, 22 Jul 2020 15:27:31 +0000. Anything received after that time might be too late.

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

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.10-rc1.gz

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

thanks,

greg k-h

All tests are passing for Tegra ...

Test results for stable-v5.7:

    11 builds:  11 pass, 0 fail
    26 boots:   26 pass, 0 fail
    56 tests:   56 pass, 0 fail
Linux version:  5.7.10-rc1-gd3c98742b46c
Boards tested:  tegra124-jetson-tk1, tegra186-p2771-0000,
                tegra194-p2972-0000, tegra20-ventana,
                tegra210-p2371-2180, tegra210-p3450-0000,
                tegra30-cardhu-a04

Cheers,
Thierry