Skip to contentSkip to conversation

4.14.36-stable review

PATCH In review Greg Kroah-Hartman 5 participants 172 messages Apr 22, 2018 – Apr 24, 2018 Page 2 of 2

Subsystems (3)
Stable branch Memory management MIPS
lore
Share & tools
lore
author maintainer
#163 lore raw

PATCH 163/164 media: staging: lirc_zilog: incorrect reference counting

In reply to Greg Kroah-Hartman

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

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

From: Sean Young <[email protected]>

[not upstream as the driver is deleted in 4.16 - gregkh]

Whenever poll is called, the reference count is increased but never decreased. This means that on rmmod, the lirc_thread is not stopped, and will trample over freed memory.

Zilog/Hauppauge IR driver unloaded

BUG: unable to handle kernel paging request at ffffffffc17ba640
Oops: 0010 [#1] SMP
CPU: 1 PID: 667 Comm: zilog-rx-i2c-1 Tainted: P         C OE   4.13.16-302.fc27.x86_64 #1
Hardware name: Gigabyte Technology Co., Ltd. GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F6 08/06/2009
task: ffff964eb452ca00 task.stack: ffffb254414dc000
RIP: 0010:0xffffffffc17ba640
RSP: 0018:ffffb254414dfe78 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff964ec1b35890 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
RBP: ffffb254414dff00 R08: 000000000000036e R09: ffff964ecfc8dfd0
R10: ffffb254414dfe78 R11: 00000000000f4240 R12: ffff964ec2bf28a0
R13: ffff964ec1b358a8 R14: ffff964ec1b358d0 R15: ffff964ec1b35800
FS:  0000000000000000(0000) GS:ffff964ecfc80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffc17ba640 CR3: 000000023058c000 CR4: 00000000000006e0
Call Trace:
 kthread+0x125/0x140
 ? kthread_park+0x60/0x60
 ? do_syscall_64+0x67/0x140
 ret_from_fork+0x25/0x30
Code:  Bad RIP value.
RIP: 0xffffffffc17ba640 RSP: ffffb254414dfe78

CR2: ffffffffc17ba640

Note that zilog-rx-i2c-1 should have exited by now, but hasn't due to the missing put in poll().

This code has been replaced completely in kernel v4.16 by a new driver, see commit acaa34bf06e9 ("media: rc: implement zilog transmitter"), and commit f95367a7b758 ("media: staging: remove lirc_zilog driver").

Cc [email protected] # v4.15- (all up to and including v4.15)
Reported-by Warren Sturm <[email protected]>
Tested-by Warren Sturm <[email protected]>
Signed-off-by Sean Young <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/staging/media/lirc/lirc_zilog.c |    1 +
 1 file changed, 1 insertion(+)
drivers/staging/media/lirc/lirc_zilog.c +1 -0
@@ -1228,6 +1228,7 @@ static unsigned int poll(struct file *fi
 
 	dev_dbg(ir->l.dev, "%s result = %s\n", __func__,
 		ret ? "POLLIN|POLLRDNORM" : "none");
+	put_ir_rx(rx, false);
 	return ret;
 }
author maintainer
#164 lore raw

PATCH 164/164 writeback: safer lock nesting

In reply to Greg Kroah-Hartman

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

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

From: Greg Thelen <[email protected]>

commit 2e898e4c0a3897ccd434adac5abb8330194f527b upstream.

lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if the page's memcg is undergoing move accounting, which occurs when a process leaves its memcg for a new one that has memory.move_charge_at_immigrate set.

unlocked_inode_to_wb_begin,end() use spin_lock_irq/spin_unlock_irq() if the given inode is switching writeback domains. Switches occur when enough writes are issued from a new domain.

This existing pattern is thus suspicious:

    lock_page_memcg(page);
    unlocked_inode_to_wb_begin(inode, &locked);
    ...
    unlocked_inode_to_wb_end(inode, locked);
    unlock_page_memcg(page);

If both inode switch and process memcg migration are both in-flight then unlocked_inode_to_wb_end() will unconditionally enable interrupts while still holding the lock_page_memcg() irq spinlock. This suggests the possibility of deadlock if an interrupt occurs before unlock_page_memcg().

truncate
__cancel_dirty_page
lock_page_memcg
unlocked_inode_to_wb_begin unlocked_inode_to_wb_end
<interrupts mistakenly enabled>
<interrupt> end_page_writeback test_clear_page_writeback lock_page_memcg <deadlock>
unlock_page_memcg

Due to configuration limitations this deadlock is not currently possible because we don't mix cgroup writeback (a cgroupv2 feature) and memory.move_charge_at_immigrate (a cgroupv1 feature).

If the kernel is hacked to always claim inode switching and memcg moving_account, then this script triggers lockup in less than a minute:

cd /mnt/cgroup/memory
mkdir a b
echo 1 > a/memory.move_charge_at_immigrate
echo 1 > b/memory.move_charge_at_immigrate
(
echo $BASHPID > a/cgroup.procs
while true; do
dd if=/dev/zero of=/mnt/big bs=1M count=256
done
) &
while true; do
sync
done &
sleep 1h &
SLEEP=$!
while true; do
echo $SLEEP > a/cgroup.procs
echo $SLEEP > b/cgroup.procs
done

The deadlock does not seem possible, so it's debatable if there's any reason to modify the kernel. I suggest we should to prevent future surprises. And Wang Long said "this deadlock occurs three times in our environment", so there's more reason to apply this, even to stable. Stable 4.4 has minor conflicts applying this patch. For a clean 4.4 patch see "[PATCH for-4.4] writeback: safer lock nesting"
https://lkml.org/lkml/2018/4/11/146

Wang Long said "this deadlock occurs three times in our environment"

[[email protected]: v4]
Link http://lkml.kernel.org/r/[email protected] open here
[[email protected]: comment tweaks, struct initialization simplification]
Change-Id Ibb773e8045852978f6207074491d262f1b3fb613
Link http://lkml.kernel.org/r/[email protected] open here
Fixes 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates")
Signed-off-by Greg Thelen <[email protected]>
Reported-by Wang Long <[email protected]>
Acked-by Wang Long <[email protected]>
Acked-by Michal Hocko <[email protected]>
Reviewed-by Andrew Morton <[email protected]>
Cc Johannes Weiner <[email protected]>
Cc Tejun Heo <[email protected]>
Cc Nicholas Piggin <[email protected]>
Cc <[email protected]> [v4.2+]
Signed-off-by Andrew Morton <[email protected]>
Signed-off-by Linus Torvalds <[email protected]>
[natechancellor: Adjust context due to lack of b93b016313b3b]
Signed-off-by Nathan Chancellor <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 fs/fs-writeback.c                |    7 ++++---
 include/linux/backing-dev-defs.h |    5 +++++
 include/linux/backing-dev.h      |   30 ++++++++++++++++--------------
 mm/page-writeback.c              |   18 +++++++++---------
 4 files changed, 34 insertions(+), 26 deletions(-)
fs/fs-writeback.c +4 -3
@@ -745,11 +745,12 @@ int inode_congested(struct inode *inode,
 	 */
 	if (inode && inode_to_wb_is_valid(inode)) {
 		struct bdi_writeback *wb;
-		bool locked, congested;
+		struct wb_lock_cookie lock_cookie = {};
+		bool congested;
 
-		wb = unlocked_inode_to_wb_begin(inode, &locked);
+		wb = unlocked_inode_to_wb_begin(inode, &lock_cookie);
 		congested = wb_congested(wb, cong_bits);
-		unlocked_inode_to_wb_end(inode, locked);
+		unlocked_inode_to_wb_end(inode, &lock_cookie);
 		return congested;
 	}
include/linux/backing-dev-defs.h +5 -0
@@ -199,6 +199,11 @@ static inline void set_bdi_congested(str
 	set_wb_congested(bdi->wb.congested, sync);
 }
 
+struct wb_lock_cookie {
+	bool locked;
+	unsigned long flags;
+};
+
 #ifdef CONFIG_CGROUP_WRITEBACK
 
 /**
include/linux/backing-dev.h +16 -14
@@ -342,7 +342,7 @@ static inline struct bdi_writeback *inod
 /**
  * unlocked_inode_to_wb_begin - begin unlocked inode wb access transaction
  * @inode: target inode
- * @lockedp: temp bool output param, to be passed to the end function
+ * @cookie: output param, to be passed to the end function
  *
  * The caller wants to access the wb associated with @inode but isn't
  * holding inode->i_lock, mapping->tree_lock or wb->list_lock.  This

@@ -350,12 +350,12 @@ static inline struct bdi_writeback *inod
  * association doesn't change until the transaction is finished with
  * unlocked_inode_to_wb_end().
  *
- * The caller must call unlocked_inode_to_wb_end() with *@lockdep
- * afterwards and can't sleep during transaction.  IRQ may or may not be
- * disabled on return.
+ * The caller must call unlocked_inode_to_wb_end() with *@cookie afterwards and
+ * can't sleep during the transaction.  IRQs may or may not be disabled on
+ * return.
  */
 static inline struct bdi_writeback *
-unlocked_inode_to_wb_begin(struct inode *inode, bool *lockedp)
+unlocked_inode_to_wb_begin(struct inode *inode, struct wb_lock_cookie *cookie)
 {
 	rcu_read_lock();
 

@@ -363,10 +363,10 @@ unlocked_inode_to_wb_begin(struct inode
 	 * Paired with store_release in inode_switch_wb_work_fn() and
 	 * ensures that we see the new wb if we see cleared I_WB_SWITCH.
 	 */
-	*lockedp = smp_load_acquire(&inode->i_state) & I_WB_SWITCH;
+	cookie->locked = smp_load_acquire(&inode->i_state) & I_WB_SWITCH;
 
-	if (unlikely(*lockedp))
-		spin_lock_irq(&inode->i_mapping->tree_lock);
+	if (unlikely(cookie->locked))
+		spin_lock_irqsave(&inode->i_mapping->tree_lock, cookie->flags);
 
 	/*
 	 * Protected by either !I_WB_SWITCH + rcu_read_lock() or tree_lock.

@@ -378,12 +378,13 @@ unlocked_inode_to_wb_begin(struct inode
 /**
  * unlocked_inode_to_wb_end - end inode wb access transaction
  * @inode: target inode
- * @locked: *@lockedp from unlocked_inode_to_wb_begin()
+ * @cookie: @cookie from unlocked_inode_to_wb_begin()
  */
-static inline void unlocked_inode_to_wb_end(struct inode *inode, bool locked)
+static inline void unlocked_inode_to_wb_end(struct inode *inode,
+					    struct wb_lock_cookie *cookie)
 {
-	if (unlikely(locked))
-		spin_unlock_irq(&inode->i_mapping->tree_lock);
+	if (unlikely(cookie->locked))
+		spin_unlock_irqrestore(&inode->i_mapping->tree_lock, cookie->flags);
 
 	rcu_read_unlock();
 }

@@ -430,12 +431,13 @@ static inline struct bdi_writeback *inod
 }
 
 static inline struct bdi_writeback *
-unlocked_inode_to_wb_begin(struct inode *inode, bool *lockedp)
+unlocked_inode_to_wb_begin(struct inode *inode, struct wb_lock_cookie *cookie)
 {
 	return inode_to_wb(inode);
 }
 
-static inline void unlocked_inode_to_wb_end(struct inode *inode, bool locked)
+static inline void unlocked_inode_to_wb_end(struct inode *inode,
+					    struct wb_lock_cookie *cookie)
 {
 }
mm/page-writeback.c +9 -9
@@ -2518,13 +2518,13 @@ void account_page_redirty(struct page *p
 	if (mapping && mapping_cap_account_dirty(mapping)) {
 		struct inode *inode = mapping->host;
 		struct bdi_writeback *wb;
-		bool locked;
+		struct wb_lock_cookie cookie = {};
 
-		wb = unlocked_inode_to_wb_begin(inode, &locked);
+		wb = unlocked_inode_to_wb_begin(inode, &cookie);
 		current->nr_dirtied--;
 		dec_node_page_state(page, NR_DIRTIED);
 		dec_wb_stat(wb, WB_DIRTIED);
-		unlocked_inode_to_wb_end(inode, locked);
+		unlocked_inode_to_wb_end(inode, &cookie);
 	}
 }
 EXPORT_SYMBOL(account_page_redirty);

@@ -2630,15 +2630,15 @@ void cancel_dirty_page(struct page *page
 	if (mapping_cap_account_dirty(mapping)) {
 		struct inode *inode = mapping->host;
 		struct bdi_writeback *wb;
-		bool locked;
+		struct wb_lock_cookie cookie = {};
 
 		lock_page_memcg(page);
-		wb = unlocked_inode_to_wb_begin(inode, &locked);
+		wb = unlocked_inode_to_wb_begin(inode, &cookie);
 
 		if (TestClearPageDirty(page))
 			account_page_cleaned(page, mapping, wb);
 
-		unlocked_inode_to_wb_end(inode, locked);
+		unlocked_inode_to_wb_end(inode, &cookie);
 		unlock_page_memcg(page);
 	} else {
 		ClearPageDirty(page);

@@ -2670,7 +2670,7 @@ int clear_page_dirty_for_io(struct page
 	if (mapping && mapping_cap_account_dirty(mapping)) {
 		struct inode *inode = mapping->host;
 		struct bdi_writeback *wb;
-		bool locked;
+		struct wb_lock_cookie cookie = {};
 
 		/*
 		 * Yes, Virginia, this is indeed insane.

@@ -2707,14 +2707,14 @@ int clear_page_dirty_for_io(struct page
 		 * always locked coming in here, so we get the desired
 		 * exclusion.
 		 */
-		wb = unlocked_inode_to_wb_begin(inode, &locked);
+		wb = unlocked_inode_to_wb_begin(inode, &cookie);
 		if (TestClearPageDirty(page)) {
 			dec_lruvec_page_state(page, NR_FILE_DIRTY);
 			dec_zone_page_state(page, NR_ZONE_WRITE_PENDING);
 			dec_wb_stat(wb, WB_RECLAIMABLE);
 			ret = 1;
 		}
-		unlocked_inode_to_wb_end(inode, locked);
+		unlocked_inode_to_wb_end(inode, &cookie);
 		return ret;
 	}
 	return TestClearPageDirty(page);
CI
#165 lore raw
In reply to Greg Kroah-Hartman
stable-rc/linux-4.14.y boot: 152 boots: 2 failed, 138 passed with 9 offline, 2 untried/unknown, 1 conflict (v4.14.35-165-g7474ba098676)

stable-rc/linux-4.14.y boot: 152 boots: 2 failed, 138 passed with 9 offline, 2 untried/unknown, 1 conflict (v4.14.35-165-g7474ba098676)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.35-165-g7474ba098676/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.35-165-g7474ba098676/

Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.35-165-g7474ba098676
Git Commit: 7474ba098676c3c439800ead8f99f13517e6797b
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 78 unique boards, 23 SoC families, 17 builds out of 185

Boot Regressions Detected:

arm:

    multi_v5_defconfig:
        at91sam9x35ek:
            lab-free-electrons: new failure (last pass: v4.14.34-215-g6c5333913b2c)

    sama5_defconfig:
        sama5d36ek:
            lab-free-electrons: new failure (last pass: v4.14.34-215-g6c5333913b2c)

arm64:

    defconfig:
        r8a7796-m3ulcb:
            lab-baylibre: new failure (last pass: v4.14.34-215-g6c5333913b2c)

Boot Failures Detected:

arm:

sama5_defconfig
sama5d36ek: 1 failed lab

multi_v5_defconfig
at91sam9x35ek: 1 failed lab

Offline Platforms:

arm:

    sunxi_defconfig:
        sun5i-r8-chip: 1 offline lab

    multi_v7_defconfig:
        qcom-apq8064-cm-qs600: 1 offline lab
        qcom-apq8064-ifc6410: 1 offline lab
        sun5i-r8-chip: 1 offline lab
        tegra20-iris-512: 1 offline lab

    qcom_defconfig:
        qcom-apq8064-cm-qs600: 1 offline lab
        qcom-apq8064-ifc6410: 1 offline lab

    tegra_defconfig:
        tegra20-iris-512: 1 offline lab

arm64:

    defconfig:
        apq8016-sbc: 1 offline lab

Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)

arm64:

    defconfig:
        r8a7796-m3ulcb:
            lab-collabora: PASS
            lab-baylibre: FAIL

---
For more info write to <[email protected]>

#166 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.14.36 release. There are 164 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 Tue Apr 24 13:51:05 UTC 2018. Anything received after that time might be too late.

For v4.14.35-165-g7474ba0:

Build results:

	total: 146 pass: 146 fail: 0
Qemu test results:
	total: 141 pass: 141 fail: 0

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

Guenter

author maintainer
#167 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.36 release. There are 164 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.

Quoted 8 lines

Responses should be made by Tue Apr 24 13:51:05 UTC 2018. Anything received after that time might be too late.

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

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.36-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.14.y
and the diffstat can be found below.

There is a -rc3 out now:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.36-rc3.gz

#168 lore raw
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.36 release. There are 164 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 Tue Apr 24 13:51:05 UTC 2018. Anything received after that time might be too late.

Quoted 10 lines
Quoted 5 lines

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

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.36-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.14.y
and the diffstat can be found below.

There is a -rc3 out now:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.36-rc3.gz

rc3 looks good. Compiled and booted on my tests system with no dmesg regression. Please ignore the WARN report on rc1.

thanks,
-- Shuah

#169 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.14.36 release. There are 164 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 Tue Apr 24 13:51:05 UTC 2018. Anything received after that time might be too late.

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

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.36-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted fine. I am seeing the same lock issue I saw on 4.16-4-rc1

new mount options do not match the existing superblock, will be ignored

================================
WARNING: inconsistent lock state
4.14.36-rc1+ #34 Not tainted
--------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/6/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(fs_reclaim){?.+.}, at: [<ffffffff81463b65>] fs_reclaim_acquire.part.77+0x5/0x30
{HARDIRQ-ON-W} state was registered at:

  lock_acquire+0x138/0x3a0
  fs_reclaim_acquire.part.77+0x29/0x30
  __alloc_pages_nodemask+0x24e/0x550
  alloc_page_interleave+0x14/0xf0
  kmalloc_order+0x1f/0x60
  kmalloc_order_trace+0x1d/0x140
  smp_store_boot_cpu_info+0x1e1/0x26d
  native_smp_prepare_cpus+0xe6/0x7ce
  kernel_init_freeable+0x276/0x499
  kernel_init+0xf/0x120
  ret_from_fork+0x3a/0x50
irq event stamp: 79104
hardirqs last  enabled at (79101): [<ffffffff823c362a>] cpuidle_enter_state+0xfa/0x820
hardirqs last disabled at (79102): [<ffffffff82a0093f>] common_interrupt+0x7f/0x84
softirqs last  enabled at (79104): [<ffffffff8111c88b>] irq_enter+0xbb/0xd0
softirqs last disabled at (79103): [<ffffffff8111c870>] irq_enter+0xa0/0xd0

other info that might help us debug this:

 Possible unsafe locking scenario:
       CPU0
       ----
  lock(fs_reclaim);
  <Interrupt>
    lock(fs_reclaim);

*** DEADLOCK ***

no locks held by swapper/6/0.

stack backtrace:
CPU: 6 PID: 0 Comm: swapper/6 Not tainted 4.14.36-rc1+ #34
Hardware name: System76, Inc. Wild Dog Performance/H87-PLUS, BIOS 0705 12/05/2013
Call Trace:
 <IRQ>
 dump_stack+0x67/0x91
 print_usage_bug+0x33c/0x35e
 mark_lock+0xba6/0xf30
 ? check_usage_backwards+0x2c0/0x2c0
 __lock_acquire+0x2049/0x4130
 ? __lock_acquire+0x8bf/0x4130
 ? extract_buf+0x1dc/0x2e0
 ? debug_check_no_locks_freed+0x2a0/0x2a0
 ? debug_check_no_locks_freed+0x2a0/0x2a0
 ? save_trace+0x250/0x250
 ? trace_event_raw_event_xfer_secondary_pool+0x2b0/0x2b0
 ? __wake_up_common+0x4a0/0x4a0
 ? lock_acquire+0x138/0x3a0
 lock_acquire+0x138/0x3a0
 ? fs_reclaim_acquire.part.77+0x5/0x30
 ? lock_acquire+0x3a0/0x3a0
 ? crng_reseed+0x3c6/0x670
 fs_reclaim_acquire.part.77+0x29/0x30
 ? fs_reclaim_acquire.part.77+0x5/0x30
 __kmalloc+0x4b/0x2a0
 crng_reseed+0x3c6/0x670
 ? init_std_data+0x270/0x270
 ? add_interrupt_randomness+0x363/0x5c0
 credit_entropy_bits+0x5a2/0x710
 ? __mix_pool_bytes+0x14d/0x1e0
 add_interrupt_randomness+0x363/0x5c0
 ? extract_entropy.constprop.41+0x260/0x260
 ? rcu_read_lock_sched_held+0xdc/0x110
 handle_irq_event_percpu+0x9a/0x120
 ? __handle_irq_event_percpu+0x640/0x640
 ? lock_acquire+0x138/0x3a0
 ? handle_edge_irq+0x30/0x750
 handle_irq_event+0xa7/0x140
 handle_edge_irq+0x1d4/0x750
 handle_irq+0x44/0x60
 do_IRQ+0x76/0x190
 common_interrupt+0x84/0x84
 </IRQ>
RIP: 0010:cpuidle_enter_state+0xfe/0x820
RSP: 0018:ffff8803cd6f7e20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff9d
RAX: 0000000000000007 RBX: ffffe8ffffd89b80 RCX: 000000032a46c809
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8803cd6e2f2c
RBP: 0000000000000002 R08: ffff8803cfda9ca4 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 000000032a46c809
R13: 0000000000000002 R14: 0000000000000000 R15: 000000032a447e26
 do_idle+0x211/0x2a0
 cpu_startup_entry+0x19/0x20
 start_secondary+0x331/0x420
 ? set_cpu_sibling_map+0x1530/0x1530
 secondary_startup_64+0xa5/0xb0

kauditd_printk_skb: 94 callbacks suppressed

thanks,
-- Shuah

#170 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.14.36 release. There are 164 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 Tue Apr 24 13:51:05 UTC 2018. 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/v4.x/stable-review/patch-4.14.36-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
Few comments inline regarding the reported failures. You may ignore these infrastructure failures.

Summary
------------------------------------------------------------------------

kernel: 4.14.36-rc3
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: c6b7e0921276555df40b59366fb6bf123b5b0816
git describe: v4.14.35-164-gc6b7e0921276
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.35-164-gc6b7e0921276

No regressions (compared to build v4.14.35-165-g7474ba098676)

Boards, architectures and test suites:
-------------------------------------

dragonboard-410c
* boot - pass: 19, fail: 1
^ infrastructure issues
* kselftest - skip: 20, pass: 42, fail: 6
^ kselftest failures caused by kselftest upgrade to 4.16 (in all cases
in this report)
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 57,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 134, pass: 1016,
* ltp-timers-tests - pass: 13,

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 17, pass: 45, fail: 6
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 57,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 135, pass: 1015,
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 18, pass: 44, fail: 6
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 57,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 134, pass: 1016,
* ltp-timers-tests - pass: 13,

qemu_arm
* boot - pass: 15, fail: 5
^ infrastructure issues
* kselftest - skip: 24, pass: 38, fail: 6
* libhugetlbfs - pass: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 62, fail: 2
* ltp-fs-tests - skip: 5, pass: 58,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-securebits-tests - pass: 4,

qemu_arm64
* boot - pass: 20,
* kselftest - skip: 24, pass: 42, fail: 4
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 57,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-securebits-tests - pass: 4,
* ltp-timers-tests - pass: 13,

qemu_x86_64
* boot - pass: 22,
* kselftest - skip: 25, pass: 51, fail: 4
* kselftest-vsyscall-mode-native - skip: 25, pass: 51, fail: 4
* kselftest-vsyscall-mode-none - skip: 25, pass: 51, fail: 4
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 57,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 148, pass: 1002,
* ltp-timers-tests - pass: 13,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 19, pass: 38, fail: 8
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 18, pass: 63,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 5, pass: 58,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 75, pass: 1075,
* ltp-timers-tests - pass: 13,

x86_64
* boot - pass: 22,
* kselftest - skip: 19, pass: 55, fail: 6
* kselftest-vsyscall-mode-native - skip: 19, pass: 54, fail: 7
* kselftest-vsyscall-mode-none - skip: 19, pass: 55, fail: 6
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 5, pass: 58,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 116, pass: 1034,
* ltp-timers-tests - pass: 13,

Signature · 2 lines
Linaro QA (BETA)
https://qa-reports.linaro.org
author maintainer
#171 lore raw
Quoted 16 lines · Naresh Kamboju
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.36 release. There are 164 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 Tue Apr 24 13:51:05 UTC 2018. Anything received after that time might be too late.

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

        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.36-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.14.y
and the diffstat can be found below.

Quoted 6 lines
Quoted 3 lines

thanks,

greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Yeah!

greg k-h