This is the start of the stable review cycle for the 4.4.196 release.
There are 36 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
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.196-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.196-rc1
Andrey Konovalov <[email protected]>
NFC: fix attrs checks in netlink interface
Eric Biggers <[email protected]>
smack: use GFP_NOFS while holding inode_smack::smk_lock
Jann Horn <[email protected]>
Smack: Don't ignore other bprm->unsafe flags if LSM_UNSAFE_PTRACE is set
Eric Dumazet <[email protected]>
sch_cbq: validate TCA_CBQ_WRROPT to avoid crash
Dotan Barak <[email protected]>
net/rds: Fix error handling in rds_ib_add_one()
Dongli Zhang <[email protected]>
xen-netfront: do not use ~0U as error return value for xennet_fill_frags()
Eric Dumazet <[email protected]>
sch_dsmark: fix potential NULL deref in dsmark_init()
Eric Dumazet <[email protected]>
nfc: fix memory leak in llcp_sock_bind()
Navid Emamdoost <[email protected]>
net: qlogic: Fix memory leak in ql_alloc_large_buffers
Paolo Abeni <[email protected]>
net: ipv4: avoid mixed n_redirects and rate_tokens usage
Eric Dumazet <[email protected]>
ipv6: drop incoming packets having a v4mapped source address
Johan Hovold <[email protected]>
hso: fix NULL-deref on tty open
Martijn Coenen <[email protected]>
ANDROID: binder: synchronize_rcu() when using POLLFREE.
Martijn Coenen <[email protected]>
ANDROID: binder: remove waitqueue when thread exits.
Nicolas Boichat <[email protected]>
kmemleak: increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE default to 16K
Changwei Ge <[email protected]>
ocfs2: wait for recovering done after direct unlock request
David Howells <[email protected]>
hypfs: Fix error number left in struct pointer member
OGAWA Hirofumi <[email protected]>
fat: work around race with userspace's read via blockdev while mounting
Jia-Ju Bai <[email protected]>
security: smack: Fix possible null-pointer dereferences in smack_socket_sock_rcv_skb()
Joao Moreno <[email protected]>
HID: apple: Fix stuck function keys when using FN
Will Deacon <[email protected]>
ARM: 8898/1: mm: Don't treat faults reported from cache maintenance as writes
Kai-Heng Feng <[email protected]>
mfd: intel-lpss: Remove D3cold delay
Bart Van Assche <[email protected]>
scsi: core: Reduce memory required for SCSI logging
Nathan Lynch <[email protected]>
powerpc/pseries: correctly track irq state in default idle
Nicholas Piggin <[email protected]>
powerpc/64s/exception: machine check use correct cfar for late handler
hexin <[email protected]>
vfio_pci: Restore original state on release
Sam Bobroff <[email protected]>
powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag
Sowjanya Komatineni <[email protected]>
pinctrl: tegra: Fix write barrier placement in pmx_writel
Nathan Lynch <[email protected]>
powerpc/pseries/mobility: use cond_resched when updating device tree
Christophe Leroy <[email protected]>
powerpc/futex: Fix warning: 'oldval' may be used uninitialized in this function
Nathan Lynch <[email protected]>
powerpc/rtas: use device model APIs and serialization during LPM
Stephen Boyd <[email protected]>
clk: sirf: Don't reference clk_init_data after registration
Nathan Huckleberry <[email protected]>
clk: qoriq: Fix -Wunused-const-variable
Corey Minyard <[email protected]>
ipmi_si: Only schedule continuously in the thread in maintenance mode
Jia-Ju Bai <[email protected]>
gpu: drm: radeon: Fix a possible null-pointer dereference in radeon_connector_set_property()
Marko Kohtala <[email protected]>
video: ssd1307fb: Start page range at page_offset
-------------
Diffstat:
Makefile | 4 +--
arch/arm/mm/fault.c | 4 +--
arch/arm/mm/fault.h | 1 +
arch/powerpc/include/asm/futex.h | 3 +-
arch/powerpc/kernel/eeh_driver.c | 11 ++++++-
arch/powerpc/kernel/exceptions-64s.S | 4 +++
arch/powerpc/kernel/rtas.c | 11 +++++--
arch/powerpc/platforms/pseries/mobility.c | 9 ++++++
arch/powerpc/platforms/pseries/setup.c | 3 ++
arch/s390/hypfs/inode.c | 9 +++---
drivers/android/binder.c | 26 +++++++++++++++-
drivers/char/ipmi/ipmi_si_intf.c | 24 ++++++++++++---
drivers/clk/clk-qoriq.c | 2 +-
drivers/clk/sirf/clk-common.c | 12 +++++---
drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
drivers/hid/hid-apple.c | 49 +++++++++++++++++-------------
drivers/mfd/intel-lpss-pci.c | 2 ++
drivers/net/ethernet/qlogic/qla3xxx.c | 1 +
drivers/net/usb/hso.c | 12 +++++---
drivers/net/xen-netfront.c | 17 ++++++-----
drivers/pinctrl/pinctrl-tegra.c | 4 ++-
drivers/scsi/scsi_logging.c | 48 ++---------------------------
drivers/vfio/pci/vfio_pci.c | 17 ++++++++---
drivers/video/fbdev/ssd1307fb.c | 2 +-
fs/fat/dir.c | 13 ++++++--
fs/fat/fatent.c | 3 ++
fs/ocfs2/dlm/dlmunlock.c | 23 +++++++++++---
include/scsi/scsi_dbg.h | 2 --
lib/Kconfig.debug | 2 +-
net/ipv4/route.c | 5 ++-
net/ipv6/ip6_input.c | 10 ++++++
net/nfc/llcp_sock.c | 7 ++++-
net/nfc/netlink.c | 6 ++--
net/rds/ib.c | 6 ++--
net/sched/sch_cbq.c | 27 +++++++++++++---
net/sched/sch_dsmark.c | 2 ++
security/smack/smack_access.c | 4 +--
security/smack/smack_lsm.c | 7 +++--
38 files changed, 257 insertions(+), 137 deletions(-)
From: Nathan Lynch <[email protected]>
[ Upstream commit ccfb5bd71d3d1228090a8633800ae7cdf42a94ac ]
After a partition migration, pseries_devicetree_update() processes
changes to the device tree communicated from the platform to
Linux. This is a relatively heavyweight operation, with multiple
device tree searches, memory allocations, and conversations with
partition firmware.
There's a few levels of nested loops which are bounded only by
decisions made by the platform, outside of Linux's control, and indeed
we have seen RCU stalls on large systems while executing this call
graph. Use cond_resched() in these loops so that the cpu is yielded
when needed.
Signed-off-by: Nathan Lynch <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/powerpc/platforms/pseries/mobility.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index c773396d0969b..8d30a425a88ab 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <linux/kobject.h>
+#include <linux/sched.h>
#include <linux/smp.h>
#include <linux/stat.h>
#include <linux/completion.h>
@@ -206,7 +207,11 @@ static int update_dt_node(__be32 phandle, s32 scope)
prop_data += vd;
}
+
+ cond_resched();
}
+
+ cond_resched();
} while (rtas_rc == 1);
of_node_put(dn);
@@ -282,8 +287,12 @@ int pseries_devicetree_update(s32 scope)
add_dt_node(phandle, drc_index);
break;
}
+
+ cond_resched();
}
}
+
+ cond_resched();
} while (rc == 1);
kfree(rtas_buf);
--
2.20.1
From: Eric Biggers <[email protected]>
commit e5bfad3d7acc5702f32aafeb388362994f4d7bd0 upstream.
inode_smack::smk_lock is taken during smack_d_instantiate(), which is
called during a filesystem transaction when creating a file on ext4.
Therefore to avoid a deadlock, all code that takes this lock must use
GFP_NOFS, to prevent memory reclaim from waiting for the filesystem
transaction to complete.
Reported-by: [email protected]
Cc: [email protected]
Signed-off-by: Eric Biggers <[email protected]>
Signed-off-by: Casey Schaufler <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
security/smack/smack_access.c | 4 ++--
security/smack/smack_lsm.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/security/smack/smack_access.c
+++ b/security/smack/smack_access.c
@@ -474,7 +474,7 @@ char *smk_parse_smack(const char *string
if (i == 0 || i >= SMK_LONGLABEL)
return ERR_PTR(-EINVAL);
- smack = kzalloc(i + 1, GFP_KERNEL);
+ smack = kzalloc(i + 1, GFP_NOFS);
if (smack == NULL)
return ERR_PTR(-ENOMEM);
@@ -545,7 +545,7 @@ struct smack_known *smk_import_entry(con
if (skp != NULL)
goto freeout;
- skp = kzalloc(sizeof(*skp), GFP_KERNEL);
+ skp = kzalloc(sizeof(*skp), GFP_NOFS);
if (skp == NULL) {
skp = ERR_PTR(-ENOMEM);
goto freeout;
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -268,7 +268,7 @@ static struct smack_known *smk_fetch(con
if (ip->i_op->getxattr == NULL)
return ERR_PTR(-EOPNOTSUPP);
- buffer = kzalloc(SMK_LONGLABEL, GFP_KERNEL);
+ buffer = kzalloc(SMK_LONGLABEL, GFP_NOFS);
if (buffer == NULL)
return ERR_PTR(-ENOMEM);
From: Dongli Zhang <[email protected]>
[ Upstream commit a761129e3625688310aecf26e1be9e98e85f8eb5 ]
xennet_fill_frags() uses ~0U as return value when the sk_buff is not able
to cache extra fragments. This is incorrect because the return type of
xennet_fill_frags() is RING_IDX and 0xffffffff is an expected value for
ring buffer index.
In the situation when the rsp_cons is approaching 0xffffffff, the return
value of xennet_fill_frags() may become 0xffffffff which xennet_poll() (the
caller) would regard as error. As a result, queue->rx.rsp_cons is set
incorrectly because it is updated only when there is error. If there is no
error, xennet_poll() would be responsible to update queue->rx.rsp_cons.
Finally, queue->rx.rsp_cons would point to the rx ring buffer entries whose
queue->rx_skbs[i] and queue->grant_rx_ref[i] are already cleared to NULL.
This leads to NULL pointer access in the next iteration to process rx ring
buffer entries.
The symptom is similar to the one fixed in
commit 00b368502d18 ("xen-netfront: do not assume sk_buff_head list is
empty in error handling").
This patch changes the return type of xennet_fill_frags() to indicate
whether it is successful or failed. The queue->rx.rsp_cons will be
always updated inside this function.
Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
Signed-off-by: Dongli Zhang <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/xen-netfront.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -874,9 +874,9 @@ static int xennet_set_skb_gso(struct sk_
return 0;
}
-static RING_IDX xennet_fill_frags(struct netfront_queue *queue,
- struct sk_buff *skb,
- struct sk_buff_head *list)
+static int xennet_fill_frags(struct netfront_queue *queue,
+ struct sk_buff *skb,
+ struct sk_buff_head *list)
{
RING_IDX cons = queue->rx.rsp_cons;
struct sk_buff *nskb;
@@ -895,7 +895,7 @@ static RING_IDX xennet_fill_frags(struct
if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) {
queue->rx.rsp_cons = ++cons + skb_queue_len(list);
kfree_skb(nskb);
- return ~0U;
+ return -ENOENT;
}
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
@@ -906,7 +906,9 @@ static RING_IDX xennet_fill_frags(struct
kfree_skb(nskb);
}
- return cons;
+ queue->rx.rsp_cons = cons;
+
+ return 0;
}
static int checksum_setup(struct net_device *dev, struct sk_buff *skb)
@@ -1032,8 +1034,7 @@ err:
skb->data_len = rx->status;
skb->len += rx->status;
- i = xennet_fill_frags(queue, skb, &tmpq);
- if (unlikely(i == ~0U))
+ if (unlikely(xennet_fill_frags(queue, skb, &tmpq)))
goto err;
if (rx->flags & XEN_NETRXF_csum_blank)
@@ -1043,7 +1044,7 @@ err:
__skb_queue_tail(&rxq, skb);
- queue->rx.rsp_cons = ++i;
+ i = ++queue->rx.rsp_cons;
work_done++;
}
From: Navid Emamdoost <[email protected]>
[ Upstream commit 1acb8f2a7a9f10543868ddd737e37424d5c36cf4 ]
In ql_alloc_large_buffers, a new skb is allocated via netdev_alloc_skb.
This skb should be released if pci_dma_mapping_error fails.
Fixes: 0f8ab89e825f ("qla3xxx: Check return code from pci_map_single() in ql_release_to_lrg_buf_free_list(), ql_populate_free_queue(), ql_alloc_large_buffers(), and ql3xxx_send()")
Signed-off-by: Navid Emamdoost <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/qlogic/qla3xxx.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/qlogic/qla3xxx.c
+++ b/drivers/net/ethernet/qlogic/qla3xxx.c
@@ -2783,6 +2783,7 @@ static int ql_alloc_large_buffers(struct
netdev_err(qdev->ndev,
"PCI mapping failed with error: %d\n",
err);
+ dev_kfree_skb_irq(skb);
ql_free_large_buffers(qdev);
return -ENOMEM;
}
From: Eric Dumazet <[email protected]>
[ Upstream commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3 ]
This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.
After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls reqsk_queue_hash_req()
reqsk_queue_hash_req() calls sk_ehashfn(sk)
At this point we have AF_INET6 sockets, and the heuristic
used by sk_ehashfn() to either hash the IPv4 or IPv6 addresses
is to use ipv6_addr_v4mapped(&sk->sk_v6_daddr)
For the particular spoofed packet, we end up hashing V4 addresses
which were not initialized by the TCP IPv6 stack, so KMSAN fired
a warning.
I first fixed sk_ehashfn() to test both source and destination addresses,
but then faced various problems, including user-space programs
like packetdrill that had similar assumptions.
Instead of trying to fix the whole ecosystem, it is better
to admit that we have a dual stack behavior, and that we
can not build linux kernels without V4 stack anyway.
The dual stack API automatically forces the traffic to be IPv4
if v4mapped addresses are used at bind() or connect(), so it makes
no sense to allow IPv6 traffic to use the same v4mapped class.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Florian Westphal <[email protected]>
Cc: Hannes Frederic Sowa <[email protected]>
Reported-by: syzbot <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_input.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -151,6 +151,16 @@ int ipv6_rcv(struct sk_buff *skb, struct
if (ipv6_addr_is_multicast(&hdr->saddr))
goto err;
+ /* While RFC4291 is not explicit about v4mapped addresses
+ * in IPv6 headers, it seems clear linux dual-stack
+ * model can not deal properly with these.
+ * Security models could be fooled by ::ffff:127.0.0.1 for example.
+ *
+ * https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
+ */
+ if (ipv6_addr_v4mapped(&hdr->saddr))
+ goto err;
+
skb->transport_header = skb->network_header + sizeof(*hdr);
IP6CB(skb)->nhoff = offsetof(struct ipv6hdr, nexthdr);
From: Will Deacon <[email protected]>
[ Upstream commit 834020366da9ab3fb87d1eb9a3160eb22dbed63a ]
Translation faults arising from cache maintenance instructions are
rather unhelpfully reported with an FSR value where the WnR field is set
to 1, indicating that the faulting access was a write. Since cache
maintenance instructions on 32-bit ARM do not require any particular
permissions, this can cause our private 'cacheflush' system call to fail
spuriously if a translation fault is generated due to page aging when
targetting a read-only VMA.
In this situation, we will return -EFAULT to userspace, although this is
unfortunately suppressed by the popular '__builtin___clear_cache()'
intrinsic provided by GCC, which returns void.
Although it's tempting to write this off as a userspace issue, we can
actually do a little bit better on CPUs that support LPAE, even if the
short-descriptor format is in use. On these CPUs, cache maintenance
faults additionally set the CM field in the FSR, which we can use to
suppress the write permission checks in the page fault handler and
succeed in performing cache maintenance to read-only areas even in the
presence of a translation fault.
Reported-by: Orion Hodson <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/arm/mm/fault.c | 4 ++--
arch/arm/mm/fault.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 0d20cd5940171..702a5542b11a8 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -211,7 +211,7 @@ static inline bool access_error(unsigned int fsr, struct vm_area_struct *vma)
{
unsigned int mask = VM_READ | VM_WRITE | VM_EXEC;
- if (fsr & FSR_WRITE)
+ if ((fsr & FSR_WRITE) && !(fsr & FSR_CM))
mask = VM_WRITE;
if (fsr & FSR_LNX_PF)
mask = VM_EXEC;
@@ -281,7 +281,7 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
if (user_mode(regs))
flags |= FAULT_FLAG_USER;
- if (fsr & FSR_WRITE)
+ if ((fsr & FSR_WRITE) && !(fsr & FSR_CM))
flags |= FAULT_FLAG_WRITE;
/*
diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
index 78830657cab3a..b014e57248044 100644
--- a/arch/arm/mm/fault.h
+++ b/arch/arm/mm/fault.h
@@ -5,6 +5,7 @@
* Fault status register encodings. We steal bit 31 for our own purposes.
*/
#define FSR_LNX_PF (1 << 31)
+#define FSR_CM (1 << 13)
#define FSR_WRITE (1 << 11)
#define FSR_FS4 (1 << 10)
#define FSR_FS3_0 (15)
--
2.20.1
From: Eric Dumazet <[email protected]>
[ Upstream commit 474f0813a3002cb299bb73a5a93aa1f537a80ca8 ]
Make sure TCA_DSMARK_INDICES was provided by the user.
syzbot reported :
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8799 Comm: syz-executor235 Not tainted 5.3.0+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:nla_get_u16 include/net/netlink.h:1501 [inline]
RIP: 0010:dsmark_init net/sched/sch_dsmark.c:364 [inline]
RIP: 0010:dsmark_init+0x193/0x640 net/sched/sch_dsmark.c:339
Code: 85 db 58 0f 88 7d 03 00 00 e8 e9 1a ac fb 48 8b 9d 70 ff ff ff 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 ca
RSP: 0018:ffff88809426f3b8 EFLAGS: 00010247
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff85c6eb09
RDX: 0000000000000000 RSI: ffffffff85c6eb17 RDI: 0000000000000004
RBP: ffff88809426f4b0 R08: ffff88808c4085c0 R09: ffffed1015d26159
R10: ffffed1015d26158 R11: ffff8880ae930ac7 R12: ffff8880a7e96940
R13: dffffc0000000000 R14: ffff88809426f8c0 R15: 0000000000000000
FS: 0000000001292880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000080 CR3: 000000008ca1b000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
qdisc_create+0x4ee/0x1210 net/sched/sch_api.c:1237
tc_modify_qdisc+0x524/0x1c50 net/sched/sch_api.c:1653
rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5223
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5241
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
___sys_sendmsg+0x803/0x920 net/socket.c:2311
__sys_sendmsg+0x105/0x1d0 net/socket.c:2356
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440369
Fixes: 758cc43c6d73 ("[PKT_SCHED]: Fix dsmark to apply changes consistent")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/sch_dsmark.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/sched/sch_dsmark.c
+++ b/net/sched/sch_dsmark.c
@@ -362,6 +362,8 @@ static int dsmark_init(struct Qdisc *sch
goto errout;
err = -EINVAL;
+ if (!tb[TCA_DSMARK_INDICES])
+ goto errout;
indices = nla_get_u16(tb[TCA_DSMARK_INDICES]);
if (hweight32(indices) != 1)
From: Paolo Abeni <[email protected]>
[ Upstream commit b406472b5ad79ede8d10077f0c8f05505ace8b6d ]
Since commit c09551c6ff7f ("net: ipv4: use a dedicated counter
for icmp_v4 redirect packets") we use 'n_redirects' to account
for redirect packets, but we still use 'rate_tokens' to compute
the redirect packets exponential backoff.
If the device sent to the relevant peer any ICMP error packet
after sending a redirect, it will also update 'rate_token' according
to the leaking bucket schema; typically 'rate_token' will raise
above BITS_PER_LONG and the redirect packets backoff algorithm
will produce undefined behavior.
Fix the issue using 'n_redirects' to compute the exponential backoff
in ip_rt_send_redirect().
Note that we still clear rate_tokens after a redirect silence period,
to avoid changing an established behaviour.
The root cause predates git history; before the mentioned commit in
the critical scenario, the kernel stopped sending redirects, after
the mentioned commit the behavior more randomic.
Reported-by: Xiumei Mu <[email protected]>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: c09551c6ff7f ("net: ipv4: use a dedicated counter for icmp_v4 redirect packets")
Signed-off-by: Paolo Abeni <[email protected]>
Acked-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/route.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -897,16 +897,15 @@ void ip_rt_send_redirect(struct sk_buff
if (peer->rate_tokens == 0 ||
time_after(jiffies,
(peer->rate_last +
- (ip_rt_redirect_load << peer->rate_tokens)))) {
+ (ip_rt_redirect_load << peer->n_redirects)))) {
__be32 gw = rt_nexthop(rt, ip_hdr(skb)->daddr);
icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, gw);
peer->rate_last = jiffies;
- ++peer->rate_tokens;
++peer->n_redirects;
#ifdef CONFIG_IP_ROUTE_VERBOSE
if (log_martians &&
- peer->rate_tokens == ip_rt_redirect_number)
+ peer->n_redirects == ip_rt_redirect_number)
net_warn_ratelimited("host %pI4/if%d ignores redirects for %pI4 to %pI4\n",
&ip_hdr(skb)->saddr, inet_iif(skb),
&ip_hdr(skb)->daddr, &gw);
From: Stephen Boyd <[email protected]>
[ Upstream commit af55dadfbce35b4f4c6247244ce3e44b2e242b84 ]
A future patch is going to change semantics of clk_register() so that
clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid
referencing this member here so that we don't run into NULL pointer
exceptions.
Cc: Guo Zeng <[email protected]>
Cc: Barry Song <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/clk/sirf/clk-common.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sirf/clk-common.c b/drivers/clk/sirf/clk-common.c
index 77e1e2491689b..edb7197cc4b4d 100644
--- a/drivers/clk/sirf/clk-common.c
+++ b/drivers/clk/sirf/clk-common.c
@@ -298,9 +298,10 @@ static u8 dmn_clk_get_parent(struct clk_hw *hw)
{
struct clk_dmn *clk = to_dmnclk(hw);
u32 cfg = clkc_readl(clk->regofs);
+ const char *name = clk_hw_get_name(hw);
/* parent of io domain can only be pll3 */
- if (strcmp(hw->init->name, "io") == 0)
+ if (strcmp(name, "io") == 0)
return 4;
WARN_ON((cfg & (BIT(3) - 1)) > 4);
@@ -312,9 +313,10 @@ static int dmn_clk_set_parent(struct clk_hw *hw, u8 parent)
{
struct clk_dmn *clk = to_dmnclk(hw);
u32 cfg = clkc_readl(clk->regofs);
+ const char *name = clk_hw_get_name(hw);
/* parent of io domain can only be pll3 */
- if (strcmp(hw->init->name, "io") == 0)
+ if (strcmp(name, "io") == 0)
return -EINVAL;
cfg &= ~(BIT(3) - 1);
@@ -354,7 +356,8 @@ static long dmn_clk_round_rate(struct clk_hw *hw, unsigned long rate,
{
unsigned long fin;
unsigned ratio, wait, hold;
- unsigned bits = (strcmp(hw->init->name, "mem") == 0) ? 3 : 4;
+ const char *name = clk_hw_get_name(hw);
+ unsigned bits = (strcmp(name, "mem") == 0) ? 3 : 4;
fin = *parent_rate;
ratio = fin / rate;
@@ -376,7 +379,8 @@ static int dmn_clk_set_rate(struct clk_hw *hw, unsigned long rate,
struct clk_dmn *clk = to_dmnclk(hw);
unsigned long fin;
unsigned ratio, wait, hold, reg;
- unsigned bits = (strcmp(hw->init->name, "mem") == 0) ? 3 : 4;
+ const char *name = clk_hw_get_name(hw);
+ unsigned bits = (strcmp(name, "mem") == 0) ? 3 : 4;
fin = parent_rate;
ratio = fin / rate;
--
2.20.1
From: Andrey Konovalov <[email protected]>
commit 18917d51472fe3b126a3a8f756c6b18085eb8130 upstream.
nfc_genl_deactivate_target() relies on the NFC_ATTR_TARGET_INDEX
attribute being present, but doesn't check whether it is actually
provided by the user. Same goes for nfc_genl_fw_download() and
NFC_ATTR_FIRMWARE_NAME.
This patch adds appropriate checks.
Found with syzkaller.
Signed-off-by: Andrey Konovalov <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/nfc/netlink.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -936,7 +936,8 @@ static int nfc_genl_dep_link_down(struct
int rc;
u32 idx;
- if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+ if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
+ !info->attrs[NFC_ATTR_TARGET_INDEX])
return -EINVAL;
idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
@@ -985,7 +986,8 @@ static int nfc_genl_llc_get_params(struc
struct sk_buff *msg = NULL;
u32 idx;
- if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+ if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
+ !info->attrs[NFC_ATTR_FIRMWARE_NAME])
return -EINVAL;
idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
From: Jann Horn <[email protected]>
commit 3675f052b43ba51b99b85b073c7070e083f3e6fb upstream.
There is a logic bug in the current smack_bprm_set_creds():
If LSM_UNSAFE_PTRACE is set, but the ptrace state is deemed to be
acceptable (e.g. because the ptracer detached in the meantime), the other
->unsafe flags aren't checked. As far as I can tell, this means that
something like the following could work (but I haven't tested it):
- task A: create task B with fork()
- task B: set NO_NEW_PRIVS
- task B: install a seccomp filter that makes open() return 0 under some
conditions
- task B: replace fd 0 with a malicious library
- task A: attach to task B with PTRACE_ATTACH
- task B: execve() a file with an SMACK64EXEC extended attribute
- task A: while task B is still in the middle of execve(), exit (which
destroys the ptrace relationship)
Make sure that if any flags other than LSM_UNSAFE_PTRACE are set in
bprm->unsafe, we reject the execve().
Cc: [email protected]
Fixes: 5663884caab1 ("Smack: unify all ptrace accesses in the smack")
Signed-off-by: Jann Horn <[email protected]>
Signed-off-by: Casey Schaufler <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
security/smack/smack_lsm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -932,7 +932,8 @@ static int smack_bprm_set_creds(struct l
if (rc != 0)
return rc;
- } else if (bprm->unsafe)
+ }
+ if (bprm->unsafe & ~LSM_UNSAFE_PTRACE)
return -EPERM;
bsp->smk_task = isp->smk_task;
From: Eric Dumazet <[email protected]>
[ Upstream commit a0c2dc1fe63e2869b74c1c7f6a81d1745c8a695d ]
sysbot reported a memory leak after a bind() has failed.
While we are at it, abort the operation if kmemdup() has failed.
BUG: memory leak
unreferenced object 0xffff888105d83ec0 (size 32):
comm "syz-executor067", pid 7207, jiffies 4294956228 (age 19.430s)
hex dump (first 32 bytes):
00 69 6c 65 20 72 65 61 64 00 6e 65 74 3a 5b 34 .ile read.net:[4
30 32 36 35 33 33 30 39 37 5d 00 00 00 00 00 00 026533097]......
backtrace:
[<0000000036bac473>] kmemleak_alloc_recursive /./include/linux/kmemleak.h:43 [inline]
[<0000000036bac473>] slab_post_alloc_hook /mm/slab.h:522 [inline]
[<0000000036bac473>] slab_alloc /mm/slab.c:3319 [inline]
[<0000000036bac473>] __do_kmalloc /mm/slab.c:3653 [inline]
[<0000000036bac473>] __kmalloc_track_caller+0x169/0x2d0 /mm/slab.c:3670
[<000000000cd39d07>] kmemdup+0x27/0x60 /mm/util.c:120
[<000000008e57e5fc>] kmemdup /./include/linux/string.h:432 [inline]
[<000000008e57e5fc>] llcp_sock_bind+0x1b3/0x230 /net/nfc/llcp_sock.c:107
[<000000009cb0b5d3>] __sys_bind+0x11c/0x140 /net/socket.c:1647
[<00000000492c3bbc>] __do_sys_bind /net/socket.c:1658 [inline]
[<00000000492c3bbc>] __se_sys_bind /net/socket.c:1656 [inline]
[<00000000492c3bbc>] __x64_sys_bind+0x1e/0x30 /net/socket.c:1656
[<0000000008704b2a>] do_syscall_64+0x76/0x1a0 /arch/x86/entry/common.c:296
[<000000009f4c57a4>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 30cc4587659e ("NFC: Move LLCP code to the NFC top level diirectory")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/nfc/llcp_sock.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -118,9 +118,14 @@ static int llcp_sock_bind(struct socket
llcp_sock->service_name = kmemdup(llcp_addr.service_name,
llcp_sock->service_name_len,
GFP_KERNEL);
-
+ if (!llcp_sock->service_name) {
+ ret = -ENOMEM;
+ goto put_dev;
+ }
llcp_sock->ssap = nfc_llcp_get_sdp_ssap(local, llcp_sock);
if (llcp_sock->ssap == LLCP_SAP_MAX) {
+ kfree(llcp_sock->service_name);
+ llcp_sock->service_name = NULL;
ret = -EADDRINUSE;
goto put_dev;
}
From: Kai-Heng Feng <[email protected]>
[ Upstream commit 76380a607ba0b28627c9b4b55cd47a079a59624b ]
Goodix touchpad may drop its first couple input events when
i2c-designware-platdrv and intel-lpss it connects to took too long to
runtime resume from runtime suspended state.
This issue happens becuase the touchpad has a rather small buffer to
store up to 13 input events, so if the host doesn't read those events in
time (i.e. runtime resume takes too long), events are dropped from the
touchpad's buffer.
The bottleneck is D3cold delay it waits when transitioning from D3cold
to D0, hence remove the delay to make the resume faster. I've tested
some systems with intel-lpss and haven't seen any regression.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202683
Signed-off-by: Kai-Heng Feng <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mfd/intel-lpss-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index 5bfdfccbb9a1a..032c95157497f 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -38,6 +38,8 @@ static int intel_lpss_pci_probe(struct pci_dev *pdev,
info->mem = &pdev->resource[0];
info->irq = pdev->irq;
+ pdev->d3cold_delay = 0;
+
/* Probably it is enough to set this for iDMA capable devices only */
pci_set_master(pdev);
--
2.20.1
stable-rc/linux-4.4.y boot: 39 boots: 1 failed, 36 passed with 2 conflicts (v4.4.195-37-g13cac61d31df)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.195-37-g13cac61d31df/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.195-37-g13cac61d31df/
Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.195-37-g13cac61d31df
Git Commit: 13cac61d31df3572c7a2c88f2f40c59e0a92baf2
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 21 unique boards, 10 SoC families, 8 builds out of 190
Boot Failure Detected:
arm64:
defconfig:
gcc-8:
qcom-qdf2400: 1 failed lab
Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
x86_64:
x86_64_defconfig:
qemu_x86_64:
lab-baylibre: FAIL (gcc-8)
lab-linaro-lkft: PASS (gcc-8)
i386:
i386_defconfig:
qemu_i386:
lab-baylibre: FAIL (gcc-8)
lab-linaro-lkft: PASS (gcc-8)
---
For more info write to <[email protected]>
On 06/10/2019 18:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.196 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
> 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.196-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
All tests are passing for Tegra ...
Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail
19 tests: 19 pass, 0 fail
Linux version: 4.4.196-rc1-g2082eedffaaa
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.196 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
> Anything received after that time might be too late.
>
powerpc:defconfig fails to build.
arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function ‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?
It has a point:
... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
$ git grep eeh_for_each_pe
arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag").
Full report will follow later.
Guenter
On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.196 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
> Anything received after that time might be too late.
>
Build results:
total: 170 pass: 169 fail: 1
Failed builds:
powerpc:defconfig
Qemu test results:
total: 324 pass: 313 fail: 11
Failed tests:
ppc64:mac99:ppc64_book3s_defconfig:nosmp:initrd
ppc64:mac99:ppc64_book3s_defconfig:smp:initrd
ppc64:mac99:ppc64_book3s_defconfig:smp:ide:rootfs
ppc64:mac99:ppc64_book3s_defconfig:smp:sdhci:mmc:rootfs
ppc64:mac99:ppc64_book3s_defconfig:smp:nvme:rootfs
ppc64:mac99:ppc64_book3s_defconfig:smp:scsi[DC395]:rootfs
ppc64:pseries:pseries_defconfig:initrd
ppc64:pseries:pseries_defconfig:scsi:rootfs
ppc64:pseries:pseries_defconfig:usb:rootfs
ppc64:pseries:pseries_defconfig:sdhci:mmc:rootfs
ppc64:pseries:pseries_defconfig:nvme:rootfs
Failure as already reported.
arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function ‘eeh_for_each_pe’
Guenter
On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:
> On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.196 release.
> > There are 36 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
> > Anything received after that time might be too late.
> >
>
> powerpc:defconfig fails to build.
>
> arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
> arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function ‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?
>
> It has a point:
>
> ... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
> $ git grep eeh_for_each_pe
> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>
> Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag").
> Full report will follow later.
Thanks for letting me know, I've dropped this from the queue now and
pushed out a -rc2 with that removed.
Sasha, I thought your builder would have caught stuff like this?
thanks,
greg k-h
Hello!
On 10/6/19 12:18 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.196 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
> 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.196-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.
Summary
------------------------------------------------------------------------
kernel: 4.4.196-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: 13cac61d31df3572c7a2c88f2f40c59e0a92baf2
git describe: v4.4.195-37-g13cac61d31df
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.195-37-g13cac61d31df
No regressions (compared to build v4.4.195)
No fixes (compared to build v4.4.195)
Ran 18597 total tests in the following environments and test suites.
Environments
--------------
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* build
* kselftest
* libhugetlbfs
* 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-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-timers-tests
* network-basic-tests
* prep-tmp-disk
* spectre-meltdown-checker-test
* kvm-unit-tests
* ltp-syscalls-tests
* perf
* v4l2-compliance
* install-android-platform-tools-r2600
* kselftest-vsyscall-mode-native
* ssuite
Summary
------------------------------------------------------------------------
kernel: 4.4.196-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.196-rc1-hikey-20191006-575
git commit: 49d2751d5f3cdb81b162d5c1f7ffb0fe210f005c
git describe: 4.4.196-rc1-hikey-20191006-575
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.196-rc1-hikey-20191006-575
No regressions (compared to build 4.4.195-rc1-hikey-20191003-572)
No fixes (compared to build 4.4.195-rc1-hikey-20191003-572)
Ran 1520 total tests in the following environments and test suites.
Environments
--------------
- hi6220-hikey - arm64
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* 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
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
Greetings!
Daniel Díaz
[email protected]
--
Linaro LKFT
https://lkft.linaro.org
On 10/7/19 7:49 AM, Greg Kroah-Hartman wrote:
> On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:
>> On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.4.196 release.
>>> There are 36 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
>>> Anything received after that time might be too late.
>>>
>>
>> powerpc:defconfig fails to build.
>>
>> arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
>> arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function ‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?
>>
>> It has a point:
>>
>> ... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
>> $ git grep eeh_for_each_pe
>> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>>
>> Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag").
>> Full report will follow later.
>
> Thanks for letting me know, I've dropped this from the queue now and
> pushed out a -rc2 with that removed.
>
For v4.4.195-36-g898f6e5cf82f:
Build results:
total: 170 pass: 170 fail: 0
Qemu test results:
total: 324 pass: 324 fail: 0
Guenter
On Mon, Oct 07, 2019 at 04:49:51PM +0200, Greg Kroah-Hartman wrote:
>On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:
>> On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
>> > This is the start of the stable review cycle for the 4.4.196 release.
>> > There are 36 patches in this series, all will be posted as a response
>> > to this one. If anyone has any issues with these being applied, please
>> > let me know.
>> >
>> > Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
>> > Anything received after that time might be too late.
>> >
>>
>> powerpc:defconfig fails to build.
>>
>> arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
>> arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function ‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?
>>
>> It has a point:
>>
>> ... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
>> $ git grep eeh_for_each_pe
>> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>>
>> Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag").
>> Full report will follow later.
>
>Thanks for letting me know, I've dropped this from the queue now and
>pushed out a -rc2 with that removed.
>
>Sasha, I thought your builder would have caught stuff like this?
Interesting, the 4.4 build fails for me with vanilla 4.4 LTS kernel
(which is why this was missed):
AS arch/powerpc/kernel/systbl.o
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1599: Warning: invalid register expression
arch/powerpc/kernel/exceptions-64s.S:1640: Warning: invalid register expression
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:840: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:864: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:865: Error: attempt to move .org backwards
scripts/Makefile.build:375: recipe for target 'arch/powerpc/kernel/head_64.o' failed
I'll look into it.
--
Thanks,
Sasha
On 10/7/19 4:07 PM, Sasha Levin wrote:
> On Mon, Oct 07, 2019 at 04:49:51PM +0200, Greg Kroah-Hartman wrote:
>> On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:
>>> On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
>>> > This is the start of the stable review cycle for the 4.4.196 release.
>>> > There are 36 patches in this series, all will be posted as a response
>>> > to this one. If anyone has any issues with these being applied, please
>>> > let me know.
>>> >
>>> > Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
>>> > Anything received after that time might be too late.
>>> >
>>>
>>> powerpc:defconfig fails to build.
>>>
>>> arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
>>> arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function ‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?
>>>
>>> It has a point:
>>>
>>> ... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
>>> $ git grep eeh_for_each_pe
>>> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>>> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>>>
>>> Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag").
>>> Full report will follow later.
>>
>> Thanks for letting me know, I've dropped this from the queue now and
>> pushed out a -rc2 with that removed.
>>
>> Sasha, I thought your builder would have caught stuff like this?
>
> Interesting, the 4.4 build fails for me with vanilla 4.4 LTS kernel
> (which is why this was missed):
>
> AS arch/powerpc/kernel/systbl.o
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:1599: Warning: invalid register expression
> arch/powerpc/kernel/exceptions-64s.S:1640: Warning: invalid register expression
> arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
> arch/powerpc/kernel/exceptions-64s.S:840: Error: attempt to move .org backwards
> arch/powerpc/kernel/exceptions-64s.S:864: Error: attempt to move .org backwards
> arch/powerpc/kernel/exceptions-64s.S:865: Error: attempt to move .org backwards
> scripts/Makefile.build:375: recipe for target 'arch/powerpc/kernel/head_64.o' failed
>
Is this allmodconfig ? That is correct - it won't build in 4.4.y, and it would not be
easy to fix.
Guenter
On Mon, Oct 07, 2019 at 04:16:51PM -0700, Guenter Roeck wrote:
>On 10/7/19 4:07 PM, Sasha Levin wrote:
>>On Mon, Oct 07, 2019 at 04:49:51PM +0200, Greg Kroah-Hartman wrote:
>>>On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:
>>>>On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 4.4.196 release.
>>>>> There are 36 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>
>>>>powerpc:defconfig fails to build.
>>>>
>>>>arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
>>>>arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function ‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?
>>>>
>>>>It has a point:
>>>>
>>>>... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
>>>>$ git grep eeh_for_each_pe
>>>>arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>>>>arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>>>>
>>>>Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag").
>>>>Full report will follow later.
>>>
>>>Thanks for letting me know, I've dropped this from the queue now and
>>>pushed out a -rc2 with that removed.
>>>
>>>Sasha, I thought your builder would have caught stuff like this?
>>
>>Interesting, the 4.4 build fails for me with vanilla 4.4 LTS kernel
>>(which is why this was missed):
>>
>> AS arch/powerpc/kernel/systbl.o
>>arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
>>arch/powerpc/kernel/exceptions-64s.S:1599: Warning: invalid register expression
>>arch/powerpc/kernel/exceptions-64s.S:1640: Warning: invalid register expression
>>arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
>>arch/powerpc/kernel/exceptions-64s.S:840: Error: attempt to move .org backwards
>>arch/powerpc/kernel/exceptions-64s.S:864: Error: attempt to move .org backwards
>>arch/powerpc/kernel/exceptions-64s.S:865: Error: attempt to move .org backwards
>>scripts/Makefile.build:375: recipe for target 'arch/powerpc/kernel/head_64.o' failed
>>
>
>Is this allmodconfig ? That is correct - it won't build in 4.4.y, and it would not be
>easy to fix.
Oh, interesting, so no allmodconfig? I've disabled everything but
allmodconfig on a few architectures in an attempt to save to build time.
--
Thanks,
Sasha
On 10/7/19 6:49 PM, Sasha Levin wrote:
> On Mon, Oct 07, 2019 at 04:16:51PM -0700, Guenter Roeck wrote:
>> On 10/7/19 4:07 PM, Sasha Levin wrote:
>>> On Mon, Oct 07, 2019 at 04:49:51PM +0200, Greg Kroah-Hartman wrote:
>>>> On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:
>>>>> On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
>>>>>> This is the start of the stable review cycle for the 4.4.196 release.
>>>>>> There are 36 patches in this series, all will be posted as a response
>>>>>> to this one. If anyone has any issues with these being applied, please
>>>>>> let me know.
>>>>>>
>>>>>> Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
>>>>>> Anything received after that time might be too late.
>>>>>>
>>>>>
>>>>> powerpc:defconfig fails to build.
>>>>>
>>>>> arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
>>>>> arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function ‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?
>>>>>
>>>>> It has a point:
>>>>>
>>>>> ... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
>>>>> $ git grep eeh_for_each_pe
>>>>> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>>>>> arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
>>>>>
>>>>> Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag").
>>>>> Full report will follow later.
>>>>
>>>> Thanks for letting me know, I've dropped this from the queue now and
>>>> pushed out a -rc2 with that removed.
>>>>
>>>> Sasha, I thought your builder would have caught stuff like this?
>>>
>>> Interesting, the 4.4 build fails for me with vanilla 4.4 LTS kernel
>>> (which is why this was missed):
>>>
>>> AS arch/powerpc/kernel/systbl.o
>>> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
>>> arch/powerpc/kernel/exceptions-64s.S:1599: Warning: invalid register expression
>>> arch/powerpc/kernel/exceptions-64s.S:1640: Warning: invalid register expression
>>> arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
>>> arch/powerpc/kernel/exceptions-64s.S:840: Error: attempt to move .org backwards
>>> arch/powerpc/kernel/exceptions-64s.S:864: Error: attempt to move .org backwards
>>> arch/powerpc/kernel/exceptions-64s.S:865: Error: attempt to move .org backwards
>>> scripts/Makefile.build:375: recipe for target 'arch/powerpc/kernel/head_64.o' failed
>>>
>>
>> Is this allmodconfig ? That is correct - it won't build in 4.4.y, and it would not be
>> easy to fix.
>
> Oh, interesting, so no allmodconfig? I've disabled everything but
> allmodconfig on a few architectures in an attempt to save to build time.
>
If I recall correctly, it stopped working quite some time ago for v4.4.y, and the powerpc
maintainers didn't want to spend the time fixing it. It works with v4.9.y and later.
Guenter
On Mon, Oct 07, 2019 at 03:36:46PM -0700, Guenter Roeck wrote:
> On 10/7/19 7:49 AM, Greg Kroah-Hartman wrote:
> > On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:
> > > On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 4.4.196 release.
> > > > There are 36 patches in this series, all will be posted as a response
> > > > to this one. If anyone has any issues with these being applied, please
> > > > let me know.
> > > >
> > > > Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
> > > > Anything received after that time might be too late.
> > > >
> > >
> > > powerpc:defconfig fails to build.
> > >
> > > arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
> > > arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function ‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?
> > >
> > > It has a point:
> > >
> > > ... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
> > > $ git grep eeh_for_each_pe
> > > arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
> > > arch/powerpc/kernel/eeh_driver.c: eeh_for_each_pe(pe, tmp_pe)
> > >
> > > Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag").
> > > Full report will follow later.
> >
> > Thanks for letting me know, I've dropped this from the queue now and
> > pushed out a -rc2 with that removed.
> >
>
> For v4.4.195-36-g898f6e5cf82f:
>
> Build results:
> total: 170 pass: 170 fail: 0
> Qemu test results:
> total: 324 pass: 324 fail: 0
Wonderful, thanks for letting me know!
greg k-h