This reverts commit 3a7f9f00f0.
Some module driver need to know current cpufreq change status
to profile cpu operation.
Bug: 280531400
Change-Id: Ibd7fa6c7e04695d2efc39775767b77b522ba6c06
Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com>
In one of the SMMU faults (NULL Pointer derefernce) the following
race condition was observed and func->interfaces_nums was being
accessed for f_fs interface after it was unbinded resulting in a
crash.
Thread-1 Thread-2
ffs_func_req_match+0x68/0xc8
drain_workqueue+0xac
gsi_unbind[usb_f_gsi]+0x64
purge_configs_funcs+0xb4
configfs_composite_unbind+0xac
usb_gadget_remove_driver+0xac
usb_gadget_unregister_driver+0xd8
gadget_dev_desc_UDC_store+0x114
android_setup+0x164/0x2a8
dwc3_ep0_inspect_setup+0x100/0x440
dwc3_ep0_interrupt+0xac/0x300
dwc3_process_event_entry+0x80/0x724
dwc3_process_event_buf+0x80/0x434
dwc3_thread_interrupt+0x60/0x124
irq_thread_fn+0x54/0xe4
irq_thread+0x3a4/0x6ec
kthread+0x188/0x1ec
ret_from_fork+0x10/0x20
The events happened in order are as follows:
We got a setup packet for ffs interface and was passed to android
setup callback from ep0.c. As part of the delegate request, the
dwc->lock is released.
At this instant a composition switch occurred and as per traces
and crash dumps:
1. UDC Stop was done successfully. So run stop is set to '0'
2. Composite disconnect was done and ep disable for all ep's is done
gadget->connected = FALSE
3. Async callbacks disabled
dwc->aysnc_callbacks = FALSE
4. composite unbind is going on and the ffs interface in question is
unbinded
udc->driver != NULL
(as per crash dump indicating that unbind is in progress)
5. Purge configs was ongoing because as per crash dumps:
otg_desc[0] = NULL;
cdev->os_desc_req->buf is not NULL
(configfs_composite_unbind is going on, but composite_dev_cleanup
not yet done)
As per the traces:
23.794712: dwc3_event event=49216 ep0state=1 str=
23.794909: dwc3_ctrl_req bRequestType=161 bRequest=1 wValue=0
wIndex=2 wLength=4096
23.799740: usb_gadget_disconnect speed=5 max_speed=6 state=7
mA=0 deactivated=0 connected=0 ret=0
This indicated that android setup came first followed by composite
disconnect. Since the dwc->lock was released by delegate_request,
soft disconnect gets unblocked and runs parallel to composite setup.
After this, there is no check in path of composite setup
indicating unbind happened and bail out is necessary instead of
executing any function ops.
Protect composite_setup (as part of android_setup) in a spinlock
to block composite_disconnect/unbind running in parallel.
Moreover, in the configfs counterpart of android_setup (configfs_
composite_stetup), the composite_setup call is done with spinlock
held.
It is only the android_setup missing this lock.
Bug: 280548269
Fixes: 7a160e2b96 ("ANDROID: usb: gadget: configfs: Add Uevent to notify userspace")
Change-Id: Id245e9f72801541689fcb185ba0459824bfb3904
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
(cherry picked from commit 9ad803f257a8eb50a52c19a4cf33690cf1b85575)
cfg80211 & mac80211 are being converted to vendor modules.
To be consistent for both arm64 & x86_64 remove them
from protected to unprotected; so they can be converted
to vendor modules for x86_64 as well.
This also helps keep things simpler for virtual_device;
so it doesn't have to maintain seperate list for these
architectures w.r.t. these modules.
Bug: 281137343
Test: TH
Change-Id: Ica028593f30528c361a6ab30da8cb5be5187d067
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Add ramjiyani@ as per-file owner for:
android/abi_gki_protected_exports_*
android/gki_aarch64_protected_modules
android/gki_x86_64_protected_modules
Update required due to addition of multi arch support
caused renaming of these files with arch name in them.
Bug: 151893768
Test: TH
Change-Id: Ice5c054f90b3fc4f91bfe73f680082dc129c0310
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
In binder_transaction_buffer_release() the 'failed_at' offset indicates
the number of objects to clean up. However, this function was changed by
commit 44d8047f1d ("binder: use standard functions to allocate fds"),
to release all the objects in the buffer when 'failed_at' is zero.
This introduced an issue when a transaction buffer is released without
any objects having been processed so far. In this case, 'failed_at' is
indeed zero yet it is misinterpreted as releasing the entire buffer.
This leads to use-after-free errors where nodes are incorrectly freed
and subsequently accessed. Such is the case in the following KASAN
report:
==================================================================
BUG: KASAN: slab-use-after-free in binder_thread_read+0xc40/0x1f30
Read of size 8 at addr ffff4faf037cfc58 by task poc/474
CPU: 6 PID: 474 Comm: poc Not tainted 6.3.0-12570-g7df047b3f0aa #5
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x94/0xec
show_stack+0x18/0x24
dump_stack_lvl+0x48/0x60
print_report+0xf8/0x5b8
kasan_report+0xb8/0xfc
__asan_load8+0x9c/0xb8
binder_thread_read+0xc40/0x1f30
binder_ioctl+0xd9c/0x1768
__arm64_sys_ioctl+0xd4/0x118
invoke_syscall+0x60/0x188
[...]
Allocated by task 474:
kasan_save_stack+0x3c/0x64
kasan_set_track+0x2c/0x40
kasan_save_alloc_info+0x24/0x34
__kasan_kmalloc+0xb8/0xbc
kmalloc_trace+0x48/0x5c
binder_new_node+0x3c/0x3a4
binder_transaction+0x2b58/0x36f0
binder_thread_write+0x8e0/0x1b78
binder_ioctl+0x14a0/0x1768
__arm64_sys_ioctl+0xd4/0x118
invoke_syscall+0x60/0x188
[...]
Freed by task 475:
kasan_save_stack+0x3c/0x64
kasan_set_track+0x2c/0x40
kasan_save_free_info+0x38/0x5c
__kasan_slab_free+0xe8/0x154
__kmem_cache_free+0x128/0x2bc
kfree+0x58/0x70
binder_dec_node_tmpref+0x178/0x1fc
binder_transaction_buffer_release+0x430/0x628
binder_transaction+0x1954/0x36f0
binder_thread_write+0x8e0/0x1b78
binder_ioctl+0x14a0/0x1768
__arm64_sys_ioctl+0xd4/0x118
invoke_syscall+0x60/0x188
[...]
==================================================================
In order to avoid these issues, let's always calculate the intended
'failed_at' offset beforehand. This is renamed and wrapped in a helper
function to make it clear and convenient.
Fixes: 32e9f56a96 ("binder: don't detect sender/target during buffer cleanup")
Reported-by: Zi Fan Tan <zifantan@google.com>
Link: https://b.corp.google.com/issues/275041864
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 275041864
Link: https://lore.kernel.org/all/20230505203020.4101154-1-cmllamas@google.com
Change-Id: I4bcc8bde77a8118872237d100cccb5caf95d99a1
Signed-off-by: Carlos Llamas <cmllamas@google.com>
trace_android_vh_binder_proc_transaction_entry:
We need change binder thread so that this work can be added in
proc->todo, if we found the binder thread, skip native logic.
trace_android_vh_binder_select_worklist_ilocked:
we need this because we can't change list point in ”trace_android_vh_binder_thread_read“,
otherwise, If a work has beed added in our own defined list before,
current may goto retry and loop again and again.
Bug: 219898723
Change-Id: Ifdb3429c9ddac521bc75c1d21740ee7cc4b8f143
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
(cherry picked from commit acefa91e51)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
(cherry picked from commit d26c0e1c409179ea74aaa89f748006bd76000cc3)
We want to add some hooks in the binder module so that we can reduce
block time until binder thread is available
Here are what new hooks do for:
1、android_vh_binder_looper_state_registered: choose a binder thread(do proc work) as a low-level thread.Only this thread has power to excute background binder transaction.
2、android_vh_binder_thread_read: let binder thread do works which come from
our list.
3、android_vh_binder_free_proc: free some pointers and variable.
4、android_vh_binder_thread_release: free the list that we create before.
5、android_vh_binder_has_work_ilocked: to check if our list has work.
6、android_vh_binder_read_done: because of we add hook in binder_has_work_ilocked,
7、android_vh_binder_preset: mark target proc's binder threads.
binder_has_work_ilocked may return true, so we try to wake up low-level thread immediately.
Bug: 212483521
Change-Id: Ic40f452cc4dcf8fc85422e23e6f1a7ad77547309
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
(cherry picked from commit 8d6074509e4ec7e10acf6ee78277ff8cd19e49d0)
Add hooks to apply oem's optimization of rwsem and mutex
Bug: 182237112
Signed-off-by: xieliujie <xieliujie@oppo.com>
(cherry picked from commit 80b4341d05)
Signed-off-by: xieliujie <xieliujie@oppo.com>
Change-Id: I36895c432e5b6d6bff8781b4a7872badb693284c
Signed-off-by: Carlos Llamas <cmllamas@google.com>
[cmllamas: completes the cherry-pick of original commit 80b4341d05
since commit 0902cc73b793 was only partial]
(cherry picked from commit d4528a28cb5be0c322031f333a6230fa3042931f)
We need pointers to proc and t, the current hooks in binder_proc_transaction
are unable to use.
Bug: 208910215
Change-Id: I730964f965a015e5f5a3e237d9b3bd084b5bd0d0
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
(cherry picked from commit cb7e10d31b)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
(cherry picked from commit 8968875ad63f4cda9f263e2a2a930524dd8fdbc7)
These hooks help us do the following things:
a) Record the number of mutex and rwsem optimistic spin.
b) Monitor the time of mutex and rwsem optimistic spin.
c) Make it possible if oems don't want mutex and rwsem to optimistic spin
for a long time.
Bug: 267565260
Change-Id: I2bee30fb17946be85e026213b481aeaeaee2459f
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
(cherry picked from commit d01f7e1269)
(cherry picked from commit 05b5ff11ad98c5896b352b4c376a84b63684e06c)
Providing vendor hooks to record the start time of holding the lock, which
protects rwsem/mutex locking-process from being preemptedfor a short time
in some cases.
- android_vh_record_mutex_lock_starttime
- android_vh_record_rtmutex_lock_starttime
- android_vh_record_rwsem_lock_starttime
- android_vh_record_pcpu_rwsem_starttime
Bug: 241191475
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
Change-Id: I0e967a1e8b77c32a1ad588acd54028fae2f90c4e
(cherry picked from commit f7294947672eb6b786f3c16b49e71e6a239101ad)
Some boards need more than the default maximum of 4 uarts. This has no
impact unless 8250.nr_uarts is specified on the cmdline to increase
the number of runtime uarts from the GKI default of 0.
Bug: 280015873
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: I5ba4e1dcce4f4e01b7d306fa3ab05319768eef00
Current 500ms min window size for psi triggers limits polling interval
to 50ms to prevent polling threads from using too much cpu bandwidth by
polling too frequently. However the number of cgroups with triggers is
unlimited, so this protection can be defeated by creating multiple
cgroups with psi triggers (triggers in each cgroup are served by a single
"psimon" kernel thread).
Instead of limiting min polling period, which also limits the latency of
psi events, it's better to limit psi trigger creation to authorized users
only, like we do for system-wide psi triggers (/proc/pressure/* files can
be written only by processes with CAP_SYS_RESOURCE capability). This also
makes access rules for cgroup psi files consistent with system-wide ones.
Add a CAP_SYS_RESOURCE capability check for cgroup psi file writers and
remove the psi window min size limitation.
Bug: 269247660
Change-Id: I8876aa306cf2ba5acdf4daa5a5eff0665537bfeb
Suggested-by: Sudarshan Rajagopalan <quic_sudaraja@quicinc.com>
Link: https://lore.kernel.org/all/20230303011346.3342233-1-surenb@google.com/
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Sudarshan Rajagopalan <quic_sudaraja@quicinc.com>
Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
locks for each hlist in hash_table.
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.
Bug: 278138377
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
Change-Id: I04c564ce42b62d8cfb9ed29e99f310ba76244763
process_notifier() is called every time a process exits. When multiple
processes exit roughly at the same time, the uid_lock taken from inside
of process_notifier() will create contention which slows down process
exit. Defer stats accounting in such case to avoid lock contention.
Bug: 261537194
Change-Id: Ia1e9a451eab39eb0dda7eb175bfd71c67f3e0a58
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Add dma_resv_iter_first and dma_resv_iter_next to
abi_gki_aarch64_qcom. These symbols were already added to the KMI as a
part of commit b38e72d30c ("ANDROID: Add initial symbols list for
db845c").
Bug: 199236943
Change-Id: Ib5222cf342c3e119e424c3c13c062c9d867c7884
Signed-off-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
IOMMU_SYS_CACHE_NWA allows buffers for non-coherent devices to be
mapped with the correct memory attributes so that the buffers can be
cached in the system cache, with a no write allocate cache policy.
However, this property is only usable by drivers that invoke the IOMMU
API directly; it is not usable by drivers that use the DMA API.
Thus, introduce DMA_ATTR_SYS_CACHE_NWA, so that drivers for
non-coherent devices that use the DMA API can use it to specify if
they want a buffer to be cached in the system cache.
Bug: 189339242
Change-Id: Ic812a1fb144a58deb4279c2bf121fc6cc4c3b208
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
IOMMU_SYS_CACHE allows buffers for non-coherent devices to be mapped
with the correct memory attributes so that the buffers can be cached
in the system cache. However, this property is only usable by drivers
that invoke the IOMMU API directly; it is not usable by drivers that
use the DMA API.
Thus, introduce DMA_ATTR_SYS_CACHE, so that drivers for non-coherent
devices that use the DMA API can use it to specify if they want a
buffer to be cached in the system cache.
Bug: 189339242
Change-Id: I849d7a3f36b689afd2f6ee400507223fd6395158
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
Add IOMMU_SYS_CACHE and IOMMU_SYS_CACHE_NWA for device mappings.
IOMMU_SYS_CACHE, used by itself, allows device accesses to be cached
in the system cache (if present). IOMMU_SYS_CACHE_NWA, used by itself,
allows device accesses to be cached in the system cache with a
no-write allocate policy.
On systems in which devices can also snoop the CPU caches (i.e.
IO-coherency is present), IOMMU_SYS_CACHE_NWA and IOMMU_SYS_CACHE can
be combined with IOMMU_CACHE (with IOMMU_SYS_CACHE + IOMMU_CACHE being
a no-op).
Bug: 189339242
Change-Id: Ic91616a148f39fead008a5b87a54ffd781fee734
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
Signed-off-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
Non-coherent devices on systems that support a system or
last level cache may want to request that allocations be
cached in the system cache. For memory that is allocated
by the kernel, and used for DMA with devices, the memory
attributes used for CPU access should match the memory
attributes that will be used for device access.
The memory attributes that need to be programmed into
the MAIR for system cache usage are:
0xf4 - Normal memory, outer write back read/write allocate,
inner non-cacheable.
There is currently no support for this memory attribute for
CPU mappings, so add it.
Bug: 189339242
Change-Id: I3abc7becd408f20ac5499cbbe3c6c6f53f784107
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
Currently, the frequency is calculated by max freq * 1.25 * util / max cap.
Add a vendor hook to adjust the frequency when the calculation
overestimate.
android_vh_map_util_freq
adjust util to freq calculation
Bug: 177845439
Signed-off-by: Yun Hsiang <yun.hsiang@mediatek.com>
Change-Id: I9aa9079f00af7d3380b19f2fe21b75cddd107d15
(cherry picked from commit 3122e3ec9672036384304fdeaa1b1815f60ba817)
(cherry picked from commit a2d89d4f3a)
Consider the following sequence of events:
1) A page in a PROT_READ|PROT_WRITE VMA is faulted.
2) Page migration allocates a page with the KASAN allocator,
causing it to receive a non-match-all tag, and uses it
to replace the page faulted in 1.
3) The program uses mprotect() to enable PROT_MTE on the page faulted in 1.
As a result of step 3, we are left with a non-match-all tag for a page
with tags accessible to userspace, which can lead to the same kind of
tag check faults that commit e74a684680 ("arm64: Reset KASAN tag in
copy_highpage with HW tags only") intended to fix.
The general invariant that we have for pages in a VMA with VM_MTE_ALLOWED
is that they cannot have a non-match-all tag. As a result of step 2, the
invariant is broken. This means that the fix in the referenced commit
was incomplete and we also need to reset the tag for pages without
PG_mte_tagged.
Fixes: e5b8d92189 ("arm64: mte: reset the page tag in page->flags")
Cc: <stable@vger.kernel.org> # 5.15
Link: https://linux-review.googlesource.com/id/I7409cdd41acbcb215c2a7417c1e50d37b875beff
Link: https://lore.kernel.org/all/20230420210945.2313627-1-pcc@google.com/
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 263910115
Change-Id: I7409cdd41acbcb215c2a7417c1e50d37b875beff
[pcc: fixed merge conflict]
The mte_sync_page_tags() function sets PG_mte_tagged if it initializes
page tags. Then we return to mte_sync_tags(), which sets PG_mte_tagged
again. At best, this is redundant. However, it is possible for
mte_sync_page_tags() to return without having initialized tags for the
page, i.e. in the case where check_swap is true (non-compound page),
is_swap_pte(old_pte) is false and pte_is_tagged is false. So at worst,
we set PG_mte_tagged on a page with uninitialized tags. This can happen
if, for example, page migration causes a PTE for an untagged page to
be replaced. If the userspace program subsequently uses mprotect() to
enable PROT_MTE for that page, the uninitialized tags will be exposed
to userspace.
Fix it by removing the redundant call to set_page_mte_tagged().
Fixes: e059853d14 ("arm64: mte: Fix/clarify the PG_mte_tagged semantics")
Signed-off-by: Peter Collingbourne <pcc@google.com>
Cc: <stable@vger.kernel.org> # 6.1
Link: https://linux-review.googlesource.com/id/Ib02d004d435b2ed87603b858ef7480f7b1463052
Link: https://lore.kernel.org/all/20230420214327.2357985-1-pcc@google.com/
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 263910115
Change-Id: Ib02d004d435b2ed87603b858ef7480f7b1463052
