The bpf_get_stackid() function may also return 0 on success as per UAPI BPF
helper documentation. Therefore, correct checks from 'val > 0' to 'val >= 0'
to ensure that they cover all possible success return values.
Signed-off-by: Yuntao Wang <ytcoode@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20220408041452.933944-1-ytcoode@gmail.com
Add CO-RE relocations into __weak subprogs for multi-file linked_funcs
selftest to make sure libbpf handles such combination well.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20220408181425.2287230-4-andrii@kernel.org
Use __weak __hidden for bpf_usdt_xxx() APIs instead of much more
confusing `static inline __noinline`. This was previously impossible due
to libbpf erroring out on CO-RE relocations pointing to eliminated weak
subprogs. Now that previous patch fixed this issue, switch back to
__weak __hidden as it's a more direct way of specifying the desired
behavior.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20220408181425.2287230-3-andrii@kernel.org
During BPF static linking, all the ELF relocations and .BTF.ext
information (including CO-RE relocations) are preserved for __weak
subprograms that were logically overriden by either previous weak
subprogram instance or by corresponding "strong" (non-weak) subprogram.
This is just how native user-space linkers work, nothing new.
But libbpf is over-zealous when processing CO-RE relocation to error out
when CO-RE relocation belonging to such eliminated weak subprogram is
encountered. Instead of erroring out on this expected situation, log
debug-level message and skip the relocation.
Fixes: db2b8b0642 ("libbpf: Support CO-RE relocations for multi-prog sections")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20220408181425.2287230-2-andrii@kernel.org
Starting with the new perf-event support in the nvdimm core, the
nfit_test mock module stops compiling. Rename its security_init() to
nfit_security_init().
tools/testing/nvdimm/test/nfit.c:1845:13: error: conflicting types for ‘security_init’; have ‘void(struct nfit_test *)’
1845 | static void security_init(struct nfit_test *t)
| ^~~~~~~~~~~~~
In file included from ./include/linux/perf_event.h:61,
from ./include/linux/nd.h:11,
from ./drivers/nvdimm/nd-core.h:11,
from tools/testing/nvdimm/test/nfit.c:19:
Fixes: 9a61d0838c ("drivers/nvdimm: Add nvdimm pmu structure")
Cc: Kajol Jain <kjain@linux.ibm.com>
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/164904238610.1330275.1889212115373993727.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The intent of the version check in the mmap ioctl was to maintain
support for existing platforms (i.e., ADL/RPL and earlier), but drop
support on all future igpu platforms. As we've seen on the dgpu side,
the hardware teams are using a more fine-grained numbering system for IP
version numbers these days, so it's possible the version number
associated with our next igpu could be some form of "12.xx" rather than
13 or higher. Comparing against the full ver.release number will ensure
the intent of the check is maintained no matter what numbering the
hardware teams settle on.
Fixes: d3f3baa356 ("drm/i915: Reinstate the mmap ioctl for some platforms")
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220407161839.1073443-1-matthew.d.roper@intel.com
Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may
represent the last reference held on the task mm.
hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed
before the final use in hfi1_release_user_pages(). A new task may
allocate the mm structure while it is still being used, resulting in
problems. One manifestation is corruption of the mmap_sem counter leading
to a hang in down_write(). Another is corruption of an mm struct that is
in use by another task.
Fixes: 3d2a9d6425 ("IB/hfi1: Ensure correct mm is used at all times")
Link: https://lore.kernel.org/r/20220408133523.122165.72975.stgit@awfm-01.cornelisnetworks.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Douglas Miller <doug.miller@cornelisnetworks.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
There are certain parts of WQ that needs to be cleaned up even after WQ is
disabled during the device disable. Those are the unchangeable parts for a
WQ when the device is still enabled. Move the cleanup outside of WQ state
check. Remove idxd_wq_disable_cleanup() inside idxd_wq_device_reset_cleanup()
since only the unchangeable parts need to be cleared.
Fixes: 0f225705cf ("dmaengine: idxd: fix wq settings post wq disable")
Reported-by: Tony Zhu <tony.zhu@intel.com>
Tested-by: Tony Zhu <tony.zhu@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/164919561905.1455025.13542366389944678346.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The DMAC block is identical on Renesas RZ/G2L, RZ/G2UL and RZ/V2L SoC's, so
instead of adding dependency for each SoC's add dependency on ARCH_RZG2L.
The ARCH_RZG2L config option is already selected by ARCH_R9A07G043,
ARCH_R9A07G044 and ARCH_R9A07G054.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20220406080417.14593-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Highlights include:
Stable fixes:
- SUNRPC: Ensure we flush any closed sockets before xs_xprt_free()
Bugfixes:
- Fix an Oopsable condition due to SLAB_ACCOUNT setting in the NFSv4.2
xattr code.
- Fix for open() using an file open mode of '3' in NFSv4
- Replace readdir's use of xxhash() with hash_64()
- Several patches to handle malloc() failure in SUNRPC
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEESQctxSBg8JpV8KqEZwvnipYKAPIFAmJQb5IACgkQZwvnipYK
APLVeRAAheQX422gIrjrWsQrZxJWmMDBBj9qwiV14XMs6g5KF/DtNbIJm1BGjA9Y
aLgNVknSDcGHMmvdh5MCVF7R61sqkCNbQWP3Bx6OBP6ei3FEgQBPyujcFXAaZ7UK
T4fBzfPoEYaxVkEG/L5BsAUnh6TvyCfNm1oqZZv2bv9M0U6UlXnRLWZN9I6cAtcw
GI9HgnufWOxJWIqPd9dY45aF44Ru+aJ953eecPh0G83Reoc99EAU+PvJJD18Wl0H
BZqM6ar5pNush50yVIjnPFXg+sM97dKGlLvYL11Uy7f8valSaBXPZLZQ/jG4Vx/a
m/l8FVwBEV89BG7z6jKNju7ERbO+xbPgXP8lSwkj69fXOpuvzo/G6VAxS6ZJww12
p6TJnhCMSEF7qrQc5mejA803dT4MiJWo4i2th482Ws/tRN5H+y9pDYLsvBPM8iHo
sVkJBco04tBHEH3qKgDTu8EY7/shH+GVO3Wmtcjz47T2rbmQB7gJtfipHcLmV2qd
Jy1tiz1T7rhGs7KNtWpu8210MY9iFhIt3rAvdGdeVmgnNjrmRex0Sxqx8vgKUAFE
aQjXkkpwHA3rHWnuGPMKu5i48BPFQ8m4QgdVC9F6ylNT6RIbImqplQiwIYNIxYC+
cBohUG1yYZRjFEMkXBdfK5cImkTLW7RkLCatRh5v8OU8xqpRVL8=
=edfs
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-5.18-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client fixes from Trond Myklebust:
"Stable fixes:
- SUNRPC: Ensure we flush any closed sockets before xs_xprt_free()
Bugfixes:
- Fix an Oopsable condition due to SLAB_ACCOUNT setting in the
NFSv4.2 xattr code.
- Fix for open() using an file open mode of '3' in NFSv4
- Replace readdir's use of xxhash() with hash_64()
- Several patches to handle malloc() failure in SUNRPC"
* tag 'nfs-for-5.18-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
SUNRPC: Move the call to xprt_send_pagedata() out of xprt_sock_sendmsg()
SUNRPC: svc_tcp_sendmsg() should handle errors from xdr_alloc_bvec()
SUNRPC: Handle allocation failure in rpc_new_task()
NFS: Ensure rpc_run_task() cannot fail in nfs_async_rename()
NFSv4/pnfs: Handle RPC allocation errors in nfs4_proc_layoutget
SUNRPC: Handle low memory situations in call_status()
SUNRPC: Handle ENOMEM in call_transmit_status()
NFSv4.2: Fix missing removal of SLAB_ACCOUNT on kmem_cache allocation
SUNRPC: Ensure we flush any closed sockets before xs_xprt_free()
NFS: Replace readdir's use of xxhash() with hash_64()
SUNRPC: handle malloc failure in ->request_prepare
NFSv4: fix open failure with O_ACCMODE flag
Revert "NFSv4: Handle the special Linux file open access mode"
The rdma_rxe driver does not actually support the reliable datagram
transport but contains two references to RD opcodes in driver code. This
commit removes these references to RD transport opcodes which are never
used.
Link: https://lore.kernel.org/r/cce0f07d-25fc-5880-69e7-001d951750b7@gmail.com
Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Currently the rdma_rxe driver supports SMI type QPs in a few places which
is incorrect. RoCE devices never should support SMI QPs. This commit
removes SMI QP support from the driver.
Link: https://lore.kernel.org/r/20220407185416.16372-1-rpearsonhpe@gmail.com
Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Currently the rdma_rxe driver claims to support both 2A and 2B type memory
windows. But the IBA requires
010-37.2.31: If an HCA supports the Base Memory Management
extensions, the HCA shall support either Type 2A or Type 2B MWs,
but not both.
This commit removes the device capability bit for type 2A memory windows
and adds a clarifying comment to rxe_mw.c.
Link: https://lore.kernel.org/r/20220407184321.14207-1-rpearsonhpe@gmail.com
Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Commit 3b6f409547 ("drm/i915/display/psr: Lock and unlock PSR around
pipe updates") did not took into account async flips with PSR1 and
PSR2 HW tracking, causing PSR lock not be held and causing warnings
when intel_psr2_program_trans_man_trk_ctl() is executed.
So here taking the PSR lock before the earlier return in
intel_pipe_update_start/end().
Cc: Jouni Högander <jouni.hogander@intel.com>
Reported-by: Imre Deak <imre.deak@intel.com>
Fixes: 3b6f409547 ("drm/i915/display/psr: Lock and unlock PSR around pipe updates")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220406210540.493610-1-jose.souza@intel.com
Rather than hard-coding pci_bus_type, pass the PF device through to
usnic_uiom_alloc_pd() and retrieve its bus there. This prepares for
iommu_domain_alloc() changing to take a device rather than a bus_type.
Link: https://lore.kernel.org/r/ef607cb3f5a09920b86971b8c8e60af8c647457e.1649169359.git.robin.murphy@arm.com
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device(s)
we care about. Replace iommu_present() with a more appropriate check at
probe time, and garbage-collect the resulting empty init function.
Link: https://lore.kernel.org/r/f707b4248e1d33b6d2c7f1d7c94febb802cf9890.1649161199.git.robin.murphy@arm.com
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
- Revert temporary bodge in MTE coredumping to ease maple tree integration
- Fix stack frame size warning reported with 64k pages
- Fix stop_machine() race with instruction text patching
- Ensure alternatives patching routines are not instrumented
- Enable Spectre-BHB mitigation for Cortex-A78AE
- Fix hugetlb TLB invalidation when contiguous hint is used
- Minor perf driver fixes
- Fix some typos
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAmJQPzQQHHdpbGxAa2Vy
bmVsLm9yZwAKCRC3rHDchMFjNGWCCACHllJr2EwIkoq9WtuNdKDIsuElVcwkxJBD
0cnZKgefwsO8BYgmG2AKJxdxqiAAF6ENYl1hVmsySwEmzqQtsuu9B0tQ1IW/1tYf
XW3WwmmaUc4Os6v7nO0GspngU6eow1R1sypi99k13PJk4V6LLHQUnXbVHB5/39mW
4upAe7A/Myb4hYlLKN51eFmFe1hmBBqWXJndvLNzODlkHaxHw11fi49rAbV4ibAM
y+MjhfoqFh9wx8CUw3RNZpR3uWl3XWDfA5UBvSOMcA330UFdtmBTuNxfvMssks33
wqXbxLzWss7wvwZuvcyaLaFP6LpSJDrAAyKUfsDfK1hd7zOVPaOe
=GWtz
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"The two main things to note are:
(1) The bulk of the diffstat is us reverting a horrible bodge we had
in place to ease the merging of maple tree during the merge
window (which turned out not to be needed, but anyway)
(2) The TLB invalidation fix is done in core code, as suggested by
(and Acked-by) Peter.
Summary:
- Revert temporary bodge in MTE coredumping to ease maple tree integration
- Fix stack frame size warning reported with 64k pages
- Fix stop_machine() race with instruction text patching
- Ensure alternatives patching routines are not instrumented
- Enable Spectre-BHB mitigation for Cortex-A78AE
- Fix hugetlb TLB invalidation when contiguous hint is used
- Minor perf driver fixes
- Fix some typos"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
perf/imx_ddr: Fix undefined behavior due to shift overflowing the constant
arm64: Add part number for Arm Cortex-A78AE
arm64: patch_text: Fixup last cpu should be master
tlb: hugetlb: Add more sizes to tlb_remove_huge_tlb_entry
arm64: alternatives: mark patch_alternative() as `noinstr`
perf: MARVELL_CN10K_DDR_PMU should depend on ARCH_THUNDER
perf: qcom_l2_pmu: fix an incorrect NULL check on list iterator
arm64: Fix comments in macro __init_el2_gicv3
arm64: fix typos in comments
arch/arm64: Fix topology initialization for core scheduling
arm64: mte: Fix the stack frame size warning in mte_dump_tag_range()
Revert "arm64: Change elfcore for_each_mte_vma() to use VMA iterator"
To move the list iterator variable into the list_for_each_entry_*() macro
in the future it should be avoided to use the list iterator variable after
the loop body.
To *never* use the list iterator variable after the loop it was concluded
to use a separate iterator variable instead of a found boolean.
This removes the need to use a found variable and simply checking if the
variable was set, can determine if the break/goto was hit.
Link: https://lore.kernel.org/r/20220331091634.644840-1-jakobkoschel@gmail.com
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
- Remove the migration code's assumptions about large pages being PMD sized
- Don't call pmd_page() on a non-leaf PMD
- Fix handling of hugetlbfs pages in page_vma_mapped_walk
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEejHryeLBw/spnjHrDpNsjXcpgj4FAmJQV0cACgkQDpNsjXcp
gj7I6wf7BYsZWixhemyz0yABRzM0Cc1+X9UE3uFctFyeB4EkjIQihTljwqk439vt
VkXmJ6LnIwmOrOLg7Q9j9NNqk8/IbbGmrPXD5MobDc68ODFv3IssOWTGcXGiXuDS
irlh4rEyPg/4kk/cL/cVfb9UvUhzg+gaq8Ev6lnLkK3xEIYr2kazoN3XpuZN/YoC
0Fz52SjLDJ6sAJ6dHM0jklewJw10SsqpQ53keN5Vs5ULra/fCmVdzreHgDhC/h+G
sZ7Am52saYyvPGq3jIlMGxaBpAN5+6wBq88HgJDP1gK9w257aJij8n8KiNdhj1DR
V8KVZZAVeWhYhszpkuCSemRYPbSatg==
=jkJU
-----END PGP SIGNATURE-----
Merge tag 'folio-5.18e' of git://git.infradead.org/users/willy/pagecache
Pull folio fixes from Matthew Wilcox:
"Fewer bug reports than I was expecting from enabling large folios.
One that doesn't show up on x86 but does on arm64, one that shows up
with hugetlbfs memory failure testing and one that shows up with page
migration, which it turns out I wasn't testing because my last NUMA
machine died. Need to set up a qemu fake NUMA machine so I don't skip
testing that in future.
Summary:
- Remove the migration code's assumptions about large pages being PMD
sized
- Don't call pmd_page() on a non-leaf PMD
- Fix handling of hugetlbfs pages in page_vma_mapped_walk"
* tag 'folio-5.18e' of git://git.infradead.org/users/willy/pagecache:
mm/rmap: Fix handling of hugetlbfs pages in page_vma_mapped_walk
mm/mempolicy: Use vma_alloc_folio() in new_page()
mm: Add vma_alloc_folio()
mm/migrate: Use a folio in migrate_misplaced_transhuge_page()
mm/migrate: Use a folio in alloc_migration_target()
mm/huge_memory: Avoid calling pmd_page() on a non-leaf PMD
A small collection of fixes that have arrived since the merge window,
the most noticable one is a fix for unmapping messages when the mapping
was done with the struct device supplied to do the mapping overridden.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmJQTFYACgkQJNaLcl1U
h9Brugf7BN5jgKE3qZE/bbmORjP7Yu/2jbgR5Y65ZPTeQoiMXpvHi7nLDr2wczYP
Th6s8WZ350Yh5AgzEVZv81+oWbFNNSYTzDn+J7Qh6u/8HXkR4rougV7kHVSNzxeA
2kJSiD/4ppjx0jAkeXE50Y9L+qfdvXvxw1RuBB+uVlwH7/g85zRmDmKJgbQ/9z4V
U6IllIs/SjNNL8H5T9IBPg8Jys1xFOyCvxIImjTVbdADhddJkaqNpAHXcDixNM9c
Wk1SxdCM2kF3sOSXy0zL5fEL/lHbOAckJnFeORj18ZnvaC5uUaGF6o+zR5J7EXmT
BMgdFaCk95FcNZ604gV6l4uXrePx+w==
=OL/w
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small collection of fixes that have arrived since the merge window,
the most noticable one is a fix for unmapping messages when the
mapping was done with the struct device supplied to do the mapping
overridden"
* tag 'spi-fix-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: bcm-qspi: fix MSPI only access with bcm_qspi_exec_mem_op()
spi: cadence-quadspi: fix protocol setup for non-1-1-X operations
spi: core: add dma_map_dev for __spi_unmap_msg()
spi: mxic: Fix an error handling path in mxic_spi_probe()
spi: rpc-if: Fix RPM imbalance in probe error path
A few small driver specific fixes for v5.18, plus an update to the
MAINTAINERS file.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmJQTPQACgkQJNaLcl1U
h9AtfAf+IFiVtVkNBM3OyJH0HqAEkicz4jwDQlcdEvKAz+rU2OkGqqikCI0HqA+s
lj8hin7AMU6wPqoVLYXD3QsEUj3kVUAA6xANphKncphi1jqykGZ1pnJCo6KpIf7R
wGcHEIriUJc0anLbvfP28sYkFUlf5BT51bY01Bthu0CGWdTCztXrCYBhfKx+eMmm
QoZGM2WjYi3RHpB19ioUD9nA3AmiO3oOikjNKJWWeo7uw3sS/CvOmryYBCcMD+wo
Jj6cqFTHH5ub9WUO5xODUP5uwWz0VAR3/fmMJ3V7BECG0k8J5Cv5eDWM8vC0/bcv
8vVGa98WLXRWaqK1M7lBreSToTPolA==
=qUOF
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A few small driver specific fixes for v5.18, plus an update to the
MAINTAINERS file"
* tag 'regulator-fix-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
MAINTAINERS: Fix reviewer info for a few ROHM ICs
regulator: atc260x: Fix missing active_discharge_on setting
regulator: rtq2134: Fix missing active_discharge_on setting
regulator: wm8994: Add an off-on delay for WM8994 variant
- Improve API to make it clear that mmc_hw_reset() is for cards
- Fixup support for writeback-cache for eMMC and SD
- Check for errors after writes on SPI
MMC host:
- renesas_sdhi: A couple of fixes of TAP settings for eMMC HS400 mode
- mmci_stm32: Fixup check of all elements in sg list
- sdhci-xenon: Revert unnecessary fix for annoying 1.8V regulator warning
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmJP/M0XHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCnMnxAAjBBCFMHHG8wykeE8S3L6Bf5Y
gQGMBwCD5LAATOEHWsomtIlGDP9fa1NJawTJbMjCdX3oec3svx9WT1h6bSGMfieB
DYqhVYb+USHx3HsoVteu1fUq4VCtNv9PSnsQermEnV3iLeke8ahmlIlUc2SUW8BA
Y/37gxmvOFv2xCWtp5OWwqHLaBrWlgd5I/5c+f2YnlZ59ROitSUNMp0GUGk8mij4
0uGKbz+ZtwrynoZxhvtxahyHSH/s6csrkKLtHDUMcIpO7s6kneSLkbOwU6z9p0Hm
ILKdmrzrsfD23g4J8nshziGBnf+09a9dTuaEw872n/Oe9Gm1TA1GvhD021Prk7fa
iR1WzlfEZ+lK7SRo1urdz/OPaFsyAVinBbq3fZZ4LteKZw9Ef/9wph/+3vjECEMe
M7W8Zw4ir1iGwReRumY9dNvSB/ShfS5E0Cd6pybNHD+t2l68LYO/RBVDd2D1Efq4
ng7lsmmEkGQRodZaDQkUx9qU+RfxWKs0farfgW4zDMPVCEfrhXQ4P398rzuw04mB
VBjnen8D68QswwQPkNzKcG81c00qgKtxy/0soL1kYa2BpQMDrM7wWYYs/U/BGTZs
ut1GsozWcpnZ3smVG1i5sQVqJ8dhhM5z7Ebfb6FieV1iTSiWtUlQFlT3mhYRvk+L
JtbTRFQCOrjmxvlV9fQ=
=MC9g
-----END PGP SIGNATURE-----
Merge tag 'mmc-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC updates from Ulf Hansson:
"MMC core:
- Improve API to make it clear that mmc_hw_reset() is for cards
- Fixup support for writeback-cache for eMMC and SD
- Check for errors after writes on SPI
MMC host:
- renesas_sdhi: A couple of fixes of TAP settings for eMMC HS400 mode
- mmci_stm32: Fixup check of all elements in sg list
- sdhci-xenon: Revert unnecessary fix for annoying 1.8V regulator warning"
* tag 'mmc-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: core: improve API to make clear mmc_hw_reset is for cards
mmc: renesas_sdhi: don't overwrite TAP settings when HS400 tuning is complete
mmc: renesas_sdhi: special 4tap settings only apply to HS400
mmc: core: Fixup support for writeback-cache for eMMC and SD
mmc: block: Check for errors after write on SPI
mmc: mmci: stm32: correctly check all elements of sg list
Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning"
ACPI firmware advertises PCI host bridge resources via PNP0A03 _CRS
methods. Some BIOSes include non-window address space in _CRS, and if we
allocate that non-window space for PCI devices, they don't work.
4dc2287c18 ("x86: avoid E820 regions when allocating address space")
works around this issue by clipping out any regions mentioned in the E820
table in the allocate_resource() path, but the implementation has a couple
issues:
- The clipping is done for *all* allocations, not just those for PCI
address space, and
- The clipping is done at each allocation instead of being done once when
setting up the host bridge windows.
Rework the implementation so we only clip PCI host bridge windows, and we
do it once when setting them up.
Example output changes:
BIOS-e820: [mem 0x00000000b0000000-0x00000000c00fffff] reserved
+ acpi PNP0A08:00: clipped [mem 0xc0000000-0xfebfffff window] to [mem 0xc0100000-0xfebfffff window] for e820 entry [mem 0xb0000000-0xc00fffff]
- pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
+ pci_bus 0000:00: root bus resource [mem 0xc0100000-0xfebfffff window]
Link: https://lore.kernel.org/r/20220304035110.988712-3-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When remove_e820_regions() clips a resource because an E820 region overlaps
it, log a note in dmesg to add in debugging.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
- Some PSCI fixes after introducing PSCIv1.1 and SYSTEM_RESET2
- Fix the MMU write-lock not being taken on THP split
- Fix mixed-width VM handling
- Fix potential UAF when debugfs registration fails
- Various selftest updates for all of the above
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAmJQTkEPHG1hekBrZXJu
ZWwub3JnAAoJECPQ0LrRPXpDUHoP/3z2X49N4zbXyEW1OAbZEFtmm/Mi8gcaqhxN
M2lnzCTfBLuQMvWMcJGzlbPnXqhH1ouRWD4IiWpvIjoHznUccivysLQJcNl9ZCEN
JH82V0UCLCU58Syw706xBpOn8Ay3bOsUbzt/QSGttxKOJ+8LuSOt0obV8wr64ppg
m408+CvqgztK637hnTPNYQE1z6qABgZK2tUWDK5+TjazTX0B+bi60xRiDNNaOS/o
13wiNStrPzCGE6FwfGMefXqQ7fhLT8WAeYz/+9x7yUbniENZTmeI8iOiapQoMZaW
vlJudKPdbK1AIvhcm51bODB8DuHpJXswhzXVutSU3DdY7o7smqFH/9q82xgby4Oe
pFy2jwLwJ0P66Oo0M9IexPPxFUzls1ZGFLMfbIZeSflDHa0oGvvnFAH5Me+YIvbG
kyzh+wEytvr77baBBvcU+xRiKd1OsUE8AnGemwHSR8kV10kfmwt80iXgNLocStsa
mctnZY4vujtjh79avzdK2VzQ+e111+Ge1Q/I3RSpkCVg0M5yyZfygyv0LNPhN7oB
vZCJU/sZt5yZiI86pt7U0g71q95VeuC5ncG7fosC2nv7fWuDz1JRBjuiCqjccvIo
28AWEDin/y3+wKsJH4MfhFGFNmOUDZhUg2y0nzJiiKGCIyvWTK49fVwtwYpI/Jeh
nNBuAYH4
=0xZo
-----END PGP SIGNATURE-----
Merge tag 'kvmarm-fixes-5.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 fixes for 5.18, take #1
- Some PSCI fixes after introducing PSCIv1.1 and SYSTEM_RESET2
- Fix the MMU write-lock not being taken on THP split
- Fix mixed-width VM handling
- Fix potential UAF when debugfs registration fails
- Various selftest updates for all of the above
- Fix boot regression due to a NULL-ptr dereference on OMAP
machines
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEr9jSbILcajRFYWYyK/BELZcBGuMFAmJQHvgACgkQK/BELZcB
GuM1HxAAn05Z/mH69iJfG5A9iUUZEwTT4s2E59r+OlZtp3U5PS9N9MZ0tqr5ZW+W
RXW1G0kMh7vWnL2xesi2dJJyeqORl+fo6zW45xXQCbUPLWWetBu+Ewau/MB5LNxl
arj8eAllNjOI5FhUUpbu1zbo5pYFYEppd51aEXxdWtBLf9GsA1sH8WuWJOcYdy0H
aKa5iSjSuN9Ju4ujTjuFaiw4zsbVNkXvhBicF7HF5z9Flf6iB3NnL/js12njIn9Q
d4ePrc6jlg4B69VXiYQAFwxtBYSzAB0W6Ira/4596GpN8QG9/urb3sl0gRC4XfVk
n9NQkz1zmKw8BdBXSDzphTM+t8zCOlvefi3Fgc4Fcj2I1sr0ou4BtbYEITr8vnr8
LtIaisMSWMt4bhmeGcxpQqe141mXQ9OU4UmcI+E7pxDvn+BvZWY8RaARgRvtWc01
d9wAEjFSwPK1pEq9NzWPmM5RfD4aAU9gr/tq/LmuHG2a6+pHvie8vD/L8W/bUZny
9/53wTWhs3mrkFUMgsfMmhn/4rHqOgS2i6p+4GOaqy5cnix/rwExg4Qvtu64n2yx
B+g8el+UyLMRewZoWHC+/2fP20glJl3fl8Y8Zi2HW9Nx6WDLxzzyPfxApzbgXsRG
MCizYsGvfh/JqF7xZGAH3BfsVd0U1bmOdnalJjPrMnw99CP8/Dc=
=AR2P
-----END PGP SIGNATURE-----
Merge tag 'iommu-fix-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull iommu fix from Joerg Roedel:
- Fix boot regression due to a NULL-ptr dereference on OMAP machines
* tag 'iommu-fix-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/omap: Fix regression in probe for NULL pointer dereference
The as370.dtsi for Synaptics AS370 SoC does not have a user (DTS board
file), is uncompilable and untestable. It was added back in 2018. No
user appeared since that time, so assume it won't be added.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
During BTF fix up for global variables, global variable can be global
weak and will have STB_WEAK binding in ELF. Support such global
variables in addition to non-weak ones.
This is not the problem when using BPF static linking, as BPF static
linker "fixes up" BTF during generation so that libbpf doesn't have to
do it anymore during bpf_object__open(), which led to this not being
noticed for a while, along with a pretty rare (currently) use of __weak
variables and maps.
Reported-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20220407230446.3980075-2-andrii@kernel.org
Coverity static analyzer complains that strcpy() can cause buffer
overflow. Use libbpf_strlcpy() instead to be 100% sure this doesn't
happen.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20220407230446.3980075-1-andrii@kernel.org
This change caused a regression with resetting while changing network
namespaces. By clearing the IFF_UP flag, the kernel now thinks it has
fully closed the device.
This reverts commit 0cc318d2e8.
Fixes: 0cc318d2e8 ("iavf: Fix deadlock occurrence during resetting VF interface")
Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
The CI testing bots triggered the following splat:
[ 718.203054] BUG: KASAN: use-after-free in free_irq_cpu_rmap+0x53/0x80
[ 718.206349] Read of size 4 at addr ffff8881bd127e00 by task sh/20834
[ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: loaded Tainted: G S W IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1
[ 718.219695] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020
[ 718.223418] Call Trace:
[ 718.227139]
[ 718.230783] dump_stack_lvl+0x33/0x42
[ 718.234431] print_address_description.constprop.9+0x21/0x170
[ 718.238177] ? free_irq_cpu_rmap+0x53/0x80
[ 718.241885] ? free_irq_cpu_rmap+0x53/0x80
[ 718.245539] kasan_report.cold.18+0x7f/0x11b
[ 718.249197] ? free_irq_cpu_rmap+0x53/0x80
[ 718.252852] free_irq_cpu_rmap+0x53/0x80
[ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [ice]
[ 718.260174] ice_remove_arfs+0x5f/0x70 [ice]
[ 718.263810] ice_rebuild_arfs+0x3b/0x70 [ice]
[ 718.267419] ice_rebuild+0x39c/0xb60 [ice]
[ 718.270974] ? asm_sysvec_apic_timer_interrupt+0x12/0x20
[ 718.274472] ? ice_init_phy_user_cfg+0x360/0x360 [ice]
[ 718.278033] ? delay_tsc+0x4a/0xb0
[ 718.281513] ? preempt_count_sub+0x14/0xc0
[ 718.284984] ? delay_tsc+0x8f/0xb0
[ 718.288463] ice_do_reset+0x92/0xf0 [ice]
[ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice]
[ 718.295561] pci_reset_function+0x53/0x80
<...>
[ 718.393035] Allocated by task 690:
[ 718.433497] Freed by task 20834:
[ 718.495688] Last potentially related work creation:
[ 718.568966] The buggy address belongs to the object at ffff8881bd127e00
which belongs to the cache kmalloc-96 of size 96
[ 718.574085] The buggy address is located 0 bytes inside of
96-byte region [ffff8881bd127e00, ffff8881bd127e60)
[ 718.579265] The buggy address belongs to the page:
[ 718.598905] Memory state around the buggy address:
[ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
[ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
[ 718.607794] >ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
[ 718.610811] ^
[ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
[ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
This is due to that free_irq_cpu_rmap() is always being called
*after* (devm_)free_irq() and thus it tries to work with IRQ descs
already freed. For example, on device reset the driver frees the
rmap right before allocating a new one (the splat above).
Make rmap creation and freeing function symmetrical with
{request,free}_irq() calls i.e. do that on ifup/ifdown instead
of device probe/remove/resume. These operations can be performed
independently from the actual device aRFS configuration.
Also, make sure ice_vsi_free_irq() clears IRQ affinity notifiers
only when aRFS is disabled -- otherwise, CPU rmap sets and clears
its own and they must not be touched manually.
Fixes: 28bf26724f ("ice: Implement aRFS")
Co-developed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Tested-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Switch the code to use for_each_gpiochip_node() helper.
While at it, in order to avoid additional churn in the future,
do the following:
- use a temporary variable for struct device pointer to shorten a few lines
- get rid of a temporary variable for vIRQ number, assign it directly
- switch to fwnode APIs where it makes sense
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Switch the code to use for_each_gpiochip_node() helper.
While at it, in order to avoid additional churn in the future,
switch to fwnode APIs where it makes sense.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Since we have generic function to count GPIO controller nodes
under a given device, there is no need to open code it. Replace
custom code by gpiochip_node_count() call.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
When removing the adt7470 module, a warning might be printed:
do not call blocking ops when !TASK_RUNNING; state=1
set at [<ffffffffa006052b>] adt7470_update_thread+0x7b/0x130 [adt7470]
This happens because adt7470_update_thread() can leave the kthread in
TASK_INTERRUPTIBLE state when the kthread is being stopped before
the call of set_current_state(). Since kthread_exit() might sleep in
exit_signals(), the warning is printed.
Fix that by using schedule_timeout_interruptible() and removing
the call of set_current_state().
This causes TASK_INTERRUPTIBLE to be set after kthread_should_stop()
which might cause the kthread to exit.
Reported-by: Zheyu Ma <zheyuma97@gmail.com>
Fixes: 93cacfd41f (hwmon: (adt7470) Allow faster removal)
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Tested-by: Zheyu Ma <zheyuma97@gmail.com>
Link: https://lore.kernel.org/r/20220407101312.13331-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
After all the work that Linus Walleij did on this platform, it can be
part of a generic kernel build as well.
Note that there are known bugs in little-endian mode on ixp4xx, and
no other ARMv5 platform at this point supports big-endian mode, or is
likely to in the future, so there is limited practical value in this,
but it helps with build testing and ixp4xx little-endian support may
get fixed in the future.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Choosing big-endian vs little-endian kernels in Kconfig has not worked
correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long
time ago.
The problems is that CONFIG_BIG_ENDIAN depends on
ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform
in the config, but would actually have to be supported by all
of them.
This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and
tend to just work aside from problems in nonportable device drivers.
For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM
were never set together, so this was disabled on all those machines
except for IXP4xx.
As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to
formalize this logic: all ARMv4/v5 platforms get an explicit dependency
on being either big-endian (ixp4xx) or little-endian (the rest). We may
want to fix ixp4xx in the future to support both, but it does not work
in LE mode at the moment.
For the ARMv6/v7 platforms, there are two ways this could be handled
a) allow both modes only for platforms selecting
'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the
others, given that these were added intentionally at some
point.
b) allow both modes everwhere, given that it was already possible
to build that way by e.g. selecting ARCH_VIRT, and that the
list is not an accurate reflection of which platforms may or
may not work.
Out of these, I picked b) because it seemed slighly more logical
to me.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
After iop32x was converted to the generic multi-irq entry
code, nothing really stops us from building it into a
generic kernel.
The two last headers can simply be removed, the mach/irqs.h
gets replaced with the sparse-irq intiialization from the
board specific .nr_irqs value, and the decompressor debug
output can use the debug_ll hack that all other platforms
use.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
With the custom ISA I/O and the missing sparse-irq support
out of the way, s3c24xx can now be built into the same
kernel as all other ARM9 based platforms.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Document support for the SPI Multi I/O Bus Controller (RPC-IF) in the
R-Car H3, M3-W, M3-W+, M3-N, and E3 SoCs.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/3784b6cb76a008fb56d6cb4ba228d78c77e710fa.1648546583.git.geert+renesas@glider.be
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
After a successful lpass_macro_pds_init() call, lpass_macro_pds_exit() must
be called.
Add the missing call in the error handling path of the probe function and
use it.
Fixes: 9e3d83c528 ("ASoC: codecs: Add power domains support in digital macro codecs")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/5b5a015a9b1dc8011c6a4053fa49da1f2531e47c.1648969065.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Jiaxin Yu <jiaxin.yu@mediatek.com>:
The series reuses mt8192-mt6359-rt1015-rt5682.c for supporting machine
driver with rt1015p speaker amplifier and rt5682s headset codec.
Fix the following coccicheck review:
./sound/soc/mediatek/mt8195/mt8195-mt6359.c:1657:1-2:
mt8195_mt6359_dt_match is not NULL terminated at line 1657
Fixes: 86a6b9c9df ("ASoC: mediatek: mt8195: add machine support for max98390 and rt5682")
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
Link: https://lore.kernel.org/r/20220408100309.2495462-1-lv.ruyi@zte.com.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
