2020-02-03 18:51:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 00/23] 5.5.2-stable review

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

Responses should be made by Wed, 05 Feb 2020 16:17:59 +0000.
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/v5.x/stable-review/patch-5.5.2-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>
Linux 5.5.2-rc1

Michal Koutný <[email protected]>
cgroup: Prevent double killing of css when enabling threaded cgroup

Dan Carpenter <[email protected]>
Bluetooth: Fix race condition in hci_release_sock()

Zhenzhong Duan <[email protected]>
ttyprintk: fix a potential deadlock in interrupt context issue

Tetsuo Handa <[email protected]>
tomoyo: Use atomic_t for statistics counter

Hans Verkuil <[email protected]>
media: dvb-usb/dvb-usb-urb.c: initialize actlen to 0

Hans Verkuil <[email protected]>
media: gspca: zero usb_buf

Sean Young <[email protected]>
media: vp7045: do not read uninitialized values if usb transfer fails

Sean Young <[email protected]>
media: af9005: uninitialized variable printked

Sean Young <[email protected]>
media: digitv: don't continue if remote control state can't be read

Jan Kara <[email protected]>
reiserfs: Fix memory leak of journal device string

Dan Carpenter <[email protected]>
mm/mempolicy.c: fix out of bounds write in mpol_parse_str()

Dirk Behme <[email protected]>
arm64: kbuild: remove compressed images on 'make ARCH=arm64 (dist)clean'

Vitaly Chikunov <[email protected]>
tools lib: Fix builds when glibc contains strlcpy()

Chanwoo Choi <[email protected]>
PM / devfreq: Add new name attribute for sysfs

Andres Freund <[email protected]>
perf c2c: Fix return type for histogram sorting comparision functions

Andy Shevchenko <[email protected]>
lib/test_bitmap: correct test data offsets for 32-bit

Andreas Gruenbacher <[email protected]>
gfs2: Another gfs2_find_jhead fix

David Michael <[email protected]>
KVM: PPC: Book3S PR: Fix -Werror=return-type build failure

Xiaochen Shen <[email protected]>
x86/resctrl: Fix use-after-free due to inaccurate refcount of rdtgroup

Xiaochen Shen <[email protected]>
x86/resctrl: Fix use-after-free when deleting resource groups

Xiaochen Shen <[email protected]>
x86/resctrl: Fix a deadlock due to inaccurate reference

Ronnie Sahlberg <[email protected]>
cifs: fix soft mounts hanging in the reconnect code

Al Viro <[email protected]>
vfs: fix do_last() regression


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

Diffstat:

Documentation/ABI/testing/sysfs-class-devfreq | 7 +++
Makefile | 4 +-
arch/arm64/boot/Makefile | 2 +-
arch/powerpc/kvm/book3s_pr.c | 1 +
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 32 ++++++++-----
drivers/char/ttyprintk.c | 15 +++---
drivers/devfreq/devfreq.c | 9 ++++
drivers/media/usb/dvb-usb/af9005.c | 2 +-
drivers/media/usb/dvb-usb/digitv.c | 10 ++--
drivers/media/usb/dvb-usb/dvb-usb-urb.c | 2 +-
drivers/media/usb/dvb-usb/vp7045.c | 21 ++++++---
drivers/media/usb/gspca/gspca.c | 2 +-
fs/cifs/smb2pdu.c | 2 +-
fs/gfs2/lops.c | 68 +++++++++++++++++----------
fs/namei.c | 4 +-
fs/reiserfs/super.c | 2 +
kernel/cgroup/cgroup.c | 11 +++--
lib/test_bitmap.c | 9 ++--
mm/mempolicy.c | 6 +--
net/bluetooth/hci_sock.c | 3 ++
security/tomoyo/common.c | 11 ++---
tools/include/linux/string.h | 8 ++++
tools/lib/string.c | 7 +++
tools/perf/builtin-c2c.c | 10 ++--
24 files changed, 164 insertions(+), 84 deletions(-)



2020-02-03 18:51:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 19/23] media: dvb-usb/dvb-usb-urb.c: initialize actlen to 0

From: Hans Verkuil <[email protected]>

commit 569bc8d6a6a50acb5fcf07fb10b8d2d461fdbf93 upstream.

This fixes a syzbot failure since actlen could be uninitialized,
but it was still used.

Syzbot link:

https://syzkaller.appspot.com/bug?extid=6bf9606ee955b646c0e1

Reported-and-tested-by: [email protected]

Signed-off-by: Hans Verkuil <[email protected]>
Acked-by: Sean Young <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/usb/dvb-usb/dvb-usb-urb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/usb/dvb-usb/dvb-usb-urb.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-urb.c
@@ -12,7 +12,7 @@
int dvb_usb_generic_rw(struct dvb_usb_device *d, u8 *wbuf, u16 wlen, u8 *rbuf,
u16 rlen, int delay_ms)
{
- int actlen,ret = -ENOMEM;
+ int actlen = 0, ret = -ENOMEM;

if (!d || wbuf == NULL || wlen == 0)
return -EINVAL;


2020-02-03 18:52:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 05/23] x86/resctrl: Fix use-after-free due to inaccurate refcount of rdtgroup

From: Xiaochen Shen <[email protected]>

[ Upstream commit 074fadee59ee7a9d2b216e9854bd4efb5dad679f ]

There is a race condition in the following scenario which results in an
use-after-free issue when reading a monitoring file and deleting the
parent ctrl_mon group concurrently:

Thread 1 calls atomic_inc() to take refcount of rdtgrp and then calls
kernfs_break_active_protection() to drop the active reference of kernfs
node in rdtgroup_kn_lock_live().

In Thread 2, kernfs_remove() is a blocking routine. It waits on all sub
kernfs nodes to drop the active reference when removing all subtree
kernfs nodes recursively. Thread 2 could block on kernfs_remove() until
Thread 1 calls kernfs_break_active_protection(). Only after
kernfs_remove() completes the refcount of rdtgrp could be trusted.

Before Thread 1 calls atomic_inc() and kernfs_break_active_protection(),
Thread 2 could call kfree() when the refcount of rdtgrp (sentry) is 0
instead of 1 due to the race.

In Thread 1, in rdtgroup_kn_unlock(), referring to earlier rdtgrp memory
(rdtgrp->waitcount) which was already freed in Thread 2 results in
use-after-free issue.

Thread 1 (rdtgroup_mondata_show) Thread 2 (rdtgroup_rmdir)
-------------------------------- -------------------------
rdtgroup_kn_lock_live
/*
* kn active protection until
* kernfs_break_active_protection(kn)
*/
rdtgrp = kernfs_to_rdtgroup(kn)
rdtgroup_kn_lock_live
atomic_inc(&rdtgrp->waitcount)
mutex_lock
rdtgroup_rmdir_ctrl
free_all_child_rdtgrp
/*
* sentry->waitcount should be 1
* but is 0 now due to the race.
*/
kfree(sentry)*[1]
/*
* Only after kernfs_remove()
* completes, the refcount of
* rdtgrp could be trusted.
*/
atomic_inc(&rdtgrp->waitcount)
/* kn->active-- */
kernfs_break_active_protection(kn)
rdtgroup_ctrl_remove
rdtgrp->flags = RDT_DELETED
/*
* Blocking routine, wait for
* all sub kernfs nodes to drop
* active reference in
* kernfs_break_active_protection.
*/
kernfs_remove(rdtgrp->kn)
rdtgroup_kn_unlock
mutex_unlock
atomic_dec_and_test(
&rdtgrp->waitcount)
&& (flags & RDT_DELETED)
kernfs_unbreak_active_protection(kn)
kfree(rdtgrp)
mutex_lock
mon_event_read
rdtgroup_kn_unlock
mutex_unlock
/*
* Use-after-free: refer to earlier rdtgrp
* memory which was freed in [1].
*/
atomic_dec_and_test(&rdtgrp->waitcount)
&& (flags & RDT_DELETED)
/* kn->active++ */
kernfs_unbreak_active_protection(kn)
kfree(rdtgrp)

Fix it by moving free_all_child_rdtgrp() to after kernfs_remove() in
rdtgroup_rmdir_ctrl() to ensure it has the accurate refcount of rdtgrp.

Fixes: f3cbeacaa06e ("x86/intel_rdt/cqm: Add rmdir support")
Suggested-by: Reinette Chatre <[email protected]>
Signed-off-by: Xiaochen Shen <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Reinette Chatre <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index c7564294a12a8..954fd048ad9bd 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -2960,13 +2960,13 @@ static int rdtgroup_rmdir_ctrl(struct kernfs_node *kn, struct rdtgroup *rdtgrp,
closid_free(rdtgrp->closid);
free_rmid(rdtgrp->mon.rmid);

+ rdtgroup_ctrl_remove(kn, rdtgrp);
+
/*
* Free all the child monitor group rmids.
*/
free_all_child_rdtgrp(rdtgrp);

- rdtgroup_ctrl_remove(kn, rdtgrp);
-
return 0;
}

--
2.20.1



2020-02-03 18:52:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 02/23] cifs: fix soft mounts hanging in the reconnect code

From: Ronnie Sahlberg <[email protected]>

commit c54849ddd832ae0a45cab16bcd1ed2db7da090d7 upstream.

RHBZ: 1795429

In recent DFS updates we have a new variable controlling how many times we will
retry to reconnect the share.
If DFS is not used, then this variable is initialized to 0 in:

static inline int
dfs_cache_get_nr_tgts(const struct dfs_cache_tgt_list *tl)
{
return tl ? tl->tl_numtgts : 0;
}

This means that in the reconnect loop in smb2_reconnect() we will immediately wrap retries to -1
and never actually get to pass this conditional:

if (--retries)
continue;

The effect is that we no longer reach the point where we fail the commands with -EHOSTDOWN
and basically the kernel threads are virtually hung and unkillable.

Fixes: a3a53b7603798fd8 (cifs: Add support for failover in smb2_reconnect())
Signed-off-by: Ronnie Sahlberg <[email protected]>
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
CC: Stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -312,7 +312,7 @@ smb2_reconnect(__le16 smb2_command, stru
if (server->tcpStatus != CifsNeedReconnect)
break;

- if (--retries)
+ if (retries && --retries)
continue;

/*


2020-02-03 18:52:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 07/23] gfs2: Another gfs2_find_jhead fix

From: Andreas Gruenbacher <[email protected]>

commit eed0f953b90e86e765197a1dad06bb48aedc27fe upstream.

On filesystems with a block size smaller than the page size,
gfs2_find_jhead can split a page across two bios (for example, when
blocks are not allocated consecutively). When that happens, the first
bio that completes will unlock the page in its bi_end_io handler even
though the page hasn't been read completely yet. Fix that by using a
chained bio for the rest of the page.

While at it, clean up the sector calculation logic in
gfs2_log_alloc_bio. In gfs2_find_jhead, simplify the disk block and
offset calculation logic and fix a variable name.

Fixes: f4686c26ecc3 ("gfs2: read journal in large chunks")
Cc: [email protected] # v5.2+
Signed-off-by: Andreas Gruenbacher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/gfs2/lops.c | 68 ++++++++++++++++++++++++++++++++++++---------------------
1 file changed, 44 insertions(+), 24 deletions(-)

--- a/fs/gfs2/lops.c
+++ b/fs/gfs2/lops.c
@@ -259,7 +259,7 @@ static struct bio *gfs2_log_alloc_bio(st
struct super_block *sb = sdp->sd_vfs;
struct bio *bio = bio_alloc(GFP_NOIO, BIO_MAX_PAGES);

- bio->bi_iter.bi_sector = blkno * (sb->s_blocksize >> 9);
+ bio->bi_iter.bi_sector = blkno << (sb->s_blocksize_bits - 9);
bio_set_dev(bio, sb->s_bdev);
bio->bi_end_io = end_io;
bio->bi_private = sdp;
@@ -472,6 +472,20 @@ static void gfs2_jhead_process_page(stru
put_page(page); /* Once more for find_or_create_page */
}

+static struct bio *gfs2_chain_bio(struct bio *prev, unsigned int nr_iovecs)
+{
+ struct bio *new;
+
+ new = bio_alloc(GFP_NOIO, nr_iovecs);
+ bio_copy_dev(new, prev);
+ new->bi_iter.bi_sector = bio_end_sector(prev);
+ new->bi_opf = prev->bi_opf;
+ new->bi_write_hint = prev->bi_write_hint;
+ bio_chain(new, prev);
+ submit_bio(prev);
+ return new;
+}
+
/**
* gfs2_find_jhead - find the head of a log
* @jd: The journal descriptor
@@ -488,15 +502,15 @@ int gfs2_find_jhead(struct gfs2_jdesc *j
struct gfs2_sbd *sdp = GFS2_SB(jd->jd_inode);
struct address_space *mapping = jd->jd_inode->i_mapping;
unsigned int block = 0, blocks_submitted = 0, blocks_read = 0;
- unsigned int bsize = sdp->sd_sb.sb_bsize;
+ unsigned int bsize = sdp->sd_sb.sb_bsize, off;
unsigned int bsize_shift = sdp->sd_sb.sb_bsize_shift;
unsigned int shift = PAGE_SHIFT - bsize_shift;
- unsigned int readhead_blocks = BIO_MAX_PAGES << shift;
+ unsigned int readahead_blocks = BIO_MAX_PAGES << shift;
struct gfs2_journal_extent *je;
int sz, ret = 0;
struct bio *bio = NULL;
struct page *page = NULL;
- bool done = false;
+ bool bio_chained = false, done = false;
errseq_t since;

memset(head, 0, sizeof(*head));
@@ -505,9 +519,9 @@ int gfs2_find_jhead(struct gfs2_jdesc *j

since = filemap_sample_wb_err(mapping);
list_for_each_entry(je, &jd->extent_list, list) {
- for (; block < je->lblock + je->blocks; block++) {
- u64 dblock;
+ u64 dblock = je->dblock;

+ for (; block < je->lblock + je->blocks; block++, dblock++) {
if (!page) {
page = find_or_create_page(mapping,
block >> shift, GFP_NOFS);
@@ -516,35 +530,41 @@ int gfs2_find_jhead(struct gfs2_jdesc *j
done = true;
goto out;
}
+ off = 0;
}

- if (bio) {
- unsigned int off;
-
- off = (block << bsize_shift) & ~PAGE_MASK;
+ if (!bio || (bio_chained && !off)) {
+ /* start new bio */
+ } else {
sz = bio_add_page(bio, page, bsize, off);
- if (sz == bsize) { /* block added */
- if (off + bsize == PAGE_SIZE) {
- page = NULL;
- goto page_added;
- }
- continue;
+ if (sz == bsize)
+ goto block_added;
+ if (off) {
+ unsigned int blocks =
+ (PAGE_SIZE - off) >> bsize_shift;
+
+ bio = gfs2_chain_bio(bio, blocks);
+ bio_chained = true;
+ goto add_block_to_new_bio;
}
+ }
+
+ if (bio) {
blocks_submitted = block + 1;
submit_bio(bio);
- bio = NULL;
}

- dblock = je->dblock + (block - je->lblock);
bio = gfs2_log_alloc_bio(sdp, dblock, gfs2_end_log_read);
bio->bi_opf = REQ_OP_READ;
- sz = bio_add_page(bio, page, bsize, 0);
- gfs2_assert_warn(sdp, sz == bsize);
- if (bsize == PAGE_SIZE)
+ bio_chained = false;
+add_block_to_new_bio:
+ sz = bio_add_page(bio, page, bsize, off);
+ BUG_ON(sz != bsize);
+block_added:
+ off += bsize;
+ if (off == PAGE_SIZE)
page = NULL;
-
-page_added:
- if (blocks_submitted < blocks_read + readhead_blocks) {
+ if (blocks_submitted < blocks_read + readahead_blocks) {
/* Keep at least one bio in flight */
continue;
}


2020-02-03 18:52:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 04/23] x86/resctrl: Fix use-after-free when deleting resource groups

From: Xiaochen Shen <[email protected]>

[ Upstream commit b8511ccc75c033f6d54188ea4df7bf1e85778740 ]

A resource group (rdtgrp) contains a reference count (rdtgrp->waitcount)
that indicates how many waiters expect this rdtgrp to exist. Waiters
could be waiting on rdtgroup_mutex or some work sitting on a task's
workqueue for when the task returns from kernel mode or exits.

The deletion of a rdtgrp is intended to have two phases:

(1) while holding rdtgroup_mutex the necessary cleanup is done and
rdtgrp->flags is set to RDT_DELETED,

(2) after releasing the rdtgroup_mutex, the rdtgrp structure is freed
only if there are no waiters and its flag is set to RDT_DELETED. Upon
gaining access to rdtgroup_mutex or rdtgrp, a waiter is required to check
for the RDT_DELETED flag.

When unmounting the resctrl file system or deleting ctrl_mon groups,
all of the subdirectories are removed and the data structure of rdtgrp
is forcibly freed without checking rdtgrp->waitcount. If at this point
there was a waiter on rdtgrp then a use-after-free issue occurs when the
waiter starts running and accesses the rdtgrp structure it was waiting
on.

See kfree() calls in [1], [2] and [3] in these two call paths in
following scenarios:
(1) rdt_kill_sb() -> rmdir_all_sub() -> free_all_child_rdtgrp()
(2) rdtgroup_rmdir() -> rdtgroup_rmdir_ctrl() -> free_all_child_rdtgrp()

There are several scenarios that result in use-after-free issue in
following:

Scenario 1:
-----------
In Thread 1, rdtgroup_tasks_write() adds a task_work callback
move_myself(). If move_myself() is scheduled to execute after Thread 2
rdt_kill_sb() is finished, referring to earlier rdtgrp memory
(rdtgrp->waitcount) which was already freed in Thread 2 results in
use-after-free issue.

Thread 1 (rdtgroup_tasks_write) Thread 2 (rdt_kill_sb)
------------------------------- ----------------------
rdtgroup_kn_lock_live
atomic_inc(&rdtgrp->waitcount)
mutex_lock
rdtgroup_move_task
__rdtgroup_move_task
/*
* Take an extra refcount, so rdtgrp cannot be freed
* before the call back move_myself has been invoked
*/
atomic_inc(&rdtgrp->waitcount)
/* Callback move_myself will be scheduled for later */
task_work_add(move_myself)
rdtgroup_kn_unlock
mutex_unlock
atomic_dec_and_test(&rdtgrp->waitcount)
&& (flags & RDT_DELETED)
mutex_lock
rmdir_all_sub
/*
* sentry and rdtgrp are freed
* without checking refcount
*/
free_all_child_rdtgrp
kfree(sentry)*[1]
kfree(rdtgrp)*[2]
mutex_unlock
/*
* Callback is scheduled to execute
* after rdt_kill_sb is finished
*/
move_myself
/*
* Use-after-free: refer to earlier rdtgrp
* memory which was freed in [1] or [2].
*/
atomic_dec_and_test(&rdtgrp->waitcount)
&& (flags & RDT_DELETED)
kfree(rdtgrp)

Scenario 2:
-----------
In Thread 1, rdtgroup_tasks_write() adds a task_work callback
move_myself(). If move_myself() is scheduled to execute after Thread 2
rdtgroup_rmdir() is finished, referring to earlier rdtgrp memory
(rdtgrp->waitcount) which was already freed in Thread 2 results in
use-after-free issue.

Thread 1 (rdtgroup_tasks_write) Thread 2 (rdtgroup_rmdir)
------------------------------- -------------------------
rdtgroup_kn_lock_live
atomic_inc(&rdtgrp->waitcount)
mutex_lock
rdtgroup_move_task
__rdtgroup_move_task
/*
* Take an extra refcount, so rdtgrp cannot be freed
* before the call back move_myself has been invoked
*/
atomic_inc(&rdtgrp->waitcount)
/* Callback move_myself will be scheduled for later */
task_work_add(move_myself)
rdtgroup_kn_unlock
mutex_unlock
atomic_dec_and_test(&rdtgrp->waitcount)
&& (flags & RDT_DELETED)
rdtgroup_kn_lock_live
atomic_inc(&rdtgrp->waitcount)
mutex_lock
rdtgroup_rmdir_ctrl
free_all_child_rdtgrp
/*
* sentry is freed without
* checking refcount
*/
kfree(sentry)*[3]
rdtgroup_ctrl_remove
rdtgrp->flags = RDT_DELETED
rdtgroup_kn_unlock
mutex_unlock
atomic_dec_and_test(
&rdtgrp->waitcount)
&& (flags & RDT_DELETED)
kfree(rdtgrp)
/*
* Callback is scheduled to execute
* after rdt_kill_sb is finished
*/
move_myself
/*
* Use-after-free: refer to earlier rdtgrp
* memory which was freed in [3].
*/
atomic_dec_and_test(&rdtgrp->waitcount)
&& (flags & RDT_DELETED)
kfree(rdtgrp)

If CONFIG_DEBUG_SLAB=y, Slab corruption on kmalloc-2k can be observed
like following. Note that "0x6b" is POISON_FREE after kfree(). The
corrupted bits "0x6a", "0x64" at offset 0x424 correspond to
waitcount member of struct rdtgroup which was freed:

Slab corruption (Not tainted): kmalloc-2k start=ffff9504c5b0d000, len=2048
420: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkjkkkkkkkkkkk
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Next obj: start=ffff9504c5b0d800, len=2048
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk

Slab corruption (Not tainted): kmalloc-2k start=ffff9504c58ab800, len=2048
420: 6b 6b 6b 6b 64 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkdkkkkkkkkkkk
Prev obj: start=ffff9504c58ab000, len=2048
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk

Fix this by taking reference count (waitcount) of rdtgrp into account in
the two call paths that currently do not do so. Instead of always
freeing the resource group it will only be freed if there are no waiters
on it. If there are waiters, the resource group will have its flags set
to RDT_DELETED.

It will be left to the waiter to free the resource group when it starts
running and finding that it was the last waiter and the resource group
has been removed (rdtgrp->flags & RDT_DELETED) since. (1) rdt_kill_sb()
-> rmdir_all_sub() -> free_all_child_rdtgrp() (2) rdtgroup_rmdir() ->
rdtgroup_rmdir_ctrl() -> free_all_child_rdtgrp()

Fixes: f3cbeacaa06e ("x86/intel_rdt/cqm: Add rmdir support")
Fixes: 60cf5e101fd4 ("x86/intel_rdt: Add mkdir to resctrl file system")
Suggested-by: Reinette Chatre <[email protected]>
Signed-off-by: Xiaochen Shen <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Reinette Chatre <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index e4da26325e3ea..c7564294a12a8 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -2205,7 +2205,11 @@ static void free_all_child_rdtgrp(struct rdtgroup *rdtgrp)
list_for_each_entry_safe(sentry, stmp, head, mon.crdtgrp_list) {
free_rmid(sentry->mon.rmid);
list_del(&sentry->mon.crdtgrp_list);
- kfree(sentry);
+
+ if (atomic_read(&sentry->waitcount) != 0)
+ sentry->flags = RDT_DELETED;
+ else
+ kfree(sentry);
}
}

@@ -2243,7 +2247,11 @@ static void rmdir_all_sub(void)

kernfs_remove(rdtgrp->kn);
list_del(&rdtgrp->rdtgroup_list);
- kfree(rdtgrp);
+
+ if (atomic_read(&rdtgrp->waitcount) != 0)
+ rdtgrp->flags = RDT_DELETED;
+ else
+ kfree(rdtgrp);
}
/* Notify online CPUs to update per cpu storage and PQR_ASSOC MSR */
update_closid_rmid(cpu_online_mask, &rdtgroup_default);
--
2.20.1



2020-02-03 18:52:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 08/23] lib/test_bitmap: correct test data offsets for 32-bit

From: Andy Shevchenko <[email protected]>

commit 69334ca530da80c1563ac6a3bd32afa40884ccd3 upstream.

On 32-bit platform the size of long is only 32 bits which makes wrong
offset in the array of 64 bit size.

Calculate offset based on BITS_PER_LONG.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: 30544ed5de43 ("lib/bitmap: introduce bitmap_replace() helper")
Signed-off-by: Andy Shevchenko <[email protected]>
Reported-by: Guenter Roeck <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Cc: Yury Norov <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
lib/test_bitmap.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -275,22 +275,23 @@ static void __init test_copy(void)
static void __init test_replace(void)
{
unsigned int nbits = 64;
+ unsigned int nlongs = DIV_ROUND_UP(nbits, BITS_PER_LONG);
DECLARE_BITMAP(bmap, 1024);

bitmap_zero(bmap, 1024);
- bitmap_replace(bmap, &exp2[0], &exp2[1], exp2_to_exp3_mask, nbits);
+ bitmap_replace(bmap, &exp2[0 * nlongs], &exp2[1 * nlongs], exp2_to_exp3_mask, nbits);
expect_eq_bitmap(bmap, exp3_0_1, nbits);

bitmap_zero(bmap, 1024);
- bitmap_replace(bmap, &exp2[1], &exp2[0], exp2_to_exp3_mask, nbits);
+ bitmap_replace(bmap, &exp2[1 * nlongs], &exp2[0 * nlongs], exp2_to_exp3_mask, nbits);
expect_eq_bitmap(bmap, exp3_1_0, nbits);

bitmap_fill(bmap, 1024);
- bitmap_replace(bmap, &exp2[0], &exp2[1], exp2_to_exp3_mask, nbits);
+ bitmap_replace(bmap, &exp2[0 * nlongs], &exp2[1 * nlongs], exp2_to_exp3_mask, nbits);
expect_eq_bitmap(bmap, exp3_0_1, nbits);

bitmap_fill(bmap, 1024);
- bitmap_replace(bmap, &exp2[1], &exp2[0], exp2_to_exp3_mask, nbits);
+ bitmap_replace(bmap, &exp2[1 * nlongs], &exp2[0 * nlongs], exp2_to_exp3_mask, nbits);
expect_eq_bitmap(bmap, exp3_1_0, nbits);
}



2020-02-03 18:52:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 17/23] media: vp7045: do not read uninitialized values if usb transfer fails

From: Sean Young <[email protected]>

commit 26cff637121d8bb866ebd6515c430ac890e6ec80 upstream.

It is not a fatal error if reading the mac address or the remote control
decoder state fails.

Reported-by: [email protected]
Signed-off-by: Sean Young <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/usb/dvb-usb/vp7045.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)

--- a/drivers/media/usb/dvb-usb/vp7045.c
+++ b/drivers/media/usb/dvb-usb/vp7045.c
@@ -96,10 +96,14 @@ static int vp7045_power_ctrl(struct dvb_

static int vp7045_rc_query(struct dvb_usb_device *d)
{
+ int ret;
u8 key;
- vp7045_usb_op(d,RC_VAL_READ,NULL,0,&key,1,20);

- deb_rc("remote query key: %x %d\n",key,key);
+ ret = vp7045_usb_op(d, RC_VAL_READ, NULL, 0, &key, 1, 20);
+ if (ret)
+ return ret;
+
+ deb_rc("remote query key: %x\n", key);

if (key != 0x44) {
/*
@@ -115,15 +119,18 @@ static int vp7045_rc_query(struct dvb_us

static int vp7045_read_eeprom(struct dvb_usb_device *d,u8 *buf, int len, int offset)
{
- int i = 0;
- u8 v,br[2];
+ int i, ret;
+ u8 v, br[2];
for (i=0; i < len; i++) {
v = offset + i;
- vp7045_usb_op(d,GET_EE_VALUE,&v,1,br,2,5);
+ ret = vp7045_usb_op(d, GET_EE_VALUE, &v, 1, br, 2, 5);
+ if (ret)
+ return ret;
+
buf[i] = br[1];
}
- deb_info("VP7045 EEPROM read (offs: %d, len: %d) : ",offset, i);
- debug_dump(buf,i,deb_info);
+ deb_info("VP7045 EEPROM read (offs: %d, len: %d) : ", offset, i);
+ debug_dump(buf, i, deb_info);
return 0;
}



2020-02-03 18:52:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 12/23] arm64: kbuild: remove compressed images on make ARCH=arm64 (dist)clean

From: Dirk Behme <[email protected]>

commit d7bbd6c1b01cb5dd13c245d4586a83145c1d5f52 upstream.

Since v4.3-rc1 commit 0723c05fb75e44 ("arm64: enable more compressed
Image formats"), it is possible to build Image.{bz2,lz4,lzma,lzo}
AArch64 images. However, the commit missed adding support for removing
those images on 'make ARCH=arm64 (dist)clean'.

Fix this by adding them to the target list.
Make sure to match the order of the recipes in the makefile.

Cc: [email protected] # v4.3+
Fixes: 0723c05fb75e44 ("arm64: enable more compressed Image formats")
Signed-off-by: Dirk Behme <[email protected]>
Signed-off-by: Eugeniu Rosca <[email protected]>
Reviewed-by: Masahiro Yamada <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/boot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
@@ -16,7 +16,7 @@

OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S

-targets := Image Image.gz
+targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo

$(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)


2020-02-03 18:52:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 22/23] Bluetooth: Fix race condition in hci_release_sock()

From: Dan Carpenter <[email protected]>

commit 11eb85ec42dc8c7a7ec519b90ccf2eeae9409de8 upstream.

Syzbot managed to trigger a use after free "KASAN: use-after-free Write
in hci_sock_bind". I have reviewed the code manually and one possibly
cause I have found is that we are not holding lock_sock(sk) when we do
the hci_dev_put(hdev) in hci_sock_release(). My theory is that the bind
and the release are racing against each other which results in this use
after free.

Reported-by: [email protected]
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/bluetooth/hci_sock.c | 3 +++
1 file changed, 3 insertions(+)

--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -831,6 +831,8 @@ static int hci_sock_release(struct socke
if (!sk)
return 0;

+ lock_sock(sk);
+
switch (hci_pi(sk)->channel) {
case HCI_CHANNEL_MONITOR:
atomic_dec(&monitor_promisc);
@@ -878,6 +880,7 @@ static int hci_sock_release(struct socke
skb_queue_purge(&sk->sk_receive_queue);
skb_queue_purge(&sk->sk_write_queue);

+ release_sock(sk);
sock_put(sk);
return 0;
}


2020-02-03 18:53:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 06/23] KVM: PPC: Book3S PR: Fix -Werror=return-type build failure

From: David Michael <[email protected]>

[ Upstream commit fd24a8624eb29d3b6b7df68096ce0321b19b03c6 ]

Fixes: 3a167beac07c ("kvm: powerpc: Add kvmppc_ops callback")
Signed-off-by: David Michael <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/powerpc/kvm/book3s_pr.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index ce4fcf76e53e9..eb86a2f26986f 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -2030,6 +2030,7 @@ static int kvm_vm_ioctl_get_smmu_info_pr(struct kvm *kvm,
{
/* We should not get called */
BUG();
+ return 0;
}
#endif /* CONFIG_PPC64 */

--
2.20.1



2020-02-03 18:53:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 14/23] reiserfs: Fix memory leak of journal device string

From: Jan Kara <[email protected]>

commit 5474ca7da6f34fa95e82edc747d5faa19cbdfb5c upstream.

When a filesystem is mounted with jdev mount option, we store the
journal device name in an allocated string in superblock. However we
fail to ever free that string. Fix it.

Reported-by: [email protected]
Fixes: c3aa077648e1 ("reiserfs: Properly display mount options in /proc/mounts")
CC: [email protected]
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/reiserfs/super.c | 2 ++
1 file changed, 2 insertions(+)

--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -629,6 +629,7 @@ static void reiserfs_put_super(struct su
reiserfs_write_unlock(s);
mutex_destroy(&REISERFS_SB(s)->lock);
destroy_workqueue(REISERFS_SB(s)->commit_wq);
+ kfree(REISERFS_SB(s)->s_jdev);
kfree(s->s_fs_info);
s->s_fs_info = NULL;
}
@@ -2240,6 +2241,7 @@ error_unlocked:
kfree(qf_names[j]);
}
#endif
+ kfree(sbi->s_jdev);
kfree(sbi);

s->s_fs_info = NULL;


2020-02-03 18:53:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 13/23] mm/mempolicy.c: fix out of bounds write in mpol_parse_str()

From: Dan Carpenter <[email protected]>

commit c7a91bc7c2e17e0a9c8b9745a2cb118891218fd1 upstream.

What we are trying to do is change the '=' character to a NUL terminator
and then at the end of the function we restore it back to an '='. The
problem is there are two error paths where we jump to the end of the
function before we have replaced the '=' with NUL.

We end up putting the '=' in the wrong place (possibly one element
before the start of the buffer).

Link: http://lkml.kernel.org/r/[email protected]
Reported-by: [email protected]
Fixes: 095f1fc4ebf3 ("mempolicy: rework shmem mpol parsing and display")
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Dmitry Vyukov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Dan Carpenter <[email protected]>
Cc: Lee Schermerhorn <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/mempolicy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2821,6 +2821,9 @@ int mpol_parse_str(char *str, struct mem
char *flags = strchr(str, '=');
int err = 1, mode;

+ if (flags)
+ *flags++ = '\0'; /* terminate mode string */
+
if (nodelist) {
/* NUL-terminate mode or flags string */
*nodelist++ = '\0';
@@ -2831,9 +2834,6 @@ int mpol_parse_str(char *str, struct mem
} else
nodes_clear(nodes);

- if (flags)
- *flags++ = '\0'; /* terminate mode string */
-
mode = match_string(policy_modes, MPOL_MAX, str);
if (mode < 0)
goto out;


2020-02-03 19:06:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.5 21/23] ttyprintk: fix a potential deadlock in interrupt context issue

From: Zhenzhong Duan <[email protected]>

commit 9a655c77ff8fc65699a3f98e237db563b37c439b upstream.

tpk_write()/tpk_close() could be interrupted when holding a mutex, then
in timer handler tpk_write() may be called again trying to acquire same
mutex, lead to deadlock.

Google syzbot reported this issue with CONFIG_DEBUG_ATOMIC_SLEEP
enabled:

BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:938
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/1
1 lock held by swapper/1/0:
...
Call Trace:
<IRQ>
dump_stack+0x197/0x210
___might_sleep.cold+0x1fb/0x23e
__might_sleep+0x95/0x190
__mutex_lock+0xc5/0x13c0
mutex_lock_nested+0x16/0x20
tpk_write+0x5d/0x340
resync_tnc+0x1b6/0x320
call_timer_fn+0x1ac/0x780
run_timer_softirq+0x6c3/0x1790
__do_softirq+0x262/0x98c
irq_exit+0x19b/0x1e0
smp_apic_timer_interrupt+0x1a3/0x610
apic_timer_interrupt+0xf/0x20
</IRQ>

See link https://syzkaller.appspot.com/bug?extid=2eeef62ee31f9460ad65 for
more details.

Fix it by using spinlock in process context instead of mutex and having
interrupt disabled in critical section.

Reported-by: [email protected]
Signed-off-by: Zhenzhong Duan <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/char/ttyprintk.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)

--- a/drivers/char/ttyprintk.c
+++ b/drivers/char/ttyprintk.c
@@ -15,10 +15,11 @@
#include <linux/serial.h>
#include <linux/tty.h>
#include <linux/module.h>
+#include <linux/spinlock.h>

struct ttyprintk_port {
struct tty_port port;
- struct mutex port_write_mutex;
+ spinlock_t spinlock;
};

static struct ttyprintk_port tpk_port;
@@ -99,11 +100,12 @@ static int tpk_open(struct tty_struct *t
static void tpk_close(struct tty_struct *tty, struct file *filp)
{
struct ttyprintk_port *tpkp = tty->driver_data;
+ unsigned long flags;

- mutex_lock(&tpkp->port_write_mutex);
+ spin_lock_irqsave(&tpkp->spinlock, flags);
/* flush tpk_printk buffer */
tpk_printk(NULL, 0);
- mutex_unlock(&tpkp->port_write_mutex);
+ spin_unlock_irqrestore(&tpkp->spinlock, flags);

tty_port_close(&tpkp->port, tty, filp);
}
@@ -115,13 +117,14 @@ static int tpk_write(struct tty_struct *
const unsigned char *buf, int count)
{
struct ttyprintk_port *tpkp = tty->driver_data;
+ unsigned long flags;
int ret;


/* exclusive use of tpk_printk within this tty */
- mutex_lock(&tpkp->port_write_mutex);
+ spin_lock_irqsave(&tpkp->spinlock, flags);
ret = tpk_printk(buf, count);
- mutex_unlock(&tpkp->port_write_mutex);
+ spin_unlock_irqrestore(&tpkp->spinlock, flags);

return ret;
}
@@ -171,7 +174,7 @@ static int __init ttyprintk_init(void)
{
int ret = -ENOMEM;

- mutex_init(&tpk_port.port_write_mutex);
+ spin_lock_init(&tpk_port.spinlock);

ttyprintk_driver = tty_alloc_driver(1,
TTY_DRIVER_RESET_TERMIOS |


2020-02-03 21:42:39

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.5 00/23] 5.5.2-stable review


On 03/02/2020 16:20, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.5.2 release.
> There are 23 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 05 Feb 2020 16:17:59 +0000.
> 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/v5.x/stable-review/patch-5.5.2-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v5.5:
13 builds: 13 pass, 0 fail
22 boots: 22 pass, 0 fail
40 tests: 40 pass, 0 fail

Linux version: 5.5.2-rc1-g8dc0cb8ae177
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-02-03 22:52:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.5 00/23] 5.5.2-stable review

On Mon, Feb 03, 2020 at 09:40:21PM +0000, Jon Hunter wrote:
>
> On 03/02/2020 16:20, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.5.2 release.
> > There are 23 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 05 Feb 2020 16:17:59 +0000.
> > 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/v5.x/stable-review/patch-5.5.2-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.5:
> 13 builds: 13 pass, 0 fail
> 22 boots: 22 pass, 0 fail
> 40 tests: 40 pass, 0 fail
>
> Linux version: 5.5.2-rc1-g8dc0cb8ae177
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra210-p3450-0000,
> tegra30-cardhu-a04
>

Thanks for testing all of these so quickly and letting me know.

greg k-h

2020-02-04 15:48:23

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.5 00/23] 5.5.2-stable review

On Mon, 3 Feb 2020 at 22:08, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.5.2 release.
> There are 23 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 05 Feb 2020 16:17:59 +0000.
> 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/v5.x/stable-review/patch-5.5.2-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

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

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

kernel: 5.5.2-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.5.y
git commit: 4ff4fd2d564ba792fa27ff72393eb5a4b5bd78e7
git describe: v5.5.1-25-g4ff4fd2d564b
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.5-oe/build/v5.5.1-25-g4ff4fd2d564b

No regressions (compared to build v5.5.1)

No fixes (compared to build v5.5.1)

Ran 11148 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* linux-log-parser
* ltp-commands-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-syscalls-tests
* kselftest
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

2020-02-04 17:23:26

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.5 00/23] 5.5.2-stable review

On Mon, Feb 03, 2020 at 04:20:20PM +0000, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.5.2 release.
> There are 23 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 05 Feb 2020 16:17:59 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 393 pass: 393 fail: 0

Guenter

2020-02-04 22:58:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.5 00/23] 5.5.2-stable review

On Tue, Feb 04, 2020 at 09:20:47AM -0800, Guenter Roeck wrote:
> On Mon, Feb 03, 2020 at 04:20:20PM +0000, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.5.2 release.
> > There are 23 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 05 Feb 2020 16:17:59 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 157 pass: 157 fail: 0
> Qemu test results:
> total: 393 pass: 393 fail: 0

Yeah, one is right. I'll tackle the rest of these tomorrow, thanks
for all of the testing and reports.

greg k-h

2020-02-05 13:08:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.5 00/23] 5.5.2-stable review

On Tue, Feb 04, 2020 at 09:15:44PM +0530, Naresh Kamboju wrote:
> On Mon, 3 Feb 2020 at 22:08, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.5.2 release.
> > There are 23 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 05 Feb 2020 16:17:59 +0000.
> > 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/v5.x/stable-review/patch-5.5.2-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Thanks for testing all of these and letting me know.

It would be interesting to figure out how all of the different build
errors on this "round" of releases did not trip up your systems...

thanks,

greg k-h

2020-02-08 16:14:00

by Daniel Díaz

[permalink] [raw]
Subject: Re: [PATCH 5.5 00/23] 5.5.2-stable review

Hello!

On Wed, 5 Feb 2020 at 07:07, Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Tue, Feb 04, 2020 at 09:15:44PM +0530, Naresh Kamboju wrote:
> > On Mon, 3 Feb 2020 at 22:08, Greg Kroah-Hartman
> > <[email protected]> wrote:
> > >
> > > This is the start of the stable review cycle for the 5.5.2 release.
> > > There are 23 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Wed, 05 Feb 2020 16:17:59 +0000.
> > > 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/v5.x/stable-review/patch-5.5.2-rc1.gz
> > > or in the git tree and branch at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Results from Linaro’s test farm.
> > No regressions on arm64, arm, x86_64, and i386.
>
> Thanks for testing all of these and letting me know.
>
> It would be interesting to figure out how all of the different build
> errors on this "round" of releases did not trip up your systems...

We're not building these configs:
allyesconfig allmodconfig omap2plus_defconfig imx_v6_v7_defconfig
nor building for ARCH=riscv, which were the ones failing.

Greetings!

Daniel Díaz
[email protected]