Skip to content

[LTS 8.8] CVE-2023-4206, CVE-2023-4207, CVE-2023-4208 #156

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 13, 2025

Conversation

pvts-mat
Copy link
Contributor

@pvts-mat pvts-mat commented Mar 8, 2025

[LTS 8.8]
CVE-2023-4206 VULN-6646
CVE-2023-4207 VULN-6653
CVE-2023-4208 VULN-6660

Problem

The PR addresses a series of related CVEs, which were once listed under a single CVE-2023-4128. From https://lore.kernel.org/netdev/[email protected]/:

Three classifiers (cls_fw, cls_u32 and cls_route) always copy
tcf_result struct into the new instance of the filter on update.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.

This patch set fixes this issue in all affected classifiers by no longer
copying the tcf_result struct from the old filter.

Each CVE is related to a different classifier:

CVE File Option
CVE-2023-4206 net/sched/cls_route.c CONFIG_NET_CLS_ROUTE4
CVE-2023-4207 net/sched/cls_fw.c CONFIG_NET_CLS_FW
CVE-2023-4208 net/sched/cls_u32.c CONFIG_NET_CLS_U32

Analysis and solution

Official fixes

The official fixes for each of the vulnerabilities are as follows:

CVE Mainline fix Backport to 4.19 (closest to 4.18 of Rocky LTS 8.8) Relation to mainline fix Applicable to LTS 8.8
CVE-2023-4206 b80b829 ad8f36f96696a7f1d191da66637c415959bab6d8 Same Yes
CVE-2023-4207 76e42ae 4f38dc8496d1991e2c055a0068dd98fb48affcc6 Same Yes
CVE-2023-4208 3044b16 4aae24015ecd70d824a953e2dc5b0ca2c4769243 Same Yes

Applicability

Each change is applicable to the LTS 8.8 from the configuration standpoint.

grep -e '\(CONFIG_NET_SCHED\|CONFIG_NET_CLS\|CONFIG_NET_CLS_ROUTE4\|CONFIG_NET_CLS_FW\|CONFIG_NET_CLS_U32\)\b' configs/kernel-4.18.0-x86_64.config

CONFIG_NET_SCHED=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m

Analysis

For the discussion of the validity of a fix based on simply ignoring a certain field while copying a data structure where the actual copy may be expected see analysis for LTS 8.6 RT Pull Request - it was not repeated for this version.

Unrelated to the tcf_result issue, it may be worth considering the retirement of the tcindex filter in LTS 8.8, as it was done in the mainline kernel for security reasons on 2023-02-16:

commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28
Author:     Jamal Hadi Salim <[email protected]>
AuthorDate: Tue Feb 14 08:49:14 2023 -0500
Commit:     Paolo Abeni <[email protected]>
CommitDate: Thu Feb 16 09:27:07 2023 +0100

    net/sched: Retire tcindex classifier
    
    The tcindex classifier has served us well for about a quarter of a century
    but has not been getting much TLC due to lack of known users. Most recently
    it has become easy prey to syzkaller. For this reason, we are retiring it.
    
    Signed-off-by: Jamal Hadi Salim <[email protected]>
    Acked-by: Jiri Pirko <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>

(Syzkaller = Google's fuzzing framework)

Retiring tcindex from mainline kernel is unfortunate, because it leaves LTS 8.8 not only with rich source of vulnerabilities, as the commit's message suggests, but a silent source, without any CVEs nor patches made for them by kernel.org in the future.

kABI check: passed

CVE=CVE-2023-4206.4207.4208 ./ninja.sh  _kabi_checked_ciqlts8_8-CVE-2023-4206.4207.4208

ninja: Entering directory `/data/build/rocky-patching'
[0/1] Check ABI of kernel [ciqlts8_8-CVE-2023-4206.4207.4208]
+ python3 /data/src/ctrliq-github/kernel-dist-git-el-8.8/SOURCES/check-kabi -k /data/src/ctrliq-github/kernel-dist-git-el-8.8/SOURCES/Module.kabi_x86_64 -s vms/build-ciqlts8_8/build_files/kernel-src-tree-ciqlts8_8-CVE-2023-4206.4207.4208/Module.symvers
kABI check passed
+ touch state/kernels/ciqlts8_8-CVE-2023-4206.4207.4208/kabi_checked

Boot test: passed

boot-test.log

Kselftests: passed relative

Methodology

A mix of kernel-selftests-internal and source-compiled tests were used:

  • kernel-selftests-internal: bpf tests, except:
    • bpf:test_kmod.sh: takes very long time to finish and always fails anyway,
    • bpf:test_progs: unstable, can crash the machine,
    • bpf:test_progs-no_alu32: unstable, can crash the machine.
  • source-compiled: all the rest.

Coverage (including tests skipped during execution)

android, bpf, breakpoints, capabilities, cgroup, core, cpu-hotplug, cpufreq, drivers/net/bonding, drivers/net/team, efivarfs, exec, filesystems, firmware, fpu, ftrace, futex, gpio, intel_pstate, ipc, kcmp, kvm, lib, livepatch, membarrier, memfd, memory-hotplug, mount, mqueue, net, net/forwarding, net/mptcp, netfilter, nsfs, proc, pstore, ptrace, rseq, rtc, sgx, sigaltstack, size, splice, static_keys, sync, sysctl, tc-testing, tdx, timens, timers, tpm2, user, vm, x86, zram

Reference

Three test runs were conducted on the reference kernel.
kselftests–mix–ciqlts8_8–run1.log
kselftests–mix–ciqlts8_8–run2.log
kselftests–mix–ciqlts8_8–run3.log

Patch

Two test runs were conducted on the patched kernel.
kselftests–mix–ciqlts8_8-CVE-2023-4206.4207.4208–run1.log
kselftests–mix–ciqlts8_8-CVE-2023-4206.4207.4208–run2.log

Comparison

ktests.xsh table --where "Summary = 'diff'" kselftests*.log

Column    File
--------  ------------------------------------------------------------
Status0   kselftests--mix--ciqlts8_8--run1.log
Status1   kselftests--mix--ciqlts8_8--run2.log
Status2   kselftests--mix--ciqlts8_8--run3.log
Status3   kselftests--mix--ciqlts8_8-CVE-2023-4206.4207.4208--run1.log
Status4   kselftests--mix--ciqlts8_8-CVE-2023-4206.4207.4208--run2.log

TestCase                       Status0  Status1  Status2  Status3  Status4  Summary
bpf:test_xdp_veth.sh           skip     skip     skip     pass     skip     diff
kvm:access_tracking_perf_test  fail     fail     pass     fail     fail     diff
kvm:rseq_test                  fail     pass     fail     fail     fail     diff
net:ip_defrag.sh               fail     pass     pass     pass     pass     diff
net:xfrm_policy.sh             fail     fail     fail     pass     fail     diff
netfilter:nft_flowtable.sh     fail     fail     fail     pass     fail     diff

Of the differing results the tests bpf:test_xdp_veth.sh, net:xfrm_policy.sh were known to give inconsistent results before.

The tests kvm:access_tracking_perf_test, kvm:rseq_test, net:ip_defrag.sh gave inconsistent results within the bounds of the reference testing itself - added to the list of flappy tests.

The netfilter:nft_flowtable.sh passes one of the patch tests while it was known to always fail before - added to the list of flappy tests as it is highly unlikely that the patch fixed this test case from "always failing" to "sometimes passing".

Kselftests (networking): passed relative

Methodology

In general kselftests all the net/forwarding tests fail (really should be skipped) because of the missing tool dependencies

# selftests: net/forwarding: bridge_igmp.sh
# SKIP: jq not installed
not ok 1 selftests: net/forwarding: bridge_igmp.sh # exit=1

Because the patch deals with networking specifically, an additional batch of tests was carried out after solving the test requirements issues.

sudo make ARCH=$(uname -m) -C tools/testing/selftests TARGETS="net/forwarding" run_tests

The tools/testing/selftests/net/forwarding/forwarding.config file used was created directly from the tools/testing/selftests/net/forwarding/forwarding.config.sample.

Reference

Three test runs were conducted on the reference kernel.
kselftests-net-forwarding–src–ciqlts8_8–run1.log
kselftests-net-forwarding–src–ciqlts8_8–run2.log
kselftests-net-forwarding–src–ciqlts8_8–run3.log

Patch

A single test run was conducted on the patched kernel.
kselftests-net-forwarding–src–ciqlts8_8-CVE-2023-4206.4207.4208–run1.log

Comparison and discussion

Results for the reference and patched kernel are the same.

ktests.xsh table kselftests-net-forwarding*.log

Column    File
--------  ---------------------------------------------------------------------------
Status0   kselftests-net-forwarding--src--ciqlts8_8--run1.log
Status1   kselftests-net-forwarding--src--ciqlts8_8--run2.log
Status2   kselftests-net-forwarding--src--ciqlts8_8--run3.log
Status3   kselftests-net-forwarding--src--ciqlts8_8-CVE-2023-4206.4207.4208--run1.log

TestCase                                     Status0  Status1  Status2  Status3  Summary
net/forwarding:bridge_igmp.sh                fail     fail     fail     fail     same
net/forwarding:bridge_locked_port.sh         pass     pass     pass     pass     same
net/forwarding:bridge_port_isolation.sh      pass     pass     pass     pass     same
net/forwarding:bridge_sticky_fdb.sh          pass     pass     pass     pass     same
net/forwarding:bridge_vlan_aware.sh          fail     fail     fail     fail     same
net/forwarding:bridge_vlan_unaware.sh        pass     pass     pass     pass     same
net/forwarding:ethtool.sh                    fail     fail     fail     fail     same
net/forwarding:gre_multipath.sh              fail     fail     fail     fail     same
net/forwarding:ip6_forward_instats_vrf.sh    fail     fail     fail     fail     same
net/forwarding:ipip_flat_gre.sh              pass     pass     pass     pass     same
net/forwarding:ipip_flat_gre_key.sh          pass     pass     pass     pass     same
net/forwarding:ipip_flat_gre_keys.sh         pass     pass     pass     pass     same
net/forwarding:ipip_hier_gre.sh              pass     pass     pass     pass     same
net/forwarding:ipip_hier_gre_key.sh          pass     pass     pass     pass     same
net/forwarding:ipip_hier_gre_keys.sh         pass     pass     pass     pass     same
net/forwarding:loopback.sh                   skip     skip     skip     skip     same
net/forwarding:mirror_gre.sh                 fail     fail     fail     fail     same
net/forwarding:mirror_gre_bound.sh           pass     pass     pass     pass     same
net/forwarding:mirror_gre_bridge_1d.sh       pass     pass     pass     pass     same
net/forwarding:mirror_gre_bridge_1d_vlan.sh  fail     fail     fail     fail     same
net/forwarding:mirror_gre_bridge_1q.sh       pass     pass     pass     pass     same
net/forwarding:mirror_gre_bridge_1q_lag.sh   pass     pass     pass     pass     same
net/forwarding:mirror_gre_changes.sh         fail     fail     fail     fail     same
net/forwarding:mirror_gre_flower.sh          fail     fail     fail     fail     same
net/forwarding:mirror_gre_lag_lacp.sh        pass     pass     pass     pass     same
net/forwarding:mirror_gre_neigh.sh           pass     pass     pass     pass     same
net/forwarding:mirror_gre_nh.sh              pass     pass     pass     pass     same
net/forwarding:mirror_gre_vlan.sh            pass     pass     pass     pass     same
net/forwarding:mirror_gre_vlan_bridge_1q.sh  fail     fail     fail     fail     same
net/forwarding:mirror_vlan.sh                pass     pass     pass     pass     same
net/forwarding:router.sh                     skip     skip     skip     skip     same
net/forwarding:router_bridge.sh              pass     pass     pass     pass     same
net/forwarding:router_bridge_vlan.sh         pass     pass     pass     pass     same
net/forwarding:router_broadcast.sh           pass     pass     pass     pass     same
net/forwarding:router_multicast.sh           skip     skip     skip     skip     same
net/forwarding:router_multipath.sh           fail     fail     fail     fail     same
net/forwarding:router_vid_1.sh               pass     pass     pass     pass     same

The list of net/forwarding tests performed is not exhaustive (37 / 54). The net/forwarding:sch_ets.sh test executed right after net/forwarding:router_vid_1.sh causes the machine to hang for more than 10 minutes and the used testing framework interrupts the test suite.

...
ok 37 selftests: net/forwarding: router_vid_1.sh
# selftests: net/forwarding: sch_ets.sh
# TEST: ping vlan 10                                                  [ OK ]
# TEST: ping vlan 11                                                  [ OK ]
# TEST: ping vlan 12                                                  [ OK ]
# Running in priomap mode
# Testing ets bands 3 strict 3, streams 0 1
# TEST: band 0                                                        [ OK ]
# INFO: Expected ratio >95% Measured ratio 100.00
# TEST: band 1                                                        [ OK ]
# INFO: Expected ratio <5% Measured ratio 0
# Testing ets bands 3 strict 3, streams 1 2
ERROR:root:Subprocess exceeded the maximum freeze time 600 s. Terminating
INFO:root:Finished tests. Cleaning up the machine
...

The fix for the problem was deferred to another CVE for the sake of patching efficiency.

pvts-mat added 3 commits March 5, 2025 15:35
…e-after-free

jira VULN-6646
cve CVE-2023-4206
commit-author valis <[email protected]>
commit b80b829

When route4_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.

Fix this by no longer copying the tcf_result struct from the old filter.

Fixes: 1109c00 ("net: sched: RCU cls_route")
	Reported-by: valis <[email protected]>
	Reported-by: Bing-Jhong Billy Jheng <[email protected]>
	Signed-off-by: valis <[email protected]>
	Signed-off-by: Jamal Hadi Salim <[email protected]>
	Reviewed-by: Victor Nogueira <[email protected]>
	Reviewed-by: Pedro Tammela <[email protected]>
	Reviewed-by: M A Ramdhan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit b80b829)
	Signed-off-by: Marcin Wcisło <[email protected]>
…fter-free

jira VULN-6653
cve CVE-2023-4207
commit-author valis <[email protected]>
commit 76e42ae

When fw_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.

Fix this by no longer copying the tcf_result struct from the old filter.

Fixes: e35a8ee ("net: sched: fw use RCU")
	Reported-by: valis <[email protected]>
	Reported-by: Bing-Jhong Billy Jheng <[email protected]>
	Signed-off-by: valis <[email protected]>
	Signed-off-by: Jamal Hadi Salim <[email protected]>
	Reviewed-by: Victor Nogueira <[email protected]>
	Reviewed-by: Pedro Tammela <[email protected]>
	Reviewed-by: M A Ramdhan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 76e42ae)
	Signed-off-by: Marcin Wcisło <[email protected]>
…after-free

jira VULN-6660
cve CVE-2023-4208
commit-author valis <[email protected]>
commit 3044b16

When u32_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.

Fix this by no longer copying the tcf_result struct from the old filter.

Fixes: de5df63 ("net: sched: cls_u32 changes to knode must appear atomic to readers")
	Reported-by: valis <[email protected]>
	Reported-by: M A Ramdhan <[email protected]>
	Signed-off-by: valis <[email protected]>
	Signed-off-by: Jamal Hadi Salim <[email protected]>
	Reviewed-by: Victor Nogueira <[email protected]>
	Reviewed-by: Pedro Tammela <[email protected]>
	Reviewed-by: M A Ramdhan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 3044b16)
	Signed-off-by: Marcin Wcisło <[email protected]>
@pvts-mat pvts-mat marked this pull request as ready for review March 12, 2025 22:11
Copy link
Collaborator

@bmastbergen bmastbergen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

Copy link
Collaborator

@PlaidCat PlaidCat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@PlaidCat PlaidCat merged commit fa2ce2c into ctrliq:ciqlts8_8 Mar 13, 2025
2 checks passed
github-actions bot pushed a commit to bmastbergen/kernel-src-tree that referenced this pull request Apr 4, 2025
Patch series "hung_task: Dump the blocking task stacktrace", v4.

The hung_task detector is very useful for detecting the lockup.  However,
since it only dumps the blocked (uninterruptible sleep) processes, it is
not enough to identify the root cause of that lockup.

For example, if a process holds a mutex and sleep an event in
interruptible state long time, the other processes will wait on the mutex
in uninterruptible state.  In this case, the waiter processes are dumped,
but the blocker process is not shown because it is sleep in interruptible
state.

This adds a feature to dump the blocker task which holds a mutex
when detecting a hung task. e.g.

 INFO: task cat:115 blocked for more than 122 seconds.
       Not tainted 6.14.0-rc3-00003-ga8946be3de00 ctrliq#156
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 task:cat             state:D stack:13432 pid:115   tgid:115   ppid:106    task_flags:0x400100 flags:0x00000002
 Call Trace:
  <TASK>
  __schedule+0x731/0x960
  ? schedule_preempt_disabled+0x54/0xa0
  schedule+0xb7/0x140
  ? __mutex_lock+0x51b/0xa60
  ? __mutex_lock+0x51b/0xa60
  schedule_preempt_disabled+0x54/0xa0
  __mutex_lock+0x51b/0xa60
  read_dummy+0x23/0x70
  full_proxy_read+0x6a/0xc0
  vfs_read+0xc2/0x340
  ? __pfx_direct_file_splice_eof+0x10/0x10
  ? do_sendfile+0x1bd/0x2e0
  ksys_read+0x76/0xe0
  do_syscall_64+0xe3/0x1c0
  ? exc_page_fault+0xa9/0x1d0
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
 RIP: 0033:0x4840cd
 RSP: 002b:00007ffe99071828 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004840cd
 RDX: 0000000000001000 RSI: 00007ffe99071870 RDI: 0000000000000003
 RBP: 00007ffe99071870 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000001000
 R13: 00000000132fd3a0 R14: 0000000000000001 R15: ffffffffffffffff
  </TASK>
 INFO: task cat:115 is blocked on a mutex likely owned by task cat:114.
 task:cat             state:S stack:13432 pid:114   tgid:114   ppid:106    task_flags:0x400100 flags:0x00000002
 Call Trace:
  <TASK>
  __schedule+0x731/0x960
  ? schedule_timeout+0xa8/0x120
  schedule+0xb7/0x140
  schedule_timeout+0xa8/0x120
  ? __pfx_process_timeout+0x10/0x10
  msleep_interruptible+0x3e/0x60
  read_dummy+0x2d/0x70
  full_proxy_read+0x6a/0xc0
  vfs_read+0xc2/0x340
  ? __pfx_direct_file_splice_eof+0x10/0x10
  ? do_sendfile+0x1bd/0x2e0
  ksys_read+0x76/0xe0
  do_syscall_64+0xe3/0x1c0
  ? exc_page_fault+0xa9/0x1d0
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
 RIP: 0033:0x4840cd
 RSP: 002b:00007ffe3e0147b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004840cd
 RDX: 0000000000001000 RSI: 00007ffe3e014800 RDI: 0000000000000003
 RBP: 00007ffe3e014800 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000001000
 R13: 000000001a0a93a0 R14: 0000000000000001 R15: ffffffffffffffff
  </TASK>

TBD: We can extend this feature to cover other locks like rwsem and
rt_mutex, but rwsem requires to dump all the tasks which acquire and wait
that rwsem.  We can follow the waiter link but the output will be a bit
different compared with mutex case.


This patch (of 2):

The "hung_task" shows a long-time uninterruptible slept task, but most
often, it's blocked on a mutex acquired by another task.  Without dumping
such a task, investigating the root cause of the hung task problem is very
difficult.

This introduce task_struct::blocker_mutex to point the mutex lock which
this task is waiting for.  Since the mutex has "owner" information, we can
find the owner task and dump it with hung tasks.

Note: the owner can be changed while dumping the owner task, so
this is "likely" the owner of the mutex.

With this change, the hung task shows blocker task's info like below;

 INFO: task cat:115 blocked for more than 122 seconds.
       Not tainted 6.14.0-rc3-00003-ga8946be3de00 ctrliq#156
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 task:cat             state:D stack:13432 pid:115   tgid:115   ppid:106    task_flags:0x400100 flags:0x00000002
 Call Trace:
  <TASK>
  __schedule+0x731/0x960
  ? schedule_preempt_disabled+0x54/0xa0
  schedule+0xb7/0x140
  ? __mutex_lock+0x51b/0xa60
  ? __mutex_lock+0x51b/0xa60
  schedule_preempt_disabled+0x54/0xa0
  __mutex_lock+0x51b/0xa60
  read_dummy+0x23/0x70
  full_proxy_read+0x6a/0xc0
  vfs_read+0xc2/0x340
  ? __pfx_direct_file_splice_eof+0x10/0x10
  ? do_sendfile+0x1bd/0x2e0
  ksys_read+0x76/0xe0
  do_syscall_64+0xe3/0x1c0
  ? exc_page_fault+0xa9/0x1d0
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
 RIP: 0033:0x4840cd
 RSP: 002b:00007ffe99071828 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004840cd
 RDX: 0000000000001000 RSI: 00007ffe99071870 RDI: 0000000000000003
 RBP: 00007ffe99071870 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000001000
 R13: 00000000132fd3a0 R14: 0000000000000001 R15: ffffffffffffffff
  </TASK>
 INFO: task cat:115 is blocked on a mutex likely owned by task cat:114.
 task:cat             state:S stack:13432 pid:114   tgid:114   ppid:106    task_flags:0x400100 flags:0x00000002
 Call Trace:
  <TASK>
  __schedule+0x731/0x960
  ? schedule_timeout+0xa8/0x120
  schedule+0xb7/0x140
  schedule_timeout+0xa8/0x120
  ? __pfx_process_timeout+0x10/0x10
  msleep_interruptible+0x3e/0x60
  read_dummy+0x2d/0x70
  full_proxy_read+0x6a/0xc0
  vfs_read+0xc2/0x340
  ? __pfx_direct_file_splice_eof+0x10/0x10
  ? do_sendfile+0x1bd/0x2e0
  ksys_read+0x76/0xe0
  do_syscall_64+0xe3/0x1c0
  ? exc_page_fault+0xa9/0x1d0
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
 RIP: 0033:0x4840cd
 RSP: 002b:00007ffe3e0147b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004840cd
 RDX: 0000000000001000 RSI: 00007ffe3e014800 RDI: 0000000000000003
 RBP: 00007ffe3e014800 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000001000
 R13: 000000001a0a93a0 R14: 0000000000000001 R15: ffffffffffffffff
  </TASK>

[[email protected]: implement debug_show_blocker() in C rather than in CPP]
Link: https://lkml.kernel.org/r/174046694331.2194069.15472952050240807469.stgit@mhiramat.tok.corp.google.com
Link: https://lkml.kernel.org/r/174046695384.2194069.16796289525958195643.stgit@mhiramat.tok.corp.google.com
Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
Reviewed-by: Waiman Long <[email protected]>
Reviewed-by: Lance Yang <[email protected]>
Reviewed-by: Sergey Senozhatsky <[email protected]>
Cc: Anna Schumaker <[email protected]>
Cc: Boqun Feng <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Joel Granados <[email protected]>
Cc: Kent Overstreet <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Tomasz Figa <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Yongliang Gao <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants