Release XT925 KDA20.127 source Please. #18

venito · 2015-05-18T14:38:13Z

Here we go again...

Please release the source for Razr HD:

System version: 180.46.127.XT925.CEE-Retail.en.EU
Build number: KDA20.127
Kernel version: 3.4.42-ga566aff hudsoncm@ilclbld29 #1 Wed Oct 15 05.30:34 CDT 2014

Thanks.

venito · 2015-05-29T21:17:52Z

Finally is here.. https://github.com/MotorolaMobilityLLC/kernel-msm/tree/kitkat-4.4.2-release-vanquish

Thanks moto.

The cost of changing a cacheline from shared to exclusive state can be significant, especially when this is triggered by an exclusive store, since it may result in having to retry the transaction. This patch prefixes our atomic bitops implementation with prefetchw, to try and grab the line in exclusive state from the start. The testop macro is left alone, since the barrier semantics limit the usefulness of prefetching data. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> ARM: 7907/1: lib: delay-loop: Add align directive to fix BogoMIPS calculation Currently mx53 (CortexA8) running at 1GHz reports: Calibrating delay loop... 663.55 BogoMIPS (lpj=3317760) Tom Evans verified that alignments of 0x0 and 0x8 run the two instructions of __loop_delay in one clock cycle (1 clock/loop), while alignments of 0x4 and 0xc take 3 clocks to run the loop twice. (1.5 clock/loop) The original object code looks like this: 00000010 <__loop_const_udelay>: 10: e3e01000 mvn r1, #0 14: e51f201c ldr r2, [pc, #-28] ; 0 <__loop_udelay-0x8> 18: e5922000 ldr r2, [r2] 1c: e0800921 add r0, r0, r1, lsr MotorolaMobilityLLC#18 20: e1a00720 lsr r0, r0, MotorolaMobilityLLC#14 24: e0822b21 add r2, r2, r1, lsr MotorolaMobilityLLC#22 28: e1a02522 lsr r2, r2, MotorolaMobilityLLC#10 2c: e0000092 mul r0, r2, r0 30: e0800d21 add r0, r0, r1, lsr MotorolaMobilityLLC#26 34: e1b00320 lsrs r0, r0, MotorolaMobilityLLC#6 38: 01a0f00e moveq pc, lr 0000003c <__loop_delay>: 3c: e2500001 subs r0, r0, #1 40: 8afffffe bhi 3c <__loop_delay> 44: e1a0f00e mov pc, lr After adding the 'align 3' directive to __loop_delay (align to 8 bytes): 00000010 <__loop_const_udelay>: 10: e3e01000 mvn r1, #0 14: e51f201c ldr r2, [pc, #-28] ; 0 <__loop_udelay-0x8> 18: e5922000 ldr r2, [r2] 1c: e0800921 add r0, r0, r1, lsr MotorolaMobilityLLC#18 20: e1a00720 lsr r0, r0, MotorolaMobilityLLC#14 24: e0822b21 add r2, r2, r1, lsr MotorolaMobilityLLC#22 28: e1a02522 lsr r2, r2, MotorolaMobilityLLC#10 2c: e0000092 mul r0, r2, r0 30: e0800d21 add r0, r0, r1, lsr MotorolaMobilityLLC#26 34: e1b00320 lsrs r0, r0, MotorolaMobilityLLC#6 38: 01a0f00e moveq pc, lr 3c: e320f000 nop {0} 00000040 <__loop_delay>: 40: e2500001 subs r0, r0, #1 44: 8afffffe bhi 40 <__loop_delay> 48: e1a0f00e mov pc, lr 4c: e320f000 nop {0} , which now reports: Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736) Some more test results: On mx31 (ARM1136) running at 532 MHz, before the patch: Calibrating delay loop... 351.43 BogoMIPS (lpj=1757184) On mx31 (ARM1136) running at 532 MHz after the patch: Calibrating delay loop... 528.79 BogoMIPS (lpj=2643968) Also tested on mx6 (CortexA9) and on mx27 (ARM926), which shows the same BogoMIPS value before and after this patch. Reported-by: Tom Evans <tom_usenet@optusnet.com.au> Suggested-by: Tom Evans <tom_usenet@optusnet.com.au> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> ARM: 7404/1: cmpxchg64: use atomic64 and local64 routines for cmpxchg64 The cmpxchg64 routines for ARMv6+ CPUs replicate inline assembly that already exists for atomic64 operations. Furthermore, the cmpxchg64 code uses the "memory" constraint in the clobber list rather than identifying the region of memory that is actually modified. This patch replaces the ARMv6+ cmpxchg64 code with macros that expand to the atomic64_ and local64_ variants, casting the pointer parameter to the appropriate container type. Cc: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> ARM: 7720/1: ARM v6/v7 cmpxchg64 shouldn't clear upper 32 bits of the old/new value The implementation of cmpxchg64() for the ARM v6 and v7 architecture casts parameter 2 and 3 (the old and new 64bit values) to an unsigned long before calling the atomic_cmpxchg64() function. This clears the top 32 bits of the old and new values, resulting in the wrong values being compare-exchanged. Luckily, this only appears to be used for 64-bit sched_clock, which we don't (yet) have on ARM. This bug was introduced by commit 3e0f5a1 ("ARM: 7404/1: cmpxchg64: use atomic64 and local64 routines for cmpxchg64"). Cc: <stable@vger.kernel.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> ARM: 7852/1: cmpxchg: implement barrier-less cmpxchg64_local Our cmpxchg64 macros are wrappers around atomic64_cmpxchg. Whilst this is great for code re-use, there is a case for barrier-less cmpxchg where it is known to be safe (for example cmpxchg64_local and cmpxchg-based lockrefs). This patch introduces a 64-bit cmpxchg implementation specifically for the cmpxchg64_* macros, so that it can be later used by the lockref code. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> ARM: 7853/1: cmpxchg: implement cmpxchg64_relaxed This patch introduces cmpxchg64_relaxed for arm, which performs a 64-bit cmpxchg operation without barrier semantics. cmpxchg64_local is updated to use the new operation. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> ARM: 7984/1: prefetch: add prefetchw invocations for barriered atomics After a bunch of benchmarking on the interaction between dmb and pldw, it turns out that issuing the pldw *after* the dmb instruction can give modest performance gains (~3% atomic_add_return improvement on a dual A15). This patch adds prefetchw invocations to our barriered atomic operations including cmpxchg, test_and_xxx and futexes. Change-Id: Id6ebfe82ff9578c27e2b745e2cce167200112606 Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

While testing the pid namespace code I hit this nasty warning. [ 176.262617] ------------[ cut here ]------------ [ 176.263388] WARNING: at /home/eric/projects/linux/linux-userns-devel/kernel/softirq.c:160 local_bh_enable_ip+0x7a/0xa0() [ 176.265145] Hardware name: Bochs [ 176.265677] Modules linked in: [ 176.266341] Pid: 742, comm: bash Not tainted 3.7.0userns+ #18 [ 176.266564] Call Trace: [ 176.266564] [<ffffffff810a539f>] warn_slowpath_common+0x7f/0xc0 [ 176.266564] [<ffffffff810a53fa>] warn_slowpath_null+0x1a/0x20 [ 176.266564] [<ffffffff810ad9ea>] local_bh_enable_ip+0x7a/0xa0 [ 176.266564] [<ffffffff819308c9>] _raw_spin_unlock_bh+0x19/0x20 [ 176.266564] [<ffffffff8123dbda>] proc_free_inum+0x3a/0x50 [ 176.266564] [<ffffffff8111d0dc>] free_pid_ns+0x1c/0x80 [ 176.266564] [<ffffffff8111d195>] put_pid_ns+0x35/0x50 [ 176.266564] [<ffffffff810c608a>] put_pid+0x4a/0x60 [ 176.266564] [<ffffffff8146b177>] tty_ioctl+0x717/0xc10 [ 176.266564] [<ffffffff810aa4d5>] ? wait_consider_task+0x855/0xb90 [ 176.266564] [<ffffffff81086bf9>] ? default_spin_lock_flags+0x9/0x10 [ 176.266564] [<ffffffff810cab0a>] ? remove_wait_queue+0x5a/0x70 [ 176.266564] [<ffffffff811e37e8>] do_vfs_ioctl+0x98/0x550 [ 176.266564] [<ffffffff810b8a0f>] ? recalc_sigpending+0x1f/0x60 [ 176.266564] [<ffffffff810b9127>] ? __set_task_blocked+0x37/0x80 [ 176.266564] [<ffffffff810ab95b>] ? sys_wait4+0xab/0xf0 [ 176.266564] [<ffffffff811e3d31>] sys_ioctl+0x91/0xb0 [ 176.266564] [<ffffffff810a95f0>] ? task_stopped_code+0x50/0x50 [ 176.266564] [<ffffffff81939199>] system_call_fastpath+0x16/0x1b [ 176.266564] ---[ end trace 387af88219ad6143 ]--- It turns out that spin_unlock_bh(proc_inum_lock) is not safe when put_pid is called with another spinlock held and irqs disabled. For now take the easy path and use spin_lock_irqsave(proc_inum_lock) in proc_free_inum and spin_loc_irq in proc_alloc_inum(proc_inum_lock). Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Bug: 22173056 Backport: commits 1bb9bf4 to this one are backport of mnt namespace (cherry picked from commit dfb2ea4) Change-Id: I1bfca15df43e2e293cf725649e1815ec985ed891 Reviewed-on: http://gerrit.mot.com/778671 SLTApproved: Slta Waiver <sltawvr@motorola.com> SME-Granted: SME Approvals Granted Reviewed-by: Russell Knize <rknize@motorola.com> Submit-Approved: Jira Key <jirakey@motorola.com> Tested-by: Jira Key <jirakey@motorola.com> Reviewed-by: Abdul Salam <salamab@motorola.com> Reviewed-by: Sudharsan Yettapu <sudharsan.yettapu@motorola.com>

While testing the pid namespace code I hit this nasty warning. [ 176.262617] ------------[ cut here ]------------ [ 176.263388] WARNING: at /home/eric/projects/linux/linux-userns-devel/kernel/softirq.c:160 local_bh_enable_ip+0x7a/0xa0() [ 176.265145] Hardware name: Bochs [ 176.265677] Modules linked in: [ 176.266341] Pid: 742, comm: bash Not tainted 3.7.0userns+ MotorolaMobilityLLC#18 [ 176.266564] Call Trace: [ 176.266564] [<ffffffff810a539f>] warn_slowpath_common+0x7f/0xc0 [ 176.266564] [<ffffffff810a53fa>] warn_slowpath_null+0x1a/0x20 [ 176.266564] [<ffffffff810ad9ea>] local_bh_enable_ip+0x7a/0xa0 [ 176.266564] [<ffffffff819308c9>] _raw_spin_unlock_bh+0x19/0x20 [ 176.266564] [<ffffffff8123dbda>] proc_free_inum+0x3a/0x50 [ 176.266564] [<ffffffff8111d0dc>] free_pid_ns+0x1c/0x80 [ 176.266564] [<ffffffff8111d195>] put_pid_ns+0x35/0x50 [ 176.266564] [<ffffffff810c608a>] put_pid+0x4a/0x60 [ 176.266564] [<ffffffff8146b177>] tty_ioctl+0x717/0xc10 [ 176.266564] [<ffffffff810aa4d5>] ? wait_consider_task+0x855/0xb90 [ 176.266564] [<ffffffff81086bf9>] ? default_spin_lock_flags+0x9/0x10 [ 176.266564] [<ffffffff810cab0a>] ? remove_wait_queue+0x5a/0x70 [ 176.266564] [<ffffffff811e37e8>] do_vfs_ioctl+0x98/0x550 [ 176.266564] [<ffffffff810b8a0f>] ? recalc_sigpending+0x1f/0x60 [ 176.266564] [<ffffffff810b9127>] ? __set_task_blocked+0x37/0x80 [ 176.266564] [<ffffffff810ab95b>] ? sys_wait4+0xab/0xf0 [ 176.266564] [<ffffffff811e3d31>] sys_ioctl+0x91/0xb0 [ 176.266564] [<ffffffff810a95f0>] ? task_stopped_code+0x50/0x50 [ 176.266564] [<ffffffff81939199>] system_call_fastpath+0x16/0x1b [ 176.266564] ---[ end trace 387af88219ad6143 ]--- It turns out that spin_unlock_bh(proc_inum_lock) is not safe when put_pid is called with another spinlock held and irqs disabled. For now take the easy path and use spin_lock_irqsave(proc_inum_lock) in proc_free_inum and spin_loc_irq in proc_alloc_inum(proc_inum_lock). Change-Id: Icc5e02fca3db0bda4acd491ad93b8f730d3b8627 Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

commit 45caeaa upstream. As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: MotorolaMobilityLLC#8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . MotorolaMobilityLLC#9 [] tcp_rcv_established at ffffffff81580b64 MotorolaMobilityLLC#10 [] tcp_v4_do_rcv at ffffffff8158b54a MotorolaMobilityLLC#11 [] tcp_v4_rcv at ffffffff8158cd02 MotorolaMobilityLLC#12 [] ip_local_deliver_finish at ffffffff815668f4 MotorolaMobilityLLC#13 [] ip_local_deliver at ffffffff81566bd9 MotorolaMobilityLLC#14 [] ip_rcv_finish at ffffffff8156656d MotorolaMobilityLLC#15 [] ip_rcv at ffffffff81566f06 MotorolaMobilityLLC#16 [] __netif_receive_skb_core at ffffffff8152b3a2 MotorolaMobilityLLC#17 [] __netif_receive_skb at ffffffff8152b608 MotorolaMobilityLLC#18 [] netif_receive_skb at ffffffff8152b690 MotorolaMobilityLLC#19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] MotorolaMobilityLLC#20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] MotorolaMobilityLLC#21 [] net_rx_action at ffffffff8152bac2 MotorolaMobilityLLC#22 [] __do_softirq at ffffffff81084b4f MotorolaMobilityLLC#23 [] call_softirq at ffffffff8164845c MotorolaMobilityLLC#24 [] do_softirq at ffffffff81016fc5 MotorolaMobilityLLC#25 [] irq_exit at ffffffff81084ee5 MotorolaMobilityLLC#26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)â�© 225 {â�© 226 â�¹ const struct inet_connection_sock *icsk = inet_csk(sk);â�© 227 â�¹ const struct dst_entry *dst = __sk_dst_get(sk);â�© 228 â�© 229 â�¹ return (dst && dst_metric(dst, RTAX_QUICKACK)) ||â�© 230 â�¹ â�¹ (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);â�© 231 }â�© But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <egarver@redhat.com> Cc: Hannes Sowa <hsowa@redhat.com> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 45caeaa upstream. As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: MotorolaMobilityLLC#8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . MotorolaMobilityLLC#9 [] tcp_rcv_established at ffffffff81580b64 MotorolaMobilityLLC#10 [] tcp_v4_do_rcv at ffffffff8158b54a MotorolaMobilityLLC#11 [] tcp_v4_rcv at ffffffff8158cd02 MotorolaMobilityLLC#12 [] ip_local_deliver_finish at ffffffff815668f4 MotorolaMobilityLLC#13 [] ip_local_deliver at ffffffff81566bd9 MotorolaMobilityLLC#14 [] ip_rcv_finish at ffffffff8156656d MotorolaMobilityLLC#15 [] ip_rcv at ffffffff81566f06 MotorolaMobilityLLC#16 [] __netif_receive_skb_core at ffffffff8152b3a2 MotorolaMobilityLLC#17 [] __netif_receive_skb at ffffffff8152b608 MotorolaMobilityLLC#18 [] netif_receive_skb at ffffffff8152b690 MotorolaMobilityLLC#19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] MotorolaMobilityLLC#20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] MotorolaMobilityLLC#21 [] net_rx_action at ffffffff8152bac2 MotorolaMobilityLLC#22 [] __do_softirq at ffffffff81084b4f MotorolaMobilityLLC#23 [] call_softirq at ffffffff8164845c MotorolaMobilityLLC#24 [] do_softirq at ffffffff81016fc5 MotorolaMobilityLLC#25 [] irq_exit at ffffffff81084ee5 MotorolaMobilityLLC#26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)↩ 225 {↩ 226 ▹ const struct inet_connection_sock *icsk = inet_csk(sk);↩ 227 ▹ const struct dst_entry *dst = __sk_dst_get(sk);↩ 228 ↩ 229 ▹ return (dst && dst_metric(dst, RTAX_QUICKACK)) ||↩ 230 ▹ ▹ (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);↩ 231 }↩ But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <egarver@redhat.com> Cc: Hannes Sowa <hsowa@redhat.com> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4dfce57 upstream. There have been several reports over the years of NULL pointer dereferences in xfs_trans_log_inode during xfs_fsr processes, when the process is doing an fput and tearing down extents on the temporary inode, something like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 PID: 29439 TASK: ffff880550584fa0 CPU: 6 COMMAND: "xfs_fsr" [exception RIP: xfs_trans_log_inode+0x10] MotorolaMobilityLLC#9 [ffff8800a57bbbe0] xfs_bunmapi at ffffffffa037398e [xfs] MotorolaMobilityLLC#10 [ffff8800a57bbce8] xfs_itruncate_extents at ffffffffa0391b29 [xfs] MotorolaMobilityLLC#11 [ffff8800a57bbd88] xfs_inactive_truncate at ffffffffa0391d0c [xfs] MotorolaMobilityLLC#12 [ffff8800a57bbdb8] xfs_inactive at ffffffffa0392508 [xfs] MotorolaMobilityLLC#13 [ffff8800a57bbdd8] xfs_fs_evict_inode at ffffffffa035907e [xfs] MotorolaMobilityLLC#14 [ffff8800a57bbe00] evict at ffffffff811e1b67 MotorolaMobilityLLC#15 [ffff8800a57bbe28] iput at ffffffff811e23a5 MotorolaMobilityLLC#16 [ffff8800a57bbe58] dentry_kill at ffffffff811dcfc8 MotorolaMobilityLLC#17 [ffff8800a57bbe88] dput at ffffffff811dd06c MotorolaMobilityLLC#18 [ffff8800a57bbea8] __fput at ffffffff811c823b MotorolaMobilityLLC#19 [ffff8800a57bbef0] ____fput at ffffffff811c846e MotorolaMobilityLLC#20 [ffff8800a57bbf00] task_work_run at ffffffff81093b27 MotorolaMobilityLLC#21 [ffff8800a57bbf30] do_notify_resume at ffffffff81013b0c MotorolaMobilityLLC#22 [ffff8800a57bbf50] int_signal at ffffffff8161405d As it turns out, this is because the i_itemp pointer, along with the d_ops pointer, has been overwritten with zeros when we tear down the extents during truncate. When the in-core inode fork on the temporary inode used by xfs_fsr was originally set up during the extent swap, we mistakenly looked at di_nextents to determine whether all extents fit inline, but this misses extents generated by speculative preallocation; we should be using if_bytes instead. This mistake corrupts the in-memory inode, and code in xfs_iext_remove_inline eventually gets bad inputs, causing it to memmove and memset incorrect ranges; this became apparent because the two values in ifp->if_u2.if_inline_ext[1] contained what should have been in d_ops and i_itemp; they were memmoved due to incorrect array indexing and then the original locations were zeroed with memset, again due to an array overrun. Fix this by properly using i_df.if_bytes to determine the number of extents, not di_nextents. Thanks to dchinner for looking at this with me and spotting the root cause. [nborisov: backported to 4.4] Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>