i2c_master_hub is only used in i2c-qcom-geni.c now,
change it to static.
Fixes: cacd9643ec ("i2c: qcom-geni: add support for I2C Master Hub variant")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Bug: 370629635
Change-Id: If191b6b205f111c9b54590859438c75235e2bd0a
(cherry picked from commit 597688792c)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.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.
Add the I2C Master Hub serial engine compatible along the specific
requirements in a new desc struct passed through the device 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: I161a19650cd69595e0829411a2dd12a58de23615
(cherry picked from commit cacd9643ec)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.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.
Those I2C serial engines variants have some requirements:
- a separate "core" clock
- doesn't support DMA, thus no memory interconnect path
- fixed FIFO size not discoverable in the HW_PARAM_0 register
Add a desc struct specifying all those requirements which will be used in
a next change when adding the I2C Master Hub serial engine compatible.
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: I9f007f3f4f435e59e41849d357fe0ed72b81c63d
(cherry picked from commit 14d02fbadb)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
Individual MLO links connection status is not copied to
EVENT_CONNECT_RESULT data while processing the connect response
information in cfg80211_connect_done(). Due to this failed links
are wrongly indicated with success status in EVENT_CONNECT_RESULT.
To fix this, copy the individual MLO links status to the
EVENT_CONNECT_RESULT data.
Bug: 254441685
Fixes: 53ad07e982 ("wifi: cfg80211: support reporting failed links")
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Link: https://patch.msgid.link/20240724125327.3495874-1-quic_vjakkam@quicinc.com
[commit message editorial changes]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit baeaabf970b9a90999f62ae27edf63f6cb86c023)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I0a1aacb180914e8d5509eab44aa27bd82272bbf7
UFS link is just put into hibern8 state during the 'freeze' process of the
hibernation. Afterwards, the system may get powered down. But that doesn't
matter during wakeup. Because during wakeup from hibernation, UFS link is
again put into hibern8 state by the restore kernel and then the control is
handed over to the to image kernel.
So in both the places, UFS link is never turned OFF. But
ufshcd_system_restore() just assumes that the link will be in OFF state and
sets the link state accordingly. And this breaks hibernation wakeup:
[ 2445.371335] phy phy-1d87000.phy.3: phy_power_on was called before phy_init
[ 2445.427883] ufshcd-qcom 1d84000.ufshc: Controller enable failed
[ 2445.427890] ufshcd-qcom 1d84000.ufshc: ufshcd_host_reset_and_restore: Host init failed -5
[ 2445.427906] ufs_device_wlun 0:0:0:49488: ufshcd_wl_resume failed: -5
[ 2445.427918] ufs_device_wlun 0:0:0:49488: PM: dpm_run_callback(): scsi_bus_restore returns -5
[ 2445.427973] ufs_device_wlun 0:0:0:49488: PM: failed to restore async: error -5
So fix the issue by removing the code that sets the link to OFF state.
Bug: 254441685
Cc: Anjana Hari <quic_ahari@quicinc.com>
Cc: stable@vger.kernel.org # 6.3
Fixes: 88441a8d35 ("scsi: ufs: core: Add hibernation callbacks")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20240718170659.201647-1-manivannan.sadhasivam@linaro.org
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit ac6efb12ca64156f4a94e964acdb96ee7d59630d)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ie855c205e39a182050f2080929977e4246eb49e1
set_initial_priority() tries to jump-start global reclaim by estimating
the priority based on cold/hot LRU pages. The estimation does not account
for shrinker objects, and it cannot do so because their sizes can be in
different units other than page.
If shrinker objects are the majority, e.g., on TrueNAS SCALE 24.04.0 where
ZFS ARC can use almost all system memory, set_initial_priority() can
vastly underestimate how much memory ARC shrinker can evict and assign
extreme low values to scan_control->priority, resulting in overshoots of
shrinker objects.
To reproduce the problem, using TrueNAS SCALE 24.04.0 with 32GB DRAM, a
test ZFS pool and the following commands:
fio --name=mglru.file --numjobs=36 --ioengine=io_uring \
--directory=/root/test-zfs-pool/ --size=1024m --buffered=1 \
--rw=randread --random_distribution=random \
--time_based --runtime=1h &
for ((i = 0; i < 20; i++))
do
sleep 120
fio --name=mglru.anon --numjobs=16 --ioengine=mmap \
--filename=/dev/zero --size=1024m --fadvise_hint=0 \
--rw=randrw --random_distribution=random \
--time_based --runtime=1m
done
To fix the problem:
1. Cap scan_control->priority at or above DEF_PRIORITY/2, to prevent
the jump-start from being overly aggressive.
2. Account for the progress from mm_account_reclaimed_pages(), to
prevent kswapd_shrink_node() from raising the priority
unnecessarily.
Bug: 254441685
Link: https://lkml.kernel.org/r/20240711191957.939105-2-yuzhao@google.com
Fixes: e4dde56cd2 ("mm: multi-gen LRU: per-node lru_gen_folio lists")
Signed-off-by: Yu Zhao <yuzhao@google.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Cc: Wei Xu <weixugc@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 3f74e6bd3b84a8b6bb3cc51609c89e5b9d58eed7)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I4ae651a8f945c7115da48205dbfea04e66032a68
Detect gso fraglist skbs with corrupted geometry (see below) and
pass these to skb_segment instead of skb_segment_list, as the first
can segment them correctly.
Valid SKB_GSO_FRAGLIST skbs
- consist of two or more segments
- the head_skb holds the protocol headers plus first gso_size
- one or more frag_list skbs hold exactly one segment
- all but the last must be gso_size
Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can
modify these skbs, breaking these invariants.
In extreme cases they pull all data into skb linear. For UDP, this
causes a NULL ptr deref in __udpv4_gso_segment_list_csum at
udp_hdr(seg->next)->dest.
Detect invalid geometry due to pull, by checking head_skb size.
Don't just drop, as this may blackhole a destination. Convert to be
able to pass to regular skb_segment.
Link: https://lore.kernel.org/netdev/20240428142913.18666-1-shiming.cheng@mediatek.com/
Fixes: 9fd1ff5d2a ("udp: Support UDP fraglist GRO/GSO.")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20241001171752.107580-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Bug: 373245346
Bug: 333849117
Change-Id: I5a317e002f149cf9d399dce9bf87cd649a24da19
(cherry picked from commit a1e40ac5b5e9077fe1f7ae0eb88034db0f9ae1ab)
Signed-off-by: Lena Wang <lena.wang@mediatek.corp-partner.google.com>
(cherry picked from commit 42c2d1ea7c1bf984372f0ca1711d91165cbb87a6)
(cherry picked from commit 7376b8e51c4ddaa8e36b2b33d6ac3392135183b1)
The select_fifo/dma_mode() functions in geni driver enable/disable
interrupts (secondary included) conditionally for non-uart modes, while
uart is supposed to manage this internally.
However, only uart uses secondary IRQs while spi, i2c do not care about
these at all making their enablement (or disablement) totally unnecessary
for these protos.
Similarly, select_gpi_mode() also does disable s_irq and its useless again.
Drop enabling/disabling secondary IRQs.
This doesn't solve any observed problem but only gets rid of code pieces
that are not required.
Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/1686742087-30731-1-git-send-email-quic_vnivarth@quicinc.com
Bug: 370629635
Change-Id: Id35fae83b7628cf583e4cdd6307862da08d07a9c
(cherry picked from commit 5d85ea2c87)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
We don't need to handle them separately. Instead, just let them
decompose/casefold to themselves.
Change-Id: I01c3f2c98ae4d84269586cec09f18239cbee0abb
Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
(cherry picked from commit 5c26d2f1d3f5e4be3e196526bead29ecb139cf91)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
If CONFIG_F2FS_CHECK_FS is off, and for very rare corner case that
we run out of free segment, we should not panic kernel, instead,
let's handle such error correctly in its caller.
Signed-off-by: Chao Yu <chao@kernel.org>
Tested-by: Zhiguo Niu <zhiguo.niu@unisoc.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Change-Id: I4e7d90895d82687ae6ec6b64b2de222f1ee2ee9e
Bug: 361829529
(cherry picked from commit 7d009e048d7cfcc21d400f2aba4c8bacbdebbd47)
Signed-off-by: Daeho Jeong <daehojeong@google.com>
There is low probability that an out-of-bounds segment will be got
on a small-capacity device. In order to prevent subsequent write requests
allocating block address from this invalid segment, which may cause
unexpected issue, stop checkpoint should be performed.
Also introduce a new stop cp reason: STOP_CP_REASON_NO_SEGMENT.
Note, f2fs_stop_checkpoint(, false) is complex and it may sleep, so we should
move it outside segmap_lock spinlock coverage in get_new_segment().
Signed-off-by: Zhiguo Niu <zhiguo.niu@unisoc.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Change-Id: Ie5a83b05851a0b5c0c75fa74dbcf9261065724fa
Bug: 361829529
(cherry picked from commit f9e28904e6442019043a8e94ec6747a064d06003)
Signed-off-by: Daeho Jeong <daehojeong@google.com>
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>
