There can be platforms that do not use/have 32-bit DMA addresses.
The current implementation of 32-bit IOVA allocation can fail for
such platforms, eventually leading to the probe failure.
Try to allocate a 32-bit msi_data. If this allocation fails,
attempt a 64-bit address allocation. Please note that if the
64-bit MSI address is allocated, then the EPs supporting 32-bit
MSI address only will not work.
Link: https://lore.kernel.org/linux-pci/20240221153840.1789979-1-ajayagarwal@google.com
Tested-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Ajay Agarwal <ajayagarwal@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Will McVicker <willmcvicker@google.com>
Bug: 312402322
Change-Id: Ic09f14087e50e106dc6361722091b8b892efc517
(cherry picked from commit f3a296405b6e65fe478144c2f85602dc5668700c)
Signed-off-by: Ajay Agarwal <ajayagarwal@google.com>
The MSI target address must be in the lowest 4GB memory to support PCI
peripherals without 64-bit MSI support. Since the allocation is done from
DMA coherent memory, set only the coherent DMA mask, leaving the streaming
DMA mask alone.
Thus streaming DMA operations will work with no artificial limitations. It
will be specifically useful for the eDMA-capable controllers so the
corresponding DMA engine clients would map the DMA buffers with no need for
SWIOTLB for buffers allocated above 4GB.
Add a brief comment about the reason allocating the MSI target address
below 4GB.
Link: https://lore.kernel.org/r/20230113171409.30470-26-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Bug: 312402322
Change-Id: I2c3acb0faf19f3a08861339ced3b2857fc405ea5
(cherry picked from commit 6c784e21b3da735bd2c3dba73acf9b2c033564fa)
Signed-off-by: Ajay Agarwal <ajayagarwal@google.com>
Renamed trace_android_vh_binder_detect_low_async_space_locked to
trace_android_vh_binder_detect_low_async_space.
Because the orignal name is too long, which results to the
compile-err of .ko that uses the symbol:
ERROR: modpost:
too long symbol "__tracepoint_android_vh_binder_detect_low_async_space_locked"
There is not any users of the the orignal hooks so that it is safe to
rename it.
Bug: 322915513
Change-Id: If45046efe8b2dba2c2ce0b9b41d2a794272f1887
Signed-off-by: chenweitao <chenweitao@oppo.com>
Currently xhci_map_urb_for_dma() creates a temporary buffer and copies
the SG list to the new linear buffer. But if the kzalloc_node() fails,
then the following sg_pcopy_to_buffer() can lead to crash since it
tries to memcpy to NULL pointer.
So return -ENOMEM if kzalloc returns null pointer.
Cc: stable@vger.kernel.org # 5.11
Fixes: 2017a1e584 ("usb: xhci: Use temporary buffer to consolidate SG")
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20240229141438.619372-10-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 328151586
(cherry picked from commit be95cc6d71dfd0cba66e3621c65413321b398052
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-next)
Change-Id: I02d1b43bd9910a28034d0363a2cca86864379aaf
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Upstream commit bac1ec5514 ("usb: xhci: Set quirk for
XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
which fixes XHC timeout, which was seen on synopsys XHCs while
using SG buffers. But the support for this quirk isn't present
in the DWC3 layer.
We will encounter this XHCI timeout/hung issue if we run iperf
loopback tests using RTL8156 ethernet adaptor on DWC3 targets
with scatter-gather enabled. This gets resolved after enabling
the XHCI_SG_TRB_CACHE_SIZE_QUIRK. This patch enables it using
the xhci device property since its needed for DWC3 controller.
In Synopsys DWC3 databook,
Table 9-3: xHCI Debug Capability Limitations
Chained TRBs greater than TRB cache size: The debug capability
driver must not create a multi-TRB TD that describes smaller
than a 1K packet that spreads across 8 or more TRBs on either
the IN TR or the OUT TR.
Cc: stable@vger.kernel.org #5.11
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20240116055816.1169821-2-quic_prashk@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 322910830
(cherry picked from commit 817349b6d26aadd8b38283a05ce0bab106b4c765
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-linus)
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Change-Id: I9a5bf2c4d43551406d452927084576387656953d
Upstream commit bac1ec5514 ("usb: xhci: Set quirk for
XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
which fixes XHC timeout, which was seen on synopsys XHCs while
using SG buffers. Currently this quirk can only be set using
xhci private data. But there are some drivers like dwc3/host.c
which adds adds quirks using software node for xhci device.
Hence set this xhci quirk by iterating over device properties.
Cc: stable@vger.kernel.org # 5.11
Fixes: bac1ec5514 ("usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK")
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Link: https://lore.kernel.org/r/20240116055816.1169821-3-quic_prashk@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 322910830
(cherry picked from commit 520b391e3e813c1dd142d1eebb3ccfa6d08c3995
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-linus)
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Change-Id: I7cc21f5975cd82997f8eca38472f9c467df21dd6
If you call getdents with a buffer size less than a page,
entries can be skipped. This correctly sets the point to continue from.
Bug: 325550828
Test: getdents with low buffer size
Signed-off-by: Daniel Rosenberg <drosen@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:506cf3f0742432c1995117f83b2528a23944989b)
Merged-In: I324e7e815d31742bd4e2d70c5d07c2b09a67a7c2
Change-Id: I324e7e815d31742bd4e2d70c5d07c2b09a67a7c2
In kernel 6.1 pending softirq won’t block turning off idle tick,
so it will take longer to be handled.
This is for power saving purposes but has extra delay then the 5.15 kernel.
From above, it needs to export raise_softirq for external module to
speed up the time sensitive event.
Bug: 324080017
Test: build pass, raise_softirq can be used
Change-Id: I675d5927d000ae5c372e6a88a1eda3101152e709
Signed-off-by: Paul Chen <chenpaul@google.com>
commit e26d3009efda338f19016df4175f354a9bd0a4ab upstream.
Never used from userspace, disallow these parameters.
Bug: 329205828
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b7be6c737a179a76901c872f6b4c1d00552d9a1b)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I3d8358a6dee3246e3ac56697dbb2be8fdc5f716f
alloc_contig_migrate_range has every information to be able to understand
big contiguous allocation latency. For example, how many pages are
migrated, how many times they were needed to unmap from page tables.
This patch adds the trace event to collect the allocation statistics. In
the field, it was quite useful to understand CMA allocation latency.
[akpm@linux-foundation.org: a/trace_mm_alloc_config_migrate_range_info_enabled/trace_mm_alloc_contig_migrate_range_info_enabled]
Link: https://lkml.kernel.org/r/20240228051127.2859472-1-richardycc@google.com
Signed-off-by: Richard Chang <richardycc@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org.
Cc: Martin Liu <liumartin@google.com>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 315897534
(cherry picked from commit c8b36003121834cb77fcaf8a1ce0a454d7a97891
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-stable)
[richardycc: slight modification for android change 0de2f42977]
Change-Id: If6c3cd106201fd13683d1dd5afdfa62a48a4dd3b
Signed-off-by: Richard Chang <richardycc@google.com>
This fix is applicable for LTS kernel, 6.1.y. In latest kernels, this race
issue is fixed by the patch series [1] and [2]. The right thing to do here
would have been propagating these changes from latest kernel to the stable
branch, 6.1.y. However, these changes seems too intrusive to be picked for
stable branches. Hence, the fix proposed can be taken as an alternative
instead of backporting the patch series.
[1] https://lore.kernel.org/all/0-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.com/
[2] https://lore.kernel.org/all/0-v5-1b99ae392328+44574-iommu_err_unwind_jgg@nvidia.com/
Issue:
A race condition is observed when arm_smmu_device_probe and
modprobe of client devices happens in parallel. This results
in the allocation of a new default domain for the iommu group
even though it was previously allocated and the respective iova
domain(iovad) was initialized. However, for this newly allocated
default domain, iovad will not be initialized. As a result, for
devices requesting dma allocations, this uninitialized iovad will
be used, thereby causing NULL pointer dereference issue.
Flow:
- During arm_smmu_device_probe, bus_iommu_probe() will be called
as part of iommu_device_register(). This results in the device probe,
__iommu_probe_device().
- When the modprobe of the client device happens in parallel, it
sets up the DMA configuration for the device using of_dma_configure_id(),
which inturn calls iommu_probe_device(). Later, default domain is
allocated and attached using iommu_alloc_default_domain() and
__iommu_attach_device() respectively. It then ends up initializing a
mapping domain(IOVA domain) and rcaches for the device via
arch_setup_dma_ops()->iommu_setup_dma_ops().
- Now, in the bus_iommu_probe() path, it again tries to allocate
a default domain via probe_alloc_default_domain(). This results in
allocating a new default domain(along with IOVA domain) via
__iommu_domain_alloc(). However, this newly allocated IOVA domain
will not be initialized.
- Now, when the same client device tries dma allocations via
iommu_dma_alloc(), it ends up accessing the rcaches of the newly
allocated IOVA domain, which is not initialized. This results
into NULL pointer dereferencing.
Fix this issue by adding a check in probe_alloc_default_domain()
to see if the iommu_group already has a default domain allocated
and initialized. Adding a check in iommu_group_alloc_default_domain
would not allow changing the default domain for an iommu group, via,
iommu_change_dev_def_domain. As per the suggestions from upstream review
for patch [3], the check for default domain was moved and duplicated into
the callers, thereby restricting it only to the probe paths.
[3] https://lore.kernel.org/all/e605b38a2d40b1e7589e10110c6d3ece35f6af4e.1705571894.git.quic_nprakash@quicinc.com/
Bug: 317188933
Link: https://lore.kernel.org/all/cbf1295589bd90083ad6f75a7fbced01f327c047.1708680521.git.quic_nprakash@quicinc.com/
Change-Id: I060d5b796911b1a597495d003e83cff0fd8b7625
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Co-developed-by: Nikhil V <quic_nprakash@quicinc.com>
Signed-off-by: Nikhil V <quic_nprakash@quicinc.com>
Since the kernel now has dynamic Shadow Call Stack (SCS) enabled, on
CPUs that don't support Pointer Authentication Codes (PAC) the kernel
runtime-patches paciasp and autiasp instructions into instructions that
push and pop from the shadow call stack. This includes instructions in
loaded modules. This broke the fips140 integrity check which needs to
know how to undo all text changes made by the module loader in order to
re-create the original text.
Fix this by updating fips140.ko to undo the dynamic SCS patching.
Bug: 188620248
Change-Id: I992bcd6c34b3340c6489b40a125715e1304cb445
Signed-off-by: Eric Biggers <ebiggers@google.com>
There now have been two times where I've had to debug the fips140
integrity check failing due to a new type of runtime code patching.
Debugging such issues requires dumping the text and rodata actually used
for the integrity check and comparing them with the originals. Add a
kconfig option to make this easier. Similar to
CRYPTO_FIPS140_MOD_EVAL_TESTING, the production build won't use this.
Bug: 188620248
Change-Id: I392de466ff31f999d65997dbc610e23e9eeca49d
Signed-off-by: Eric Biggers <ebiggers@google.com>
The DisplayPort driver's sysfs nodes may be present to the userspace before
typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that
a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in
hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns
NULL in those cases.
Remove manual sysfs node creation in favor of adding attribute group as
default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is
not used here otherwise the path to the sysfs nodes is no longer compliant
with the ABI.
Fixes: 0e3bb7d689 ("usb: typec: Add driver for DisplayPort alternate mode")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Link: https://lore.kernel.org/r/20240229001101.3889432-2-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 313517804
(cherry picked from commit 165376f6b23e9a779850e750fb2eb06622e5a531)
Signed-off-by: RD Babiera <rdbabiera@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:884fea555f0af00dee9fefefa5bb38eb4ed251b5)
Merged-In: I13aaa956ff2b37e29eb0d90bbac0b7e1ac969b80
Change-Id: I13aaa956ff2b37e29eb0d90bbac0b7e1ac969b80
We are observing huge contention on the epmutex during an http
connection/rate test:
83.17% 0.25% nginx [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe
[...]
|--66.96%--__fput
|--60.04%--eventpoll_release_file
|--58.41%--__mutex_lock.isra.6
|--56.56%--osq_lock
The application is multi-threaded, creates a new epoll entry for
each incoming connection, and does not delete it before the
connection shutdown - that is, before the connection's fd close().
Many different threads compete frequently for the epmutex lock,
affecting the overall performance.
To reduce the contention this patch introduces explicit reference counting
for the eventpoll struct. Each registered event acquires a reference,
and references are released at ep_remove() time.
The eventpoll struct is released by whoever - among EP file close() and
and the monitored file close() drops its last reference.
Additionally, this introduces a new 'dying' flag to prevent races between
the EP file close() and the monitored file close().
ep_eventpoll_release() marks, under f_lock spinlock, each epitem as dying
before removing it, while EP file close() does not touch dying epitems.
The above is needed as both close operations could run concurrently and
drop the EP reference acquired via the epitem entry. Without the above
flag, the monitored file close() could reach the EP struct via the epitem
list while the epitem is still listed and then try to put it after its
disposal.
An alternative could be avoiding touching the references acquired via
the epitems at EP file close() time, but that could leave the EP struct
alive for potentially unlimited time after EP file close(), with nasty
side effects.
With all the above in place, we can drop the epmutex usage at disposal time.
Overall this produces a significant performance improvement in the
mentioned connection/rate scenario: the mutex operations disappear from
the topmost offenders in the perf report, and the measured connections/rate
grows by ~60%.
To make the change more readable this additionally renames ep_free() to
ep_clear_and_put(), and moves the actual memory cleanup in a separate
ep_free() helper.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Xiumei Mu <xmu@redhiat.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Jacob Keller <jacob.e.keller@intel.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.kernel.org/r/4a57788dcaf28f5eb4f8dfddcc3a8b172a7357bb.1679504153.git.pabeni@redhat.com
Bug: 329052712
Change-Id: I78254b584f6fb1c20a1e11b7033d93a7c9fd65fb
(cherry picked from commit 58c9b016e12855286370dfb704c08498edbc857a)
Signed-off-by: Pradeep P V K <quic_pragalla@quicinc.com>
'commit b6115e14010 ("ANDROID: uid_sys_stat: split the global
lock uid_lock to the fine-grained locks for each hlist in hash_table.")'
The above patch split the global lock to per-uid lock to reduce lock
competition. But result in data-error from uid_cputime_show and uid_io_show in
some cases.
E.g, if thread1 and thread2 read /proc/uid_cputime/show_uid_stat at the same time,
thread2 maybe operate in partA and zero active_stime and active_utime of uid_entry
when thread1 is between partB and partC, which would cause thread1 show the error data.
static int uid_cputime_show(struct seq_file *m, void *v)
{
...
/*partA*/
for (bkt = 0, uid_entry = NULL; uid_entry == NULL &&
bkt < HASH_SIZE(hash_table); bkt++) {
lock_uid_by_bkt(bkt);
hlist_for_each_entry(uid_entry, &hash_table[bkt], hash) {
uid_entry->active_stime = 0;
uid_entry->active_utime = 0;
}
unlock_uid_by_bkt(bkt);
}
rcu_read_lock();
/* partB */
do_each_thread(temp, task) {
...
lock_uid(uid);
if (!(task->flags & PF_EXITING)) {
task_cputime_adjusted(task, &utime, &stime);
uid_entry->active_utime += utime;
uid_entry->active_stime += stime;
}
unlock_uid(uid);
} while_each_thread(temp, task);
rcu_read_unlock();
for (bkt = 0, uid_entry = NULL; uid_entry == NULL &&
bkt < HASH_SIZE(hash_table); bkt++) {
lock_uid_by_bkt(bkt);
hlist_for_each_entry(uid_entry, &hash_table[bkt], hash) {
u64 total_utime = uid_entry->utime +
uid_entry->active_utime;
u64 total_stime = uid_entry->stime +
uid_entry->active_stime;
/* partC */
seq_printf(m, "%d: %llu %llu\n", uid_entry->uid,
ktime_to_us(total_utime), ktime_to_us(total_stime));
}
unlock_uid_by_bkt(bkt);
}
The patch ensures that the calculation and seq_printf of each uid_entry is within
the uid_lock range, in order to accurate data.
Bug: 278138377
Change-Id: Iaa2ccd95c4b4b333f04b2ba18d7699d94017394e
Signed-off-by: lipeifeng <lipeifeng@oppo.com>
(cherry picked from commit ea35d2bd073214e84be242287a2e91741c6588ed)
Enable this config to add scmi-virtio transport procotol
Bug: 326840729
Change-Id: I006afe8686eb4b7db0aa2baa93db44a1518d700c
Signed-off-by: Hang Wei <hang01.wei@samsung.com>
This reverts commit 1dbafe61e3.
Reason for revert: Too early. Needs to wait until 2024-03-27
Change-Id: I769b944bd089aa2278659ec87f7ba4ac4e74ee4a
Signed-off-by: Todd Kjos <tkjos@google.com>
[ Upstream commit 32b55c5ff9103b8508c1e04bfa5a08c64e7a925f ]
tls_decrypt_sg doesn't take a reference on the pages from clear_skb,
so the put_page() in tls_decrypt_done releases them, and we trigger
a use-after-free in process_rx_list when we try to read from the
partially-read skb.
Bug: 326214405
Fixes: fd31f3996a ("tls: rx: decrypt into a fresh skb")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit d684763534b969cca1022e2a28645c7cc91f7fa5)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ifdd765d0af082523d1432436b6f6d2c094c48dca
This patch add GKI symbol list for Exynosauto SoC.
We need to add 2 functions symbol to support our vdriver.
2 function symbol(s) added
'unsigned long devm_get_free_pages(struct device*, gfp_t, unsigned int)'
'int kill_pid(struct pid*, int, int)'
Bug: 326148350
Signed-off-by: Kisung Lee <kiisung.lee@samsung.com>
Change-Id: Ia8dca21f474b41bf206ad0333e5b0b2649f96ae6
usb: typec: class: fix typec_altmode_put_partner to put plugs
When typec_altmode_put_partner is called by a plug altmode upon release,
the port altmode the plug belongs to will not remove its reference to the
plug. The check to see if the altmode being released is a plug evaluates
against the released altmode's partner instead of the calling altmode, so
change adev in typec_altmode_put_partner to properly refer to the altmode
being released.
Because typec_altmode_set_partner calls get_device() on the port altmode,
add partner_adev that points to the port altmode in typec_put_partner to
call put_device() on. typec_altmode_set_partner is not called for port
altmodes, so add a check in typec_altmode_release to prevent
typec_altmode_put_partner() calls on port altmode release.
Fixes: 8a37d87d72 ("usb: typec: Bus type for alternate modes")
Cc: <stable@vger.kernel.org>
Co-developed-by: Christian A. Ehrhardt <lk@c--e.de>
Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
Signed-off-by: RD Babiera <rdbabiera@google.com>
Tested-by: Christian A. Ehrhardt <lk@c--e.de>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20240103181754.2492492-2-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 324496488
(cherry picked from commit 5962ded777d689cd8bf04454273e32228d7fb71f)
Change-Id: I688a333753b2e8069c0437a6d9dea30bf029c92c
Signed-off-by: RD Babiera <rdbabiera@google.com>
This reverts commit b17b7fe6dd5c6ff74b38b0758ca799cdbb79e26e.
That commit messed up the reference counting, so it needs to
be rethought.
Fixes: b17b7fe6dd5c ("usb: typec: class: fix typec_altmode_put_partner to put plugs")
Cc: stable@vger.kernel.org
Cc: RD Babiera <rdbabiera@google.com>
Reported-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Closes: https://lore.kernel.org/lkml/CAP-bSRb3SXpgo_BEdqZB-p1K5625fMegRZ17ZkPE1J8ZYgEHDg@mail.gmail.com/
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Bug: 324496488
(cherry picked from commit 9c6b789e954fae73c548f39332bcc56bdf0d4373)
Change-Id: I2755a5e44dd1970d60e5d996dd7fc6d88f79684a
Signed-off-by: RD Babiera <rdbabiera@google.com>
We will encounter below inconsistent status when FAULT_BLKADDR type
fault injection is on.
Info: checkpoint state = d6 : nat_bits crc fsck compacted_summary orphan_inodes sudden-power-off
[ASSERT] (fsck_chk_inode_blk:1254) --> ino: 0x1c100 has i_blocks: 000000c0, but has 191 blocks
[FIX] (fsck_chk_inode_blk:1260) --> [0x1c100] i_blocks=0x000000c0 -> 0xbf
[FIX] (fsck_chk_inode_blk:1269) --> [0x1c100] i_compr_blocks=0x00000026 -> 0x27
[ASSERT] (fsck_chk_inode_blk:1254) --> ino: 0x1cadb has i_blocks: 0000002f, but has 46 blocks
[FIX] (fsck_chk_inode_blk:1260) --> [0x1cadb] i_blocks=0x0000002f -> 0x2e
[FIX] (fsck_chk_inode_blk:1269) --> [0x1cadb] i_compr_blocks=0x00000011 -> 0x12
[ASSERT] (fsck_chk_inode_blk:1254) --> ino: 0x1c62c has i_blocks: 00000002, but has 1 blocks
[FIX] (fsck_chk_inode_blk:1260) --> [0x1c62c] i_blocks=0x00000002 -> 0x1
After we inject fault into f2fs_is_valid_blkaddr() during truncation,
a) it missed to increase @nr_free or @valid_blocks
b) it can cause in blkaddr leak in truncated dnode
Which may cause inconsistent status.
This patch separates FAULT_BLKADDR_CONSISTENCE from FAULT_BLKADDR,
and rename FAULT_BLKADDR to FAULT_BLKADDR_VALIDITY
so that we can:
a) use FAULT_BLKADDR_CONSISTENCE in f2fs_truncate_data_blocks_range()
to simulate inconsistent issue independently, then it can verify fsck
repair flow.
b) FAULT_BLKADDR_VALIDITY fault will not cause any inconsistent status,
we can just use it to check error path handling in kernel side.
Reviewed-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 313549450
(cherry picked from commit c7115e094ca820bb72e0c89f158d16bc48c6fa04
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: Ifd6527aa2e48d883ae4063bfce1a404ccfbdaa48
Signed-off-by: Daeho Jeong <daehojeong@google.com>
In reserve_compress_blocks(), we update blkaddrs of dnode in prior to
inc_valid_block_count(), it may cause inconsistent status bewteen
i_blocks and blkaddrs once inc_valid_block_count() fails.
To fix this issue, it needs to reverse their invoking order.
Fixes: c75488fb4d ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS")
Reviewed-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 313549450
(cherry picked from commit 54607494875edd636aff3c21ace3ad9a7da758a9
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: I74a5d1d47246d39b1ed0131c714c6a2a2bfab6cf
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Compressed cluster may not be released due to we can fail in
release_compress_blocks(), fix to handle reserved compressed
cluster correctly in reserve_compress_blocks().
Fixes: 4c8ff7095b ("f2fs: support data compression")
Signed-off-by: Sheng Yong <shengyong@oppo.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 313549450
(cherry picked from commit eb8fbaa53374e0a2d4381190abfe708481517bbb
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: I2a4223efb548a921a8f28f45798709743e38e899
Signed-off-by: Daeho Jeong <daehojeong@google.com>
When we overwrite compressed cluster w/ normal cluster, we should
not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data
will be corrupted if partial blocks were persisted before CP & SPOR,
due to cluster metadata wasn't updated atomically.
Fixes: 4c8ff7095b ("f2fs: support data compression")
Reviewed-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 313549450
(cherry picked from commit fd244524c2cf07b5f4c3fe8abd6a99225c76544b
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: I231eef3eb7ee5a105ad929718a6d1d67f4950dd2
Signed-off-by: Daeho Jeong <daehojeong@google.com>
If data block in compressed cluster is not persisted with metadata
during checkpoint, after SPOR, the data may be corrupted, let's
guarantee to write compressed page by checkpoint.
Fixes: 4c8ff7095b ("f2fs: support data compression")
Reviewed-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 313549450
(cherry picked from commit 8a430dd49e9cb021372b0ad91e60aeef9c6ced00
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: Ie52d0bc7d89ec3111f1f6e8140555358620e875c
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Don't check the "LTO" variable in build.config.gki.aarch64.fips140,
since fips140.ko no longer depends on LTO. Also, Kleaf doesn't set the
"LTO" variable anyway; it was specific to build.sh.
Bug: 188620248
Change-Id: I213faa4c8c1a23898c08da121b0a5dc602b7218a
Signed-off-by: Eric Biggers <ebiggers@google.com>
Symbols updated to QCOM abi symbol list for Toshiba EMAC:
clk_unregister_fixed_rate
get_phy_device
__hw_addr_sync_dev
netdev_features_change
pcie_capability_read_dword
phy_device_free
phy_device_register
phy_loopback
phy_lookup_setting
phy_restart_aneg
Bug: 325987248
Change-Id: I0f4a1070283f2e9c98df4de9da0660e572a7826e
Signed-off-by: Andre Ding <quic_shuangxi@quicinc.com>
CONFIG_TASK_DELAY_ACCT cannot be enabled since `struct task_struct`
is KMI frozen. Instead, use vendor hooks to allow delay accounting
to be implemented in a vendor module.
Bug: 327566572
Bug: 310129610
Bug: 314931189
Change-Id: If814d7834889fe162aba3dd97e935289127ca3ae
Signed-off-by: Dongyun Liu <dongyun.liu@transsion.com>
(cherry picked from commit bb57557246d39dba8a66df7f43983fe1ec71bff6)
(cherry picked from commit 896cff873452d9a3853c489bb2a173a1e290ca95)
Revert commit 9b476ebe99 in preparation of making this a
Pixel-specific change. A disadvantage of building null_blk and
scsi_debug as kernel modules for all vendors is that this causes these
kernel modules to be loaded by the init process during boot and there is
no vendor-independent mechanism for preventing kernel modules to be
loaded.
Bug: 323406846
Change-Id: I6e7bcdd9fd06194bbc134ee52251b6ae9a3c1477
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This reverts commit ee42bfc791 which is
commit af42269c3523492d71ebbe11fefae2653e9cdc78 upstream.
It is reported to cause crashes, so revert it for now.
Bug: 326555421
Change-Id: I2fb3626c306e0444f4e0eb42a95488e688942ba9
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Vendors might want to change tasks affinity settings when they are
moving from one cpuset into the other. Add vendor hook to give control
to vendor to implement what they need.
This reverts commit a42f6e7d0aa0("Revert "ANDROID: sched/cpuset: Add
vendor hook to change tasks affinity"") to effectively bring back the
original change.
Bug: 323765868
Change-Id: I47c1ee0dabda491732932c653bd80e95ee550791
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Signed-off-by: Sai Harshini Nimmala <quic_snimmala@quicinc.com>
When cpu loading is high, the task maybe preempted after restoring the
sched priority in trace_android_vh_binder_free_buf(). This means that
node->has_async_transaction can't be cleared immediately and the work
isn't added to the proc->todo queue as soon as possible.
To fix this we add a new hook trace_android_vh_binder_buffer_release()
to restore the priority after node->has_async_transaction has been
updated and the node->work has been added to the proc->todo queue.
Note: the old trace_android_vh_binder_free_buf() hook is kept to avoid
breaking KMI but is not extrictly needed.
Bug: 327307900
Fixes: 0eb66ec39ca8 ("ANDROID: vendor_hooks: Add hooks for binder")
Change-Id: I8126c79c9c68faa3ce0cd87ce83e2591bd61d5dd
Signed-off-by: Fuchun Liao <lfc@oppo.com>
[cmllamas: fix-up commit log and variable naming]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit 0db211ec0f which is
commit 13619170303878e1dae86d9a58b039475c957fcf upstream.
It is reported to cause crashes, so revert it for now.
Bug: 326555421
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3dd7744a9b706a959cbed3a793be668147dfcb9a
Commit 1fd54773c267 ("udp: allow header check for dodgy GSO_UDP_L4
packets.") checks DODGY bit for UDP, but for packets that can be fed
directly to the device after gso_segs reset, it actually falls through
to fragmentation:
https://lore.kernel.org/all/CAJPywTKDdjtwkLVUW6LRA2FU912qcDmQOQGt2WaDo28KzYDg+A@mail.gmail.com/
This change restores the expected behavior of GSO_UDP_L4 packets.
Fixes: 1fd54773c267 ("udp: allow header check for dodgy GSO_UDP_L4 packets.")
Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Change-Id: Id7ff0fac79fb0b4fabb62b09a905f27a5e8cfea7
(cherry picked from commit 9840036786d90cea11a90d1f30b6dc003b34ee67)
[lena: Resolved conflict in net/ipv6/udp_offload.c ]
Signed-off-by: Yan Zhai <yan@cloudflare.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ajay Agarwal
Serge Semin
chenweitao
Prashanth K
Daniel Rosenberg
Paul Chen
Pablo Neira Ayuso
Richard Chang
Charan Teja Kalla
Eric Biggers
Jaegeuk Kim
Jia-Shiuan Chen
RD Babiera
Paolo Abeni
Wei Liu
lipeifeng
Hang Wei
Todd Kjos
Sabrina Dubroca
Greg Kroah-Hartman
Kisung Lee
Seiya Wang
Chao Yu
Sheng Yong
Andre Ding
Dongyun Liu
Bart Van Assche
xiaofeng
Sai Harshini Nimmala
lfc
Yan Zhai