This introduces a new environment variable, KCPPFLAGS_COMPAT.
One use-case is to ensure -ffile-prefix-map is passed to the arm32
compiler to normalise compilation directory and make the ELF build ID
reproducible.
Bug: 345452375
Change-Id: I6ae1df58172f4dadeac1dbbee2e3241b704a9256
Signed-off-by: Giuliano Procida <gprocida@google.com>
Enable configs required for Broadcom Set Top Box SoCs.
Also explicitly disable the Broadcom Set Top Box SoC
drivers that we wish to build as loadable modules.
Bug: 343006993
Change-Id: Ia3e542d0eeb519539aba2990fb4eb4eb2970a867
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
Requesting a retune before switching to the RPMB partition has been
observed to cause CRC errors on the RPMB reads (-EILSEQ).
Since RPMB reads can not be retried, the clients would be directly
affected by the errors.
This commit disables the retune request prior to switching to the RPMB
partition: mmc_retune_pause() no longer triggers a retune before the
pause period begins.
This was verified with the sdhci-of-arasan driver (ZynqMP) configured
for HS200 using two separate eMMC cards (DG4064 and 064GB2). In both
cases, the error was easy to reproduce triggering every few tenths of
reads.
With this commit, systems that were utilizing OP-TEE to access RPMB
variables will experience an enhanced performance. Specifically, when
OP-TEE is configured to employ RPMB as a secure storage solution, it not
only writes the data but also the secure filesystem within the
partition. As a result, retrieving any variable involves multiple RPMB
reads, typically around five.
For context, on ZynqMP, each retune request consumed approximately
8ms. Consequently, reading any RPMB variable used to take at the very
minimum 40ms.
After droping the need to retune before switching to the RPMB partition,
this is no longer the case.
Change-Id: I2320a38436b05b435ac528c6656b621a1e2eaeb7
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Avri Altman <avri.altman@wdc.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20240103112911.2954632-1-jorge@foundries.io
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 67380251e8bbd3302c64fea07f95c31971b91c22)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
The driver used to truncate several 64-bit registers such as PMCEID[n]
registers used to describe whether architectural and microarchitectural
events in range 0x4000-0x401f exist. Due to discarding the bits, the
driver made the events invisible, even if they existed.
Moreover, PMCCFILTR and PMCR registers have additional bits in the upper
32 bits. This patch makes them available although they aren't currently
used. Finally, functions handling PMXEVCNTR and PMXEVTYPER registers are
removed as they not being used at all.
Fixes: df29ddf4f04b ("arm64: perf: Abstract system register accesses away")
Reported-by: Carl Worth <carl@os.amperecomputing.com>
Change-Id: Ic2ec717caa2fdda2456c560a82490e374565eb2d
Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
Acked-by: Will Deacon <will@kernel.org>
Closes: https://lore.kernel.org/..
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20231102183012.1251410-1-ilkka@os.amperecomputing.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit 403edfa436286b21f5ffe6856ae5b36396e8966c)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
A few PHY drivers are currently attempting to not suspend the PHY when
Wake-on-LAN is enabled, however that code is not currently executing at
all due to an early check in phy_suspend().
This prevents PHY drivers from making an appropriate decisions and put
the hardware into a low power state if desired.
In order to allow the PHY drivers to opt into getting their ->suspend
routine to be called, add a PHY_ALWAYS_CALL_SUSPEND bit which can be
set. A boolean that tracks whether the PHY or the attached MAC has
Wake-on-LAN enabled is also provided for convenience.
If phydev::wol_enabled then the PHY shall not prevent its own
Wake-on-LAN detection logic from working and shall not prevent the
Ethernet MAC from receiving packets for matching.
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Change-Id: I9077fe16d2515b60a2cb58753e6914be95a6923a
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a7e3448086d580abadccff399316c6eb5ecdedbf)
[danesh: Moved phydev->wol_enabled to avoid KMI-break]
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
When just including <asm/arm_pmuv3.h>:
arch/arm/include/asm/arm_pmuv3.h:110:13: error: ‘write_pmevtypern’ defined but not used [-Werror=unused-function]
110 | static void write_pmevtypern(int n, unsigned long val)
| ^~~~~~~~~~~~~~~~
arch/arm/include/asm/arm_pmuv3.h:103:13: error: ‘write_pmevcntrn’ defined but not used [-Werror=unused-function]
103 | static void write_pmevcntrn(int n, unsigned long val)
| ^~~~~~~~~~~~~~~
arch/arm/include/asm/arm_pmuv3.h:95:22: error: ‘read_pmevcntrn’ defined but not used [-Werror=unused-function]
95 | static unsigned long read_pmevcntrn(int n)
| ^~~~~~~~~~~~~~
Fix this by adding the missing "inline" keywords to the three accessor
functions that lack them.
Fixes: 009d6dc87a56 ("ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM")
Change-Id: I0877fa9d337a59857c8480a219515e2c641cfc55
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/3a7d9bc7470aa2d85696ee9765c74f8c03fb5454.1683561482.git.geert+renesas@glider.be
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 68e3f61eb9f58798e28b18152cd38cb269eebc34)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
When just including <asm/arm_pmuv3.h>:
arch/arm64/include/asm/arm_pmuv3.h:31:13: error: ‘write_pmevtypern’ defined but not used [-Werror=unused-function]
31 | static void write_pmevtypern(int n, unsigned long val)
| ^~~~~~~~~~~~~~~~
arch/arm64/include/asm/arm_pmuv3.h:24:13: error: ‘write_pmevcntrn’ defined but not used [-Werror=unused-function]
24 | static void write_pmevcntrn(int n, unsigned long val)
| ^~~~~~~~~~~~~~~
arch/arm64/include/asm/arm_pmuv3.h:16:22: error: ‘read_pmevcntrn’ defined but not used [-Werror=unused-function]
16 | static unsigned long read_pmevcntrn(int n)
| ^~~~~~~~~~~~~~
Fix this by adding the missing "inline" keywords to the three accessor
functions that lack them.
Fixes: df29ddf4f04b ("arm64: perf: Abstract system register accesses away")
Change-Id: I36e1360fc3b187b5e68619386ae9c142a9dda3c6
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/d53a19043c0c3bd25f6c203e73a2fb08a9661824.1683561482.git.geert+renesas@glider.be
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 3bc879e355da4ff925e9d82278a829547d9d54bf)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
Reiji reports that the arm64 implementation of arch_perf_update_userpage()
is now ignored and replaced by the dummy stub in core code.
This seems to happen since the PMUv3 driver was moved to driver/perf.
As it turns out, dropping the __weak attribute from the *prototype*
of the function solves the problem. You're right, this doesn't seem
to make much sense. And yet... It appears that both symbols get
flagged as weak, and that the first one to appear in the link order
wins:
$ nm drivers/perf/arm_pmuv3.o|grep arch_perf_update_userpage
0000000000001db0 W arch_perf_update_userpage
Dropping the attribute from the prototype restores the expected
behaviour, and arm64 is able to enjoy arch_perf_update_userpage()
again.
Fixes: 7755cec63ade ("arm64: perf: Move PMUv3 driver to drivers/perf")
Fixes: f1ec3a517b ("kernel/events: Add a missing prototype for arch_perf_update_userpage()")
Reported-by: Reiji Watanabe <reijiw@google.com>
Change-Id: I497041999776e66ac77c3fccdd09ce47aae544e9
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Reiji Watanabe <reijiw@google.com>
Link: https://lkml.kernel.org/r/20230616114831.3186980-1-maz@kernel.org
(cherry picked from commit b50f26a44887f3f71ff5457135ee1d5f1d542d7d)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
The only thing stopping the PMUv3 driver from compiling on 32bit
is the lack of defined system registers names and the handful of
required helpers.
This is easily solved by providing the sysreg accessors and updating
the Kconfig entry.
Change-Id: I3f7f46feaeac69bb7d20c86b013e4a3091fb4bce
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Co-developed-by: Zaid Al-Bassam <zalbassam@google.com>
Signed-off-by: Zaid Al-Bassam <zalbassam@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230317195027.3746949-8-zalbassam@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 009d6dc87a568db62290b8dc0a517b612217b6da)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
ARMv8 is a superset of ARMv7, and all the ARMv8 features are
discoverable with a set of ID registers. It means that we can
use CPU_V7 to guard ARMv8 features at compile time.
This commit simply amends the CPU_V7 configuration symbol comment
to reflect that CPU_V7 also covers ARMv8.
Change-Id: Ibfa141b7fcf77619cea6f95d562b8ddf959187a3
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Zaid Al-Bassam <zalbassam@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230317195027.3746949-7-zalbassam@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 252309adc81f529d42c8c90a4965866ec82cb6ad)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
GENMASK macro uses "unsigned long" (32-bit wide on arm and 64-bit
on arm64), This causes build issues when enabling PMUv3 on arm as
it tries to access bits > 31. This patch switches the GENMASK to
GENMASK_ULL, which uses "unsigned long long" (64-bit on both arm
and arm64).
Change-Id: I44e30f5326202a4e691bf70ce15ac5c946cca19a
Signed-off-by: Zaid Al-Bassam <zalbassam@google.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230317195027.3746949-6-zalbassam@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit b3a070869f39be4fad9ea4d99f2c8fab1fb7eead)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
KVM host support is available only on arm64.
By moving the inclusion of kvm_host.h to an arm64-specific file,
the 32bit architecture will be able to implement dummy helpers.
Change-Id: I219958c7d95fa89b3fadcfaa73eec7392717a534
Signed-off-by: Zaid Al-Bassam <zalbassam@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230317195027.3746949-5-zalbassam@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 11fba29a8a1f2fca08f301426b15c62d8a0b8040)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
The current PMU version definitions are available for arm64 only,
As we want to add PMUv3 support to arm (32-bit), abstracts
these definitions by using arch-specific helpers.
Change-Id: I4d487c354c5b1384d2e8c95d097c0d3864907787
Signed-off-by: Zaid Al-Bassam <zalbassam@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230317195027.3746949-4-zalbassam@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 711432770f78e5a9ae235a1a55decfb71993c958)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
As we want to enable 32bit support, we need to distanciate the
PMUv3 driver from the AArch64 system register names.
This patch moves all system register accesses to an architecture
specific include file, allowing the 32bit counterpart to be
slotted in at a later time.
Change-Id: Ib5c22a45d2b0ed844ee7d03cb7a7fa855230fcca
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Co-developed-by: Zaid Al-Bassam <zalbassam@google.com>
Signed-off-by: Zaid Al-Bassam <zalbassam@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230317195027.3746949-3-zalbassam@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit df29ddf4f04b00cf60669686dc7f534c3ed7c433)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
Having the ARM PMUv3 driver sitting in arch/arm64/kernel is getting
in the way of being able to use perf on ARMv8 cores running a 32bit
kernel, such as 32bit KVM guests.
This patch moves it into drivers/perf/arm_pmuv3.c, with an include
file in include/linux/perf/arm_pmuv3.h. The only thing left in
arch/arm64 is some mundane perf stuff.
Change-Id: I1928ceb684a107ef991401175458f2ea6c711826
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Zaid Al-Bassam <zalbassam@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230317195027.3746949-2-zalbassam@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 7755cec63adeecea3cbbf4032047812c37cf7cc3)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
__armv8pmu_probe_pmu() returns if detected PMU is either not implemented or
implementation defined. Extracted ID_AA64DFR0_EL1_PMUVer value, when PMU is
not implemented is '0' which can be replaced with ID_AA64DFR0_EL1_PMUVer_NI
defined as '0b0000'.
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-perf-users@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Change-Id: I1d3b7e35313b967b19fb4370fde4ad3392f28db2
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20221128025449.39085-1-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit cc91b9481605b1f62f947857231050c747ceda16)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
The logic in blk_mq_complete_need_ipi() assumes SMP systems where all
CPUs have equal compute capacities and only LLC cache can make
a different on perceived performance. But this assumption falls apart on
HMP systems where LLC is shared, but the CPUs have different capacities.
Staying local then can have a big performance impact if the IO request
was done from a CPU with higher capacity but the interrupt is serviced
on a lower capacity CPU.
Use the new cpus_equal_capacity() function to check if we need to send
an IPI.
Without the patch I see the BLOCK softirq always running on little cores
(where the hardirq is serviced). With it I can see it running on all
cores.
This was noticed after the topology change [1] where now on a big.LITTLE
we truly get that the LLC is shared between all cores where as in the
past it was being misrepresented for historical reasons. The logic
exposed a missing dependency on capacities for such systems where there
can be a big performance difference between the CPUs.
This of course introduced a noticeable change in behavior depending on
how the topology is presented. Leading to regressions in some workloads
as the performance of the BLOCK softirq on littles can be noticeably
worse on some platforms.
Worth noting that we could have checked for capacities being greater
than or equal instead for equality. This will lead to favouring higher
performance always. But opted for equality instead to match the
performance of the requester without making an assumption that can lead
to power trade-offs which these systems tend to be sensitive about. If
the requester would like to run faster, it's better to rely on the
scheduler to give the IO requester via some facility to run on a faster
core; and then if the interrupt triggered on a CPU with different
capacity we'll make sure to match the performance the requester is
supposed to run at.
[1] https://lpc.events/event/16/contributions/1342/attachments/962/1883/LPC-2022-Android-MC-Phantom-Domains.pdf
Bug: 341551538
Signed-off-by: Qais Yousef <qyousef@layalina.io>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240223155749.2958009-3-qyousef@layalina.io
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit af550e4c968294398fc76b075f12d51c76caf753)
Signed-off-by: Qais Yousef <qyousef@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:d01dc1c7d020f49f31194254a89694bd23ad3dd5)
Merged-In: Iefed6a19b9d25102642e264118431f5e12e23fea
Change-Id: Iefed6a19b9d25102642e264118431f5e12e23fea
The new helper function is needed to help blk-mq check if it needs to
dispatch the softirq on another CPU to match the performance level the
IO requester is running at. This is important on HMP systems where not
all CPUs have the same compute capacity.
Bug: 341551538
Signed-off-by: Qais Yousef <qyousef@layalina.io>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240223155749.2958009-2-qyousef@layalina.io
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit b361c9027b4e4159e7bcca4eb64fd26507c19994)
[Trivial clash due to some code shuffling between versions]
Signed-off-by: Qais Yousef <qyousef@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:ee8168e00c6e4fb04bea953bacb61ff017a39f63)
Merged-In: I58f3f3e3560f4800b5c73b3c85bbfdf628e9764e
Change-Id: I58f3f3e3560f4800b5c73b3c85bbfdf628e9764e
FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC. There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect. For a DWC3 based implementation, the callstack looks
like the following:
DWC3 Gadget FFS Application
dwc3_gadget_soft_disconnect() ...
--> dwc3_stop_active_transfers()
--> dwc3_gadget_giveback(-ESHUTDOWN)
--> ffs_epfile_async_io_complete() ffs_aio_cancel()
--> usb_ep_free_request() --> usb_ep_dequeue()
There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data->req) the FFS
application is also referencing it for the usb_ep_dequeue() call. This can
lead to accessing a stale/hanging pointer.
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().
However, in order to properly implement locking to mitigate this issue, the
spinlock can't be added to ffs_epfile_async_io_complete(), as
usb_ep_dequeue() (if successfully dequeuing a USB request) will call the
function driver's completion handler in the same context. Hence, leading
into a deadlock.
Fix this issue by moving the usb_ep_free_request() back to
ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req
to NULL after freeing it within the ffs->eps_lock. This resolves the race
condition above, as the ffs_aio_cancel() routine will not continue
attempting to dequeue a request that has already been freed, or the
ffs_user_copy_work() not freeing the USB request until the AIO cancel is
done referencing it.
This fix depends on
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status
consistently")
Fixes: 2e4c7553cd ("usb: gadget: f_fs: add aio support")
Cc: stable <stable@kernel.org> # b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20240409014059.6740-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 334976932
(cherry picked from commit 24729b307eefcd7c476065cd7351c1a018082c19)
Change-Id: I56f6b9d24c239e73edff94e1f9f33ab41a9bd37b
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Commit fb1f16d74e ("usb: gadget: f_fs: change ep->status safe in
ffs_epfile_io()") added a new ffs_io_data::status field to fix lifetime
issues in synchronous requests.
While there are no similar lifetime issues for asynchronous requests
(the separate ep member in ffs_io_data avoids them) using the status
field means the USB request can be freed earlier and that there is more
consistency between the synchronous and asynchronous I/O paths.
Cc: Linyu Yuan <quic_linyyuan@quicinc.com>
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20221124170430.3998755-1-john@metanate.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 334976932
(cherry picked from commit b566d38857fcb6777f25b674b90a831eec0817a2)
Change-Id: I8cd4d95ff6ec694adac3881da80eff23f6c679d4
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
For GKI targets with kmi_symbol_list set,
also set rewrite_absolute_paths_in_config to True
so that CONFIG_UNUSED_KSYMS_WHITELIST is not an
absolute path any more, increasing reproducibility
on different machines.
This is made possible with c6427490ab
"Revert^2 "BACKPORT: FROMGIT: module: allow UNUSED_KSYMS_WHITELIST to be relative against objtree.""
so that Kbuild recognizes relative paths by searching
$(objtree) first.
This does not change x86 builds because it
doesn't have kmi_symbol_list set.
This change does not affect device builds like
db845c, rockpi and fips140. Adding the attribute
to these targets would be okay, but it is not
covered by this change.
Bug: 333769605
Bug: 342390208
Change-Id: I844c251979bae5277474837eaa055f1346b0afa2
Signed-off-by: Yifan Hong <elsk@google.com>
wdev->valid_links is not cleared when upper layer disconnect from a
wdev->AP MLD. It has been observed that this would prevent offchannel
operations like remain-on-channel which would be needed for user space
operations with Public Action frame.
Clear the wdev->valid_links when STA disconnects.
Signed-off-by: Xin Deng <quic_deng@quicinc.com>
Link: https://msgid.link/20240426092501.8592-1-quic_deng@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 344476904
Change-Id: Ie84dda35e26d2792ed39f50d0c3f959682730d89
(cherry picked from commit 9f6d4b8d149af8dc3f9a1e3000168b99ca576390)
Signed-off-by: Xin Deng <quic_deng@quicinc.com>
Add the usb gadget connect/disconnect symbols to ABI to be used by
vendor driver:
usb_gadget_connect
usb_gadget_disconnect
Bug: 344835325
Change-Id: I506d142ed863e6ce0d21b7a0e31c1721f6bdba93
Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com>
This is a step toward making __iommu_probe_device() self contained.
It should, under proper locking, check if the device is already associated
with an iommu driver and resolve parallel probes. All but one of the
callers open code this test using two different means, but they all
rely on dev->iommu_group.
Currently the bus_iommu_probe()/probe_iommu_group() and
probe_acpi_namespace_devices() rejects already probed devices with an
unlocked read of dev->iommu_group. The OF and ACPI "replay" functions use
device_iommu_mapped() which is the same read without the pointless
refcount.
Move this test into __iommu_probe_device() and put it under the
iommu_probe_device_lock. The store to dev->iommu_group is in
iommu_group_add_device() which is also called under this lock for iommu
driver devices, making it properly locked.
The only path that didn't have this check is the hotplug path triggered by
BUS_NOTIFY_ADD_DEVICE. The only way to get dev->iommu_group assigned
outside the probe path is via iommu_group_add_device(). Today the only
caller is VFIO no-iommu which never associates with an iommu driver. Thus
adding this additional check is safe.
Bug: 337990354
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/1-v3-328044aa278c+45e49-iommu_probe_jgg@nvidia.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 6eb4da8cf54537992fc9843be8b2af4f83f717e0)
Change-Id: I079ee5467e96367a5e1aa2ae5f0d5f6837df597c
[quic_nprakash: Resolved conflicts in drivers/iommu/iommu.c]
Signed-off-by: Nikhil V <quic_nprakash@quicinc.com>
In commit 92f1655aa2b2 ("net: fix __dst_negative_advice() race") the
struct dst_ops callback negative_advice is callback changes function
parameters. But as this pointer is part of a structure that is tracked
in the ABI checker, the tool triggers when this is changed.
However, the callback pointer is internal to the networking stack, so
changing the function type is safe, so needing to preserve this is not
required. To do so, switch the function pointer type back to the old
one so that the checking tools pass, AND then do a hard cast of the
function pointer to the new type when assigning and calling the
function.
[6.1.y backport note, work around --Werror=cast-function-type issue by
abusing void * for function pointer types, despite its best effort, C
still let's us shoot our foot off if we really want to!]
Bug: 343727534
Fixes: 92f1655aa2b2 ("net: fix __dst_negative_advice() race")
Change-Id: I48d4ab4bbd29f8edc8fbd7923828b7f78a23e12e
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
__dst_negative_advice() does not enforce proper RCU rules when
sk->dst_cache must be cleared, leading to possible UAF.
RCU rules are that we must first clear sk->sk_dst_cache,
then call dst_release(old_dst).
Note that sk_dst_reset(sk) is implementing this protocol correctly,
while __dst_negative_advice() uses the wrong order.
Given that ip6_negative_advice() has special logic
against RTF_CACHE, this means each of the three ->negative_advice()
existing methods must perform the sk_dst_reset() themselves.
Note the check against NULL dst is centralized in
__dst_negative_advice(), there is no need to duplicate
it in various callbacks.
Many thanks to Clement Lecigne for tracking this issue.
This old bug became visible after the blamed commit, using UDP sockets.
Bug: 343727534
Fixes: a87cb3e48e ("net: Facility to report route quality of connected sockets")
Reported-by: Clement Lecigne <clecigne@google.com>
Diagnosed-by: Clement Lecigne <clecigne@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Tom Herbert <tom@herbertland.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20240528114353.1794151-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 92f1655aa2b2294d0b49925f3b875a634bd3b59e)
[Lee: Trivial/unrelated conflict - no change to the patch]
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I293734dca1b81fcb712e1de294f51e96a405f7e4
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 680eb0a993 which is
commit 27016f75f5ed47e2d8e0ca75a8ff1f40bc1a5e27 upstream.
This breaks for devices that use the downstream fips140 module.
Bug: 335718233
Bug: 335830134
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:0cf5cecba66e91b69268fd87ded20e755bee1938)
Merged-In: Ie465403c40fe75fee5934ea160b86a4c77ef8f17
Change-Id: Ie465403c40fe75fee5934ea160b86a4c77ef8f17
udc device and gadget device are tightly coupled, yet there's no good
way to corelate the two. Add a sysfs link in udc that points to the
corresponding gadget device.
An example use case: userspace configures a f_midi configfs driver and
bind the udc device, then it tries to locate the corresponding midi
device, which is a child device of the gadget device. The gadget device
that's associated to the udc device has to be identified in order to
index the midi device. Having a sysfs link would make things much
easier.
Signed-off-by: Roy Luo <royluo@google.com>
Link: https://lore.kernel.org/r/20240307030922.3573161-1-royluo@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 333778731
Change-Id: I9e3f782543eba5e026a65031aaae754daafb69ab
(cherry picked from commit 0ef40f399aa2be8c04aee9b7430705612c104ce5)
Signed-off-by: Roy Luo <royluo@google.com>
Enabling configs for Tegra SoCs required this module to be included in
the rockpi4 builds. This change fixes the following build issue:
ERROR: The following kernel modules are built but not copied. Add these lines to the module_outs attribute of @@//common:rockpi4_no_kgdb:
"drivers/cpufreq/tegra20-cpufreq.ko",
Bug: 335325897
Change-Id: I898000725287f34956cb977b3b02685f189cd5a0
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Enabling configs for Tegra SoCs required these symbols to be included.
This change fixes the following build issues:
ERROR: modpost: "devm_tegra_memory_controller_get" [drivers/iommu/arm/arm-smmu/arm_smmu.ko] undefined!
ERROR: modpost: "tegra_mc_probe_device" [drivers/iommu/arm/arm-smmu/arm_smmu.ko] undefined!
Also update the STG file accordingly:
2 function symbol(s) added
'struct tegra_mc* devm_tegra_memory_controller_get(struct device*)'
'int tegra_mc_probe_device(struct tegra_mc*, struct device*)'
Bug: 335325897
Change-Id: Ie357116189e074f1dc0e572553b2264abc910bd3
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Build some configs that are tristate and selected by
CONFIG_ARCH_TEGRA as vendor modules rather than built-in.
Bug: 335325897
Change-Id: I7ce4cf975fcbc834bc5fc3c90317d9d81162185a
Signed-off-by: Ahmad Chaudhry <ahmadc@nvidia.com>
To use cpumask_parse_user in vendor code, it will call
bitmap_parse_user.
Adding the following symbols:
- bitmap_parse_user
Bug: 248621289
Change-Id: I4b24d8b1fba71af7b55c7444963a003d50f6d93c
Signed-off-by: Rick Yiu <rickyiu@google.com>
This reverts commit 3f13972470.
Reason for revert: relanding change that should be safe to go in on its own. Below is the original commit message.
BACKPORT: FROMGIT: module: allow UNUSED_KSYMS_WHITELIST to be relative against objtree.
If UNUSED_KSYMS_WHITELIST is a file generated
before Kbuild runs, and the source tree is in
a read-only filesystem, the developer must put
the file somewhere and specify an absolute
path to UNUSED_KSYMS_WHITELIST. This worked,
but if IKCONFIG=y, an absolute path is embedded
into .config and eventually into vmlinux, causing
the build to be less reproducible when building
on a different machine.
This patch makes the handling of
UNUSED_KSYMS_WHITELIST to be similar to
MODULE_SIG_KEY.
First, check if UNUSED_KSYMS_WHITELIST is an
absolute path, just as before this patch. If so,
use the path as is.
If it is a relative path, use wildcard to check
the existence of the file below objtree first.
If it does not exist, fall back to the original
behavior of adding $(srctree)/ before the value.
After this patch, the developer can put the generated
file in objtree, then use a relative path against
objtree in .config, eradicating any absolute paths
that may be evaluated differently on different machines.
Signed-off-by: Yifan Hong <elsk@google.com>
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
(cherry picked from commit a2e3c811938b4902725e259c03b2d6c539613992
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git modules-next)
Bug: 333769605
Change-Id: I442bbe5a68fc895619b84b4749f1e97cb88088ea
[elsk: apply change to gen_autoksyms.sh instead because
CONFIG_UNUSED_KSYMS_WHITELIST is parsed there. Revert change
to Makefile.modpost.]
Bug: 342390208
Signed-off-by: Yifan Hong <elsk@google.com>
Wrap 'struct binder_proc' inside 'struct binder_proc_wrap' to add the
alloc->lock equivalent without breaking the KMI. Also, add convenient
apis to access/modify this new spinlock.
Without this patch, the following KMI issues show up:
type 'struct binder_proc' changed
byte size changed from 616 to 576
type 'struct binder_alloc' changed
byte size changed from 152 to 112
member 'spinlock_t lock' was added
member 'struct mutex mutex' was removed
Bug: 254650075
Bug: 319778300
Change-Id: Ic31dc39fb82800a3e47be10a7873cd210f7b60be
Signed-off-by: Carlos Llamas <cmllamas@google.com>
[cmllamas: fixed trivial conflicts]
The correct printk format specifier when calculating buffer offsets
should be "%tx" as it is a pointer difference (a.k.a ptrdiff_t). This
fixes some W=1 build warnings reported by the kernel test robot.
Bug: 329799092
Fixes: 63f7ddea2e48 ("ANDROID: binder: fix KMI-break due to address type change")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202401100511.A4BKMwoq-lkp@intel.com/
Change-Id: Iaa87433897b507c47fe8601464445cb6de4b61db
Signed-off-by: Carlos Llamas <cmllamas@google.com>
In commit ("binder: keep vma addresses type as unsigned long") the vma
address type in 'struct binder_alloc' and 'struct binder_buffer' is
changed from 'void __user *' to 'unsigned long'.
This triggers the following KMI issues:
type 'struct binder_buffer' changed
member changed from 'void* user_data' to 'unsigned long user_data'
type changed from 'void*' to 'unsigned long'
type 'struct binder_alloc' changed
member changed from 'void* buffer' to 'unsigned long buffer'
type changed from 'void*' to 'unsigned long'
This offending commit is being backported as part of a larger patchset
from upstream in [1]. Lets fix these issues by doing a partial revert
that restores the original types and casts to an integer type where
necessary.
Note this approach is preferred over dropping the single KMI-breaking
patch from the backport, as this would have created non-trivial merge
conflicts in the subsequent cherry-picks.
Bug: 254650075
Bug: 319778300
Link: https://lore.kernel.org/all/20231201172212.1813387-1-cmllamas@google.com/ [1]
Change-Id: Ief9de717d0f34642f5954ffa2e306075a5b4e02e
Signed-off-by: Carlos Llamas <cmllamas@google.com>
[cmllamas: fixed trivial conflicts]
This reverts commit 637c8e0d372f1dfff53337a5db89f772577828d7.
Also squash commit db91c5d31a ("ANDROID: vendor_hook: rename the the
name of hooks"), which fixes the length of the vendor hook's name.
Rework the error return for a goto as this has been refactor too.
Finally, also fix spaces vs tabs.
Change-Id: I22c495eb81237c51c0f9f4d4f9f4f1cf0c8438a8
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit eeb899e9f54bef5286fd5044db481ecc01e417b4.
Change-Id: I810727a6872c16ccb484023bfbc587daca8a2515
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The alloc->mutex is a highly contended lock that causes performance
issues on Android devices. When a low-priority task is given this lock
and it sleeps, it becomes difficult for the task to wake up and complete
its work. This delays other tasks that are also waiting on the mutex.
The problem gets worse when there is memory pressure in the system,
because this increases the contention on the alloc->mutex while the
shrinker reclaims binder pages.
Switching to a spinlock helps to keep the waiters running and avoids the
overhead of waking up tasks. This significantly improves the transaction
latency when the problematic scenario occurs.
The performance impact of this patchset was measured by stress-testing
the binder alloc contention. In this test, several clients of different
priorities send thousands of transactions of different sizes to a single
server. In parallel, pages get reclaimed using the shinker's debugfs.
The test was run on a Pixel 8, Pixel 6 and qemu machine. The results
were similar on all three devices:
after:
| sched | prio | average | max | min |
|--------+------+---------+-----------+---------|
| fifo | 99 | 0.135ms | 1.197ms | 0.022ms |
| fifo | 01 | 0.136ms | 5.232ms | 0.018ms |
| other | -20 | 0.180ms | 7.403ms | 0.019ms |
| other | 19 | 0.241ms | 58.094ms | 0.018ms |
before:
| sched | prio | average | max | min |
|--------+------+---------+-----------+---------|
| fifo | 99 | 0.350ms | 248.730ms | 0.020ms |
| fifo | 01 | 0.357ms | 248.817ms | 0.024ms |
| other | -20 | 0.399ms | 249.906ms | 0.020ms |
| other | 19 | 0.477ms | 297.756ms | 0.022ms |
The key metrics above are the average and max latencies (wall time).
These improvements should roughly translate to p95-p99 latencies on real
workloads. The response time is up to 200x faster in these scenarios and
there is no penalty in the regular path.
Note that it is only possible to convert this lock after a series of
changes made by previous patches. These mainly include refactoring the
sections that might_sleep() and changing the locking order with the
mmap_lock amongst others.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-29-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 254650075
(cherry picked from commit 7710e2cca32e7f3958480e8bd44f50e29d0c2509)
Change-Id: I67121be071d5f072ac0e5eb719c95c0f1dee5eb5
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The locking order currently requires the alloc->mutex to be acquired
first followed by the mmap lock. However, the alloc->mutex is converted
into a spinlock in subsequent commits so the order needs to be reversed
to avoid nesting the sleeping mmap lock under the spinlock.
The shrinker's callback binder_alloc_free_page() is the only place that
needs to be reordered since other functions have been refactored and no
longer nest these locks.
Some minor cosmetic changes are also included in this patch.
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-28-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 254650075
(cherry picked from commit e50f4e6cc9bfaca655d3b6a3506d27cf2caa1d40)
Change-Id: I7f7501945a477ac5571082a5dd2a7934f484b8ab
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Prefer logging vma offsets instead of addresses or simply drop the debug
log altogether if not useful. Note this covers the instances affected by
the switch to store addresses as unsigned long. However, there are other
sections in the driver that could do the same.
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-27-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 254650075
(cherry picked from commit 162c79731448a5a052e93af7753df579dfe0bf7a)
Change-Id: I92b7f409e45d9006492d56302e911ccdd8efc950
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Skip the freelist call immediately as needed, instead of continuing the
pointless checks. Also, drop the debug logs that we don't really need.
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-26-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 254650075
(cherry picked from commit f07b83a48e944c8a1cc1e9f6703fae5e34df2ba4)
Change-Id: I035bd6cd5c06ec984cd6eb3c3b53e0958c64df4f
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The code in print_binder_buffer() is quite small so it can be collapsed
into its single caller binder_alloc_print_allocated().
No functional change in this patch.
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-25-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 254650075
(cherry picked from commit 8e905217c4543af9cf1754809846157a7dbbb261)
Change-Id: Ic3e2522b4702e60e09be3d5940f88ec8252ac793
Signed-off-by: Carlos Llamas <cmllamas@google.com>
