2021-03-05 12:45:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 00/30] 4.4.260-rc1 review

This is the start of the stable review cycle for the 4.4.260 release.
There are 30 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 Sun, 07 Mar 2021 12:08:39 +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/v4.x/stable-review/patch-4.4.260-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Sakari Ailus <[email protected]>
media: v4l: ioctl: Fix memory leak in video_usercopy

Jens Axboe <[email protected]>
swap: fix swapfile read/write offset

Rokudo Yan <[email protected]>
zsmalloc: account the number of compacted pages correctly

Jan Beulich <[email protected]>
xen-netback: respect gnttab_map_refs()'s return value

Jan Beulich <[email protected]>
Xen/gnttab: handle p2m update errors on a per-slot basis

Chris Leech <[email protected]>
scsi: iscsi: Verify lengths on passthrough PDUs

Chris Leech <[email protected]>
scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE

Joe Perches <[email protected]>
sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output

Lee Duncan <[email protected]>
scsi: iscsi: Restrict sessions and handles to admin capabilities

Ricardo Ribalda <[email protected]>
media: uvcvideo: Allow entities with no pads

Christian Gromm <[email protected]>
staging: most: sound: add sanity check for function argument

Gopal Tiwari <[email protected]>
Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data

Fangrui Song <[email protected]>
x86/build: Treat R_386_PLT32 relocation as R_386_PC32

Miaoqing Pan <[email protected]>
ath10k: fix wmi mgmt tx queue full due to race condition

Di Zhu <[email protected]>
pktgen: fix misuse of BUG_ON() in pktgen_thread_worker()

Tony Lindgren <[email protected]>
wlcore: Fix command execute failure 19 for wl12xx

Jiri Slaby <[email protected]>
vt/consolemap: do font sum unsigned

Heiner Kallweit <[email protected]>
x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirk

Dinghao Liu <[email protected]>
staging: fwserial: Fix error handling in fwserial_create

Li Xinhai <[email protected]>
mm/hugetlb.c: fix unnecessary address expansion of pmd sharing

Marco Elver <[email protected]>
net: fix up truesize of cloned skb in skb_prepare_for_shift()

Yumei Huang <[email protected]>
xfs: Fix assert failure in xfs_setattr_size()

Randy Dunlap <[email protected]>
JFS: more checks for invalid superblock

Mike Kravetz <[email protected]>
hugetlb: fix update_and_free_page contig page struct assumption

Rolf Eike Beer <[email protected]>
scripts: set proper OpenSSL include dir also for sign-file

Rolf Eike Beer <[email protected]>
scripts: use pkg-config to locate libcrypto

Frank Li <[email protected]>
mmc: sdhci-esdhc-imx: fix kernel panic when remove module

Nobuhiro Iwamatsu <[email protected]>
iwlwifi: pcie: fix to correct null check

Lech Perczak <[email protected]>
net: usb: qmi_wwan: support ZTE P685M modem

Thomas Gleixner <[email protected]>
futex: Ensure the correct return value from futex_lock_pi()


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

Diffstat:

Documentation/filesystems/sysfs.txt | 8 +-
Makefile | 4 +-
arch/arm/xen/p2m.c | 35 +++++++-
arch/x86/kernel/module.c | 1 +
arch/x86/kernel/reboot.c | 9 ++
arch/x86/tools/relocs.c | 12 ++-
arch/x86/xen/p2m.c | 44 +++++++++-
drivers/block/zram/zram_drv.c | 2 +-
drivers/media/usb/uvc/uvc_driver.c | 7 +-
drivers/media/v4l2-core/v4l2-ioctl.c | 19 ++--
drivers/mmc/host/sdhci-esdhc-imx.c | 3 +-
drivers/net/usb/qmi_wwan.c | 1 +
drivers/net/wireless/ath/ath10k/mac.c | 15 +---
drivers/net/wireless/iwlwifi/pcie/tx.c | 4 +-
drivers/net/wireless/ti/wl12xx/main.c | 3 -
drivers/net/wireless/ti/wlcore/main.c | 15 +---
drivers/net/wireless/ti/wlcore/wlcore.h | 3 -
drivers/net/xen-netback/netback.c | 12 ++-
drivers/scsi/libiscsi.c | 148 ++++++++++++++++----------------
drivers/scsi/scsi_transport_iscsi.c | 38 ++++++--
drivers/staging/fwserial/fwserial.c | 2 +
drivers/staging/most/aim-sound/sound.c | 2 +
drivers/tty/vt/consolemap.c | 2 +-
fs/jfs/jfs_filsys.h | 1 +
fs/jfs/jfs_mount.c | 10 +++
fs/sysfs/file.c | 55 ++++++++++++
fs/xfs/xfs_iops.c | 2 +-
include/linux/sysfs.h | 16 ++++
include/linux/zsmalloc.h | 2 +-
kernel/futex.c | 24 +++---
mm/hugetlb.c | 28 +++---
mm/page_io.c | 11 +--
mm/swapfile.c | 2 +-
mm/zsmalloc.c | 17 ++--
net/bluetooth/amp.c | 3 +
net/core/pktgen.c | 2 +-
net/core/skbuff.c | 14 ++-
scripts/Makefile | 9 +-
38 files changed, 390 insertions(+), 195 deletions(-)



2021-03-05 12:45:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 27/30] xen-netback: respect gnttab_map_refs()s return value

From: Jan Beulich <[email protected]>

commit 2991397d23ec597405b116d96de3813420bdcbc3 upstream.

Commit 3194a1746e8a ("xen-netback: don't "handle" error by BUG()")
dropped respective a BUG_ON() without noticing that with this the
variable's value wouldn't be consumed anymore. With gnttab_set_map_op()
setting all status fields to a non-zero value, in case of an error no
slot should have a status of GNTST_okay (zero).

This is part of XSA-367.

Cc: <[email protected]>
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/xen-netback/netback.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)

--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1792,11 +1792,21 @@ int xenvif_tx_action(struct xenvif_queue
return 0;

gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
- if (nr_mops != 0)
+ if (nr_mops != 0) {
ret = gnttab_map_refs(queue->tx_map_ops,
NULL,
queue->pages_to_map,
nr_mops);
+ if (ret) {
+ unsigned int i;
+
+ netdev_err(queue->vif->dev, "Map fail: nr %u ret %d\n",
+ nr_mops, ret);
+ for (i = 0; i < nr_mops; ++i)
+ WARN_ON_ONCE(queue->tx_map_ops[i].status ==
+ GNTST_okay);
+ }
+ }

work_done = xenvif_tx_submit(queue);



2021-03-05 12:46:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 03/30] iwlwifi: pcie: fix to correct null check

From: Nobuhiro Iwamatsu <[email protected]>

The fixes made in commit: 4ae5798004d8 ("iwlwifi: pcie: add a NULL check in
iwl_pcie_txq_unmap") is not enough in 4.4.y tree.. This still have problems
with null references. This provides the correct fix.
Also, this is a problem only in 4.4.y. This patch has been applied to other
LTS trees, but with the correct fixes.

Fixes: 4ae5798004d8 ("iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmap")
Cc: [email protected]
Cc: Emmanuel Grumbach <[email protected]>
Cc: Luca Coelho <[email protected]>
Cc: Kalle Valo <[email protected]>
Cc: Sasha Levin <[email protected]>
Signed-off-by: Nobuhiro Iwamatsu (CIP) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/pcie/tx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -583,13 +583,15 @@ static void iwl_pcie_txq_unmap(struct iw
{
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
struct iwl_txq *txq = &trans_pcie->txq[txq_id];
- struct iwl_queue *q = &txq->q;
+ struct iwl_queue *q;

if (!txq) {
IWL_ERR(trans, "Trying to free a queue that wasn't allocated?\n");
return;
}

+ q = &txq->q;
+
spin_lock_bh(&txq->lock);
while (q->write_ptr != q->read_ptr) {
IWL_DEBUG_TX_REPLY(trans, "Q %d Free %d\n",


2021-03-05 12:46:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 07/30] hugetlb: fix update_and_free_page contig page struct assumption

From: Mike Kravetz <[email protected]>

commit dbfee5aee7e54f83d96ceb8e3e80717fac62ad63 upstream.

page structs are not guaranteed to be contiguous for gigantic pages. The
routine update_and_free_page can encounter a gigantic page, yet it assumes
page structs are contiguous when setting page flags in subpages.

If update_and_free_page encounters non-contiguous page structs, we can see
“BUG: Bad page state in process …” errors.

Non-contiguous page structs are generally not an issue. However, they can
exist with a specific kernel configuration and hotplug operations. For
example: Configure the kernel with CONFIG_SPARSEMEM and
!CONFIG_SPARSEMEM_VMEMMAP. Then, hotplug add memory for the area where
the gigantic page will be allocated. Zi Yan outlined steps to reproduce
here [1].

[1] https://lore.kernel.org/linux-mm/[email protected]/

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime")
Signed-off-by: Zi Yan <[email protected]>
Signed-off-by: Mike Kravetz <[email protected]>
Cc: Zi Yan <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: "Kirill A . Shutemov" <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Oscar Salvador <[email protected]>
Cc: Joao Martins <[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]>
Signed-off-by: Mike Kravetz <[email protected]>
---
mm/hugetlb.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1159,14 +1159,16 @@ static inline int alloc_fresh_gigantic_p
static void update_and_free_page(struct hstate *h, struct page *page)
{
int i;
+ struct page *subpage = page;

if (hstate_is_gigantic(h) && !gigantic_page_supported())
return;

h->nr_huge_pages--;
h->nr_huge_pages_node[page_to_nid(page)]--;
- for (i = 0; i < pages_per_huge_page(h); i++) {
- page[i].flags &= ~(1 << PG_locked | 1 << PG_error |
+ for (i = 0; i < pages_per_huge_page(h);
+ i++, subpage = mem_map_next(subpage, page, i)) {
+ subpage->flags &= ~(1 << PG_locked | 1 << PG_error |
1 << PG_referenced | 1 << PG_dirty |
1 << PG_active | 1 << PG_private |
1 << PG_writeback);


2021-03-05 12:46:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 25/30] scsi: iscsi: Verify lengths on passthrough PDUs

From: Chris Leech <[email protected]>

commit f9dbdf97a5bd92b1a49cee3d591b55b11fd7a6d5 upstream.

Open-iSCSI sends passthrough PDUs over netlink, but the kernel should be
verifying that the provided PDU header and data lengths fall within the
netlink message to prevent accessing beyond that in memory.

Cc: [email protected]
Reported-by: Adam Nichols <[email protected]>
Reviewed-by: Lee Duncan <[email protected]>
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Chris Leech <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/scsi_transport_iscsi.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -3526,6 +3526,7 @@ static int
iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
{
int err = 0;
+ u32 pdu_len;
struct iscsi_uevent *ev = nlmsg_data(nlh);
struct iscsi_transport *transport = NULL;
struct iscsi_internal *priv;
@@ -3641,6 +3642,14 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
err = -EINVAL;
break;
case ISCSI_UEVENT_SEND_PDU:
+ pdu_len = nlh->nlmsg_len - sizeof(*nlh) - sizeof(*ev);
+
+ if ((ev->u.send_pdu.hdr_size > pdu_len) ||
+ (ev->u.send_pdu.data_size > (pdu_len - ev->u.send_pdu.hdr_size))) {
+ err = -EINVAL;
+ break;
+ }
+
conn = iscsi_conn_lookup(ev->u.send_pdu.sid, ev->u.send_pdu.cid);
if (conn)
ev->r.retcode = transport->send_pdu(conn,


2021-03-05 12:46:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 17/30] ath10k: fix wmi mgmt tx queue full due to race condition

From: Miaoqing Pan <[email protected]>

[ Upstream commit b55379e343a3472c35f4a1245906db5158cab453 ]

Failed to transmit wmi management frames:

[84977.840894] ath10k_snoc a000000.wifi: wmi mgmt tx queue is full
[84977.840913] ath10k_snoc a000000.wifi: failed to transmit packet, dropping: -28
[84977.840924] ath10k_snoc a000000.wifi: failed to submit frame: -28
[84977.840932] ath10k_snoc a000000.wifi: failed to transmit frame: -28

This issue is caused by race condition between skb_dequeue and
__skb_queue_tail. The queue of ‘wmi_mgmt_tx_queue’ is protected by a
different lock: ar->data_lock vs list->lock, the result is no protection.
So when ath10k_mgmt_over_wmi_tx_work() and ath10k_mac_tx_wmi_mgmt()
running concurrently on different CPUs, there appear to be a rare corner
cases when the queue length is 1,

CPUx (skb_deuque) CPUy (__skb_queue_tail)
next=list
prev=list
struct sk_buff *skb = skb_peek(list); WRITE_ONCE(newsk->next, next);
WRITE_ONCE(list->qlen, list->qlen - 1);WRITE_ONCE(newsk->prev, prev);
next = skb->next; WRITE_ONCE(next->prev, newsk);
prev = skb->prev; WRITE_ONCE(prev->next, newsk);
skb->next = skb->prev = NULL; list->qlen++;
WRITE_ONCE(next->prev, prev);
WRITE_ONCE(prev->next, next);

If the instruction ‘next = skb->next’ is executed before
‘WRITE_ONCE(prev->next, newsk)’, newsk will be lost, as CPUx get the
old ‘next’ pointer, but the length is still added by one. The final
result is the length of the queue will reach the maximum value but
the queue is empty.

So remove ar->data_lock, and use 'skb_queue_tail' instead of
'__skb_queue_tail' to prevent the potential race condition. Also switch
to use skb_queue_len_lockless, in case we queue a few SKBs simultaneously.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1.c2-00033-QCAHLSWMTPLZ-1

Signed-off-by: Miaoqing Pan <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/wireless/ath/ath10k/mac.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 7fbf2abcfc43..5fad38c3feb1 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3336,23 +3336,16 @@ static bool ath10k_mac_need_offchan_tx_work(struct ath10k *ar)
static int ath10k_mac_tx_wmi_mgmt(struct ath10k *ar, struct sk_buff *skb)
{
struct sk_buff_head *q = &ar->wmi_mgmt_tx_queue;
- int ret = 0;
-
- spin_lock_bh(&ar->data_lock);

- if (skb_queue_len(q) == ATH10K_MAX_NUM_MGMT_PENDING) {
+ if (skb_queue_len_lockless(q) >= ATH10K_MAX_NUM_MGMT_PENDING) {
ath10k_warn(ar, "wmi mgmt tx queue is full\n");
- ret = -ENOSPC;
- goto unlock;
+ return -ENOSPC;
}

- __skb_queue_tail(q, skb);
+ skb_queue_tail(q, skb);
ieee80211_queue_work(ar->hw, &ar->wmi_mgmt_tx_work);

-unlock:
- spin_unlock_bh(&ar->data_lock);
-
- return ret;
+ return 0;
}

static void ath10k_mac_tx(struct ath10k *ar, struct sk_buff *skb)
--
2.30.1



2021-03-05 12:46:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 10/30] net: fix up truesize of cloned skb in skb_prepare_for_shift()

From: Marco Elver <[email protected]>

commit 097b9146c0e26aabaa6ff3e5ea536a53f5254a79 upstream.

Avoid the assumption that ksize(kmalloc(S)) == ksize(kmalloc(S)): when
cloning an skb, save and restore truesize after pskb_expand_head(). This
can occur if the allocator decides to service an allocation of the same
size differently (e.g. use a different size class, or pass the
allocation on to KFENCE).

Because truesize is used for bookkeeping (such as sk_wmem_queued), a
modified truesize of a cloned skb may result in corrupt bookkeeping and
relevant warnings (such as in sk_stream_kill_queues()).

Link: https://lkml.kernel.org/r/X9JR/[email protected]
Reported-by: [email protected]
Suggested-by: Eric Dumazet <[email protected]>
Signed-off-by: Marco Elver <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/skbuff.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)

--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2628,7 +2628,19 @@ EXPORT_SYMBOL(skb_split);
*/
static int skb_prepare_for_shift(struct sk_buff *skb)
{
- return skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
+ int ret = 0;
+
+ if (skb_cloned(skb)) {
+ /* Save and restore truesize: pskb_expand_head() may reallocate
+ * memory where ksize(kmalloc(S)) != ksize(kmalloc(S)), but we
+ * cannot change truesize at this point.
+ */
+ unsigned int save_truesize = skb->truesize;
+
+ ret = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
+ skb->truesize = save_truesize;
+ }
+ return ret;
}

/**


2021-03-05 12:46:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 01/30] futex: Ensure the correct return value from futex_lock_pi()

From: Thomas Gleixner <[email protected]>

commit 12bb3f7f1b03d5913b3f9d4236a488aa7774dfe9 upstream.

In case that futex_lock_pi() was aborted by a signal or a timeout and the
task returned without acquiring the rtmutex, but is the designated owner of
the futex due to a concurrent futex_unlock_pi() fixup_owner() is invoked to
establish consistent state. In that case it invokes fixup_pi_state_owner()
which in turn tries to acquire the rtmutex again. If that succeeds then it
does not propagate this success to fixup_owner() and futex_lock_pi()
returns -EINTR or -ETIMEOUT despite having the futex locked.

Return success from fixup_pi_state_owner() in all cases where the current
task owns the rtmutex and therefore the futex and propagate it correctly
through fixup_owner(). Fixup the other callsite which does not expect a
positive return value.

Fixes: c1e2f0eaf015 ("futex: Avoid violating the 10th rule of futex")
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
[Sharan: Backported patch for kernel 4.4.y. Also folded in is a part
of the cleanup patch d7c5ed73b19c("futex: Remove needless goto's")]
Signed-off-by: Sharan Turlapati <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/futex.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)

--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2283,7 +2283,7 @@ retry:
}

if (__rt_mutex_futex_trylock(&pi_state->pi_mutex)) {
- /* We got the lock after all, nothing to fix. */
+ /* We got the lock. pi_state is correct. Tell caller */
return 1;
}

@@ -2328,7 +2328,7 @@ retry:
*/
pi_state_update_owner(pi_state, newowner);

- return 0;
+ return argowner == current;

/*
* To handle the page fault we need to drop the hash bucket
@@ -2411,8 +2411,6 @@ static long futex_wait_restart(struct re
*/
static int fixup_owner(u32 __user *uaddr, struct futex_q *q, int locked)
{
- int ret = 0;
-
if (locked) {
/*
* Got the lock. We might not be the anticipated owner if we
@@ -2423,8 +2421,8 @@ static int fixup_owner(u32 __user *uaddr
* stable state, anything else needs more attention.
*/
if (q->pi_state->owner != current)
- ret = fixup_pi_state_owner(uaddr, q, current);
- goto out;
+ return fixup_pi_state_owner(uaddr, q, current);
+ return 1;
}

/*
@@ -2435,10 +2433,8 @@ static int fixup_owner(u32 __user *uaddr
* Another speculative read; pi_state->owner == current is unstable
* but needs our attention.
*/
- if (q->pi_state->owner == current) {
- ret = fixup_pi_state_owner(uaddr, q, NULL);
- goto out;
- }
+ if (q->pi_state->owner == current)
+ return fixup_pi_state_owner(uaddr, q, NULL);

/*
* Paranoia check. If we did not take the lock, then we should not be
@@ -2447,8 +2443,7 @@ static int fixup_owner(u32 __user *uaddr
if (WARN_ON_ONCE(rt_mutex_owner(&q->pi_state->pi_mutex) == current))
return fixup_pi_state_owner(uaddr, q, current);

-out:
- return ret ? ret : locked;
+ return 0;
}

/**
@@ -3070,6 +3065,11 @@ static int futex_wait_requeue_pi(u32 __u
*/
free_pi_state(q.pi_state);
spin_unlock(q.lock_ptr);
+ /*
+ * Adjust the return value. It's either -EFAULT or
+ * success (1) but the caller expects 0 for success.
+ */
+ ret = ret < 0 ? ret : 0;
}
} else {
struct rt_mutex *pi_mutex;


2021-03-05 12:47:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 28/30] zsmalloc: account the number of compacted pages correctly

From: Rokudo Yan <[email protected]>

commit 2395928158059b8f9858365fce7713ce7fef62e4 upstream.

There exists multiple path may do zram compaction concurrently.
1. auto-compaction triggered during memory reclaim
2. userspace utils write zram<id>/compaction node

So, multiple threads may call zs_shrinker_scan/zs_compact concurrently.
But pages_compacted is a per zsmalloc pool variable and modification
of the variable is not serialized(through under class->lock).
There are two issues here:
1. the pages_compacted may not equal to total number of pages
freed(due to concurrently add).
2. zs_shrinker_scan may not return the correct number of pages
freed(issued by current shrinker).

The fix is simple:
1. account the number of pages freed in zs_compact locally.
2. use actomic variable pages_compacted to accumulate total number.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 860c707dca155a56 ("zsmalloc: account the number of compacted pages")
Signed-off-by: Rokudo Yan <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Sergey Senozhatsky <[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]>
---
drivers/block/zram/zram_drv.c | 2 +-
include/linux/zsmalloc.h | 2 +-
mm/zsmalloc.c | 17 +++++++++++------
3 files changed, 13 insertions(+), 8 deletions(-)

--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -450,7 +450,7 @@ static ssize_t mm_stat_show(struct devic
zram->limit_pages << PAGE_SHIFT,
max_used << PAGE_SHIFT,
(u64)atomic64_read(&zram->stats.zero_pages),
- pool_stats.pages_compacted);
+ atomic_long_read(&pool_stats.pages_compacted));
up_read(&zram->init_lock);

return ret;
--- a/include/linux/zsmalloc.h
+++ b/include/linux/zsmalloc.h
@@ -36,7 +36,7 @@ enum zs_mapmode {

struct zs_pool_stats {
/* How many pages were migrated (freed) */
- unsigned long pages_compacted;
+ atomic_long_t pages_compacted;
};

struct zs_pool;
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1745,11 +1745,13 @@ static unsigned long zs_can_compact(stru
return obj_wasted * class->pages_per_zspage;
}

-static void __zs_compact(struct zs_pool *pool, struct size_class *class)
+static unsigned long __zs_compact(struct zs_pool *pool,
+ struct size_class *class)
{
struct zs_compact_control cc;
struct page *src_page;
struct page *dst_page = NULL;
+ unsigned long pages_freed = 0;

spin_lock(&class->lock);
while ((src_page = isolate_source_page(class))) {
@@ -1780,7 +1782,7 @@ static void __zs_compact(struct zs_pool

putback_zspage(pool, class, dst_page);
if (putback_zspage(pool, class, src_page) == ZS_EMPTY)
- pool->stats.pages_compacted += class->pages_per_zspage;
+ pages_freed += class->pages_per_zspage;
spin_unlock(&class->lock);
cond_resched();
spin_lock(&class->lock);
@@ -1790,12 +1792,15 @@ static void __zs_compact(struct zs_pool
putback_zspage(pool, class, src_page);

spin_unlock(&class->lock);
+
+ return pages_freed;
}

unsigned long zs_compact(struct zs_pool *pool)
{
int i;
struct size_class *class;
+ unsigned long pages_freed = 0;

for (i = zs_size_classes - 1; i >= 0; i--) {
class = pool->size_class[i];
@@ -1803,10 +1808,11 @@ unsigned long zs_compact(struct zs_pool
continue;
if (class->index != i)
continue;
- __zs_compact(pool, class);
+ pages_freed += __zs_compact(pool, class);
}
+ atomic_long_add(pages_freed, &pool->stats.pages_compacted);

- return pool->stats.pages_compacted;
+ return pages_freed;
}
EXPORT_SYMBOL_GPL(zs_compact);

@@ -1823,13 +1829,12 @@ static unsigned long zs_shrinker_scan(st
struct zs_pool *pool = container_of(shrinker, struct zs_pool,
shrinker);

- pages_freed = pool->stats.pages_compacted;
/*
* Compact classes and calculate compaction delta.
* Can run concurrently with a manually triggered
* (by user) compaction.
*/
- pages_freed = zs_compact(pool) - pages_freed;
+ pages_freed = zs_compact(pool);

return pages_freed ? pages_freed : SHRINK_STOP;
}


2021-03-05 12:47:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 20/30] staging: most: sound: add sanity check for function argument

From: Christian Gromm <[email protected]>

[ Upstream commit 45b754ae5b82949dca2b6e74fa680313cefdc813 ]

This patch checks the function parameter 'bytes' before doing the
subtraction to prevent memory corruption.

Signed-off-by: Christian Gromm <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/staging/most/aim-sound/sound.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/staging/most/aim-sound/sound.c b/drivers/staging/most/aim-sound/sound.c
index 9c645801cff4..532ec0f7100e 100644
--- a/drivers/staging/most/aim-sound/sound.c
+++ b/drivers/staging/most/aim-sound/sound.c
@@ -92,6 +92,8 @@ static void swap_copy24(u8 *dest, const u8 *source, unsigned int bytes)
{
unsigned int i = 0;

+ if (bytes < 2)
+ return;
while (i < bytes - 2) {
dest[i] = source[i + 2];
dest[i + 1] = source[i + 1];
--
2.30.1



2021-03-05 12:47:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 21/30] media: uvcvideo: Allow entities with no pads

From: Ricardo Ribalda <[email protected]>

[ Upstream commit 7532dad6634031d083df7af606fac655b8d08b5c ]

Avoid an underflow while calculating the number of inputs for entities
with zero pads.

Signed-off-by: Ricardo Ribalda <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/media/usb/uvc/uvc_driver.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index f353ab569b8e..def22b7fef9c 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -869,7 +869,10 @@ static struct uvc_entity *uvc_alloc_entity(u16 type, u8 id,
unsigned int i;

extra_size = roundup(extra_size, sizeof(*entity->pads));
- num_inputs = (type & UVC_TERM_OUTPUT) ? num_pads : num_pads - 1;
+ if (num_pads)
+ num_inputs = type & UVC_TERM_OUTPUT ? num_pads : num_pads - 1;
+ else
+ num_inputs = 0;
size = sizeof(*entity) + extra_size + sizeof(*entity->pads) * num_pads
+ num_inputs;
entity = kzalloc(size, GFP_KERNEL);
@@ -885,7 +888,7 @@ static struct uvc_entity *uvc_alloc_entity(u16 type, u8 id,

for (i = 0; i < num_inputs; ++i)
entity->pads[i].flags = MEDIA_PAD_FL_SINK;
- if (!UVC_ENTITY_IS_OTERM(entity))
+ if (!UVC_ENTITY_IS_OTERM(entity) && num_pads)
entity->pads[num_pads-1].flags = MEDIA_PAD_FL_SOURCE;

entity->bNrInPins = num_inputs;
--
2.30.1



2021-03-05 12:48:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 29/30] swap: fix swapfile read/write offset

From: Jens Axboe <[email protected]>

commit caf6912f3f4af7232340d500a4a2008f81b93f14 upstream.

We're not factoring in the start of the file for where to write and
read the swapfile, which leads to very unfortunate side effects of
writing where we should not be...

[This issue only affects swapfiles on filesystems on top of blockdevs
that implement rw_page ops (brd, zram, btt, pmem), and not on top of any
other block devices, in contrast to the upstream commit fix.]

Fixes: dd6bd0d9c7db ("swap: use bdev_read_page() / bdev_write_page()")
Cc: [email protected] # 4.4
Signed-off-by: Anthony Iliopoulos <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/page_io.c | 11 +++--------
mm/swapfile.c | 2 +-
2 files changed, 4 insertions(+), 9 deletions(-)

--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -32,7 +32,6 @@ static struct bio *get_swap_bio(gfp_t gf
bio = bio_alloc(gfp_flags, 1);
if (bio) {
bio->bi_iter.bi_sector = map_swap_page(page, &bio->bi_bdev);
- bio->bi_iter.bi_sector <<= PAGE_SHIFT - 9;
bio->bi_end_io = end_io;

bio_add_page(bio, page, PAGE_SIZE, 0);
@@ -244,11 +243,6 @@ out:
return ret;
}

-static sector_t swap_page_sector(struct page *page)
-{
- return (sector_t)__page_file_index(page) << (PAGE_CACHE_SHIFT - 9);
-}
-
int __swap_writepage(struct page *page, struct writeback_control *wbc,
bio_end_io_t end_write_func)
{
@@ -297,7 +291,8 @@ int __swap_writepage(struct page *page,
return ret;
}

- ret = bdev_write_page(sis->bdev, swap_page_sector(page), page, wbc);
+ ret = bdev_write_page(sis->bdev, map_swap_page(page, &sis->bdev),
+ page, wbc);
if (!ret) {
count_vm_event(PSWPOUT);
return 0;
@@ -345,7 +340,7 @@ int swap_readpage(struct page *page)
return ret;
}

- ret = bdev_read_page(sis->bdev, swap_page_sector(page), page);
+ ret = bdev_read_page(sis->bdev, map_swap_page(page, &sis->bdev), page);
if (!ret) {
count_vm_event(PSWPIN);
return 0;
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1653,7 +1653,7 @@ sector_t map_swap_page(struct page *page
{
swp_entry_t entry;
entry.val = page_private(page);
- return map_swap_entry(entry, bdev);
+ return map_swap_entry(entry, bdev) << (PAGE_SHIFT - 9);
}

/*


2021-03-05 12:48:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 30/30] media: v4l: ioctl: Fix memory leak in video_usercopy

From: Sakari Ailus <[email protected]>

commit fb18802a338b36f675a388fc03d2aa504a0d0899 upstream.

When an IOCTL with argument size larger than 128 that also used array
arguments were handled, two memory allocations were made but alas, only
the latter one of them was released. This happened because there was only
a single local variable to hold such a temporary allocation.

Fix this by adding separate variables to hold the pointers to the
temporary allocations.

Reported-by: Arnd Bergmann <[email protected]>
Reported-by: [email protected]
Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code")
Cc: [email protected]
Signed-off-by: Sakari Ailus <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Hans Verkuil <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/v4l2-core/v4l2-ioctl.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)

--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2710,7 +2710,7 @@ video_usercopy(struct file *file, unsign
v4l2_kioctl func)
{
char sbuf[128];
- void *mbuf = NULL;
+ void *mbuf = NULL, *array_buf = NULL;
void *parg = (void *)arg;
long err = -EINVAL;
bool has_array_args;
@@ -2765,20 +2765,14 @@ video_usercopy(struct file *file, unsign
has_array_args = err;

if (has_array_args) {
- /*
- * When adding new types of array args, make sure that the
- * parent argument to ioctl (which contains the pointer to the
- * array) fits into sbuf (so that mbuf will still remain
- * unused up to here).
- */
- mbuf = kmalloc(array_size, GFP_KERNEL);
+ array_buf = kmalloc(array_size, GFP_KERNEL);
err = -ENOMEM;
- if (NULL == mbuf)
+ if (array_buf == NULL)
goto out_array_args;
err = -EFAULT;
- if (copy_from_user(mbuf, user_ptr, array_size))
+ if (copy_from_user(array_buf, user_ptr, array_size))
goto out_array_args;
- *kernel_ptr = mbuf;
+ *kernel_ptr = array_buf;
}

/* Handles IOCTL */
@@ -2797,7 +2791,7 @@ video_usercopy(struct file *file, unsign

if (has_array_args) {
*kernel_ptr = (void __force *)user_ptr;
- if (copy_to_user(user_ptr, mbuf, array_size))
+ if (copy_to_user(user_ptr, array_buf, array_size))
err = -EFAULT;
goto out_array_args;
}
@@ -2817,6 +2811,7 @@ out_array_args:
}

out:
+ kfree(array_buf);
kfree(mbuf);
return err;
}


2021-03-05 12:48:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 26/30] Xen/gnttab: handle p2m update errors on a per-slot basis

From: Jan Beulich <[email protected]>

commit 8310b77b48c5558c140e7a57a702e7819e62f04e upstream.

Bailing immediately from set_foreign_p2m_mapping() upon a p2m updating
error leaves the full batch in an ambiguous state as far as the caller
is concerned. Instead flags respective slots as bad, unmapping what
was mapped there right away.

HYPERVISOR_grant_table_op()'s return value and the individual unmap
slots' status fields get used only for a one-time - there's not much we
can do in case of a failure.

Note that there's no GNTST_enomem or alike, so GNTST_general_error gets
used.

The map ops' handle fields get overwritten just to be on the safe side.

This is part of XSA-367.

Cc: <[email protected]>
Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/xen/p2m.c | 35 +++++++++++++++++++++++++++++++----
arch/x86/xen/p2m.c | 44 +++++++++++++++++++++++++++++++++++++++++---
2 files changed, 72 insertions(+), 7 deletions(-)

--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -91,12 +91,39 @@ int set_foreign_p2m_mapping(struct gntta
int i;

for (i = 0; i < count; i++) {
+ struct gnttab_unmap_grant_ref unmap;
+ int rc;
+
if (map_ops[i].status)
continue;
- if (unlikely(!set_phys_to_machine(map_ops[i].host_addr >> XEN_PAGE_SHIFT,
- map_ops[i].dev_bus_addr >> XEN_PAGE_SHIFT))) {
- return -ENOMEM;
- }
+ if (likely(set_phys_to_machine(map_ops[i].host_addr >> XEN_PAGE_SHIFT,
+ map_ops[i].dev_bus_addr >> XEN_PAGE_SHIFT)))
+ continue;
+
+ /*
+ * Signal an error for this slot. This in turn requires
+ * immediate unmapping.
+ */
+ map_ops[i].status = GNTST_general_error;
+ unmap.host_addr = map_ops[i].host_addr,
+ unmap.handle = map_ops[i].handle;
+ map_ops[i].handle = ~0;
+ if (map_ops[i].flags & GNTMAP_device_map)
+ unmap.dev_bus_addr = map_ops[i].dev_bus_addr;
+ else
+ unmap.dev_bus_addr = 0;
+
+ /*
+ * Pre-populate the status field, to be recognizable in
+ * the log message below.
+ */
+ unmap.status = 1;
+
+ rc = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+ &unmap, 1);
+ if (rc || unmap.status != GNTST_okay)
+ pr_err_once("gnttab unmap failed: rc=%d st=%d\n",
+ rc, unmap.status);
}

return 0;
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -723,6 +723,8 @@ int set_foreign_p2m_mapping(struct gntta

for (i = 0; i < count; i++) {
unsigned long mfn, pfn;
+ struct gnttab_unmap_grant_ref unmap[2];
+ int rc;

/* Do not add to override if the map failed. */
if (map_ops[i].status != GNTST_okay ||
@@ -740,10 +742,46 @@ int set_foreign_p2m_mapping(struct gntta

WARN(pfn_to_mfn(pfn) != INVALID_P2M_ENTRY, "page must be ballooned");

- if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) {
- ret = -ENOMEM;
- goto out;
+ if (likely(set_phys_to_machine(pfn, FOREIGN_FRAME(mfn))))
+ continue;
+
+ /*
+ * Signal an error for this slot. This in turn requires
+ * immediate unmapping.
+ */
+ map_ops[i].status = GNTST_general_error;
+ unmap[0].host_addr = map_ops[i].host_addr,
+ unmap[0].handle = map_ops[i].handle;
+ map_ops[i].handle = ~0;
+ if (map_ops[i].flags & GNTMAP_device_map)
+ unmap[0].dev_bus_addr = map_ops[i].dev_bus_addr;
+ else
+ unmap[0].dev_bus_addr = 0;
+
+ if (kmap_ops) {
+ kmap_ops[i].status = GNTST_general_error;
+ unmap[1].host_addr = kmap_ops[i].host_addr,
+ unmap[1].handle = kmap_ops[i].handle;
+ kmap_ops[i].handle = ~0;
+ if (kmap_ops[i].flags & GNTMAP_device_map)
+ unmap[1].dev_bus_addr = kmap_ops[i].dev_bus_addr;
+ else
+ unmap[1].dev_bus_addr = 0;
}
+
+ /*
+ * Pre-populate both status fields, to be recognizable in
+ * the log message below.
+ */
+ unmap[0].status = 1;
+ unmap[1].status = 1;
+
+ rc = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+ unmap, 1 + !!kmap_ops);
+ if (rc || unmap[0].status != GNTST_okay ||
+ unmap[1].status != GNTST_okay)
+ pr_err_once("gnttab unmap failed: rc=%d st0=%d st1=%d\n",
+ rc, unmap[0].status, unmap[1].status);
}

out:


2021-03-05 22:08:06

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/30] 4.4.260-rc1 review

Hi!

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

Ok, so we ran some tests.

And they failed:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1075959449

[ 26.785861] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=CVE-2018-3639 RESULT=fail>
Received signal: <TESTCASE> TEST_CASE_ID=CVE-2018-3639 RESULT=fail

Testcase name is spectre-meltdown-checker... Failing on qemu? Somehow
strange, but it looks like real test failure.

I'm cc: ing Chris, perhaps he can help.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (868.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2021-03-06 08:13:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/30] 4.4.260-rc1 review

On Fri, Mar 05, 2021 at 11:06:34PM +0100, Pavel Machek wrote:
> Hi!
>
> > This is the start of the stable review cycle for the 4.4.260 release.
> > There are 30 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.
>
> Ok, so we ran some tests.
>
> And they failed:
>
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1075959449
>
> [ 26.785861] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=CVE-2018-3639 RESULT=fail>
> Received signal: <TESTCASE> TEST_CASE_ID=CVE-2018-3639 RESULT=fail
>
> Testcase name is spectre-meltdown-checker... Failing on qemu? Somehow
> strange, but it looks like real test failure.
>
> I'm cc: ing Chris, perhaps he can help.

Can you bisect?

2021-03-06 10:43:24

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/30] 4.4.260-rc1 review

On Fri, 5 Mar 2021 at 18:15, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.4.260 release.
> There are 30 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 Sun, 07 Mar 2021 12:08:39 +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/v4.x/stable-review/patch-4.4.260-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.4.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.

Tested-by: Linux Kernel Functional Testing <[email protected]>

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

kernel: 4.4.260-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 22ce103533f98c3a483b24b6e18069e581f58f16
git describe: v4.4.259-31-g22ce103533f9
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.259-31-g22ce103533f9

No regressions (compared to build v4.4.259)

No fixes (compared to build v4.4.259)

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

Environments
--------------
- arm
- arm64
- i386
- juno-64k_page_size
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- mips
- qemu-arm64-kasan
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- sparc
- x15 - arm
- x86_64
- x86-kasan
- x86_64

Test Suites
-----------
* build
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-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-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* ltp-open-posix-tests
* network-basic-tests
* perf
* v4l2-compliance
* install-android-platform-tools-r2600
* kselftest-kvm
* kselftest-vm

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

kernel: 4.4.260-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.260-rc1-hikey-20210305-947
git commit: cce57b0d5e1b470f2de450435f74b9eba4e898a7
git describe: 4.4.260-rc1-hikey-20210305-947
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.260-rc1-hikey-20210305-947


No regressions (compared to build 4.4.259-rc2-hikey-20210302-945)

No fixes (compared to build 4.4.259-rc2-hikey-20210302-945)

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

Environments
--------------
- hi6220-hikey - arm64

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-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-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance

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

2021-03-06 16:29:08

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/30] 4.4.260-rc1 review

On Fri, Mar 05, 2021 at 01:22:29PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.260 release.
> There are 30 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 Sun, 07 Mar 2021 12:08:39 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 165 pass: 165 fail: 0
Qemu test results:
total: 329 pass: 329 fail: 0

Guenter

2021-03-06 16:33:24

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/30] 4.4.260-rc1 review

On Fri, Mar 05, 2021 at 01:22:29PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.260 release.
> There are 30 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 Sun, 07 Mar 2021 12:08:39 +0000.
> Anything received after that time might be too late.
>

Forgot:

Tested-by: Guenter Roeck <[email protected]>

Guenter

2021-03-06 23:15:53

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/30] 4.4.260-rc1 review

Hi!

> > > This is the start of the stable review cycle for the 4.4.260 release.
> > > There are 30 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.
> >
> > Ok, so we ran some tests.
> >
> > And they failed:
> >
> > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1075959449
> >
> > [ 26.785861] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=CVE-2018-3639 RESULT=fail>
> > Received signal: <TESTCASE> TEST_CASE_ID=CVE-2018-3639 RESULT=fail
> >
> > Testcase name is spectre-meltdown-checker... Failing on qemu? Somehow
> > strange, but it looks like real test failure.
> >
> > I'm cc: ing Chris, perhaps he can help.
>
> Can you bisect?

I'm kind of hoping someone else hits this, too, as I'm not that
experienced with the CIP q/a system.

But in the meantime I resubmitted older kerneland it is passing on
qemu, so it looks it might be real.

I can probably bisect it on Monday. I may try to start bisection on
Sunday.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (1.22 kB)
signature.asc (188.00 B)
Digital signature
Download all attachments

2021-03-07 00:05:59

by Pavel Machek

[permalink] [raw]
Subject: qemu meltdown test failure was Re: [PATCH 4.4 00/30] 4.4.260-rc1 review

Hi!

> > Ok, so we ran some tests.
> >
> > And they failed:
> >
> > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1075959449
> >
> > [ 26.785861] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=CVE-2018-3639 RESULT=fail>
> > Received signal: <TESTCASE> TEST_CASE_ID=CVE-2018-3639 RESULT=fail
> >
> > Testcase name is spectre-meltdown-checker... Failing on qemu? Somehow
> > strange, but it looks like real test failure.

First let me try 7d472e4a11d6a2fb1c492b02c7d7dacd3297bbf4 --
v4.4.257-cip54. That is
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266532179
... Qemu is OKAY.

add3ff3730919447a7519fede0b8554132e0f8d5 Merge remote-tracking branch
'stable/queue/4.4' in to v4.4.260-bisect. Results will be at
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266534478
... ... still pending.

Aha, but I won't be able to bisect in that :-(.

So let's create v4.4.259-cip:

e988bf453263ff43de27336a31115e8f552cd520 Merge commit
'93af63b25443f66d90450845526843076c81c7f0' into v4.4.260-bisect
93af63b25443f66d90450845526843076c81c7f0 Linux 4.4.259

And rebase v4.4.260 on top of that. So we now have this ... and it
should enable bisection:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/XXX

c700659b7d3efe7e5e1482aac93ccc6d88896696 media: v4l: ioctl: Fix memory leak in video_usercopy
430f39261e34361d909df9d25cdd7fe4925ab147 swap: fix swapfile read/write offset
0a3f4c372b91921ffc9976c142cc7de42f527d15 zsmalloc: account the number of compacted pages correctly
test 266539168 8c461bb103f89696576945ad9cb376df34fa9d28 xen-netback: respect gnttab_map_refs()'s return value
c6352c9b2e66258bd78101a85858e1b1c6c01fe2 Xen/gnttab: handle p2m update errors on a per-slot basis
b854b5154c7a682856081b25552f59ff13b5edf6 scsi: iscsi: Verify lengths on passthrough PDUs
015110b4ba859649dd94f23040732c75fcd3c0f2 scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE
679dbc5d12389622c842ccce08b92bab3d8ce853 sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output
8f5a499b4489f8aaeb7e95ec8da955317006f767 scsi: iscsi: Restrict sessions and handles to admin capabilities
8e3bd2f64a90b6be947fc8636e2642f2f4186077 media: uvcvideo: Allow entities with no pads
55a0611f55d162faecf4514dea4351612b2ffc26 staging: most: sound: add sanity check for function argument
76471b77ee8eb76795cfaffef9065cf219fef432 Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data
163650eed99950e9a1b485fd927323430db2a01a x86/build: Treat R_386_PLT32 relocation as R_386_PC32
fcd9411f34ca2b80244adeb4589ee592cebabe58 ath10k: fix wmi mgmt tx queue full due to race condition
c8b13f3c80f4ff8201a149a1eb2a45859be5b28b pktgen: fix misuse of BUG_ON() in pktgen_thread_worker()
a3a6ff3d2a4a5f6f092c3294c9c7c8d3a26a1190 wlcore: Fix command execute failure 19 for wl12xx
0334ca6c8e3a07688ceb5bbf7589d9ca8ad25d53 vt/consolemap: do font sum unsigned
48145a8b9d1aa1a8eada534df395f39355eb02f8 x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirk
test 266538760 1efe86b456816c95485c65cf9ba46a5bff8a241e staging: fwserial: Fix error handling in fwserial_create
d1b114d9ab15fe3f9f87178af194c8e6573948a5 mm/hugetlb.c: fix unnecessary address expansion of pmd sharing
ee60af793079bcf79a4ae0ff0877bd1c5767b0de net: fix up truesize of cloned skb in skb_prepare_for_shift()
6f2e9739399d5d2ba02d82fe32177c1e933116e9 xfs: Fix assert failure in xfs_setattr_size()
1ba9d3843164451426cc37413cd20d55a5702b3e JFS: more checks for invalid superblock
11f19718da9f3e5307a08d03e6bb72aef9450a9c hugetlb: fix update_and_free_page contig page struct assumption
d2f0c8c15ff0900d76496b7cbb870c830b120867 scripts: set proper OpenSSL include dir also for sign-file
ae3507eb02e8b6449add4d356d6ba788d65aee14 scripts: use pkg-config to locate libcrypto
66e96f4397bd1ca22275c3d7c2820d04a11ff765 mmc: sdhci-esdhc-imx: fix kernel panic when remove module
test 266539768 8b4bc0f97fdd13b08c2436aad01bd4515d07f93a iwlwifi: pcie: fix to correct null check
6805f20f2187dde9e2ad44e045747bcaa621ee51 net: usb: qmi_wwan: support ZTE P685M modem
3879e0dbe534ac4b937455fe3af2248692e9f6d8 futex: Ensure the correct return value from futex_lock_pi()
e988bf453263ff43de27336a31115e8f552cd520 Merge commit '93af63b25443f66d90450845526843076c81c7f0' into v4.4.260-bisect
93af63b25443f66d90450845526843076c81c7f0 Linux 4.4.259

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (5.08 kB)
signature.asc (188.00 B)
Digital signature
Download all attachments

2021-03-07 08:37:32

by Pavel Machek

[permalink] [raw]
Subject: Re: qemu meltdown test failure was Re: [PATCH 4.4 00/30] 4.4.260-rc1 review

Hi!

> > > Ok, so we ran some tests.
> > >
> > > And they failed:
> > >
> > > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1075959449
> > >
> > > [ 26.785861] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=CVE-2018-3639 RESULT=fail>
> > > Received signal: <TESTCASE> TEST_CASE_ID=CVE-2018-3639 RESULT=fail
> > >
> > > Testcase name is spectre-meltdown-checker... Failing on qemu? Somehow
> > > strange, but it looks like real test failure.

This is pointer to the pipeline:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/265992696

> First let me try 7d472e4a11d6a2fb1c492b02c7d7dacd3297bbf4 --
> v4.4.257-cip54. That is
> https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266532179
> ... Qemu is OKAY.
>
> add3ff3730919447a7519fede0b8554132e0f8d5 Merge remote-tracking branch
> 'stable/queue/4.4' in to v4.4.260-bisect. Results will be at
> https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266534478
> ... ... still pending.

Qemu is okay here, too.

> test 266539168 8c461bb103f89696576945ad9cb376df34fa9d28 xen-netback: respect gnttab_map_refs()'s return value

Qemu is ok.

> test 266538760 1efe86b456816c95485c65cf9ba46a5bff8a241e staging: fwserial: Fix error handling in fwserial_create

Qemu is ok.

> test 266539768 8b4bc0f97fdd13b08c2436aad01bd4515d07f93a iwlwifi: pcie: fix to correct null check
Pavel
Qemu is ok.

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266539768

So... failure apparently went away when trying to
bisect. That's.... strange? Aha, except that it looks like the same
"suceeded" tests still have failures in them:

https://lava.ciplatform.org/scheduler/job/173186

[ 26.224557] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=CVE-2017-5715
RESULT=fail>
Received signal: <TESTCASE> TEST_CASE_ID=CVE-2017-5715 RESULT=fail

...I guess those fails are expected, then? And qemu tests on
-stable-rc are really failing on timeouts. ... Hmm, let's just re-run
the tests.

I'm still not sure, but it looks like a test failure now.

Best regards,

Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (2.25 kB)
signature.asc (188.00 B)
Digital signature
Download all attachments

2021-03-08 08:23:08

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/30] 4.4.260-rc1 review

Hi!

> > > This is the start of the stable review cycle for the 4.4.260 release.
> > > There are 30 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.
> >
> > Ok, so we ran some tests.

> > Testcase name is spectre-meltdown-checker... Failing on qemu? Somehow
> > strange, but it looks like real test failure.

Some kind of timeout, fixed by re-run. So CIP testing did not find any
problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.4.y

Tested-by: Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (827.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments