4.4.94-stable review
Subsystems (3)
Greg Kroah-Hartman
maintainercover 4.4.94-stable review
This is the start of the stable review cycle for the 4.4.94 release. There are 46 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat Oct 21 13:48:23 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.94-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.94-rc1
Greg Kroah-Hartman <[email protected]>
Revert "tty: goldfish: Fix a parameter of a call to free_irq"
Arnd Bergmann <[email protected]>
cpufreq: CPPC: add ACPI_PROCESSOR dependency
Kinglong Mee <[email protected]>
nfsd/callback: Cleanup callback cred on shutdown
Varun Prakash <[email protected]>
target/iscsi: Fix unsolicited data seq_end_offset calculation
Dmitry V. Levin <[email protected]>
uapi: fix linux/mroute6.h userspace compilation errors
Dmitry V. Levin <[email protected]>
uapi: fix linux/rds.h userspace compilation errors
Jeff Layton <[email protected]>
ceph: clean up unsafe d_parent accesses in build_dentry_path
Alexandre Belloni <[email protected]>
i2c: at91: ensure state is restored after suspending
Thomas Petazzoni <[email protected]>
net: mvpp2: release reference to txq_cpu[] entry after unmapping
Dan Carpenter <[email protected]>
scsi: scsi_dh_emc: return success in clariion_std_inquiry()
Grygorii Maistrenko <[email protected]>
slub: do not merge cache if slub_debug contains a never-merge flag
Eric Ren <[email protected]>
ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock
Milan Broz <[email protected]>
crypto: xts - Add ECB dependency
Majd Dibbiny <[email protected]>
net/mlx4_core: Fix VF overwrite of module param which disables DMFS on new probed PFs
Vijay Kumar <[email protected]>
sparc64: Migrate hvcons irq to panicked cpu
Shaohua Li <[email protected]>
md/linear: shutup lockdep warnning
Jaegeuk Kim <[email protected]>
f2fs: do not wait for writeback in write_begin
Robbie Ko <[email protected]>
Btrfs: send, fix failure to rename top level inode due to name collision
Christophe JAILLET <[email protected]>
iio: adc: xilinx: Fix error handling
Jarno Rajahalme <[email protected]>
netfilter: nf_ct_expect: Change __nf_ct_expect_check() return value.
Eric Dumazet <[email protected]>
net/mlx4_en: fix overflow in mlx4_en_init_timestamp()
Emmanuel Grumbach <[email protected]>
mac80211: fix power saving clients handling in iwlwifi
Johannes Berg <[email protected]>
mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length
Franck Demathieu <[email protected]>
irqchip/crossbar: Fix incorrect type of local variables
Arnd Bergmann <[email protected]>
watchdog: kempld: fix gcc-4.3 build
Peter Zijlstra <[email protected]>
locking/lockdep: Add nest_lock integrity test
Greg Kroah-Hartman <[email protected]>
Revert "bsg-lib: don't free job in bsg_prepare_job"
Parthasarathy Bhuvaragan <[email protected]>
tipc: use only positive error codes in messages
Christoph Paasch <[email protected]>
net: Set sk_prot_creator when cloning sockets to the right proto
Willem de Bruijn <[email protected]>
packet: only test po->has_vnet_hdr once in packet_snd
Willem de Bruijn <[email protected]>
packet: in packet_do_bind, test fanout with bind_lock held
Alexander Potapenko <[email protected]>
tun: bail out from tun_get_user() if the skb is empty
Sabrina Dubroca <[email protected]>
l2tp: fix race condition in l2tp_tunnel_delete
Ridge Kennedy <[email protected]>
l2tp: Avoid schedule while atomic in exit_net
Alexey Kodanev <[email protected]>
vti: fix use after free in vti_tunnel_xmit/vti6_tnl_xmit
Meng Xu <[email protected]>
isdn/i4l: fetch the ppp_write buffer in one shot
Yonghong Song <[email protected]>
bpf: one perf event close won't free bpf program attached by another perf event
Willem de Bruijn <[email protected]>
packet: hold bind lock when rebinding to fanout hook
Christian Lamparter <[email protected]>
net: emac: Fix napi poll list corruption
Xin Long <[email protected]>
ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header
Subash Abhinov Kasiviswanathan <[email protected]>
udpv6: Fix the checksum computation when HW checksum does not apply
Edward Cree <[email protected]>
bpf/verifier: reject BPF_ALU64|BPF_END
Dan Carpenter <[email protected]>
sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
Matt Redfearn <[email protected]>
MIPS: Fix minimum alignment requirement of IRQ stack
Harry Wentland <[email protected]>
drm/dp/mst: save vcpi with payloads
Mark Rutland <[email protected]>
percpu: make this_cpu_generic_read() atomic w.r.t. interrupts
-------------
Diffstat:
Makefile | 4 +- arch/mips/include/asm/irq.h | 2 +- arch/sparc/include/asm/setup.h | 5 +- arch/sparc/kernel/smp_64.c | 6 +- block/bsg-lib.c | 1 + crypto/Kconfig | 1 + drivers/cpufreq/Kconfig.arm | 2 +- drivers/gpu/drm/drm_dp_mst_topology.c | 2 + drivers/i2c/busses/i2c-at91.c | 3 + drivers/iio/adc/xilinx-xadc-core.c | 6 +- drivers/irqchip/irq-crossbar.c | 3 +- drivers/isdn/i4l/isdn_ppp.c | 37 ++++++--- drivers/md/linear.c | 3 +- drivers/net/ethernet/ibm/emac/mal.c | 3 +- drivers/net/ethernet/marvell/mvpp2.c | 9 +-- drivers/net/ethernet/mellanox/mlx4/en_clock.c | 18 ++--- drivers/net/ethernet/mellanox/mlx4/main.c | 2 - drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 - drivers/net/tun.c | 8 +- drivers/net/wireless/mac80211_hwsim.c | 28 +++++-- drivers/scsi/device_handler/scsi_dh_emc.c | 2 +- drivers/target/iscsi/iscsi_target_erl0.c | 6 +- drivers/tty/goldfish.c | 2 +- drivers/tty/serial/sunhv.c | 6 ++ drivers/watchdog/kempld_wdt.c | 9 ++- fs/btrfs/send.c | 5 +- fs/ceph/mds_client.c | 9 ++- fs/f2fs/data.c | 7 +- fs/nfsd/nfs4callback.c | 8 ++ fs/nfsd/nfs4state.c | 10 ++- fs/nfsd/state.h | 1 + fs/ocfs2/dlmglue.c | 105 +++++++++++++++++++++++++- fs/ocfs2/dlmglue.h | 18 +++++ fs/ocfs2/ocfs2.h | 1 + include/asm-generic/percpu.h | 24 +++++- include/linux/trace_events.h | 1 + include/net/sctp/ulpevent.h | 6 +- include/uapi/linux/mroute6.h | 1 + include/uapi/linux/rds.h | 3 +- kernel/bpf/verifier.c | 3 +- kernel/events/core.c | 3 +- kernel/locking/lockdep.c | 11 ++- mm/slab_common.c | 5 +- net/core/sock.c | 2 + net/ipv4/ip_vti.c | 3 +- net/ipv6/ip6_gre.c | 21 +++--- net/ipv6/ip6_vti.c | 3 +- net/ipv6/udp.c | 1 + net/l2tp/l2tp_core.c | 14 ++-- net/l2tp/l2tp_core.h | 5 +- net/mac80211/sta_info.c | 2 +- net/netfilter/nf_conntrack_expect.c | 4 +- net/packet/af_packet.c | 28 ++++--- net/tipc/msg.c | 2 +- 54 files changed, 362 insertions(+), 113 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/46 percpu: make this_cpu_generic_read() atomic w.r.t. interrupts
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit e88d62cd4b2f0b1ae55e9008e79c2794b1fc914d upstream.
As raw_cpu_generic_read() is a plain read from a raw_cpu_ptr() address, it's possible (albeit unlikely) that the compiler will split the access across multiple instructions.
In this_cpu_generic_read() we disable preemption but not interrupts before calling raw_cpu_generic_read(). Thus, an interrupt could be taken in the middle of the split load instructions. If a this_cpu_write() or RMW this_cpu_*() op is made to the same variable in the interrupt handling path, this_cpu_read() will return a torn value.
For native word types, we can avoid tearing using READ_ONCE(), but this won't work in all cases (e.g. 64-bit types on most 32-bit platforms). This patch reworks this_cpu_generic_read() to use READ_ONCE() where possible, otherwise falling back to disabling interrupts.
--- include/asm-generic/percpu.h | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-)
include/asm-generic/percpu.h +22 -2
@@ -105,15 +105,35 @@ do { \ (__ret); \ }) -#define this_cpu_generic_read (pcp) \ +#define __this_cpu_generic_read_nopreempt (pcp) \ ({ \ typeof(pcp) __ret; \ preempt_disable(); \ - __ret = *this_cpu_ptr(&(pcp)); \ + __ret = READ_ONCE(*raw_cpu_ptr(&(pcp))); \ preempt_enable(); \ __ret; \ }) +#define __this_cpu_generic_read_noirq (pcp) \ +({ \ + typeof(pcp) __ret; \ + unsigned long __flags; \ + raw_local_irq_save(__flags); \ + __ret = *raw_cpu_ptr(&(pcp)); \ + raw_local_irq_restore(__flags); \ + __ret; \ +}) + +#define this_cpu_generic_read (pcp) \ +({ \ + typeof(pcp) __ret; \ + if (__native_word(pcp)) \ + __ret = __this_cpu_generic_read_nopreempt(pcp); \ + else \ + __ret = __this_cpu_generic_read_noirq(pcp); \ + __ret; \ +}) +#define this_cpu_generic_to_op (pcp, val, op) \ do { \ unsigned long __flags; \
Greg Kroah-Hartman
maintainerPATCH 15/46 tun: bail out from tun_get_user() if the skb is empty
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Potapenko <[email protected]>
[ Upstream commit 2580c4c17aee3ad58e9751012bad278dd074ccae ]
KMSAN (https://github.com/google/kmsan) reported accessing uninitialized skb->data[0] in the case the skb is empty (i.e. skb->len is 0):
================================================
BUG: KMSAN: use of uninitialized memory in tun_get_user+0x19ba/0x3770 CPU: 0 PID: 3051 Comm: probe Not tainted 4.13.0+ #3140 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: ... __msan_warning_32+0x66/0xb0 mm/kmsan/kmsan_instr.c:477 tun_get_user+0x19ba/0x3770 drivers/net/tun.c:1301 tun_chr_write_iter+0x19f/0x300 drivers/net/tun.c:1365 call_write_iter ./include/linux/fs.h:1743 new_sync_write fs/read_write.c:457 __vfs_write+0x6c3/0x7f0 fs/read_write.c:470 vfs_write+0x3e4/0x770 fs/read_write.c:518 SYSC_write+0x12f/0x2b0 fs/read_write.c:565 SyS_write+0x55/0x80 fs/read_write.c:557 do_syscall_64+0x242/0x330 arch/x86/entry/common.c:284 entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:245 ... origin: ... kmsan_poison_shadow+0x6e/0xc0 mm/kmsan/kmsan.c:211 slab_alloc_node mm/slub.c:2732 __kmalloc_node_track_caller+0x351/0x370 mm/slub.c:4351 __kmalloc_reserve net/core/skbuff.c:138 __alloc_skb+0x26a/0x810 net/core/skbuff.c:231 alloc_skb ./include/linux/skbuff.h:903 alloc_skb_with_frags+0x1d7/0xc80 net/core/skbuff.c:4756 sock_alloc_send_pskb+0xabf/0xfe0 net/core/sock.c:2037 tun_alloc_skb drivers/net/tun.c:1144 tun_get_user+0x9a8/0x3770 drivers/net/tun.c:1274 tun_chr_write_iter+0x19f/0x300 drivers/net/tun.c:1365 call_write_iter ./include/linux/fs.h:1743 new_sync_write fs/read_write.c:457 __vfs_write+0x6c3/0x7f0 fs/read_write.c:470 vfs_write+0x3e4/0x770 fs/read_write.c:518 SYSC_write+0x12f/0x2b0 fs/read_write.c:565 SyS_write+0x55/0x80 fs/read_write.c:557 do_syscall_64+0x242/0x330 arch/x86/entry/common.c:284 return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:245 ================================================
Make sure tun_get_user() doesn't touch skb->data[0] unless there is actual data.
C reproducer below:
==========================
// autogenerated by syzkaller (http://github.com/google/syzkaller) #define _GNU_SOURCE #include <fcntl.h> #include <linux/if_tun.h> #include <netinet/ip.h> #include <net/if.h> #include <string.h> #include <sys/ioctl.h> int main() { int sock = socket(PF_INET, SOCK_STREAM, IPPROTO_IP); int tun_fd = open("/dev/net/tun", O_RDWR); struct ifreq req; memset(&req, 0, sizeof(struct ifreq)); strcpy((char*)&req.ifr_name, "gre0"); req.ifr_flags = IFF_UP | IFF_MULTICAST; ioctl(tun_fd, TUNSETIFF, &req); ioctl(sock, SIOCSIFFLAGS, "gre0"); write(tun_fd, "hi", 0); return 0; }
==========================
--- drivers/net/tun.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/net/tun.c +5 -3
@@ -1195,11 +1195,13 @@ static ssize_t tun_get_user(struct tun_sswitch (tun->flags &TUN_TYPE_MASK ) {case IFF_TUN :if (tun->flags &IFF_NO_PI ) { -switch (skb->data[0 ] &0xf0 ) { -case 0x40 : +u8 ip_version = skb->len ? (skb->data[0 ] >>4 ) :0 ; + +switch (ip_version) { +case 4 : pi.proto =htons (ETH_P_IP );break ; -case 0x60 : +case 6 : pi.proto =htons (ETH_P_IPV6 );break ;default :
Greg Kroah-Hartman
maintainerPATCH 42/46 uapi: fix linux/mroute6.h userspace compilation errors
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Dmitry V. Levin" <[email protected]>
[ Upstream commit 72aa107df6a275cf03359934ca5799a2be7a1bf7 ]
Include <linux/in6.h> to fix the following linux/mroute6.h userspace compilation errors:
/usr/include/linux/mroute6.h:80:22: error: field 'mf6cc_origin' has incomplete type
struct sockaddr_in6 mf6cc_origin; /* Origin of mcast *//usr/include/linux/mroute6.h:81:22: error: field 'mf6cc_mcastgrp' has incomplete type
struct sockaddr_in6 mf6cc_mcastgrp; /* Group in question *//usr/include/linux/mroute6.h:91:22: error: field 'src' has incomplete type
struct sockaddr_in6 src;/usr/include/linux/mroute6.h:92:22: error: field 'grp' has incomplete type
struct sockaddr_in6 grp;/usr/include/linux/mroute6.h:132:18: error: field 'im6_src' has incomplete type
struct in6_addr im6_src, im6_dst;/usr/include/linux/mroute6.h:132:27: error: field 'im6_dst' has incomplete type
struct in6_addr im6_src, im6_dst;
--- include/uapi/linux/mroute6.h | 1 + 1 file changed, 1 insertion(+)
include/uapi/linux/mroute6.h +1 -0
@@ -3,6 +3,7 @@#include <linux/types.h> #include <linux/sockios.h> +#include <linux/in6.h> /* For struct sockaddr_in6. */ /* * Based on the MROUTING 3.5 defines primarily to keep
Greg Kroah-Hartman
maintainerPATCH 10/46 bpf: one perf event close wont free bpf program attached by another perf event
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yonghong Song <[email protected]>
[ Upstream commit ec9dd352d591f0c90402ec67a317c1ed4fb2e638 ]
This patch fixes a bug exhibited by the following scenario:
1. fd1 = perf_event_open with attr.config = ID1
2. attach bpf program prog1 to fd1
3. fd2 = perf_event_open with attr.config = ID1
<this will be successful>
4. user program closes fd2 and prog1 is detached from the tracepoint.
5. user program with fd1 does not work properly as tracepoint no output any more.
The issue happens at step 4. Multiple perf_event_open can be called successfully, but only one bpf prog pointer in the tp_event. In the current logic, any fd release for the same tp_event will free the tp_event->prog.
The fix is to free tp_event->prog only when the closing fd corresponds to the one which registered the program.
--- include/linux/trace_events.h | 1 + kernel/events/core.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-)
include/linux/trace_events.h +1 -0
@@ -301,6 +301,7 @@ struct trace_event_call {int perf_refcount;struct hlist_head __percpu *perf_events;struct bpf_prog *prog; +struct perf_event *bpf_prog_owner;int (*perf_perm)(struct trace_event_call *,struct perf_event *);
kernel/events/core.c +2 -1
@@ -7108,6 +7108,7 @@ static int perf_event_set_bpf_prog(struc } event->tp_event->prog = prog; + event->tp_event->bpf_prog_owner = event;return 0 ; }
@@ -7120,7 +7121,7 @@ static void perf_event_free_bpf_prog(strreturn ; prog = event->tp_event->prog; -if (prog) { +if (prog && event->tp_event->bpf_prog_owner == event) { event->tp_event->prog =NULL ;bpf_prog_put_rcu (prog); }
Greg Kroah-Hartman
maintainerPATCH 11/46 isdn/i4l: fetch the ppp_write buffer in one shot
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Meng Xu <[email protected]>
[ Upstream commit 02388bf87f72e1d47174cd8f81c34443920eb5a0 ]
In isdn_ppp_write(), the header (i.e., protobuf) of the buffer is fetched twice from userspace. The first fetch is used to peek at the protocol of the message and reset the huptimer if necessary; while the second fetch copies in the whole buffer. However, given that buf resides in userspace memory, a user process can race to change its memory content across fetches. By doing so, we can either avoid resetting the huptimer for any type of packets (by first setting proto to PPP_LCP and later change to the actual type) or force resetting the huptimer for LCP packets.
This patch changes this double-fetch behavior into two single fetches decided by condition (lp->isdn_device < 0 || lp->isdn_channel <0). A more detailed discussion can be found at
https://marc.info/?l=linux-kernel&m=150586376926123&w=2
--- drivers/isdn/i4l/isdn_ppp.c | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-)
drivers/isdn/i4l/isdn_ppp.c +25 -12
@@ -828,7 +828,6 @@ isdn_ppp_write(int min, struct file *filisdn_net_local *lp;struct ippp_struct *is;int proto; -unsigned char protobuf[4 ]; is = file->private_data;
@@ -842,24 +841,28 @@ isdn_ppp_write(int min, struct file *filif (!lp)printk (KERN_DEBUG "isdn_ppp_write: lp == NULL\n" );else { -/* -* Don't reset huptimer for -* LCP packets. (Echo requests). -*/ -if (copy_from_user (protobuf, buf,4 )) -return -EFAULT ; - proto =PPP_PROTOCOL (protobuf); -if (proto !=PPP_LCP ) - lp->huptimer =0 ; +if (lp->isdn_device <0 || lp->isdn_channel <0 ) { +unsigned char protobuf[4 ]; +/* +* Don't reset huptimer for +* LCP packets. (Echo requests). +*/ +if (copy_from_user (protobuf, buf,4 )) +return -EFAULT ; + + proto =PPP_PROTOCOL (protobuf); +if (proto !=PPP_LCP ) + lp->huptimer =0 ; -if (lp->isdn_device <0 || lp->isdn_channel <0 )return 0 ; + }if ((dev->drv[lp->isdn_device]->flags &DRV_FLAG_RUNNING ) && lp->dialstate ==0 && (lp->flags &ISDN_NET_CONNECTED )) {unsigned short hl;struct sk_buff *skb; +unsigned char *cpy_buf;/* * we need to reserve enough space in front of * sk_buff. old call to dev_alloc_skb only reserved
@@ -872,11 +875,21 @@ isdn_ppp_write(int min, struct file *filreturn count; }skb_reserve (skb, hl); -if (copy_from_user (skb_put (skb, count), buf, count)) + cpy_buf =skb_put (skb, count); +if (copy_from_user (cpy_buf, buf, count)) {kfree_skb (skb);return -EFAULT ; } + +/* +* Don't reset huptimer for +* LCP packets. (Echo requests). +*/ + proto =PPP_PROTOCOL (cpy_buf); +if (proto !=PPP_LCP ) + lp->huptimer =0 ; +if (is->debug &0x40 ) {printk (KERN_DEBUG "ppp xmit: len %d\n" , (int ) skb->len);isdn_ppp_frame_log ("xmit" , skb->data, skb->len,32 , is->unit, lp->ppp_slot);
Greg Kroah-Hartman
maintainerPATCH 12/46 vti: fix use after free in vti_tunnel_xmit/vti6_tnl_xmit
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Kodanev <[email protected]>
[ Upstream commit 36f6ee22d2d66046e369757ec6bbe1c482957ba6 ]
When running LTP IPsec tests, KASan might report:
BUG: KASAN: use-after-free in vti_tunnel_xmit+0xeee/0xff0 [ip_vti] Read of size 4 at addr ffff880dc6ad1980 by task swapper/0/0 ... Call Trace: <IRQ> dump_stack+0x63/0x89 print_address_description+0x7c/0x290 kasan_report+0x28d/0x370 ? vti_tunnel_xmit+0xeee/0xff0 [ip_vti] __asan_report_load4_noabort+0x19/0x20 vti_tunnel_xmit+0xeee/0xff0 [ip_vti] ? vti_init_net+0x190/0x190 [ip_vti] ? save_stack_trace+0x1b/0x20 ? save_stack+0x46/0xd0 dev_hard_start_xmit+0x147/0x510 ? icmp_echo.part.24+0x1f0/0x210 __dev_queue_xmit+0x1394/0x1c60 ... Freed by task 0: save_stack_trace+0x1b/0x20 save_stack+0x46/0xd0 kasan_slab_free+0x70/0xc0 kmem_cache_free+0x81/0x1e0 kfree_skbmem+0xb1/0xe0 kfree_skb+0x75/0x170 kfree_skb_list+0x3e/0x60 __dev_queue_xmit+0x1298/0x1c60 dev_queue_xmit+0x10/0x20 neigh_resolve_output+0x3a8/0x740 ip_finish_output2+0x5c0/0xe70 ip_finish_output+0x4ba/0x680 ip_output+0x1c1/0x3a0 xfrm_output_resume+0xc65/0x13d0 xfrm_output+0x1e4/0x380 xfrm4_output_finish+0x5c/0x70
Can be fixed if we get skb->len before dst_output().
--- net/ipv4/ip_vti.c | 3 ++- net/ipv6/ip6_vti.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
net/ipv4/ip_vti.c +2 -1
@@ -156,6 +156,7 @@ static netdev_tx_t vti_xmit(struct sk_bustruct ip_tunnel_parm *parms = &tunnel->parms;struct dst_entry *dst =skb_dst (skb);struct net_device *tdev;/* Device to other host */ +int pkt_len = skb->len;int err;if (!dst) {
@@ -199,7 +200,7 @@ static netdev_tx_t vti_xmit(struct sk_bu err =dst_output (tunnel->net, skb->sk, skb);if (net_xmit_eval (err) ==0 ) - err = skb->len; + err = pkt_len;iptunnel_xmit_stats (err, &dev->stats, dev->tstats);return NETDEV_TX_OK ;
net/ipv6/ip6_vti.c +2 -1
@@ -434,6 +434,7 @@ vti6_xmit(struct sk_buff *skb, struct nestruct dst_entry *dst =skb_dst (skb);struct net_device *tdev;struct xfrm_state *x; +int pkt_len = skb->len;int err =-1 ;int mtu;
@@ -487,7 +488,7 @@ vti6_xmit(struct sk_buff *skb, struct nestruct pcpu_sw_netstats *tstats =this_cpu_ptr (dev->tstats);u64_stats_update_begin (&tstats->syncp); - tstats->tx_bytes += skb->len; + tstats->tx_bytes += pkt_len; tstats->tx_packets++;u64_stats_update_end (&tstats->syncp); }else {
Greg Kroah-Hartman
maintainerPATCH 13/46 l2tp: Avoid schedule while atomic in exit_net
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ridge Kennedy <[email protected]>
[ Upstream commit 12d656af4e3d2781b9b9f52538593e1717e7c979 ]
While destroying a network namespace that contains a L2TP tunnel a "BUG: scheduling while atomic" can be observed.
Enabling lockdep shows that this is happening because l2tp_exit_net() is calling l2tp_tunnel_closeall() (via l2tp_tunnel_delete()) from within an RCU critical section.
l2tp_exit_net() takes rcu_read_lock_bh()
<< list_for_each_entry_rcu() >>
l2tp_tunnel_delete()
l2tp_tunnel_closeall()
__l2tp_session_unhash()
synchronize_rcu() << Illegal inside RCU critical section >>
BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 0, pid: 86, name: kworker/u16:2 INFO: lockdep is turned off. CPU: 2 PID: 86 Comm: kworker/u16:2 Tainted: G W O 4.4.6-at1 #2 Hardware name: Xen HVM domU, BIOS 4.6.1-xs125300 05/09/2016 Workqueue: netns cleanup_net 0000000000000000 ffff880202417b90 ffffffff812b0013 ffff880202410ac0 ffffffff81870de8 ffff880202417bb8 ffffffff8107aee8 ffffffff81870de8 0000000000000c51 0000000000000000 ffff880202417be0 ffffffff8107b024 Call Trace: [<ffffffff812b0013>] dump_stack+0x85/0xc2 [<ffffffff8107aee8>] ___might_sleep+0x148/0x240 [<ffffffff8107b024>] __might_sleep+0x44/0x80 [<ffffffff810b21bd>] synchronize_sched+0x2d/0xe0 [<ffffffff8109be6d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8105c7bb>] ? __local_bh_enable_ip+0x6b/0xc0 [<ffffffff816a1b00>] ? _raw_spin_unlock_bh+0x30/0x40 [<ffffffff81667482>] __l2tp_session_unhash+0x172/0x220 [<ffffffff81667397>] ? __l2tp_session_unhash+0x87/0x220 [<ffffffff8166888b>] l2tp_tunnel_closeall+0x9b/0x140 [<ffffffff81668c74>] l2tp_tunnel_delete+0x14/0x60 [<ffffffff81668dd0>] l2tp_exit_net+0x110/0x270 [<ffffffff81668d5c>] ? l2tp_exit_net+0x9c/0x270 [<ffffffff815001c3>] ops_exit_list.isra.6+0x33/0x60 [<ffffffff81501166>] cleanup_net+0x1b6/0x280 ...
This bug can easily be reproduced with a few steps:
$ sudo unshare -n bash # Create a shell in a new namespace
# ip link set lo up
# ip addr add 127.0.0.1 dev lo
# ip l2tp add tunnel remote 127.0.0.1 local 127.0.0.1 tunnel_id 1 \
peer_tunnel_id 1 udp_sport 50000 udp_dport 50000
# ip l2tp add session name foo tunnel_id 1 session_id 1 \
peer_session_id 1
# ip link set foo up
# exit # Exit the shell, in turn exiting the namespace
$ dmesg
...
[942121.089216] BUG: scheduling while atomic: kworker/u16:3/13872/0x00000200
...To fix this, move the call to l2tp_tunnel_closeall() out of the RCU critical section, and instead call it from l2tp_tunnel_del_work(), which is running from the l2tp_wq workqueue.
--- net/l2tp/l2tp_core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/l2tp/l2tp_core.c +3 -1
@@ -1321,6 +1321,9 @@ static void l2tp_tunnel_del_work(structstruct sock *sk =NULL ; tunnel = container_of(work, struct l2tp_tunnel, del_work); + +l2tp_tunnel_closeall (tunnel); + sk =l2tp_tunnel_sock_lookup (tunnel);if (!sk) goto out;
@@ -1643,7 +1646,6 @@ EXPORT_SYMBOL_GPL(l2tp_tunnel_create);int l2tp_tunnel_delete (struct l2tp_tunnel *tunnel) {l2tp_tunnel_inc_refcount (tunnel); -l2tp_tunnel_closeall (tunnel);if (false ==queue_work (l2tp_wq, &tunnel->del_work)) {l2tp_tunnel_dec_refcount (tunnel);return 1 ;
Greg Kroah-Hartman
maintainerPATCH 14/46 l2tp: fix race condition in l2tp_tunnel_delete
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <[email protected]>
[ Upstream commit 62b982eeb4589b2e6d7c01a90590e3a4c2b2ca19 ]
If we try to delete the same tunnel twice, the first delete operation does a lookup (l2tp_tunnel_get), finds the tunnel, calls l2tp_tunnel_delete, which queues it for deletion by l2tp_tunnel_del_work.
The second delete operation also finds the tunnel and calls l2tp_tunnel_delete. If the workqueue has already fired and started running l2tp_tunnel_del_work, then l2tp_tunnel_delete will queue the same tunnel a second time, and try to free the socket again.
Add a dead flag to prevent firing the workqueue twice. Then we can remove the check of queue_work's result that was meant to prevent that race but doesn't.
Reproducer:
ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 local 192.168.0.2 remote 192.168.0.1 encap udp udp_sport 5000 udp_dport 6000 ip l2tp add session name l2tp1 tunnel_id 3000 session_id 1000 peer_session_id 2000
ip link set l2tp1 up
ip l2tp del tunnel tunnel_id 3000
ip l2tp del tunnel tunnel_id 3000
--- net/l2tp/l2tp_core.c | 10 ++++------ net/l2tp/l2tp_core.h | 5 ++++- 2 files changed, 8 insertions(+), 7 deletions(-)
net/l2tp/l2tp_core.c +4 -6
@@ -1643,14 +1643,12 @@ EXPORT_SYMBOL_GPL(l2tp_tunnel_create);/* This function is used by the netlink TUNNEL_DELETE command. */ -int l2tp_tunnel_delete (struct l2tp_tunnel *tunnel) +void l2tp_tunnel_delete (struct l2tp_tunnel *tunnel) { -l2tp_tunnel_inc_refcount (tunnel); -if (false ==queue_work (l2tp_wq, &tunnel->del_work)) { -l2tp_tunnel_dec_refcount (tunnel); -return 1 ; +if (!test_and_set_bit (0 , &tunnel->dead)) { +l2tp_tunnel_inc_refcount (tunnel); +queue_work (l2tp_wq, &tunnel->del_work); } -return 0 ; }EXPORT_SYMBOL_GPL (l2tp_tunnel_delete);
net/l2tp/l2tp_core.h +4 -1
@@ -169,6 +169,9 @@ struct l2tp_tunnel_cfg {struct l2tp_tunnel {int magic;/* Should be L2TP_TUNNEL_MAGIC */ + +unsigned long dead; +struct rcu_head rcu;rwlock_t hlist_lock;/* protect session_hlist */ struct hlist_head session_hlist[L2TP_HASH_SIZE ];
@@ -253,7 +256,7 @@ int l2tp_tunnel_create(struct net *net, u32 peer_tunnel_id, struct l2tp_tunnel_cfg *cfg, struct l2tp_tunnel **tunnelp);void l2tp_tunnel_closeall (struct l2tp_tunnel *tunnel); -int l2tp_tunnel_delete (struct l2tp_tunnel *tunnel); +void l2tp_tunnel_delete (struct l2tp_tunnel *tunnel); struct l2tp_session *l2tp_session_create(int priv_size, struct l2tp_tunnel *tunnel, u32 session_id, u32 peer_session_id,
Greg Kroah-Hartman
maintainerPATCH 16/46 packet: in packet_do_bind, test fanout with bind_lock held
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Willem de Bruijn <[email protected]>
[ Upstream commit 4971613c1639d8e5f102c4e797c3bf8f83a5a69e ]
Once a socket has po->fanout set, it remains a member of the group until it is destroyed. The prot_hook must be constant and identical across sockets in the group.
If fanout_add races with packet_do_bind between the test of po->fanout and taking the lock, the bind call may make type or dev inconsistent with that of the fanout group.
Hold po->bind_lock when testing po->fanout to avoid this race.
I had to introduce artificial delay (local_bh_enable) to actually observe the race.
--- net/packet/af_packet.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
net/packet/af_packet.c +5 -3
@@ -2944,13 +2944,15 @@ static int packet_do_bind(struct sock *sint ret =0 ;bool unlisted = false; -if (po->fanout) -return -EINVAL ; -lock_sock (sk);spin_lock (&po->bind_lock);rcu_read_lock (); +if (po->fanout) { + ret = -EINVAL ; + goto out_unlock; + } +if (name) { dev =dev_get_by_name_rcu (sock_net (sk), name);if (!dev) {
Greg Kroah-Hartman
maintainerPATCH 17/46 packet: only test po->has_vnet_hdr once in packet_snd
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Willem de Bruijn <[email protected]>
[ Upstream commit da7c9561015e93d10fe6aab73e9288e0d09d65a6 ]
Packet socket option po->has_vnet_hdr can be updated concurrently with other operations if no ring is attached.
Do not test the option twice in packet_snd, as the value may change in between calls. A race on setsockopt disable may cause a packet > mtu to be sent without having GSO options set.
--- net/packet/af_packet.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/packet/af_packet.c +4 -2
@@ -1717,7 +1717,7 @@ static int fanout_add(struct sock *sk, u }spin_unlock (&po->bind_lock); -if (err && !refcount_read (&match->sk_ref)) { +if (err && !atomic_read (&match->sk_ref)) {list_del (&match->list);kfree (match); }
@@ -2656,6 +2656,7 @@ static int packet_snd(struct socket *socint vnet_hdr_len;struct packet_sock *po =pkt_sk (sk);unsigned short gso_type =0 ; +bool has_vnet_hdr = false;int hlen, tlen, linear;int extra_len =0 ;ssize_t n;
@@ -2743,6 +2744,7 @@ static int packet_snd(struct socket *soc goto out_unlock; } + has_vnet_hdr = true; }if (unlikely (sock_flag (sk,SOCK_NOFCS ))) {
@@ -2802,7 +2804,7 @@ static int packet_snd(struct socket *socpacket_pick_tx_queue (dev, skb); -if (po->has_vnet_hdr) { +if (has_vnet_hdr) {if (vnet_hdr.flags &VIRTIO_NET_HDR_F_NEEDS_CSUM ) {u16 s =__virtio16_to_cpu (vio_le (), vnet_hdr.csum_start);u16 o =__virtio16_to_cpu (vio_le (), vnet_hdr.csum_offset);
Greg Kroah-Hartman
maintainerPATCH 18/46 net: Set sk_prot_creator when cloning sockets to the right proto
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Paasch <[email protected]>
[ Upstream commit 9d538fa60bad4f7b23193c89e843797a1cf71ef3 ]
sk->sk_prot and sk->sk_prot_creator can differ when the app uses IPV6_ADDRFORM (transforming an IPv6-socket to an IPv4-one). Which is why sk_prot_creator is there to make sure that sk_prot_free() does the kmem_cache_free() on the right kmem_cache slab.
Now, if such a socket gets transformed back to a listening socket (using connect() with AF_UNSPEC) we will allocate an IPv4 tcp_sock through sk_clone_lock() when a new connection comes in. But sk_prot_creator will still point to the IPv6 kmem_cache (as everything got copied in sk_clone_lock()). When freeing, we will thus put this
memory back into the IPv6 kmem_cache although it was allocated in the IPv4 cache. I have seen memory corruption happening because of this.
With slub-debugging and MEMCG_KMEM enabled this gives the warning
"cache_from_obj: Wrong slab cache. TCPv6 but object is from TCP"
A C-program to trigger this:
void main(void)
{
int fd = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP);
int new_fd, newest_fd, client_fd;
struct sockaddr_in6 bind_addr;
struct sockaddr_in bind_addr4, client_addr1, client_addr2;
struct sockaddr unsp;
int val;
memset(&bind_addr, 0, sizeof(bind_addr));
bind_addr.sin6_family = AF_INET6;
bind_addr.sin6_port = ntohs(42424);
memset(&client_addr1, 0, sizeof(client_addr1));
client_addr1.sin_family = AF_INET;
client_addr1.sin_port = ntohs(42424);
client_addr1.sin_addr.s_addr = inet_addr("127.0.0.1");
memset(&client_addr2, 0, sizeof(client_addr2));
client_addr2.sin_family = AF_INET;
client_addr2.sin_port = ntohs(42421);
client_addr2.sin_addr.s_addr = inet_addr("127.0.0.1");
memset(&unsp, 0, sizeof(unsp));
unsp.sa_family = AF_UNSPEC;
bind(fd, (struct sockaddr *)&bind_addr, sizeof(bind_addr));
listen(fd, 5);
client_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
connect(client_fd, (struct sockaddr *)&client_addr1, sizeof(client_addr1));
new_fd = accept(fd, NULL, NULL);
close(fd);
val = AF_INET;
setsockopt(new_fd, SOL_IPV6, IPV6_ADDRFORM, &val, sizeof(val));
connect(new_fd, &unsp, sizeof(unsp));
memset(&bind_addr4, 0, sizeof(bind_addr4));
bind_addr4.sin_family = AF_INET;
bind_addr4.sin_port = ntohs(42421);
bind(new_fd, (struct sockaddr *)&bind_addr4, sizeof(bind_addr4));
listen(new_fd, 5);
client_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
connect(client_fd, (struct sockaddr *)&client_addr2, sizeof(client_addr2));
newest_fd = accept(new_fd, NULL, NULL);
close(new_fd);
close(client_fd);
close(new_fd);
}As far as I can see, this bug has been there since the beginning of the git-days.
--- net/core/sock.c | 2 ++ 1 file changed, 2 insertions(+)
net/core/sock.c +2 -0
@@ -1516,6 +1516,8 @@ struct sock *sk_clone_lock(const structsock_copy (newsk, sk); + newsk->sk_prot_creator = sk->sk_prot; +/* SANITY */ if (likely (newsk->sk_net_refcnt))get_net (sock_net (newsk));
Greg Kroah-Hartman
maintainerPATCH 19/46 tipc: use only positive error codes in messages
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Parthasarathy Bhuvaragan <[email protected]>
[ Upstream commit aad06212d36cf34859428a0a279e5c14ee5c9e26 ]
In commit e3a77561e7d32 ("tipc: split up function tipc_msg_eval()"), we have updated the function tipc_msg_lookup_dest() to set the error codes to negative values at destination lookup failures. Thus when the function sets the error code to -TIPC_ERR_NO_NAME, its inserted into the 4 bit error field of the message header as 0xf instead of TIPC_ERR_NO_NAME (1). The value 0xf is an unknown error code.
In this commit, we set only positive error code.
--- net/tipc/msg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/tipc/msg.c +1 -1
@@ -541,7 +541,7 @@ bool tipc_msg_lookup_dest(struct net *nereturn false;if (msg_errcode (msg))return false; - *err = -TIPC_ERR_NO_NAME ; + *err =TIPC_ERR_NO_NAME ;if (skb_linearize (skb))return false; msg =buf_msg (skb);
Greg Kroah-Hartman
maintainerPATCH 2/46 drm/dp/mst: save vcpi with payloads
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harry Wentland <[email protected]>
commit 6cecdf7a161d2b909dc7c8979176bbc4f0669968 upstream.
This makes it possibly for drivers to find the associated mst_port by looking at the payload allocation table.
--- drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/drm_dp_mst_topology.c +2 -0
@@ -1802,6 +1802,7 @@ int drm_dp_update_payload_part1(struct dreturn -EINVAL ; } req_payload.num_slots = mgr->proposed_vcpis[i]->num_slots; + req_payload.vcpi = mgr->proposed_vcpis[i]->vcpi; }else { port =NULL ; req_payload.num_slots =0 ;
@@ -1817,6 +1818,7 @@ int drm_dp_update_payload_part1(struct dif (req_payload.num_slots) {drm_dp_create_payload_step1 (mgr, mgr->proposed_vcpis[i]->vcpi, &req_payload); mgr->payloads[i].num_slots = req_payload.num_slots; + mgr->payloads[i].vcpi = req_payload.vcpi; }else if (mgr->payloads[i].num_slots) { mgr->payloads[i].num_slots =0 ;drm_dp_destroy_payload_step1 (mgr, port, mgr->payloads[i].vcpi, &mgr->payloads[i]);
Greg Kroah-Hartman
maintainerPATCH 22/46 watchdog: kempld: fix gcc-4.3 build
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 3736d4eb6af37492aeded7fec0072dedd959c842 ]
gcc-4.3 can't decide whether the constant value in kempld_prescaler[PRESCALER_21] is built-time constant or not, and gets confused by the logic in do_div():
drivers/watchdog/kempld_wdt.o: In function `kempld_wdt_set_stage_timeout':
kempld_wdt.c:(.text.kempld_wdt_set_stage_timeout+0x130): undefined reference to `__aeabi_uldivmod'
This adds a call to ACCESS_ONCE() to force it to not consider it to be constant, and leaves the more efficient normal case in place for modern compilers, using an #ifdef to annotate why we do this hack.
--- drivers/watchdog/kempld_wdt.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/watchdog/kempld_wdt.c +8 -1
@@ -140,12 +140,19 @@ static int kempld_wdt_set_stage_timeout( unsigned int timeout) {struct kempld_device_data *pld = wdt_data->pld; -u32 prescaler = kempld_prescaler[PRESCALER_21 ]; +u32 prescaler;u64 stage_timeout64;u32 stage_timeout;u32 remainder;u8 stage_cfg; +#if GCC_VERSION <40400 +/* work around a bug compiling do_div() */ + prescaler =READ_ONCE (kempld_prescaler[PRESCALER_21 ]); +#else + prescaler = kempld_prescaler[PRESCALER_21 ]; +#endif +if (!stage)return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 23/46 irqchip/crossbar: Fix incorrect type of local variables
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Franck Demathieu <[email protected]>
[ Upstream commit b28ace12661fbcfd90959c1e84ff5a85113a82a1 ]
The max and entry variables are unsigned according to the dt-bindings. Fix following 3 sparse issues (-Wtypesign):
drivers/irqchip/irq-crossbar.c:222:52: warning: incorrect type in argument 3 (different signedness)
drivers/irqchip/irq-crossbar.c:222:52: expected unsigned int [usertype] *out_value
drivers/irqchip/irq-crossbar.c:222:52: got int *<noident>
drivers/irqchip/irq-crossbar.c:245:56: warning: incorrect type in argument 4 (different signedness)
drivers/irqchip/irq-crossbar.c:245:56: expected unsigned int [usertype] *out_value
drivers/irqchip/irq-crossbar.c:245:56: got int *<noident>
drivers/irqchip/irq-crossbar.c:263:56: warning: incorrect type in argument 4 (different signedness)
drivers/irqchip/irq-crossbar.c:263:56: expected unsigned int [usertype] *out_value
drivers/irqchip/irq-crossbar.c:263:56: got int *<noident>
--- drivers/irqchip/irq-crossbar.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/irqchip/irq-crossbar.c +2 -1
@@ -198,7 +198,8 @@ static const struct irq_domain_ops crossstatic int __init crossbar_of_init (struct device_node *node) { -int i, size, max =0 , reserved =0 , entry; +int i, size, reserved =0 ; +u32 max =0 , entry;const __be32 *irqsr;int ret = -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 24/46 mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
[ Upstream commit ff4dd73dd2b4806419f8ff65cbce11d5019548d0 ]
Unfortunately, the nla policy was defined to have HWSIM_ATTR_RADIO_NAME as an NLA_STRING, rather than NLA_NUL_STRING, so we can't use it as a NUL-terminated string in the kernel.
Rather than break the API, kasprintf() the string to a new buffer to guarantee NUL termination.
--- drivers/net/wireless/mac80211_hwsim.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-)
drivers/net/wireless/mac80211_hwsim.c +21 -7
@@ -2884,6 +2884,7 @@ static int hwsim_register_received_nl(ststatic int hwsim_new_radio_nl (struct sk_buff *msg,struct genl_info *info) {struct hwsim_new_radio_params param = {0 }; +const char *hwname =NULL ; param.reg_strict = info->attrs[HWSIM_ATTR_REG_STRICT_REG ]; param.p2p_device = info->attrs[HWSIM_ATTR_SUPPORT_P2P_DEVICE ];
@@ -2897,8 +2898,14 @@ static int hwsim_new_radio_nl(struct sk_if (info->attrs[HWSIM_ATTR_NO_VIF ]) param.no_vif = true; -if (info->attrs[HWSIM_ATTR_RADIO_NAME ]) - param.hwname =nla_data (info->attrs[HWSIM_ATTR_RADIO_NAME ]); +if (info->attrs[HWSIM_ATTR_RADIO_NAME ]) { + hwname =kasprintf (GFP_KERNEL ,"%.*s" , +nla_len (info->attrs[HWSIM_ATTR_RADIO_NAME ]), + (char *)nla_data (info->attrs[HWSIM_ATTR_RADIO_NAME ])); +if (!hwname) +return -ENOMEM ; + param.hwname = hwname; + }if (info->attrs[HWSIM_ATTR_USE_CHANCTX ]) param.use_chanctx = true;
@@ -2926,11 +2933,15 @@ static int hwsim_del_radio_nl(struct sk_s64 idx =-1 ;const char *hwname =NULL ; -if (info->attrs[HWSIM_ATTR_RADIO_ID ]) +if (info->attrs[HWSIM_ATTR_RADIO_ID ]) { idx =nla_get_u32 (info->attrs[HWSIM_ATTR_RADIO_ID ]); -else if (info->attrs[HWSIM_ATTR_RADIO_NAME ]) - hwname = (void *)nla_data (info->attrs[HWSIM_ATTR_RADIO_NAME ]); -else + }else if (info->attrs[HWSIM_ATTR_RADIO_NAME ]) { + hwname =kasprintf (GFP_KERNEL ,"%.*s" , +nla_len (info->attrs[HWSIM_ATTR_RADIO_NAME ]), + (char *)nla_data (info->attrs[HWSIM_ATTR_RADIO_NAME ])); +if (!hwname) +return -ENOMEM ; + }else return -EINVAL ;spin_lock_bh (&hwsim_radio_lock);
@@ -2939,7 +2950,8 @@ static int hwsim_del_radio_nl(struct sk_if (data->idx != idx)continue ; }else { -if (strcmp (hwname,wiphy_name (data->hw->wiphy))) +if (!hwname || +strcmp (hwname,wiphy_name (data->hw->wiphy)))continue ; }
@@ -2947,10 +2959,12 @@ static int hwsim_del_radio_nl(struct sk_spin_unlock_bh (&hwsim_radio_lock);mac80211_hwsim_del_radio (data,wiphy_name (data->hw->wiphy), info); +kfree (hwname);return 0 ; }spin_unlock_bh (&hwsim_radio_lock); +kfree (hwname);return -ENODEV ; }
Greg Kroah-Hartman
maintainerPATCH 25/46 mac80211: fix power saving clients handling in iwlwifi
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emmanuel Grumbach <[email protected]>
[ Upstream commit d98937f4ea713d21e0fcc345919f86c877dd8d6f ]
iwlwifi now supports RSS and can't let mac80211 track the PS state based on the Rx frames since they can come out of order. iwlwifi is now advertising AP_LINK_PS, and uses explicit notifications to teach mac80211 about the PS state of the stations and the PS poll / uAPSD trigger frames coming our way from the peers.
Because of that, the TIM stopped being maintained in
mac80211. I tried to fix this in commit c68df2e7be0c ("mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE") but that was later reverted by Felix in commit 6c18a6b4e799 ("Revert "mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE") since it broke drivers that do not implement set_tim.
Since none of the drivers that set AP_LINK_PS have the set_tim() handler set besides iwlwifi, I can bail out in __sta_info_recalc_tim if AP_LINK_PS AND .set_tim is not implemented.
--- net/mac80211/sta_info.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/mac80211/sta_info.c +1 -1
@@ -661,7 +661,7 @@ static void __sta_info_recalc_tim(struct }/* No need to do anything if the driver does all */ -if (ieee80211_hw_check (&local->hw,AP_LINK_PS )) +if (ieee80211_hw_check (&local->hw,AP_LINK_PS ) && !local->ops->set_tim)return ;if (sta->dead)
Greg Kroah-Hartman
maintainerPATCH 26/46 net/mlx4_en: fix overflow in mlx4_en_init_timestamp()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 47d3a07528ecbbccf53bc4390d70b4e3d1c04fcf ]
The cited commit makes a great job of finding optimal shift/multiplier values assuming a 10 seconds wrap around, but forgot to change the overflow_period computation.
It overflows in cyclecounter_cyc2ns(), and the final result is 804 ms, which is silly.
Lets simply use 5 seconds, no need to recompute this, given how it is supposed to work.
Later, we will use a timer instead of a work queue, since the new RX allocation schem will no longer need mlx4_en_recover_from_oom() and the service_task firing every 250 ms.
--- drivers/net/ethernet/mellanox/mlx4/en_clock.c | 18 ++++++++---------- drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 - 2 files changed, 8 insertions(+), 11 deletions(-)
drivers/net/ethernet/mellanox/mlx4/en_clock.c +8 -10
@@ -88,10 +88,17 @@ void mlx4_en_remove_timestamp(struct mlx } } +#define MLX4_EN_WRAP_AROUND_SEC 10UL +/* By scheduling the overflow check every 5 seconds, we have a reasonably +* good chance we wont miss a wrap around. +* TOTO: Use a timer instead of a work queue to increase the guarantee. +*/ +#define MLX4_EN_OVERFLOW_PERIOD (MLX4_EN_WRAP_AROUND_SEC * HZ / 2) +void mlx4_en_ptp_overflow_check (struct mlx4_en_dev *mdev) {bool timeout =time_is_before_jiffies (mdev->last_overflow_check + - mdev->overflow_period); +MLX4_EN_OVERFLOW_PERIOD );unsigned long flags;if (timeout) {
@@ -236,7 +243,6 @@ static const struct ptp_clock_info mlx4_ .enable = mlx4_en_phc_enable, }; -#define MLX4_EN_WRAP_AROUND_SEC 10ULL/* This function calculates the max shift that enables the user range * of MLX4_EN_WRAP_AROUND_SEC values in the cycles register.
@@ -258,7 +264,6 @@ void mlx4_en_init_timestamp(struct mlx4_ {struct mlx4_dev *dev = mdev->dev;unsigned long flags; -u64 ns, zero =0 ;/* mlx4_en_init_timestamp is called for each netdev. * mdev->ptp_clock is common for all ports, skip initialization if
@@ -282,13 +287,6 @@ void mlx4_en_init_timestamp(struct mlx4_ ktime_to_ns(ktime_get_real()));write_unlock_irqrestore (&mdev->clock_lock, flags); -/* Calculate period in seconds to call the overflow watchdog - to make -* sure counter is checked at least once every wrap around. -*/ - ns =cyclecounter_cyc2ns (&mdev->cycles, mdev->cycles.mask, zero, &zero); -do_div (ns,NSEC_PER_SEC /2 /HZ ); - mdev->overflow_period = ns; -/* Configure the PHC */ mdev->ptp_clock_info = mlx4_en_ptp_clock_info;snprintf (mdev->ptp_clock_info.name,16 ,"mlx4 ptp" );
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h +0 -1
@@ -409,7 +409,6 @@ struct mlx4_en_dev {struct cyclecounter cycles;struct timecounter clock;unsigned long last_overflow_check; -unsigned long overflow_period;struct ptp_clock *ptp_clock;struct ptp_clock_info ptp_clock_info;struct notifier_block nb;
Greg Kroah-Hartman
maintainerPATCH 27/46 netfilter: nf_ct_expect: Change __nf_ct_expect_check() return value.
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jarno Rajahalme <[email protected]>
[ Upstream commit 4b86c459c7bee3acaf92f0e2b4c6ac803eaa1a58 ]
Commit 4dee62b1b9b4 ("netfilter: nf_ct_expect: nf_ct_expect_insert() returns void") inadvertently changed the successful return value of nf_ct_expect_related_report() from 0 to 1 due to __nf_ct_expect_check() returning 1 on success. Prevent this regression in the future by changing the return value of __nf_ct_expect_check() to 0 on success.
--- net/netfilter/nf_conntrack_expect.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/netfilter/nf_conntrack_expect.c +2 -2
@@ -395,7 +395,7 @@ static inline int __nf_ct_expect_check(sstruct net *net =nf_ct_exp_net (expect);struct hlist_node *next;unsigned int h; -int ret =1 ; +int ret =0 ;if (!master_help) { ret = -ESHUTDOWN ;
@@ -445,7 +445,7 @@ int nf_ct_expect_related_report(struct nspin_lock_bh (&nf_conntrack_expect_lock); ret =__nf_ct_expect_check (expect); -if (ret <=0 ) +if (ret <0 ) goto out; ret =nf_ct_expect_insert (expect);
Greg Kroah-Hartman
maintainerPATCH 28/46 iio: adc: xilinx: Fix error handling
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit ca1c39ef76376b67303d01f94fe98bb68bb3861a ]
Reorder error handling labels in order to match the way resources have been allocated.
--- drivers/iio/adc/xilinx-xadc-core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/iio/adc/xilinx-xadc-core.c +3 -3
@@ -1208,7 +1208,7 @@ static int xadc_probe(struct platform_de ret = xadc->ops->setup (pdev, indio_dev, irq);if (ret) - goto err_free_samplerate_trigger; + goto err_clk_disable_unprepare; ret =request_irq (irq, xadc->ops->interrupt_handler,0 ,dev_name (&pdev->dev), indio_dev);
@@ -1268,6 +1268,8 @@ static int xadc_probe(struct platform_de err_free_irq:free_irq (irq, indio_dev); +err_clk_disable_unprepare: +clk_disable_unprepare (xadc->clk); err_free_samplerate_trigger:if (xadc->ops->flags &XADC_FLAGS_BUFFERED )iio_trigger_free (xadc->samplerate_trigger);
@@ -1277,8 +1279,6 @@ err_free_convst_trigger: err_triggered_buffer_cleanup:if (xadc->ops->flags &XADC_FLAGS_BUFFERED )iio_triggered_buffer_cleanup (indio_dev); -err_clk_disable_unprepare: -clk_disable_unprepare (xadc->clk); err_device_free:kfree (indio_dev->channels);
Greg Kroah-Hartman
maintainerPATCH 29/46 Btrfs: send, fix failure to rename top level inode due to name collision
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robbie Ko <[email protected]>
[ Upstream commit 4dd9920d991745c4a16f53a8f615f706fbe4b3f7 ]
Under certain situations, an incremental send operation can fail due to a premature attempt to create a new top level inode (a direct child of the subvolume/snapshot root) whose name collides with another inode that was removed from the send snapshot.
Consider the following example scenario.
Parent snapshot:
. (ino 256, gen 8) |---- a1/ (ino 257, gen 9) |---- a2/ (ino 258, gen 9)
Send snapshot:
. (ino 256, gen 3)
|---- a2/ (ino 257, gen 7)
In this scenario, when receiving the incremental send stream, the btrfs receive command fails like this (ran in verbose mode, -vv argument):
rmdir a1
mkfile o257-7-0
rename o257-7-0 -> a2
ERROR: rename o257-7-0 -> a2 failed: Is a directory
What happens when computing the incremental send stream is:
1) An operation to remove the directory with inode number 257 and generation 9 is issued.
2) An operation to create the inode with number 257 and generation 7 is issued. This creates the inode with an orphanized name of "o257-7-0".
3) An operation rename the new inode 257 to its final name, "a2", is issued. This is incorrect because inode 258, which has the same name and it's a child of the same parent (root inode 256), was not yet processed and therefore no rmdir operation for it was yet issued. The rename operation is issued because we fail to detect that the name of the new inode 257 collides with inode 258, because their parent, a subvolume/snapshot root (inode 256) has a different generation in both snapshots.
So fix this by ignoring the generation value of a parent directory that matches a root inode (number 256) when we are checking if the name of the inode currently being processed collides with the name of some other inode that was not yet processed.
We can achieve this scenario of different inodes with the same number but different generation values either by mounting a filesystem with the inode cache option (-o inode_cache) or by creating and sending snapshots across different filesystems, like in the following example:
$ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ mkdir /mnt/a1 $ mkdir /mnt/a2 $ btrfs subvolume snapshot -r /mnt /mnt/snap1 $ btrfs send /mnt/snap1 -f /tmp/1.snap $ umount /mnt
$ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ touch /mnt/a2 $ btrfs subvolume snapshot -r /mnt /mnt/snap2 $ btrfs receive /mnt -f /tmp/1.snap # Take note that once the filesystem is created, its current # generation has value 7 so the inode from the second snapshot has # a generation value of 7. And after receiving the first snapshot # the filesystem is at a generation value of 10, because the call to # create the second snapshot bumps the generation to 8 (the snapshot # creation ioctl does a transaction commit), the receive command calls # the snapshot creation ioctl to create the first snapshot, which bumps # the filesystem's generation to 9, and finally when the receive # operation finishes it calls an ioctl to transition the first snapshot # (snap1) from RW mode to RO mode, which does another transaction commit # and bumps the filesystem's generation to 10. $ rm -f /tmp/1.snap $ btrfs send /mnt/snap1 -f /tmp/1.snap $ btrfs send -p /mnt/snap1 /mnt/snap2 -f /tmp/2.snap $ umount /mnt
$ mkfs.btrfs -f /dev/sdd $ mount /dev/sdd /mnt $ btrfs receive /mnt /tmp/1.snap # Receive of snapshot snap2 used to fail. $ btrfs receive /mnt /tmp/2.snap
--- fs/btrfs/send.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/btrfs/send.c +4 -1
@@ -1648,6 +1648,9 @@ static int is_inode_existent(struct send {int ret; +if (ino ==BTRFS_FIRST_FREE_OBJECTID ) +return 1 ; + ret =get_cur_inode_state (sctx, ino, gen);if (ret <0 ) goto out;
@@ -1833,7 +1836,7 @@ static int will_overwrite_ref(struct sen* not delted and then re-created, if it was then we have no overwrite * and we can just unlink this entry. */ -if (sctx->parent_root) { +if (sctx->parent_root && dir !=BTRFS_FIRST_FREE_OBJECTID ) { ret =get_inode_info (sctx->parent_root, dir,NULL , &gen,NULL ,NULL ,NULL ,NULL );if (ret <0 && ret != -ENOENT )
Greg Kroah-Hartman
maintainerPATCH 3/46 MIPS: Fix minimum alignment requirement of IRQ stack
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Redfearn <[email protected]>
commit 5fdc66e046206306bf61ff2d626bfa52ca087f7b upstream.
Commit db8466c581cc ("MIPS: IRQ Stack: Unwind IRQ stack onto task stack") erroneously set the initial stack pointer of the IRQ stack to a value with a 4 byte alignment. The MIPS32 ABI requires that the minimum stack alignment is 8 byte, and the MIPS64 ABIs(n32/n64) require 16 byte minimum alignment. Fix IRQ_STACK_START such that it leaves space for the dummy stack frame (containing interrupted task kernel stack pointer) while also meeting minimum alignment requirements.
Patchwork: https://patchwork.linux-mips.org/patch/16760/
--- arch/mips/include/asm/irq.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/include/asm/irq.h +1 -1
@@ -18,7 +18,7 @@#include <irq.h> #define IRQ_STACK_SIZE THREAD_SIZE -#define IRQ_STACK_START (IRQ_STACK_SIZE - sizeof(unsigned long)) +#define IRQ_STACK_START (IRQ_STACK_SIZE - 16)extern void *irq_stack[NR_CPUS ];
Greg Kroah-Hartman
maintainerPATCH 30/46 f2fs: do not wait for writeback in write_begin
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jaegeuk Kim <[email protected]>
[ Upstream commit 86d54795c94532075d862aa0a79f0c981dab4bdd ]
Otherwise we can get livelock like below.
[79880.428136] dbench D 0 18405 18404 0x00000000 [79880.428139] Call Trace: [79880.428142] __schedule+0x219/0x6b0 [79880.428144] schedule+0x36/0x80 [79880.428147] schedule_timeout+0x243/0x2e0 [79880.428152] ? update_sd_lb_stats+0x16b/0x5f0 [79880.428155] ? ktime_get+0x3c/0xb0 [79880.428157] io_schedule_timeout+0xa6/0x110 [79880.428161] __lock_page+0xf7/0x130 [79880.428164] ? unlock_page+0x30/0x30 [79880.428167] pagecache_get_page+0x16b/0x250 [79880.428171] grab_cache_page_write_begin+0x20/0x40 [79880.428182] f2fs_write_begin+0xa2/0xdb0 [f2fs] [79880.428192] ? f2fs_mark_inode_dirty_sync+0x16/0x30 [f2fs] [79880.428197] ? kmem_cache_free+0x79/0x200 [79880.428203] ? __mark_inode_dirty+0x17f/0x360 [79880.428206] generic_perform_write+0xbb/0x190 [79880.428213] ? file_update_time+0xa4/0xf0 [79880.428217] __generic_file_write_iter+0x19b/0x1e0 [79880.428226] f2fs_file_write_iter+0x9c/0x180 [f2fs] [79880.428231] __vfs_write+0xc5/0x140 [79880.428235] vfs_write+0xb2/0x1b0 [79880.428238] SyS_write+0x46/0xa0 [79880.428242] entry_SYSCALL_64_fastpath+0x1e/0xad
--- fs/f2fs/data.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
fs/f2fs/data.c +6 -1
@@ -1416,7 +1416,12 @@ static int f2fs_write_begin(struct file goto fail; } repeat: - page =grab_cache_page_write_begin (mapping, index, flags); +/* +* Do not use grab_cache_page_write_begin() to avoid deadlock due to +* wait_for_stable_page. Will wait that below with our IO control. +*/ + page =pagecache_get_page (mapping, index, +FGP_LOCK |FGP_WRITE |FGP_CREAT ,GFP_NOFS );if (!page) { err = -ENOMEM ; goto fail;
Greg Kroah-Hartman
maintainerPATCH 31/46 md/linear: shutup lockdep warnning
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shaohua Li <[email protected]>
[ Upstream commit d939cdfde34f50b95254b375f498447c82190b3e ]
Commit 03a9e24(md linear: fix a race between linear_add() and linear_congested()) introduces the warnning.
--- drivers/md/linear.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/md/linear.c +2 -1
@@ -223,7 +223,8 @@ static int linear_add(struct mddev *mdde* oldconf until no one uses it anymore. */ mddev_suspend (mddev); - oldconf =rcu_dereference (mddev->private); + oldconf =rcu_dereference_protected (mddev->private, +lockdep_is_held (&mddev->reconfig_mutex)); mddev->raid_disks++;WARN_ONCE (mddev->raid_disks != newconf->raid_disks,"copied raid_disks doesn't match mddev->raid_disks" );
Greg Kroah-Hartman
maintainerPATCH 32/46 sparc64: Migrate hvcons irq to panicked cpu
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vijay Kumar <[email protected]>
[ Upstream commit 7dd4fcf5b70694dc961eb6b954673e4fc9730dbd ]
On panic, all other CPUs are stopped except the one which had hit panic. To keep console alive, we need to migrate hvcons irq to panicked CPU.
--- arch/sparc/include/asm/setup.h | 5 ++++- arch/sparc/kernel/smp_64.c | 6 +++++- drivers/tty/serial/sunhv.c | 6 ++++++ 3 files changed, 15 insertions(+), 2 deletions(-)
arch/sparc/include/asm/setup.h +4 -1
@@ -59,8 +59,11 @@ extern atomic_t dcpage_flushes;extern atomic_t dcpage_flushes_xcall;extern int sysctl_tsb_ratio; -#endif +#ifdef CONFIG_SERIAL_SUNHV +void sunhv_migrate_hvcons_irq (int cpu); +#endif +#endif void sun_do_break (void );extern int stop_a_enabled;extern int scons_pwroff;
arch/sparc/kernel/smp_64.c +5 -1
@@ -1443,8 +1443,12 @@ void smp_send_stop(void)int cpu;if (tlb_type == hypervisor) { +int this_cpu =smp_processor_id (); +#ifdef CONFIG_SERIAL_SUNHV +sunhv_migrate_hvcons_irq (this_cpu); +#endif for_each_online_cpu (cpu) { -if (cpu ==smp_processor_id ()) +if (cpu == this_cpu)continue ;#ifdef CONFIG_SUN_LDOMS if (ldom_domaining_enabled) {
drivers/tty/serial/sunhv.c +6 -0
@@ -398,6 +398,12 @@ static struct uart_driver sunhv_reg = {static struct uart_port *sunhv_port; +void sunhv_migrate_hvcons_irq (int cpu) +{ +/* Migrate hvcons irq to param cpu */ +irq_force_affinity (sunhv_port->irq,cpumask_of (cpu)); +} +/* Copy 's' into the con_write_page, decoding "\n" into * "\r\n" along the way. We have to return two lengths * because the caller needs to know how much to advance
Greg Kroah-Hartman
maintainerPATCH 33/46 net/mlx4_core: Fix VF overwrite of module param which disables DMFS on new probed PFs
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Majd Dibbiny <[email protected]>
[ Upstream commit 95f1ba9a24af9769f6e20dfe9a77c863f253f311 ]
In the VF driver, module parameter mlx4_log_num_mgm_entry_size was mistakenly overwritten -- and in a manner which overrode the device-managed flow steering option encoded in the parameter.
log_num_mgm_entry_size is a global module parameter which affects all ConnectX-3 PFs installed on that host.
If a VF changes log_num_mgm_entry_size, this will affect all PFs which are probed subsequent to the change (by disabling DMFS for those PFs).
--- drivers/net/ethernet/mellanox/mlx4/main.c | 2 -- 1 file changed, 2 deletions(-)
drivers/net/ethernet/mellanox/mlx4/main.c +0 -2
@@ -791,8 +791,6 @@ static int mlx4_slave_cap(struct mlx4_dereturn -ENOSYS ; } - mlx4_log_num_mgm_entry_size = hca_param.log_mc_entry_sz; - dev->caps.hca_core_clock = hca_param.hca_core_clock;memset (&dev_cap,0 ,sizeof (dev_cap));
Greg Kroah-Hartman
maintainerPATCH 4/46 sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit fa5f7b51fc3080c2b195fa87c7eca7c05e56f673 ]
This code causes a static checker warning because Smatch doesn't trust anything that comes from skb->data. I've reviewed this code and I do think skb->data can be controlled by the user here.
The sctp_event_subscribe struct has 13 __u8 fields and we want to see if ours is non-zero. sn_type can be any value in the 0-USHRT_MAX range. We're subtracting SCTP_SN_TYPE_BASE which is 1 << 15 so we could read either before the start of the struct or after the end.
This is a very old bug and it's surprising that it would go undetected for so long but my theory is that it just doesn't have a big impact so it would be hard to notice.
--- include/net/sctp/ulpevent.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
include/net/sctp/ulpevent.h +5 -1
@@ -141,8 +141,12 @@ __u16 sctp_ulpevent_get_notification_typstatic inline int sctp_ulpevent_type_enabled (__u16 sn_type,struct sctp_event_subscribe *mask) { +int offset = sn_type -SCTP_SN_TYPE_BASE ;char *amask = (char *) mask; -return amask[sn_type -SCTP_SN_TYPE_BASE ]; + +if (offset >=sizeof (struct sctp_event_subscribe )) +return 0 ; +return amask[offset]; }/* Given an event subscription, is this event enabled? */
Greg Kroah-Hartman
maintainerPATCH 34/46 crypto: xts - Add ECB dependency
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Milan Broz <[email protected]>
[ Upstream commit 12cb3a1c4184f891d965d1f39f8cfcc9ef617647 ]
Since the
commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
crypto: xts - Convert to skcipher
the XTS mode is based on ECB, so the mode must select ECB otherwise it can fail to initialize.
--- crypto/Kconfig | 1 + 1 file changed, 1 insertion(+)
crypto/Kconfig +1 -0
@@ -343,6 +343,7 @@ config CRYPTO_XTS select CRYPTO_BLKCIPHER select CRYPTO_MANAGER select CRYPTO_GF128MUL + select CRYPTO_ECB help XTS: IEEE1619/D16 narrow block cipher use with aes-xts-plain, key size 256, 384 or 512 bits. This implementation currently
Greg Kroah-Hartman
maintainerPATCH 5/46 bpf/verifier: reject BPF_ALU64|BPF_END
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Edward Cree <[email protected]>
[ Upstream commit e67b8a685c7c984e834e3181ef4619cd7025a136 ]
Neither ___bpf_prog_run nor the JITs accept it. Also adds a new test case.
--- kernel/bpf/verifier.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/bpf/verifier.c +2 -1
@@ -1033,7 +1033,8 @@ static int check_alu_op(struct verifier_ } }else {if (insn->src_reg !=BPF_REG_0 || insn->off !=0 || - (insn->imm !=16 && insn->imm !=32 && insn->imm !=64 )) { + (insn->imm !=16 && insn->imm !=32 && insn->imm !=64 ) || +BPF_CLASS (insn->code) ==BPF_ALU64 ) {verbose ("BPF_END uses reserved fields\n" );return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 6/46 udpv6: Fix the checksum computation when HW checksum does not apply
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Subash Abhinov Kasiviswanathan <[email protected]>
[ Upstream commit 63ecc3d9436f8012e49dc846d6cb0a85a3433517 ]
While trying an ESP transport mode encryption for UDPv6 packets of datagram size 1436 with MTU 1500, checksum error was observed in the secondary fragment.
This error occurs due to the UDP payload checksum being missed out when computing the full checksum for these packets in udp6_hwcsum_outgoing().
--- net/ipv6/udp.c | 1 + 1 file changed, 1 insertion(+)
net/ipv6/udp.c +1 -0
@@ -1007,6 +1007,7 @@ static void udp6_hwcsum_outgoing(struct*/ offset =skb_transport_offset (skb); skb->csum =skb_checksum (skb, offset, skb->len - offset,0 ); + csum = skb->csum; skb->ip_summed =CHECKSUM_NONE ;
Greg Kroah-Hartman
maintainerPATCH 35/46 ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Ren <[email protected]>
[ Upstream commit 439a36b8ef38657f765b80b775e2885338d72451 ]
We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already.
Mostly, we can avoid recursive locking by writing code carefully. However, we found that it's very hard to handle the routines that are invoked directly by vfs code. For instance:
const struct inode_operations ocfs2_file_iops = {
.permission = ocfs2_permission,
.get_acl = ocfs2_iop_get_acl,
.set_acl = ocfs2_iop_set_acl,
};Both ocfs2_permission() and ocfs2_iop_get_acl() call ocfs2_inode_lock(PR):
do_sys_open
may_open
inode_permission
ocfs2_permission
ocfs2_inode_lock() <=== first time
generic_permission
get_acl
ocfs2_iop_get_acl ocfs2_inode_lock() <=== recursive one
A deadlock will occur if a remote EX request comes in between two of ocfs2_inode_lock(). Briefly describe how the deadlock is formed:
On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in BAST(ocfs2_generic_handle_bast) when downconvert is started on behalf of the remote EX lock request. Another hand, the recursive cluster lock (the second one) will be blocked in in __ocfs2_cluster_lock() because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, why? because there is no chance for the first cluster lock on this node to be unlocked - we block ourselves in the code path.
The idea to fix this issue is mostly taken from gfs2 code.
1. introduce a new field: struct ocfs2_lock_res.l_holders, to keep track of the processes' pid who has taken the cluster lock of this lock resource;
2. introduce a new flag for ocfs2_inode_lock_full:
OCFS2_META_LOCK_GETBH; it means just getting back disk inode bh for us if we've got cluster lock.
3. export a helper: ocfs2_is_locked_by_me() is used to check if we have got the cluster lock in the upper code path.
The tracking logic should be used by some of the ocfs2 vfs's callbacks, to solve the recursive locking issue cuased by the fact that vfs routines can call into each other.
The performance penalty of processing the holder list should only be seen at a few cases where the tracking logic is used, such as get/set acl.
You may ask what if the first time we got a PR lock, and the second time we want a EX lock? fortunately, this case never happens in the real world, as far as I can see, including permission check, (get|set)_(acl|attr), and the gfs2 code also do so.
--- fs/ocfs2/dlmglue.c | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++-- fs/ocfs2/dlmglue.h | 18 +++++++++ fs/ocfs2/ocfs2.h | 1 3 files changed, 121 insertions(+), 3 deletions(-)
fs/ocfs2/dlmglue.c +102 -3
@@ -531,6 +531,7 @@ void ocfs2_lock_res_init_once(struct ocfinit_waitqueue_head (&res->l_event);INIT_LIST_HEAD (&res->l_blocked_list);INIT_LIST_HEAD (&res->l_mask_waiters); +INIT_LIST_HEAD (&res->l_holders); } void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,
@@ -748,6 +749,50 @@ void ocfs2_lock_res_free(struct ocfs2_lo res->l_flags =0UL ; } +/* +* Keep a list of processes who have interest in a lockres. +* Note: this is now only uesed for check recursive cluster locking. +*/ +static inline void ocfs2_add_holder (struct ocfs2_lock_res *lockres, +struct ocfs2_lock_holder *oh) +{ +INIT_LIST_HEAD (&oh->oh_list); + oh->oh_owner_pid =get_pid (task_pid (current)); + +spin_lock (&lockres->l_lock); +list_add_tail (&oh->oh_list, &lockres->l_holders); +spin_unlock (&lockres->l_lock); +} + +static inline void ocfs2_remove_holder (struct ocfs2_lock_res *lockres, +struct ocfs2_lock_holder *oh) +{ +spin_lock (&lockres->l_lock); +list_del (&oh->oh_list); +spin_unlock (&lockres->l_lock); + +put_pid (oh->oh_owner_pid); +} + +static inline int ocfs2_is_locked_by_me (struct ocfs2_lock_res *lockres) +{ +struct ocfs2_lock_holder *oh; +struct pid *pid; + +/* look in the list of holders for one with the current task as owner */ +spin_lock (&lockres->l_lock); + pid =task_pid (current); +list_for_each_entry (oh, &lockres->l_holders, oh_list) { +if (oh->oh_owner_pid == pid) { +spin_unlock (&lockres->l_lock); +return 1 ; + } + } +spin_unlock (&lockres->l_lock); + +return 0 ; +} +static inline void ocfs2_inc_holders (struct ocfs2_lock_res *lockres,int level) {
@@ -2343,8 +2388,9 @@ int ocfs2_inode_lock_full_nested(struct goto getbh; } -if (ocfs2_mount_local (osb)) - goto local; +if ((arg_flags &OCFS2_META_LOCK_GETBH ) || +ocfs2_mount_local (osb)) + goto update;if (!(arg_flags &OCFS2_META_LOCK_RECOVERY ))ocfs2_wait_for_recovery (osb);
@@ -2373,7 +2419,7 @@ int ocfs2_inode_lock_full_nested(structif (!(arg_flags &OCFS2_META_LOCK_RECOVERY ))ocfs2_wait_for_recovery (osb); -local: +update:/* * We only see this flag if we're being called from * ocfs2_read_locked_inode(). It means we're locking an inode
@@ -2515,6 +2561,59 @@ void ocfs2_inode_unlock(struct inode *inocfs2_cluster_unlock (OCFS2_SB (inode->i_sb), lockres, level); } +/* +* This _tracker variantes are introduced to deal with the recursive cluster +* locking issue. The idea is to keep track of a lock holder on the stack of +* the current process. If there's a lock holder on the stack, we know the +* task context is already protected by cluster locking. Currently, they're +* used in some VFS entry routines. +* +* return < 0 on error, return == 0 if there's no lock holder on the stack +* before this call, return == 1 if this call would be a recursive locking. +*/ +int ocfs2_inode_lock_tracker (struct inode *inode, +struct buffer_head **ret_bh, +int ex, +struct ocfs2_lock_holder *oh) +{ +int status; +int arg_flags =0 , has_locked; +struct ocfs2_lock_res *lockres; + + lockres = &OCFS2_I (inode)->ip_inode_lockres; + has_locked =ocfs2_is_locked_by_me (lockres); +/* Just get buffer head if the cluster lock has been taken */ +if (has_locked) + arg_flags =OCFS2_META_LOCK_GETBH ; + +if (likely (!has_locked || ret_bh)) { + status =ocfs2_inode_lock_full (inode, ret_bh, ex, arg_flags); +if (status <0 ) { +if (status != -ENOENT ) +mlog_errno (status); +return status; + } + } +if (!has_locked) +ocfs2_add_holder (lockres, oh); + +return has_locked; +} + +void ocfs2_inode_unlock_tracker (struct inode *inode, +int ex, +struct ocfs2_lock_holder *oh, +int had_lock) +{ +struct ocfs2_lock_res *lockres; + + lockres = &OCFS2_I (inode)->ip_inode_lockres; +if (!had_lock) { +ocfs2_remove_holder (lockres, oh); +ocfs2_inode_unlock (inode, ex); + } +} +int ocfs2_orphan_scan_lock (struct ocfs2_super *osb,u32 *seqno) {struct ocfs2_lock_res *lockres;
fs/ocfs2/dlmglue.h +18 -0
@@ -70,6 +70,11 @@ struct ocfs2_orphan_scan_lvb {__be32 lvb_os_seqno; }; +struct ocfs2_lock_holder { +struct list_head oh_list; +struct pid *oh_owner_pid; +}; +/* ocfs2_inode_lock_full() 'arg_flags' flags */ /* don't wait on recovery. */ #define OCFS2_META_LOCK_RECOVERY (0x01)
@@ -77,6 +82,8 @@ struct ocfs2_orphan_scan_lvb {#define OCFS2_META_LOCK_NOQUEUE (0x02)/* don't block waiting for the downconvert thread, instead return -EAGAIN */ #define OCFS2_LOCK_NONBLOCK (0x04) +/* just get back disk inode bh if we've got cluster lock. */ +#define OCFS2_META_LOCK_GETBH (0x08)/* Locking subclasses of inode cluster lock */ enum {
@@ -170,4 +177,15 @@ void ocfs2_put_dlm_debug(struct ocfs2_dl/* To set the locking protocol on module initialization */ void ocfs2_set_locking_protocol (void ); + +/* The _tracker pair is used to avoid cluster recursive locking */ +int ocfs2_inode_lock_tracker (struct inode *inode, +struct buffer_head **ret_bh, +int ex, +struct ocfs2_lock_holder *oh); +void ocfs2_inode_unlock_tracker (struct inode *inode, +int ex, +struct ocfs2_lock_holder *oh, +int had_lock); +#endif /* DLMGLUE_H */
fs/ocfs2/ocfs2.h +1 -0
@@ -172,6 +172,7 @@ struct ocfs2_lock_res {struct list_head l_blocked_list;struct list_head l_mask_waiters; +struct list_head l_holders;unsigned long l_flags;char l_name[OCFS2_LOCK_ID_MAX_LEN ];
Greg Kroah-Hartman
maintainerPATCH 7/46 ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ Upstream commit 76cc0d3282d4b933fa144fa41fbc5318e0fdca24 ]
Now in ip6gre_header before packing the ipv6 header, it skb_push t->hlen which only includes encap_hlen + tun_hlen. It means greh and inner header would be over written by ipv6 stuff and ipv6h might have no chance to set up.
Jianlin found this issue when using remote any on ip6_gre, the packets he captured on gre dev are truncated:
22:50:26.210866 Out ethertype IPv6 (0x86dd), length 120: truncated-ip6 -\
8128 bytes missing!(flowlabel 0x92f40, hlim 0, next-header Options (0) \
payload length: 8192) ::1:2000:0 > ::1:0:86dd: HBH [trunc] ip-proto-128 \
8184
It should also skb_push ipv6hdr so that ipv6h points to the right position to set ipv6 stuff up.
This patch is to skb_push hlen + sizeof(*ipv6h) and also fix some indents in ip6gre_header.
--- net/ipv6/ip6_gre.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)
net/ipv6/ip6_gre.c +11 -10
@@ -1173,24 +1173,25 @@ static int ip6gre_tunnel_change_mtu(stru }static int ip6gre_header (struct sk_buff *skb,struct net_device *dev, -unsigned short type, -const void *daddr,const void *saddr,unsigned int len) +unsigned short type,const void *daddr, +const void *saddr,unsigned int len) {struct ip6_tnl *t =netdev_priv (dev); -struct ipv6hdr *ipv6h = (struct ipv6hdr *)skb_push (skb, t->hlen); -__be16 *p = (__be16 *)(ipv6h+1 ); +struct ipv6hdr *ipv6h; +__be16 *p; -ip6_flow_hdr (ipv6h,0 , -ip6_make_flowlabel (dev_net (dev), skb, - t->fl.u.ip6.flowlabel, true, - &t->fl.u.ip6)); + ipv6h = (struct ipv6hdr *)skb_push (skb, t->hlen +sizeof (*ipv6h)); +ip6_flow_hdr (ipv6h,0 ,ip6_make_flowlabel (dev_net (dev), skb, + t->fl.u.ip6.flowlabel, + true, &t->fl.u.ip6)); ipv6h->hop_limit = t->parms.hop_limit; ipv6h->nexthdr =NEXTHDR_GRE ; ipv6h->saddr = t->parms.laddr; ipv6h->daddr = t->parms.raddr; - p[0 ] = t->parms.o_flags; - p[1 ] =htons (type); + p = (__be16 *)(ipv6h +1 ); + p[0 ] = t->parms.o_flags; + p[1 ] =htons (type);/* * Set the source hardware address.
Greg Kroah-Hartman
maintainerPATCH 8/46 net: emac: Fix napi poll list corruption
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Lamparter <[email protected]>
[ Upstream commit f55956065ec94e3e9371463d693a1029c4cc3007 ]
This patch is pretty much a carbon copy of
commit 3079c652141f ("caif: Fix napi poll list corruption") with "caif" replaced by "emac".
The commit d75b1ade567f ("net: less interrupt masking in NAPI") breaks emac.
It is now required that if the entire budget is consumed when poll returns, the napi poll_list must remain empty. However, like some other drivers emac tries to do a last-ditch check and if there is more work it will call napi_reschedule and then immediately process some of this new work. Should the entire budget be consumed while processing such new work then we will violate the new caller contract.
This patch fixes this by not touching any work when we reschedule in emac.
--- drivers/net/ethernet/ibm/emac/mal.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/ethernet/ibm/emac/mal.c +1 -2
@@ -402,7 +402,7 @@ static int mal_poll(struct napi_struct *unsigned long flags;MAL_DBG2 (mal,"poll(%d)" NL , budget); - again: +/* Process TX skbs */ list_for_each (l, &mal->poll_list) { struct mal_commac *mc =
@@ -451,7 +451,6 @@ static int mal_poll(struct napi_struct *spin_lock_irqsave (&mal->lock, flags);mal_disable_eob_irq (mal);spin_unlock_irqrestore (&mal->lock, flags); - goto again; } mc->ops->poll_tx (mc->dev); }
Greg Kroah-Hartman
maintainerPATCH 9/46 packet: hold bind lock when rebinding to fanout hook
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Willem de Bruijn <[email protected]>
[ Upstream commit 008ba2a13f2d04c947adc536d19debb8fe66f110 ]
Packet socket bind operations must hold the po->bind_lock. This keeps po->running consistent with whether the socket is actually on a ptype list to receive packets.
fanout_add unbinds a socket and its packet_rcv/tpacket_rcv call, then binds the fanout object to receive through packet_rcv_fanout.
Make it hold the po->bind_lock when testing po->running and rebinding. Else, it can race with other rebind operations, such as that in packet_set_ring from packet_rcv to tpacket_rcv. Concurrent updates can result in a socket being added to a fanout group twice, causing use-after-free KASAN bug reports, among others.
Reported independently by both trinity and syzkaller. Verified that the syzkaller reproducer passes after this patch.
--- net/packet/af_packet.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
net/packet/af_packet.c +11 -5
@@ -1652,10 +1652,6 @@ static int fanout_add(struct sock *sk, umutex_lock (&fanout_mutex); - err = -EINVAL ; -if (!po->running) - goto out; - err = -EALREADY ;if (po->fanout) goto out;
@@ -1704,7 +1700,10 @@ static int fanout_add(struct sock *sk, ulist_add (&match->list, &fanout_list); } err = -EINVAL ; -if (match->type == type && + +spin_lock (&po->bind_lock); +if (po->running && + match->type == type && match->prot_hook.type == po->prot_hook.type && match->prot_hook.dev == po->prot_hook.dev) { err = -ENOSPC ;
@@ -1716,6 +1715,13 @@ static int fanout_add(struct sock *sk, u err =0 ; } } +spin_unlock (&po->bind_lock); + +if (err && !refcount_read (&match->sk_ref)) { +list_del (&match->list); +kfree (match); + } + out:if (err && rollover) {kfree (rollover);
Greg Kroah-Hartman
maintainerPATCH 37/46 scsi: scsi_dh_emc: return success in clariion_std_inquiry()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 4d7d39a18b8b81511f0b893b7d2203790bf8a58b ]
We accidentally return an uninitialized variable on success.
--- drivers/scsi/device_handler/scsi_dh_emc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/device_handler/scsi_dh_emc.c +1 -1
@@ -456,7 +456,7 @@ static int clariion_prep_fn(struct scsi_static int clariion_std_inquiry (struct scsi_device *sdev,struct clariion_dh_data *csdev) { -int err; +int err =SCSI_DH_OK ;char *sp_model; err =send_inquiry_cmd (sdev,0 , csdev);
Greg Kroah-Hartman
maintainerPATCH 38/46 net: mvpp2: release reference to txq_cpu[] entry after unmapping
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Petazzoni <[email protected]>
[ Upstream commit 36fb7435b6ac4d288a2d4deea8934f9456ab46b6 ]
The mvpp2_txq_bufs_free() function is called upon TX completion to DMA unmap TX buffers, and free the corresponding SKBs. It gets the references to the SKB to free and the DMA buffer to unmap from a per-CPU txq_pcpu data structure.
However, the code currently increments the pointer to the next entry before doing the DMA unmap and freeing the SKB. It does not cause any visible problem because for a given SKB the TX completion is guaranteed to take place on the CPU where the TX was started. However, it is much more logical to increment the pointer to the next entry once the current entry has been completely unmapped/released.
--- drivers/net/ethernet/marvell/mvpp2.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/net/ethernet/marvell/mvpp2.c +4 -5
@@ -4415,13 +4415,12 @@ static void mvpp2_txq_bufs_free(struct mstruct mvpp2_txq_pcpu_buf *tx_buf = txq_pcpu->buffs + txq_pcpu->txq_get_index; -mvpp2_txq_inc_get (txq_pcpu); -dma_unmap_single (port->dev->dev.parent, tx_buf->phys, tx_buf->size,DMA_TO_DEVICE ); -if (!tx_buf->skb) -continue ; -dev_kfree_skb_any (tx_buf->skb); +if (tx_buf->skb) +dev_kfree_skb_any (tx_buf->skb); + +mvpp2_txq_inc_get (txq_pcpu); } }
Greg Kroah-Hartman
maintainerPATCH 39/46 i2c: at91: ensure state is restored after suspending
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Belloni <[email protected]>
[ Upstream commit e3ccc921b7d8fd1fcd10a00720e09823d8078666 ]
When going to suspend, the I2C registers may be lost because the power to VDDcore is cut. Restore them when resuming.
--- drivers/i2c/busses/i2c-at91.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/i2c/busses/i2c-at91.c +3 -0
@@ -1131,6 +1131,7 @@ static int at91_twi_suspend_noirq(structstatic int at91_twi_resume_noirq (struct device *dev) { +struct at91_twi_dev *twi_dev =dev_get_drvdata (dev);int ret;if (!pm_runtime_status_suspended (dev)) {
@@ -1142,6 +1143,8 @@ static int at91_twi_resume_noirq(structpm_runtime_mark_last_busy (dev);pm_request_autosuspend (dev); +at91_init_twi_bus (twi_dev); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 40/46 ceph: clean up unsafe d_parent accesses in build_dentry_path
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <[email protected]>
[ Upstream commit c6b0b656ca24ede6657abb4a2cd910fa9c1879ba ]
While we hold a reference to the dentry when build_dentry_path is called, we could end up racing with a rename that changes d_parent. Handle that situation correctly, by using the rcu_read_lock to ensure that the parent dentry and inode stick around long enough to safely check ceph_snap and ceph_ino.
--- fs/ceph/mds_client.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
fs/ceph/mds_client.c +7 -2
@@ -1845,13 +1845,18 @@ static int build_dentry_path(struct dent int *pfreepath) {char *path; +struct inode *dir; -if (ceph_snap (d_inode (dentry->d_parent)) ==CEPH_NOSNAP ) { - *pino =ceph_ino (d_inode (dentry->d_parent)); +rcu_read_lock (); + dir =d_inode_rcu (dentry->d_parent); +if (dir &&ceph_snap (dir) ==CEPH_NOSNAP ) { + *pino =ceph_ino (dir); +rcu_read_unlock (); *ppath = dentry->d_name.name; *ppathlen = dentry->d_name.len;return 0 ; } +rcu_read_unlock (); path =ceph_mdsc_build_path (dentry, ppathlen, pino,1 );if (IS_ERR (path))return PTR_ERR (path);
Greg Kroah-Hartman
maintainerPATCH 41/46 uapi: fix linux/rds.h userspace compilation errors
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Dmitry V. Levin" <[email protected]>
[ Upstream commit feb0869d90e51ce8b6fd8a46588465b1b5a26d09 ]
Consistently use types from linux/types.h to fix the following linux/rds.h userspace compilation errors:
/usr/include/linux/rds.h:106:2: error: unknown type name 'uint8_t'
uint8_t name[32];/usr/include/linux/rds.h:107:2: error: unknown type name 'uint64_t'
uint64_t value;/usr/include/linux/rds.h:117:2: error: unknown type name 'uint64_t'
uint64_t next_tx_seq;/usr/include/linux/rds.h:118:2: error: unknown type name 'uint64_t'
uint64_t next_rx_seq;/usr/include/linux/rds.h:121:2: error: unknown type name 'uint8_t'
uint8_t transport[TRANSNAMSIZ]; /* null term ascii *//usr/include/linux/rds.h:122:2: error: unknown type name 'uint8_t'
uint8_t flags;/usr/include/linux/rds.h:129:2: error: unknown type name 'uint64_t'
uint64_t seq;/usr/include/linux/rds.h:130:2: error: unknown type name 'uint32_t'
uint32_t len;/usr/include/linux/rds.h:135:2: error: unknown type name 'uint8_t'
uint8_t flags;/usr/include/linux/rds.h:139:2: error: unknown type name 'uint32_t'
uint32_t sndbuf;/usr/include/linux/rds.h:144:2: error: unknown type name 'uint32_t'
uint32_t rcvbuf;/usr/include/linux/rds.h:145:2: error: unknown type name 'uint64_t'
uint64_t inum;/usr/include/linux/rds.h:153:2: error: unknown type name 'uint64_t'
uint64_t hdr_rem;/usr/include/linux/rds.h:154:2: error: unknown type name 'uint64_t'
uint64_t data_rem;/usr/include/linux/rds.h:155:2: error: unknown type name 'uint32_t'
uint32_t last_sent_nxt;/usr/include/linux/rds.h:156:2: error: unknown type name 'uint32_t'
uint32_t last_expected_una;/usr/include/linux/rds.h:157:2: error: unknown type name 'uint32_t'
uint32_t last_seen_una;/usr/include/linux/rds.h:164:2: error: unknown type name 'uint8_t'
uint8_t src_gid[RDS_IB_GID_LEN];/usr/include/linux/rds.h:165:2: error: unknown type name 'uint8_t'
uint8_t dst_gid[RDS_IB_GID_LEN];/usr/include/linux/rds.h:167:2: error: unknown type name 'uint32_t'
uint32_t max_send_wr;/usr/include/linux/rds.h:168:2: error: unknown type name 'uint32_t'
uint32_t max_recv_wr;/usr/include/linux/rds.h:169:2: error: unknown type name 'uint32_t'
uint32_t max_send_sge;/usr/include/linux/rds.h:170:2: error: unknown type name 'uint32_t'
uint32_t rdma_mr_max;/usr/include/linux/rds.h:171:2: error: unknown type name 'uint32_t'
uint32_t rdma_mr_size;/usr/include/linux/rds.h:212:9: error: unknown type name 'uint64_t'
typedef uint64_t rds_rdma_cookie_t;/usr/include/linux/rds.h:215:2: error: unknown type name 'uint64_t'
uint64_t addr;/usr/include/linux/rds.h:216:2: error: unknown type name 'uint64_t'
uint64_t bytes;/usr/include/linux/rds.h:221:2: error: unknown type name 'uint64_t'
uint64_t cookie_addr;/usr/include/linux/rds.h:222:2: error: unknown type name 'uint64_t'
uint64_t flags;/usr/include/linux/rds.h:228:2: error: unknown type name 'uint64_t'
uint64_t cookie_addr;/usr/include/linux/rds.h:229:2: error: unknown type name 'uint64_t'
uint64_t flags;/usr/include/linux/rds.h:234:2: error: unknown type name 'uint64_t'
uint64_t flags;/usr/include/linux/rds.h:240:2: error: unknown type name 'uint64_t'
uint64_t local_vec_addr;/usr/include/linux/rds.h:241:2: error: unknown type name 'uint64_t'
uint64_t nr_local;/usr/include/linux/rds.h:242:2: error: unknown type name 'uint64_t'
uint64_t flags;/usr/include/linux/rds.h:243:2: error: unknown type name 'uint64_t'
uint64_t user_token;/usr/include/linux/rds.h:248:2: error: unknown type name 'uint64_t'
uint64_t local_addr;/usr/include/linux/rds.h:249:2: error: unknown type name 'uint64_t'
uint64_t remote_addr;/usr/include/linux/rds.h:252:4: error: unknown type name 'uint64_t'
uint64_t compare;
/usr/include/linux/rds.h:253:4: error: unknown type name 'uint64_t'
uint64_t swap;
/usr/include/linux/rds.h:256:4: error: unknown type name 'uint64_t'
uint64_t add;
/usr/include/linux/rds.h:259:4: error: unknown type name 'uint64_t'
uint64_t compare;
/usr/include/linux/rds.h:260:4: error: unknown type name 'uint64_t'
uint64_t swap;
/usr/include/linux/rds.h:261:4: error: unknown type name 'uint64_t'
uint64_t compare_mask;
/usr/include/linux/rds.h:262:4: error: unknown type name 'uint64_t'
uint64_t swap_mask;
/usr/include/linux/rds.h:265:4: error: unknown type name 'uint64_t'
uint64_t add;
/usr/include/linux/rds.h:266:4: error: unknown type name 'uint64_t'
uint64_t nocarry_mask;/usr/include/linux/rds.h:269:2: error: unknown type name 'uint64_t'
uint64_t flags;/usr/include/linux/rds.h:270:2: error: unknown type name 'uint64_t'
uint64_t user_token;/usr/include/linux/rds.h:274:2: error: unknown type name 'uint64_t'
uint64_t user_token;/usr/include/linux/rds.h:275:2: error: unknown type name 'int32_t'
int32_t status;
--- include/uapi/linux/rds.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
include/uapi/linux/rds.h +2 -1
@@ -35,6 +35,7 @@#define _LINUX_RDS_H#include <linux/types.h> +#include <linux/socket.h> /* For __kernel_sockaddr_storage. */ #define RDS_IB_ABI_VERSION 0x301
@@ -223,7 +224,7 @@ struct rds_get_mr_args { };struct rds_get_mr_for_dest_args { -struct sockaddr_storage dest_addr; +struct __kernel_sockaddr_storage dest_addr;struct rds_iovec vec;uint64_t cookie_addr;uint64_t flags;
Greg Kroah-Hartman
maintainerPATCH 43/46 target/iscsi: Fix unsolicited data seq_end_offset calculation
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Varun Prakash <[email protected]>
[ Upstream commit 4d65491c269729a1e3b375c45e73213f49103d33 ]
In case of unsolicited data for the first sequence seq_end_offset must be set to minimum of total data length and FirstBurstLength, so do not add cmd->write_data_done to the min of total data length and FirstBurstLength.
This patch avoids that with ImmediateData=Yes, InitialR2T=No, MaxXmitDataSegmentLength < FirstBurstLength that a WRITE command with IO size above FirstBurstLength triggers sequence error messages, for example
Set following parameters on target (linux-4.8.12)
ImmediateData = Yes
InitialR2T = No
MaxXmitDataSegmentLength = 8k
FirstBurstLength = 64k
Log in from Open iSCSI initiator and execute
dd if=/dev/zero of=/dev/sdb bs=128k count=1 oflag=direct
Error messages on target
Command ITT: 0x00000035 with Offset: 65536, Length: 8192 outside of Sequence 73728:131072 while DataSequenceInOrder=Yes. Command ITT: 0x00000035, received DataSN: 0x00000001 higher than expected 0x00000000.
Unable to perform within-command recovery while ERL=0.
--- drivers/target/iscsi/iscsi_target_erl0.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/target/iscsi/iscsi_target_erl0.c +2 -4
@@ -44,10 +44,8 @@ void iscsit_set_dataout_sequence_values(*/ if (cmd->unsolicited_data) { cmd->seq_start_offset = cmd->write_data_done; - cmd->seq_end_offset = (cmd->write_data_done + - ((cmd->se_cmd.data_length > - conn->sess->sess_ops->FirstBurstLength) ? - conn->sess->sess_ops->FirstBurstLength : cmd->se_cmd.data_length)); + cmd->seq_end_offset =min (cmd->se_cmd.data_length, + conn->sess->sess_ops->FirstBurstLength);return ; }
Greg Kroah-Hartman
maintainerPATCH 44/46 nfsd/callback: Cleanup callback cred on shutdown
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kinglong Mee <[email protected]>
[ Upstream commit f7d1ddbe7648af7460d23688c8c131342eb43b3a ]
The rpccred gotten from rpc_lookup_machine_cred() should be put when state is shutdown.
--- fs/nfsd/nfs4callback.c | 8 ++++++++ fs/nfsd/nfs4state.c | 10 ++++++---- fs/nfsd/state.h | 1 + 3 files changed, 15 insertions(+), 4 deletions(-)
fs/nfsd/nfs4callback.c +8 -0
@@ -696,6 +696,14 @@ int set_callback_cred(void)return 0 ; } +void cleanup_callback_cred (void ) +{ +if (callback_cred) { +put_rpccred (callback_cred); + callback_cred =NULL ; + } +} +static struct rpc_cred *get_backchannel_cred (struct nfs4_client *clp,struct rpc_clnt *client,struct nfsd4_session *ses) {if (clp->cl_minorversion ==0 ) {
fs/nfsd/nfs4state.c +6 -4
@@ -6792,23 +6792,24 @@ nfs4_state_start(void) ret =set_callback_cred ();if (ret) -return -ENOMEM ; +return ret; + laundry_wq =alloc_workqueue ("%s" ,WQ_UNBOUND ,0 ,"nfsd4" );if (laundry_wq ==NULL ) { ret = -ENOMEM ; - goto out_recovery; + goto out_cleanup_cred; } ret =nfsd4_create_callback_queue ();if (ret) goto out_free_laundry;set_max_delegations (); -return 0 ; out_free_laundry:destroy_workqueue (laundry_wq); -out_recovery: +out_cleanup_cred: +cleanup_callback_cred ();return ret; }
@@ -6847,6 +6848,7 @@ nfs4_state_shutdown(void) {destroy_workqueue (laundry_wq);nfsd4_destroy_callback_queue (); +cleanup_callback_cred (); } static void
fs/nfsd/state.h +1 -0
@@ -595,6 +595,7 @@ extern struct nfs4_client_reclaim *nfsd4extern __be32 nfs4_check_open_reclaim (clientid_t *clid,struct nfsd4_compound_state *cstate,struct nfsd_net *nn);extern int set_callback_cred (void ); +extern void cleanup_callback_cred (void );extern void nfsd4_probe_callback (struct nfs4_client *clp);extern void nfsd4_probe_callback_sync (struct nfs4_client *clp);extern void nfsd4_change_callback (struct nfs4_client *clp,struct nfs4_cb_conn *);
Greg Kroah-Hartman
maintainerPATCH 45/46 cpufreq: CPPC: add ACPI_PROCESSOR dependency
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit a578884fa0d2768f13d37c6591a9e1ed600482d3 ]
Without the Kconfig dependency, we can get this warning:
warning: ACPI_CPPC_CPUFREQ selects ACPI_CPPC_LIB which has unmet direct dependencies (ACPI && ACPI_PROCESSOR)
--- drivers/cpufreq/Kconfig.arm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/cpufreq/Kconfig.arm +1 -1
@@ -241,7 +241,7 @@ config ARM_PXA2xx_CPUFREQ config ACPI_CPPC_CPUFREQ tristate "CPUFreq driver based on the ACPI CPPC spec" - depends on ACPI + depends on ACPI_PROCESSOR select ACPI_CPPC_LIB default n help
Greg Kroah-Hartman
maintainerPATCH 36/46 slub: do not merge cache if slub_debug contains a never-merge flag
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Grygorii Maistrenko <[email protected]>
[ Upstream commit c6e28895a4372992961888ffaadc9efc643b5bfe ]
In case CONFIG_SLUB_DEBUG_ON=n, find_mergeable() gets debug features from commandline but never checks if there are features from the SLAB_NEVER_MERGE set.
As a result selected by slub_debug caches are always mergeable if they have been created without a custom constructor set or without one of the SLAB_* debug features on.
This moves the SLAB_NEVER_MERGE check below the flags update from commandline to make sure it won't merge the slab cache if one of the debug features is on.
--- mm/slab_common.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
mm/slab_common.c +4 -1
@@ -250,7 +250,7 @@ struct kmem_cache *find_mergeable(size_t {struct kmem_cache *s; -if (slab_nomerge || (flags &SLAB_NEVER_MERGE )) +if (slab_nomerge)return NULL ;if (ctor)
@@ -261,6 +261,9 @@ struct kmem_cache *find_mergeable(size_t size =ALIGN (size, align); flags =kmem_cache_flags (size, flags, name,NULL ); +if (flags &SLAB_NEVER_MERGE ) +return NULL ; +list_for_each_entry_reverse (s, &slab_caches, list) {if (slab_unmergeable (s))continue ;
Greg Kroah-Hartman
maintainerPATCH 20/46 Revert "bsg-lib: dont free job in bsg_prepare_job"
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
This reverts commit 668cee82cd28d2c38a99f7cbddf3b3fd58f257b9 which was commit f507b54dccfd8000c517d740bc45f20c74532d18 upstream.
Ben reports:
That function doesn't exist here (it was introduced in 4.13). Instead, this backport has modified bsg_create_job(), creating a leak. Please revert this on the 3.18, 4.4 and 4.9 stable branches.
So I'm dropping it from here.
--- block/bsg-lib.c | 1 + 1 file changed, 1 insertion(+)
block/bsg-lib.c +1 -0
@@ -147,6 +147,7 @@ static int bsg_create_job(struct device failjob_rls_rqst_payload:kfree (job->request_payload.sg_list); failjob_rls_job: +kfree (job);return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 46/46 Revert "tty: goldfish: Fix a parameter of a call to free_irq"
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
This reverts commit 01b3db29ba1edd79b9c3e7cd294739b70257d278 which is commit 1a5c2d1de7d35f5eb9793266237903348989502b upstream.
Ben writes:
This fixes a bug introduced in 4.6 by commit 465893e18878 "tty:
goldfish: support platform_device with id -1". For earlier kernel versions, it *introduces* a bug.
So let's drop it.
--- drivers/tty/goldfish.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/goldfish.c +1 -1
@@ -293,7 +293,7 @@ static int goldfish_tty_probe(struct plareturn 0 ; err_tty_register_device_failed: -free_irq (irq, qtty); +free_irq (irq, pdev); err_request_irq_failed: goldfish_tty_current_line_count--;if (goldfish_tty_current_line_count ==0 )
Quoted 12 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.94 release. There are 46 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat Oct 21 13:48:23 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.94-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from the Linaro test farm. This report is in two parts. The second part and reported separately is the HiKey results since there are platform support patches added to the LTS to make it work.
Summary
------------------------------------------------------------------------
kernel: 4.4.94-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: cc1d76b2d639a37b3e6aec284b6838637d826f08
git describe: v4.4.93-47-gcc1d76b2d639
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.93-47-gcc1d76b2d639
Regressions (compared to build v4.4.92-29-g51c43ad676c4)
------------------------------------------------------------------------
x15 - arm:
kselftest:
* raw_skew
* test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz
ltp-syscalls-tests:
* fcntl36
* test src: git://github.com/linux-test-project/ltp.git
fcntl36 and raw_skew we’ll looking into.
ltp-timers-tests:
* leapsec_timer
* runltp_timers
* test src: git://github.com/linux-test-project/ltp.git
This one has been working and just failed with this RC cycle. It’s only failing on 32 bit arm.
Needs to be looked into.
Boards, architectures and test suites:
-------------------------------------
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 7, fail: 13 (known failures)
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 27, skip: 36, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 59, fail: 2 (known failures)
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 938, skip: 159, fail: 15 (known failures)
* ltp-timers-tests - pass: 13,
x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, skip: 1, fail: 21 (known failures)
* libhugetlbfs - skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 68, fail: 5 (noted above)
* ltp-timers-tests - pass: 11, fail: 2 (noted above)
dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 43, fail: 24
* libhugetlbfs - pass: 76, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 960, skip: 164, fail: 13 (known failures)
* ltp-timers-tests - pass: 13,
Summary
------------------------------------------------------------------------
kernel: 4.4.94-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.94-rc1-hikey-20171019
git commit: 64eacf43d6ff4c9320737af2fe207e5711010f1f
git describe: 4.4.94-rc1-hikey-20171019
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.94-rc1-hikey-20171019
No regressions (compared to build 4.4.93-rc1-hikey-20171016)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 9, fail: 13 (known failures)
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 27, skip: 36, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 59, fail: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 980, skip: 125, fail: 4 (known failures)
* ltp-timers-tests - pass: 13,
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Greg Kroah-Hartman
maintainerQuoted 55 lines · Tom Gall
Quoted 12 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.94 release. There are 46 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat Oct 21 13:48:23 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.94-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from the Linaro test farm. This report is in two parts. The second part and reported separately is the HiKey results since there are platform support patches added to the LTS to make it work.
Summary
------------------------------------------------------------------------kernel: 4.4.94-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:cc1d76b2d639a37b3e6aec284b6838637d826f08
git describe: v4.4.93-47-gcc1d76b2d639
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.93-47-gcc1d76b2d639Regressions (compared to build v4.4.92-29-g51c43ad676c4)
------------------------------------------------------------------------x15 - arm:
kselftest:
*raw_skew* test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz
ltp-syscalls-tests:
* fcntl36* test src:
git://github.com/linux-test-project/ltp.gitfcntl36 and
raw_skewwe’ll looking into.ltp-timers-tests:
*leapsec_timer
*runltp_timers
Quoted 5 lines
* test src:
git://github.com/linux-test-project/ltp.gitThis one has been working and just failed with this RC cycle. It’s only failing on 32 bit arm.
Needs to be looked into.
When you say "Needs to be looked into", does that mean that you are pointing this out for someone else to do this (i.e. help, someone look at this!), or are you going to be working to figure it out?
thanks,
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.94 release. There are 46 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat Oct 21 13:48:23 UTC 2017. Anything received after that time might be too late.
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 116 pass: 116 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
Quoted 58 lines · Greg Kroah-Hartman
Quoted 57 lines · Tom Gall
Quoted 12 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.94 release. There are 46 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat Oct 21 13:48:23 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.94-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from the Linaro test farm. This report is in two parts. The second part and reported separately is the HiKey results since there are platform support patches added to the LTS to make it work.
Summary
------------------------------------------------------------------------kernel: 4.4.94-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:cc1d76b2d639a37b3e6aec284b6838637d826f08
git describe: v4.4.93-47-gcc1d76b2d639
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.93-47-gcc1d76b2d639Regressions (compared to build v4.4.92-29-g51c43ad676c4)
------------------------------------------------------------------------x15 - arm:
kselftest:
*raw_skew* test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz
ltp-syscalls-tests:
* fcntl36* test src:
git://github.com/linux-test-project/ltp.gitfcntl36 and
raw_skewwe’ll looking into.ltp-timers-tests:
*leapsec_timer
*runltp_timers* test src:
git://github.com/linux-test-project/ltp.git
Quoted 7 lines
Quoted 3 lines
This one has been working and just failed with this RC cycle. It’s only failing on 32 bit arm.
Needs to be looked into.
When you say "Needs to be looked into", does that mean that you are pointing this out for someone else to do this (i.e. help, someone look at this!), or are you going to be working to figure it out?
Help is always great. We've got it covered.
One of the team that works on this board has been looking into it.
As of this second, and looking within the context of 4.4, 4.9 and mainline data what we're looking at is intermitted failures involving raw_skew from kselftest and leapsec_timer
from ltp_timers that is present across all those 3 kernel version and their respective streams.
(by stream I mean FOO, FOO-rc1, FOO+1, FOO+1-rc1, etc)
As such we can rule these out detecting a regression in the new RC patches. Likely it's board
specific.
For fcntl36 it's been intermittent only through the series of 4.4 kernels. At the moment we just
have one type of arm 32bit board, so we don't have a history here where we could refer to and say
fails occasionally on one board but not others. (We'll get there, Rome wasn't built in a day) At the
time I reported results I couldn't narrow between a board specific issue, an arch specific issue or
an issue that my have arose due to a bad patch in the RC.
Today however with fcntl36 produced failure for the very first time on mainline only on X15 which is
a 32 bit arm board.
That should rule out the bad patch scenario in the new RC series.
Having result history you can look back into across multiple versions and arches is awesome.
Doing all the comparisons, coming at the data from multiple directions and triple checking to
make sure data is pointing you to reasonable conclusions, that's the fun part.
Quoted 3 lines
thanks,
greg k-h
Signature · 9 lines
Regards, Tom Director, Linaro Mobile Group Linaro.org │ Open source software for ARM SoCs irc: tgall_foo | skype : tom_gall "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian
Greg Kroah-Hartman
maintainerQuoted 28 lines · Tom Gall
On Fri, Oct 20, 2017 at 1:26 AM, Greg Kroah-Hartman
Quoted 8 lines
Quoted 8 lines
fcntl36 and
raw_skewwe’ll looking into.ltp-timers-tests:
*leapsec_timer
*runltp_timers* test src:
git://github.com/linux-test-project/ltp.gitQuoted 7 lines
Quoted 3 lines
This one has been working and just failed with this RC cycle. It’s only failing on 32 bit arm.
Needs to be looked into.
When you say "Needs to be looked into", does that mean that you are pointing this out for someone else to do this (i.e. help, someone look at this!), or are you going to be working to figure it out?
Help is always great. We've got it covered.
One of the team that works on this board has been looking into it.
As of this second, and looking within the context of 4.4, 4.9 and mainline data what we're looking at is intermitted failures involving
raw_skewfrom kselftest andleapsec_timer
fromltp_timersthat is present across all those 3 kernel version and their respective streams.
(by stream I mean FOO, FOO-rc1, FOO+1, FOO+1-rc1, etc)
Quoted 3 lines
As such we can rule these out detecting a regression in the new RC patches. Likely it's board
specific.
Side note, your use of \n is still really odd. I strongly recommend getting a decent email client, or an sane editor that knows what to do here....
Anyway, if you have board-specific issues, that are not -rc issues, can you say so really obviously so I don't worry that I broke something? Otherwise it's pretty annoying, as your email implies that I did something wrong, and only a few emails in the thread later will it come out that this is flaky hardware/tests so there's nothing to worry about.
The kernel.ci reports are a bit like this, I glance at them and only worry if the reporter tells me to worry. Should I do the same thing here as well? When can these tests/reports start to be trusted?
thanks,
greg k-h
Quoted 32 lines · Greg Kroah-Hartman
Quoted 28 lines · Tom Gall
On Fri, Oct 20, 2017 at 1:26 AM, Greg Kroah-Hartman
Quoted 8 lines
Quoted 8 lines
fcntl36 and
raw_skewwe’ll looking into.ltp-timers-tests:
*leapsec_timer
*runltp_timers* test src:
git://github.com/linux-test-project/ltp.gitQuoted 7 lines
Quoted 3 lines
This one has been working and just failed with this RC cycle. It’s only failing on 32 bit arm.
Needs to be looked into.
When you say "Needs to be looked into", does that mean that you are pointing this out for someone else to do this (i.e. help, someone look at this!), or are you going to be working to figure it out?
Help is always great. We've got it covered.
One of the team that works on this board has been looking into it.
As of this second, and looking within the context of 4.4, 4.9 and mainline data what we're looking at is intermitted failures involving
raw_skewfrom kselftest andleapsec_timer
fromltp_timersthat is present across all those 3 kernel version and their respective streams.
(by stream I mean FOO, FOO-rc1, FOO+1, FOO+1-rc1, etc)
Quoted 7 lines
Quoted 3 lines
As such we can rule these out detecting a regression in the new RC patches. Likely it's board
specific.Side note, your use of \n is still really odd. I strongly recommend getting a decent email client, or an sane editor that knows what to do here….
That email client has been sacked.
Quoted 5 lines
Anyway, if you have board-specific issues, that are not -rc issues, can you say so really obviously so I don't worry that I broke something? Otherwise it's pretty annoying, as your email implies that I did something wrong, and only a few emails in the thread later will it come out that this is flaky hardware/tests so there's nothing to worry about.
Reports are pretty new & shiny yet so yes I’m over explaining the logic. To me, showing your work applies to other places besides math.
Quoted 3 lines
The kernel.ci reports are a bit like this, I glance at them and only worry if the reporter tells me to worry. Should I do the same thing here as well? When can these tests/reports start to be trusted?
Exactly and no surprise as number of those involved in all of this helped get kernelci off the ground.
Our aim is to have quick summaries either appended with the gory details or pointers to it for those that care.
For me the x86 and arm64 results are trustable. We’re working on getting 4.14-rc runs clean and then we’ll get after the ‘known errors with 4.4 and 4.9 as well.
32 bit arm results are a bit new/shiny yet. That’s where I’m most skeptical when something pops up.
Hope the perspective helps.
Quoted 3 lines
thanks,
greg k-h
Re: [PATCH 4.4 34/46] crypto: xts - Add ECB dependency
In reply to Greg Kroah-HartmanQuoted 5 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
Quoted 8 lines
From: Milan Broz <[email protected]>
[ Upstream commit
12cb3a1c4184f891d965d1f39f8cfcc9ef617647]Since the
commitf1c131b45410a202eb45cc55980a7a9e4e4b4f40
crypto: xts - Convert to skcipher
That commit went into 4.10, and not any stable branches. So this fix doesn't appear to be appropriate for the older branches it was applied to.
Ben.
Quoted 26 lines
the XTS mode is based on ECB, so the mode must select ECB otherwise it can fail to initialize.
Signed-off-by Milan Broz <[email protected]>Signed-off-by Herbert Xu <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
crypto/Kconfig | 1 +1 file changed, 1 insertion(+)crypto/Kconfig +0
-0@@ -343,6 +343,7 @@ config CRYPTO_XTSselect
CRYPTO_BLKCIPHER
selectCRYPTO_MANAGER
selectCRYPTO_GF128MULcrypto/Kconfig +1
-0+ select CRYPTO_ECBhelp
XTS: IEEE1619/D16 narrow block cipher use with aes-xts- plain,
key size 256, 384 or 512 bits. This implementation currently
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Re: [PATCH 4.4 41/46] uapi: fix linux/rds.h userspace compilation errors
In reply to Greg Kroah-HartmanQuoted 11 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Dmitry V. Levin" <[email protected]>
[ Upstream commit
feb0869d90e51ce8b6fd8a46588465b1b5a26d09]Consistently use types from
linux/types.hto fix the followinglinux/rds.huserspace compilation errors:
[...]
Quoted 16 lines
include/uapi/linux/rds.h +0
-0@@ -35,6 +35,7 @@ #define _LINUX_RDS_H
#include <linux/types.h>
+#include <linux/socket.h> /* For__kernel_sockaddr_storage. */
#defineRDS_IB_ABI_VERSION0x301include/uapi/linux/rds.h +0
-0@@ -223,7 +224,7 @@ struct rds_get_mr_args { };
structrds_get_mr_for_dest_args{include/uapi/linux/rds.h +1
-1-struct sockaddr_storage dest_addr; +struct __kernel_sockaddr_storage dest_addr;
Quoted 3 lines
struct rds_iovec vec;
uint64_tcookie_addr;
uint64_tflags;
This is a valid fix but not the one that the commit message and upstream commit hash refer to. This diff matches:
commit 1786dbf3702e33ce3afd2d3dbe630bd04b1d2e58
Author: Dmitry V. Levin <[email protected]>
Date: Thu Feb 16 18:05:45 2017 +0300
uapi: fix linux/rds.h userspace compilation error
which has almost the same subject line.
Maybe you should cherry-pick commit feb0869d90e51ce8b6fd8a46588465b1b5a26d09 for real as well (in all branches).
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Re: [PATCH 4.4 34/46] crypto: xts - Add ECB dependency
In reply to Ben HutchingsQuoted 11 lines · Ben Hutchings
Quoted 10 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Milan Broz <[email protected]>
[ Upstream commit
12cb3a1c4184f891d965d1f39f8cfcc9ef617647]
Quoted 7 lines
Quoted 3 lines
Since the
commitf1c131b45410a202eb45cc55980a7a9e4e4b4f40
crypto: xts - Convert to skcipherThat commit went into 4.10, and not any stable branches. So this fix doesn't appear to be appropriate for the older branches it was applied to.
I'll send a revert along with my next pull request. Thanks Ben!
Signature · 2 lines
Thanks, Sasha
Re: [PATCH 4.4 41/46] uapi: fix linux/rds.h userspace compilation errors
In reply to Ben HutchingsQuoted 40 lines · Ben Hutchings
Quoted 11 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Dmitry V. Levin" <[email protected]>
[ Upstream commit
feb0869d90e51ce8b6fd8a46588465b1b5a26d09]Consistently use types from
linux/types.hto fix the followinglinux/rds.huserspace compilation errors:[...]
Quoted 16 lines
include/uapi/linux/rds.h +0
-0@@ -35,6 +35,7 @@ #define _LINUX_RDS_H
#include <linux/types.h>
+#include <linux/socket.h> /* For__kernel_sockaddr_storage. */
#defineRDS_IB_ABI_VERSION0x301include/uapi/linux/rds.h +0
-0@@ -223,7 +224,7 @@ struct rds_get_mr_args { };
structrds_get_mr_for_dest_args{include/uapi/linux/rds.h +1
-1-struct sockaddr_storage dest_addr; +struct __kernel_sockaddr_storage dest_addr;Quoted 3 lines
struct rds_iovec vec;
uint64_tcookie_addr;
uint64_tflags;This is a valid fix but not the one that the commit message and upstream commit hash refer to. This diff matches:
commit
1786dbf3702e33ce3afd2d3dbe630bd04b1d2e58
Author: Dmitry V. Levin <[email protected]>
Date: Thu Feb 16 18:05:45 2017 +0300
Quoted 7 lines
uapi: fix
linux/rds.huserspace compilation errorwhich has almost the same subject line.
Maybe you should cherry-pick commit
feb0869d90e51ce8b6fd8a46588465b1b5a26d09for real as well (in all branches).
Uh, I'll get scripts + git trees fixed to deal with this issue. I'll send it along with my next pull request to Greg.
Thanks Ben!
Signature · 2 lines
Thanks, Sasha