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>
commit 3c4f8333b5 upstream.
In commit 9b9c8195f3 ("tty: n_gsm: fix UAF in gsm_cleanup_mux"), the UAF
problem is not completely fixed. There is a race condition in
gsm_cleanup_mux(), which caused this UAF.
The UAF problem is triggered by the following race:
task[5046] task[5054]
----------------------- -----------------------
gsm_cleanup_mux();
dlci = gsm->dlci[0];
mutex_lock(&gsm->mutex);
gsm_cleanup_mux();
dlci = gsm->dlci[0]; //Didn't take the lock
gsm_dlci_release(gsm->dlci[i]);
gsm->dlci[i] = NULL;
mutex_unlock(&gsm->mutex);
mutex_lock(&gsm->mutex);
dlci->dead = true; //UAF
Fix it by assigning values after mutex_lock().
Bug: 291178675
Link: https://syzkaller.appspot.com/text?tag=CrashReport&x=176188b5a80000
Cc: stable <stable@kernel.org>
Fixes: 9b9c8195f3 ("tty: n_gsm: fix UAF in gsm_cleanup_mux")
Fixes: aa371e96f0 ("tty: n_gsm: fix restart handling via CLD command")
Signed-off-by: Yi Yang <yiyang13@huawei.com>
Co-developed-by: Qiumiao Zhang <zhangqiumiao1@huawei.com>
Signed-off-by: Qiumiao Zhang <zhangqiumiao1@huawei.com>
Link: https://lore.kernel.org/r/20230811031121.153237-1-yiyang13@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 31311a9a4b)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I460a0f21f4121531d7732e09643a451382dfa2da
When CONFIG_OF_ADDRESS is not set, there is a build warning/error
about an unused function.
Annotate the function to quieten the warning/error.
../drivers/iommu/of_iommu.c:176:29: warning: 'iommu_resv_region_get_type' defined but not used [-Wunused-function]
176 | static enum iommu_resv_type iommu_resv_region_get_type(struct device *dev, struct resource *phys,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Bug: 257546262
Fixes: a5bf3cfce8 ("iommu: Implement of_iommu_get_resv_regions()")
Change-Id: Ice815df046c06efa7351351e3886e925c27ca57f
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Will Deacon <will@kernel.org>
Cc: iommu@lists.linux.dev
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20230209010359.23831-1-rdunlap@infradead.org
[joro: Improve code formatting]
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 4762315d1c)
This adds the "iommu-addresses" property to reserved-memory nodes, which
allow describing the interaction of memory regions with IOMMUs. Two use-
cases are supported:
1. Static mappings can be described by pairing the "iommu-addresses"
property with a "reg" property. This is mostly useful for adopting
firmware-allocated buffers via identity mappings. One common use-
case where this is required is if early firmware or bootloaders
have set up a bootsplash framebuffer that a display controller is
actively scanning out from during the operating system boot
process.
2. If an "iommu-addresses" property exists without a "reg" property,
the reserved-memory node describes an IOVA reservation. Such memory
regions are excluded from the IOVA space available to operating
system drivers and can be used for regions that must not be used to
map arbitrary buffers.
Each mapping or reservation is tied to a specific device via a phandle
to the device's device tree node. This allows a reserved-memory region
to be reused across multiple devices.
Bug: 257546262
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Change-Id: I9cdd29d056896b9cbb9fdbbc0c6cbd824f1be78e
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20230120174251.4004100-3-thierry.reding@gmail.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit af0d81357c)
Add rockchip fragment and build.config for build symbol list and abi update.
Bug: 300024866
Change-Id: I05f9b2cdba8b558be68a3f93330cd072cd341d71
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Add initial symbol list for rockchip in android/abi_gki_aarch64_rockchip
Bug: 300024866
Change-Id: I4fd44b33141dfbdcd5b8d0d7c5d0fbc5aa2758cc
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Commit 95158a89dd ("sched,rt: Use the full cpumask for balancing")
allows find_lock_lowest_rq() to pick a task with migration disabled.
The purpose of the commit is to push the current running task on the
CPU that has the migrate_disable() task away.
However, there is a race which allows a migrate_disable() task to be
migrated. Consider:
CPU0 CPU1
push_rt_task
check is_migration_disabled(next_task)
task not running and
migration_disabled == 0
find_lock_lowest_rq(next_task, rq);
_double_lock_balance(this_rq, busiest);
raw_spin_rq_unlock(this_rq);
double_rq_lock(this_rq, busiest);
<<wait for busiest rq>>
<wakeup>
task become running
migrate_disable();
<context out>
deactivate_task(rq, next_task, 0);
set_task_cpu(next_task, lowest_rq->cpu);
WARN_ON_ONCE(is_migration_disabled(p));
Fixes: 95158a89dd ("sched,rt: Use the full cpumask for balancing")
Signed-off-by: Schspa Shi <schspa@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Reviewed-by: Valentin Schneider <vschneid@redhat.com>
Tested-by: Dwaine Gonyier <dgonyier@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bug: 300418678
(cherry picked from commit feffe5bb27)
[quic_dickey@quicinc.com: Port only]
Change-Id: I3e7953aeb3edf3f1a5d03e355297d7b1541ff7c8
Signed-off-by: Stephen Dickey <quic_dickey@quicinc.com>
create the ASUS symbol list of HID symbols for the USB HID Fan driver which requires them
6 function symbol(s) added
'int __hid_register_driver(struct hid_driver*, struct module*, const char*)'
'int hid_hw_raw_request(struct hid_device*, unsigned char, __u8*, size_t, enum hid_report_type, enum hid_class_request)'
'int hid_hw_start(struct hid_device*, unsigned int)'
'void hid_hw_stop(struct hid_device*)'
'int hid_open_report(struct hid_device*)'
'void hid_unregister_driver(struct hid_driver*)'
Bug: 300220786
Change-Id: I422c3b82754921c530e9afc32529a1dbf2f6c38e
Signed-off-by: Steve2 Yang <steve2_yang@asus.com>
Update whitelist for the symbols used by the unisoc device and
update the ABI representation accordingly.
1 function symbol(s) added
'int pvclock_gtod_register_notifier(struct notifier_block*)'
Bug: 300019103
Change-Id: Ice320a418069f24a27d14939a143ce01f50c0de8
Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
Add vendor hook to determine if the memory of a process
that received the SIGKILL can be reaped.
Partial cherry-pick of aosp/1724512 & aosp/2093626.
Bug: 232062955
Change-Id: I75072bd264df33caff67d083821ee6f33ca83af9
Signed-off-by: Tangquan Zheng <zhengtangquan@oppo.com>
Whitelist the below symbols that can be used to decide if overshooting
of kswapd reclaim is allowed.
Symbols added:
__traceiter_android_vh_scan_abort_check_wmarks
__tracepoint_android_vh_scan_abort_check_wmarks
Bug: 224956008
Change-Id: I185a570b345d2db0a1426075faa4d9c6325fb0e8
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Allow vendor hook to enable checking of the high water marks to
decide if reclaim should continue scanning.
Bug: 224956008
Change-Id: I63fe1fd386e7599451c2df0a04c8440b4fc142fc
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
When ufshcd_clk_scaling_suspend_work(Thread A) running and new command
coming, ufshcd_clk_scaling_start_busy(Thread B) may get host_lock
after Thread A first time release host_lock. Then Thread A second time
get host_lock will set clk_scaling.window_start_t = 0 which scale up
clock abnormal next polling_ms time.
Also inlines another __ufshcd_suspend_clkscaling calls.
Below is racing step:
1 hba->clk_scaling.suspend_work (Thread A)
ufshcd_clk_scaling_suspend_work
2 spin_lock_irqsave(hba->host->host_lock, irq_flags);
3 hba->clk_scaling.is_suspended = true;
4 spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
__ufshcd_suspend_clkscaling
7 spin_lock_irqsave(hba->host->host_lock, flags);
8 hba->clk_scaling.window_start_t = 0;
9 spin_unlock_irqrestore(hba->host->host_lock, flags);
ufshcd_send_command (Thread B)
ufshcd_clk_scaling_start_busy
5 spin_lock_irqsave(hba->host->host_lock, flags);
....
6 spin_unlock_irqrestore(hba->host->host_lock, flags);
Bug: 298004596
Link: https://lore.kernel.org/all/20230831130826.5592-3-peter.wang@mediatek.com/
Change-Id: Ib208b1265107769005c4ae3f72d46b12c072b5c7
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
When no active_reqs, devfreq_monitor(Thread A) will suspend clock scaling.
But it may have racing with clk_scaling.suspend_work(Thread B) and
actually not suspend clock scaling(requue after suspend).
Next time after polling_ms, devfreq_monitor read
clk_scaling.window_start_t = 0 then scale up clock abnormal.
Below is racing step:
devfreq->work (Thread A)
devfreq_monitor
update_devfreq
.....
ufshcd_devfreq_target
queue_work(hba->clk_scaling.workq,
1 &hba->clk_scaling.suspend_work)
.....
5 queue_delayed_work(devfreq_wq, &devfreq->work,
msecs_to_jiffies(devfreq->profile->polling_ms));
2 hba->clk_scaling.suspend_work (Thread B)
ufshcd_clk_scaling_suspend_work
__ufshcd_suspend_clkscaling
devfreq_suspend_device(hba->devfreq);
3 cancel_delayed_work_sync(&devfreq->work);
4 hba->clk_scaling.window_start_t = 0;
.....
Bug: 298004596
Link: https://lore.kernel.org/all/20230831130826.5592-4-peter.wang@mediatek.com/
Change-Id: I3ea77255f1b3845e9dd7bf6b050f3e9ba1f5f3f2
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Regenerate ABU definition file to resolve ABI breakage caused by a
private struct zs_pool:
INFO: ABI DIFFERENCES HAVE BEEN DETECTED!
INFO: type 'struct zs_pool' changed
member 'atomic_t compaction_in_progress' was added
Bug: 296365608
Change-Id: I477b6dbbdaf464b2fdf3e666b9696f1a79095a63
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
zsmalloc pool can be compacted concurrently by many contexts,
e.g.
cc1 handle_mm_fault()
do_anonymous_page()
__alloc_pages_slowpath()
try_to_free_pages()
do_try_to_free_pages(
lru_gen_shrink_node()
shrink_slab()
do_shrink_slab()
zs_shrinker_scan()
zs_compact()
Pool compaction is currently (basically) single-threaded as
it is performed under pool->lock. Having multiple compaction
threads results in unnecessary contention, as each thread
competes for pool->lock. This, in turn, affects all zsmalloc
operations such as zs_malloc(), zs_map_object(), zs_free(), etc.
Introduce the pool->compaction_in_progress atomic variable,
which ensures that only one compaction context can run at a
time. This reduces overall pool->lock contention in (corner)
cases when many contexts attempt to shrink zspool simultaneously.
Link: https://lkml.kernel.org/r/20230418074639.1903197-1-senozhatsky@chromium.org
Fixes: c0547d0b6a ("zsmalloc: consolidate zs_pool's migrate_lock and size_class's locks")
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Yosry Ahmed <yosryahmed@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit cb440cecb2)
Bug: 296365608
Change-Id: Ic7878e08c3484ade8c766d051a8f17cc8179eedf
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Update whitelist for the symbols used by qcom socs in
abi_gki_aarch64_qcom.
1 function symbol(s) added
'vhost_dev_flush'
Bug: 299585715
Change-Id: I403394331953c9cfee54b4b0c2a0365a3df5f0af
Signed-off-by: Prathu Baronia <quic_pbaronia@quicinc.com>
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
When sending Discover Identity messages to a Port Partner that uses Power
Delivery v2 and SVDM v1, we currently send PD v2 messages with SVDM v2.0,
expecting the port partner to respond with its highest supported SVDM
version as stated in Section 6.4.4.2.3 in the Power Delivery v3
specification. However, sending SVDM v2 to some Power Delivery v2 port
partners results in a NAK whereas sending SVDM v1 does not.
NAK messages can be handled by the initiator (PD v3 section 6.4.4.2.5.1),
and one solution could be to resend Discover Identity on a lower SVDM
version if possible. But, Section 6.4.4.3 of PD v2 states that "A NAK
response Should be taken as an indication not to retry that particular
Command."
Instead, we can set the SVDM version to the maximum one supported by the
negotiated PD revision. When operating in PD v2, this obeys Section
6.4.4.2.3, which states the SVDM field "Shall be set to zero to indicate
Version 1.0." In PD v3, the SVDM field "Shall be set to 01b to indicate
Version 2.0."
Fixes: c34e85fa69 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230731165926.1815338-1-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 289437937
(cherry picked from commit c97cd0b4b5)
Signed-off-by: RD Babiera <rdbabiera@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:d02aef1ae51a03b9ab20c8e01ed32593a7ffc6fc)
Merged-In: Ie919c29bab68cb08cb659471ff6106bae502c8dd
Change-Id: Ie919c29bab68cb08cb659471ff6106bae502c8dd
Share/unshare initiated by host doesn't change memory permission, and
as currently pKVM doesn't support device assignment, there is no need
to update the IOMMU unnecessarily as it waste cycles.
Once device assignment is enabled, this assumption will not be valid
as guests have access to DMA.
Bug: 291843613
Change-Id: I28c69ec8f721711d5b59fa2784386fa61654fe5a
Signed-off-by: Mostafa Saleh <smostafa@google.com>
There are some corner cases where we do worse in power because the
threshold is too low. Until these cases are better understood and
addressed upstream, provide a function for vendors to override this
value with something more suitable in their modules.
Bug: 289293494
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I95dd36718a317f3fcb2a9f4bc87dd3390a4f7d7d
Vendor may have need to track rt util.
Bug: 201261299
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I2f4e5142c6bc8574ee3558042e1fb0dae13b702d
