Allocate and map hyp memory to maintain the host's fp/simd state,
which is also used for SVE and SME, later in the initialization
process. The amount of memory needed to track the host's state
varies depending on the number of cpus in the system, whether
there's SVE support, as well as the SVE vector size. Much of the
state needed to extract this information isn't initialized yet at
kvm_hyp_reserve().
Fixes: 6dc9af85f7 ("ANDROID: KVM: arm64: Allocate host fp state at pkvm init rather than per cpu")
Bug: 303684934
Signed-off-by: Fuad Tabba <tabba@google.com>
Change-Id: I744be685a107ddd92c6975bafb0149aebad7bb55
[ Upstream commit f15f29fd47 ]
Chain binding only requires the rule addition/insertion command within
the same transaction. Removal of rules from chain bindings within the
same transaction makes no sense, userspace does not utilize this
feature. Replace nft_chain_is_bound() check to nft_chain_binding() in
rule deletion commands. Replace command implies a rule deletion, reject
this command too.
Rule flush command can also safely rely on this nft_chain_binding()
check because unbound chains are not allowed since 62e1e94b24
("netfilter: nf_tables: reject unbound chain set before commit phase").
Bug: 302085977
Fixes: d0e2c7de92 ("netfilter: nf_tables: add NFT_CHAIN_BINDING")
Reported-by: Kevin Rich <kevinrich1337@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 9af8bb2afe)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I8b05dc37062824db4c2901000fdf701b38605d32
Adding the following symbols:
- kmemdup_nul
Bug: 304675894
Change-Id: Ib6ab20a2c034d3e8dc9aff7384876d10468cd15b
Signed-off-by: David Chiang <davidchiang@google.com>
While backporting, a check for vma locking inside do_wp_page() was
missed. Add it.
Fixes: 3ebafb7b46 ("BACKPORT: FROMGIT: mm: handle faults that merely update the accessed bit under the VMA lock")
Bug: 293665307
Change-Id: Ibd7f21ae8fec7b8edc6e3d88954714b5fad41516
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
After commit f5d39b0208 ("freezer,sched: Rewrite core freezer logic"),
tasks that transition directly from TASK_FREEZABLE to TASK_FROZEN are
always woken up on the thaw path. Prior to that commit, tasks could ask
freezer to consider them "frozen enough" via freezer_do_not_count(). The
commit replaced freezer_do_not_count() with a TASK_FREEZABLE state which
allows freezer to immediately mark the task as TASK_FROZEN without
waking up the task. This is efficient for the suspend path, but on the
thaw path, the task is always woken up even if the task didn't need to
wake up and goes back to its TASK_(UN)INTERRUPTIBLE state. Although
these tasks are capable of handling of the wakeup, we can observe a
power/perf impact from the extra wakeup.
We observed on Android many tasks wait in the TASK_FREEZABLE state
(particularly due to many of them being binder clients). We observed
nearly 4x the number of tasks and a corresponding linear increase in
latency and power consumption when thawing the system. The latency
increased from ~15ms to ~50ms.
Avoid the spurious wakeups by saving the state of TASK_FREEZABLE tasks.
If the task was running before entering TASK_FROZEN state
(__refrigerator()) or if the task received a wake up for the saved
state, then the task is woken on thaw. saved_state from PREEMPT_RT locks
can be re-used because freezer would not stomp on the rtlock wait flow:
TASK_RTLOCK_WAIT isn't considered freezable.
Reported-by: Prakash Viswalingam <quic_prakashv@quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 8f0eed4a78a81668bc78923ea09f51a7a663c2b0)
(cherry picked from commit e4d93065a5085dbb862aa4bd06fb3e51b02e8857
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core)
Bug: 292064955
Change-Id: I121cfff46536a13e59b5eb60842984aed0d73faa
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
In preparation for freezer to also use saved_state, remove the
CONFIG_PREEMPT_RT compilation guard around saved_state.
On the arm64 platform I tested which did not have CONFIG_PREEMPT_RT,
there was no statistically significant deviation by applying this patch.
Test methodology:
perf bench sched message -g 40 -l 40
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit fa14aa2c23d31eb39bc615feb920f28d32d2a87e
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core)
Bug: 292064955
Change-Id: I9c11ab7ce31ba3b48b304229898d4c7c18a6cb2c
[eberman: Use KABI reservation to preserve CRC/ABI of struct task_struct and
preserved raw_spin_(un)lock instead of new guard(...) syntax in task_state_match]
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Set the block size to that specified in on-disk superblock.
Also remove the hard constraint of PAGE_SIZE block size for the
uncompressed device backend. This constraint is temporarily remained
for compressed device and fscache backend, as there is more work needed
to handle the condition where the block size is not equal to PAGE_SIZE.
It is worth noting that the on-disk block size is read prior to
erofs_superblock_csum_verify(), as the read block size is needed in the
latter.
Besides, later we are going to make erofs refer to tar data blobs (which
is 512-byte aligned) for OCI containers, where the block size is 512
bytes. In this case, the 512-byte block size may not be adequate for a
directory to contain enough dirents. To fix this, we are also going to
introduce directory block size independent on the block size.
Due to we have already supported block size smaller than PAGE_SIZE now,
disable all these images with such separated directory block size until
we supported this feature later.
Bug: 303691233
Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Yue Hu <huyue2@coolpad.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Link: https://lore.kernel.org/r/20230313135309.75269-3-jefflexu@linux.alibaba.com
[ Gao Xiang: update documentation. ]
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
(cherry picked from commit d3c4bdcc75)
[dhavale: resolved minor conflict in Documentation/filesystems/erofs.rst]
Signed-off-by: Sandeep Dhavale <dhavale@google.com>
Change-Id: I9a46bfb7ec9f79751e0df8f9d6369192dc861736
As the first step of converting hardcoded blocksize to that specified in
on-disk superblock, convert all call sites of hardcoded blocksize to
sb->s_blocksize except for:
1) use sbi->blkszbits instead of sb->s_blocksize in
erofs_superblock_csum_verify() since sb->s_blocksize has not been
updated with the on-disk blocksize yet when the function is called.
2) use inode->i_blkbits instead of sb->s_blocksize in erofs_bread(),
since the inode operated on may be an anonymous inode in fscache mode.
Currently the anonymous inode is allocated from an anonymous mount
maintained in erofs, while in the near future we may allocate anonymous
inodes from a generic API directly and thus have no access to the
anonymous inode's i_sb. Thus we keep the block size in i_blkbits for
anonymous inodes in fscache mode.
Be noted that this patch only gets rid of the hardcoded blocksize, in
preparation for actually setting the on-disk block size in the following
patch. The hard limit of constraining the block size to PAGE_SIZE still
exists until the next patch.
Bug: 303691233
Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Yue Hu <huyue2@coolpad.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Link: https://lore.kernel.org/r/20230313135309.75269-2-jefflexu@linux.alibaba.com
[ Gao Xiang: fold a patch to fix incorrect truncated offsets. ]
Link: https://lore.kernel.org/r/20230413035734.15457-1-zhujia.zj@bytedance.com
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
(cherry picked from commit 3acea5fc33)
[dhavale: resolved few conflicts due to missing other features]
Signed-off-by: Sandeep Dhavale <dhavale@google.com>
Change-Id: I4751529e42e4a646b1a2dda75981cdc41b39b6d4
Adding the following symbols:
- reserve_iova
Bug: 303000855
Change-Id: I84b0eeb179b4194d0d8294b789f2cecc388f0963
Signed-off-by: Junghoon Jang <junghoonjang@google.com>
To monitor the reclaiming ability of kswapd, add vendor hook recording when the kswapd finish the reclaiming job and the reclaim progress.
android_vh_vmscan_kswpad_done(int, unsigned int, unsigned int, unsigned int)
Bug: 301044280
Change-Id: Id6e0a97003f0a156cff4d0996bc38bcd89b1dc69
Signed-off-by: John Hsu <john.hsu@mediatek.com>
To monitor the efficiency of memory relciaming in __alloc_pages_slowpath, add vendor hooks in each stages of __alloc_pages_slowpath including __alloc_pages_may_oom and __alloc_pages_direct_reclaim.
android_vh_mm_alloc_pages_direct_reclaim_enter()
android_vh_mm_alloc_pages_direct_reclaim_exit(unsigned long, int)
android_vh_mm_alloc_pages_may_oom_exit(struct oom_control *, unsigned long)
Bug: 301044280
Change-Id: Ic5b5f1c2ad31b16e7339f539fcf54659e9acaba7
Signed-off-by: John Hsu <john.hsu@mediatek.com>
To monitor the efficiency of each action about compaction.
Add the vendor_hook function and call it in kcompactd_do_work() and
try_to_compact_pages()
ANDROID vendor hook
android_vh_compaction_exit(int, int, const int)
android_vh_compaction_try_to_compact_pages_exit(enum *compact result)
Bug: 301044280
Change-Id: I4c3f94e77eb2b16ba154ba88a9f75095536de916
Signed-off-by: John Hsu <john.hsu@mediatek.com>
Some usb hubs will negotiate DisplayPort Alt mode with the device
but will then negotiate a data role swap after entering the alt
mode. The data role swap causes the device to unregister all alt
modes, however the usb hub will still send Attention messages
even after failing to reregister the Alt Mode. type_altmode_attention
currently does not verify whether or not a device's altmode partner
exists, which results in a NULL pointer error when dereferencing
the typec_altmode and typec_altmode_ops belonging to the altmode
partner.
Verify the presence of a device's altmode partner before sending
the Attention message to the Alt Mode driver.
Fixes: 8a37d87d72 ("usb: typec: Bus type for alternate modes")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230814180559.923475-1-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 288952921
(cherry picked from commit f236433064)
[rd: changed return type of typec_altmode_attention to void to not break
kmi, moved tcpm_log from error return to typec_altmode_attention as
dev_warn]
Signed-off-by: RD Babiera <rdbabiera@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:e23c89c0b76305f9f264ba113d647710b956a540)
Merged-In: I054a6ef56b9b2d7c4e8167e8630a8c277910da88
Change-Id: I054a6ef56b9b2d7c4e8167e8630a8c277910da88
smaps_pte_hole_lookup() is calling shmem_partial_swap_usage() with page
table lock held: but shmem_partial_swap_usage() does cond_resched_rcu() if
need_resched(): "BUG: sleeping function called from invalid context".
Since shmem_partial_swap_usage() is designed to count across a range, but
smaps_pte_hole_lookup() only calls it for a single page slot, just break
out of the loop on the last or only page, before checking need_resched().
Bug: 302977171
Link: https://lkml.kernel.org/r/6fe3b3ec-abdf-332f-5c23-6a3b3a3b11a9@google.com
(cherry picked from commit e5548f85b4)
Fixes: 2301003215 ("mm/smaps: simplify shmem handling of pte holes")
Change-Id: I1b59341c954cb7eb31709ba0dcc65ec6e67c58c6
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Peter Xu <peterx@redhat.com>
Cc: <stable@vger.kernel.org> [5.16+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Since commit a78418e6a0 ("block: Always initialize bio IO priority on
submit"), bio->bi_ioprio will never be IOPRIO_CLASS_NONE when calling
blkcg_set_ioprio(), so there will be no way to promote the io-priority
of one cgroup to IOPRIO_CLASS_RT, because bi_ioprio will always be
greater than or equals to IOPRIO_CLASS_RT.
It seems possible to call blkcg_set_ioprio() first then try to
initialize bi_ioprio later in bio_set_ioprio(), but this doesn't work
for bio in which bi_ioprio is already initialized (e.g., direct-io), so
introduce a new promote-to-rt policy to promote the iopriority of bio to
IOPRIO_CLASS_RT if the ioprio is not already RT.
For none-to-rt policy, although it doesn't work now, but considering
that its purpose was also to override the io-priority to RT and allowing
for a smoother transition, just keep it and treat it as an alias of
the promote-to-rt policy.
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Change-Id: I1f511e8dca604fdb3249562ea73adb69b93a8aec
Signed-off-by: Hou Tao <houtao1@huawei.com>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Link: https://lore.kernel.org/r/20230428074404.280532-1-houtao@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit ddf63516d8)
Bug: 186902601
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Prepare for supporting I/O priority in the storage stack.
Bug: 186902601
Change-Id: I387ac4792c89d88d131c5146b116a0393c01b096
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Crosvm thread can get interrupted while making a call to the Resource
Manager. If we wait on mutext_lock_interruptible, the RM call might be
incomplete and as part of the cleanup if there are further RM calls that
need to be made, they will also return without making the RM call
because there is a signal on the thread. Use mutex_lock while making the
RM calls to ensure the RM call completes and only if there is a geniune
error, we can clean up.
Bug: 302322730
Change-Id: I961aa917588a72bb8733e6f80d80f3ceed179076
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Since commit 4e57a4ddf6 ("ARM: 9107/1: syscall: always store
thread_info->abi_syscall"), the seccomp selftests "syscall_errno"
and "syscall_faked" have been broken. Both seccomp and PTRACE depend
on using the special value of "-1" for skipping syscalls. This value
wasn't working because it was getting masked by __NR_SYSCALL_MASK in
both PTRACE_SET_SYSCALL and get_syscall_nr().
Explicitly test for -1 in PTRACE_SET_SYSCALL and get_syscall_nr(),
leaving it exposed when present, allowing tracers to skip syscalls
again.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org
Fixes: 4e57a4ddf6 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall")
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230810195422.2304827-2-keescook@chromium.org
Change-Id: I5b13c06a9cca85d13beec809a695198a7696df45
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 4697b5848b)
Bug: 289991100
Signed-off-by: Edward Liaw <edliaw@google.com>
This reverts commit 251aa28d16.
Reason for revert: b/301670242
The connect_lock mutex is not being released in error path. This patch was reverted upstream.
Signed-off-by: Neill Kapron <nkapron@google.com>
Change-Id: I802a9a8afc9f23b1bf91fa4df4bfb5d207373b04
They don't have device-specific modules. They are just generic configs
that are different from GKI.
Bug: 301852599
Test: run following commands
tools/bazel run //common:kernel_aarch64_microdroid_dist
tools/bazel run //common:kernel_x86_64_microdroid_dist
tools/bazel run //common:kernel_aarch64_microdroid_config -- menuconfig
tools/bazel run //common:kernel_x86_64_microdroid_config -- menuconfig
tools/bazel run //common:kernel_aarch64_crashdump_dist
tools/bazel run //common:kernel_x86_64_crashdump_dist
tools/bazel run //common:kernel_aarch64_crashdump_config -- menuconfig
tools/bazel run //common:kernel_x86_64_crashdump_config -- menuconfig
Change-Id: I8908a7499451ace0740979b694eb5fcc68398c61
Signed-off-by: Jiyong Park <jiyong@google.com>
Recently we have discovered many lag issues caused by percpu_rwsem
lock-holding tasks not being scheduled for a long time. we need to
identify them and provide appropriate scheduling protection in our
oem scheduler.
To support this, we add one hook below:
trace_android_vh_percpu_rwsem_wq_add
Bug: 301066838
Change-Id: Id770c1a7978842abfc62d3fa9aeb5ac7a1904972
Signed-off-by: xieliujie <xieliujie@oppo.com>
Add hooks to support oem's binder feature of improving binder_thread->task sched priority
1) Check if it is a specific task in trace_android_vh_binder_transaction_buffer() and store the flag to t->android_vendor_data1
2) If it is a specific binder task and binder_thread selected, raise the sched priority of binder_thread->task in runqueue.
3) If it is a specific binder task but no binder_thread selected (e.g pending_async or no free threads), insert t->work to the appropriate position in the list.
4) Reset the sched priority when BR_TRANSACTION or BC_FREE_BUFFER.
Some high-priority async binder task reset the sched priority when BC_FREE_BUFFER in trace_android_vh_binder_free_buf().
Some middle-priority async binder task reset the sched priority when driver return server "BR_TRANSACTION" in trace_android_vh_binder_transaction_received().
Bug: 299328919
Change-Id: Iab4939fe4a4881b31961aaa2fef500b51c944743
Signed-off-by: lfc <lfc@oppo.com>
Update_io_stats_uid_locked would take a long lock-time of uid_lock due to
call do_each_thread to compute uid_entry->io, which would cause to lock
competition sometime.
Using uid_entry_tmp to get the result of update_io_stats_uid, so that we
can unlock_uid during update_io_stats_uid, in order to avoid the
unnecessary lock-time of uid_lock.
Bug: 278138377
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
(cherry picked from https://android-review.googlesource.com/q/commit:c1fa53f3cf85c0a1c23f0e0a944986b4aa049073)
Merged-In: I5be62105e57e2a896a95d906e3c14e17c7f8077d
Change-Id: I5be62105e57e2a896a95d906e3c14e17c7f8077d
locks for each hlist in hash_table.
1.Hash_table in uid_sys_stat is protected by a global lock named id_lock,
which causes some lock competition issue. Actually, uid_lock can be split to
several file-grained locks for each hlist in hash_table, which avoid
the unnecessary lock competition when get different-uid process info.
2. Switching rt-mutex to spinlock, in order to operate with read_rcu_lock.
Bug: 278138377
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
(cherry picked from https://android-review.googlesource.com/q/commit:c949fbdce0bc792dea206c709d909094be579c3a)
Merged-In: Ib252b65e9aebe3a594e6edf075f7aa01f8e6105d
Change-Id: Ib252b65e9aebe3a594e6edf075f7aa01f8e6105d
Some IOMMU devices might be deferred after the driver being
loaded early, so we need to flush the deferred probe list,
this will work if all dependencies already exist.
Bug: 290582379
Change-Id: I5fb3af9b0f7d1b4dbf57078707112dfdb8a3dc23
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Commit d096d35445 ("ANDROID: KVM: arm64: Have different callbacks for
PTE manipulation") accidentally forces the use of pte-level mappings for
the guest stage-2 page-table when not using pKVM.
This confuses user_mem_abort() when the guest takes a permission fault
trying to execute from a huge page. Since the fault is reported at the
pte-level, we end up handling it as a translation fault by calling
kvm_pgtable_stage2_map() which dutifully returns -EAGAIN when it finds
the RW PTE. Consequently, the guest appears to hang randomly during boot.
Fix the issue by inverting stage2_force_pte_cb() so that the host is in
complete control of the mapping granularity of the guest when pKVM is
not being used.
Cc: Fuad Tabba <tabba@google.com>
Cc: Mostafa Saleh <smostafa@google.com>
Fixes: d096d35445 ("ANDROID: KVM: arm64: Have different callbacks for PTE manipulation")
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 222044487
Change-Id: Ideab281ae6d1d5c0fd29fba03ad8ed1cae521a1e
If gs_close has cleared port->port.tty and gs_start_io is called
afterwards, then the function tty_wakeup will attempt to access the value
of the pointer port->port.tty which will cause a null pointer
dereference error.
To avoid this, add a null pointer check to gs_start_io before attempting
to access the value of the pointer port->port.tty.
Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
Message-ID: <20230602070009.1353946-1-khtsai@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 283247551
(cherry picked from commit ffd603f214)
Change-Id: I782ef328b0d49810d3fb23c002a86439e6728542
Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
(cherry picked from commit ca0cd37761)
With the introduction of task_struct::saved_state in commit
5f220be214 ("sched/wakeup: Prepare for RT sleeping spin/rwlocks")
matching the task state has gotten more complicated. That same commit
changed try_to_wake_up() to consider both states, but
wait_task_inactive() has been neglected.
Sebastian noted that the wait_task_inactive() usage in
ptrace_check_attach() can misbehave when ptrace_stop() is blocked on
the tasklist_lock after it sets TASK_TRACED.
Therefore extract a common helper from ttwu_state_match() and use that
to teach wait_task_inactive() about the PREEMPT_RT locks.
Originally-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20230601091234.GW83892@hirez.programming.kicks-ass.net
(cherry picked from commit 1c06918788)
Bug: 292064955
Change-Id: I2cc02dfdf3c04be146078f80d09c3a87979d79a6
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
While modifying wait_task_inactive() for PREEMPT_RT; the build robot
noted that UP got broken. This led to audit and consideration of the
UP implementation of wait_task_inactive().
It looks like the UP implementation is also broken for PREEMPT;
consider task_current_syscall() getting preempted between the two
calls to wait_task_inactive().
Therefore move the wait_task_inactive() implementation out of
CONFIG_SMP and unconditionally use it.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230602103731.GA630648%40hirez.programming.kicks-ass.net
(cherry picked from commit d5e1586617)
Bug: 292064955
Change-Id: Ief91cf48c27533fee47d5bd049c8a9be4010e6f6
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
