LinuxLists.cc - [PATCH 4.8 00/10] 4.8.1-stable review

[permalink] [raw]

Subject: [PATCH 4.8 01/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.

Cc: <[email protected]>
Reported-by: Yao Qi <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/kernel/debug-monitors.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -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);

2016-10-06 08:18:57

[permalink] [raw]

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

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
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -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),

2016-10-06 08:19:00

[permalink] [raw]

Subject: [PATCH 4.8 02/10] Using BUG_ON() as an assert() is _never_ acceptable

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]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/linux/swap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -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;
}

2016-10-06 08:19:09

[permalink] [raw]

Subject: [PATCH 4.8 03/10] usb: misc: legousbtower: Fix NULL pointer deference

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.

Reported-by: James Patrick-Evans <[email protected]>
Tested-by: James Patrick-Evans <[email protected]>
Signed-off-by: James Patrick-Evans <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/misc/legousbtower.c | 35 +++++++++++++++++------------------
1 file changed, 17 insertions(+), 18 deletions(-)

--- a/drivers/usb/misc/legousbtower.c
+++ b/drivers/usb/misc/legousbtower.c
@@ -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;

2016-10-06 08:19:17

[permalink] [raw]

Subject: [PATCH 4.8 04/10] Staging: fbtft: Fix bug in fbtft-core

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.

Signed-off-by: Ksenija Stanojevic <[email protected]>
Fixes: 367e8560e8d7 ("Staging: fbtbt: Replace timespec with ktime_t")
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/fbtft/fbtft-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -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);

2016-10-06 08:19:26

[permalink] [raw]

Subject: [PATCH 4.8 05/10] usb: usbip: vudc: fix left shift overflow

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")
Signed-off-by: Nicolas Iooss <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/usbip/vudc_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/usbip/vudc_rx.c
+++ b/drivers/usb/usbip/vudc_rx.c
@@ -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);

2016-10-06 08:19:32

[permalink] [raw]

Subject: [PATCH 4.8 06/10] USB: serial: cp210x: Add ID for a Juniper console

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

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

From: Kyle Jones <[email protected]>

commit decc5360f23e9efe0252094f47f57f254dcbb3a9 upstream.

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

---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -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 */

2016-10-06 08:19:40

[permalink] [raw]

Subject: [PATCH 4.8 07/10] Revert "usbtmc: convert to devm_kzalloc"

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.

Reported-by: Ladislav Michl <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/class/usbtmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -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;

2016-10-06 08:19:48

[permalink] [raw]

Subject: [PATCH 4.8 08/10] ALSA: hda - Adding one more ALC255 pin definition for headset problem

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.

Signed-off-by: Hui Wang <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -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}),

2016-10-06 08:19:56

[permalink] [raw]

Subject: [PATCH 4.8 09/10] ALSA: hda - Fix headset mic detection problem for several Dell laptops

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.

Signed-off-by: Hui Wang <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -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}),

2016-10-06 18:51:12

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Thu, Oct 06, 2016 at 10:18:23AM +0200, Greg Kroah-Hartman wrote:
> 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

2016-10-06 19:57:03

by Shuah Khan

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On 10/06/2016 02:18 AM, Greg Kroah-Hartman wrote:
> 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
>

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

thanks,
-- Shuah

--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
[email protected]

2016-10-07 04:05:18

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Thu, Oct 06, 2016 at 01:56:28PM -0600, Shuah Khan wrote:
> On 10/06/2016 02:18 AM, Greg Kroah-Hartman wrote:
> > 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
> >
>
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

2016-10-07 04:05:31

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Thu, Oct 06, 2016 at 11:51:01AM -0700, Guenter Roeck wrote:
> On Thu, Oct 06, 2016 at 10:18:23AM +0200, Greg Kroah-Hartman wrote:
> > 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.

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

greg k-h

2016-10-08 14:04:00

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Fri, Oct 07, 2016 at 03:26:04PM -0700, kernelci.org bot wrote:
> 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
>
> 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

2016-10-08 16:11:55

by Kevin Hilman

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

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

> On Fri, Oct 07, 2016 at 03:26:04PM -0700, kernelci.org bot wrote:
>> 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

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

>> 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

>> 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

2016-10-08 17:22:53

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On 10/08/2016 09:11 AM, Kevin Hilman wrote:
> Greg Kroah-Hartman <[email protected]> writes:
>
>> On Fri, Oct 07, 2016 at 03:26:04PM -0700, kernelci.org bot wrote:
>>> 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
>
> This one looks like lab-specific intermittent failures, not related to
> the this kernel.
>
>>> 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
>
>>> 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

2016-10-10 09:39:29

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Sat, Oct 08, 2016 at 10:22:41AM -0700, Guenter Roeck wrote:
> On 10/08/2016 09:11 AM, Kevin Hilman wrote:

> > > > 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

Attachments:

(No filename) (415.00 B)
signature.asc (455.00 B)
Download all attachments

2016-10-10 12:54:28

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On 10/10/2016 02:38 AM, Mark Brown wrote:
> On Sat, Oct 08, 2016 at 10:22:41AM -0700, Guenter Roeck wrote:
>> On 10/08/2016 09:11 AM, Kevin Hilman wrote:
>
>>>>> 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
>

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

2016-10-10 19:12:12

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Mon, Oct 10, 2016 at 05:54:22AM -0700, Guenter Roeck wrote:

> 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.

Attachments:

(No filename) (1.01 kB)
signature.asc (455.00 B)
Download all attachments

2016-10-10 19:47:48

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Mon, Oct 10, 2016 at 09:11:23PM +0200, Mark Brown wrote:
> On Mon, Oct 10, 2016 at 05:54:22AM -0700, Guenter Roeck wrote:
>
> > 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.

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

2016-10-11 07:25:04

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

Attachments:

(No filename) (556.00 B)
signature.asc (455.00 B)
Download all attachments

2016-10-11 10:20:54

[permalink] [raw]

Subject: Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Mon, Oct 10, 2016 at 12:47:43PM -0700, Guenter Roeck wrote:
> On Mon, Oct 10, 2016 at 09:11:23PM +0200, Mark Brown wrote:

> > 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

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

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

Attachments:

(No filename) (962.00 B)
signature.asc (455.00 B)
Download all attachments

2016-10-11 13:40:14