Skip to contentSkip to conversation

4.8.1-stable review

PATCH In review Greg Kroah-Hartman 5 participants 25 messages Oct 6, 2016 – Oct 11, 2016 1 message not in the archive Stable branch

lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.8.1-stable review

This is the start of the stable review cycle for the 4.8.1 release. There are 10 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 Sat Oct 8 07:47:33 UTC 2016. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.1-rc1.gz

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

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>

    Linux 4.8.1-rc1

Takashi Iwai <[email protected]>
ALSA: hda - Add the top speaker pin config for HP Spectre x360

Hui Wang <[email protected]>
ALSA: hda - Fix headset mic detection problem for several Dell laptops

Hui Wang <[email protected]>
ALSA: hda - Adding one more ALC255 pin definition for headset problem

Greg Kroah-Hartman <[email protected]>
Revert "usbtmc: convert to devm_kzalloc"

Kyle Jones <[email protected]>

    USB: serial: cp210x: Add ID for a Juniper console

Nicolas Iooss <[email protected]>
usb: usbip: vudc: fix left shift overflow

Ksenija Stanojevic <[email protected]>
Staging: fbtft: Fix bug in fbtft-core

Greg Kroah-Hartman <[email protected]>
usb: misc: legousbtower: Fix NULL pointer deference

Linus Torvalds <[email protected]>
Using BUG_ON() as an assert() is _never_ acceptable

Will Deacon <[email protected]>
arm64: debug: avoid resetting stepping state machine when TIF_SINGLESTEP

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

Diffstat:

 Makefile                           |  4 ++--
 arch/arm64/kernel/debug-monitors.c |  6 ++++--
 drivers/staging/fbtft/fbtft-core.c |  4 ++--
 drivers/usb/class/usbtmc.c         |  3 ++-
 drivers/usb/misc/legousbtower.c    | 35 +++++++++++++++++------------------
 drivers/usb/serial/cp210x.c        |  1 +
 drivers/usb/usbip/vudc_rx.c        |  2 +-
 include/linux/swap.h               |  4 ++--
 sound/pci/hda/patch_conexant.c     | 10 ++++++++++
 sound/pci/hda/patch_realtek.c      | 17 +++++++++++++++++
 10 files changed, 58 insertions(+), 28 deletions(-)
author maintainer
#1 lore raw

PATCH 1/10 arm64: debug: avoid resetting stepping state machine when TIF_SINGLESTEP

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Will Deacon <[email protected]>

commit 3a402a709500c5a3faca2111668c33d96555e35a upstream.

When TIF_SINGLESTEP is set for a task, the single-step state machine is enabled and we must take care not to reset it to the active-not-pending state if it is already in the active-pending state.

Unfortunately, that's exactly what user_enable_single_step does, by unconditionally setting the SS bit in the SPSR for the current task. This causes failures in the GDB testsuite, where GDB ends up missing expected step traps if the instruction being stepped generates another trap, e.g. PTRACE_EVENT_FORK from an SVC instruction.

This patch fixes the problem by preserving the current state of the stepping state machine when TIF_SINGLESTEP is set on the current thread.

---
 arch/arm64/kernel/debug-monitors.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
arch/arm64/kernel/debug-monitors.c +4 -2
@@ -435,8 +435,10 @@ NOKPROBE_SYMBOL(kernel_active_single_ste
 /* ptrace API */
 void user_enable_single_step(struct task_struct *task)
 {
-	set_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
-	set_regs_spsr_ss(task_pt_regs(task));
+	struct thread_info *ti = task_thread_info(task);
+
+	if (!test_and_set_ti_thread_flag(ti, TIF_SINGLESTEP))
+		set_regs_spsr_ss(task_pt_regs(task));
 }
 NOKPROBE_SYMBOL(user_enable_single_step);
 
author maintainer
#2 lore raw

PATCH 2/10 Using BUG_ON() as an assert() is _never_ acceptable

In reply to Greg Kroah-Hartman

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Linus Torvalds <[email protected]>

commit 21f54ddae449f4bdd9f1498124901d67202243d9 upstream.

That just generally kills the machine, and makes debugging only much harder, since the traces may long be gone.

Debugging by assert() is a disease. Don't do it. If you can continue, you're much better off doing so with a live machine where you have a much higher chance that the report actually makes it to the system logs, rather than result in a machine that is just completely dead.

The only valid situation for BUG_ON() is when continuing is not an option, because there is massive corruption. But if you are just verifying that something is true, you warn about your broken assumptions (preferably just once), and limp on.

Fixes 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()")
Cc Johannes Weiner <[email protected]>
Cc Miklos Szeredi <[email protected]>
Cc Andrew Morton <[email protected]>
---
 include/linux/swap.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
include/linux/swap.h +2 -2
@@ -257,7 +257,7 @@ static inline void workingset_node_pages
 
 static inline void workingset_node_pages_dec(struct radix_tree_node *node)
 {
-	VM_BUG_ON(!workingset_node_pages(node));
+	VM_WARN_ON_ONCE(!workingset_node_pages(node));
 	node->count--;
 }
 
@@ -273,7 +273,7 @@ static inline void workingset_node_shado
 
 static inline void workingset_node_shadows_dec(struct radix_tree_node *node)
 {
-	VM_BUG_ON(!workingset_node_shadows(node));
+	VM_WARN_ON_ONCE(!workingset_node_shadows(node));
 	node->count -= 1U << RADIX_TREE_COUNT_SHIFT;
 }
 
author maintainer
#3 lore raw

PATCH 3/10 usb: misc: legousbtower: Fix NULL pointer deference

In reply to Greg Kroah-Hartman

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Greg Kroah-Hartman <[email protected]>

commit 2fae9e5a7babada041e2e161699ade2447a01989 upstream.

This patch fixes a NULL pointer dereference caused by a race codition in the probe function of the legousbtower driver. It re-structures the probe function to only register the interface after successfully reading the board's firmware ID.

The probe function does not deregister the usb interface after an error receiving the devices firmware ID. The device file registered (/dev/usb/legousbtower%d) may be read/written globally before the probe function returns. When tower_delete is called in the probe function (after an r/w has been initiated), core dev structures are deleted while the file operation functions are still running. If the 0 address is mappable on the machine, this vulnerability can be used to create a Local Priviege Escalation exploit via a write-what-where condition by remapping dev->interrupt_out_buffer in tower_write. A forged USB device and local program execution would be required for LPE. The USB device would have to delay the control message in tower_probe and accept the control urb in tower_open whilst guest code initiated a write to the device file as tower_delete is called from the error in tower_probe.

This bug has existed since 2003. Patch tested by emulated device.

---
 drivers/usb/misc/legousbtower.c |   35 +++++++++++++++++------------------
 1 file changed, 17 insertions(+), 18 deletions(-)
drivers/usb/misc/legousbtower.c +17 -18
@@ -898,24 +898,6 @@ static int tower_probe (struct usb_inter
 	dev->interrupt_in_interval = interrupt_in_interval ? interrupt_in_interval : dev->interrupt_in_endpoint->bInterval;
 	dev->interrupt_out_interval = interrupt_out_interval ? interrupt_out_interval : dev->interrupt_out_endpoint->bInterval;
 
-	/* we can register the device now, as it is ready */
-	usb_set_intfdata (interface, dev);
-
-	retval = usb_register_dev (interface, &tower_class);
-
-	if (retval) {
-		/* something prevented us from registering this driver */
-		dev_err(idev, "Not able to get a minor for this device.\n");
-		usb_set_intfdata (interface, NULL);
-		goto error;
-	}
-	dev->minor = interface->minor;
-
-	/* let the user know what node this device is now attached to */
-	dev_info(&interface->dev, "LEGO USB Tower #%d now attached to major "
-		 "%d minor %d\n", (dev->minor - LEGO_USB_TOWER_MINOR_BASE),
-		 USB_MAJOR, dev->minor);
-
 	/* get the firmware version and log it */
 	result = usb_control_msg (udev,
 				  usb_rcvctrlpipe(udev, 0),
@@ -936,6 +918,23 @@ static int tower_probe (struct usb_inter
 		 get_version_reply.minor,
 		 le16_to_cpu(get_version_reply.build_no));
 
+	/* we can register the device now, as it is ready */
+	usb_set_intfdata (interface, dev);
+
+	retval = usb_register_dev (interface, &tower_class);
+
+	if (retval) {
+		/* something prevented us from registering this driver */
+		dev_err(idev, "Not able to get a minor for this device.\n");
+		usb_set_intfdata (interface, NULL);
+		goto error;
+	}
+	dev->minor = interface->minor;
+
+	/* let the user know what node this device is now attached to */
+	dev_info(&interface->dev, "LEGO USB Tower #%d now attached to major "
+		 "%d minor %d\n", (dev->minor - LEGO_USB_TOWER_MINOR_BASE),
+		 USB_MAJOR, dev->minor);
 
 exit:
 	return retval;
author maintainer
#4 lore raw

PATCH 4/10 Staging: fbtft: Fix bug in fbtft-core

In reply to Greg Kroah-Hartman

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Ksenija Stanojevic <[email protected]>

commit fc1e2c8ea85e109acf09e74789e9b852f6eed251 upstream.

Commit 367e8560e8d7a62d96e9b1d644028a3816e04206 introduced a bug in fbtft-core where fps is always 0, this is because variable update_time is not assigned correctly.

Fixes 367e8560e8d7 ("Staging: fbtbt: Replace timespec with ktime_t")
---
 drivers/staging/fbtft/fbtft-core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/staging/fbtft/fbtft-core.c +2 -2
@@ -391,11 +391,11 @@ static void fbtft_update_display(struct
 
 	if (unlikely(timeit)) {
 		ts_end = ktime_get();
-		if (ktime_to_ns(par->update_time))
+		if (!ktime_to_ns(par->update_time))
 			par->update_time = ts_start;
 
-		par->update_time = ts_start;
 		fps = ktime_us_delta(ts_start, par->update_time);
+		par->update_time = ts_start;
 		fps = fps ? 1000000 / fps : 0;
 
 		throughput = ktime_us_delta(ts_end, ts_start);
author maintainer
#5 lore raw

PATCH 5/10 usb: usbip: vudc: fix left shift overflow

In reply to Greg Kroah-Hartman

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Nicolas Iooss <[email protected]>

commit 238b7bd91b16d5a08326f858db42229b212e53d8 upstream.

In v_recv_cmd_submit(), urb_p->urb->pipe has the type unsigned int (which is 32-bit long on x86_64) but 11<<30 results in a 34-bit integer. Therefore the 2 leading bits are truncated and

    urb_p->urb->pipe &= ~(11 << 30);

has the same meaning as

    urb_p->urb->pipe &= ~(3 << 30);

This second statement seems to be how the code was intended to be written, as PIPE_ constants have values between 0 and 3.

The overflow has been detected with a clang warning:

    drivers/usb/usbip/vudc_rx.c:145:27: warning: signed shift result
    (0x2C0000000) requires 35 bits to represent, but 'int' only has 32
    bits [-Wshift-overflow]
            urb_p->urb->pipe &= ~(11 << 30);
                                  ~~ ^  ~~
Fixes 79c02cb1fd5c ("usbip: vudc: Add vudc_rx")
---
 drivers/usb/usbip/vudc_rx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/usbip/vudc_rx.c +1 -1
@@ -142,7 +142,7 @@ static int v_recv_cmd_submit(struct vudc
 	urb_p->urb->status = -EINPROGRESS;
 
 	/* FIXME: more pipe setup to please usbip_common */
-	urb_p->urb->pipe &= ~(11 << 30);
+	urb_p->urb->pipe &= ~(3 << 30);
 	switch (urb_p->ep->type) {
 	case USB_ENDPOINT_XFER_BULK:
 		urb_p->urb->pipe |= (PIPE_BULK << 30);
author maintainer
#6 lore raw

PATCH 6/10 USB: serial: cp210x: Add ID for a Juniper console

In reply to Greg Kroah-Hartman

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Kyle Jones <[email protected]>

commit decc5360f23e9efe0252094f47f57f254dcbb3a9 upstream.

---
 drivers/usb/serial/cp210x.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/serial/cp210x.c +1 -0
@@ -118,6 +118,7 @@ static const struct usb_device_id id_tab
 	{ USB_DEVICE(0x10C4, 0x8411) }, /* Kyocera GPS Module */
 	{ USB_DEVICE(0x10C4, 0x8418) }, /* IRZ Automation Teleport SG-10 GSM/GPRS Modem */
 	{ USB_DEVICE(0x10C4, 0x846E) }, /* BEI USB Sensor Interface (VCP) */
+	{ USB_DEVICE(0x10C4, 0x8470) }, /* Juniper Networks BX Series System Console */
 	{ USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */
 	{ USB_DEVICE(0x10C4, 0x84B6) }, /* Starizona Hyperion */
 	{ USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */
author maintainer
#7 lore raw

PATCH 7/10 Revert "usbtmc: convert to devm_kzalloc"

In reply to Greg Kroah-Hartman

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Greg Kroah-Hartman <[email protected]>

commit ab21b63e8aedfc73565dd9cdd51eb338341177cb upstream.

This reverts commit e6c7efdcb76f11b04e3d3f71c8d764ab75c9423b.

Turns out it was totally wrong. The memory is supposed to be bound to the kref, as the original code was doing correctly, not the device/driver binding as the devm_kzalloc() would cause.

This fixes an oops when read would be called after the device was unbound from the driver.

---
 drivers/usb/class/usbtmc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/class/usbtmc.c +2 -1
@@ -141,6 +141,7 @@ static void usbtmc_delete(struct kref *k
 	struct usbtmc_device_data *data = to_usbtmc_data(kref);
 
 	usb_put_dev(data->usb_dev);
+	kfree(data);
 }
 
 static int usbtmc_open(struct inode *inode, struct file *filp)
@@ -1379,7 +1380,7 @@ static int usbtmc_probe(struct usb_inter
 
 	dev_dbg(&intf->dev, "%s called\n", __func__);
 
-	data = devm_kzalloc(&intf->dev, sizeof(*data), GFP_KERNEL);
+	data = kmalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return -ENOMEM;
 
author maintainer
#8 lore raw

PATCH 8/10 ALSA: hda - Adding one more ALC255 pin definition for headset problem

In reply to Greg Kroah-Hartman

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Hui Wang <[email protected]>

commit 392c9da24a994f238c5d7ea611c6245be4617014 upstream.

We have two new Dell laptop models, they have the same ALC255 pin definition, but not in the pin quirk table yet, as a result, the headset microphone can't work. After adding the definition in the table, the headset microphone works well.

---
 sound/pci/hda/patch_realtek.c |    4 ++++
 1 file changed, 4 insertions(+)
sound/pci/hda/patch_realtek.c +4 -0
@@ -5846,6 +5846,10 @@ static const struct snd_hda_pin_quirk al
 		{0x14, 0x90170120},
 		{0x21, 0x02211030}),
 	SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+		{0x14, 0x90170110},
+		{0x1b, 0x02011020},
+		{0x21, 0x0221101f}),
+	SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
 		{0x14, 0x90170130},
 		{0x1b, 0x01014020},
 		{0x21, 0x0221103f}),
author maintainer
#9 lore raw

PATCH 9/10 ALSA: hda - Fix headset mic detection problem for several Dell laptops

In reply to Greg Kroah-Hartman

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Hui Wang <[email protected]>

commit 3f640970a41429f0a076c01270bbd014c9eae61c upstream.

One of the laptops has the codec ALC256 on it, applying the ALC255_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem, the rest of laptops have the codec ALC295 on them, they are similar to machines with ALC225, applying the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem.

---
 sound/pci/hda/patch_realtek.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)
sound/pci/hda/patch_realtek.c +13 -0
@@ -5806,6 +5806,13 @@ static const struct hda_model_fixup alc2
 	{0x14, 0x90170110}, \
 	{0x15, 0x0221401f}
 
+#define ALC295_STANDARD_PINS \
+	{0x12, 0xb7a60130}, \
+	{0x14, 0x90170110}, \
+	{0x17, 0x21014020}, \
+	{0x18, 0x21a19030}, \
+	{0x21, 0x04211020}
+
 #define ALC298_STANDARD_PINS \
 	{0x12, 0x90a60130}, \
 	{0x21, 0x03211020}
@@ -5915,6 +5922,10 @@ static const struct snd_hda_pin_quirk al
 		{0x14, 0x90170120},
 		{0x21, 0x02211030}),
 	SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+		{0x12, 0xb7a60130},
+		{0x14, 0x90170110},
+		{0x21, 0x02211020}),
+	SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
 		ALC256_STANDARD_PINS),
 	SND_HDA_PIN_QUIRK(0x10ec0280, 0x103c, "HP", ALC280_FIXUP_HP_GPIO4,
 		{0x12, 0x90a60130},
@@ -6025,6 +6036,8 @@ static const struct snd_hda_pin_quirk al
 	SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
 		ALC292_STANDARD_PINS,
 		{0x13, 0x90a60140}),
+	SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
+		ALC295_STANDARD_PINS),
 	SND_HDA_PIN_QUIRK(0x10ec0298, 0x1028, "Dell", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
 		ALC298_STANDARD_PINS,
 		{0x17, 0x90170110}),
author maintainer
#10 lore raw

PATCH 10/10 ALSA: hda - Add the top speaker pin config for HP Spectre x360

In reply to Greg Kroah-Hartman

4.8-stable review patch. If anyone has any objections, please let me know.

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

From: Takashi Iwai <[email protected]>

commit 0eec880966e77bdbee0112989a2be67d92e39929 upstream.

HP Spectre x360 with CX20724 codec has two speaker outputs while the BIOS sets up only the bottom one (NID 0x17) and disables the top one (NID 0x1d).

This patch adds a fixup simply defining the proper pincfg for NID 0x1d so that the top speaker works as is.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=169071

---
 sound/pci/hda/patch_conexant.c |   10 ++++++++++
 1 file changed, 10 insertions(+)
sound/pci/hda/patch_conexant.c +10 -0
@@ -261,6 +261,7 @@ enum {
 	CXT_FIXUP_HP_530,
 	CXT_FIXUP_CAP_MIX_AMP_5047,
 	CXT_FIXUP_MUTE_LED_EAPD,
+	CXT_FIXUP_HP_SPECTRE,
 };
 
 /* for hda_fixup_thinkpad_acpi() */
@@ -765,6 +766,14 @@ static const struct hda_fixup cxt_fixups
 		.type = HDA_FIXUP_FUNC,
 		.v.func = cxt_fixup_mute_led_eapd,
 	},
+	[CXT_FIXUP_HP_SPECTRE] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			/* enable NID 0x1d for the speaker on top */
+			{ 0x1d, 0x91170111 },
+			{ }
+		}
+	},
 };
 
 static const struct snd_pci_quirk cxt5045_fixups[] = {
@@ -814,6 +823,7 @@ static const struct snd_pci_quirk cxt506
 	SND_PCI_QUIRK(0x1025, 0x0543, "Acer Aspire One 522", CXT_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK(0x1025, 0x054c, "Acer Aspire 3830TG", CXT_FIXUP_ASPIRE_DMIC),
 	SND_PCI_QUIRK(0x1025, 0x054f, "Acer Aspire 4830T", CXT_FIXUP_ASPIRE_DMIC),
+	SND_PCI_QUIRK(0x103c, 0x8174, "HP Spectre x360", CXT_FIXUP_HP_SPECTRE),
 	SND_PCI_QUIRK(0x1043, 0x138d, "Asus", CXT_FIXUP_HEADPHONE_MIC_PIN),
 	SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT_FIXUP_OLPC_XO),
 	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400", CXT_PINCFG_LENOVO_TP410),
#11 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.8.1 release. There are 10 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 Sat Oct 8 07:47:33 UTC 2016. Anything received after that time might be too late.

Build results:

	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 108 pass: 108 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

author maintainer
#12 lore raw
Quoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.8.1 release. There are 10 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 Sat Oct 8 07:47:33 UTC 2016. Anything received after that time might be too late.

Quoted 6 lines

Build results:

	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 108 pass: 108 fail: 0

Details are available at http://kerneltests.org/builders.

Great, thanks for testing all of these and letting me know.

greg k-h

#13 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.8.1 release. There are 10 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 Sat Oct 8 07:47:33 UTC 2016. Anything received after that time might be too late.

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

Quoted 9 lines
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.1-rc1.gz

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

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Signature · 5 lines
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
[email protected]
author maintainer
#14 lore raw
Quoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.8.1 release. There are 10 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 Sat Oct 8 07:47:33 UTC 2016. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.1-rc1.gz

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

Quoted 6 lines
Quoted 4 lines

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

A message that is not in the archive (sent off-list or not yet received): [email protected]

author maintainer
#16 lore raw
Quoted 19 lines · kernelci.org bot

stable-rc boot: 479 boots: 4 failed, 183 passed with 292 offline (v4.8-11-ge141008f62ab)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.8-11-ge141008f62ab/
Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.8-11-ge141008f62ab/

Tree: stable-rc
Branch: local/linux-4.8.y
Git Describe: v4.8-11-ge141008f62ab
Git Commit: e141008f62abab72c15b093d97a88f37c8cd7096
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 86 unique boards, 23 SoC families, 33 builds out of 206

Boot Failures Detected: https://kernelci.org/boot/?v4.8-11-ge141008f62ab&fail

arm:

mxs_defconfig:
imx23-olinuxino: 1 failed lab

Quoted 6 lines

multi_v7_defconfig+CONFIG_SMP=n:
imx6q-sabrelite: 1 failed lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
vexpress-v2p-ca15-tc1: 1 failed lab
vexpress-v2p-ca15_a7: 1 failed lab

How does this compare to 4.8.0?

thanks,

greg k-h

#17 lore raw
Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · kernelci.org bot

stable-rc boot: 479 boots: 4 failed, 183 passed with 292 offline (v4.8-11-ge141008f62ab)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.8-11-ge141008f62ab/
Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.8-11-ge141008f62ab/

Tree: stable-rc
Branch: local/linux-4.8.y
Git Describe: v4.8-11-ge141008f62ab
Git Commit: e141008f62abab72c15b093d97a88f37c8cd7096
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 86 unique boards, 23 SoC families, 33 builds out of 206

Quoted 6 lines
Quoted 6 lines

Boot Failures Detected: https://kernelci.org/boot/?v4.8-11-ge141008f62ab&fail

arm:

mxs_defconfig:
imx23-olinuxino: 1 failed lab

This one looks like lab-specific intermittent failures, not related to the this kernel.

Quoted 2 lines
Quoted 2 lines

multi_v7_defconfig+CONFIG_SMP=n:
imx6q-sabrelite: 1 failed lab

The CONFIG_SMP=n boots for this board have been failing for awhile, so this isn't related to stable-rc

Quoted 3 lines
Quoted 3 lines
    multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
        vexpress-v2p-ca15-tc1: 1 failed lab
        vexpress-v2p-ca15_a7: 1 failed lab

These builds are known broken an QEMU need to be blacklisted until we find out what's going on.

Kevin

#18 lore raw
Quoted 31 lines · Kevin Hilman
Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · kernelci.org bot

stable-rc boot: 479 boots: 4 failed, 183 passed with 292 offline (v4.8-11-ge141008f62ab)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.8-11-ge141008f62ab/
Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.8-11-ge141008f62ab/

Tree: stable-rc
Branch: local/linux-4.8.y
Git Describe: v4.8-11-ge141008f62ab
Git Commit: e141008f62abab72c15b093d97a88f37c8cd7096
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 86 unique boards, 23 SoC families, 33 builds out of 206

Quoted 6 lines
Quoted 6 lines

Boot Failures Detected: https://kernelci.org/boot/?v4.8-11-ge141008f62ab&fail

arm:

mxs_defconfig:
imx23-olinuxino: 1 failed lab

This one looks like lab-specific intermittent failures, not related to the this kernel.

Quoted 2 lines
Quoted 2 lines

multi_v7_defconfig+CONFIG_SMP=n:
imx6q-sabrelite: 1 failed lab

The CONFIG_SMP=n boots for this board have been failing for awhile, so this isn't related to stable-rc

Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
    multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
        vexpress-v2p-ca15-tc1: 1 failed lab
        vexpress-v2p-ca15_a7: 1 failed lab

These builds are known broken an QEMU need to be blacklisted until we find out what's going on.

Is this with qemu or on a real board ?

If with qemu, what is your qemu version ?

Thanks,
Guenter

#19 lore raw
Quoted 11 lines · Guenter Roeck
Quoted 5 lines · Kevin Hilman
Quoted 2 lines
Quoted 2 lines
        vexpress-v2p-ca15-tc1: 1 failed lab
        vexpress-v2p-ca15_a7: 1 failed lab

These builds are known broken an QEMU need to be blacklisted until we find out what's going on.

Is this with qemu or on a real board ?

If with qemu, what is your qemu version ?

qemu 2.5

#20 lore raw
Quoted 6 lines · Mark Brown
Quoted 4 lines · Guenter Roeck
Quoted 2 lines · Kevin Hilman
Quoted 2 lines
Quoted 2 lines
        vexpress-v2p-ca15-tc1: 1 failed lab
        vexpress-v2p-ca15_a7: 1 failed lab
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines

These builds are known broken an QEMU need to be blacklisted until we find out what's going on.

Is this with qemu or on a real board ?

If with qemu, what is your qemu version ?

qemu 2.5

Can I find the qemu command line somewhere ? The following work fine for me.

Building arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 ... running ..... passed Building arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 ... running ..... passed

Thanks,
Guenter

#21 lore raw
Quoted 5 lines · Guenter Roeck

Can I find the qemu command line somewhere ? The following work fine for me.

Building arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 ... running ..... passed Building arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 ... running ..... passed

Note that most of the failures my lab saw are with extra configs, the only vanilla config that failed was vexpress-v2p-ca15_a7 with the multi_v7_defconfig.

My connection doesn't have IPv6 and is a bit spotty right now so it's a bit difficult for me to check by lab but today's -next jobs are working for me as well... looking at the log for the failed stable boots:

https://storage.kernelci.org/stable/v4.8.1/arm-multi_v7_defconfig/lab-broonie/boot-vexpress-v2p-ca15_a7.html

looks like it's some interaction with the test image causing udevadm settle to not run quickly enough - there's also a big delay before the UART comes up. I'm wondering if it's just that the host machine is just too slow here.

#22 lore raw
Quoted 16 lines · Mark Brown
Quoted 5 lines · Guenter Roeck

Can I find the qemu command line somewhere ? The following work fine for me.

Building arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 ... running ..... passed Building arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 ... running ..... passed

Note that most of the failures my lab saw are with extra configs, the only vanilla config that failed was vexpress-v2p-ca15_a7 with the multi_v7_defconfig.

My connection doesn't have IPv6 and is a bit spotty right now so it's a bit difficult for me to check by lab but today's -next jobs are working for me as well... looking at the log for the failed stable boots:

Quoted 6 lines

https://storage.kernelci.org/stable/v4.8.1/arm-multi_v7_defconfig/lab-broonie/boot-vexpress-v2p-ca15_a7.html

looks like it's some interaction with the test image causing udevadm settle to not run quickly enough - there's also a big delay before the UART comes up. I'm wondering if it's just that the host machine is just too slow here.

Can you send me (or point me to) the qemu command lines you are using ? Even better would the complete setup describing how you connect to kernelci.

Thanks,
Guenter

#23 lore raw
Quoted 7 lines · Guenter Roeck
Quoted 3 lines · Mark Brown

My connection doesn't have IPv6 and is a bit spotty right now so it's a bit difficult for me to check by lab but today's -next jobs are working for me as well... looking at the log for the failed stable boots:

Can you send me (or point me to) the qemu command lines you are using ?

See above.

Quoted 1 line

Even better would the complete setup describing how you connect to kernelci.

It's an off the shelf install of LAVA.

#24 lore raw
In reply to Guenter Roeck
Quoted 7 lines · Guenter Roeck
Quoted 3 lines · Mark Brown

My connection doesn't have IPv6 and is a bit spotty right now so it's a bit difficult for me to check by lab but today's -next jobs are working for me as well... looking at the log for the failed stable boots:

Can you send me (or point me to) the qemu command lines you are using ?

Managed to get things running long enough to pull the log:

qemu-system-arm -M vexpress-a15 -no-reboot -show-cursor -no-reboot -nographic -m 256 -net user -kernel /var/lib/lava/dispatcher/tmp/tmpZBxic8/.zImage -append "root=/dev/ram0 rw console=ttyAMA0 115200 ip=dhcp mem=256M" -initrd /var/lib/lava/dispatcher/tmp/tmpxoFsPn/ramdisk.cpio.gz -dtb /var/lib/lava/dispatcher/tmp/tmpMN1a1R/vexpress-v2p-ca15_a7.dtb

Quoted 1 line

Even better would the complete setup describing how you connect to kernelci.

Like I say it's just a standard LAVA install.

#25 lore raw
Quoted 7 lines · Mark Brown
Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Mark Brown

My connection doesn't have IPv6 and is a bit spotty right now so it's a bit difficult for me to check by lab but today's -next jobs are working for me as well... looking at the log for the failed stable boots:

Quoted 6 lines
Quoted 1 line

Can you send me (or point me to) the qemu command lines you are using ?

Managed to get things running long enough to pull the log:

qemu-system-arm -M vexpress-a15 -no-reboot -show-cursor -no-reboot -nographic -m 256 -net user -kernel /var/lib/lava/dispatcher/tmp/tmpZBxic8/.zImage -append "root=/dev/ram0 rw console=ttyAMA0 115200 ip=dhcp mem=256M" -initrd /var/lib/lava/dispatcher/tmp/tmpxoFsPn/ramdisk.cpio.gz -dtb /var/lib/lava/dispatcher/tmp/tmpMN1a1R/vexpress-v2p-ca15_a7.dtb

Boots for me, though I have to specify

	-append "rdinit=/sbin/init console=ttyAMA0,115200"
or, when using a root file system,
	-drive file=core-image-minimal-qemuarm.ext3,format=raw,if=sd \
	-append "root=/dev/mmcblk0 rootwait rw console=ttyAMA0,115200"

I do get the warning about the wrong CPU id, but looks like that is as expected.

I tried with qemu 2.5, 1.6, and 2.7, and the mainline kernel as well as v4.7.

Guenter