Skip to content
This repository has been archived by the owner on Jun 18, 2024. It is now read-only.

6.9-rc4 + sched_ext compile fails, related to "scx_tick" #183

Closed
MichaelDeets opened this issue Apr 19, 2024 · 3 comments
Closed

6.9-rc4 + sched_ext compile fails, related to "scx_tick" #183

MichaelDeets opened this issue Apr 19, 2024 · 3 comments

Comments

@MichaelDeets
Copy link

MichaelDeets commented Apr 19, 2024

While trying to compile 6.9-rc4 with sched_ext applied, the build fails due to scx_tick being called within kernel/sched/core.c.

Specifically, it calls scx_tick(rq), while the definition within kernel/sched/ext.h uses just void. Changing the definition from void (within kernel/sched/ext.h) to struct rq *rq results in the kernel compiling without errors. Given I have not tested this kernel yet, I do not want to submit a PR; I could submit one after testing, but I would rather refer this issue to someone who knows what they are doing.

I'm currently using 6.8.7, and currently have a working configuration (can use scx_lavd for example). I'm extremely novice, so I'm hesitant to say anything; I would hate to waste people's time.

EDIT: Thanks I'm just going to test out and will report back if anything interesting pops up

@ptr1337
Copy link

ptr1337 commented Apr 19, 2024

Weve succesfully compiled 6.9rc4 with following patchset:
https://github.com/CachyOS/kernel-patches/blob/master/6.9/sched/0001-sched-ext.patch

Please give it a try.

@htejun
Copy link
Collaborator

htejun commented Apr 19, 2024

#184 should fix it. Thanks.

@MichaelDeets
Copy link
Author

Compiled fine, though I had to adjust the patch provided by CachyOS as some of the changes had already been applied. Was able to run scx_lavd just fine and everything seems to work well.

arighi pushed a commit to arighi/sched_ext that referenced this issue May 3, 2024
BugLink: https://bugs.launchpad.net/bugs/2060097

[ Upstream commit f7b94bd ]

Attemting to do sock_lock on .recvmsg may cause a deadlock as shown
bellow, so instead of using sock_sock this uses sk_receive_queue.lock
on bt_sock_ioctl to avoid the UAF:

INFO: task kworker/u9:1:121 blocked for more than 30 seconds.
      Not tainted 6.7.6-lemon sched-ext#183
Workqueue: hci0 hci_rx_work
Call Trace:
 <TASK>
 __schedule+0x37d/0xa00
 schedule+0x32/0xe0
 __lock_sock+0x68/0xa0
 ? __pfx_autoremove_wake_function+0x10/0x10
 lock_sock_nested+0x43/0x50
 l2cap_sock_recv_cb+0x21/0xa0
 l2cap_recv_frame+0x55b/0x30a0
 ? psi_task_switch+0xeb/0x270
 ? finish_task_switch.isra.0+0x93/0x2a0
 hci_rx_work+0x33a/0x3f0
 process_one_work+0x13a/0x2f0
 worker_thread+0x2f0/0x410
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe0/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2c/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 </TASK>

Fixes: 2e07e83 ("Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg")
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
(cherry picked from commit 2c9e2df022ef8b9d7fac58a04a2ef4ed25288955)
Signed-off-by: Paolo Pisati <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants