This repository has been archived by the owner on Oct 5, 2018. It is now read-only.
Enable PSCI for v3.18 #15
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
March 12, 2015 10:12
Reserve the upper memory address for some runtime images. Signed-off-by: Haojian Zhuang <[email protected]> Signed-off-by: Leo Yan <[email protected]>
Enable psci in Hisilicon Hi6220 HiKey board. Signed-off-by: Haojian Zhuang <[email protected]> Signed-off-by: Leo Yan <[email protected]>
|
a regression is introduced with this change when using Hisilicon's bootloader.
It has been proposed to provide a legacy dtb and use the PSCI enabled combination (UEFI + kernel) as the default since it is the long term plan |
|
I can confirm this patch also works with UEFI+4.0rc3+dtb-from-3.18 |
|
Leo-yan, can you confirm that this is a conscious decision to stop users from using the hisilicon bootloader? are you aware of the implications? |
|
We are planning to use ATF + UEFI, so this will replace hisilicon's bootloader; now we still are working on porting hisilicon's bootloader code to ATF/UEFI so that can meet the release requirement. Like Fathi said, maybe we can provide a legacy dtb to compatiable w/t hisilicon's bootloader; so that we can support two kinds of bootloaders in short term. BTW, regard of Jorge's question, it's better u can confirm w/t Scott/Usman/Haojian when is a good time point to remove hisilicon bootloader. |
|
shouldn't we better have another hi6220.dtsi selectable at build time? there is work that might need device tree changes that could be carried out still using the hisilicon bootloader. Using precompiled dtbs might cause confusion. |
|
I'm more comfortable to ship a legacy dtb and document it. I assume we'll get rid of legacy as soon as we get rid of HiSilicon bootloader. |
|
do you know when will that happen? besides, what would be the advantage? device trees live in the kernel and are built along with the kernel for a reason. Adding a commit that brings in a new build config is equally easy to remove and keeps all the info self contained in tree (without having to look for documents and binaries). in any case, if it makes the release process easier for you and we are talking of a couple of weeks I guess we can go either way. |
|
merged to hikey-psci branch to allow psci/ATF feature development. |
|
reopening since it's not in the main branch yet. |
|
please send the pull request to the hikey-psci topic branch. this cant be merged to hikey. |
|
Why not? It is needed to have all cpus working with UEFI. Why are people so scared to make the call to have all cores working with UEFI and only one with that horrid, binary-only, closed-source evil vendor bootloader? |
|
AFAIK not enough testing has been done: once UEFI offers the same functionality than the vendor's bootloader we will definitively make the move (that has always been the plan as you know and it is the direction that we are following). If what you are saying is that they are functionally equivalent now, then sure, lets discuss and move ahead. But I dont think this is the case. |
|
It has more functionality at this point:
And more. |
|
I agree with Koen that UEFI is mature enough now.
IIRC The pcsi move will not even break booting with old bootloader - they will just have to live with one core. Which, if a problem for the user, is a good motivation to move to UEFI.. |
|
beside having one core, there's still known issues on uefi:
I'm not arguing agree/disagree. There's still things that other people consider a blocker at this point, even the developer working on it. |
|
There needs to be an incentive to switch to UEFI so more people use it and give feedback/report bugs or even fix them. Having clear requirements, meaning more detailed than just "feature parity" would go a long way. Having said all that, the only drawback to this pull request is having only one core on the evil vendor bootloader, is that really such a big problem that prevents merging this right now? AFAICT the board will ship with UEFI, so we should be pushing that, not stick with the old and hope the new will be ready in time for launch. |
|
No, the board will not ship with UEFI. In any case please send the pull request to the topic branch - topic/hikey/psci tracks hikey: it is a matter of time until we push this to the main branch, I wouldn't worry too much about it at this point. |
|
No support in mainline, not shipping with an open source bootloader, this hikey board is a farce. |
|
Koen, it will get there - upstream - and UEFI will be available: many are working towards it. It just wont happen as fast as we would all like but such is life. |
|
close pull request in favor of #97 |
docularxu
pushed a commit
that referenced
this pull request
Oct 26, 2015
Martin KaFai Lau says: ==================== ipv6: Fix dst_entry refcnt bugs in ip6_tunnel v4: - Fix a compilation error in patch 5 when CONFIG_LOCKDEP is turned on and re-test it v3: - Merge a 'if else if' test in patch 4 - Use rcu_dereference_protected in patch 5 to fix a sparse check when CONFIG_SPARSE_RCU_POINTER is enabled v2: - Add patch 4 and 5 to remove the spinlock v1: This patch series is to fix the dst refcnt bugs in ip6_tunnel. Patch 1 and 2 are the prep works. Patch 3 is the fix. I can reproduce the bug by adding and removing the ip6gre tunnel while running a super_netperf TCP_CRR test. I get the following trace by adding WARN_ON_ONCE(newrefcnt < 0) to dst_release(): [ 312.760432] ------------[ cut here ]------------ [ 312.774664] WARNING: CPU: 2 PID: 10263 at net/core/dst.c:288 dst_release+0xf3/0x100() [ 312.776041] Modules linked in: k10temp coretemp hwmon ip6_gre ip6_tunnel tunnel6 ipmi_devintf ipmi_ms\ ghandler ip6table_filter ip6_tables xt_NFLOG nfnetlink_log nfnetlink xt_comment xt_statistic iptable_fil\ ter ip_tables x_tables nfsv3 nfs_acl nfs fscache lockd grace mptctl netconsole autofs4 rpcsec_gss_krb5 a\ uth_rpcgss oid_registry sunrpc ipv6 dm_mod loop iTCO_wdt iTCO_vendor_support serio_raw rtc_cmos pcspkr i\ 2c_i801 i2c_core lpc_ich mfd_core ehci_pci ehci_hcd e1000e mlx4_en ptp pps_core vxlan udp_tunnel ip6_udp\ _tunnel mlx4_core sg button ext3 jbd mpt2sas raid_class [ 312.785302] CPU: 2 PID: 10263 Comm: netperf Not tainted 4.2.0-rc8-00046-g4db9b63-dirty #15 [ 312.791695] Hardware name: Quanta Freedom /Windmill-EP, BIOS F03_3B04 09/12/2013 [ 312.792965] ffffffff819dca2c ffff8811dfbdf6f8 ffffffff816537de ffff88123788fdb8 [ 312.794263] 0000000000000000 ffff8811dfbdf738 ffffffff81052646 ffff8811dfbdf768 [ 312.795593] ffff881203a98180 00000000ffffffff ffff88242927a000 ffff88120a2532e0 [ 312.796946] Call Trace: [ 312.797380] [<ffffffff816537de>] dump_stack+0x45/0x57 [ 312.798288] [<ffffffff81052646>] warn_slowpath_common+0x86/0xc0 [ 312.799699] [<ffffffff8105273a>] warn_slowpath_null+0x1a/0x20 [ 312.800852] [<ffffffff8159f9b3>] dst_release+0xf3/0x100 [ 312.801834] [<ffffffffa03f1308>] ip6_tnl_dst_store+0x48/0x70 [ip6_tunnel] [ 312.803738] [<ffffffffa03fd0b6>] ip6gre_xmit2+0x536/0x720 [ip6_gre] [ 312.804774] [<ffffffffa03fd40a>] ip6gre_tunnel_xmit+0x16a/0x410 [ip6_gre] [ 312.805986] [<ffffffff8159934b>] dev_hard_start_xmit+0x23b/0x390 [ 312.808810] [<ffffffff815a2f5f>] ? neigh_destroy+0xef/0x140 [ 312.809843] [<ffffffff81599a6c>] __dev_queue_xmit+0x48c/0x4f0 [ 312.813931] [<ffffffff81599ae3>] dev_queue_xmit_sk+0x13/0x20 [ 312.814993] [<ffffffff815a0832>] neigh_direct_output+0x12/0x20 [ 312.817448] [<ffffffffa021d633>] ip6_finish_output2+0x183/0x460 [ipv6] [ 312.818762] [<ffffffff81306fc5>] ? find_next_bit+0x15/0x20 [ 312.819671] [<ffffffffa021fd79>] ip6_finish_output+0x89/0xe0 [ipv6] [ 312.820720] [<ffffffffa021fe14>] ip6_output+0x44/0xe0 [ipv6] [ 312.821762] [<ffffffff815c8809>] ? nf_hook_slow+0x69/0xc0 [ 312.823123] [<ffffffffa021d232>] ip6_xmit+0x242/0x4c0 [ipv6] [ 312.824073] [<ffffffffa021c9f0>] ? ac6_proc_exit+0x20/0x20 [ipv6] [ 312.825116] [<ffffffffa024c751>] inet6_csk_xmit+0x61/0xa0 [ipv6] [ 312.826127] [<ffffffff815eb590>] tcp_transmit_skb+0x4f0/0x9b0 [ 312.827441] [<ffffffff815ed267>] tcp_connect+0x637/0x7a0 [ 312.828327] [<ffffffffa0245906>] tcp_v6_connect+0x2d6/0x550 [ipv6] [ 312.829581] [<ffffffff81606f05>] __inet_stream_connect+0x95/0x2f0 [ 312.830600] [<ffffffff810ae13a>] ? hrtimer_try_to_cancel+0x1a/0xf0 [ 312.833456] [<ffffffff812fba19>] ? timerqueue_add+0x59/0xb0 [ 312.834407] [<ffffffff81607198>] inet_stream_connect+0x38/0x50 [ 312.835886] [<ffffffff8157cb17>] SYSC_connect+0xb7/0xf0 [ 312.840035] [<ffffffff810af6d3>] ? do_setitimer+0x1b3/0x200 [ 312.840983] [<ffffffff810af75a>] ? alarm_setitimer+0x3a/0x70 [ 312.841941] [<ffffffff8157d7ae>] SyS_connect+0xe/0x10 [ 312.842818] [<ffffffff81659297>] entry_SYSCALL_64_fastpath+0x12/0x6a [ 312.844206] ---[ end trace 43f3ecd86c3b1313 ]--- ==================== Signed-off-by: David S. Miller <[email protected]>
johnstultz-work
pushed a commit
that referenced
this pull request
Jan 5, 2016
commit ecf5fc6 upstream. Nikolay has reported a hang when a memcg reclaim got stuck with the following backtrace: PID: 18308 TASK: ffff883d7c9b0a30 CPU: 1 COMMAND: "rsync" #0 __schedule at ffffffff815ab152 #1 schedule at ffffffff815ab76e #2 schedule_timeout at ffffffff815ae5e5 #3 io_schedule_timeout at ffffffff815aad6a #4 bit_wait_io at ffffffff815abfc6 #5 __wait_on_bit at ffffffff815abda5 #6 wait_on_page_bit at ffffffff8111fd4f #7 shrink_page_list at ffffffff81135445 #8 shrink_inactive_list at ffffffff81135845 #9 shrink_lruvec at ffffffff81135ead #10 shrink_zone at ffffffff811360c3 #11 shrink_zones at ffffffff81136eff #12 do_try_to_free_pages at ffffffff8113712f #13 try_to_free_mem_cgroup_pages at ffffffff811372be #14 try_charge at ffffffff81189423 #15 mem_cgroup_try_charge at ffffffff8118c6f5 #16 __add_to_page_cache_locked at ffffffff8112137d #17 add_to_page_cache_lru at ffffffff81121618 #18 pagecache_get_page at ffffffff8112170b #19 grow_dev_page at ffffffff811c8297 #20 __getblk_slow at ffffffff811c91d6 #21 __getblk_gfp at ffffffff811c92c1 #22 ext4_ext_grow_indepth at ffffffff8124565c #23 ext4_ext_create_new_leaf at ffffffff81246ca8 #24 ext4_ext_insert_extent at ffffffff81246f09 #25 ext4_ext_map_blocks at ffffffff8124a848 #26 ext4_map_blocks at ffffffff8121a5b7 #27 mpage_map_one_extent at ffffffff8121b1fa #28 mpage_map_and_submit_extent at ffffffff8121f07b #29 ext4_writepages at ffffffff8121f6d5 #30 do_writepages at ffffffff8112c490 #31 __filemap_fdatawrite_range at ffffffff81120199 #32 filemap_flush at ffffffff8112041c #33 ext4_alloc_da_blocks at ffffffff81219da1 #34 ext4_rename at ffffffff81229b91 #35 ext4_rename2 at ffffffff81229e32 #36 vfs_rename at ffffffff811a08a5 #37 SYSC_renameat2 at ffffffff811a3ffc #38 sys_renameat2 at ffffffff811a408e #39 sys_rename at ffffffff8119e51e #40 system_call_fastpath at ffffffff815afa89 Dave Chinner has properly pointed out that this is a deadlock in the reclaim code because ext4 doesn't submit pages which are marked by PG_writeback right away. The heuristic was introduced by commit e62e384 ("memcg: prevent OOM with too many dirty pages") and it was applied only when may_enter_fs was specified. The code has been changed by c3b94f4 ("memcg: further prevent OOM with too many dirty pages") which has removed the __GFP_FS restriction with a reasoning that we do not get into the fs code. But this is not sufficient apparently because the fs doesn't necessarily submit pages marked PG_writeback for IO right away. ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily submit the bio. Instead it tries to map more pages into the bio and mpage_map_one_extent might trigger memcg charge which might end up waiting on a page which is marked PG_writeback but hasn't been submitted yet so we would end up waiting for something that never finishes. Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2) before we go to wait on the writeback. The page fault path, which is the only path that triggers memcg oom killer since 3.12, shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue which was originally addressed by the heuristic. As per David Chinner the xfs is doing similar thing since 2.6.15 already so ext4 is not the only affected filesystem. Moreover he notes: : For example: IO completion might require unwritten extent conversion : which executes filesystem transactions and GFP_NOFS allocations. The : writeback flag on the pages can not be cleared until unwritten : extent conversion completes. Hence memory reclaim cannot wait on : page writeback to complete in GFP_NOFS context because it is not : safe to do so, memcg reclaim or otherwise. Cc: [email protected] # 3.9+ [[email protected]: corrected the control flow] Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages") Reported-by: Nikolay Borisov <[email protected]> Signed-off-by: Michal Hocko <[email protected]> Signed-off-by: Hugh Dickins <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
idlethread
pushed a commit
that referenced
this pull request
Apr 21, 2016
commit ec183d2 upstream. Fixes segmentation fault using, for instance: (gdb) run record -I -e intel_pt/tsc=1,noretcomp=1/u /bin/ls Starting program: /home/acme/bin/perf record -I -e intel_pt/tsc=1,noretcomp=1/u /bin/ls Missing separate debuginfos, use: dnf debuginfo-install glibc-2.22-7.fc23.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0 x00000000004b9ea5 in tracepoint_error (e=0x0, err=13, sys=0x19b1370 "sched", name=0x19a5d00 "sched_switch") at util/parse-events.c:410 (gdb) bt #0 0x00000000004b9ea5 in tracepoint_error (e=0x0, err=13, sys=0x19b1370 "sched", name=0x19a5d00 "sched_switch") at util/parse-events.c:410 #1 0x00000000004b9fc5 in add_tracepoint (list=0x19a5d20, idx=0x7fffffffb8c0, sys_name=0x19b1370 "sched", evt_name=0x19a5d00 "sched_switch", err=0x0, head_config=0x0) at util/parse-events.c:433 #2 0x00000000004ba334 in add_tracepoint_event (list=0x19a5d20, idx=0x7fffffffb8c0, sys_name=0x19b1370 "sched", evt_name=0x19a5d00 "sched_switch", err=0x0, head_config=0x0) at util/parse-events.c:498 #3 0x00000000004bb699 in parse_events_add_tracepoint (list=0x19a5d20, idx=0x7fffffffb8c0, sys=0x19b1370 "sched", event=0x19a5d00 "sched_switch", err=0x0, head_config=0x0) at util/parse-events.c:936 #4 0x00000000004f6eda in parse_events_parse (_data=0x7fffffffb8b0, scanner=0x19a49d0) at util/parse-events.y:391 #5 0x00000000004bc8e5 in parse_events__scanner (str=0x663ff2 "sched:sched_switch", data=0x7fffffffb8b0, start_token=258) at util/parse-events.c:1361 #6 0x00000000004bca57 in parse_events (evlist=0x19a5220, str=0x663ff2 "sched:sched_switch", err=0x0) at util/parse-events.c:1401 #7 0x0000000000518d5f in perf_evlist__can_select_event (evlist=0x19a3b90, str=0x663ff2 "sched:sched_switch") at util/record.c:253 #8 0x0000000000553c42 in intel_pt_track_switches (evlist=0x19a3b90) at arch/x86/util/intel-pt.c:364 #9 0x00000000005549d1 in intel_pt_recording_options (itr=0x19a2c40, evlist=0x19a3b90, opts=0x8edf68 <record+232>) at arch/x86/util/intel-pt.c:664 #10 0x000000000051e076 in auxtrace_record__options (itr=0x19a2c40, evlist=0x19a3b90, opts=0x8edf68 <record+232>) at util/auxtrace.c:539 #11 0x0000000000433368 in cmd_record (argc=1, argv=0x7fffffffde60, prefix=0x0) at builtin-record.c:1264 #12 0x000000000049bec2 in run_builtin (p=0x8fa2a8 <commands+168>, argc=5, argv=0x7fffffffde60) at perf.c:390 #13 0x000000000049c12a in handle_internal_command (argc=5, argv=0x7fffffffde60) at perf.c:451 #14 0x000000000049c278 in run_argv (argcp=0x7fffffffdcbc, argv=0x7fffffffdcb0) at perf.c:495 #15 0x000000000049c60a in main (argc=5, argv=0x7fffffffde60) at perf.c:618 (gdb) Intel PT attempts to find the sched:sched_switch tracepoint but that seg faults if tracefs is not readable, because the error reporting structure is null, as errors are not reported when automatically adding tracepoints. Fix by checking before using. Committer note: This doesn't take place in a kernel that supports perf_event_attr.context_switch, that is the default way that will be used for tracking context switches, only in older kernels, like 4.2, in a machine with Intel PT (e.g. Broadwell) for non-priviledged users. Further info from a similar patch by Wang: The error is in tracepoint_error: it assumes the 'e' parameter is valid. However, there are many situation a parse_event() can be called without parse_events_error. See result of $ grep 'parse_events(.*NULL)' ./tools/perf/ -r' Signed-off-by: Adrian Hunter <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Tong Zhang <[email protected]> Cc: Wang Nan <[email protected]> Fixes: 1965817 ("perf tools: Enhance parsing events tracepoint error output") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
nyadla-sys
pushed a commit
to nyadla-sys/linux
that referenced
this pull request
Apr 24, 2017
[ Upstream commit 45caeaa ] 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: 96boards#8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . 96boards#9 [] tcp_rcv_established at ffffffff81580b64 96boards#10 [] tcp_v4_do_rcv at ffffffff8158b54a 96boards#11 [] tcp_v4_rcv at ffffffff8158cd02 96boards#12 [] ip_local_deliver_finish at ffffffff815668f4 96boards#13 [] ip_local_deliver at ffffffff81566bd9 96boards#14 [] ip_rcv_finish at ffffffff8156656d 96boards#15 [] ip_rcv at ffffffff81566f06 #16 [] __netif_receive_skb_core at ffffffff8152b3a2 #17 [] __netif_receive_skb at ffffffff8152b608 #18 [] netif_receive_skb at ffffffff8152b690 #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] 96boards#21 [] net_rx_action at ffffffff8152bac2 96boards#22 [] __do_softirq at ffffffff81084b4f 96boards#23 [] call_softirq at ffffffff8164845c 96boards#24 [] do_softirq at ffffffff81016fc5 96boards#25 [] irq_exit at ffffffff81084ee5 96boards#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 <[email protected]> Cc: Hannes Sowa <[email protected]> Signed-off-by: Jon Maxwell <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
nyadla-sys
pushed a commit
to nyadla-sys/linux
that referenced
this pull request
Apr 24, 2017
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] 96boards#9 [ffff8800a57bbbe0] xfs_bunmapi at ffffffffa037398e [xfs] 96boards#10 [ffff8800a57bbce8] xfs_itruncate_extents at ffffffffa0391b29 [xfs] 96boards#11 [ffff8800a57bbd88] xfs_inactive_truncate at ffffffffa0391d0c [xfs] 96boards#12 [ffff8800a57bbdb8] xfs_inactive at ffffffffa0392508 [xfs] 96boards#13 [ffff8800a57bbdd8] xfs_fs_evict_inode at ffffffffa035907e [xfs] 96boards#14 [ffff8800a57bbe00] evict at ffffffff811e1b67 96boards#15 [ffff8800a57bbe28] iput at ffffffff811e23a5 #16 [ffff8800a57bbe58] dentry_kill at ffffffff811dcfc8 #17 [ffff8800a57bbe88] dput at ffffffff811dd06c #18 [ffff8800a57bbea8] __fput at ffffffff811c823b #19 [ffff8800a57bbef0] ____fput at ffffffff811c846e #20 [ffff8800a57bbf00] task_work_run at ffffffff81093b27 96boards#21 [ffff8800a57bbf30] do_notify_resume at ffffffff81013b0c 96boards#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] Cc: [email protected] Signed-off-by: Eric Sandeen <[email protected]> Reviewed-by: Brian Foster <[email protected]> Signed-off-by: Dave Chinner <[email protected]> Signed-off-by: Nikolay Borisov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> -- fs/xfs/xfs_bmap_util.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Enable PSCI for v3.18