aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-22irqchip/gic-v4.1: Add VPE INVALL callbackMarc Zyngier2-0/+20
GICv4.1 redistributors have a VPE-aware INVALL register. Progress! We can now emulate a guest-requested INVALL without emiting a VINVALL command. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v4.1: Add VPE eviction callbackMarc Zyngier1-11/+42
When descheduling a VPE, special care must be taken to tell the GIC about whether we want to receive a doorbell or not. This is a major improvement on GICv4.0, where the doorbell had to be separately enabled/disabled. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v4.1: Add VPE residency callbackMarc Zyngier3-0/+31
Making a VPE resident on GICv4.1 is pretty simple, as it is just a single write to the local redistributor. We just need extra information about which groups to enable, which the KVM code will have to provide. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v4.1: Add mask/unmask doorbell callbacksMarc Zyngier2-1/+75
masking/unmasking doorbells on GICv4.1 relies on a new INVDB command, which broadcasts the invalidation to all RDs. Implement the new command as well as the masking callbacks, and plug the whole thing into the v4.1 VPE irqchip. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v4.1: Plumb skeletal VPE irqchipMarc Zyngier1-1/+31
Just like for GICv4.0, each VPE has its own doorbell interrupt, and thus an irqchip that manages them. Since the doorbell management is quite different on GICv4.1, let's introduce an almost empty irqchip the will get populated over the next new patches. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v4.1: Implement the v4.1 flavour of VMOVPMarc Zyngier1-7/+33
With GICv4.1, VMOVP is extended to allow a default doorbell to be specified, as well as a validity bit for this doorbell. As an added bonus, VMOVP isn't required anymore of moving a VPE between redistributors that share the same affinity. Let's add this support to the VMOVP builder, and make sure we don't issue the command if we don't really need to. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v4.1: Don't use the VPE proxy if RVPEID is setMarc Zyngier1-1/+24
The infamous VPE proxy device isn't used with GICv4.1 because: - we can invalidate any LPI from the DirectLPI MMIO interface - the ITS and redistributors understand the life cycle of the doorbell, so we don't need to enable/disable it all the time So let's escape early from the proxy related functions. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPPMarc Zyngier2-9/+69
The ITS VMAPP command gains some new fields with GICv4.1: - a default doorbell, which allows a single doorbell to be used for all the VLPIs routed to a given VPE - a pointer to the configuration table (instead of having it in a register that gets context switched) - a flag indicating whether this is the first map or the last unmap for this particular VPE - a flag indicating whether the pending table is known to be zeroed, or not Plumb in the new fields in the VMAPP builder, and add the map/unmap refcounting so that the ITS can do the right thing. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v4.1: VPE table (aka GICR_VPROPBASER) allocationMarc Zyngier4-7/+339
GICv4.1 defines a new VPE table that is potentially shared between both the ITSs and the redistributors, following complicated affinity rules. To make things more confusing, the programming of this table at the redistributor level is reusing the GICv4.0 GICR_VPROPBASER register for something completely different. The code flow is somewhat complexified by the need to respect the affinities required by the HW, meaning that tables can either be inherited from a previously discovered ITS or redistributor. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v3: Add GICv4.1 VPEID size discoveryMarc Zyngier3-1/+18
While GICv4.0 mandates 16 bit worth of VPEIDs, GICv4.1 allows smaller implementations to be built. Add the required glue to dynamically compute the limit. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v3: Detect GICv4.1 supporting RVPEIDMarc Zyngier2-3/+20
GICv4.1 supports the RVPEID ("Residency per vPE ID"), which allows for a much efficient way of making virtual CPUs resident (to allow direct injection of interrupts). The functionnality needs to be discovered on each and every redistributor in the system, and disabled if the settings are inconsistent. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22irqchip/gic-v3-its: Fix get_vlpi_map() breakage with doorbellsMarc Zyngier1-5/+6
When updating an LPI configuration, get_vlpi_map() may be passed a irq_data structure relative to an ITS domain (the normal case) or one that is relative to the core GICv3 domain in the case of a GICv4 doorbell. In the latter case, special care must be take not to dereference the irq_chip data as an its_dev structure, as that isn't what is stored there. Instead, check *first* whether the IRQ is forwarded to a vcpu, and only then try to obtain the vlpi mapping. Fixes: c1d4d5cd203c ("irqchip/gic-v3-its: Add its_vlpi_map helpers") Signed-off-by: Marc Zyngier <[email protected]> Reported-by: Zenghui Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22tracing/uprobe: Fix to make trace_uprobe_filter alignment safeMasami Hiramatsu4-28/+22
Commit 99c9a923e97a ("tracing/uprobe: Fix double perf_event linking on multiprobe uprobe") moved trace_uprobe_filter on trace_probe_event. However, since it introduced a flexible data structure with char array and type casting, the alignment of trace_uprobe_filter can be broken. This changes the type of the array to trace_uprobe_filter data strucure to fix it. Link: http://lore.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/157966340499.5107.10978352478952144902.stgit@devnote2 Fixes: 99c9a923e97a ("tracing/uprobe: Fix double perf_event linking on multiprobe uprobe") Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2020-01-22Merge branch 'for-next/rng' into for-next/coreWill Deacon11-2/+124
* for-next/rng: (2 commits) arm64: Use v8.5-RNG entropy for KASLR seed ...
2020-01-22Merge branch 'for-next/errata' into for-next/coreWill Deacon9-25/+61
* for-next/errata: (3 commits) arm64: Workaround for Cortex-A55 erratum 1530923 ...
2020-01-22Merge branch 'for-next/asm-annotations' into for-next/coreWill Deacon25-104/+112
* for-next/asm-annotations: (6 commits) arm64: kernel: Correct annotation of end of el0_sync ...
2020-01-22Merge branches 'for-next/acpi', 'for-next/cpufeatures', 'for-next/csum', ↵Will Deacon64-382/+954
'for-next/e0pd', 'for-next/entry', 'for-next/kbuild', 'for-next/kexec/cleanup', 'for-next/kexec/file-kdump', 'for-next/misc', 'for-next/nofpsimd', 'for-next/perf' and 'for-next/scs' into for-next/core * for-next/acpi: ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map() * for-next/cpufeatures: (2 commits) arm64: Introduce ID_ISAR6 CPU register ... * for-next/csum: (2 commits) arm64: csum: Fix pathological zero-length calls ... * for-next/e0pd: (7 commits) arm64: kconfig: Fix alignment of E0PD help text ... * for-next/entry: (5 commits) arm64: entry: cleanup sp_el0 manipulation ... * for-next/kbuild: (4 commits) arm64: kbuild: remove compressed images on 'make ARCH=arm64 (dist)clean' ... * for-next/kexec/cleanup: (11 commits) Revert "arm64: kexec: make dtb_mem always enabled" ... * for-next/kexec/file-kdump: (2 commits) arm64: kexec_file: add crash dump support ... * for-next/misc: (12 commits) arm64: entry: Avoid empty alternatives entries ... * for-next/nofpsimd: (7 commits) arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly ... * for-next/perf: (2 commits) perf/imx_ddr: Fix cpu hotplug state cleanup ... * for-next/scs: (6 commits) arm64: kernel: avoid x18 in __cpu_soft_restart ...
2020-01-22arm64: kconfig: Fix alignment of E0PD help textWill Deacon1-6/+6
Remove the additional space. Signed-off-by: Will Deacon <[email protected]>
2020-01-22arm64: Use v8.5-RNG entropy for KASLR seedMark Brown2-0/+19
When seeding KALSR on a system where we have architecture level random number generation make use of that entropy, mixing it in with the seed passed by the bootloader. Since this is run very early in init before feature detection is complete we open code rather than use archrandom.h. Signed-off-by: Mark Brown <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-01-22arm64: Implement archrandom.h for ARMv8.5-RNGRichard Henderson10-1/+108
Expose the ID_AA64ISAR0.RNDR field to userspace, as the RNG system registers are always available at EL0. Implement arch_get_random_seed_long using RNDR. Given that the TRNG is likely to be a shared resource between cores, and VMs, do not explicitly force re-seeding with RNDRRS. In order to avoid code complexity and potential issues with hetrogenous systems only provide values after cpufeature has finalized the system capabilities. Signed-off-by: Richard Henderson <[email protected]> [Modified to only function after cpufeature has finalized the system capabilities and move all the code into the header -- broonie] Signed-off-by: Mark Brown <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> [will: Advertise HWCAP via /proc/cpuinfo] Signed-off-by: Will Deacon <[email protected]>
2020-01-22powerpc/xive: Discard ESB load value when interrupt is invalidFrederic Barrat2-3/+13
A load on an ESB page returning all 1's means that the underlying device has invalidated the access to the PQ state of the interrupt through mmio. It may happen, for example when querying a PHB interrupt while the PHB is in an error state. In that case, we should consider the interrupt to be invalid when checking its state in the irq_get_irqchip_state() handler. Fixes: da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race") Cc: [email protected] # v5.4+ Signed-off-by: Frederic Barrat <[email protected]> [clg: wrote a commit log, introduced XIVE_ESB_INVALID ] Signed-off-by: Cédric Le Goater <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22powerpc: Ultravisor: Fix the dependencies for CONFIG_PPC_UVBharata B Rao1-5/+1
Let PPC_UV depend only on DEVICE_PRIVATE which in turn will satisfy all the other required dependencies Fixes: 013a53f2d25a ("powerpc: Ultravisor: Add PPC_UV config option") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Bharata B Rao <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-22tpm: Add tpm_version_major sysfs fileJerry Snitselaar2-7/+38
Easily determining what TCG version a tpm device implements has been a pain point for userspace for a long time, so add a sysfs file to report the TCG major version of a tpm device. Also add an entry to Documentation/ABI/stable/sysfs-class-tpm describing the new file. Cc: Jarkko Sakkinen <[email protected]> Cc: Mimi Zohar <[email protected]> Cc: Peter Huewe <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: [email protected] Signed-off-by: Jerry Snitselaar <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-01-22tpm: Update mailing list contact information in sysfs-class-tpmJerry Snitselaar1-11/+11
All of the entries in Documentation/ABI/stable/sysfs-class-tpm point to the old tpmdd-devel mailing list. This patch updates the entries to point to linux-intergrity. Cc: Jarkko Sakkinen <[email protected]> Cc: Peter Huewe <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: [email protected] Signed-off-by: Jerry Snitselaar <[email protected]> Acked-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-01-22efi/x86: Disallow efi=old_map in mixed modeArd Biesheuvel1-1/+1
Before: 1f299fad1e31: ("efi/x86: Limit EFI old memory map to SGI UV machines") enabling the old EFI memory map on mixed mode systems disabled EFI runtime services altogether. Given that efi=old_map is a debug feature designed to work around firmware problems related to EFI runtime services, and disabling them can be achieved more straightforwardly using 'noefi' or 'efi=noruntime', it makes more sense to ignore efi=old_map on mixed mode systems. Currently, we do neither, and try to use the old memory map in combination with mixed mode routines, which results in crashes, so let's fix this by making efi=old_map functional on native systems only. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-01-21ceph: hold extra reference to r_parent over life of requestJeff Layton1-2/+6
Currently, we just assume that it will stick around by virtue of the submitter's reference, but later patches will allow the syscall to return early and we can't rely on that reference at that point. While I'm not aware of any reports of it, Xiubo pointed out that this may fix a use-after-free. If the wait for a reply times out or is canceled via signal, and then the reply comes in after the syscall returns, the client can end up trying to access r_parent without a reference. Take an extra reference to the inode when setting r_parent and release it when releasing the request. Cc: [email protected] Signed-off-by: Jeff Layton <[email protected]> Reviewed-by: "Yan, Zheng" <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2020-01-21Merge branch 'regmap-5.6' into regmap-nextMark Brown3-10/+62
2020-01-21spi: pxa2xx: Avoid touching SSCR0_SSE on MMP2Lubomir Rintel1-11/+17
A read from a Winbond W25Q32FV SPI NOR memory chip on my MMP2 returns wrong data. It seems like SSE doesn't do the right thing on MMP2 at all. After enabling the SPI port back again, the FIFO reads return garbage. Things can be brought back to order by telling the PMU to reset the block. Here's a good transaction with said chip: # busybox devmem 0xd4035000 32 0x00001987 # SSCR0 # echo 0 >/sys/class/gpio/gpio46/value # (assert CS) # busybox devmem 0xd4035010 32 0x0000009f # SSDR (read ID command) # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 # SSDR 0x000000ff # busybox devmem 0xd4035010 # SSDR 0x000000ef # Correct response # busybox devmem 0xd4035010 # SSDR 0x00000040 # busybox devmem 0xd4035010 # SSDR 0x00000016 # busybox devmem 0xd4035010 # SSDR 0x00000000 # busybox devmem 0xd4035010 # SSDR 0x00000000 # busybox devmem 0xd4035010 # SSDR 0x00000000 # echo 1 >/sys/class/gpio/gpio46/value # (deassert CS) # Flipping off an on SSE, then running another transaction: # busybox devmem 0xd4035000 32 0x00001907 # SSCR0, SSE off # busybox devmem 0xd4035000 32 0x00001987 # SSCR0, SSE on # echo 0 >/sys/class/gpio/gpio46/value # (assert CS) # busybox devmem 0xd4035010 32 0x0000009f # SSDR (read ID command) # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 32 0x00000000 # SSDR # busybox devmem 0xd4035010 # SSDR 0x000000ff # busybox devmem 0xd4035010 # SSDR 0x000000ff # Garbage! # busybox devmem 0xd4035010 # SSDR 0x000000ff # Oh no # busybox devmem 0xd4035010 # SSDR 0x000000ff # busybox devmem 0xd4035010 # SSDR 0x000000ff # busybox devmem 0xd4035010 # SSDR 0x000000ff # busybox devmem 0xd4035010 # SSDR 0x000000ff # echo 1 >/sys/class/gpio/gpio46/value # (deassert CS) # Sometimes the response is not just ones, but something that looks like bits of a response from a previous transaction. I can't see a fix other than not touching the SSE altogether after the device is first brought up. Signed-off-by: Lubomir Rintel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-21regmap: fix writes to non incrementing registersBen Whitten1-5/+12
When checking if a register block is writable we must ensure that the block does not start with or contain a non incrementing register. Fixes: 8b9f9d4dc511 ("regmap: verify if register is writeable before writing operations") Signed-off-by: Ben Whitten <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-21spi: spi-fsl-qspi: Ensure width is respected in spi-mem operationsMichael Walle1-1/+1
Make use of a core helper to ensure the desired width is respected when calling spi-mem operators. Otherwise only the SPI controller will be matched with the flash chip, which might lead to wrong widths. Also consider the width specified by the user in the device tree. Fixes: 84d043185dbe ("spi: Add a driver for the Freescale/NXP QuadSPI controller") Signed-off-by: Michael Walle <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-21drm/panfrost: Add the panfrost_gem_mapping conceptBoris Brezillon9-74/+300
With the introduction of per-FD address space, the same BO can be mapped in different address space if the BO is globally visible (GEM_FLINK) and opened in different context or if the dmabuf is self-imported. The current implementation does not take case into account, and attaches the mapping directly to the panfrost_gem_object. Let's create a panfrost_gem_mapping struct and allow multiple mappings per BO. The mappings are refcounted which helps solve another problem where mappings were torn down (GEM handle closed by userspace) while GPU jobs accessing those BOs were still in-flight. Jobs now keep a reference on the mappings they use. v2 (robh): - Minor review comment clean-ups from Steven - Use list_is_singular helper - Just WARN if we add a mapping when madvise state is not WILLNEED. With that, drop the use of object_name_lock. v3 (robh): - Revert returning list iterator in panfrost_gem_mapping_get() Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Rob Herring <[email protected]> Acked-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-21arm64: kbuild: remove compressed images on 'make ARCH=arm64 (dist)clean'Dirk Behme1-1/+1
Since v4.3-rc1 commit 0723c05fb75e44 ("arm64: enable more compressed Image formats"), it is possible to build Image.{bz2,lz4,lzma,lzo} AArch64 images. However, the commit missed adding support for removing those images on 'make ARCH=arm64 (dist)clean'. Fix this by adding them to the target list. Make sure to match the order of the recipes in the makefile. Cc: [email protected] # v4.3+ Fixes: 0723c05fb75e44 ("arm64: enable more compressed Image formats") Signed-off-by: Dirk Behme <[email protected]> Signed-off-by: Eugeniu Rosca <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-01-21net, ip_tunnel: fix namespaces moveWilliam Dauchy1-3/+1
in the same manner as commit 690afc165bb3 ("net: ip6_gre: fix moving ip6gre between namespaces"), fix namespace moving as it was broken since commit 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata."). Indeed, the ip6_gre commit removed the local flag for collect_md condition, so there is no reason to keep it for ip_gre/ip_tunnel. this patch will fix both ip_tunnel and ip_gre modules. Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.") Signed-off-by: William Dauchy <[email protected]> Acked-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-21arm64: entry: Avoid empty alternatives entriesJulien Thierry1-2/+2
kernel_ventry will create alternative entries to potentially replace 0 instructions with 0 instructions for EL1 vectors. While this does not cause an issue, it pointlessly takes up some bytes in the alternatives section. Do not generate such entries. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Julien Thierry <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-01-21tcp: remove redundant assigment to snd_cwndTheodore Dubois1-1/+0
Not sure how this got in here. git blame says the second assignment was added in 3a9a57f6, but that commit also removed the first assignment. Signed-off-by: Theodore Dubois <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-21net: usb: lan78xx: Add .ndo_features_checkJames Hughes1-0/+15
As reported by Eric Dumazet, there are still some outstanding cases where the driver does not handle TSO correctly when skb's are over a certain size. Most cases have been fixed, this patch should ensure that forwarded SKB's that are greater than MAX_SINGLE_PACKET_SIZE - TX_OVERHEAD are software segmented and handled correctly. Signed-off-by: James Hughes <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-21tcp_bbr: improve arithmetic division in bbr_update_bw()Wen Yang1-2/+1
do_div() does a 64-by-32 division. Use div64_long() instead of it if the divisor is long, to avoid truncation to 32-bit. And as a nice side effect also cleans up the function a bit. Signed-off-by: Wen Yang <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Alexey Kuznetsov <[email protected]> Cc: Hideaki YOSHIFUJI <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-21net-sysfs: Fix reference count leakJouni Hogander1-1/+3
Netdev_register_kobject is calling device_initialize. In case of error reference taken by device_initialize is not given up. Drivers are supposed to call free_netdev in case of error. In non-error case the last reference is given up there and device release sequence is triggered. In error case this reference is kept and the release sequence is never started. Fix this by setting reg_state as NETREG_UNREGISTERED if registering fails. This is the rootcause for couple of memory leaks reported by Syzkaller: BUG: memory leak unreferenced object 0xffff8880675ca008 (size 256): comm "netdev_register", pid 281, jiffies 4294696663 (age 6.808s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000058ca4711>] kmem_cache_alloc_trace+0x167/0x280 [<000000002340019b>] device_add+0x882/0x1750 [<000000001d588c3a>] netdev_register_kobject+0x128/0x380 [<0000000011ef5535>] register_netdevice+0xa1b/0xf00 [<000000007fcf1c99>] __tun_chr_ioctl+0x20d5/0x3dd0 [<000000006a5b7b2b>] tun_chr_ioctl+0x2f/0x40 [<00000000f30f834a>] do_vfs_ioctl+0x1c7/0x1510 [<00000000fba062ea>] ksys_ioctl+0x99/0xb0 [<00000000b1c1b8d2>] __x64_sys_ioctl+0x78/0xb0 [<00000000984cabb9>] do_syscall_64+0x16f/0x580 [<000000000bde033d>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<00000000e6ca2d9f>] 0xffffffffffffffff BUG: memory leak unreferenced object 0xffff8880668ba588 (size 8): comm "kobject_set_nam", pid 286, jiffies 4294725297 (age 9.871s) hex dump (first 8 bytes): 6e 72 30 00 cc be df 2b nr0....+ backtrace: [<00000000a322332a>] __kmalloc_track_caller+0x16e/0x290 [<00000000236fd26b>] kstrdup+0x3e/0x70 [<00000000dd4a2815>] kstrdup_const+0x3e/0x50 [<0000000049a377fc>] kvasprintf_const+0x10e/0x160 [<00000000627fc711>] kobject_set_name_vargs+0x5b/0x140 [<0000000019eeab06>] dev_set_name+0xc0/0xf0 [<0000000069cb12bc>] netdev_register_kobject+0xc8/0x320 [<00000000f2e83732>] register_netdevice+0xa1b/0xf00 [<000000009e1f57cc>] __tun_chr_ioctl+0x20d5/0x3dd0 [<000000009c560784>] tun_chr_ioctl+0x2f/0x40 [<000000000d759e02>] do_vfs_ioctl+0x1c7/0x1510 [<00000000351d7c31>] ksys_ioctl+0x99/0xb0 [<000000008390040a>] __x64_sys_ioctl+0x78/0xb0 [<0000000052d196b7>] do_syscall_64+0x16f/0x580 [<0000000019af9236>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<00000000bc384531>] 0xffffffffffffffff v3 -> v4: Set reg_state to NETREG_UNREGISTERED if registering fails v2 -> v3: * Replaced BUG_ON with WARN_ON in free_netdev and netdev_release v1 -> v2: * Relying on driver calling free_netdev rather than calling put_device directly in error path Reported-by: [email protected] Cc: David Miller <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Lukas Bulwahn <[email protected]> Signed-off-by: Jouni Hogander <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-21dmaengine: Move dma_get_{,any_}slave_channel() to private dmaengine.hGeert Uytterhoeven3-2/+5
The functions dma_get_slave_channel() and dma_get_any_slave_channel() are called from DMA engine drivers only. Hence move their declarations from the public header file <linux/dmaengine.h> to the private header file drivers/dma/dmaengine.h. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-01-21dmaengine: Remove dma_request_slave_channel_compat() wrapperGeert Uytterhoeven1-4/+2
At its original introduction, dma_request_slave_channel_compat() used a wrapper, to accommodate filter functions that modify the mask passed. Filter functions can no longer modify masks, and the mask parameter was made const in commit a53e28da574a40bc ("dma: Make the 'mask' parameter of __dma_request_channel const") consecutively. Hence remove the wrapper, and rename __dma_request_slave_channel_compat() to dma_request_slave_channel_compat(), to get rid of one more function name starting with a double underscore. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-01-21dmaengine: Remove dma_device_satisfies_mask() wrapperGeert Uytterhoeven1-6/+3
Commit aa1e6f1a385eb2b0 ("dmaengine: kill struct dma_client and supporting infrastructure") removed the last user of the dma_device_satisfies_mask() wrapper. Remove the wrapper, and rename __dma_device_satisfies_mask() to dma_device_satisfies_mask(), to get rid of one more function starting with a double underscore. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-01-21dt-bindings: fsl-imx-sdma: Add i.MX8MM/i.MX8MN/i.MX8MP compatible stringAnson Huang1-0/+3
Add imx8mm/imx8mn/imx8mp sdma support. Signed-off-by: Anson Huang <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-01-21dmaengine: zynqmp_dma: fix burst length configurationMatthias Fend1-9/+15
Since the dma engine expects the burst length register content as power of 2 value, the burst length needs to be converted first. Additionally add a burst length range check to avoid corrupting unrelated register bits. Signed-off-by: Matthias Fend <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-01-21ipv6: sr: remove SKB_GSO_IPXIP6 on End.D* actionsYuki Taguchi1-1/+3
After LRO/GRO is applied, SRv6 encapsulated packets have SKB_GSO_IPXIP6 feature flag, and this flag must be removed right after decapulation procedure. Currently, SKB_GSO_IPXIP6 flag is not removed on End.D* actions, which creates inconsistent packet state, that is, a normal TCP/IP packets have the SKB_GSO_IPXIP6 flag. This behavior can cause unexpected fallback to GSO on routing to netdevices that do not support SKB_GSO_IPXIP6. For example, on inter-VRF forwarding, decapsulated packets separated into small packets by GSO because VRF devices do not support TSO for packets with SKB_GSO_IPXIP6 flag, and this degrades forwarding performance. This patch removes encapsulation related GSO flags from the skb right after the End.D* action is applied. Fixes: d7a669dd2f8b ("ipv6: sr: add helper functions for seg6local") Signed-off-by: Yuki Taguchi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-21arm64: Kconfig: select HAVE_FUTEX_CMPXCHGVladimir Murzin1-0/+1
arm64 provides always working implementation of futex_atomic_cmpxchg_inatomic(), so there is no need to check it runtime. Reported-by: Piyush swami <[email protected]> Signed-off-by: Vladimir Murzin <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-01-21dmaengine: sun4i: Add support for cyclic requests with dedicated DMAStefan Mavrodiev1-21/+24
Currently the cyclic transfers can be used only with normal DMAs. They can be used by pcm_dmaengine module, which is required for implementing sound with sun4i-hdmi encoder. This is so because the controller can accept audio only from a dedicated DMA. This patch enables them, following the existing style for the scatter/gather type transfers. Signed-off-by: Stefan Mavrodiev <[email protected]> Acked-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-01-21Merge branch 'master' of ↵David S. Miller5-12/+52
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2020-01-21 1) Fix packet tx through bpf_redirect() for xfrm and vti interfaces. From Nicolas Dichtel. 2) Do not confirm neighbor when do pmtu update on a virtual xfrm interface. From Xu Wang. 3) Support output_mark for offload ESP packets, this was forgotten when the output_mark was added initially. From Ulrich Weber. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-01-21dmaengine: fsl-qdma: fix duplicated argument to &&Chen Zhou1-1/+1
There is duplicated argument to && in function fsl_qdma_free_chan_resources, which looks like a typo, pointer fsl_queue->desc_pool also needs NULL check, fix it. Detected with coccinelle. Fixes: b092529e0aa0 ("dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs") Signed-off-by: Chen Zhou <[email protected]> Reviewed-by: Peng Ma <[email protected]> Tested-by: Peng Ma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-01-21dmaengine: ti: k3-psil: make symbols staticPeter Ujfalusi4-7/+8
Fixe the following warnings by making these static drivers/dma/ti/k3-psil-j721e.c:62:16: warning: symbol 'j721e_src_ep_map' was not declared. Should it be static? drivers/dma/ti/k3-psil-j721e.c:172:16: warning: symbol 'j721e_dst_ep_map' was not declared. Should it be static? drivers/dma/ti/k3-psil-j721e.c:216:20: warning: symbol 'j721e_ep_map' was not declared. Should it be static? CC drivers/dma/ti/k3-psil-j721e.o drivers/dma/ti/k3-psil-am654.c:52:16: warning: symbol 'am654_src_ep_map' was not declared. Should it be static? drivers/dma/ti/k3-psil-am654.c:127:16: warning: symbol 'am654_dst_ep_map' was not declared. Should it be static? drivers/dma/ti/k3-psil-am654.c:169:20: warning: symbol 'am654_ep_map' was not declared. Should it be static? Reported-by: Vinod Koul <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] [vkoul: updated patch title] Signed-off-by: Vinod Koul <[email protected]>
2020-01-21drm/i915: Align engine->uabi_class/instance with i915_drm.hTvrtko Ursulin2-8/+8
In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates implicit coupling with type widths used in, also ABI, struct i915_engine_class_instance. One place where we export engine->uabi_class I915_ENGINE_CLASS_INVALID_VIRTUAL is from our our tracepoints. Because the type of the former is u8 in contrast to u16 defined in the ABI, 254 will be returned instead of 65534 which userspace would legitimately expect. Another place is I915_CONTEXT_PARAM_ENGINES. Therefore we need to align the type used to store engine ABI class and instance. v2: * Update the commit message mentioning get_engines and cc stable. (Chris) Signed-off-by: Tvrtko Ursulin <[email protected]> Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Cc: Chris Wilson <[email protected]> Cc: <[email protected]> # v5.3+ Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 0b3bd0cdc329a1e2e00995cffd61aacf58c87cb4) Signed-off-by: Joonas Lahtinen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.