To restore previous uclamp value, we still need store uclamp_req directly.
Otherwise, saved_priority will store effective uclamp value and restore it
to uclamp_req later.
Bug: 277389699
Change-Id: I7b3e357fcfc3bd955789e85d730713c384d0ade7
Signed-off-by: Chungkai Mei <chungkai@google.com>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
Don't use the uclamp of current task as the default uclamp for
binders, because the uclamp of current task influence
binders' placement when not in a transaction.
Just use default value 0 and SCHED_CAPACITY_SCALE for binders'
default uclamp min and max. Also replace set_inherited_uclamp with
set_binder_prio_uclamp
Bug: 277389699
Change-Id: I07c4f40c2689dbc7eb23e7d3e2a2f435353dc25f
Signed-off-by: Chungkai Mei <chungkai@google.com>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
uclamp inheritance is not relevant while !uclamp_is_used().
Partially addresses the issue of enabling uclamp_is_used static key
causing a splat because of holding cpus_read_lock() in_atomic() context.
Bug: 259145692
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: Ib752e96e41b2fcace6edcdcec169f1ca56540a9b
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
We may still have long binder transaction due to
insufficient uclamp, so expand binder_prioity to
inherit uclamp as well.
Bug: 226003124
Signed-off-by: ChungKai Mei <chungkai@google.com>
Change-Id: I307ab812638eeea1ca3e80ae07dee05fb9797dd6
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
Most of binder's memory allocations are tiny, and they're allocated
and freed extremely frequently. The latency from going through the page
allocator all the time for such small allocations ends up being quite
high, especially when the system is low on memory. Binder is
performance-critical, so this is suboptimal.
Instead of using kzalloc to allocate a struct every time, reserve caches
specifically for allocating each struct quickly.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Juhyung Park <qkrwngud825@gmail.com>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
Every binder operation is being logged. This impacts performance and
increases memory footprint. Since binder is critical for Android
operation, doing any logging on production builds isn't best idea.
Quick grep over Android sources revealed that only lshal and dumpsys
binaries use binder_log directory, these are not critical so breaking
them won't hurt much. Anyways, I was able to succesfully run both and
bacis functionality was still there.
Benchmarks showed significant decrease in transaction time with an avg
of 1000ns.
Signed-off-by: Andrzej Perczak <linux@andrzejperczak.com>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
[Helium-Studio: Forwardport to 5.10 binder]
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
# Conflicts:
# drivers/android/Kconfig
In commit 15d9da3f818c ("binder: use bitmap for faster descriptor
lookup"), it was incorrectly assumed that references to the context
manager node should always get descriptor zero assigned to them.
However, if the context manager dies and a new process takes its place,
then assigning descriptor zero to the new context manager might lead to
collisions, as there could still be references to the older node. This
issue was reported by syzbot with the following trace:
kernel BUG at drivers/android/binder.c:1173!
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 447 Comm: binder-util Not tainted 6.10.0-rc6-00348-g31643d84b8c3 #10
Hardware name: linux,dummy-virt (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : binder_inc_ref_for_node+0x500/0x544
lr : binder_inc_ref_for_node+0x1e4/0x544
sp : ffff80008112b940
x29: ffff80008112b940 x28: ffff0e0e40310780 x27: 0000000000000000
x26: 0000000000000001 x25: ffff0e0e40310738 x24: ffff0e0e4089ba34
x23: ffff0e0e40310b00 x22: ffff80008112bb50 x21: ffffaf7b8f246970
x20: ffffaf7b8f773f08 x19: ffff0e0e4089b800 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 000000002de4aa60
x14: 0000000000000000 x13: 2de4acf000000000 x12: 0000000000000020
x11: 0000000000000018 x10: 0000000000000020 x9 : ffffaf7b90601000
x8 : ffff0e0e48739140 x7 : 0000000000000000 x6 : 000000000000003f
x5 : ffff0e0e40310b28 x4 : 0000000000000000 x3 : ffff0e0e40310720
x2 : ffff0e0e40310728 x1 : 0000000000000000 x0 : ffff0e0e40310710
Call trace:
binder_inc_ref_for_node+0x500/0x544
binder_transaction+0xf68/0x2620
binder_thread_write+0x5bc/0x139c
binder_ioctl+0xef4/0x10c8
[...]
This patch adds back the previous behavior of assigning the next
non-zero descriptor if references to previous context managers still
exist. It amends both strategies, the newer dbitmap code and also the
legacy slow_desc_lookup_olocked(), by allowing them to start looking
for available descriptors at a given offset.
Fixes: 15d9da3f818c ("binder: use bitmap for faster descriptor lookup")
Cc: stable@vger.kernel.org
Reported-and-tested-by: syzbot+3dae065ca76952a67257@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/000000000000c1c0a0061d1e6979@google.com/
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240722150512.4192473-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
commit 31643d84b8c3d9c846aa0e20bc033e46c68c7e7d upstream.
With the introduction of binder_available_for_proc_work_ilocked() in
commit 1b77e9dcc3 ("ANDROID: binder: remove proc waitqueue") a binder
thread can only "wait_for_proc_work" after its thread->looper has been
marked as BINDER_LOOPER_STATE_{ENTERED|REGISTERED}.
This means an unregistered reader risks waiting indefinitely for work
since it never gets added to the proc->waiting_threads. If there are no
further references to its waitqueue either the task will hang. The same
applies to readers using the (e)poll interface.
I couldn't find the rationale behind this restriction. So this patch
restores the previous behavior of allowing unregistered threads to
"wait_for_proc_work". Note that an error message for this scenario,
which had previously become unreachable, is now re-enabled.
Fixes: 1b77e9dcc3 ("ANDROID: binder: remove proc waitqueue")
Cc: stable@vger.kernel.org
Cc: Martijn Coenen <maco@google.com>
Cc: Arve Hjønnevåg <arve@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240711201452.2017543-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 229670361c29381b0e1677763590e4dbc209ecbe)
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
commit 42316941335644a98335f209daafa4c122f28983 upstream.
The type defined for the BINDER_SET_MAX_THREADS ioctl was changed from
size_t to __u32 in order to avoid incompatibility issues between 32 and
64-bit kernels. However, the internal types used to copy from user and
store the value were never updated. Use u32 to fix the inconsistency.
Fixes: a9350fc859 ("staging: android: binder: fix BINDER_SET_MAX_THREADS declaration")
Reported-by: Arve Hjønnevåg <arve@android.com>
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240421173750.3117808-1-cmllamas@google.com
[cmllamas: resolve minor conflicts due to missing commit 421518a2740f]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c437184be3c16f7123e5c59b4c85c1101f4dc96b)
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Most of binder's memory allocations are tiny, and they're allocated
and freed extremely frequently. The latency from going through the page
allocator all the time for such small allocations ends up being quite
high, especially when the system is low on memory. Binder is
performance-critical, so this is suboptimal.
Instead of using kzalloc to allocate a struct every time, reserve caches
specifically for allocating each struct quickly.
Change-Id: Ic63d27213f6a33dda817e959379a07c6384ece29
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Juhyung Park <qkrwngud825@gmail.com>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
These are initialized properly from the code just below kzalloc().
Replace it with kmalloc().
Change-Id: I0708699817fb6d0a1265bfbec6d3b27cfa00dd34
Signed-off-by: Juhyung Park <qkrwngud825@gmail.com>
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
* Excessive logging -- not present on angler -- is
affecting performance, contributing to missed audio
deadlines and likely other latency-dependent tasks.
Bug: 30375418
[0ctobot: Extend patch to cover binder_alloc_debug_mask]
Co-authored-by: Adam W. Willis <return.of.octobot@gmail.com>
Change-Id: I2acbc34aff0019d24c5c748df583f06f9d01aeb5
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
Binder code is very hot, so checking frequently to see if a debug
message should be printed is a waste of cycles. We're not debugging
binder, so just stub out the debug prints to compile them out entirely.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Change-Id: I66ac2d22bbc8943976b4dffa742e55b4e118d042
Signed-off-by: Helium-Studio <67852324+Helium-Studio@users.noreply.github.com>
[ Upstream commit 97830f3c3088638ff90b20dfba2eb4d487bf14d7 ]
In (e)poll mode, threads often depend on I/O events to determine when
data is ready for consumption. Within binder, a thread may initiate a
command via BINDER_WRITE_READ without a read buffer and then make use
of epoll_wait() or similar to consume any responses afterwards.
It is then crucial that epoll threads are signaled via wakeup when they
queue their own work. Otherwise, they risk waiting indefinitely for an
event leaving their work unhandled. What is worse, subsequent commands
won't trigger a wakeup either as the thread has pending work.
Fixes: 457b9a6f09 ("Staging: android: add binder driver")
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Steven Moreland <smoreland@google.com>
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240131215347.1808751-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
[ Upstream commit 148ade2c4d4f46b3ecc1ddad1c762371e8708e35 ]
This flag determines whether the thread should currently
process the work in the thread->todo worklist.
The prime usecase for this is improving the performance
of synchronous transactions: all synchronous transactions
post a BR_TRANSACTION_COMPLETE to the calling thread,
but there's no reason to return that command to userspace
right away - userspace anyway needs to wait for the reply.
Likewise, a synchronous transaction that contains a binder
object can cause a BC_ACQUIRE/BC_INCREFS to be returned to
userspace; since the caller must anyway hold a strong/weak
ref for the duration of the call, postponing these commands
until the reply comes in is not a problem.
Note that this flag is not used to determine whether a
thread can handle process work; a thread should never pick
up process work when thread work is still pending.
Before patch:
------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------
BM_sendVec_binderize/4 45959 ns 20288 ns 34351
BM_sendVec_binderize/8 45603 ns 20080 ns 34909
BM_sendVec_binderize/16 45528 ns 20113 ns 34863
BM_sendVec_binderize/32 45551 ns 20122 ns 34881
BM_sendVec_binderize/64 45701 ns 20183 ns 34864
BM_sendVec_binderize/128 45824 ns 20250 ns 34576
BM_sendVec_binderize/256 45695 ns 20171 ns 34759
BM_sendVec_binderize/512 45743 ns 20211 ns 34489
BM_sendVec_binderize/1024 46169 ns 20430 ns 34081
After patch:
------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------
BM_sendVec_binderize/4 42939 ns 17262 ns 40653
BM_sendVec_binderize/8 42823 ns 17243 ns 40671
BM_sendVec_binderize/16 42898 ns 17243 ns 40594
BM_sendVec_binderize/32 42838 ns 17267 ns 40527
BM_sendVec_binderize/64 42854 ns 17249 ns 40379
BM_sendVec_binderize/128 42881 ns 17288 ns 40427
BM_sendVec_binderize/256 42917 ns 17297 ns 40429
BM_sendVec_binderize/512 43184 ns 17395 ns 40411
BM_sendVec_binderize/1024 43119 ns 17357 ns 40432
Signed-off-by: Martijn Coenen <maco@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of: 97830f3c3088 ("binder: signal epoll threads of self-work")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
commit c6d05e0762ab276102246d24affd1e116a46aa0c upstream.
Each transaction is associated with a 'struct binder_buffer' that stores
the metadata about its buffer area. Since commit 74310e06be ("android:
binder: Move buffer out of area shared with user space") this struct is
no longer embedded within the buffer itself but is instead allocated on
the heap to prevent userspace access to this driver-exclusive info.
Unfortunately, the space of this struct is still being accounted for in
the total buffer size calculation, specifically for async transactions.
This results in an additional 104 bytes added to every async buffer
request, and this area is never used.
This wasted space can be substantial. If we consider the maximum mmap
buffer space of SZ_4M, the driver will reserve half of it for async
transactions, or 0x200000. This area should, in theory, accommodate up
to 262,144 buffers of the minimum 8-byte size. However, after adding
the extra 'sizeof(struct binder_buffer)', the total number of buffers
drops to only 18,724, which is a sad 7.14% of the actual capacity.
This patch fixes the buffer size calculation to enable the utilization
of the entire async buffer space. This is expected to reduce the number
of -ENOSPC errors that are seen on the field.
Fixes: 74310e06be ("android: binder: Move buffer out of area shared with user space")
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-6-cmllamas@google.com
[cmllamas: fix trivial conflict with missing 261e7818f06e.]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e2425a67b5ed67496959d0dfb99816f5757164b0)
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
commit 9a9ab0d963621d9d12199df9817e66982582d5a5 upstream.
Task A calls binder_update_page_range() to allocate and insert pages on
a remote address space from Task B. For this, Task A pins the remote mm
via mmget_not_zero() first. This can race with Task B do_exit() and the
final mmput() refcount decrement will come from Task A.
Task A | Task B
------------------+------------------
mmget_not_zero() |
| do_exit()
| exit_mm()
| mmput()
mmput() |
exit_mmap() |
remove_vma() |
fput() |
In this case, the work of ____fput() from Task B is queued up in Task A
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
work gets executed. However, Task A instead sleep, waiting for a reply
from Task B that never comes (it's dead).
This means the binder_deferred_release() is blocked until an unrelated
binder event forces Task A to go back to userspace. All the associated
death notifications will also be delayed until then.
In order to fix this use mmput_async() that will schedule the work in
the corresponding mm->async_put_work WQ instead of Task A.
Fixes: 457b9a6f09 ("Staging: android: add binder driver")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-4-cmllamas@google.com
[cmllamas: fix trivial conflict with missing d8ed45c5dcd4.]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 95b1d336b0642198b56836b89908d07b9a0c9608)
[fix conflict due to missing commit 720c241924046aff83f5f2323232f34a30a4c281
("ANDROID: binder: change down_write to down_read")]
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Among the kmem caches, the duplicate ones get merged with the system kmem
caches that cover basically every allocation size <64K which is a power of
2. In such a case, use of kmem cache is useless. Remove them.
Suggested-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
Changes in 4.14.324
lib/mpi: Eliminate unused umul_ppmm definitions for MIPS
drm/radeon: Fix integer overflow in radeon_cs_parser_init
ALSA: emu10k1: roll up loops in DSP setup code for Audigy
quota: Properly disable quotas when add_dquot_ref() fails
quota: fix warning in dqgrab()
udf: Fix uninitialized array access for some pathnames
fs: jfs: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLev
MIPS: dec: prom: Address -Warray-bounds warning
FS: JFS: Fix null-ptr-deref Read in txBegin
FS: JFS: Check for read-only mounted filesystem in txBegin
media: v4l2-mem2mem: add lock to protect parameter num_rdy
media: platform: mediatek: vpu: fix NULL ptr dereference
gfs2: Fix possible data races in gfs2_show_options()
pcmcia: rsrc_nonstatic: Fix memory leak in nonstatic_release_resource_db()
Bluetooth: L2CAP: Fix use-after-free
drm/amdgpu: Fix potential fence use-after-free v2
fbdev: mmp: fix value check in mmphw_probe()
net: xfrm: Fix xfrm_address_filter OOB read
net: af_key: fix sadb_x_filter validation
ip6_vti: fix slab-use-after-free in decode_session6
ip_vti: fix potential slab-use-after-free in decode_session6
xfrm: add NULL check in xfrm_update_ae_params
netfilter: nft_dynset: disallow object maps
team: Fix incorrect deletion of ETH_P_8021AD protocol vid from slaves
i40e: fix misleading debug logs
sock: Fix misuse of sk_under_memory_pressure()
net: do not allow gso_size to be set to GSO_BY_FRAGS
ALSA: usb-audio: Add support for Mythware XA001AU capture and playback interfaces.
cifs: Release folio lock on fscache read hit.
mmc: wbsd: fix double mmc_free_host() in wbsd_init()
serial: 8250: Fix oops for port->pm on uart_change_pm()
binder: fix memory leak in binder_init()
test_firmware: prevent race conditions by a correct implementation of locking
netfilter: set default timeout to 3 secs for sctp shutdown send and recv state
ASoC: rt5665: add missed regulator_bulk_disable
af_unix: Fix null-ptr-deref in unix_stream_sendpage().
net: fix the RTO timer retransmitting skb every 1ms if linear option is enabled
net: xfrm: Amend XFRMA_SEC_CTX nla_policy structure
net: phy: broadcom: stub c45 read/write for 54810
tracing: Fix memleak due to race between current_tracer and trace
sock: annotate data-races around prot->memory_pressure
igb: Avoid starting unnecessary workqueues
ipvs: Improve robustness to the ipvs sysctl
ipvs: fix racy memcpy in proc_do_sync_threshold
ibmveth: Use dcbf rather than dcbfl
batman-adv: Trigger events for auto adjusted MTU
batman-adv: Do not get eth header before batadv_check_management_packet
batman-adv: Fix TT global entry leak when client roamed back
batman-adv: Fix batadv_v_ogm_aggr_send memory leak
lib/clz_ctz.c: Fix __clzdi2() and __ctzdi2() for 32-bit kernels
media: vcodec: Fix potential array out-of-bounds in encoder queue_setup
x86/fpu: Set X86_FEATURE_OSXSAVE feature after enabling OSXSAVE in CR4
rtnetlink: Reject negative ifindexes in RTM_NEWLINK
scsi: snic: Fix double free in snic_tgt_create()
scsi: core: raid_class: Remove raid_component_add()
dma-buf/sw_sync: Avoid recursive lock during fence signal
Linux 4.14.324
Change-Id: I91a1deeaf4c37592b26abd9d9314eff77329c0f0
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Most of binder's memory allocations are tiny, and they're allocated
and freed extremely frequently. The latency from going through the page
allocator all the time for such small allocations ends up being quite
high, especially when the system is low on memory. Binder is
performance-critical, so this is suboptimal.
Instead of using kzalloc to allocate a struct every time, reserve caches
specifically for allocating each struct quickly.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
[ Tashar02: Fix compilation on k5.10 binder ]
Co-authored-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
