Simply clean up symbol order to recognize changes easily.
There are no changes on symbol.
Bug: 330635812
Change-Id: I10a83b2ceb56c34bad57068bab58e48e7e753991
Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com>
The hyp event host_hcall was missing when a custom HVC runs.
Bug: 278749606
Bug: 244543039
Bug: 244373730
Change-Id: I760cab4fbd36a13ad262842880d9ec484f23fd22
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
(cherry picked from commit a1836ffbea9fcb70fa9d49af7382b9343285036f)
Adding the following symbols:
- blk_queue_max_segment_size
Bug: 269652215
Change-Id: Ie599f23056fd0f6641df6dba57e48413b144fa1b
Signed-off-by: Robin Peng <robinpeng@google.com>
LPM feature of DWC2 module integrated in Rockchip SoCs doesn't work
properly or needs some additional handling, so disable it for now.
Without disabling LPM feature, the USB ADB communication fail with
the following error log:
dwc2 ff580000.usb: new address 27
dwc2 ff580000.usb: Failed to exit L1 sleep state in 200us.
dwc2 ff580000.usb: dwc2_hsotg_send_reply: cannot queue req
dwc2 ff580000.usb: dwc2_hsotg_process_req_status: failed to send reply
dwc2 ff580000.usb: dwc2_hsotg_enqueue_setup: failed queue (-11)
dwc2 ff580000.usb: Failed to exit L1 sleep state in 200us.
[diff vs vendor kernel: added lpm_clock_gating, besl and
hird_threshold_en settings as seen in commit 53febc9569 ("usb: dwc2:
disable Link Power Management on STM32MP15 HS OTG")]
Bug: 300024866
Change-Id: Ib8ae241dce5993e34b6cf8e83254b2730effe009
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20221206-dwc2-gadget-dual-role-v1-1-36515e1092cd@theobroma-systems.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 42a317d076)
This reverts commit fa6c89a93f.
Reason for revert: Only reverting the prerequisite CL. Will revert the dependent aosp/3007694 once it's safe.
Bug: 324290965
Test: tools/bazel run //common-modules/virtual-device:virtual_device_aarch64_dist
Change-Id: I4f4caf7916e8030b6fe4f407c41a593c4916f43f
Signed-off-by: Istvan Nador <istvannador@google.com>
The tail pages in a THP can have swap entry information stored in their
private field. When migrating to a new page, all tail pages of the new
page need to update ->private to avoid future data corruption.
This fix is stable-only, since after commit 07e09c483c ("mm/huge_memory:
work on folio->swap instead of page->private when splitting folio"),
subpages of a swapcached THP no longer requires the maintenance.
Adding THPs to the swapcache was introduced in commit
38d8b4e6bd ("mm, THP, swap: delay splitting THP during swap out"),
where each subpage of a THP added to the swapcache had its own swapcache
entry and required the ->private field to point to the correct swapcache
entry. Later, when THP migration functionality was implemented in commit
616b837153 ("mm: thp: enable thp migration in generic path"),
it initially did not handle the subpages of swapcached THPs, failing to
update their ->private fields or replace the subpage pointers in the
swapcache. Subsequently, commit e71769ae52 ("mm: enable thp migration
for shmem thp") addressed the swapcache update aspect. This patch fixes
the update of subpage ->private fields.
Bug: 324818390
Fixes: 616b837153 ("mm: thp: enable thp migration in generic path")
Link: https://lore.kernel.org/linux-mm/20240306155217.118467-1-zi.yan@sent.com/
Reported-and-tested-by: Charan Teja Kalla <quic_charante@quicinc.com>
Change-Id: Ia4603cd58b76dc6ff46a2c53a735942a87221419
Signed-off-by: Zi Yan <ziy@nvidia.com>
Acked-by: David Hildenbrand <david@redhat.com>
Closes: https://lore.kernel.org/linux-mm/1707814102-22682-1-git-send-email-quic_charante@quicinc.com/
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Gunyah resource manager has limited internal buffering to send messages
to VMs and it is possible to fill the buffer and cause RM to drop
replies. Prevent the "drop" scenario by serializing the entire
send/receive RPC flow.
Bug: 330201551
Change-Id: I65f2f6daf495eb24e1bc120a6a4d0b84c966e3cc
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Add support for configuring the maximum segment size.
Add support for segments smaller than the page size.
This patch enables testing segments smaller than the page size with a
driver that does not call blk_rq_map_sg().
Bug: 308663717
Bug: 319125789
Change-Id: Idd7094e9f773c295017b44377d2a3f10abea95cf
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Juan Yescas <jyescas@google.com>
Add a kernel module parameter for configuring the maximum segment size.
This patch enables testing SCSI support for segments smaller than the
page size.
Bug: 308663717
Bug: 319125789
Change-Id: I1d9f1714876de72630cbf3150e7082b988dd7322
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Juan Yescas <jyescas@google.com>
Add support in the bio splitting code and also in the bio submission code
for bios with segments smaller than the page size.
Bug: 308663717
Bug: 319125789
Change-Id: I056659cf86c04fb095aa01cd3d274d29417782ac
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Juan Yescas <jyescas@google.com>
If the segment size is smaller than the page size there may be multiple
segments per bvec even if a bvec only contains a single page. Hence this
patch.
Bug: 308663717
Bug: 319125789
Change-Id: I81516bf6da8ce3e4e60651ab2bd379080e7d3482
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Juan Yescas <jyescas@google.com>
This new debugfs attribute makes it easier to verify the code that tracks
how many queues require limits below the page size.
Bug: 308663717
Bug: 319125789
Change-Id: I2ee54a9e4544866e71b505ae9296b68039d5ca82
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
[jyescas@google.com: Wrap #include "blk-mq-debugfs.h" with
#ifndef __GENKSYSM__ to avoid ABI CRC
changes.]
Signed-off-by: Juan Yescas <jyescas@google.com>
Allow block drivers to configure the following:
* Maximum number of hardware sectors values smaller than
PAGE_SIZE >> SECTOR_SHIFT. For PAGE_SIZE = 4096 this means that values
below 8 become supported.
* A maximum segment size below the page size. This is most useful
for page sizes above 4096 bytes.
The blk_sub_page_segments static branch will be used in later patches to
prevent that performance of block drivers that support segments >=
PAGE_SIZE and max_hw_sectors >= PAGE_SIZE >> SECTOR_SHIFT would be affected.
This patch may change the behavior of existing block drivers from not
working into working. If a block driver calls
blk_queue_max_hw_sectors() or blk_queue_max_segment_size(), this is
usually done to configure the maximum supported limits. An attempt to
configure a limit below what is supported by the block layer causes the
block layer to select a larger value. If that value is not supported by
the block driver, this may cause other data to be transferred than
requested, a kernel crash or other undesirable behavior.
Keeps the ABI stable by taking advantage of hole in struct queue_limits.
Bug: 308663717
Bug: 319125789
Bug: 324152549
Change-Id: I7358f3e16aa0c80a6d345cb7887fbe9276e52912
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
[jyescas@google.com: disable subpage limits in block/blk-sysfs.c
instead block/blk-core.c because the function
blk_free_queue() is not defined in 6.1 kernel]
Signed-off-by: Juan Yescas <jyescas@google.com>
Introduce variables that represent the lower configuration bounds. This
patch does not change any functionality.
Bug: 308663717
Bug: 319125789
Change-Id: Ie88bfa6b716a43ca7e95a67fad267bdb1507015f
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Juan Yescas <jyescas@google.com>
Switch to the modern style of printing kernel messages. Use %u instead
of %d to print unsigned integers.
The pr_fmt() format is added on top of the file to include __func__
in the pr_info() calls.
Bug: 308663717
Bug: 319125789
Change-Id: I11dbb559263ae5ef18febc7ab89f27f231e511e2
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
[jyescas@google.com: define pr_fmt(fmt) to include __func__ in the output]
Signed-off-by: Juan Yescas <jyescas@google.com>
Add vendor hook android_vh_sound_check_support_cpu_suspend
to allow ACPU to suspend during USB playback/capture,
if this is supported.
Bug: 329345852
Bug: 192206510
Change-Id: Ia8d4c335db27de5fcefab13cab653fd1ae34f691
Signed-off-by: JJ Lee <leejj@google.com>
(cherry picked from commit e8516fd3af)
(cherry picked from commit 4cbf19a6f8)
Add the hook that vendor can design and bypass the suspend/resume.
When the bypass is set, skip the orignal suspend/resume methods.
In mobile, a co-processor can be used with USB audio, and ACPU may
be able to sleep in such condition to improve power consumption.
We will need vendor hook to support this.
Bug: 329345852
Bug: 302982919
Signed-off-by: Puma Hsu <pumahsu@google.com>
Change-Id: Ic62a8a1e662bbe3fb0aa17af7491daace0b9f18a
(cherry picked from commit 98085b5dd8)
(cherry picked from commit 358b59f1bc)
Currently, the linker script's support for merging module's section is
guarded by either CONFIG_LTO_CLANG or CONFIG_CRYPTO_FIPS140_MOD. This
functionally is also needed by additional fips140 modules built out of
tree. So, have an explicit config (CRYPTO_FIPS140_MERGE_MOD_SECTIONS)
that can be selected by the various fips140 modules without having to
depend on and enabling CONFIG_CRYPTO_FIPS140_MOD.
Bug: 281657135
Change-Id: I2af727813151ba839a95696bc847e2a841a7175a
Signed-off-by: Konstantin Vyshetsky <vkon@google.com>
When driver uses pm_runtime_force_suspend() as the system suspend callback
function and registers the wake irq with reverse enable ordering, the wake
irq will be re-enabled when entering system suspend, triggering an
'Unbalanced enable for IRQ xxx' warning. In this scenario, the call
sequence during system suspend is as follows:
suspend_devices_and_enter()
-> dpm_suspend_start()
-> dpm_run_callback()
-> pm_runtime_force_suspend()
-> dev_pm_enable_wake_irq_check()
-> dev_pm_enable_wake_irq_complete()
-> suspend_enter()
-> dpm_suspend_noirq()
-> device_wakeup_arm_wake_irqs()
-> dev_pm_arm_wake_irq()
To fix this issue, complete the setting of WAKE_IRQ_DEDICATED_ENABLED flag
in dev_pm_enable_wake_irq_complete() to avoid redundant irq enablement.
Bug: 330244514
(cherry picked from commit e7a7681c859643f3f2476b2a28a494877fd89442
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next)
Fixes: 8527beb120 ("PM: sleep: wakeirq: fix wake irq arming")
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Qingliang Li <qingliang.li@mediatek.com>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Cc: 5.16+ <stable@vger.kernel.org> # 5.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Change-Id: I46ba27631ed5561123bd98dd32872837b726b5bd
There is no new symbol to be added. We just try to update our symbol list.
Bug: 330272507
Change-Id: I1acb83c75c0dd4f594f8cbcdf341fe8dbef5bf26
Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com>
Currently for dwc3_usb31 controller, if maximum_speed is limited to
super-speed in DT, then device mode is limited to SS, but host mode
still works in SSP.
The documentation for max-speed property is as follows:
"Tells USB controllers we want to work up to a certain speed.
Incase this isn't passed via DT, USB controllers should default to
their maximum HW capability."
It doesn't specify that the property is only for device mode.
There are cases where we need to limit the host's maximum speed to
SuperSpeed only. Use this property for host mode to contrain host's
speed to SuperSpeed.
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20231219041559.15789-1-quic_kriskura@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 91736d0619eb4083f33ae737b9d9763fc6b196ed
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master)
Bug: 329199528
Change-Id: Ic36953592a899ae263f900ee885c09033a11d910
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
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 6c784e21b3)
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 e26d3009ef 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 b7be6c737a)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I3d8358a6dee3246e3ac56697dbb2be8fdc5f716f
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 58c9b016e1)
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>
