This reverts commit 81cc178d7c which was a
revert of commit a3812a47a3 which is
commit 6e5e6d274956305f1fc0340522b38f5f5be74bdb upstream.
It brings it back in an abi-safe way.
Bug: 338889538
Change-Id: I5e2fd45fb4d972056728fb9963a9ef9f86e9a6ca
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The default UIC command timeout still remains 500ms.
Allow platform drivers to override the UIC command
timeout if desired.
In a real product, the 500ms timeout value is probably good enough.
However, during the product development where there are a lot of
logging and debug messages being printed to the uart console,
interrupt starvations happen occasionally because the uart may
print long debug messages from different modules in the system.
While printing, the uart may have interrupts disabled for more
than 500ms, causing UIC command timeout.
The UIC command timeout would trigger more printing from
the UFS driver, and eventually a watchdog timeout may
occur unnecessarily.
Add support for overriding the UIC command timeout value
with the newly created uic_cmd_timeout kernel module parameter.
Default value is 500ms. Supported values range from 500ms
to 2 seconds.
Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
Link: https://lore.kernel.org/r/e4e1c87f3f867f270a3d4b5d57a00139ff0e9741.1721792309.git.quic_nguyenb@quicinc.com
Suggested-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 358022094
Bug: 361419350
Change-Id: I3778a26aa82805591454f3771f727d30f92286d9
(cherry picked from commit 88e6804fb323d1dbe477f002a89755f8b034e890
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 6.12/scsi-staging)
Signed-off-by: Ziqi Chen <quic_ziqichen@quicinc.com>
(cherry picked from commit 0c95462c9112873df5ceeeaff13cbfcf05136480)
Signed-off-by: Blagovest Kolenichev <quic_c_bkolen@quicinc.com>
(cherry picked from commit 5414728d5721e0ad3921e45083ebf8cff8d757ac)
Signed-off-by: Shreyas K K <quic_shrekk@quicinc.com>
This reverts commit bf20c69cf3cf9c6445c4925dd9a8a6ca1b78bfdf.
During tcpm_init() stage, if the VBUS is still present after
tcpm_reset_port(), then we assume that VBUS will off and goto safe0v
after a specific discharge time. Following a TCPM_VBUS_EVENT event if
VBUS reach to off state. TCPM_VBUS_EVENT event may be set during
PORT_RESET handling stage. If pd_events reset to 0 after TCPM_VBUS_EVENT
set, we will lost this VBUS event. Then the port state machine may stuck
at one state.
Before:
[ 2.570172] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev1 NONE_AMS]
[ 2.570179] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
[ 2.570182] pending state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED @ 920 ms [rev1 NONE_AMS]
[ 3.490213] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [delayed 920 ms]
[ 3.490220] Start toggling
[ 3.546050] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected]
[ 3.546057] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS]
After revert this patch, we can see VBUS off event and the port will goto
expected state.
[ 2.441992] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev1 NONE_AMS]
[ 2.441999] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
[ 2.442002] pending state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED @ 920 ms [rev1 NONE_AMS]
[ 2.442122] VBUS off
[ 2.442125] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev1 NONE_AMS]
[ 2.442127] VBUS VSAFE0V
[ 2.442351] CC1: 0 -> 0, CC2: 0 -> 0 [state SNK_UNATTACHED, polarity 0, disconnected]
[ 2.442357] Start toggling
[ 2.491850] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected]
[ 2.491858] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS]
[ 2.491863] pending state change SRC_ATTACH_WAIT -> SNK_TRY @ 200 ms [rev1 NONE_AMS]
[ 2.691905] state change SRC_ATTACH_WAIT -> SNK_TRY [delayed 200 ms]
Fixes: bf20c69cf3cf ("usb: typec: tcpm: clear pd_event queue in PORT_RESET")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20240809112901.535072-1-xu.yang_2@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 21ea1ce37fc267dc45fe27517bbde926211683df)
Test: Verify 100 reboot loop, device not stuck in SRC_ATTACH_WAIT
Bug: 320466108
Change-Id: I334497dc94d3011079d5d3208c9355dc2374c4ff
Signed-off-by: RD Babiera <rdbabiera@google.com>
There could be following scenario where there is a ongoing reboot
is going from processA which tries to call all the reboot notifier
callback and one of them is firmware reboot call which tries to
abort all the ongoing firmware userspace request under fw_lock but
there could be another processB which tries to do request firmware,
which came just after abort done from ProcessA and ask for userspace
to load the firmware and this can stop the ongoing reboot ProcessA
to stall for next 60s(default timeout) which may not be expected
behaviour everyone like to see, instead we should abort any firmware
load request which came once firmware knows about the reboot through
notification.
ProcessA ProcessB
kernel_restart_prepare
blocking_notifier_call_chain
fw_shutdown_notify
kill_pending_fw_fallback_reqs
__fw_load_abort
fw_state_aborted request_firmware
__fw_state_set firmware_fallback_sysfs
... fw_load_from_user_helper
.. ...
. ..
usermodehelper_read_trylock
fw_load_sysfs_fallback
fw_sysfs_wait_timeout
usermodehelper_disable
__usermodehelper_disable
down_write()
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/1698330459-31776-2-git-send-email-quic_mojha@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 309378049
Change-Id: I61eb91f21a01460f340f890b25c60de7597a87ff
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/1698330459-31776-2-git-send-email-quic_mojha@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit effd7c70eaa0440688b60b9d419243695ede3c45)
Signed-off-by: Srinivasarao Pathipati <quic_c_spathi@quicinc.com>
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
There is currently nothing preventing tasks from changing their per-task
clamp values in anyway that they like. The rationale is probably that
system administrators are still able to limit those clamps thanks to the
cgroup interface. However, this causes pain in a system where both
per-task and per-cgroup clamp values are expected to be under the
control of core system components (as is the case for Android).
To fix this, let's require CAP_SYS_NICE to change per-task clamp values.
There are ongoing discussions upstream about more flexible approaches
than this using the RLIMIT API -- see [1]. But the upstream discussion
has not converged yet, and this is way too late for UAPI changes in
android12-5.10 anyway, so let's apply this change which provides the
behaviour we want without actually impacting UAPIs.
[1] https://lore.kernel.org/lkml/20210623123441.592348-4-qperret@google.com/
Bug: 187186685
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I749312a77306460318ac5374cf243d00b78120dd
generic/728 - output mismatch (see /media/fstests/results//generic/728.out.bad)
--- tests/generic/728.out 2023-07-19 07:10:48.362711407 +0000
+++ /media/fstests/results//generic/728.out.bad 2023-07-19 08:39:57.000000000 +0000
QA output created by 728
+Expected ctime to change after setxattr.
+Expected ctime to change after removexattr.
Silence is golden
...
(Run 'diff -u /media/fstests/tests/generic/728.out /media/fstests/results//generic/728.out.bad' to see the entire diff)
generic/729 1s
It needs to update i_ctime after {set,remove}xattr, fix it.
Bug: 369150601
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Change-Id: I06ecb39a14703efe711bfceef6b52790405b9d2f
(cherry picked from commit 8874ad7dae)
Signed-off-by: Daeho Jeong <daehojeong@google.com>
The i_pino in f2fs_inode_info has the previous parent's i_ino when inode
was renamed, which may cause f2fs_ioc_start_atomic_write to fail.
If file_wrong_pino is true and i_nlink is 1, then to find a valid pino,
we should refer to the dentry from inode.
To resolve this issue, let's get parent inode using parent dentry
directly.
Fixes: 3db1de0e58 ("f2fs: change the current atomic write way")
Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
Reviewed-by: Sunmin Jeong <s_min.jeong@samsung.com>
Signed-off-by: Yeongjin Gil <youngjin.gil@samsung.com>
Reviewed-by: Daeho Jeong <daehojeong@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 369150601
Change-Id: I0a32c0a9f67b57ba02e6600ca22e96806ee5470d
(cherry picked from commit 8c1b787938fd86bab27a1492fa887408c75fec2b)
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Case #1:
SQLite App GC Thread Kworker Shrinker
- f2fs_ioc_start_atomic_write
- f2fs_ioc_commit_atomic_write
- f2fs_commit_atomic_write
- filemap_write_and_wait_range
: write atomic_file's data to cow_inode
echo 3 > drop_caches
to drop atomic_file's
cache.
- f2fs_gc
- gc_data_segment
- move_data_page
- set_page_dirty
- writepages
- f2fs_do_write_data_page
: overwrite atomic_file's data
to cow_inode
- f2fs_down_write(&fi->i_gc_rwsem[WRITE])
- __f2fs_commit_atomic_write
- f2fs_up_write(&fi->i_gc_rwsem[WRITE])
Case #2:
SQLite App GC Thread Kworker
- f2fs_ioc_start_atomic_write
- __writeback_single_inode
- do_writepages
- f2fs_write_cache_pages
- f2fs_write_single_data_page
- f2fs_do_write_data_page
: write atomic_file's data to cow_inode
- f2fs_gc
- gc_data_segment
- move_data_page
- set_page_dirty
- writepages
- f2fs_do_write_data_page
: overwrite atomic_file's data to cow_inode
- f2fs_ioc_commit_atomic_write
In above cases racing in between atomic_write and GC, previous
data in atomic_file may be overwrited to cow_file, result in
data corruption.
This patch introduces PAGE_PRIVATE_ATOMIC_WRITE bit flag in page.private,
and use it to indicate that there is last dirty data in atomic file,
and the data should be writebacked into cow_file, if the flag is not
tagged in page, we should never write data across files.
Fixes: 3db1de0e58 ("f2fs: change the current atomic write way")
Cc: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 369150601
Change-Id: I79e87d74a3a7eaea23490a9ee6da0f832c99abd3
(cherry picked from commit 1a0bd289a5db1df8df8fab949633a0b8d3f235ee)
Signed-off-by: Daeho Jeong <daehojeong@google.com>
In case of the COW file, new updates and GC writes are already
separated to page caches of the atomic file and COW file. As some cases
that use the meta inode for GC, there are some race issues between a
foreground thread and GC thread.
To handle them, we need to take care when to invalidate and wait
writeback of GC pages in COW files as the case of using the meta inode.
Also, a pointer from the COW inode to the original inode is required to
check the state of original pages.
For the former, we can solve the problem by using the meta inode for GC
of COW files. Then let's get a page from the original inode in
move_data_block when GCing the COW file to avoid race condition.
Fixes: 3db1de0e58 ("f2fs: change the current atomic write way")
Cc: stable@vger.kernel.org #v5.19+
Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
Reviewed-by: Yeongjin Gil <youngjin.gil@samsung.com>
Signed-off-by: Sunmin Jeong <s_min.jeong@samsung.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 369150601
Change-Id: Ibebf5ecb100b23680ef320586d83e74c41339377
(cherry picked from commit f18d0076933689775fe7faeeb10ee93ff01be6ab)
Signed-off-by: Daeho Jeong <daehojeong@google.com>
The page cache of the atomic file keeps new data pages which will be
stored in the COW file. It can also keep old data pages when GCing the
atomic file. In this case, new data can be overwritten by old data if a
GC thread sets the old data page as dirty after new data page was
evicted.
Also, since all writes to the atomic file are redirected to COW inodes,
GC for the atomic file is not working well as below.
f2fs_gc(gc_type=FG_GC)
- select A as a victim segment
do_garbage_collect
- iget atomic file's inode for block B
move_data_page
f2fs_do_write_data_page
- use dn of cow inode
- set fio->old_blkaddr from cow inode
- seg_freed is 0 since block B is still valid
- goto gc_more and A is selected as victim again
To solve the problem, let's separate GC writes and updates in the atomic
file by using the meta inode for GC writes.
Fixes: 3db1de0e58 ("f2fs: change the current atomic write way")
Cc: stable@vger.kernel.org #v5.19+
Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
Reviewed-by: Yeongjin Gil <youngjin.gil@samsung.com>
Signed-off-by: Sunmin Jeong <s_min.jeong@samsung.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 369150601
Change-Id: I0bcc1da7a59df3254d736ba3fb1d81a6d31bbbcd
(cherry picked from commit b40a2b00370931b0c50148681dd7364573e52e6b)
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Add the following symbol for power_supply_core driver to be used in
bq27xxx_battery driver.
1 function symbol(s) added
'struct power_supply *__must_check power_supply_register_no_ws(struct
device *, const struct power_supply_desc *, const struct
power_supply_config *)'
Bug: 370695775
Change-Id: Ie47064f9724b52ef260c33f12e7681e0eee74a1e
Signed-off-by: Monish Chunara <quic_mchunara@quicinc.com>
virtio-audio is used in Haleytek and Volvo Cars audio.
Symbols added:
snd_device_new
snd_pcm_hw_limit_rates
_snd_pcm_stream_lock_irqsave
snd_pcm_stream_unlock_irqrestore
Bug: 370896645
Change-Id: I741aa41e4ecb873994e567734ebe6728e1de2a69
Signed-off-by: Victor Shutemov <victor@haleytek.com>
Commit 63fc9af83c ("soc: qcom: geni-se:
add desc struct to specify clocks from device match data") modifies a
structure in drivers/soc/qcom/qcom-geni-se.c as follows.
type 'struct geni_wrapper' changed
byte size changed from 48 to 56
member 'struct clk_bulk_data ahb_clks[2]' was removed
member 'struct clk_bulk_data clks[2]' was added
member 'unsigned int num_clks' was added
The Android 14 ABI tooling does not exclude this type definition.
This commit updates the ABI representation with the apparent break.
This is safe because the type is not visible to any other code.
Bug: 370629635
Change-Id: I9caeba4a48c4485e209352fa8fe56244e7859ea7
Signed-off-by: Giuliano Procida <gprocida@google.com>
The I2C Master Hub is a stripped down version of the GENI Serial Engine
QUP Wrapper Controller but only supporting I2C serial engines without
DMA support.
Prepare support for the I2C Master Hub variant by moving the required
clocks list to a new desc struct then passing it through the compatible
match data.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Bug: 370629635
Change-Id: I3dacf29d5a1c630b676bf35644222fd96b399446
(cherry picked from commit 63fc9af83c)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
2 function symbol(s) added
'int alloc_contig_range(unsigned long start, unsigned long end, unsigned migratetype, gfp_t gfp_mask)'
'void free_contig_range(unsigned long pfn, unsigned long nr_pages)'
Bug: 370415608
Change-Id: I6ed58458b26364c07779d4b4f662444f14e9a146
Signed-off-by: Seiya Wang <seiya.wang@mediatek.com>
When we share memory through FF-A and the description of the buffers
exceeds the size of the mapped buffer, the fragmentation API is used.
The fragmentation API allows specifying chunks of descriptors in subsequent
FF-A fragment calls and no upper limit has been established for this.
The entire memory region transferred is identified by a handle which can be
used to reclaim the transferred memory.
To be able to reclaim the memory, the description of the buffers has to fit
in the ffa_desc_buf.
Add a bounds check on the FF-A sharing path to prevent the memory reclaim
from failing.
Also do_ffa_mem_xfer() does not need __always_inline, except for the
BUILD_BUG_ON() aspect, which gets moved to a macro.
[maz: fixed the BUILD_BUG_ON() breakage with LLVM, thanks to Wei-Lin Chang
for the timely report]
Fixes: 634d90cf0a ("KVM: arm64: Handle FFA_MEM_LEND calls from the host")
Cc: stable@vger.kernel.org
Reviewed-by: Sebastian Ene <sebastianene@google.com>
Signed-off-by: Snehal Koukuntla <snehalreddy@google.com>
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
Link: https://lore.kernel.org/r/20240909180154.3267939-1-snehalreddy@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
(cherry picked from commit f26a525b77e040d584e967369af1e018d2d59112)
Bug: 298514256
Change-Id: If515f5c03db42e7c994f9f82bef6167b104d75e2
Signed-off-by: Snehal Koukuntla <snehalreddy@google.com>
The function prototype for dev_pm_opp_add differs between a
configuration when CONFIG_PM_OPP is set versus when CONFIG_PM_OPP is not
set.
Fix this mismatch by aligning the function arguments for the dummy
dev_pm_opp_add with the non-dummy version.
Bug: 369659366
Fixes: adf41f4737 ("BACKPORT: OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility")
Change-Id: If23af6ba28bb493d619f96846545cb86608b285d
Signed-off-by: Anant Goel <quic_anantg@quicinc.com>
Export a symbol “next_arg” in android/abi_gki_aarch64_honor
Bug: 368221985
Change-Id: I0bd8fc321752f0fa3d103b56510b33eadcb6e39b
Signed-off-by: yipeng xiang <yipengxiang@honor.corp-partner.google.com>
[ Upstream commit c07ff8592d57ed258afee5a5e04991a48dbaf382 ]
There is a bug in netem_enqueue() introduced by
commit 5845f70638 ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
that can lead to a use-after-free.
This commit made netem_enqueue() always return NET_XMIT_SUCCESS
when a packet is duplicated, which can cause the parent qdisc's q.qlen
to be mistakenly incremented. When this happens qlen_notify() may be
skipped on the parent during destruction, leaving a dangling pointer
for some classful qdiscs like DRR.
There are two ways for the bug happen:
- If the duplicated packet is dropped by rootq->enqueue() and then
the original packet is also dropped.
- If rootq->enqueue() sends the duplicated packet to a different qdisc
and the original packet is dropped.
In both cases NET_XMIT_SUCCESS is returned even though no packets
are enqueued at the netem qdisc.
The fix is to defer the enqueue of the duplicate packet until after
the original packet has been guaranteed to return NET_XMIT_SUCCESS.
Bug: 362391455
Fixes: 5845f70638 ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
Reported-by: Budimir Markovic <markovicbudimir@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20240819175753.5151-1-stephen@networkplumber.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 0486d31dd8)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I390f02549c726e961f57daace468d5cd48468722
In some cases VMAs are split without the mmap write lock held;
later the lock is taken to fixup vm_flags of the original VMA.
Since some uppper bits of vm_flags are used to encode the ELF
padding ranges, they need to be modified on splits. This is
usually handled correctly by __split_vma(). However in the above
case, the flags get over witten later under the write lock.
Preserve vm_flag bits on reset to correctly represent padding.
Bug: 357901498
Change-Id: I1cb75419e614791a47cbdb0341373f619daf0bf2
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Introduce inline header to avoid circular dependency. This
will be used in a subsequent patch.
Also take opportunity to do some small noop refactor in
vma_pad_pages() and split_pad_vma() for more robust code.
Bug: 357901498
Change-Id: Ia5f447758d0d07ed3e1429ca1e35dcc0741cc22a
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
The BINDER_WORK_FROZEN_BINDER type is not handled in the binder_logs
entries and it shows up as "unknown work" when logged:
proc 649
context binder-test
thread 649: l 00 need_return 0 tr 0
ref 13: desc 1 node 8 s 1 w 0 d 0000000053c4c0c3
unknown work: type 10
This patch add the freeze work type and is now logged as such:
proc 637
context binder-test
thread 637: l 00 need_return 0 tr 0
ref 8: desc 1 node 3 s 1 w 0 d 00000000dc39e9c6
has frozen binder
Fixes: d579b04a52a1 ("binder: frozen notification")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 366003708
Link: https://lore.kernel.org/all/20240924184401.76043-5-cmllamas@google.com/
Change-Id: I06f888aa5218db19eeda79e315385506af09d9d5
Signed-off-by: Carlos Llamas <cmllamas@google.com>
When a binder reference is cleaned up, any freeze work queued in the
associated process should also be removed. Otherwise, the reference is
freed while its ref->freeze.work is still queued in proc->work leading
to a use-after-free issue as shown by the following KASAN report:
==================================================================
BUG: KASAN: slab-use-after-free in binder_release_work+0x398/0x3d0
Read of size 8 at addr ffff31600ee91488 by task kworker/5:1/211
CPU: 5 UID: 0 PID: 211 Comm: kworker/5:1 Not tainted 6.11.0-rc7-00382-gfc6c92196396 #22
Hardware name: linux,dummy-virt (DT)
Workqueue: events binder_deferred_func
Call trace:
binder_release_work+0x398/0x3d0
binder_deferred_func+0xb60/0x109c
process_one_work+0x51c/0xbd4
worker_thread+0x608/0xee8
Allocated by task 703:
__kmalloc_cache_noprof+0x130/0x280
binder_thread_write+0xdb4/0x42a0
binder_ioctl+0x18f0/0x25ac
__arm64_sys_ioctl+0x124/0x190
invoke_syscall+0x6c/0x254
Freed by task 211:
kfree+0xc4/0x230
binder_deferred_func+0xae8/0x109c
process_one_work+0x51c/0xbd4
worker_thread+0x608/0xee8
==================================================================
This commit fixes the issue by ensuring any queued freeze work is removed
when cleaning up a binder reference.
Fixes: d579b04a52a1 ("binder: frozen notification")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 366003708
Link: https://lore.kernel.org/all/20240924184401.76043-4-cmllamas@google.com/
Change-Id: Icc40e7dd6157981f4adbea7243e55be118552321
[cmllamas: drop BINDER_STAT_FREEZE as it's not supported here]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
In binder_add_freeze_work() we iterate over the proc->nodes with the
proc->inner_lock held. However, this lock is temporarily dropped to
acquire the node->lock first (lock nesting order). This can race with
binder_deferred_release() which removes the nodes from the proc->nodes
rbtree and adds them into binder_dead_nodes list. This leads to a broken
iteration in binder_add_freeze_work() as rb_next() will use data from
binder_dead_nodes, triggering an out-of-bounds access:
==================================================================
BUG: KASAN: global-out-of-bounds in rb_next+0xfc/0x124
Read of size 8 at addr ffffcb84285f7170 by task freeze/660
CPU: 8 UID: 0 PID: 660 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #18
Hardware name: linux,dummy-virt (DT)
Call trace:
rb_next+0xfc/0x124
binder_add_freeze_work+0x344/0x534
binder_ioctl+0x1e70/0x25ac
__arm64_sys_ioctl+0x124/0x190
The buggy address belongs to the variable:
binder_dead_nodes+0x10/0x40
[...]
==================================================================
This is possible because proc->nodes (rbtree) and binder_dead_nodes
(list) share entries in binder_node through a union:
struct binder_node {
[...]
union {
struct rb_node rb_node;
struct hlist_node dead_node;
};
Fix the race by checking that the proc is still alive. If not, simply
break out of the iteration.
Fixes: d579b04a52a1 ("binder: frozen notification")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 366003708
Link: https://lore.kernel.org/all/20240924184401.76043-3-cmllamas@google.com/
Change-Id: I5ec9d49277a23b864862665b52213460750c535e
Signed-off-by: Carlos Llamas <cmllamas@google.com>
In binder_add_freeze_work() we iterate over the proc->nodes with the
proc->inner_lock held. However, this lock is temporarily dropped in
order to acquire the node->lock first (lock nesting order). This can
race with binder_node_release() and trigger a use-after-free:
==================================================================
BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c
Write of size 4 at addr ffff53c04c29dd04 by task freeze/640
CPU: 5 UID: 0 PID: 640 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #17
Hardware name: linux,dummy-virt (DT)
Call trace:
_raw_spin_lock+0xe4/0x19c
binder_add_freeze_work+0x148/0x478
binder_ioctl+0x1e70/0x25ac
__arm64_sys_ioctl+0x124/0x190
Allocated by task 637:
__kmalloc_cache_noprof+0x12c/0x27c
binder_new_node+0x50/0x700
binder_transaction+0x35ac/0x6f74
binder_thread_write+0xfb8/0x42a0
binder_ioctl+0x18f0/0x25ac
__arm64_sys_ioctl+0x124/0x190
Freed by task 637:
kfree+0xf0/0x330
binder_thread_read+0x1e88/0x3a68
binder_ioctl+0x16d8/0x25ac
__arm64_sys_ioctl+0x124/0x190
==================================================================
Fix the race by taking a temporary reference on the node before
releasing the proc->inner lock. This ensures the node remains alive
while in use.
Fixes: d579b04a52a1 ("binder: frozen notification")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 366003708
Link: https://lore.kernel.org/all/20240924184401.76043-2-cmllamas@google.com/
Change-Id: I47b053532dd4cd3424d35d6f254ca4d00c426411
Signed-off-by: Carlos Llamas <cmllamas@google.com>
If a pmem device is in a bad status, the driver side could wait for
host ack forever in virtio_pmem_flush(), causing the system to hang.
So add a status check in the beginning of virtio_pmem_flush() to return
early if the device is not activated.
Signed-off-by: Philip Chen <philipchen@chromium.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com
Bug: 358391069
Change-Id: I325e6f0ea047c4c5fa82cf4b590cbf7240f39b7b
(cherry picked from commit e25fbcd97cf52c3c9824d44b5c56c19673c3dd50 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master)
Signed-off-by: Philip Chen <philipchen@google.com>
Update symbol list for honor in android/abi_gki_aarch64_honor
Bug: 369259421
Change-Id: I6954293467a50a758b27444bf51b7205d68dd34d
Signed-off-by: Chenghao Zhao <zhaochenghao@honor.com>
Export netdev_get_name, tcp_send_active_reset functions, allow vendor
modules perform more operations on socks and improve users' online
experience.When users browse websites or watch videos, we will sense
the bad sock is on which device, so that the sock can be switched to
another good device by us, so that the internet service will no longer
be stuck. In a similar scenario, if the user downloads from multiple
devices and the rate of one device is low,we can reset the TCP stream
with a lower rate and establish it on the device with a higher rate.
Bug: 334000512
Change-Id: I9ed90ea9fe6f3dc9f11ae1661ca9f2f5fdad5820
Signed-off-by: Dezhi Huang <huangdezhi@hihonor.com>
(cherry picked from commit 21614c79408f0342363db9874d315fbb3ff6553b)
android_vh_modify_scan_control().
add two vendor hooks:
android_vh_page_should_be_protected():protect pages from memory
reclaim.
android_vh_page_referenced_check_bypass():bypass rmap in active list
shrink.
The new vendor data field in scan_control are used to track how many
pages are protected in current reclaim and the "protected / scanned"
rate. These parameters are useful for understanding the impact of page
protection operations on LRU and reclaim, helping us make better
decsions.
Bug: 348285765
Change-Id: I49567a4b1f978821a94da0a8339b2b8fdfd52daf
Signed-off-by: Yuxuan Yan <yanyuxuan3@xiaomi.corp-partner.google.com>
kcompactd_cpu_online() changes kcompactd cpumask, potentially
overwriting any vendor-specific cpumask that was there. This
hook allows vendors to re-set the cpumask.
Bug: 367400751
Change-Id: I45b92bcd16fbf2d5d76474287db659e32af64201
Signed-off-by: Dmitry Skiba <dskiba@google.com>
Jaegeuk Kim