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]
Change-Id: I054a6ef56b9b2d7c4e8167e8630a8c277910da88
Signed-off-by: RD Babiera <rdbabiera@google.com>
Commit 4b23a68f95 ("mm/page_alloc: protect PCP lists with a spinlock")
bypasses the pcplist on lock contention and returns the page directly to
the buddy list of the page's migratetype.
For pages that don't have their own pcplist, such as CMA and HIGHATOMIC,
the migratetype is temporarily updated such that the page can hitch a ride
on the MOVABLE pcplist. Their true type is later reassessed when flushing
in free_pcppages_bulk(). However, when lock contention is detected after
the type was already overridden, the bypass will then put the page on the
wrong buddy list.
Once on the MOVABLE buddy list, the page becomes eligible for fallbacks
and even stealing. In the case of HIGHATOMIC, otherwise ineligible
allocations can dip into the highatomic reserves. In the case of CMA, the
page can be lost from the CMA region permanently.
Use a separate pcpmigratetype variable for the pcplist override. Use the
original migratetype when going directly to the buddy. This fixes the bug
and should make the intentions more obvious in the code.
Originally sent here to address the HIGHATOMIC case:
https://lore.kernel.org/lkml/20230821183733.106619-4-hannes@cmpxchg.org/
Changelog updated in response to the CMA-specific bug report.
[mgorman@techsingularity.net: updated changelog]
Link: https://lkml.kernel.org/r/20230911181108.GA104295@cmpxchg.org
Fixes: 4b23a68f95 ("mm/page_alloc: protect PCP lists with a spinlock")
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reported-by: Joe Liu <joe.liu@mediatek.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 302075941
(cherry picked from commit 7b086755fb)
Change-Id: I5e62c941e0a91db551a56f4b8c1ae14f87fd2bc3
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.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 patch tries to preload extent_cache given POSIX_FADV_WILLNEED, which is
more useful for generic usecases.
Bug: 301585673
Bug: 296299682
Fixes: f43b021e14 ("FROMGIT: f2fs: preload extent_cache for POSIX_FADV_WILLNEED")
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 3e729e50d01e6a336132d1739866a6463f82faa9
https://git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: I11702b172270b143209407d06aa0338f19f19b43
By this vh, so that we can reimplement the function xhci_urb_suitable_for_idt()
Bug: 301055890
Change-Id: I5e4eabf1155eceb650eee6a42b0e00e8d55281dc
Signed-off-by: Wanwei Jiang <wanwei.jiang@amlogic.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
When building using kleaf on an host distribution with glibc 2.38 or later,
there is a linkage failure when building resolve_btfids:
ld.lld: error: undefined symbol: __isoc23_strtol
>>> referenced by stdlib.h:483 (/usr/include/stdlib.h:483)
>>> libsubcmd-in.o:(pretty_print_string_list) in archive .../libsubcmd.a
>>> referenced by stdlib.h:483 (/usr/include/stdlib.h:483)
>>> libsubcmd-in.o:(pretty_print_string_list) in archive .../libsubcmd.a
>>> referenced by stdlib.h:483 (/usr/include/stdlib.h:483)
>>> libsubcmd-in.o:(pager_get_columns) in archive .../libsubcmd.a
>>> referenced 2 more times
ld.lld: error: undefined symbol: __isoc23_strtoul
>>> referenced by parse-options.c:314 (.../tools/lib/subcmd/parse-options.c:314)
>>> libsubcmd-in.o:(get_value) in archive .../libsubcmd.a
ld.lld: error: undefined symbol: __isoc23_strtoull
>>> referenced by parse-options.c:332 (.../tools/lib/subcmd/parse-options.c:332)
>>> libsubcmd-in.o:(get_value) in archive .../libsubcmd.a
clang-17: error: linker command failed with exit code 1 (use -v to see invocation)
These errors imply that the files were build against glibc 2.38 headers
but attempted to be linked with an older glibc version.
Building with '--debug_make_verbosity=D' reveals that the libsubcmd
object files are not built with the additional HOSTCFLAGS the Android
build system provides for a hermetic build (namely '-I' for .c files),
so they build against the system's headers but link against Android's
glibc 2.17, resulting in the error above.
This is not an issue upstream after
commit 13e07691a1 ("tools/resolve_btfids: Alter how HOSTCC is
forced"), as HOST_OVERRIDES (which contains HOSTCFLAGS via EXTRA_CFLAGS)
is passed along to libsubcmd. That change is quite invasive as a
backport for 5.15 and earlier. As a miminal fix, pass CFLAGS (which
contains HOSTCFLAGS via KBUILD_HOSTCFLAGS) to the libsubcmd build via
EXTRA_CFLAGS, which really should have been done upstream in
commit 0e3a1c902f ("tools/resolve_btfids: Build with host flags"),
which is present in this branch as commit 9e332a14f3 ("FROMGIT:
tools/resolve_btfids: Build with host flags").
Bug: 301145081
Change-Id: I91c1c9a8fb8f83118a6b8ec4da6cc33a773f2124
Fixes: 368cd63174 ("FROMGIT: tools/resolve_btfids: Build with host flags")
Link: https://github.com/ClangBuiltLinux/linux/issues/1929
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
When applying HOSTCFLAGS to the libsubcmd build to resolve a separate
issue, which contain '-std=gnu89' prior to commit 1e24078113 ("Kbuild:
use -std=gnu11 for KBUILD_USERCFLAGS"), the following warning/error
occurs:
parse-options.c:643:8: error: GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat]
for (int i = 0; subcommands[i]; i++) {
^
parse-options.c:669:9: error: GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat]
for (int i = 0; subcommands[i]; i++)
^
This issue was never visible upstream, as commit 1e24078113 ("Kbuild:
use -std=gnu11 for KBUILD_USERCFLAGS") was applied before
commit 13e07691a1 ("tools/resolve_btfids: Alter how HOSTCC is
forced"). Prior to the latter change, there was no '-std=' flag passed
to the libsubcmd build, so the default standard value was used, which
may be newer than C99.
To resolve this issue to unblock applying HOSTCFLAGS to libsubcmd, just
hoist the declarations out of the for loops.
Bug: 301145081
Change-Id: I41f17964f3d0822b026f6ae8f06a4d49bc7f15a9
Link: https://github.com/ClangBuiltLinux/linux/issues/1929
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Revert commit 9102217567 ("ANDROID: block: Send requeued requests to
the I/O scheduler") because these changes are not needed for any use
case.
Bug: 298142254
Change-Id: I0a0e51a46d56c2c433ae5900d69e69ee2abad7a0
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Revert commit 5d90f7cbaf ("ANDROID: block: Preserve the order of
requeued requests") because it is no longer needed. A mechanism has
been added in the SCSI core for sorting zoned writes by LBA. This
patch includes changes to compensate for the move of the requeue_work
member from struct request_queue into struct internal_request_queue.
Bug: 298142254
Change-Id: I35161cfff058d518c3ac5835c6bfcedb8fb567c7
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Restore the struct request_queue requeue_work member without modifying
the KMI. The approach of this patch works because blk_dev_init() is the
only function that needs to know the size of a request queue structure.
This patch prepares for reverting "Preserve the order of requeued
requests".
See also commit 619ba336c3 ("ANDROID: block: Remove
request_queue.requeue_work").
Bug: 298142254
Change-Id: I108ceb9f58cec521f81fd8cf82f38185376a7a6b
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The logical unit information is missing from the UFS command tracing
output. Although the device name is logged, e.g. 13200000.ufs, this
name does not include logical unit information. Hence this patch that
replaces the device name with the SCSI ID in the tracing output. An
example of tracing output with this patch applied:
kworker/8:0H-80 [008] ..... 89.106063: ufshcd_command: send_req: 0:0:0:4: tag: 10, DB: 0x7ffffbff, size: 524288, IS: 0, LBA: 1085538, opcode: 0x8a (WRITE_16), group_id: 0x0
dd-4225 [000] d.h.. 89.106219: ufshcd_command: complete_rsp: 0:0:0:4: tag: 11, DB: 0x7ffff7ff, size: 524288, IS: 0, LBA: 1081728, opcode: 0x8a (WRITE_16), group_id: 0x0
Bug: 299493745
Change-Id: I140a5b0bfea25d17d0c0e46038cb016d8f6ca589
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
(cherry picked from commit ccc3e1363069c5955045824bb0e63c51d8873e25 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Advanced Dot product is a feature present in AArch32 state for Armv8 and
is represented by ISAR6 identification register.
This feature denotes the presence of UDOT and SDOT instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Bug: 282663915
(cherry picked from commit 62ea0d873a)
Change-Id: I27cd1e060ec48ec3302c23b566ef9f50f7dc384e
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Floating point half-precision (FPHP) and Advanced SIMD half-precision
(ASIMDHP) are VFP features (FEAT_FP16) represented by MVFR1 identification register. These capabilities can optionally exist with VFPv3 and mandatory with VFPv4. Both these new features exist for Armv8 architecture in AArch32 state.
These hwcaps may be useful for the userspace to add conditional check
before trying to use FEAT_FP16 feature specific instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Bug: 282663915
(cherry picked from commit c00a19c8b1)
Change-Id: I46af49d39168b0d35db05cdd1499f9b7df030f09
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
AArch32 Instruction Set Attribute Register 6 (ID_ISAR6_EL1) and AArch32
Processor Feature Register 2 (ID_PFR2_EL1) identifies some new features
for the Armv8 architecture. This registers will be utilized to add
hwcaps for those cpu features.
These registers are marked as reserved for Armv7 and should be a RAZ.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Bug: 282663915
(cherry picked from commit 74c344e6f1)
Change-Id: I5545dbb3d22424ef130c0f95e92ee31a9e7de9be
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
While porting [1] from 5.10 kernel there was a bug introduced which
results in CMA pages ending up in MIGRATE_MOVABLE pcp list. Remove
the extra line.
[1] https://android-review.googlesource.com/c/kernel/common/+/2059993
Fixes: 98f3cc7ecd ("ANDROID: mm: freeing MIGRATE_ISOLATE page instantly")
Bug: 299241869
Change-Id: Ia63bca17e455460eb9f22a1190c991159c44acaa
Signed-off-by: Suren Baghdasaryan <surenb@google.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
By this vh, so that we can reimplement the function cma_alloc()
Bug: 299425220
Change-Id: I7068915c3c38784dba25d130434abe595b06b996
Signed-off-by: Wanwei Jiang <wanwei.jiang@amlogic.com>
ra->prev_pos tracks the last visited byte in the previous read request.
It is used to check whether it is sequential read in ondemand_readahead
and thus affects the readahead window.
After commit 06c0444290 ("mm/filemap.c: generic_file_buffered_read() now
uses find_get_pages_contig"), update logic of prev_pos is changed. It
updates prev_pos after each return from filemap_get_pages(). But the read
request from user may be not fully completed at this point. The updated
prev_pos impacts the subsequent readahead window.
The real problem is performance drop of fsck_msdos between linux-5.4 and
linux-5.15(also linux-6.4). Comparing to linux-5.4,It spends about 110%
time and read 140% pages. The read pattern of fsck_msdos is not fully
sequential.
Simplified read pattern of fsck_msdos likes below:
1.read at page offset 0xa,size 0x1000
2.read at other page offset like 0x20,size 0x1000
3.read at page offset 0xa,size 0x4000
4.read at page offset 0xe,size 0x1000
Here is the read status on linux-6.4:
1.after read at page offset 0xa,size 0x1000
->page ofs 0xa go into pagecache
2.after read at page offset 0x20,size 0x1000
->page ofs 0x20 go into pagecache
3.read at page offset 0xa,size 0x4000
->filemap_get_pages read ofs 0xa from pagecache and returns
->prev_pos is updated to 0xb and goto next loop
->filemap_get_pages tends to read ofs 0xb,size 0x3000
->initial_readahead case in ondemand_readahead since prev_pos is
the same as request ofs.
->read 8 pages while async size is 5 pages
(PageReadahead flag at page 0xe)
4.read at page offset 0xe,size 0x1000
->hit page 0xe with PageReadahead flag set,double the ra_size.
read 16 pages while async size is 16 pages
Now it reads 24 pages while actually uses 5 pages
on linux-5.4:
1.the same as 6.4
2.the same as 6.4
3.read at page offset 0xa,size 0x4000
->read ofs 0xa from pagecache
->read ofs 0xb,size 0x3000 using page_cache_sync_readahead
read 3 pages
->prev_pos is updated to 0xd before generic_file_buffered_read
returns
4.read at page offset 0xe,size 0x1000
->initial_readahead case in ondemand_readahead since
request ofs-prev_pos==1
->read 4 pages while async size is 3 pages
Now it reads 7 pages while actually uses 5 pages.
In above demo, the initial_readahead case is triggered by offset of user
request on linux-5.4. While it may be triggered by update logic of
prev_pos on linux-6.4.
To fix the performance drop, update prev_pos after finishing one read
request.
Link: https://lkml.kernel.org/r/20230628110220.120134-1-haibo.li@mediatek.com
Change-Id: I7c9c9f8630df580120498a38ec7543ba20931201
Signed-off-by: Haibo Li <haibo.li@mediatek.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 298557577
(cherry picked from commit f04d16ee3a)
Change-Id: Ie2adb86d5642f01465d5c7ffef71cc6964598afc
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.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)
Change-Id: Ie919c29bab68cb08cb659471ff6106bae502c8dd
Signed-off-by: RD Babiera <rdbabiera@google.com>
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>
It holds mmap_sem lock which is a hot path. Some debug daemons can end
up holding this lock to get the cmdline of a process, which can result
in slowing down this process.
Add hooks around the calls to allow vendors to implement a simple prio
inheritance scheme to deal with this.
Bug: 289412815
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I160637b30e5bd58d5978b25be8a21ce025175ec3
The purpose of the symbol is for getting runnable latency.
Bug: 275806676
Change-Id: I34d8450df16f63d133aaf3e9773a1f5436cbae58
Signed-off-by: Ziyi Cui <ziyic@google.com>
BPF is always 64-bit code, so we need to pad the uapi structs to be the
same on 32-bit as 64-bit
Bug: 285477572
Test: Cuttlefish x86_64, x86 and x86 only all boot and load fuseMedia
Change-Id: Idf5b09b2581b8d097048e7d2ff4039cd1806c082
Signed-off-by: Paul Lawrence <paullawrence@google.com>
A use-after-free bug was found in the previous custom lock-free list
implementation for the deferred work, so switch functionality to llist
implementation.
While the previous approach atomically handled the list head, it did not
assure the new node's next pointer was assigned before the head was
pointed to the node, allowing the consumer to traverse to an invalid
next pointer.
Additionally, in switching to llists, this patch pulls the entire list
off the list head once and processes it separately, reducing the number
of atomic operations compared with the custom lists's implementation
which pulled one node at a time atomically from the list head.
BUG: KASAN: use-after-free in process_notifier+0x270/0x2dc
Write of size 8 at addr d4ffff89545c3c58 by task Blocking Thread/3431
Pointer tag: [d4], memory tag: [fe]
call trace:
dump_backtrace+0xf8/0x118
show_stack+0x18/0x24
dump_stack_lvl+0x60/0x78
print_report+0x178/0x470
kasan_report+0x8c/0xbc
kasan_tag_mismatch+0x28/0x3c
__hwasan_tag_mismatch+0x30/0x60
process_notifier+0x270/0x2dc
notifier_call_chain+0xb4/0x108
blocking_notifier_call_chain+0x54/0x80
profile_task_exit+0x20/0x2c
do_exit+0xec/0x1114
__arm64_sys_exit_group+0x0/0x24
get_signal+0x93c/0xa78
do_notify_resume+0x158/0x3fc
el0_svc+0x54/0x78
el0t_64_sync_handler+0x44/0xe4
el0t_64_sync+0x190/0x194
Bug: 294468796
Bug: 295787403
Fixes: 8e86825eec ("ANDROID: uid_sys_stats: Use a single work for deferred updates")
Signed-off-by: John Stultz <jstultz@google.com>
[nkapron: Squashed with other changes and rewrote the commit message]
Signed-off-by: Neill Kapron <nkapron@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:87647c0c54bbfe865691d8b58988a3ce941b905e)
Merged-In: Id377348c239ec720a5237726bc3632544d737e3b
Change-Id: Id377348c239ec720a5237726bc3632544d737e3b
uid_sys_stats tries to acquire a lock when any task exits to do some
bookkeeping in common data structure. If the lock is contended, it
allocates and schedules a work to do the work later to avoid task exit
latency.
In a stress test which creates many tasks exiting, the workqueue can be
overwhelmed by the number of works being scheduled and allocates more
worker threads to handle queue. The growth of the number of threads is
effectively unbounded and can exhaust the process table. This causes
denial of service to userspace trying to fork().
Instead of allocating a new work each, create a linked list of the
update stats deferred work and have a single work to drain the linked
list. The linked list is implemented using an atomic_long_t.
Bug: 294468796
Fixes: 5586278c0f ("ANDROID: uid_sys_stats: defer process_notifier work if uid_lock is contended")
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
(cherry picked from https://android-review.googlesource.com/q/commit:8e86825eecfaaa582ab51a0924b469d2d2adc743)
Merged-In: I15f20f4f69ea66a452bdf815c4ef3a0da3edfd36
Change-Id: I15f20f4f69ea66a452bdf815c4ef3a0da3edfd36
We were getting the inode with the parent inode info
Also change variable names to remove confusion
Also set bpf correctly in new inode
Bug: 293838958
Test: fuse_test, atest ScopedStorageDeviceTest,
atest CtsScopedStorageHostTest
Signed-off-by: Paul Lawrence <paullawrence@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:12eb00420cad77d7b7fcfbd1088c921ae629e69d)
Merged-In: I0b6a6951599e0d211afd2243daacb98679503448
Change-Id: I0b6a6951599e0d211afd2243daacb98679503448
